PIC C compilers

[edeca]

I'm getting a little fed up of BoostC, constantly running into problems like this:

**broken link removed**

Which is a real shame, as I was close to handing over some money to purchase it.

I've just downloaded mikroC to have a play, I have no idea on code limits/optimization/cost yet so can't make a comparison. But boy does it seem to have a lot of library routines.

What other compilers should I look at?

 

[jimlovell777]

I'm a fan of SDCC and formerly Hi-Tech PIC C.

 

[Mike - K8LH]

Hi edeca,

I placed my 96x7 font table in ROM at address 8192 (0x2000) using a #pragma DATA 8192 statement and access it after setting up the "tblptr" registers like this (BoostC);

 //
 //  tblptr = (charval-32)*7+8192
 //

   void setpointer(unsigned char val)
   { asm {
     movlw   32              //
     subwf   _val,W          //
     mullw   7               //
     movf    _prodl,W        //
     movwf   _tblptrl        //
     movlw   32              //
     addwf   _prodh,W        //
     movwf   _tblptrh        //
     clrf    _tblptru        //
     }
   }

 

[Pommie]

There are no compilers that implement ROM pointers on the 16 series chips without writable flash. This is because it's impossible to implement such a pointer. It'll be interesting to see if they implement ROM pointers on the 16 series with writable flash in version 7.

Mike.

 

[edeca]

Thanks Mike (K8LH), I'll have to look at that code and try to get my head round it. I use C to avoid the ASM! But I do like being able to access all the registers to configure hardware, I don't necessarily like a total "black box" set of library routines.

Pommie, I am using an 18F chip, is that "16 series"?. Unsure exactly what you mean by your comment, but the thread now definitively says BoostC will have this in v7. I don't know enough about the internals to understand how it works.

I was cranky last night as I finally understood most of your GLCD code and had got it ported over, only to get stuck on the font. I had hoped to rewrite portions of your code to cope with multiple fonts (big/small/fixed width etc) but the array issue was a roadblock.

For what it's worth the price of MikroC probably puts it out of my price range for hobby purposes, so I'll keep playing with others and see where I get.

 

[Pommie]

As you are using an 18 series chip, why not use the free C18 compiler from Microchip. It's free and without memory restrictions.

Mike.

 

[edeca]

I looked at it before and didn't get on with the syntax. I evaluated it for a while and seemed to get up to speed with BoostC much quicker.

I really should look again, especially as I've spent a while converting your perfectly good GLCD code to BoostC, where it doesn't currently work!

 

[EN0]

C18 honestly isn't that bad, have you ever tried it with MPLAB?

 

[edeca]

C18 honestly isn't that bad, have you ever tried it with MPLAB?

As someone with 2 weeks experience I'm not sure I trust you implicitly! However, I am going to see how long it takes me to port my previous code to C18.

PORTAbits.RA1

Ugh, horrible syntax

 

[EN0]

I've never tried other compilers so I wouldn't know.

Hope it works out for you.

 

[AtomSoft]

PORTAbits.RA1

actually makes tons on sense... PORT A BITS (R A 1) READ/WRITE PORTA BIT 1

LATAbits.LATA1 = LATCH A BITS (L A 1) LATCH PORTA BIT 1

Some compilers like CCS have PORTB.B0 which to me is ok also... If you are lazy then simply (LED is example name)

#define LED PORTAbits.RA1

Then do LED = 1 or something

 

[edeca]

Well I just tried HI-TECH C. Took a little while to move the code over but their GUI is really nice. Also no code limits, but with no optimization either.

Now have it working, with a proper 2D array. Took perhaps 1 hour of concerted effort and I have text on the screen. It is currently inverse for some reason (blue on white, not white on blue) but I can fix that easily.

Will wait to make a proper conclusion after I've played with I2C and serial routines, but looking at it I might ditch SourceBoost in favour of HI-TECH.

 

[Mike - K8LH]

Hi edeca,

I gave up on the free/lite version of the Hi-Tech product because the "unoptimized" code it produced was terrible. Has that changed or are you considering purchasing the "full blown" version?

Regards, Mike

 

[AtomSoft]

From a hobbyists perspective optimization doesn't matter, as long as it works

 

[Mike - K8LH]

I'm a hobbyist and I seem to "push the envelope" all the time so it matters to me (LOL)...

 

[AtomSoft]

Now if its your job thenbyou or you company should shell out the cash for one with optimization

 

[edeca]

Atomsoft, optimized code can matter a lot. For example, the delay routines that come with HI-TECH explicitly say that they should be compiled with optimization. In many cases small variations will not matter (if you care about 255ms vs. 250ms, use a crystal and the timer!) but this is just one example of where unoptimized code isn't as good.

Mike, I was going to install the 40 day trial of the "pro" version and do a comparison between the generated code. It will be a shame if it is hugely inefficient but faster PICs with more ROM/RAM are cheaper than most compilers!

At the moment the fact is has an amazing GUI, is unrestricted on data size and accepts sensible constructs (such as 2D array) without mucking about means it is winning. The syntax is quite attractive too, but somebody pointed out to me last night that code is not art and function is more important than form

I'm sure I'll find a reason to fall out with it soon enough!

 

[AtomSoft]

If you need precise delays i would suggest inline ASM and some basic debugging. No optimization needed.

Um.. Can you pot some sample hitech code for lets say blinking a led?

 

[AtomSoft]

Erase me erase me erase me erase me

 

[AtomSoft]

Erase me erase me erase me erase me