Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Dave

  1. No one still can't do it even with these defines around. The problem is that even with the defines the variable is still processed and added to the variables list of every source file that includes this header. Remember that compiler doesn't store information between compilation of different files so these defines won't help. Regards, Pavel <{POST_SNAPBACK}> The thing to do here is: header.h ============= #ifdef DECLARE_MY_VARS int myglobal; #else extern int myglobal; #endif .... main.c ============== #define DECLARE_MY_VARS #include "header.h" void main() { myglobal = 0; .... } other.c ============== #include "header.h" void foo() { myglobal++; } Hope this helps. Regards Dave
  2. teunizz, Use ccpr1 and ccpr2 instead. These refer to the same registers as ccpr1l and ccpr2l. Regards Dave
  3. fischp, This has now been fixed and will be available in the next release. Regards Dave
  4. fischp, Looks like a compiler bug Workaround for now is something like: Regards Dave
  5. Pavel, Oh yeah. I just had a look in boostc.h, as I remembered that there was some macro in there. So only the set_bit one is useful. Regards Dave
  6. Guys, #define set_bit( x, bitNo ) x |= (1 << bitNo); #define clear_bit( x, bitNo ) x &= ~(1 << bitNo); #define test_bit( x, bitNo ) x & (1 << bitNo) != 0 I have written some macros for you. They generates single instruction code when the bit Number is a constant. They should give what is missing from C2C. Regards Dave
  7. Pittuck, This also works under source boost: void main() { char uartReg@0x123; volatile bit txdone@0x123.0; volatile bit rxdone@0x123.1; volatile bit er@0x123.2; txdone = 1; // equivalent to set_bit( uartReg, 0 ); rxdone = 0; // equivalent to clear_bit( uartReg, 1 ); er = 1; // equivalent to set_bit( uartReg, 2 ); } And the results is really efficient code. Regards Dave
  8. Pittuck, Bit testing of a hardware register (like a uart) using: Is this not what you are after ? Regards Dave
  9. FrankGe, Looks like a compiler problem. It goes wrong when variables declared in a list eg: extern c, c2; // bad when external, fails to link // char c, c2; // good char c; char c2; void main() { c = 0; c2 = 0; } so the workaround is for now to declare vars invidually. Regards Dave
  10. ducster81, I guess you are talking about MSVC. It doesn't support any kind of fixed address adressing - it doesn't need to. Fixed addresses are required on PICs because this is where all the peripheral hardware control registes are at fixed addresses. Nearest things is this: char c; char* addr = &c; Hope this helps. Regards Dave
  11. Martyn, I don't feel I understand how what you are saying works. Please have a look here at the bootloader for BoostC compiler by Ryan Davis, maybe you will see something here that helps. Regards Dave
  12. Hollie, This was a bug in the BoostC compiler and is now fixed in V1.9.2 Only one source file needs to specify the clock frequency. More than one source file can specify the clock frequency, but they must then all match, otherwise its an error. Regards Dave
  13. pittuck, Works for me, you need Sourceboost V1.9 or greater, if you used V1.8 you can only specify the offset in decimal, and an org 0x0000 is still added at the beginning. Regards Dave
  14. Hollie, Yes this functionality changed between BoostC V1.8 and V1.9 What is meant to happen is this: If no clock frequcency is specified in source file, then compiler should put no clock frequency in .obj file. If two .obj files contain different clock frequcency settings, then this is any error, because linker has no idea which to use. This all looks like it is working correctly with compiler V1.9.1 Regards Dave
  15. pittuck, Use the linker option -rb 0x0004 (Rom Bottom). This sets the lowest address linker will use for code placement. Regards Dave
  16. Joe, Its always good to keep the amount of work being done in an interrupt routine to a minimum, so it sound like you have the best solution. Regards Dave
  17. Joe, An external clock can be fed into the T0CLKI input. The only clock sources that can be fed into this input is through plugins, eg buttons, voltage source or signal generator. Signal generator has a max frequency of 20kHz, so you won't get the frequency you are after. Also simulator doesn't support the sleep instruction, so it will never need waking up. Regards Dave
  18. FrankGe, I would recommend code the function this way: void send(rom char* s) { char c; char i = 0; while ( c = s[ i ] ) { send(c); i++; } } This only computes and use once the index value, making the code length much shorted. Regards Dave
  19. Joe, This error is created during the creation of the coff (debug info) file. It is non fatal, ie the code can is correctly created even though the error is reported. Maybe the message should be a warning rather than an error. Also coff file should be able to handle this type. so the error should not be reported in the first place. This should get fixed when the other coff is made compatible with MPLABS. Regards Dave
  20. Joe, This is not a bug, but a know limitation. The PIC12s with 14Bit instruction cores do not have peripheral device simulation in the simulator Support for PIC12 with 14Bit instruction cores was only recently added to BoostC compiler. No doubt it will get added in the future. Regards Dave
  21. Joe, Modulus (%) is not coded inline by compiler, it calls a function to do this work. The problem with calling a function is multiple threads has been explained fully before here. Now the only way for linker to handle this would be to make a copy of each function for each thread of execution. Linker can't currently do this. The answer (for now) is to write a separate function to do the math, and call this from only one thread. I know its not so nice, but it will get around the problem. Regards Dave
  22. ppulle, If I was using the BoostC compiler to do what you want, I would where the linker puts the bottom of its code using the -rb linker option. This way you move everything up leaving you to fill in the blanks regarding reset and interrupt vector. You have total freedom in this area The only downside to this is that to put code in this area you will need to manually put in the opcodes using the #pragma DATA directive This will be OK if you only have a tiny amount of code todo. You can aways jump to the interrupt handler function once you have done you highspeed stuff. You will need to add code to patch the reset through to the normal reset code. You will know where this is because it will all be shifted by the amount you specify in -rb option. To see this kind of thing being done have a look at the BoostC bootloader by Ryan Davis http://www.picant.com/c2c/examples.html Hope this helps. Regards Dave
  23. Joe, This limitation is due to be fixed, at the same time as we make coff output compatible with MPLABs. Regards Dave
  24. Joe, This is a problem that has been reported before - I can't seem to find the original post though. Because we currently use a coff file format compatible with HiTech PIC C, we have a problem, files name less than 5 characters don't work inside the coff (debug file) generated. Regards Dave
  25. Joe, Linker builds all the delay routines first, then it processes the call tree. If the functions are not used then they are orphan functions, so they are removed. So this is why you get the message even though they are not used. Regards Dave
  • Create New...