Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About crash_n_burn

  • Rank
  • Birthday 06/14/1971

Profile Information

  • Gender
  • Location
    Quebec, Canada
  • Interests
    Electronics, electronics, electronics and running.
  1. Okay. I'll put the linker option. At least I'll know if things get too big. Thank you for your reply.
  2. In one of my programs there is user data in flash memory ( code memory ). It's near the middle of the memory map. For my example here, I will say it's at location 0x12000 to 0x13000. I'm using a PIC18F6720. Don't ask me why I did this. I know it's not how it should be done, but now I have to keep it this way so my customer can upgrade the software without losing the user data. We are using a ICD-U40 programmer from CCS with the "no erase" function to upgrade the systems with new software. This way, the code is replaced and the user data is not erased. The code is getting bigg
  3. Yes it does. Will take a look at the file and give it a try. Thanks Dave.
  4. I designed a system with a PIC18F6720. The program memory is full at 128K. My customer still want to add features and stuff. I'm thinking about designing a new system with a PIC18F8720 with external 2Mb memory so I can have some room to work. I could take my 6720 code modif it and move it to the 8720 without starting from scratch. Do I have to specify to BoostC that I'm using external memory ? I know I have to set the fuses correctly in the PIC but am I going to have an error message in BoostC when the internal prog memory is full ? I know some people are using this configuration,
  5. I'm writing code for a 18F8720. Not too long ago my code was using memory space from 0x00000 to 0x0C030 ( 48K ). Then I wrote some more lines. The compilator seems to work ok with no errors but the linker does something strange. No errors messages and then the "Successful" and "Done" but no memory usage report... In my work directory the .HEX file is empty. Other files produced by the linker are also empty. There is also massive hard-disk acces while linking. The HD wasn't doing this before. I tried to remove some old lines of code to leave space for the new ones and it
  6. Hello hvn0005, I looked in the help file and could not find the function. Maybe this will do the job : // Input must be from 00 to 99 in BCD // Output in decimal unsigned char bcd_to_char ( unsigned char bcdval) { unsigned char bcd_hi; bcd_hi = bcdval & 0xF0; // Isolate MSB 7-6-5-4 bcd_hi>>=4; return (bcd_hi*10)+(bcdval & 0x0F); } Is this what you want ?
  7. I thought i would save time in the linking process. I'm a little disappointed. The compile time is not soo bad. The linking is very long. I guess i'll start shopping for a replacement for my 1.6Ghz CPU. Still, i'm going to follow your instructions to link the libraries to the project. Thank you for the support. Yves Belzile AKA Crash n burn
  8. Hello all, During the last weeks, or should i say months, I've been working on writing code for an application. This thing is bigger and bigger everyday. It's takes a hell of a time to compile and link this monster. Most of my functions don't change and I should not need to compile them all the time. I know it is possible to compile some functions to build "libraries" and then link to my code. This way i would surely save a lot of time. But i have never done that. I don't know how to do it. I know there is an option you can check in BoostC to build libraries. I tried to compil
  9. Dave, thanks a lot for the explanation of the call tree. Now i know it's purpose ! I'm learning while debugging. This rings a bell. You might be right. I'll double check my code for any overrun issues. I'm gonna trust the call tree analysis since it's been used for some time. Thanks for the lightning-fast answer. Crash
  10. I am using Boost C V1.9.2 with IDE V5.9.1. Im writing code for a PIC 18F6720. The program is getting bigger everyday and lately I saw a strange beavior of the code. For some reason, some functions don't input the right value in the parameters... In my search for bugs, I looked at the .ASM file produced by the compiler. I was suprised to see many variables using the same RAM adress. For example, RAM location 0x2D is used many times. Here are some sample lines for my .ASM file : CompTempVar32 EQU 0x0000002D; bytes:1 CompTempVar34 EQU
  11. I'm using V1.8 Also. I don't know what is going on with my program... Anyway, I wrote my program a different way to get rid of the GOTO. When I have more time, I'll investigate further to find out what is going on. Thanks for your reply Dave.
  12. I am unable to get the GOTO instruction to work in BoostC. I always get "label lookup error" It's not recommended to use the GOTO instruction but I use it to get out of a nested loop. I am carefully paying attention to the syntax but the compiler is unable to find the label. ... goto progm; ... progm: ... I tried in assembly and it does not work all the time : asm { start: btfsc _i, 4 goto start ... } Depending on where the assembly code is in my prog, sometime it's ok, sometime it's not.
  13. The files are in the mail. This 64k limit could explain why i'm having other problems when I try to put too much data in the code memory space. In my example i have 3.5K of data. When I hit 6k of data or more the compiler sends me messages like : "error, missing right paren". I know this message is wrong because the compiler did it's job correcly a minute before with just less data in the memory space. But why do you mention MPLAB ? I dont' use it. I'm using BoostC in the SourceBoost IDE. Thank you for looking into this matter.
  14. I modified the location of the data in my project. I placed the data after the code : Code from 0x0FC9A to 0x0FFFF (870 bytes) Data from 0x11000 to 0x11015 (22 bytes) Data from 0x12000 to 0x12E07 (3592 bytes) Still 4484 bytes total. And got a different memory usage report : Memory Useage Report ==================== RAM available:3840 bytes, used:20 bytes (0.6%), free:3820 bytes (99.4%) ROM available:65536 bytes, used:909 bytes (1.4%), free:64627 bytes (98.6%) ?
  15. Im using BoostC V5.6.1 with update 1.3 Alpha. The target device is a PIC 18F8720. I looked in the .LST file to see the memory usage (ROM) of my project. I have the following : Data from adresses 0x1000 to 0x1015 ( 22 bytes ) Data from adresses 0x2000 to 0x2E07 ( 3592 bytes ) Code from adresses 0xFC9A to 0xFFFF ( 870 bytes ) 4484 bytes total if my calculations are ok. The memory useage report shows this : Memory Useage Report ==================== RAM available:3840 bytes, used:20 bytes (0.6%), free:3820 bytes (99.4%) ROM available:65536 bytes, used:12653 byte
  • Create New...