Jump to content

crash_n_burn

EstablishedMember
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral

About crash_n_burn

  • Rank
    Regular
  • Birthday 06/14/1971

Profile Information

  • Gender
    Male
  • 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 bigger and bigger and someday it will hit the user data. Is there a way to tell Boost C not to put any code there ? Something like #pragma reserve this memory area from there to there. I tried to manually move big function with something like : void mybigfunc ( void ) @ 0x140000 { ... } but boost C does not take it. Any suggestions ? Thank you all.
  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, I have done a search in the forum with the string "external memory". Anybody got hints on this ? I don't want to buy another compiler, BoostC works very well for me. Thank you.
  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 compiled and linked fine. If there is something wrong with my new code i'm supposed to get an error during compile and/or linking right ? I also un-installed Sourceboost and replaced it with a fresh install. I tough boostc might been corrupted. The 18F8720 PIC has 128K code memory but i'm stuck. Can't add more code ! Help !
  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 compile some of the functions as libraries and it worked. BoostC generated a .LIB file but i don't know what to do with it next. I'm not asking for a complete explanation on this forum. I know it's a lot to ask for. But does anybody know a web page of a book that would have some sort of tutorial on the subject ? Or maybe some simple code examples to show how it's done ? Thanks.
  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 0x0000002D; bytes:1 eewrite_00000_1_ll EQU 0x0000002D; bytes:2 CompTempVar43 EQU 0x0000002D; bytes:1 printbmp_00000_1_lx EQU 0x0000002D; bytes:1 box_00000_arg_layer EQU 0x0000002D; bytes:1 showpar_00000_arg_x EQU 0x0000002D; bytes:2 showprice_00000_arg_x EQU 0x0000002D; bytes:2 showtemp_00000_arg_pol EQU 0x0000002D; bytes:1 infusion_00000_1_tingcafe EQU 0x0000002D; bytes:2 CompTempVar264 EQU 0x0000002D; bytes:1 Variable "ll" in fonction eewrite is using it. Variable "lx" in fonction printbmp is using it. Variable "layer" in fonction box is using it. and so on. I compared with a .ASM file from a older program compiled with C2C and every variable is using it's own memory location. I think it's much better like this. I got rid of my bugs by manualy put RAM arrays farther away in memory. My program is running fine, but still many variables are sharing the same RAM location. I'm afraid the prog will crash when i had some more code because of all this RAM sharing. Is the compilator doing things correcly ? Thank you.
  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 bytes (19.4%), free:52883 bytes (80.6%) It's not even near my calculations. Am I missing something ? Also, the device has a program memory space of 131072 bytes ( adresses from 0 to 0x1FFFF ). Should we read 131072 bytes available instead of 65536 ? I know this CPU is using two bytes for each instruction but each adress is pointing to a byte not a word. I can provide all my code and project files if you want to check the memory usage. Thank you.
×
×
  • Create New...