BoostC Forum Extracts 2007

From OpenCircuits
Revision as of 20:04, 30 January 2009 by Russ hensel (talk | contribs) (→‎more)
Jump to navigation Jump to search

Almost Ready For Reading

A macro like MAKESHORT can initialize a variable but the compiler does not know that and generates a warning. Is there a way to solve this without initializing the variable explicitly? 


    u16_t timestamp;

    t1con.TMR1ON = 0; // stop timer
    MAKESHORT(timestamp, tmr1l, tmr1h);

    en_of_pulse = timestamp; <<==== causes warning

It's not the macro that's the problem, but the inline assembly it uses. The compiler doesn't notice if you set a variable with inline assembly statements and warns that it's possibly uninitialized. Declaring the variable as 'volatile' gets rid of the warning, but isn't a great solution as you might miss a true 'uninitialized' case.

I am not an expert, but I think I have seen compilers that have pragma's that give hints to compiler about these things.


Problem initializing struct. Whah, this doesn't work! 

typedef struct {
    char foo[11];
    bar_enum bar;
} baz_list;

baz_list baz[] = { "0123456789", quux,
                   "0123456789", quuux,
                   "0123456789", quuuux
                 };


I can create a two dimensional array of strings and initialize them or a array of enums and initialize them but not an array of structs.

A more premitive question to ask would be why: 

CODE
struct thing {
  char ch_1;
  char ch_2;
};
 
struct thing thingy = {2,2};

doesn't work.

I can't find the thread I'm thinking of but I believe you're going to have to assign the values yourself. I'd say use an inline function or something to make it look neater: 

struct thing {
  char ch_1;
  char ch_2;
};

inline void set_thing( struct thing &i_thing, 
                       unsigned char ch_1, 
                       unsigned char ch_2 ) {
  i_thing.ch_1 = ch_1;
  i_thing.ch_2 = ch_2;
}

