HI-TECH PICC Quirks...

[bsodmike]

Hi,

I've been working on some code in PICC and have been looking at CCS, which I must say is quite tempting. Tbh, I've spent the past few days attempting to satisfy the PICC compiler which complains about the most tedious things. For example, I had maxed out bank0 RAM space and rather than just shifting vars to bank1, 2 (etc)...it generates a greek like error (some thing _psect _rdata bank 0). Of course I found the problem, after a bit of reading up/wasting a ton of time.

The list goes on, but here's something that's really annoying. Basically I'm controlling two lines (open collector) so to pull it low, you set the output to 0, and TRIS = 0. To release, TRIS=1 (making it a high impedance input) and both lines are pulled high to Vcc via two 10K resistors.

I have defined something like this:

// Bit Address Defining command
#define BITNUM(adr, bit) ((unsigned)(&adr)*8+(bit))  	// Used for port defs

// Mouse Port Pins
static bit IN_X_DATA_PIN	@ BITNUM(PORTA,3); // RA3
static bit IN_X_DATA_TRIS	@ BITNUM(TRISA,3); //
static bit IN_X_CLOCK_PIN	@ BITNUM(PORTA,2);// RA2
static bit IN_X_CLOCK_TRIS	@ BITNUM(TRISA,2);//

Is there anyway to directly control these pins in asm (via #asm/#endasm) without doing things like bcf _PORTA,3 etc etc. More like bcf IN_X_DATA_PIN?

Another strange issue is that bcf _PORTA,3 isn't working even....very odd. Back to tinkering with this pesky compiler. CCS eats stuff like this for breakfast...it's shocking.

 

[Pommie]

I would expect bcf PORTA,3 or bcf IN_X_DATA_PIN/8,IN_X_DATA_PIN&7 to work.

When you say it doesn't work, how doesn't it work. Can you look at the complied code. If so, what is it?

Mike.

 

[bsodmike]

Hey there Pommie,

I'm adding these via #asm/#endasm, hence it needs the '_' or else it complains about PORTA. I will try bcf IN_X_DATA_PIN/8 and bcf IN_X_DATA_PIN&7 (and same for TRIS) and let you know how it goes.

Oh, I've got it on my scope and I can clearly see that the line is sitting high. I even tried changing to bank1 (bsf _STATUS,5) before clearing TRIS...no cheddar.

Atm I've accomplished (sort of) what I've set out to do with the earlier method of having the routines in pure C, but with time (as I'm working on a coms protocol) it seems the extra delays are causing it to go out of sync as it's sampling the data line too late or too early, so having the routines in asm would help but I got a few ideas as to how I can sort it out.

 

[Exo]

plain

IN_X_DATA_PIN = 1;
of 
IN_X_DATA_PIN = 0;

should work...

 

[Pommie]

Hey there Pommie,

I'm adding these via #asm/#endasm, hence it needs the '_' or else it complains about PORTA. I will try bcf IN_X_DATA_PIN/8 and bcf IN_X_DATA_PIN&7 (and same for TRIS) and let you know how it goes.

The instruction should be,

            bcf IN_X_DATA_PIN/8,IN_X_DATA_PIN&7

Mike.

 

[Oznog]

There is nothing wrong with PICC in this regard.
#define BITNUM(adr, bit) ((unsigned)(&adr)*8+(bit)) That's a plain bad coding style. I have never seen a reason to do variable ports and it's unnecessarily complex to implement in assembly. The resulting code is large and slow. IMHO CCS was dumb to drive people that way.
You just need to be doing:
#define PIN_MOUSE_DATA LATB3
PIN_MOUSE_DATA=1; //which is a single assembly instruction

I have used PICC18 extensively, found it very good, it has a few quirks but this is not one of them. CCS, on the other hand, I found to be all kinds of crappy and would never recommend it.

 

[bsodmike]

Thanks for that Oznog, I did have a feeling that was going to be terribly slow, but that's how it's done in the manual and lots of other code examples...was hoping to ditch it at some point.

Note: I've just checked, that LATAbits.LATA2 etc etc are valid Microchip C18 compiler directives, nothing to do with HI-TECH PICC?

Cheers, Mike

 

[bsodmike]

Update:

FYI, I'm using an old version of the compiler btw, v8.50PL2

1. Pommie: That works thanks, it needs #defines though, i.e.

#define IN_X_DATA_PIN _PORTA,2 etc etc

2. Exo: is that in asm?
3. Oznog, seems like you've got the compilers mixed up, I may be wrong..PICC slapped me for trying that as well.

Right now my routines such as:

while(IN_X_CLOCK_PIN); is taking TOOONS of time, that it's killing me here. What Oznog said seems to be quite true

"#define BITNUM(adr, bit) ((unsigned)(&adr)*8+(bit)) That's a plain bad coding style. I have never seen a reason to do variable ports and it's unnecessarily complex to implement in assembly. The resulting code is large and slow."

Hope someone has any bright ideas on this though

 

[Oznog]

3. Oznog, seems like you've got the compilers mixed up, I may be wrong..PICC slapped me for trying that as well.

That's PICC18. Are you talking PICC16 or PICC18? While I have not used PICC16, I doubt there is any difference in this area.

If it barked at you for "LATB2=1;", then you probably neglected to include the header file for the part.

 

[Exo]

2. Exo: is that in asm?

nevermind, i misread the question