Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Hi jartim, Are you sure INCF 0x47, W modifies the value in Trembler ? Cheers Reynard
  3. Last week
  4. Preprocessor Macros Do Not Work In Mplab-X V4

    Hi If my memory is not tricking me, that "item 2" refered a problem with the Sourceboost IDE and has nothing to do with MPLAB integration. Just my 2 cents... Best regards Jorge
  5. You are correct in your findings. Some of the tdf files are specifying the incorrect program address range. This is a subject that came up a few years ago but who wants to go through all the tdf files to find the errors. Hopefully they will be corrected as they are reported. My main work horses are the 26k22 and 46k22 which appear correctly specified. Cheers Reynard
  6. Preprocessor Macros Do Not Work In Mplab-X V4

    It looks like this problem was originally fixed in V7.10 but has been re-introduced (this is the text from the version log for V7.10) - Mplab x integration 1. Updated MPLAB X plugin to support all SourceBoost compilers. 2. Fixed problem when extra command line arguments were not added to the command line. 3. Added support for include directories to mplabx plugin. Item 2 is the problem being reported here.
  7. 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....
  8. Earlier
  9. Check that the data sheets are not specifying number of instructions as one instruction is two bytes. Cheers Reynard
  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 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....
  11. Preprocessor Macros Do Not Work In Mplab-X V4

    Found a workaround to this issue - manually define the macro in the "Additional options" field - The output window shows the value gets tagged on to the end of the command line, whereas before it was not being passed to the compiler at all.
  12. Bug description: The same source code line generates different assembly code in different places. Sometimes the generated code is incorrect, sometimes it is correct. Steps to reproduce: Use the same source code in 2 different places in the source. Detailed description to reproduce this problem I use this statement in two different places in my source code - WatchdogTarget = CONST_WDT_MINTIME + (Trembler & 0x07); CONST_WDT_MINTIME is a constant - #define CONST_WDT_MINTIME 1U The first time it is used, the following code is generated (which looks correct) - 01D7 3007 MOVLW 0x7 01D8 0547 ANDWF 0x47, W 01D9 00CA MOVWF 0x4A 01DA 0A4A INCF 0x4A, W 01DB 00C4 MOVWF WatchdogTarget The second time is it used, the following code is generated (which is not correct as it modifies the value in "Trembler" at 0x47) - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, F 020C 0A47 INCF 0x47, W 020D 00C4 MOVWF WatchdogTarget Expected behaviour: This is the code I would expect to see - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, W 020C 0A47 ADDLW 0x01 020D 00C4 MOVWF WatchdogTarget The compiler should not modify the value of "Trembler" at 0x47 (and as the value of CONST_WDT_MINTIME may be other values at compile-time) If CONST_WDT_MINTIME was (say) 32, I would expect to see this instead - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, W 020C 0A47 ADDLW 0x20 020D 00C4 MOVWF WatchdogTarget Is the problem 100% reproduceable: Every time IDE version: MPLAB-X 4.0 Compiler: BoostC++ Compiler version: 7.42 Target device: PIC12F635 OS: Windows 7 64-bit
  13. Looks like a bug. Will take a look. Pavel
  14. First time using Chameleon and I'm stuck. enum MY_ENUM {ENUM0, ENUM1, ENUM2}; int myIntArray[ENUM2]; void main() {} Why can't I use an enum value as array size ? Works with BoostC. Cheers Reynard
  15. Update To Test_Bit

    Hi Any special reason to not use the bitwise not operator (~) or does it generate the same code^? Using a logical operator induces the compiler to do a type cast on the result of "test_bit" to a logical type (char or int) before checking its value. In strict 'C' the "!test_bit(...)" expression translates to something like "!(char)test_bit()" or "!(int)test_bit(...)" How about droping the old "test-bit()" and similar macros and using direct bit indexing, If I'm not worng its available since the first release of BoostC 7.xx AFAIK the "test_bit", "set_bit" and "clear_bit" macros have been deprecated several years ago. EDIT ADD: "semantics do matter!" Best reards Jorge
  16. Update To Test_Bit

    Hello - When the compiler generates code for "test_bit(x,y)" it very nicely generates a 'btfss' instruction. However, when it generates code for "!test_bit(x,y)" it generates much more complex code because the ! is a logical operation not a bit-wise operation. It would be nice if the compiler could spot that "!test_bit(x,y)" is really a 'btfsc' instruction instead. Thanks!
  17. I would guess the endian-ness is wrong for the long-integer so when you load the bytes in individually, they're actually going in in the wrong order. The union works because the compiler automatically swaps the bytes around to match the correct endian-ness for the long or float.
  18. Hello - I am trying your excellent compiler before buying a license for my business. I have installed the toolchain in MPLAB-X V4.00 but the pre-processor macros do not work. Please see the attached file for an example of my configuration. I have defined 2 Preprocessor macros "_ICD3_DEBUG" and "_SJL_BUILD" , but they do not get passed to the compiler - CLEAN SUCCESSFUL (total time: 266ms) make -f nbproject/Makefile-ICD3_Debug.mk SUBPROJECTS= .build-conf make[1]: Entering directory 'E:/Projects/InCarKeepAlive' make -f nbproject/Makefile-ICD3_Debug.mk dist/ICD3_Debug/production/InCarKeepAlive.production.hex make[2]: Entering directory 'E:/Projects/InCarKeepAlive' gnumkdir -p build/ICD3_Debug/production gnumkdir -p build/ICD3_Debug/production gnumkdir -p build/ICD3_Debug/production "C:\Program Files (x86)\SourceBoost\xlaunch.exe" -t PIC12F635 -obj "build/ICD3_Debug/production" -o "build/ICD3_Debug/production/main.o" main.c -v "C:\Program Files (x86)\SourceBoost\xlaunch.exe" -t PIC12F635 -obj "build/ICD3_Debug/production" -o "build/ICD3_Debug/production/config.o" config.c -v "C:\Program Files (x86)\SourceBoost\xlaunch.exe" -t PIC12F635 -obj "build/ICD3_Debug/production" -o "build/ICD3_Debug/production/init.o" init.c -v BoostC Optimizing C Compiler Version 7.41 (for PIC16 architecture) http://www.sourceboost.com Copyright(C) 2004-2017 Pavel Baranov Copyright(C) 2004-2017 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC12,PIC16 max code size:2048 words, max RAM banks:2, Non commercial use only main.c Starting preprocessor: "C:\Program Files (x86)\SourceBoost\pp.exe" main.c -i "C:\Program Files (x86)\SourceBoost\include" -d _PIC12F635 -la -c2 -o build/ICD3_Debug/production\main.pp -v -d _BOOSTC -d _PIC16 -d _CHAR_INDEX BoostC Optimizing C Compiler Version 7.41 (for PIC16 architecture) http://www.sourceboost.com Copyright(C) 2004-2017 Pavel Baranov Copyright(C) 2004-2017 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC12,PIC16 max code size:2048 words, max RAM banks:2, Non commercial use only init.c Starting preprocessor: "C:\Program Files (x86)\SourceBoost\pp.exe" init.c -i "C:\Program Files (x86)\SourceBoost\include" -d _PIC12F635 -la -c2 -o build/ICD3_Debug/production\init.pp -v -d _BOOSTC -d _PIC16 -d _CHAR_INDEX BoostC Optimizing C Compiler Version 7.41 (for PIC16 architecture) http://www.sourceboost.com Copyright(C) 2004-2017 Pavel Baranov Copyright(C) 2004-2017 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC12,PIC16 max code size:2048 words, max RAM banks:2, Non commercial use only C:\Program Files (x86)\SourceBoost\include\system.h(40): WARNING: Try our new Chameleon C compiler. It's fast, free and 95% backward compatible with BoostC. headers.h(14): WARNING: Release build headers.h(18): WARNING: BoostC compiler in use config.c Starting preprocessor: "C:\Program Files (x86)\SourceBoost\pp.exe" config.c -i "C:\Program Files (x86)\SourceBoost\include" -d _PIC12F635 -la -c2 -o build/ICD3_Debug/production\config.pp -v -d _BOOSTC -d _PIC16 -d _CHAR_INDEX C:\Program Files (x86)\SourceBoost\include\system.h(40): WARNING: Try our new Chameleon C compiler. It's fast, free and 95% backward compatible with BoostC. headers.h(14): WARNING: Release build headers.h(18): WARNING: BoostC compiler in use C:\Program Files (x86)\SourceBoost\include\system.h(40): WARNING: Try our new Chameleon C compiler. It's fast, free and 95% backward compatible with BoostC. headers.h(14): WARNING: Release build headers.h(18): WARNING: BoostC compiler in use init.c success config.c success Compile time: 0:01 success Compile time: 0:01 success main.c success Compile time: 0:01 success gnumkdir -p dist/ICD3_Debug/production "C:\Program Files (x86)\SourceBoost\boostlink_picmicro.exe" -t PIC12F635 -ld "C:\Program Files (x86)\SourceBoost"\lib -p dist/ICD3_Debug/production/InCarKeepAlive.production.hex build/ICD3_Debug/production/main.o build/ICD3_Debug/production/config.o build/ICD3_Debug/production/init.o BoostLink Optimizing Linker Version 7.41 http://www.sourceboost.com Copyright(C) 2004-2017 Pavel Baranov Copyright(C) 2004-2017 David Hobday Building CASM file Memory Usage Report =================== RAM available:64 bytes, used:12 bytes (18.8%), free:52 bytes (81.2%), Heap size:52 bytes, Heap max single alloc:51 bytes ROM available:1024 words, used:247 words (24.2%), free:777 words (75.8%) success make[2]: Leaving directory 'E:/Projects/InCarKeepAlive' make[1]: Leaving directory 'E:/Projects/InCarKeepAlive' BUILD SUCCESSFUL (total time: 7s) Loading code from E:/Projects/InCarKeepAlive/dist/ICD3_Debug/production/InCarKeepAlive.production.hex... Loading completed Please can you advise how to make this work? Many thanks
  19. Plugins have not changed and we don't plan to release 7.41 plugins. You can use 7.40 plugins with this release.
  20. I see that the document " MplabX_Plugin.pdf " in the source boost install is chanced. On page 9 is an explanation how to force the compiler: To force BoostC or BoostC++ use command line argument -force_c or -force_cpp. To force Chameleon use command line argument -force_chameleon To add command line argument right click on the project inside MPLAB-X and open project properties dialog. this is a far better method , so forget about chancing "build tools" file names Lieuwe
  21. hello, I have source boost v7.41 installed, when I look to the download http://www.sourceboost.com/Products/IdePlugins/Download.html There is no V7.41 plug-in pack yet. Although v7.40 plug-in seem to work with 7.41 IDE, is the upgrade to 7.41 on the way, or must I use the 7.40 plug-in with the 7.41 IDE ? Lieuwe
  22. Hi Thank you Pavel. So, if I understood it correctly all the important things are acounted for, its only missing optionals. All the registers relating to oscillator configurations, interrupts, memory paging/banking and other core features are defined. The compiler and linker do handle interrupts (context), the memory maps (ROM pages / RAM banks) and config words correctly, including the tricky dispatching code used by Novo. All I have to take care by myself are the peripherals. Good enought for me! EDIT ADD: BTW, I mostly use MPLAB 8/X Best regards Jorge
  23. Limited support means that only core information that is necessary to compile and debug for this target is included into system headers and TDF files:- only core registers are defined in the system header files, if you need other registers you need to add your own defines to either your code or system header - full config data is added to the system headers (PIC16) or TDF(PIC18) files - target architecture is fully described in the TDF files but non-core registers and register groups are not. You are welcome to add missing information. To compile it's only necessary to add it to system header files. Missing information in the TDF files is used in debugging under SourceBoost IDE and if you use Mplab or Mplab X you don't need it. For example look at the Port B support that is not defined in the limited support targets but is fully supported in PIC18F8722. This target has the following information in its system header file PIC18F8722.h (used in compilation): ... #define PORTB 0x00000F81 ... volatile char portb @PORTB; .. and in PIC18F8722.tdf file (used for debugging): Configure PORTB { // create PinNames = "RB0|INT0","RB1|INT1","RB2|INT2","RB3|INT3|ECCP2|P2A","RB4|KBI0","RB5|KBI1|PGM","RB6|KBI2|PGC","RB7|KBI3|PGD"; } RegisterSF PORTB { Description = "PORTB",""; Address = F81h; BitNames = "RB7","RB6","RB5","RB4","RB3","RB2","RB1","RB0"; }
  24. Hi Pavel What exactly means "limited support" in the version log? Its something to do with the core processor or its only a libraries thing? Best regards Jorge
  25. The reason we use xlaunch.exe instead of the actual compiler in the MplabX plugin is to allow different programming languages to be used in the same project. Xlaunch analyses the command line and based on the extension of the input source file launched a relevant compiler For example a project can consist of .c, .c++ and .bas files an when compiling xlaunch.exe will use C, C++ and Basic compilers to compile these files.
  1. Load more activity
×