Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. Unrecognised type ID

    Hi guys, I'm getting this message when I build my project - Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F It doesn't appear to be causing any issues, however the compiler reports a warning so I expect there is something odd going on. Any ideas? (Compiler = BoostC++ V7.42) Regards Tim Jarrett
  3. A TDF file is required for build but only the core data from it is used. You need to have a TDF file that has at least minimal data like in _PIC18minimal.TDF There is no document that lists all options that can be used in TDF. You need to check the existing TDF files for examples. Regards, Pavel
  4. You can use your v7 license key with SourceBoost v6. Regards, Pavel
  5. Error with PIC18F25K40

    Well spotted. This error affects several other recently added targets as well. The fix you provided is correct too. Affected files: PIC18F24K40.TDF PIC18F25K40.TDF PIC18F26K40.TDF PIC18F27K40.TDF PIC18F45K40.TDF PIC18F46K40.TDF PIC18F47K40.TDF PIC18F65K40.TDF PIC18F66K40.TDF PIC18F67K40.TDF PIC18LF24K40.TDF PIC18LF25K40.TDF PIC18LF26K40.TDF PIC18LF27K40.TDF PIC18LF45K40.TDF PIC18LF46K40.TDF PIC18LF47K40.TDF PIC18LF65K40.TDF PIC18LF66K40.TDF PIC18LF67K40.TDF
  6. Thanks Jorge, pretty much what I had decided to do as well. It just would be easier to have the compiler and linker do all the work for me, rather than have to build the code twice. Regards Tim
  7. Hi There is one thing in your logic that you might want to re-evaluate. I wouldn't trust a compiler to organize the code space in a continuos block, most of the ones I know do spread chuncks of code all over the place just to optimize for the addressing scheme of the PIC (mnimize pagging). The same spreading, for the same reasons, might be found with RAM usage. If you intend to use some part of your flash memory for data you would better reserve it. Use the "-rt" command line switch to limit the maximum address available for the program and use the flash above that address for runtime data (NVM). A work around for your initial question can be to adjust the top of rom (-rt) close the the actual size of your release code and calculate the CRC from "0x0000" up to your "-rt" value. You can calculate the CRC verification from the data on the HEX file as it is a byte image of what will be recorded in the program flash. BTW: Make sure you do program your release code on blank chips so you can use the erased value of the flash in your CRC calculation. Just my 2 cents of it.... Best regards Jorge
  8. Earlier
  9. Hi Jorge All I'm trying to do is calculate a CRC checksum for the ROM, starting at 0x0000 and ending at the last used address of my program, hence I need to know the last address used. I can't CRC the entire ROM because I will be using the top end for non-volatile storage, and for that I also need to know the last used address. Normally I would edit the linker control file and add a label after the used code section, but this compiler doesn't appear to use a control file, I guess it has the parameters hard-coded in. All I can do at the moment is build the code with a 0x0000 address coded in as a rom char* pair, look at the code statistics after the build process, copy the size of the code in to the rom char* and then re-build. It would be safer and easier to have the compiler and linker do it automatically. Regards Tim
  10. Hi I usually find that kind of information on the HEX file used to program the PIC. If you tell us what is your goal, maybe there are other ways, besides finding the last used flash address, to achieve it. Best regards Jorge
  11. Hi guys, Is there any easy way of identifying the last used address in rom using BoostC or BoostC++ compilers? I cannot find a linker control file to add a label, is there any way to guarantee that a label defined in the source code ends up as the last addressed object? Thanks Tim
  12. Another request, not much luck with enhancements so far but worth a punt... Please can you add support for friend functions for classes? Thanks.
  13. A long shot I know, but what are the chances of the source code being moved to an open-source licence? That way maybe there could be more third-party improvements and bug fixes etc. Just a thought. (I would certainly be interested in adding new features, i.e. 12-bit support, true template support, overloaded constructor support etc.) Regards Tim
  14. There is a bug in the PIC18F25K40.tdf file. As installed it reads Configure AccessBank { SplitAddr = 0FFh; } but should be Configure AccessBank { SplitAddr = 05Fh; } It means that indexing of arrays and routines like delay_ms, sprintf do not work and the processor hangs
  15. Please let me know how to change 7th licence key which matches Source Boost v6. I have a licence key of 7th version, but I would like to use 6th edition Source Boost. I use the licence key and nothing happen to 6th version. Regards, Nologram
  16. Yes, I understand that I'm using old architecture here (16F...) and I'm sure chameleon will be targetted for more modern ones and it will not need #pragma data for configuration lines... For me, big plus of chameleon compiler at the moment is it's speed. I'm using it under linux and speed difference of boostc_pic16.exe and c_pic16.exe is absolutely measurable. I hope to try it on a more modern architecture, where it will not be limited with such constructs Anyway, thank you very much for trying it out
  17. Hi Jaero, I think #pragma DATA is only for byte data and not words. I tried your config but with a different processor selected (PIC18F25K22), I forgot to change it to your chip, and I got Windows error box saying "c_pis18.exe has stopped working". Using "rom char *myromdata = {1,2,3};" just puts the data into RAM. Tried other forms from other compilers but no luck. Enums don't work right for me either. Using a compiler warning to promote SPAM telling us to try Chameleon is very bad practice. Deleted that offending line of code. Until Chameleon comes out of Beta and there exist a manual, Chameleon is just a toy at the moment. The limit of 256 bytes of rom per declaration in BoostC is a pain for me at the moment. I have to split my GLCD font files into pages. Will be moving this project to an ATmega very shortly. Cheers Reynard
  18. Ok spamming more Looks like chameleon compiles #pragma data wrong: #pragma DATA _CONFIG1, 0x2FAE // 0b0010111110101110 #pragma DATA _CONFIG2, 0x3FFD // 0b0011111111111101 end up as: ORG 0x00002007 2007 00AE DW 0x00AE 2008 00FD DW 0x00FD And another thing, chameleon produces over 100% more code (479 words instead of 222 words with v7 compiler). I don't understand this: intcon.GIE = 1; compiles into 0101 142A BSF CompTempVar640,0 0102 1C2A BTFSS CompTempVar640,0 0103 138B BCF gbl_intcon,7 0104 182A BTFSC CompTempVar640,0 0105 178B BSF gbl_intcon,7 So this post is more for Pavel or David...
  19. Ok, I'm taking it back with asm data placed at speciffic address. This one works, my project compiles with chameleon at this stage. I accidentaly removed CONF_BYTE1 and CONF_BYTE2 when I was trying the asm data statements. I hope chameleon will understand all my other exercises with this project
  20. Hi Reynard. You are right with logic operators in #pragma, when I place computed hex values there, these two lines compile without problems. #pragma DATA _CONFIG1, 0b0010111110101110 #pragma DATA _CONFIG2, 0b0011111111111101 It is for PIC16F720 so I don't have #pragma configs available. As you mentioned, it seems that there is no way to put data in flash, because this chip has no eeprom and for my project I need 5 configuration bytes placed in flash. I tried #pragma data, compiler doesn't like it the same as it doesn't like: void config_data_in_flash() @ CONFIG_FLASH_ADDR { asm data CONF_BYTE1, CONF_BYTE2, FLAGS_SIREN, MOT_SINGLE, 5 } So, asm data construct isn't supported either and I'm stuck with my legacy v6 compiler. Thank you Reynard for helping with the config lines!
  21. Please can you add support for the 12-bit baseline devices to BoostC and BoostC++? Some of these have relatively large FLASH and register memories but have a 12-bit instruction-width core, which the current compiler doesn't support! Regards Tim Jarrett
  22. Pavel, I don't think this is correct? I'm using MPLAB-X and I've added a new header for a PIC16F570 device and modified the MPLAB jar files to allow me to use SourceBoost with that device (it doesn't by default). I haven't created a .tdf file for the same device because I don't use the SourceBoost IDE, but when I try to build under MPLAB-X, I get this message - main.cpp error: could not open input file 'C:\Program Files (x86)\SourceBoost\config\PIC16F570.tdf' So it appears as though the build process needs the .tdf file as part of the build as well (this is using the C++ compiler under MPLAB-X). I will have a go at creating one for my new device. If it's successful, is there somewhere I can post it on the forum to make it available to other users? [EDIT] Pavel, is there a full list of the options that can be used in the .tdf file entries? I found a .txt file in the config folder that partly explains the .tdf file format, but it does not give a complete list of all the possible options? Rgds Tim
  23. Hi Jareo, The Chameleon doesn't seem to like the '&' in the pragma line. If the header file contains the type 2 config style then use it. #pragma config FOSC = INTIO67 // Internal oscillator block, port function on RA6 and RA7 #pragma config WDTEN = ON // WDT is always enabled. SWDTEN bit has no effect #pragma config PWRTEN = ON // Power up timer enabled otherwise work out the bits you need and insert a hex value. Remember to define all the bits in all the config bytes or strange things can happen. SourceBoost doesn't recognise the default erased chip values. I still haven't worked out how to put data into rom with this compiler. Cheers Reynard
  24. Please let me know how to change 7th licence key which matches Source Boost v6. I have a licence key of 7th version, but I would like to use 6th edition Source Boost. I use the licence key and nothing happen to 6th version. Regards, Magia
  25. Chameleon has much better template support including meta programming. It does not however support member functions including constructors and destructors or inheritance (inheritance is not too difficult to add but probably does not make much sense if member functions are not supported). Regards, Pavel
  26. Thanks Pavel. Will you be doing a similar exercise with an alternative to the BoostC++ compiler as well, or does Chameleon already support C++? Thanks Rgds. Tim
  27. Now I have the licence key of 7th version, but I am going to use 6th edition. I would like to know how to change licence key. Regards, Magia
  1. Load more activity
×