void main( void ){
  struct thing i_thing[3];
  set_thing( i_thing[0], 2, 3 );
  set_thing( i_thing[1], 5, 3 );
  set_thing( i_thing[2], 1, 9 );

Found the thread - http://forum.sourceboost.com/index.php?showtopic=3404

break this into 3

    • Question 1:

Function prototypes, It looks like they are allowed, but not required nor enforced?

Prototypes are required if you do a forward reference to a function. If you are in the habit of using them, then always use them. I do.

    • Question 2:

If I call 

 delay_ms(1000 );

I get no warnings.

Is there a way to make it more strict?

If you go to Settings - Options and enable All warnings the compiler will warn you if you exceed 255 for a delay.

    • Question 3:

Interrupts; If I don't put the interrupt function in my code, is there a default handler?

There is no default interrupt handler that I can see. Keep GIE = 0 if you don't want you program to go into the woods.


    • Question 4:

Global variables vs volatile; If I declare a variable in a header file, and wish to use it in both a main thread function and an interrupt handler, do I really need to declare it volatile?

If I was sharing a variable with main and interrupt, I would probably make it volatile. It all depends on how your main code is written and how many times the variable is used in main. The compiler may retain the variable value between uses and the interrupt may change its value between uses. You could always devise a semaphore type system.



I had some code that suddenly got bigger and slower and all I'd done was change the size of an array, though no variables ended up placed anywhere but bank 0. ...

read the post for some info an location of variables in memory, bank switching ..... size and speed.


Boostc gives me the warning Caution: Delay inaccurrate: 'delay_us', Delay overhead:0.01ms, Unit delay:0.001ms

How do I interpret the overhead and unit delay....?

delay_us( 1 ) gives 0.01ms + (1 * 0.001ms) = 11us delay_us(12) gives 0.01ms + (12 * 0.001ms) = 22us delay_us(13) gives 0.01ms + (13 * 0.001ms) = 23us

delay_us(0) results in 0.01ms + (255 * 0.001ms) = 265us



notes that I am not able to summarize about structs union and access of sub-components.





Best Method For Accumulated Timer -- go read it


http://forum.sourceboost.com/index.php?showtopic=3408&pid=12790&mode=threaded&start=#entry12790

go read it

may be useful for lcd read and other ? Here is my basic template when working with the 684 chip.


It may be of some help to you...... 

 LCD_684.txt ( 4.03K ) Number of downloads: 41


more

http://forum.sourceboost.com/index.php?showtopic=3411&pid=12788&mode=threaded&start=#entry12788


hallo... how do i measure the eact timing on my code using boostc? even it have speed tester, but it dont show in time base.... and how do i measure my the time of my desired code? Interested in advertising here? Contact support@sourceboost.com



set breakpoints in the debugger at the beginning and end of the code you want to evaluate. in the debugger you can see the amount of ticks. so when you let it run from breakpoint to breakpoint you are able to see how manny ticks it took. If I don't oversee something here ( ) this should be a working method to determine the exact time it takes to run that peace of code.....



Reynard Dec 17 2007, 12:44 PM Pos


QUOTE (fred @ Dec 16 2007, 11:30 PM) set breakpoints in the debugger at the beginning and end of the code you want to evaluate. in the debugger you can see the amount of ticks. so when you let it run from breakpoint to breakpoint you are able to see how manny ticks it took. If I don't oversee something here ( ) this should be a working method to determine the exact time it takes to run that peace of code.....


A tick appears to be an oscillator cycle. If you step through a 1 cycle instruction it will increment the tick count by 4. A 4MHz xtal will give 1us instruction cycle time.

The tick count will change to values in 'kilo' after a while i.e. 10k etc. which cannot be reset to zero.

If you install BoostC within MPLab (Microchip IDE) you can use its watchdog feature measure in real time.

http://forum.sourceboost.com/index.php?showtopic=3410&pid=12768&mode=threaded&start=#entry12768

As has been pointed out, you should have i != 100 and i++. But in general, it's said to be safer to use "<" than "!=" in such a loop as it can prevent infinite loops if the "i" gets changed somewhere else in the loop.

If you KNOW that the loop is going to be executed at least once, you are better off using the following:

i = 0; do { /* loop contents */ } while ( ++i != 10 );

Or if "i" is ONLY used as a counter, the following can be better still:

i = 10; do { /* loop contents */ } while ( --i != 0 );

Both can produce shorter, faster code!

Orin.

http://forum.sourceboost.com/index.php?showtopic=3405

You can't cast rom to not-rom types or vice versa. I'd either do 2 switch constructions: one for rom and another for not-rom arrays or use a buffer where rom arrays will be copied before use.

Regards,

New to C and I may be missing it, but I think assignment it the wrong way to go, instesad use a string copy to move from rom to ram. I know this sor of thing works because I do it all the time.

Russ


http://forum.sourceboost.com/index.php?showtopic=3404&pid=12741&mode=threaded&start=#entry12741

I have a structure:

typedef struct { unsigned int A; unsigned int B; unsigned int c; } ConvertCoeff;

and I declare an array of this structure:

ConvertCoeff coeff[8];

As long as I leave it this way everything is OK. But if I try to intialize the array during decleration as follows:

ConvertCoeff coeff[3] = { {1,2,3}, {1,2,3}, {1,2,3}};

I get an error during compilation - missing semicolon.

Is it not a legitimate initialization? I know it is possible on other compilers - how do I do it in BoostC? 


As you said it appears that BoostC does not like initialising structures like other compilers.

You will have to fill your structure the hard way.


http://forum.sourceboost.com/index.php?showtopic=3403&pid=12735&mode=threaded&start=#entry12735

the linker generates a serious stack warning because I have a function which is called within the handling of a rb0 interrupt and also in the program main loop. I can imagine that this can cause problems when the function is called by the interrupt routine and within the main() loop at the same time.

But under specific conditions the rb0 interrupt handler (which contains that function call) is disabling it's interrupt and activates a flag. Depending on that flag the mentioned funtion is called in the main loop.

So that function, referred to in the warning, can never be called in the interrupt routine at the time it´s also being executed because of a call within the main loop!

This is still all tricky or it´s not a problem to ignore this warning under this conditions? If you are sure you are handling this situation correctly you can ignore this warning, your code looks like it maybe ok, but this kind of code can be tricky to understand.

http://forum.sourceboost.com/index.php?showtopic=3269&pid=12715&mode=threaded&start=#entry12715

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.


v


Is it possible for lprintf to write a substring to the lcd?

eg. I've got a string 254 bytes long, but I only want to print 16 chars to the first line of the display.

I tried lprintf("%c",buffer[i]) in a for loop, but that didn't work (no compiler error though).


Use CODE ... 

   lcd_datamode();
   char c, i;
   for( i = 0; i < 16; i++ )
   {
       c = buffer[i];
       if( c == 0 ) 
           break;
       lcd_write( c );
   }

...

Regards Dave


http://forum.sourceboost.com/index.php?showtopic=3367&pid=12653&mode=threaded&start=#entry12653

@Pavel:

That's it. Adding -d DEBUG to the compiler options does exactly what I want. Thanks very much.

Edward


stop at

Counting Optimization (decfsz) 1 Thompson 409 18th November 2007 - 07:22 PM Last post by: Pavel

Retrieved from "http://www.opencircuits.com/index.php?title=BoostC_Forum_Extracts_2007&oldid=17678"