Jump to content

DTPIC

EstablishedMember
  • Content Count

    33
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DTPIC

  • Rank
    Regular

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, since using BoostC 8.01 I have come across the message "Can't fit avoid code boundary code....". I have followed a couple of (Novo RTOS) posts about this (or similar) message and it seems that this incarnation of the compiler now builds a table (of return addresses?)for each call of a function. Because the table is only 256 entries long it effectively limits the number of times the function can be called (to 256). Is my understanding correct so far? 256 calls may seem to be "a number unlikely to be exceeded" - but in my code and on bigger processors I use a lot of serial
  2. Hi Reynard, I am using PIC18F (45K22). I cant really send you full source code, as these are commercial designs and "the customer's property". But here are some snippets: This is the code as I have followed it; I know I'm not infallible, and I did try to say "if I'm right" ...(!) see what you think of my understanding: Looking in the asm output, a RAM byte is assigned for the array called "sw_id": gbl_sw_id EQU 0x000002FC ; bytes:1 // why!?!?! Then the _startup code does this: _startup MOVLW 0x00
  3. I recently had a problem with arrays held in RAM being corrupted, so I thought i would move them to ROM using rom char *. I found that it was still possible to corrupt the array output! Here's what i think happened... It looks like the compiler assigns a 256 byte ROM area to every rom char array, regardless of actual size. It then assigns a "rom char array number" (1,2,3, etc) to each array for identification: THEN IT STORES THAT NUMBER IN RAM! Consequently, if the area of RAM holding the rom char array number is corrupted, then the rom array output is also corrupted (because you a
  4. Only other things I can tell you: 1) I use the "#if 1.... #endif" and "#if 0.... #endif" constructs to include\"comment out" sections of experimental code... 2) I have used nested #ifs \ #ifdefs sometimes to 3 or more levels... 3) there may be #if\#ifdef\#endifs existing inside /*...*/ commented out code, or #if \ ifdef \ #endifs commented out using //.... Hope this helps...
  5. Hi Pavel, I would love to be able to help debug Chameleon, but this code is commercial and I would have to get the customer's permission to send it out to a third party; I don't think they would want to, but I will ask....
  6. I have taken a BoostC project which compiles fine and tried to compile using Chameleon - did a "clean all" then "build" - got the response "failed to index input file", with no extra information about the problem... What does this message mean? What do I need to look for to fix it? Is there a (pdf?) help guide anywhere for Chameleon, or extra info which which would help to debug?
  7. I have a routine like: EEPROMwrite(unsigned char addr, unsigned char* str, unsigned char len) { // print out hex of string of length "len"... } I call it using hex replacement values in a string, ie using the "\xnn" replacement method: EEPROMwrite(,addr, "\xFF\x00\x01",3); (prints 00 00 01) Now, if a "\x" replacement in the string contains FF (or ff) , the hex value read \ printed is 00 .. BUT if the value is preceded by another value (which is not 00 or FF), eg, EEPROMwrite(,addr, "\01\xFF\x00",3); (prints 01 FF 00) ... it correctly re
  8. I have a routine like: EEPROMwrite(unsigned char addr, unsigned char* str, unsigned char len) { // print out hex of string of length "len"... } I call it using hex replacement values in a string, ie using the "\xnn" replecement method: EEPROMwrite(,addr, "\xFF\x00\x01",3); Now, if a "\x" replacement in the string contains FF (or ff) , the hex value read \ printed is 00 .. BUT if the value is preceded by another value (which is not 00 or FF), eg, EEPROMwrite(,addr, "\01\xFF\x00",3); ... it correctly reads \ prints the hesx value as FF! To b
  9. Thanks Reynard, but that was my first thought too! (I have been caught before with that one...). If I play with the compiler, I can see some CPUs with values which agree with the data sheets, and others which do not - even though the data sheets are all specifying "Flash (bytes)", not "instructions. Also, some TDF files agree with the associated data sheets (eg 44K22), while the TDF for 66K22 does not agree - so there is some inconsistency worth checking! I have had a situation where the compiler says "all OK, only used just over 50% program memory" while MPLAB wont load the h
  10. In SourceBoostC ver 730, I have noticed that some 18Fxx'K'yy CPUs are returning the wrong program memory size in the IDE (it is often 2x correct value). Examples: 66K22, 67K22. If I look in the .tdf files for these CPUs, the same "incorrect" values are present as the program memory ranges. The values are 2 x the size shown in the CPU data sheet. This leads to the IDE \ compiler stats being incorrect after a compile (eg, "ROM available:", "used:" and "free:" figures) I have checked a "correct" CPU tdf (eg, 44K22) and the size agrees with the data sheet, and is displayed
  11. I am planning a project for a customer targetting PIC 18F67K40. This CPU doesn't appear to be supported in the current release (7.30). Can you please provide an update to allow me to use this part? In general, how is BoostC tracking the appearance of new processors? Is anybody producing new support files for them? Either within the Sourceboost company or the community? Is there some other community support site that I should be looking at? (I have in the past edited the _PIC18Fxxx.TDF, map.txt and other include files, to add a CPU, but its a tricky process - is there a guide publi
  12. It would be handy if a large Read-Only data array could be created in ROM space, to be accessed only by using the table pointer instructions. This array would have to be of a type which relaxes the array size limit of 256 bytes (on PIC18). At the moment, I can achieve this with a 'C' program I have written which reads the data I want in the large array from an 'h' file and appends extra 'S' records to the SourceBoost .hex file output. The PIC programmer then programs the target with code + data array, which can then be read with a table pointer routine. However, all this is tedious an
  13. Regarding C compiler \ ver 7.30... are the Flash \ codespace sizes in the 18F86K22, 18F87K22 TDF files correct? They seem twice as large as the data sheet implies.... My compiler was reporting the ROM available 2 x the size the data sheet says- it also caused some problems loading the code when I exceeded the "50%" value, implying that the compiler had got it wrong. The sizes of the 85K22 and 65K22 <do> agree with the datasheet however... Please check - if I've got it wrong, my apologies !
  14. Hi, currently I have a program which uses 2 dimensional arrays to store lists of menu options. These reside in RAM, because Sourceboost wont support 2D rom arrays. (I am using SB 7.30). I now have to expand my menus and dont have the space for them in RAM - so I must re-work the code to place the data in rom. I can get around the 2D array problem with a little work - but in checking on my options in the forum, I see that someone mentioned a "single rom page limit" on rom arrays. Could you explain a little more please? Is this a limit "per "rom array" or on rom arrays, total?
×
×
  • Create New...