Jump to content

DTPIC

EstablishedMember
  • Content count

    27
  • Joined

  • Last visited

Everything posted by DTPIC

  1. 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 reads \ prints the hex value as FF! To be clear, EEPROMwrite(,addr, "\00\xFF\x00",3); (prints 00 00 00) ... does NOT print out FF, as the preceding value is 00.. I have checked the web and this does not seem to be expected behaviour - can you look into it please?
  2. 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 be clear, EEPROMwrite(,addr, "\00\xFF\x00",3); ... does NOT print out FF, as the preceding value is 00.. I have checked the web and this does not seem to be expected behaviour - can you look into it please?
  3. 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 correctly in the IDE... Am i missing something about the "factor of 2" on these CPUs? Or is this just a plain and simple error? (It has turned up on other CPUs too - I will list as I come across them again...) This may be "old news" now that Chameleon is out, but other users may still be working on 730 and it may be that the error has carried over into the new compiler support files....
  4. 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 hex file into the CPU properly because its too big.... As an example, my current project uses 66K22: the compiler is saying "ROM available 131072 bytes, ROM used 34774 bytes (26.1%)". But if I look at the program area of the hex file in MPLAB, it has a limit of 0xFFFF (65536 bytes) and has code up to 0x87D6 (which is the 34774 bytes specified by the compiler). Clearly not 26% utilisation..... more like 53%.... compiler is wrong....
  5. 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 published for "how to" add a CPU to the list? Or could you write one? Or should I write one based on what i have done in the past for you to edit?) Is there a mechanism for users to contribute "mods" they have made for new CPUs, so they can be sent back into the community? Still using your product after many years (back to early 6.xx) - many thanks for a great little compiler & IDE. Just wish you would do a PIC32MX one...(!)
  6. 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 and timewasting, and especially frustrating as the original data for the large table array is in an 'h' file format anyway! Could you perhaps consider this "large Read Only array" as an addition to a future release of Sourceboost C?
  7. 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 !
  8. 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? I could do with a more detailed explanation of rom data limits in the compiler, if you have the time... also any comments on what i am trying to do and whether the method is the best approach, etc
  9. ...erm, have just realised that there is a difference in the K20, K22 cores - they are not "functionally equivalent" - so best ignore my last post....
  10. I am still using BoostC Ver 6.97. I have created a project using 18F44K20, (a 3V3 CPU) but would like to move it to a 44K22 (a 5V CPU). However, 6.97 doesn't support 44K22 in its target list. Could you please confirm for me: 1) As far as I can tell, the K20 and K22 are functionally equivalent - so can I compile for a K20 and use the code on a K22? 2) If so, I guess this also applies for 45K20/K22, 46K20/22, etc? 3) Finally, from another part of this topic, it seems I could add the K22 variants by creating (copy K20 part and edit?) a .h, and .tdf file and adding an entry to the map.txt file? I will move up to release 7 when time allows! But I must get this job out first.... Many thanks!
  11. Hi, I am interested in creating a boostc library for a serial loader (<not> a classic "bootloader", but more of an "on demand" loader, for a specific customer application). To get the serial loader routine to locate at a specific fixed address in memory, I have defined a project which links with the -rb xxxx option; as there is no main() function in the project, I guess this has to be compiled as a library... The routine contains asm instructions, for which it seems the compiler must have system.h included, to be able to interpret the asm. This compiles ok as a library. But when I try to link this into my main project, the linker says failure Error: Duplicate global var: cmcon Error: Duplicate global var: eedata ...etc. I think the project is seeing 2 copies of system.h (one from the library, one from the main part), both of which call in the _PIC16Fxxx.h header, and this is causing the duplication. But I must have system.h in my library project, or else it doesnt understand the asm instructions... I have tried including boostc.h into the lib instead of system.h, but this seems to be too generalised, ie, also does not allow the library asm commands to be understood... There must be a way of compiling a library a) containing asm commands and without a duplicate system.h - but I havent found it yet! Any ideas?
  12. Think I may have found the answer... The problem is indeed duplication of the "volatile char..." definitions for the CPU registers. 1) I copied the PIC16Fxxx.h file from Sourceboost\include to a file in my project directory, (renaming it for safety) and converted all the "volatile char..." definitions to "extern volatile char...". 2) In the library project, I included the above .h file and the compilers own boostc.h file. This now works fine - the loader routine is called from its fixed location at the top of memory, does its stuff (including calls to main program routines) and finally jumps to 0x000 to start the new code... Interestingly, the RAM is unchanged during this load, so you can leave a main program variable set from the loader module (define it as extern...) to indicate that the restart has occurred as a result of a download, etc... I'd still be interested if anyone can find a cleaner way of doing it... There doesnt seem to be much documentation that I could find on the subject of precompiing libraries, even though the feature is there in BoostC - perhaps someone could write a little something to shed some light on this area?
  13. Hi, I have a function into which Im passing a pointer to a char buffer; the sizeof() operator indicates different buffer lengths depending on whether it is used inside or outside the called function: void rcv_RS232_msg(char *buffer); // function def for called function... void myfunc(void) // calling function { char msgbuf[20]; // char message buffer printf("size of buffer outside function is: %d",sizeof(msgbuf)); rcv_RS232_msg(msgbuf); // call the function, passing buffer in... : : } // end of calling function void rcv_RS232_msg(char *buffer) // the called function { printf("size of buffer inside function is: %d",sizeof(buffer)); } The result of the first printf is 20 (correct) The result of the second printf is 2 (?!?) It appears that the length of the buffer is not reported correctly using sizeof() from inside the called function into which the buffer has been passed...... I dont think this behaviour is intentional - can you verify this behaviour? Is it on the fix list? Thanks!
  14. Might be able to answer this one myself....(!) the buffer is passed to the called function as a pointer - so Im probably being given the sizeof the <pointer>, not the buffer, inside the called function... ...so sizeof() is working ok after all....(!) Hope this has been of some use to someone doing something similar... I suppose I will need to pass the buffer length into the called function as another parameter if I really want to use it there... anybody know any other way?
  15. Hi, can you tell me if the BoostC 18F compile is "incremental" (ie, only re-compiles changed source files)? It seems to take the same amount of time to compile regardless of what \ how many source files in the project are changed, and the compiler also lists <all> the source files in the project in the output window as it works through them... I did see a reference to this in a 2004\5 post, suggesting that the incremental feature had been added, but I am not sure if the response was for 16F only... ( I am using BoostC V6.60...)
  16. Think Ive got 2 problems... First, I thought that the "compile" option was the incremental compile of editied source files.... Second, I thought that the "Build" option was a complete buld of all source files - seems that <this> is the incremental option, as it generates a new "makefile.gen" when used... I think the terminology may be different in Microsoft Visual Studio? This may be where my confusion comes from... The "build" option has shown up another problem - it says Building... FATAL: Don't know how to make: D:\Sourceboost\My Done I think its because I have some path names with embedded spaces, (eg "D:\Sourceboost\My Lib Functions...", as above) which require quotes around them - I have looked in the makefile.gen, and the use of quotes around such pathnames seems to be 'unpredictable' - also notice that the file paths and names in project.__c do not have quotes around them.... Should I be declaring the path\filenames in some other way to get around this, or is this an issue? Can I 'fudge' it temporarily by manually editing the project.__c file to include quotes around the paths? Thanks!
  17. I am using BoostC 6.60.... There seems to be a limit on the number of parameters I can OR together in one entry of a rom table initialisation, which is also possibly dependent on the paramter names and values... Let's define some constant parameters: #define PARAM_1 1 #define PARAM_2 2 ...... #define PARAM_7 7 The compiler seems ok with #define RESULT PARAM_1 | PARAM_2 | PARAM_3 | ....PARAM_7 or even char result: result = PARAM_1 | PARAM_2 | PARAM_3 | ....PARAM_7; I can initialise some rom char* array elements with rom char* test_array = { PARAM_1, PARAM_2, 1, 2, 3 etc But I cant init a single element with rom char* test_array = { PARAM_1 PARAM_2 | PARAM_3 | PARAM_4 , 1, 2, 3, etc Worse still, it seems to be dependent on the name or value of the parameters used: #define TONE_CHECK_IDLE 0x00 #define RX_IDD_MEAS_OFF 0x00 #define RX_IDLE_SEL 0x00 #define XXX1_2_LOAD_OFF 0x00 #define XXX3_4_LOAD_OFF 0x00 rom char* test_array = { TONE_CHECK_IDLE | RX_IDD_MEAS_OFF | RX_IDLE_SEL | XXX_4_LOAD_OFF, 1, 2, works, while rom char* test_array = { TONE_CHECK_IDLE | RX_IDD_MEAS_OFF | RX_IDLE_SEL | XXX3_4_LOAD_OFF | XX1_2_LOAD_OFF, 1, 2, doesnt work! There seems to be a limit on the number of parameters I can OR together in one entry of a rom table initialisation, which is dependent on the paramter names and values... I really wanted to adopt the PARAM1 | PARAM2| PARAM3 style of notation as it is self-documenting.... Any ideas or workarounds?
  18. OK, thanks for that - agree that the only reliable workaround I could find was to use a numeric constant - puzzling thing was that the use of certain #defines seemed to work, while others didn't(!) - I'll wait for the fix!
  19. Hi, no response to this one after 2 weeks....! Can anybody a) verify this problem tell me if there are any workarounds c) tell me if it's likely to be fixed? I have previously been using the MPLAB assembler,and it has allowed me to initialise items with many ORed terms in this fashion, so I dont think its completely unreasonable to attempt the same in BoostC? It looks like the part of the preprocessor which deals with defined constants is not being applied to array initialisation... I am guessing that the fix is not so much a "big block of new compiler code", but a re-direction of an existing part of the preprocessor...
  20. Hi, just thought I'd let you know about this 'feature'... If I write: rom char* myarray1[256] = { 0,1,2,3,4,5,6,7 }; and then for (i=0;i<4;i++) {lprintf("%d ", myarray);} I get 1 3 5 7 However, if I use rom char myarray1 = { 0,1,2,3,4,5,6,7 }; I get 0 1 2 3 Apparently the compiler treats the array differently if I try to bound it with . I know that 'according to the manual', a rom char* array strictly shouldn't have a size in its definition, but the compiler accepts it, and produces an unusual result - if the compiler were to throw out a rom char* array definition with a size, it might save a few cross words...! It would also be useful if there was a way to produce a rom char array larger than 256 bytes without having to define an access function to select between several 256 byte sub-arrays...
  21. Hi Wally, thanks for the reminder about arrays being zero-based - we've all forgotten it sometime! But no confusion there - I said that the <size> of the array was 256 bytes, and I expected to be able to access the last byte (ie, array[255]). Anyway, all this doesn't change the fact that you get 2 different behaviours from the BoostC compiler depending on whether you try to specify a at declaration... It seems that you need to declare a rom char* array without to get the 'correct' (expected?) behaviour from the array afterwards...... I just wanted to point it out for anyone making the same mistake, and for the developers to perhaps get a future release of the compiler to throw out such a rom char* .... declaration...
  22. Emte, thanks for the response. The code is now working - I just put this up because I thought it might help others with the same problem, and to inform the developers. According to the documentation, BoostC allows rom char * arrays of a maximum of 256 bytes - I would hope that any compiler that allows an array of that size would allow me to access the last byte of the array! (this seems to be true, as borne out by more recent code...). I am constructing a piece of test equipment, where each test takes 8 parameters, and there may be up to 40-50 tests - this could require arrays greater than 256 bytes. The array \ table goes into program memory space because of the "rom" keyword, and is packed 2 bytes to each program word - the compiler accesses the arrays using the TABLAT, etc assembly instructions (its an 18F target...) - it is a very efficient way of storing this amount of non-varying data. Besides, the user EEPROM space is in use for 'other things'...!
  23. Hi, I have previously created a 16F asm{} block in C2C to 'bit bang' RS232 to a pin which I have been using for some time now (I am already using the UART for something else!) - but I find that I cannot port the asm to 18F in BoostC witout errors... Here is the (working) C2C code: ******************************************* void send_dbg_char(char c) { // executes in 9 cycles per bit - // at 4MHz, runs at 111.1kb/s (112.5kb/s - 1.2%) // unsigned char i = 8; unsigned char t; asm{ startbit: bcf DBGPORT, TX ; set line to space nop nop nop nop nop ; for other rates, insert nops here ifdef RS232CLK20 ;3(n-1)+ 5 cycles - decfsz adds one cycle when result of dec = 0 movlw 0x0B movwf _t_send_dbg_char sdc_startbit_delay: decfsz _t_send_dbg_char,f goto sdc_startbit_delay nop endif databit: btfsc param00_send_dbg_char, 0 ; test data bit 0 goto bit_is_1 rrf param00_send_dbg_char, f ; rotate data - only done if data bit is 0 bit_is_0: bcf DBGPORT, TX ; set line to space goto nextbit bit_is_1: bsf DBGPORT, TX ; set line to mark rrf param00_send_dbg_char, f ; rotate data - only done if data bit is 1 nop ; balances GOTO timing nextbit: ; for other rates, insert nops here ifdef RS232CLK20 ;3n+3 cycles movlw 0x0B movwf _t_send_dbg_char sdc_databit_delay: decfsz _t_send_dbg_char,f goto sdc_databit_delay nop endif decfsz _i_send_dbg_char,f ; check if end of loop goto databit goto stopbit stopbit: nop nop bsf DBGPORT, TX ; set line to mark nop nop nop nop nop nop nop nop ; for other rates, insert nops here ifdef RS232CLK20 ;3n+3 cycles movlw 0x0B movwf _t_send_dbg_char sdc_stopbit_delay: decfsz _t_send_dbg_char,f goto sdc_stopbit_delay nop endif mark_stop_end: } } ******************************************* .... and here is the BoostC port: ******************************************* #include <pic18F452.h> // for port, reg name defs #include "hardware.h" // contains defs for DBGPORT, TXPIN void send_dbg_char(char c) { // executes in 9 cycles per bit - // at 4MHz, runs at 111.1kb/s (112.5kb/s - 1.2%) // unsigned char i = 8; unsigned char t; asm{ startbit: bcf DBGPORT, TXPIN, 0 // set line to space nop nop nop nop nop // for other rates, insert nops here #ifdef RS232CLK20 //3(n-1)+ 5 cycles - decfsz adds one cycle when result of dec = 0 movlw 0x0B movwf _t startbit_delay: decfsz _t, f bra startbit_delay nop #endif databit: btfsc _c, 0 // test data bit 0 bra databit_is_one rrncf _c, 1, 0 // rotate data - only done if bit is zero databit_is_zero: bcf DBGPORT, TXPIN // set line to space bra nextbit databit_is_one: rrncf _c, 1, 0 // rotate data - only done if bit is 1 bsf DBGPORT, TXPIN, 0 // set line to mark nop // balances GOTO(BRA) timing nextbit: // for other rates, insert nops here #ifdef RS232CLK20 //3n+3 cycles movlw 0x0B movwf _t sdc_databit_delay: decfsz _t,f bra sdc_databit_delay nop #endif decfsz _i,f // check if end of loop bra databit bra stopbit stopbit: nop nop bsf DBGPORT, TXPIN, 0 // set line to mark nop nop nop nop nop nop nop nop // for other rates, insert nops here #ifdef RS232CLK20 //3n+3 cycles movlw 0x0B movwf _t sdc_stopbit_delay: decfsz _t,f goto sdc_stopbit_delay nop #endif mark_stop_end: } } ******************************************* BoostC gives the following error: "C:\PROGRAM FILES\SOURCEBOOSTC\boostc.pic18.exe" -t PIC18F452 SCA_DCTJ.c tests.c hardware.c test_table.c "..\..\..\..\..\Sourceboost\My Lib Functions\debug_tx2.c" BoostC Optimizing C Compiler Version 6.55 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Licensed to <me!> under Single user Pro License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited SCA_DCTJ.c tests.c hardware.c test_table.c ..\..\..\..\..\Sourceboost\My Lib Functions\debug_tx2.c >>>>>>>> *** here it is! *** >>>>>>>>> D:\Sourceboost\My Lib Functions\debug_tx2.c(39): error: error in built-in assembly >>>>>>>> failure Failed to locate output file 'debug_tx2.obj' Done Failed ******************************************* Line 39 is the line with the label "databit_is_zero:".... To achieve the port, I have: changed the function parameter external variable name to _c changed the local variable labels to _label_name changed the goto's to bra's changed the rrf 's to rrncf 's changed the comments from ';' to '//' (the #define var "RS232CLK20" is not defined in the above) Quite a long post, I'm afraid, but any ideas? Thanks!
  24. Hi, something I have noticed on IDE vers 5 and 6 is that if I open Acrobat reader at the same time, I get strange interactions between the two; sometimes the file tabs and border around the IDE editor window disappear, leaving Acrobat Reader showing through; sometimes the IDE and Acro will not minimise \ maximise properly; sometimes the IDE and \ or Acro will lock up, requiring restart of the applications, or the whole machine; and sometimes when the IDE has crashed, it re-runs with the message " a requested resource was not available",and the IDE window doesn't appear (but the IDE process shows up in process manager). The version of Acro Reader I am using is V5 on Win98 (quite old stuff, I guess...) - I suppose I should upgrade and see if it goes away.... This is at worst "a bit annoying" for me, but I thought I'd bring it up as I am also having the problem with the new V6 IDE - has anybody else had similar problems?
×