Should I move from Pic SourceBoost to XC8? - Page 1
Forum section: electronics / general

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 08, 2013, 09:33:49 pm
content: HiI have a contract to fix some bad microchip 8 bit code. Pic16f90 and one other similar pic.It was originally compiled using SourceBoost.I have never used Pic before but the code compiles ok, the free version of SourceBoost doesn't link it though, due to size constraints.Sourceboost looks completely antiquated, especially the programmer (with a default MFC program Icon), compared to MPLabX.What compiler should I choose, I am not worried about porting it to use XC8 libraries as I have done plenty of porting and a fair few code changes are needed.The client will have to spring for the compiler, but I want to keep costs down. I didn't check how close I was to the Flash limit, but I am guessing there is a bit of space.Having a simulator, or debugger would be good. Especially with 8bit code.Any suggestions.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 09, 2013, 01:35:55 pm
content: Bump, anyone got a view on this?Does anyone use SourceBoost, or should I dump it and use MPLabX?

author: JTR
author_rank: Regular Contributor
timestamp: March 09, 2013, 02:05:56 pm
content: Why not use sourceboost within MPLAB X? There is a plugin for it and you get all of MPLAB X's features without having to alter the code. The full version of sourceboost is substantially cheaper than a licensed version of XC8 and given how bloated the unlicensed version of XC8 is you probably will need the paid for version.Edit: Typo, XC6 - > XC8

author: ecat
author_rank: Frequent Contributor
timestamp: March 09, 2013, 02:42:03 pm
content: I used SourceBoost a few years ago and it does the job. My lasting impression was one of quirkiness and dodgy syntax checking but the final output worked. I've not used it since as given the choice between SB + 16f or MPLab + 18f I'd go MPLab every time and now MPLab has XC8... Well, I've not tried it so cannot comment.Why not spend a couple of hours and try them both?The good thing about SB in your case is the base source code remains unchanged so no matter what you do you always have a base reference of known functionality to return to and you are not in the position of having to recommission the entire system from scratch. From the customer's perspective, all the code and functionality that works should remain working, this is important. From your perspective, you can save yourself a lot of headache and many hours investigating what may be external influences by not changing the code.At the end of the day the choice should be made by the customer, it is your job to make them aware of the pros, cons, costs, risks and time scales associated with each option. After that your job is to deliver on your promises.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 09, 2013, 03:32:42 pm
content: If you're moving something to another tool, going for the manufacturer's 'standard' one is generally the best approach as it gives the best chance of long-term maintainability. You don't want to be repeating the process when some other oddball tool ceases to exixt/be capable/be supported etc.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 09, 2013, 11:08:19 pm
content: Thanks for all the suggestions. Much appreciated.I have been playing a little bit with the free versions of both SourceBoost and Xc8.I have just read a lot of people complaining about the free version of Xc8.I was also worried that nobody seemed to be using SourceBoost.I think I might try the SourceBoost plugin, I really want the MPLabX simulator if possible, the IDE is nice too. It seems to be that with 8bit code and new compilers, I find things aren't always as they seem.Maybe a fall back option is to try a quick port to Xc8, obviously the codebase isn't huge.and lastly just use SourceBoost.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 10, 2013, 10:32:06 am
content: I failed to get the SourceBoost plugin to plugin, spent a couple of hours on it. <sigh>Oh well it's either SourceBoost IDE or MPLabX and Xc8. Not the plugin.This guy had my exact problem but his fix didn't work for me.QuoteIt might have something to do with SourceBoost not integrating properly with MPLabX when I installed SourceBoost. It said it couldn't find MPLabX's language suite.Anyway no matter If I really need it I can sort it out then.

