Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. Hi The same solution works for all libs. Also its valid to the old MPLab 8.xx as for MPLab X. If memory is not tricking me, this is documented in the manuals. Best regards Jorge
  3. We would like to reproduce this and we don't need your source code. Please email your project obj files and linker command line to support@sourceboost.com Regards, Pavel
  4. Answering to my self. Its working now. Under mplabx the libraries should be added to the project through Project Properties and add it to BoostLink / Additional options. By the way, the compiler/linker finish the job in about 3 minutes > 72 module_files / 273 functions - 4 core, i7, 2.8GHZ, 16gb_ram The compiler takes 30 seconds. The rest of the time is spent by the linker (2.5 minutes)... It would be great if linker could be improved.
  5. #include <system.h> typedef unsigned char uchar; void main() { uchar j=20; uchar i = (j/10); } Compiling the little snipet above under mplabx, it return errors like this: Error: Unresolved external function:'__div_8_8(unsigned char,unsigned char)' depending of the evaluated expression the error could be: Error: Unresolved external function:'__div_16_16(unsigned char,unsigned char)' Surprinsingly, the same not happens to 16/32 bit multiplications. The solution is to include libc.pic16.lib or libc.pic18.lib, depending the pic family we are using. This could be done, under mplabx/File/Project Properties. Now in the Project Properties Window, select Libraries and Add Library/Object File, choose <libc.pic1x.lib> and thats it. Alternately, it can be done following the procedure above but picking Linker instead Libraries and add <libc.pic1x.lib> in the Additional Options. P.S. the same procedure works with floats.
  6. Is there any trick for float lib to work with mplab x? The code below compiles ok in sourceboost editor but not in mplabx. #include <system.h> #include <float.h> void main() { float f = float32_mul(2.5, 2.5); } Here is some errors when compiling this code in mplabx ide: Error: Unresolved external function:'__mul_32_32(unsigned long,unsigned long)' ... same error above repeated n times ! Error: Unresolved external symbol, function:__mul_32_32 ... same error above repeated n times ! make[2]: *** [dist/default/production/float.X.production.hex] Error -2 make[1]: *** [.build-conf] Error 2 make: *** [.build-impl] Error 2 BUILD FAILED (exit value 2, total time: 5s) float.pic18.lib was included as explained in the FoatMath.pdf page 9 PIC18LF67K40 / c++ pro licence / sourceboost 4.43 / mplab x 4.15
  7. Earlier
  8. Hi there, As far as I can see, J94 types are not supported and I have no idea if the compiler will continue to be upgraded or not. The 18(l)fxxk40 types, they are supported, but the header files are incomplete, so i wrote a simple tool to generate them from the "inc" files included in the mplabx/v4.10/mpasmx. I can put them here if the owners of sourceboost allow me to... i have no idea about legal stuff. Optionally it can be done by modifying the files provided by microchip, using an editor with macros in order to turn the job less painfull... for instance, p18lf67k40 has about 6700 lines. regards
  9. I tried your suggestions but could not reproduce this error Most likely it's just one particular line of code. Maybe you can remove portions of this code that contain IP of your customer and send us the resulting file and maybe even obfuscate it. We are releasing a new version very soon and it'll be nice if this fix makes its way in. Regards, Pavel
  10. Here are some notes how rom objects work in BoostC: - a rom object is always identified by one byte (that's why in the code above gbl_sw_id is 1 byte long) - when linker processes all its input files it makes a list of all rom objects and allocates IDs to them - linker generates code for all these rom objects that it puts into the code memory - linker generates a function that can extract any byte of any rom object using its ID and position/index - when compiler needs to generate code to access character in a rom object it uses an placeholder ID and character position/index and calls function that linker generates in the prev bullet. Later linker replaces this placeholder ID with an actual object ID. Chameleon does not yet support rom objects. Support for rom objects will be added to Chameleon in the upcoming 7.43 release. Regards, Pavel
  11. I have been using SourceBoost for 10 years now and never knew it put all that extra code into the startup section for rom arrays. I suppose that is because the IDE shows the .casm file which doesn't show all this extra stuff. We will just have to make sure to write code that doesn't crash and test it well. Function pointers taking arguments usually causes me problems. Can't seem to use the arguments unless I copy them into a local first variable. Maybe it's just me. But as you say a great little compiler. Novo is usually in every project I do. Cheers Reynard
  12. Hi DTPIC, That's handy. My current project uses a 40 pin PIC18F46K22. Thanks for the info and I will have a look into it. Cheers Reynard
  13. 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 MOVLB 0x02 MOVWF gbl_segmap, 1 MOVLW 0x01 MOVWF gbl_sw_id, 1 MOVLW 0x02 MOVWF gbl_xfm_id, 1 MOVLW 0x03 MOVWF gbl_sw_xform, 1 MOVLW 0x04 MOVWF gbl_mastermodename, 1 MOVLW 0x05 ... where segmap, sw_id, xfm_id, swxform, mastermodename, are all rom char* arrays. Isn't this putting an array token number into RAM? Example: 'C' definition of sw_id array: // 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 // <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> rom char *sw_id = "CFGDM1MODTD1TU1DM2TU2TD2DSBDSADM3TD3TU3TD4TU4DM4---"; A typical use of the array in 'C' would be romstrget(sw_id,start,length,dest_array); // romstrget is my function which accesses the array at the array position given by "start", // then copies "length" bytes to "dest_array", terminating in 0x00 At the asm level, the array is accessed using: MOVLB 0x02 MOVF gbl_sw_id, W, 1 MOVLB 0x03 MOVWF romstrget_00000_arg_romstr, 1 MOVF main_1_j, W, 1 MULLW 0x03 MOVF PRODL, W MOVWF romstrget_00000_arg_start, 1 MOVLW 0x03 MOVWF romstrget_00000_arg_len, 1 MOVLW HIGH(gbl_msg_tmp+D'0') MOVWF romstrget_00000_arg_str+D'1', 1 MOVLW LOW(gbl_msg_tmp+D'0') MOVWF romstrget_00000_arg_str, 1 CALL romstrget_00000 Isn't MOVF gbl_sw_id,W,1, attempting to access the rom array using a RAM based token value? I haven't followed the code to the absolute letter \ byte at this point, so you may be able to set me on the right path...! Thanks for your time.... still think its a great little compiler, and I'm looking forward to Chameleon...
  14. Are you using a PIC 16 or PIC 18 ? My current project is for PIC 18 and I have 70+ rom char arrays both string and byte arrays. All the arrays are stored consecutively in program memory. Accessing the arrays is through an index which is a constant. If my arrays are each occupying 256 bytes I would know about it. Can you supply Dave and Pavel with code showing what you believe to be experiencing. Cheers Reynard
  15. 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 are probably looking in the wrong place in ROM). As a (licenced!) commercial user, it is sometimes necessary to try to ensure the contents of a lookup table or array at all costs. (Yes, I am the first to agree that I should be preventing the overwrite of RAM!). If the above is a correct observation, then 1) this assignment of rom char numbers to RAM is not a good idea-it can be corrupted 2) we seem to be burning 256 bytes of ROM per array regardless of required size, which also does not help in a tight for space application. Looking at the assembly output, it would seem reasonable to hard code the rom array base address; this would also make it easier to make the arrays only the length they need to be (and leave more code space available). Maybe you can take this into consideration if you are revisiting rom char array handling in Chameleon. (...and it would also be good to be able to assign the contents with 0xnn or \xnn - I think others have reported problems here?) Thanks for listening!
  16. 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...
  17. 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....
  18. When compiling a file the first thing the compiler does it splitting preprocessed source file into lines. If it fails it spits out the error that you quoted. Normally this process is very straightforward and there shouldn't be any errors (hence the error is so brief) but looks like we missed something in this parser (Chameleon is still in beta stage). Can you email your source file along with the compiler command line to support@sourceboost.com so we can investigate. Regards, Pavel
  19. 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?
  20. Chameleon compile error

    Source file sent.
  21. Cam you email your source file to support@sourceboost.com Regards, Pavel
  22. Reading this again integration is for old MPLAB not MPLABX. Managed to install plugin manually following instructions. Thanks.
  23. At the end of installation I get error - Can't locate MPLAB language suite directory. BoostC integration into MPLAB failed.
  24. Chameleon compile error

    While building I get error window "c_pic16 has stopped working"
  25. This is a bug. Please try a fix available from http://www.sourceboost.com/CommonDownload/Fixes/c_pic16.zip (download and unzip it into your SourceBoost installation directory, it will replace the original chameleon pic16 compiler). Thanks for reporting this. Regards, Pavel
  26. Failed To Locate Output File..

    mi problema es el mismo y desabilitado el mi antivirus y aun así obj no se ejecuta My problem is the same and disabled my antivirus and still obj does not run
  27. Chameleon compile error

    I removed some personal comment lines. Line 18 is the Config1 setting. Turned optimization off but still not working.
  1. Load more activity