Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. pittuck, Not a bug!!!! You are now enjoying one of the great things about 'C', you don't have the overhead of bounds checking on arrays unless you add it yourself. Your code will compile under any 'C'-compiler without an error. And now for the "dumb" question (remember that once we where all beginners) char array1[ 3 ]; // uses 3 bytes, valid indexes 0 to 2 char array2[ 4 ]; // uses 4 bytes, valid indexes 0 to 3 Regards Dave
  2. Andrew, I forgot to supply this link that gives more information about BoostC. Regards Dave
  3. Dave

    Compiler Error

    jevdsnny, I'm just interested how do you know that your code is failing on the actual target ? Presumeably you add some code to read the EEPROM back and show the result to the outside world. If this is the case, then that dramtically affects you program. If you have two projects one that demonstrates the problem, and one that doesn't then please send them to support@picant.com, and I will investigate futher. It maybe that your pick has a bad memory location, when the code is changed, it changes which locations are used for what. This may then use the bad memory location for data that doesn't matter so the code succeeds. The simulator is very well trusted, although timing with respect to EEPROM writes made be better than the actual hardware, ie the simulator operates like a more ideal device. Regards Dave
  4. Andrew, Oops, I thought I had mentioned that. BoostC does support structures and unions. Soon it will also integrate into MPLABs (this work is done, soon it should be released) so you can used ICD2 and any other MPLABs facilities and debug at source code level. Regards Dave
  5. andrew, The current c-compiler you can buy is the C2C-plus compiler it doesn't support structures or unions. It support PIC12, PIC16 and Ubicon SX devices. You could also consider using the c++ compiler, it supports structures and unions. It support PIC12, PIC16 and Ubicon SX devices. Soon the C2C-plus compiler will be superceeded by the BoostC c-compiler. The BoostC c-compiler is currently in beta test, with very few bugs now being reported. BoostC supports PIC12 (only those that have 14bit instruction cores), PIC16 and PIC18. The BoostC beta compiler can be downloaded and used for free, so why not give it a try. Regards Dave
  6. neilbuck, looks like a bug, even code with no macros fails: void main() { char res = 0; char myByte; myByte = 1; if ( (myByte & 1) && (myByte & 2) ) { res |= 4; } // res should be 0 here while( 1 ); } Regards Dave
  7. pbraju123, This message is created when the debugger doesn't know which source line is associated with a give value of the program counter (PC) register. Nothing is missing from the code, but from the debug information. Currently there are some circumstances when this can happen, these should all be fixed in the next release - mainly todo with global variable initialisation code. The work around is set a break in the function and run the code to that point, or try just keep stepping the code, it shouldn't take too long before you see source code high lighted in the source window. Regards Dave
  8. Alex, To set configuration bits with the BoostC compiler, you need to used: #pragma data _config, 0x3194 Regards Dave
  9. ppulle, Linker now changed so that -h, /h, -?, /? shows the help screen. Will be in the next release Regards Dave
  10. Pavel, For PIC18 -rb 0x100 in this case code must jump to 0x100 to follow the code reset execution path, code must jump to 0x108 to follow the interrupt execution path. code must jump to 0x118 to follow the low priority interrupt execution path. In all cases the whole memory image is offset by the value specified in -rb command linker option, of course all code page crossing is correctly adjusted to Note: low priority interrupt not yet implement for PIC18. Regards Dave
  11. Pavel, When linker option -rb is used, it offsets the whole of the code. The entry point and interrupt jump are located as they are normally, but offset by the value specified the -rb option. Example for a PIC16 device, -rb 0x100 in this case code must jump to 0x100 to follow the code reset execution path, code must jump to 0x104 to follow the interrupt execution path. Hope thats clear ? Regards Dave
  12. pittuck, Please provide a short code, but complete, code example that demonstrates the problem. Regards Dave
  13. Dan, Yes that will be a very good exercise. I look forward to seeing the result. Regards Dave
  14. asheleges, The whole of the code can be shifted in memory by using the -rb 0x1234 (rom bottom) linker command line option. How this is used with a bootloader is demonstrated here: Examples Hope this helps. Regards Dave
  15. Dan, I have one two, but have coded nothing for it yet - maybe you will be the one to come up with some samples. Doing this would get you a discount on the final release BoostC. BoostC doesn't integrate well into MPLABs yet, but should in the next release - I currently work on this. Source code stepping with ICD2 should then be working BoostC currently only exists as an beta release, you can't buy it even if you want to. The beta release has no restrictions other than it will eventually expire. When the release version of BoostC comes along, there will be a free version. It will have limitations on the amount of RAM and ROM that can be used. Regards Dave
  16. Lanste, Which sourceboost version are you using ? Regards Dave
  17. Richard, The PIC16F676 is well supported by the simulator. Regards Dave
  18. Alexandre, Thats the plan, but 32bit maths has yet to be implemented. Regards Dave
  19. A note from Dave: These are both 12F508 and 10F20x are both devices with a 12bit instruction core.
  20. Rando, Source debug with MPLABs is not currently possible This is something I am currently working on, so all being well it should be the next release Regards Dave
  21. gilly, The primary function of clearing the status register here is to cause memory bank 0 to be selected. It could be done with: bcf STATUS, RP0 bcf STATUS, RP1 But this uses one more instruction - using clr STATUS is therefore more efficient. As a side affect of using clr status, all other status flags also get cleared. The only thing I could see that could go wrong is that bank is not correctly set when come variables are referenced in the interrupt routine, by adding the clr STATUS you are fixing this problem. The problem may only occur occassionally because is only a problem if the main execution thread sets the bank to a bank other than 0 and then an interrupt occurs Please send a project demonstrating the problem to support@picant.com Regards Dave PS: This link doesn't seem to refer to the correct document:
  22. asheleges, Use the linker option -rb 0x200. This offsets all the code leave address 0x000 to 0x1FF for your bootloader. Regards Dave
  23. Daniel, BoostC and C2C are compilers. They turn your source code into a program that can be run on the target device. The plugins work with the debugger/simulator, they don't care about what has produced the code. So it doesn't matter what compiler is used the simulator should work the same. Regards Dave
  24. Booster, Nice spot. This error is not a function of LCD, but of the simulation of 16F628. Thanks Regards Dave
  25. In the header files defines are in upper case and vars at a specific address are in lower case. TRISA appears in the header file as #define TRISA 0x0085 this means TRISA = 0x0000; actually turns into 0x0085 = 0x0000; Where TRISA is used the number 0x0085 is substituted. trisa appears in the header file as volatile char trisa @ TRISA; trisa = 0x0000; actually changes the value at address 0x0085 So change you code to: set_bit(status, 5); trisa = 0x0000; clear_bit(status, 5); Hope this helps Regards Dave
×
×
  • Create New...