BoostC from the Fourm

Introduction

This is the extraction of useful info on BoostC from its forum. Each extract starts with a link to the foum thered, 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 thnik 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

• From: http://forum.sourceboost.com/index.php?showtopic=3909&pid=14605&mode=threaded&start=#entry14605

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.

• From: http://forum.sourceboost.com/index.php?showtopic=3896

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

• From: http://forum.sourceboost.com/index.php?showtopic=3895&pid=14515&mode=threaded&start=#entry14515

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"

• From: http://forum.sourceboost.com/index.php?showtopic=3877&pid=14436&mode=threaded&start=#entry14436

Question: I can understand that the isr may interrupt the 'main loop' at any point and hence (global) variables may be in a inderterminate 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.

• From: http://forum.sourceboost.com/index.php?showtopic=3871&pid=14426&mode=threaded&start=#entry14426

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

• From: http://forum.sourceboost.com/index.php?showtopic=3862&pid=14378&mode=threaded&start=#entry14378

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.

• • also see: Gotchas http://www.piclist.com/techref/microchip/gotchas.htm and Tips and pitfalls http://www.voti.nl/swp/index.html and LIST OF Most common errors with PICs http://www.micro-examples.com/public/micro...c/205-faqs.html

• From: http://forum.sourceboost.com/index.php?showtopic=3762&pid=14225&mode=threaded&start=#entry14225

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

• From: http://forum.sourceboost.com/index.php?showtopic=3854&pid=14343&mode=threaded&start=#entry14343

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

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.

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.

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.

• From http://forum.sourceboost.com/index.php?showtopic=2704&pid=14026&mode=threaded&start=#entry14026

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

• From http://forum.sourceboost.com/index.php?showtopic=3687&pid=13897&mode=threaded&show=&st=0

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.

• From http://forum.sourceboost.com/index.php?showtopic=3689&pid=13901&mode=threaded&start=#entry13901

This looks like well documented but included as a goctgha. 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).

• From: http://forum.sourceboost.com/index.php?showtopic=3591&pid=13546&mode=threaded&start=#entry13546

...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.

• From: http://forum.sourceboost.com/index.php?showtopic=3670&pid=13847&mode=threaded&start=#entry13847

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

• From: http://forum.sourceboost.com/index.php?showtopic=3669&pid=13792&mode=threaded&start=#entry13792

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.

• From: http://forum.sourceboost.com/index.php?showtopic=3649&pid=13765&mode=threaded&start=#entry13765

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.

• From: http://forum.sourceboost.com/index.php?showtopic=3658&pid=13746&mode=threaded&start=#entry13746

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.

• From: http://forum.sourceboost.com/index.php?showtopic=3644&pid=13713&mode=threaded&start=#entry13713

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

• From: http://forum.sourceboost.com/index.php?showtopic=3588&pid=13562&mode=threaded&start=#entry13562

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.

• From: http://forum.sourceboost.com/index.php?showtopic=3602&pid=13596&mode=threaded&start=#entry13596

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.

• From: http://forum.sourceboost.com/index.php?showtopic=3598&pid=13576&mode=threaded&start=#entry13576

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

• From: http://forum.sourceboost.com/index.php?showtopic=3593&pid=13553&mode=threaded&start=#entry13553

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? 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.

• From: http://forum.sourceboost.com/index.php?showtopic=3591&pid=13546&mode=threaded&start=#entry13546

...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.

• From: http://forum.sourceboost.com/index.php?showtopic=3590&pid=13539&mode=threaded&start=#entry13539

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.

• From: http://forum.sourceboost.com/index.php?showtopic=3587&pid=13523&mode=threaded&start=#entry13523

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));
}

• From: http://forum.sourceboost.com/index.php?showtopic=3577&pid=13494&mode=threaded&start=#entry13494

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.

going on

http://forum.sourceboost.com/index.php?showtopic=3574&pid=13469&mode=threaded&start=#entry13469

Hi, my problem seems pretty simple, but has stumped me....

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

CODE // PULSE INTERUPT ==================================

void pulse_int (void) { unsigned short temp_short;

   clear_bit(intcon,INTF);
   if (pulse == 1)
   {    pulse_timer1 = TMR0;

SNIP

the line "pulse_timer1 = TMR0;" will place a 1 in the (unsigned char) pulse_timer1 register, no matter what the value of TMR0 is.

Can anyone think of a reason for this?

I have been using TMR0 in this program successfully, it is incrementing and giving the TMR0IF normally. The only problem is that I can't write it's value to another register.

Group: EstablishedMember Posts: 6 Joined: 14-March 08 Member No.: 4,102

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!

Dave Mar 26 2008, 12:42 PM Post #3

Super Maniac

Group: Administrators Posts: 1,610 Joined: 28-September 04 From: UK Member No.: 469

julian265, QUOTE (julian265 @ Mar 26 2008, 10:49 AM) 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! Capitals are used for constants. 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.

Regards Dave

http://forum.sourceboost.com/index.php?showtopic=3570&pid=13455&mode=threaded&start=#entry13455

The secret of how to do this:

CODE what{

      indent

}

is to use [code] followed by your code and then ending with the same thing except end with /code in brackets.

As far as your problem is concerned, how big is your transmit buffer and how long of a string are you sending. 9600 baud is pretty slow, about 100 characters/second. Also, Why are you calculating parity. I thought the UART did this for you while you are sleeping? The data sheet will have the secrets. I'm not sure what device you are using but I wrote ASM code for the 16F628 to do the buffered RS-232 receive for a little LCD terminal project. (http://www.geocities.com/ted_rossin/Electronics/Pic/Pic.html#LCD%20Terminal or http://www.geocities.com/ted_rossin/Electronics/Pic/Pic.html if the previous link is messed).

If your buffer is 10 characters and you shove a string longer than 10 characters at it, you will most likely overrun your buffer and have your string chopped off. The delay you add plus all the code you execute may be enough to slow the buffer fill rate down low enough to get longer strings out. At least, you should try using a buffer of 10 bytes and see if it is rock solid sending strings of 9 characters with a wait of 100ms between each string sent. You should not need the 1ms wait for each character.

---

http://forum.sourceboost.com/index.php?showtopic=3571&pid=13459&mode=threaded&start=#entry13459

Hello, The libary code for one wire library use the nop() instruction. They should rewrite this lib becasue 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

---

http://forum.sourceboost.com/index.php?showtopic=3566&pid=13440&mode=threaded&start=#entry13440

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

CODE 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."

Help or pointers will be appreciated.

Thank you, Carl Petito Interested in advertising here? Contact support@sourceboost.com

Replies Pavel Mar 19 2008, 10:50 PM Post #2

Maniac

Group: Administrators Posts: 994 Joined: 6-July 04 From: Melbourne, Australia Member No.: 424

Complex initialisation like you use is 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:

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

Regards, Pavel

---

http://forum.sourceboost.com/index.php?showtopic=3556

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;

Memory Usage Report

=======

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%)

Keith Corvette Engineering

---

http://forum.sourceboost.com/index.php?showtopic=3496

direct people to read this for usart lib info

Pic16f628a Serial Usart  

---

and more

5th February 2008 - 09:06 PM Last post by: eckertc http://forum.sourceboost.com/index.php?showtopic=3494&pid=13143&mode=threaded&start=#entry13143

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.

stopped on the one above