Boostc Compiler Suggestions Options

[Ian Harris]

Hi All,

Just a few notes on suggestions for updates to the BoostC compiler after investing in the pro version and having a good couple of months play with it.

For the most part, I'm very happy with the BoostC compiler.

- Being able to specify where a chunk of code starts, eg, before the subroutine, would be very handy to locate different parts of the code in different locations. You can get around this with the DATA pragma, but it means hand-coding assembler, turning it into hex, and then putting it in code. Not nice. This would make bootloaders, etc much easier. CC5X uses the pragma origin to do this. Also means that same project could be used to build for different chips, since you wouldn't need to go change the -rb command line option

- delay_ms seems to run very fast - despite having pragma CLOCK_FREQ set correctly, when run on an actuall device it's running at least 4? times fast. delay_ms(1000) does not delay for a second.

- Call tree and Function info are one of the best things about BoostC - being able to have all this information to optimise is just fantastic. One thing that would be handy is some more information about the #GLOBAL section - you can see the total, but where did it come from? A file by file break down would be very helpful here, especially with complex projects

Many thanks for a great tool,

kind regards
Ian.

[Paolino]

Hi All,

Just a few notes on suggestions for updates to the BoostC compiler after investing in the pro version and having a good couple of months play with it.
...
- delay_ms seems to run very fast - despite having pragma CLOCK_FREQ set correctly, when run on an actuall device it's running at least 4? times fast. delay_ms(1000) does not delay for a second.

Ian, I think that the problem you encountered with delay_ms() is due to an overflow. Infact, the manual says:

void delay_ms( unsigned char t )
(generated function) Delays execution for 't' milli seconds. Declared in boostc.h
This function gets generated every time a project is linked and is controlled by the CLOCK_FREQ pragma.

delay_ms() accepts an 8-bit parameter. So, if you put 1000 (0x3E8), the compiler cut it at 0xE8, not too far from 0xFF...

Try

CODE

delay_s(1);

or

CODE

delay_ms(250);
delay_ms(250);
delay_ms(250);
delay_ms(250);

Regards.

Paolo.

[PICcoder]

Hi All,

Just a few notes on suggestions for updates to the BoostC compiler after investing in the pro version and having a good couple of months play with it.
...
- delay_ms seems to run very fast - despite having pragma CLOCK_FREQ set correctly, when run on an actuall device it's running at least 4? times fast. delay_ms(1000) does not delay for a second.

Ian, I think that the problem you encountered with delay_ms() is due to an overflow. Infact, the manual says:

void delay_ms( unsigned char t )
(generated function) Delays execution for 't' milli seconds. Declared in boostc.h
This function gets generated every time a project is linked and is controlled by the CLOCK_FREQ pragma.

delay_ms() accepts an 8-bit parameter. So, if you put 1000 (0x3E8), the compiler cut it at 0xE8, not too far from 0xFF...

Try

CODE

delay_s(1);

or

CODE

delay_ms(250);
delay_ms(250);
delay_ms(250);
delay_ms(250);

Regards.

Paolo.

Yes, this one bit me too! I wrote the following routine that you can use for any ms value from 1 to 65535. I timed it at 60,000 and it seems to be pretty much on the money.

void delayMs(unsigned int ms){
char i;
char high = ms >> 8;
char low = ms & 0x00ff;
for(i = 0; i < high; i++){
delay_ms(255);
}
delay_ms(low);
}

You might think that it needs another delay_ms(1) in the loop but I got the most accurate time without it.