Jump to content
bren

12F683 6Bit Gpio Pics Comparator Not Fully Implemented

Recommended Posts

Hi,

 

I've spent the last few days trying to migrate to BoostC but it seems that 6bit GPIO chips are not fully implemented.

OS WIn7
SourceBoost IDE 7.05
12F683

 

 

 

 

 

 

The comparator uses GP0,GP1,GP2 and an internal voltage reference to function.

It can be configured in many ways but it's output (COUT) is always available as bit6 of the CMCON0 register.

CMCON0 : [
u
] [
cout
] [
u
] [cinv] [cis] [cm2] [cm1] [cm0]
(page 56 of the 12F683 pdf - 41211d)

 

 

 

 

 

 

I'm setting the comparator up in mode 6 (cm2:0<110>) for the first example and mode 5 (cm2:0<101>) for the second.

Both use the internal reference. Mode 6 does not put COUT on GP2, Mode 5 does.

Regardless, COUT should be available internally all the time.
The examples below illustrate the hair pulling and suffering I endured before I facepalmed a WORKAROUND
(yes I know - I read the EULA - it's ok)
Facepalm workaround
#define COMPOUT cmcon0.6
But of course...
#define COUT cmcon0.6
will not work because COUT is already taken by the compiler that refuses to implement it
:rolleyes:

 

 

 

 

In both examples my dev board's pot is hard wired to GP0(AN0:CIN+).

I am multiplexing it as an input (cis<1>).

 

 

Here is an example of how COUT is not available internally.

 

#include		 <system.h>
#pragma		 CLOCK_FREQ 20000000
#pragma DATA	_CONFIG, _WDT_OFF & _CP_OFF & _HS_OSC & _MCLRE_OFF
#include "firsttry.h"

//Labels for General Purpose ports
//0 pot input from PCB
#define LED		 gpio.1


//MAIN

void main()
{

trisio	 = 0b000001;		//GP0(AN0) as input
// cmcon0 [cinv][cis][cm2][cm1][cm0]
cmcon0	 = 0b01110;		 // internal vref // CIN+ input multiplexed to GP0(AN0) // COUT internal only - aka mode 6
ansel	  = 0b0001;		// allow GP0 to be analogue   	
vrcon	 = 0b10000001;	 // internal vref HIGH range to allow pot to move mid range
delay_us(20);	// just to allow things to settle


// This should cause the LED to light when COUT  is triggered by the pot input
// but it does not do so

while(1){
LED = COUT;
}
}

 

 

 

Here is an example of what does work however it requires COUT to be on GP2 and then have a my variable (COMPOUT) defined to mirror that port.

(this of course uses port GP2 which defeats the object of using a low pin count device - see facepalm solution above)

 

#include		 <system.h>
#pragma		 CLOCK_FREQ 20000000
#pragma DATA	_CONFIG, _WDT_OFF & _CP_OFF & _HS_OSC & _MCLRE_OFF
#include "firsttry.h"

//Labels for General Purpose ports
//0 pot input from PCB
#define LED		 gpio.1
#define COMPOUT		 gpio.2 // **ADDED BECAUSE COUT IS NOT AVAILABLE INTERNALLY - MUST BE PATCHED PHYSICALLY**

//MAIN

void main()
{

trisio	 = 0b000001;		//GP0(AN0) as input
// cmcon0 [cinv][cis][cm2][cm1][cm0]
cmcon0	 = 0b01101;	 // internal vref // CIN+ input multiplexed to GP0(AN0) // COUT on GP2 - aka mode 5 // **CHANGED**
ansel	  = 0b0001;		// allow GP0(AN0) to be analogue   	
vrcon	 = 0b10000001;	 // internal vref HIGH range to allow pot to move mid range
delay_us(20);	// just to allow things to settle


// This will cause the LED to light when COUT is triggered by the pot input
// but only because it's made available on a real pin (GP2) and assigned to a variable

while(1){
//LED = COUT; // does not work and yet COUT cannot be redefined - i.e. it's been assigned but not implemented
LED = COMPOUT;
}
}

 

Other things like cinv/cis/cm2/cm1/cm0 cannot be set individually and of course result in compile errors.

 

 

 

 

 

 

The 12F683 and similar PICs are very powerful and useful little devices.

I'm currently generating a video signal from scratch (in ASM - not an overlay but actual video source) and now need to detect an incoming video signal's presence, or lack thereof, which obviously needs the comparator.

All the difficult timing is done in ASM. I just need to patch some logic into the application which is what C would be used for.

 

If this is not a bug and I'm doing something wrong then please feel free to move/retitle this post.

But as far as I can tell you guys think the 8 legged PICs are not worthy of being concidered BIG BOYS (the plugins have ignored the GPIO for about 4 yrs and counting) -_-

 

thanks,

 

Bren

Share this post


Link to post
Share on other sites

Take a look at the PIC12F683.h file in the "include" subdiecrory of your Sourceboost installation. You will see that COUT is defined as 6 in the COMCON0 bits section (since it is bit 6 of the cmcon0 register.. To use COUT you have to provide the full register and bit name so in your example you would need to write

LED = cmcon0.COUT;

Share this post


Link to post
Share on other sites

It's a rather odd way of doing things.

 

cmcon0.6 is faster to type

 

I ended out commenting out COUT and similar in the 12f683.h file and doing the defines in my code as follows

 

#define COUT cmcon0.6

#define CM0. cmcon.0

 

etc

Share this post


Link to post
Share on other sites

Obviously you are a liberty to change the header files in any manner you like but they do follow the Microchip data sheet naming conventions and I would not recomend changing names and definitions adhock. A better way to do this would be to make use of the fact that C is case sensitive and use the following code;

#define cout cmcon0.COUT
..........
LED = cout;

Share this post


Link to post
Share on other sites

It's a rather odd way of doing things.

 

cmcon0.6 is faster to type

 

I ended out commenting out COUT and similar in the 12f683.h file and doing the defines in my code as follows

 

#define COUT cmcon0.6

#define CM0. cmcon.0

 

etc

 

 

 

Yes

 

Its shorter to type.

But I'de rather have a good readability than a shorter text.

 

Using the bit number's would put me reading the datasheet much more times, so wasting the time saved in typing x10 or x20, in a medium size program.

 

BTW if you are going to make changes to the standard include files, probably you should consider saving a copy of the changed ones in a separate location.

They can end up overwriten during an update, and you will lose your changes thus compromising all already finished and tested code.

 

 

Best regards

 

Jorge

Edited by JorgeF

Share this post


Link to post
Share on other sites

BTW if you are going to make changes to the standard include files, probably you should consider saving a copy of the changed ones in a separate location.

They can end up overwriten during an update, and you will lose your changes thus compromising all already finished and tested code.

 

thanks for the heads up - easily overlooked :blink:

 

I'm just commenting out the original lines in the include file and all my own c source has the defines I need in it on this project so all would not be in vain. :ph34r:

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×