author: poorchava
author_rank: Super Contributor
timestamp: March 11, 2013, 12:12:44 pm
content: XC8 is utter crap. It has some nice features compared to C18 (like human friendly interrupt coding scheme) but it's crap anyway. Free version inflates the code artificially (or generates shitty code on purpose) in order for them to later brag about how paid versions reduce code size by XX%. This sucks especially if your target is a relatively small device. On top of that it includes huge amount of header files which it then has to evaluate, and this causes programs to compile excruciatingly long (my example 12kB on PIC18F4553 is anywhere from 22 to 29 seconds on Core2Duo 2.13GHz). Microchip is digging their own grave with such practices.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 11, 2013, 10:16:17 pm
content: Thanks poorchava, but what compiler do you suggest?I think code size based restrictions would be better than compiling deliberately badly.Has anyone used SDCC or any other compiler for a pic16?Actually I'd like to throw the whole thing away and use ARM Cortex but I don't think that is going to happen in the near term.

author: David_AVD
author_rank: Super Contributor
timestamp: March 11, 2013, 11:26:15 pm
content: I'd also prefer a size restriction over code bloat. I'm thinking of buying XC8 but only at the start of my C programming journey.

author: poorchava
author_rank: Super Contributor
timestamp: March 12, 2013, 08:53:43 am
content: QuoteAnd that's what I am doing. I have switched from C18 to XC8 for the current project I am doing, but this is definitely last one with Microchip MCU inside. And lack of useful compiler for free is not the most important reason.I'm going for ARMs. I have been using PICs only because Microchip was sending samples for free. No way in hell I would pay that amount of money for such crappy silicon. Especially that i.e. LPC1111 costs exactly $1.73/pc @ 10pcs and has like an order of magnitude more power than any 8-bit PIC. And has totally free development chain, which is not all that hard to setup (took me like 2 evenings starting from scratch to code, compile, program and debug STM32VLDiscovery)SDCC is in work-in-progress phase for Microchip, which means it will work reasonably in a fefw years for more popular models.Mikroelektronika is fine, but commercial (and $250 is a lot of money for me, not willing to spend it on a compiler). On top of that they don't support Pickit 2/3. That sucks, because Pickits are really amazing debuggers for their price. Maybe it's possible to somehow write in mplab, compile in mikroe and then debug in mplab, but I don;t know how to do it.Obviously Keil, IAR and such also have compilaers for PIC18, but I haven;t tried those.

author: Unknown
author_rank: Unknown
timestamp: March 12, 2013, 10:38:57 am
content: Quote from: HackedFridgeMagnet on March 09, 2013, 01:35:55 pmI suppose it depends on how much of the chips 1k space is used; if it's been squeezed to the max with a very good optimizing compiler you might have problems with lesser compilers; so you might want to check the code limit.1K isn't many lines of C code; i'd try the free SDCC; although don't expect a nice IDE with a nice icon.I'm not a big fan of the clunky MPLab IDEs etc, I much prefer a code editor and to learn the compiler switches, then create my own custom build scripts, which you can then fire from hotkeys. I guess I've just wasted too much time in the past trying to get them to work with 3rd party compilers that I just don't even bother anymore.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 12, 2013, 11:20:53 am
content: Quote'1k' You gave me a fright then!I meant the Pic16f690, not the fictitious Pic16F90, sorry.The datasheet says the 16f690 has 4k of words and the words are 14 bit. That seems a bit more realistic.I think I have a bit of a chance to shrink the code too as it seems the original code is written by a desktop programmer. No real string stuff either.I will give SDCC a go, but I must admit out of all the technologies I have ever used makefiles give me the most grief.

