BoostC from the Fourm

From OpenCircuits
Jump to navigation Jump to search

Introduction[edit]

This is the extraction of useful info on BoostC from its forum. We hope it is the most useful information as it deals only with issues which lead to conclusions on information that might otherwse have been missed. Each extract starts with a link to the forum thread, read it in full if you wish. I have removed names and edited the text in a way that I hope makes it more readable. It is just a forum, the postings may be outright wrong, or out of date. The final product is mine ( I am responsible for posting the material ( check page history), I claim no ownership, nor am I responsible for the accuracy of the material or your results using it. ) If you object let me [russ_hensel] know, or fix it yourself. It is a wiki so others than [russ_hensel] may have added/edited the content. Not included:

  • Things unresolved:
  • Errors made by questioner
  • Compiler issues that should have been fixed by now or soon
  • Most hardware issues
  • Things that i think are covered in the manual
  • Documentation of most things you cannot do.
  • Notices of projects, websites.... we should have these in the PIC Links or some other place.
  • Things I do not understand.

2008 Extracts[edit]

User had problem geting consistent data reading and writing to an IO port: Response:

Sounds like the classic read modify write issue, when ports externally are being dragged down by whatever is connected to them. Remember that when a port is read on a PIC16 the actually logic level on the pins are read, not the last data written. This is not a problem on PIC18 if you use the LAT register as this actually holds the last data written.

Possible solutions: 1) Don't drag down the outputs with excessive load. 2) Use a shadow register to hold the data written to the port. 3) Use the LAT register, if it is available.

See "The Read-Modify-Write problem" for far more details.


Is This Technique Ok?, Implementing an array of function pointers .....

Russ says: do not understand well enough to summarize, someone else want to take a wack at it


You can use the standard C macros for time and date which will generate text strings for the date and time the code was compiled. (*Not* the current date and time at run-time). 

// CODE
char time[] = __TIME__;  // "16:38:53"
char date[] = __DATE__;  // "Nov 30 2008"


Question: I can understand that the isr may interrupt the 'main loop' at any point and hence (global) variables may be in a indeterminate state, but why can't functions be used in both isr and main routines.

Surely the sw stack is used for 'main' and 'interrupt' functions, so local vars so they should be safe while the isr is running??

A: Most PIC C compilers assign all local variables for a function to a single fixed "global" location (very different from C compilers for other CPUs).

Answer: The software stack (or memory overlay) means that all the memory useage on the "stack" has to be known at the time of linking the program. That makes functions that use the software stack un-interruptible or corruption will occur.


I am using the BoostC compiler using the MPLAB environment (to be able to use the ICD2) and am doing a project that uses a number of source files (11 or so C files at the moment) to keep it all nice and modular.

However, I can't seem to find any way of doing a 'make' of the project (i.e. only recompile changed source files).

There only seems to be a 'build' that explicitly deletes all object files and then rebuilds the whole lot!

Am I missing something? No. Thats the only option under MPLAB


Question: Does anyone know how to set the configuration for the PIC16F877A? In general, how do we know to set the configuration for any specific PIC, let's say PIC18F452?

Answers:

    • The 887 has a wizzard, use it.
    • Use any number of example programs out there.
    • Use a guide for assembler, port.bit = xxx or set_bit clear_bit are easy to translate.
    • pragma s are used for some settings rtfm
    • be prepared to be amaized at how many mistakes can be made.


GPIO is not currently supported by the PIC simulator. Its on the todo list, but we haven't got round to it yet


Using a library[edit]

To add a library to your project, goto the Workspace (project) window (left of screen usually), right click and add the .lib file you want to include.

Also #include the corresponding .h file in your source.

Remember: If you use #include <test.h> , the compiler expects the .h file to be in the ...\SourceBoost\include directory. Use #include "test.h" if the header is in your local project directory. Or just use the full path name.

Building a library[edit]

To build (compile) a library, goto "Settings -> Options...", select Output Type: Library radio button.

I think left out a subtle point in that most libraries need not only a .lib but also a .h which defines the function prototypes that the library contains. Then, the user of the library would also #include the .h file in the source that is using it so that the compiler knows what to expect. This is the same as if you have multiple files in a stand-alone compile.

