Hi-Tech PICC weirdness

[futz]

futz, what happens if you add an endless loop after the existing one? I think that the original program was not properly terminated for Hi-Tech PICC compiler.

I know it was falling thru and restarting. That shouldn't prevent the array from being initialized, should it? I only ran it in the sim, so it basically got single stepped only.

And in my other programs, which were properly terminated, the same problem happened.

 

[August Treubig]

nop()

For nop it is a builtin function:

nop();
nop();

For asm

asm {
put you asm stuff
}

Time to download and peruse the FM.

 

[eng1]

I know it was falling thru and restarting. That shouldn't prevent the array from being initialized, should it? I only ran it in the sim, so it basically got single stepped only.

And in my other programs, which were properly terminated, the same problem happened.

I ran the program in MPLAB sim and I could see the correct sequence (4,5,8,9,8,1) at location 0x22. Then the program exits the while loop as expected. As you know, the following endless loop is important in order to avoid weird results.

 

[August Treubig]

C18

I agree with Bill about the USB and Ethernet stacks. It is much better to stick with C18. Way too much code to port/hack up to move to another compiler

What I meant about Libraries is that BoostC comes with some include files and samples that do things like: RS232, OneWire, I2C, LCD that are just included. They also have an RTOS that you can use for free if you can use their pre-compiled versions of the libraries. Very light and works well. And if you need more than what the pre-compled ones do, it costs a whole 30 dollars for the non-commercial version.

 

[futz]

For nop it is a builtin function:

nop();

Oh! Cool!

Time to download and peruse the FM.

Ya, I have it open here. Just starting to go thru it. I was trying to skip ahead by pickin you guys brains.

 

[futz]

I ran the program in MPLAB sim and I could see the correct sequence (4,5,8,9,8,1) at location 0x22. Then the program exits the while loop as expected. As you know, the following endless loop is important in order to avoid weird results.

I put the endless loop in, recompiled and stepped thru it. The array is still all zeros, or whatever leftover junk was in RAM there.

 

[eng1]

It looks ok here

 

[futz]

It looks ok here

Isn't that odd!

 

[August Treubig]

Versions Please?

Ok what version of it is each of you running.

Mine was the Lite 9.60....

 

[eng1]

Ok what version of it is each of you running.

Mine was the Lite 9.60....

On this machine I have PICC Lite v9.60 + MPLAB 8.00.

BTW, have you tried running a simultation? Which values do you get?

 

[futz]

On this machine I have PICC Lite v9.60 + MPLAB 8.00

PICC Lite v9.60 + MPLAB 8.02.00.00

 

[August Treubig]

??

Ok, we all have the same version of the compiler, but Futz and I are on the later MPLAB.

 

[futz]

How do I make my F10 build key work again?

I'm not sure, I usually just click. :red face

Have to use CTRL - F10. I can live with that.

Had some confusion with the way BoostC accesses bits, but I have it all figured out now. Those were 99% of my initial errors.

The rest were caused by BoostC's very strange requirement that stuff like PORTC and TRISA and such are required to be in lower case. I'm tempted to change the include. I love lower case for everything else, but I like my SFR's names to match what's in the datasheet and in assembler code. Upper case helps them stand out in the code too.

 

[August Treubig]

Bits different ways

Well there are two ways to play with the bits.

clear_bit( t1con, T1CKPS1 ); //prescaler rate 1:1
clear_bit( t1con, T1CKPS0 );

or
t1con.T1CKPS1 = 0;
t1con.T1CKPS1 = 0;

The fuses are different also.

#pragma DATA _CONFIG, _CP_OFF & _LVP_OFF & _BODEN_OFF & _MCLRE_ON & _PWRTE_ON & _WDT_OFF & _INTOSC_OSC_NOCLKOUT

Bit it works like a top and generates clean code. Look at the .asm file.

ONE TRICK. To use the debugger you HAVE to have an:

void interrupt(void) {
}