author: Unknown
author_rank: Unknown
timestamp: March 12, 2013, 12:27:39 pm
content: Quote from: HackedFridgeMagnet on March 12, 2013, 11:20:53 am1. Install Gputils and SDCC2. Create a source called "main.c" but obviously change the config and headers etc.Code:#include "pic16/pic18f4550.h"#include <stdint.h>#pragma preproc_asm-typedef unsigned int config;#pragma config PLLDIV=1, CPUDIV=OSC1_PLL2, USBDIV=2, FOSC=HSPLL_HS, FCMEN=OFF, IESO=OFF, PWRT=OFF, BOR=OFF, VREGEN=OFF, WDT=OFF, WDTPS=1, PBADEN=OFF, LPT1OSC=OFF, MCLRE=OFF, STVREN=OFF, LVP=OFF, ICPRT=OFF, XINST=ON, CP0=OFF, CP1=OFF, CPB=OFF, WRT0=OFF, WRT1=OFF, WRTC=OFF, WRTB=OFF, EBTR0=OFF, EBTR1=OFF, EBTRB=OFFvoid main() {TRISC = 0x00;while(1) {PORTCbits.RC7 = ! PORTCbits.RC7;}}3. Compile it to a hex to burn with a makefile like; or just write a batch file. Codeblocks supports SDCC if you can get that up a running.Code:# Makefile for PIC microcontrollers using sdcc# Specific microcontroller type:DEVICE=18f4550FAMILY=pic16PRJ=main# Compile and AssembleCC=sdcc --use-non-free -m$(FAMILY)# PK2=pk2cmd -Ppic$(DEVICE)All: $(PRJ).hex$(PRJ).hex: main.c$(CC) -p$(DEVICE) $(PRJ).cwrite:# $(PK2) -M -F$(PRJ).hexon:$(PK2) -Toff:$(PK2) -Werase:$(PK2) -Eclean:rm -f *.o *.cod *.hex *.lst *.errNot sure if that helps but it might give you a head-start! ;-)

author: dfnr2
author_rank: Regular Contributor
timestamp: March 12, 2013, 04:42:25 pm
content: If you are doing this as a professional job, and the client is offering to pay for the compiler, then your best option by far is to use the XC8 PRO compiler. It's actually inexpensive as far as professional grade compilers go, less than when it was Hi-tech. You get free updates for life. The XC8 compiler will generally produce tight code. However, you should be in the habit of inspecting the output regardless of the compiler you use. Your client is offering to pay for the compiler because they want a stable platform with predictable behavior. It's worth it to them. And if you are stuck with a particular PIC part and can't easily switch it out, then it pays to have a compiler that generates tight code.My main gripe about the XC8 compiler is that it doesn't support inline functions, which can be very helpful in controlling stack depth on these tiny PIC16 stacks. The workaround is to use macros, but that's an imperfect solution.For the PIC18 series, I recently used C18 instead of XC8, because XC8 is new, and the applications libraries are not yet ported. C18 worked fine, but XC8 produced tighter code, and has better error reporting.When comparing a compilers, consider how the vendor manages regression testing and releases, tracks bugs and fixes, etc. Some compilers such as CCS are very nice but fail in those areas.

author: David_AVD
author_rank: Super Contributor
timestamp: March 12, 2013, 09:29:42 pm
content: Quote from: dfnr2 on March 12, 2013, 04:42:25 pmThe XC8 manual says it supports them but may not be obeyed in some circumstances?

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: March 12, 2013, 11:07:43 pm
content: https://www.eevblog.com/forum/microcontrollers/good-sdcc-for-pic-tutorial/Had a go with SDCC, it was ok but I would have to do a port anyway to use it. There were a few warnings in that other thread too.So I will go with SourceBoost, I cut down the code to 2k words to see if it compiles and links, with the free version and it does.It was actually easy to cut down as there were a kazillion nop();s due to gratuitous bit banging.After linking I am left with a heap size of 17 bytes.What am I to do with such riches? <sarcasm>Thanks for the input from all the posters, it helped a lot, and I will promise I will keep checking the output for compiler idiocy.

author: JTR
author_rank: Regular Contributor
timestamp: March 13, 2013, 12:00:54 pm
content: I think you have saved yourself a lot of grief going this way. I thought it the best option rather than trying to butt heads with the currently half baked XC8.