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 particular creation of data is that the buffer that data points to, "abcdef", is getting overwritten by other parts of the program. It seems the compiler has optimized the code and laid other variables, particularly ones used for the passing of arguments to another function, over this buffer. I then changed the definition of data to this: static const char data[7] = "abc123"; And with that comes a nasty linker error: I just tried moving the definition out of the function, so that the same two variable definitions including the static specifier remain but at the global level. The pointer version compiles and does not seem to suffer from the buffer corruption issue that it did in the function. The array version still fails with the same linker error however.
  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 value 2 instead of 1 after RESET, because the value remains at 1 after entering the function. In looking at the disassembly of the inline function, the code to reset the variable is not present there. I did find the code that is supposed to clear it another address outside of the function, and could not locate any call to that address. In the case of the non-inline function, the code to reset the variable is present and works appropriately.
  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 func_a(void) { static unsigned char count = 0; ++count; } void interrupt( void ) { } void main( void ) { for(;;) { func_a(); asm { reset } } } After the reset, the value of count in func_a would still be 1. Once I made the function a regular, non-inline function, the static variable was initialized correctly on reset. I just tested this with the Boost IDE as well. It appears to work in there. I'm guessing this is because all resets force a memory clear in Boost IDE. As soon as the reset instruction was executed the memory view showed the byte was cleared.
  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 rapid indexing situations. From code I've compiled it looks like BoostC itself is generating code that uses FSR0 without saving it, but I'm also not using a software stack at the moment. I would like a solution that isn't likely to break as I expand the project, but realize that may be too much to ask Thanks
  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 MOVLW 0xa 004C 6056 CPFSLT 0x56, ACCESS 0054 2A56 INCF 0x56, F, ACCESS 0056 D7F9 BRA 0x4a 146: unsigned char a; 147: a = i + 1; 0050 2856 INCF 0x56, W, ACCESS 0052 6E57 MOVWF 0x57, ACCESS 148: } This is for the PIC18F1320 and here is the output of BoostC/BoostLink for version info and anything else of interest: Clean: Deleting intermediary and output files. Clean: Done. Executing: "C:\Program Files (x86)\SourceBoost\boostc.pic18.exe" dft.c -W2 -t 18F1320 -O1 BoostC Optimizing C Compiler Version 6.91 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2008 Pavel Baranov Copyright© 2004-2008 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC18 max code size:8192 bytes, max RAM banks:2, Non commercial use only dft.c T:\test_dft\dft.c(157): warning: conversion from 'unsigned char*' to 'void*' success Executing: "C:\Program Files (x86)\SourceBoost\boostlink.pic.exe" "T:\test_dft\dft.obj" -p "test_dft" -t 18F1320 -O1 BoostLink Optimizing Linker Version 6.91 http://www.sourceboost.com Copyright© 2004-2008 Pavel Baranov Copyright© 2004-2008 David Hobday Optimisation level:1 Warning unreferenced functions removed: dft in: T:\test_dft\dft.c Building CASM file Memory Usage Report =================== RAM available:256 bytes, used:93 bytes (36.4%), free:163 bytes (63.6%), Heap size:163 bytes, Heap max single alloc:127 bytes ROM available:8192 bytes, used:502 bytes (6.2%), free:7690 bytes (93.8%) success Loaded T:\test_dft\test_dft.COF. BUILD SUCCEEDED: Wed Feb 18 11:08:45 2009
×
×
  • Create New...