even if their is nothing in it. Will DRIVE you NUTS and won't work without it.

Of course, if you already had an interrupt procedure with some code in it, then there is no problem.

For an 18Fwhaterver, it sort of will look something like this:

#pragma DATA _CONFIG1H, _OSC_INTIO7_1H & _FCMEN_OFF_1H
#pragma DATA _CONFIG2L, _PWRT_ON_2L & _BOREN_OFF_2L
#pragma DATA _CONFIG2H, _WDT_OFF_2H & _WDTPS_32768_2H
#pragma DATA _CONFIG3H, _MCLRE_ON_3H & _PBADEN_OFF_3H
#pragma DATA _CONFIG4L, _DEBUG_OFF_4L & _LVP_OFF_4L & _STVREN_ON_4L & _XINST_OFF_4L

#pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L
#pragma DATA _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
#pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L
#pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
#pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L
#pragma DATA _CONFIG7H, _EBTRB_OFF_7H

All you have to do is look in the include files for the correct target.

Oh and really you should put:

#include <system.h>

rather than the specific chip. That way when you change horses, that part is done.

 

[futz]

Well there are two ways to play with the bits.

clear_bit( t1con, T1CKPS1 ); //prescaler rate 1:1
clear_bit( t1con, T1CKPS0 );

or
t1con.T1CKPS1 = 0;
t1con.T1CKPS1 = 0;

Or even better, the one I'm using:

[COLOR="Red"]portc.0 = 1;[/COLOR]
or, in the .h file
[COLOR="Red"]#define RW		portc.1[/COLOR]
and
[COLOR="Red"]RW = 1;[/COLOR]

The fuses are different also.

Got those figured out, no problem.

ONE TRICK. To use the debugger you HAVE to have an:

void interrupt(void) {
}

even if their is nothing in it. Will DRIVE you NUTS and won't work without it.

Thanks August. That will save me a BUNCH of time, I'm sure!

Oh and really you should put:

#include <system.h>

rather than the specific chip.

Found that one right away.

 

[August Treubig]

Here's another to look at

volatile bit led1@PORTB.3;
volatile bit led2@PORTB.2;
volatile bit led3@PORTB.1;
volatile bit xmit@PORTB.7;
volatile bit key@PORTB.6;

 

[futz]

The volatile type specifier should be used with variables that:
a) Can be changed outside the normal program flow, and
b) Should not receive intermediate values within expressions.

For example, if a bit variable is mapped to a port pin, it is a good programming
practice to declare such variable as volatile.

Code generated for expressions with volatile variables is a little longer when compared to 'regular' code:

volatile bit pinB1@0x6.1; //declare bit variable mapped to pin 1, port B

Currently compiler generates different code only for expressions that assign values to volatile bit variables. Also volatile variables are not checked for being initialized.

I've read it three times but I'm still not clear on what it means.

 

[eng1]

PICC Lite v9.60 + MPLAB 8.02.00.00

If you have installed HI-TIDE, you can use its debugger and see what happens. Again, I got correct results here.

 

[futz]

If you have installed HI-TIDE, you can use its debugger and see what happens. Again, I got correct results here.

Thanks eng1, but I no longer care about PICC. Screw it. It's stupidly expensive anyway. I was never going to be able to buy the full version. The only way I could go to full version would have been piracy, not that that's a bad thing. I never use support lines anyway. Never have, never will.

I have switched to BoostC, which I can afford to buy a license for, and so far it's pretty good. In fact, for the price they're asking, it's excellent!

EDIT: Just ran that test program in BoostC and it works perfect.

 

[August Treubig]

Thanks for the pointer

Futz,

Thanks for the link about the inexpensive AGM1264F's. Two of them arrived today. Got 2 for the price I was going to eventually pay for one. Currently setting up to marry it to the Unicorn.



Now go look at BoostC's RS232 includes and the LCD include stuff. Eventually I will show some of the RTOS stuff. Simple to do lots of things that you used to stand on head to do.