KeyLib.h

Header files (.h) are not generated automatically. You have to build them yourself.

Open a blank page. Insert you function prototypes as trossin says (char ScanKeyMatrix(void). Save the file as test.h

You now have your .h file to match your .lib file.


linker options[edit]

Settings -> Options -> BoostC compiler Options -> Extra linker options. What you add in the extra linker options is appended to the regular linker command line. You can append anything you want


It is not be possible to alter configuration words from the bootloader context. That is your program should have the same configuration as the bootloader.


This looks like well documented but included as a gotcha. Have you tried reading the GPIO ports before clearing the interrupt flag GPIF? The port has to be read to end the change mismatch condition otherwise GPIF will just set itself again (page 21 of data sheet).


...Is it not possible to get quick access to bits in an array?... No it's not. You have to use good old bitwise operators.


I had the UART on my USB/Serial thinger configured for 3V. That makes sure it does not work correctly gotcha.


All features supported by SourceBoost IDE built-in simulator are listed in Users Manual. So anything NOT listed in the Users Manual (such as the Comparator), is NOT supported in the Simulator.


Well as it turns out, once you come back from interrupt, the ports doesn´t retain the original configuration( analog comparators get turn on when they where off before interrupt). So now, I turn comparators off again, and load values in porta and portb, before coming back from interrupt. Also I put a "while" loop in the interrupt service routine, to compare the value that portb should have with no key pressed, so if the key still pressed I scan the keyboard again BEFORE leaving the interrupt service routine. As soon as I have the time I think I´ll upload a post on dealing with wake up from sleep on interrupts, because I think it might benefit beginners like me.


I have a mystery. After using BoostC for some time all of a sudden there's no *.map file generated Boostc compiler and linker has never generated a map file. The best option is to look in the *.lst file to find where everything is.


The BoostC compiler does not currently support PIC18 Extended instructions. This may change, rtfm.


Post- and pre-build steps are now implemented in our working ide copy and will be available in the next release. It will work like this: when build command is issued IDE first looks in the project directory for a file called prebuild.bat and if found executes it. At the end of a successful build IDE looks in the project directory for a file called postbuild.bat and if found executes it. It's up to a developer to create those files. If such files don't exist build goes how it used to do. -- Should be implemented by the time you read this.


BoostC does not have much of a stimulus, but wait: there is the signal generator in the extra plugins. Some devices have full ADC support and so the signal generator can be used on those with the ADC. Also the signal generator can be connected to digital pins to provide other stimulation. Also highly exact timings can be had with the stopwatch plugin.


Boostc doesn't support 12 bit instruction PICs. See the list of supported devices to see what is supported, it is a lot.


Q: The problem is that Debug Express reserves RAM, as well as some program memory, for its own use. e.g. on the 16F887 it reserves 0x070, 0x0f0, 0x165 to 0x170 inclusive and 0x1f0. (These are shown as RR in the MPLAB IDE file registers window). On larger projects requiring more RAM BoostC has no knowledge of these reserved locations and simply overwrites them. Does anyone know the best way, if there is one, of reserving these or any other locations to prevent them being used by BoostC?

A: Declare fixed address variables at the locations you want to protect. BoostLink will work around any fixed address variables.

Something like this would fit the bill: 

 char reserved_0x070 @ 0x070;
 char reserved_0x0F0 @ 0x0F0;
 char reserved_0x165[ 11 ] @ 0x0165;
 char reserved_0x1F0 @ 0x1F0;

I extracted the above but do not quite understand it, you may want to refer to the original post.


...Is it not possible to get quick access to bits in an array?... No it's not. You have to use good old bitwise operators. The "<<", ">>", "&", and "|" operators.


When a project contains multiple source files, is there a way to compile a single file? You can try using "Project -> Quick", then select the source (.c) file you are interested in, and a mini project will be created containing only that single file. When you are done, just delete the mini project file and go back to the main project.


I am going to use the float.h and float.pic18.lib files. Since I am going to calculate floats and I need to represent them on a LCD display, I have only one idea to work-around the missing "%f" in the lprintf format; I multiplicate the float variable by 10 (for example, needing only one decimal digit), convert it into long variable and then calculate the integer part (with sign) and the decimal of that long variable. That should give me more possibilities to show a float-to-long variable on LCD... Any other ideas?

This basically does what you suggested. Just format the intPart and fracPart with a decimal point between into a string. 

void main(void) {
    float    myfloat;
    int32    intPart;
    int32    fracPart;
 
    myfloat = 3.14;
     
    intPart = float32_to_int32(myfloat);
    fracPart = float32_to_int32(float32_mul(float32_sub(myfloat, float32_from_int32(intPart)), 10.0));
}


I ran into a 'bug' in the PIC part itself. I found the solution here: http://forum.microchip.com/fb.aspx?m=306403 The 16F88 and a few other chips become unprogrammable if you use MCLR as an IO pin, you use the internal osc, and you set TIMER1 to use the internal osc as a clock source. If you do all three, you can no longer program the part. The post gives the solution to recovering the chips.


I'm trying to read the tmr0 register using this chunk of code, called on INT interrupt: 

  ....
  pulse_timer1 = TMR0;
  ....

the line "pulse_timer1 = TMR0;" will place a 1 in the (unsigned char) pulse_timer1 register, no matter what the value of TMR0 is. mmmm capitals.... It works if I use tmr0, not TMR0. The PIC's include file has TMR0 in upper case, so I'm a bit confused there!

TMR0 is the address of TMR0 register. tmr0 is a variable that is declared to have address TMR0. So when you access the tmr0 variable you access the registers value, and not its address. Also note that a convention is that volitle variables ( which can change outside of code ) are always lower case.


On the forum to format as code use [code] followed by your code and then ending with the same thing except end with /code in brackets. ( on the wiki have a least one space at the beginning of the line ) It then looks like this: 

    unsigned char ix;


The library code for one wire library use the nop() instruction. They should rewrite this lib because now it´s not working with different clock frequency. A work around is to run goodies if you have pro licens and change the code your self. Or you can download the lib code from lika.be

Not sure about the above, you many want to see the original post


Using BoostC version 6.85 should I be able to initialize the following structure? 

const struct {
    unsigned char NAME[4];
    unsigned char DAYS;
} MONTH[13] =  {
        "   ", 29, 
        "Jan", 31,
        "Feb", 28,
        "Mar", 31,
        "Apr", 30,
        "May", 31,
        "Jun", 30,
        "Jul", 31,
        "Aug", 31,
        "Sep", 30,
        "Oct", 31,
        "Nov", 30,
        "Dec", 31
    };


The above approach results in "error: can't assign string to 'struct' variable."

Complex initialisation like the above are not supported in current BoostC release. We plan to add support for it in the coming release. Meanwhile the workaround is to initialise variables outside of declaration like: 

 ...
 strcpy( MONTH[1].NAME, "Jan" );
 MONTH[1].DAYS = 31;
 ...

May want to check the manual to see if this change has been made ( if you find it, why not fix the wiki here? ).


I have a small asm program for a 12F675. It's a light sequencer for those that must know ;-) The C version is completely unoptimised, it uses a big ol switch statement that is easy to read. The C version was MUCH easier to write only a few bytes bigger so it will be to version I keep. 

 Anyway, the asm (MPASM) version is;
 Data Memory, 11 bytes
 Program memory 231 bytes



 The sourceboost version;
 RAM available:64 bytes, used:32 bytes (50.0%), free:32 bytes (50.0%), 
 Heap size:32 bytes, Heap max single alloc:31 bytes
 ROM available:1024 words, used:277 words (27.1%), free:747 words (72.9%)

So BoostC does a good job without much fuss.


for a disucssion of serial comm in software ie: Pic16f628a Serial Usart. Use the link.


Well, conveniently SourceBoost has a header file called "rs232_driver.h" which will do serial data communication pretty well! Now, unfortunately this is not generalised for any PIC and the 16F628A isn't one of the ones it is configured for. Don't worry. This isn't that bad an issue, but it will involve some research on your part. There is a sample rs232 project that you should look at first at SourceBoost/Samples/BoostC/SerialTest.__c. It is configured for the ... PIC18F452. Now. It looks all confusing at first with the preamble before main, but open up the datasheet for the PIC and reverse-engineer where it got the register locations, and then try to translate that to your own PIC. If you search for rs232 on this site I know someone made it work for the PIC16F627 so you might be able to use that as another reference on how it was translated.


When I link my project in sourceboost it links succesfull with still remaining 3 free bytes for code (.. ) When I link the same thing within the MPLAB it fails: "Too much code to fit in ROM, overfilled by:27 locations."

I copied the linker options from the sourceboost IDE in MPLAB IDE. When I look at the linker execution lines sourceboost added extra options however which probably causes extra optimization when linking.

Answer: The final binary is affected by the order the modules are linked together in because that affects their placement in memory, and hence may cause some jumps to cross code page boundaries. The order the modules are linked under MPLAB is different to that under SourceBoost IDE.


How do I unlock the library and goodies files. I bought the ProVersion especially to get a hold of the library.

Answer: Goodies require a separate key. This key is sent free of charge to all BoostC Pro and BoostC++ Pro license holders. Goodies key is generated manually so usually there is a short delay between sending a mail with compiler key and another email with goodies key.


Reference To Volatile Variable you will need to read this one yourself, extract it here if you get it


A library is a precompiled binary file that means the compilation of the library code is only required once.

To create a library: 1) Create a header file containing function prototypes. 2) Create a .c file containing the implementation of the functions. 3) Set the Compiler options->Compile options->Output Type to Library. 4) Build the code. If successful a .lib file is produce.

