Jump to content

link87

EstablishedMember
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About link87

  • Rank
    Newbrie
  1. I'm having a couple of issues with creating a static variable that points to a string/array in a function. Initially I was creating and using the variable data like this: static uint8 receive_bit(bool wait_for_start) { static const char *data = "abc123"; static uint8 bit_index = 0; uint8 byte; switch(bit_index) { case 0: ++bit_index; return 1; default: byte = (*data >> (8 - bit_index)) & 0x01; ++bit_index; return byte; case 9: ++data; bit_index = 0; return 0; } } This snippet of code is from a much larger source file. The problem with this particula
  2. I found some document written about GNU gcc that says the same thing about C99. So my preference would really be an error for this, but if it can be made to work in some defined way that is good too. As it stands now, I don't believe the variable is ever getting initialized and was only working for a while because of the implicit memory clear when the simulation starts.
  3. Not really. After reset all variables become uninitialised what means that they can be of any values. Than start up code initialises globals and by the time 'main' starts all global variables that are initialised within their declaration are initialised. However because 'count' in your code is local to 'func_a' it won't get initialised till 'func_a' is called. Regards, Pavel But that is not happening. When I was checking the value of that variable, it was inside the function. The effect of running that snippet of code I posted is that the variable will immediately increment to the
  4. After spending some time trying to figure out why function-static variables were not being reinitialized on a processor reset, I realized that the function they were in was inline. That may be a bit dubious in nature, but it seems like this should really either be supported correctly (whatever that means) or a warning/error is generated. I don't know what the standard says about this issue. In fact I think only C99 has an inline keyword anyway. Here is sample code of what I'm talking about though: #include <system.h> //Set clock frequency #pragma CLOCK_FREQ 4000000 inline void fu
  5. I've noticed the compiler seems to generate an error with constant expressions involving #defines that evaluate to 0. The following code compiles fine: #define ADC_SHIFT 0 sample >>= ADC_SHIFT; This code produces an error: #define ADC_SHIFT 1 sample >>= (ADC_SHIFT - 1); Errors produced: This code also produces the same error: #define ADC_SHIFT 1 - 1 sample >>= ADC_SHIFT; This is with BoostC 6.91 running with -O2 targetted for the PIC18F1320.
  6. I am experimenting with the inline assembly feature of the BoostC compiler. I would like to work with certain registers, but I don't know if I need to save their values or not. I know I could do it to be safe, but some of these are very time critical and I don't want to save unnecessarily. Is there a guide somewhere about what registers BoostC uses for internal purposes or provides guidelines for which registers can be safely modified without saving? In particular I'd like to deal with FSR registers. I know some PIC compilers use these for software stacks and occasionally loop or other rap
  7. Ahh, when I looked at the program memory view instead of the disassembled view, I see what you mean about the addresses. Sorry about that--still getting used to using a C compiler on the PIC. I will check out the Boost IDE and see if that helps any too.
  8. I have produces a very simple for-loop below that shows this problem. I have tried running this in -O0, -O1, and -O2 and all produce the same general problem. The code for the body of the for-loop is appearing outside of the actual "loop" section in the assembled code. Here is the example for-loop: unsigned char i; for(i = 0; i < 10; ++i) { unsigned char a; a = i + 1; } And here is the output with -O1: 144: unsigned char i; 145: for(i = 0; i < 10; ++i) { 0048 6A56 CLRF 0x56, ACCESS 004A 0E0A
×
×
  • Create New...