Pavel

STATUS and C are defined as integer constants so after preprocessing compiler will see "asm bcf 0x0003,0x0000" which is not valid assembly. Take a look at the BoostC help as the "Inline Assembly" chapter. Pavel

Sorry still no good. Eeprom header already checks this but it doesn't help linker that can't find 'eeadrh' variable. Regards, Pavel

Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH? Regards, Pavel I would have thought that was more your job rather than mine but since you ask how about adding the dummy EEADRH definition to all of the appropriate PIC18 header files. That would stop the linker from complaining and the user would not have to waste a day scratching his head wondering why the code doesnt compile. Not sure I understand your suggestion. Can't see how a dummy EEADRH definition can help. Linker wants a variable called 'eeadrh' when links to eeprom library.

Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH? Regards, Pavel

SourceBoost v7.10 release candidate is available to download from: http://www.sourceboost.com/CommonDownload/Binaries/SourceBoostV7.10RC/sourceboostv710.exe What's new: MplabX plugin updated to work with Mplab X 1.20 BoostBuild is now installed as a service Added support for new targets PIC16f1508, PIC16lf1508, PIC16f1509, PIC16lf1509, PIC16f1782, PIC16lf1782, PIC16f1783, PIC16lf1783, PIC16F720, PIC16F721, PIC16F722A, PIC16F723A Fixed several issues in compiler, simulator and ide reported on the forum Let us know if you find any problems. Regards, Pavel

Please do. This fix will be included into the coming 7.10 release. Regards, Pavel

Not sure I understand. Window sizes and positions are saved unless we are talking about different things. And all size/position behaviour hasn't changed for years. Maybe you can post a screenshot and mark what's wrong there. Regards, Pavel

Yes this is weird and should be fixed. If this happens again please send the corrupted project file (file with .__c extension) to support@sourceboost.com (or just put its content into this thread) We want to keep IDE simple without adding tons of (not essential) features what seems to be a tendency in other environments. Renaming can be done easily in windows explorer (just as you mentioned). Unless we get requests from other users this probably won't be implemented. Regards, Pavel

Please don't use volatile and use intermediate temporary. Something like: #define IOTRISB ((unsigned*)(BANK_0 + TRISB)) ... unsigned *tris = IOTRISB; *tris &= ~SEGMENT_MASK; Regards, Pavel

I'm afraid the usage of libc.pic16x.lib is not documented well. The reason for that (not a good one) is that SourceBoostIDE users don't need to worry about this library as it is linked to a project automatically when working with SourceBoostIDE. But this is not the case when project is managed outside of SourceBoost IDE (i.e. under MPLAB) where the correct libc needs to be explicitly linked to a project: large\\libc.pic18.lib PIC18, large memory model system library. Linked automatically under SourceBoostIDE. Needs to be explicitly linked when working outside of SourceBoostIDE (i.e. under

Not sure what PICs are "enhanced mid-range" targets but you need to use libc.pic16x.lib instead of libc.pic16.lib with devices that use PIC16 extended instruction set like PIC16F193x and alike (the ones for which you need to use -16x compiler command line argument) Pavel Regards,

I see. Try to add -O2 into the compiler "Additional command line options" field. If MPLAB puts it after -O1 than the last one will be used. If this doesn't work add #pragma OPTIMIZE "2" before the function you want to optimise and this will apply level 2 optimisation to it. Regards, Pavel

The code that I posted was produced with optimisation level 2 which is the default one. So in theory you don't need to specify any optimisation arguments to get similar result. Try to remove the optimisation pragma. Does MPLAB show you the compiler command line? If it does check that it does not use any -On command line argument (except -O2 which is ok). Note that the optimisation pragma works an function level. This means that it will only apply for a function that follows the pragma statement. Regards, Pavel

Looks like you have optimisation disabled. Here is what I got: signed int binl; binl = ~binl; binl++; 004E 09A0 COMF main_1_binl, F 004F 09A1 COMF main_1_binl+D'1', F 0050 0AA0 INCF main_1_binl, F 0051 1903 BTFSC STATUS,Z 0052 0AA1 INCF main_1_binl+D'1', F Regards, Pavel

Yes it is possible. Plugin API lets plugin code access registers and check and modify their values (all these are described in the Plugin System document): Get register handle: void GetRegHandle( char* name, HANDLE* hReg ) Read/write register: void GetRegVal( HANDLE hReg, int* val ) void SetRegVal( HANDLE hReg, int val ) Register/unregister register change callback: void AddRegChangeCallBack( HANDLE hReg, REGCHGCALLBACK pfunc, void* pParam, int iParam ) void RemoveRegChangeCallBack ( HANDLE hReg, REGCHGCALLBACK pfunc, void* pParam, int iParam ) where the callback signature

Have you added eeprom library to the project? Regards, Pavel

The color indicates the active project. Try to add more projects to a workspace and you'll see the difference. Regards, Pavel

These macros are used to make the code easier to use. To understand how they work you need to understand C++ templates (the BoostC compiler supports some of C++ language features including function templates). In short template arguments are values known at compile time and are passed down the call tree. What may look confusing is that a template argument may not be used inside a function called from application code but it will be used somewhere inside functions called from this function. Regards, Pavel

We were able to reproduce the problem and are working on a solution. Current strategy is to add necessary settings during installation or warn user if computer settings need to be modified manually. Thanks to all for reporting. Regards, Pavel

We are sitting on some bug fixes/changes/improvements but have not release any new version. We planned to do this after we update the MPLAB X integration but it looks that we might to release before this happens as it takes a longer than expected to get answers for a few technical questions from Microchip. Regards, Pavel

Congratulations with the project. We can put the project on SourceBoost examples page on http://www.sourceboost.com/Products/BoostC/ExampleCode.html (just mail all relevant file to support@sourceboost.com) Regards, Pavel

I don't know the detail. This is one for Pavel to answer. Current MPLAB X integration was done for MPLAB X beta 5 and 7. We currently work on the update that will match changes made in MPLAB X since then. Unfortunately we need to get answers for a few technical questions from Microchip and they are a bit slow with replies. Hopefully we will resolve those soon and release an MPLAB X integration update. Regards, Pavel

Rom specifier can be used with char and char* types only. Your code tries to use it with array of pointers and this is not supported. Take a look at the 'Rom' chapter in BoostC help for more information. Regards, Pavel

Our MPLAB-X plugin has been available for a while. It's part of 7.05 release. Regards, Pavel

Keep copying I didn't realize that you don't use SourceBoost installation directory structure. You'll need to copy config, include and lib directories from SourceBoost installation directory into the same place where compiler is located. You also need to copy tdf.dll there (that's probably it). To me using compiler from it's installation directory sounds like a much simpler option as all required files are already there. Regards, Pavel