To use a library: 1) #include the library header file in any source file that will use any of the library functions. 2) Add the .lib file to the project. 3) Build the code to link in the library.


I like getting hex values when using Hover in the dubug mode, as shown in IDE User's Guide. I'm getting octal numbers.

Answer: Settings -> Options -> Debugger -> Default watch format


I have been caught out recently by not reading the errata sheets, which Microchip have plenty off. Look at the Rev A1 sheet for the 18F4520 issue #23. It explains problems with fast interrupts which may give random operation.

I should have said before, try using the linker option -isrnoshadow, which uses RAM to save the important registers rather than restore from the shadow registers (fast) for high priority interrupts. Dave and Pavel have been here before.


Standard practice is when prototypes go to headers and implementation to sources. The only exceptions are inline functions and templates. The reason for this is that for both compiler needs to know their implementation every time such functions get called.


discussion of functions in interrupts, debouncing in various ways, see the post.


I did not get this one, read it your self, perhaps you can summarize here.


  • From:

Is there a way to force a variable to be allocated in a specific bank? Yes, by giving it a specific adress, eg 

 char z@0x43;

I can give any arbitrary value and this will not collide with other variables? I need this in the ISR, so that more efficient code is generated.

I have sometimes seen that the amount of code decreases while I added some code and the other way around. Could this be explained by another distribution of the variables over the banks?

I can give any arbitrary value and this will not collide with other variables? RAM locations that have associated variables with fixed addresses are not used by the compiler for any other use, so they won't collide unless you have another piece of code that uses a fixed address variable at the same address.


Issue is location of code and jumps to code when using a bootloader. One answer was: I use this bootloader - it automatically fixes the short jump to a long jump. http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm Other bootloaders may also do this, perhaps the one at PIP Pack. And/or read the whole post.


soft uart, read it for more info, think may a soft uart in the library support from BoostC.


I want to use the mplab debugger for a project. Is there a way to convert\integrate existing project file(s) to mplab or do I really have to build separate mplab projects from scratch?

Answer: Put your source files in a new directory(or not).Open MPLAB, start a new project(project(new)), give it a name, tell it the directory where your files are located. This will create the project. Now add your files. You'll need to make sure you point MPLAB to your compiler and linker(project(add language toolsuite)). Ctrl+F10(build)

2007 Extract[edit]

BoostC Forum Extracts 2007

Retrieved from "http://www.opencircuits.com/index.php?title=BoostC_from_the_Fourm&oldid=77825"