Q: using MCLR for Input on 12F683

[tenaja]

I was looking in to C compilers last year, and got some great feedback from a guy whose job requires him to be familiar with just about every pic compiler. (His feedback was offline, because he could not post his opinions public for the same reason he knows about all of the compilers. I am going to respect his anonymity.) Anyway, his advice regarding Mikroe and their compilers was to avoid them, for a variety of reasons. (Which mostly boiled down to "you get what you pay for.")

I own PBP, and find it a great compiler for people wanting to step up from Stamps. I mostly use Proton Basic (PDS), however, because it compiles much more compactly (about 20%) and runs faster. It's only $165, and even comes with a simulator that allows you to step through your code and debug much faster. The sim is limited to a couple chips and a couple development board models, but that allows you to test routines without messing with hardware. (I purchased the full sim so I can create just about any circuit I can think of--but that is not cheap.)

For the most part, you get what you pay for in compilers. Comparing PBP to PDS, they are very similar (they both used BS2 as a base), but PDS is more powerful. The same guy mentioned above said PDS "is as close to coding in asm as it gets for any pic compiler." The biggest difference is that PBP is a little more oriented (better oriented?) towards beginners because it has fewer features to trip you up. PDS has a larger command set, and built in interrupt context saving. The parser is better with PBP, so you can string together many math equations on one line with lots of parentheses to make it readable...but if you separate them out and use PDS, your code will be a LOT smaller.

[rmteo]

Would you care to share the reasons why your guy said to avoid mikroE?

[tenaja]

This is what he said that I can share: "mikroC has a good support of internal libraries but the binary code is not that optimized". Like I said, the rest boiled down to "you get what you pay for." If you want cheap, you get cheap... either minimal features, buggy or bloated code. Nobody makes a compiler that is bug-free, optimized, and feature-full.

And, more importantly for me, I use the Proteus PIC/Spice simulator for debugging my code, and the Mikro compilers put out a proprietary format (not a standardized format), so it is only useful for use with their own debugger.

You can always use PicBasic (instead of PicBasic Pro), which is a lot cheaper, and almost certainly bug-free... but it has minimal features and no optimization. There's also the free Pascal-like compiler, JAL: http://www.voti.nl/jal/

[mister_e]

while cheaper is not always better, even if you pay a single full license for Hi-Tech C (more than 2K) but cover ALL PIC familly (from 10F to Dspic, PIC32), you won't have the peace of mind. Most of those I know of, have now moved on Microchip ones. OK they're still expensive, but they seems to be better with years than Hi-Tech (That's what i've heard and experimented myself awhile back).

However, the only single language that cover EVERY PIC familly and which is free is ASM. That's great, but a real pain to program in, and it's syntax change from a familly to another, more noticeable on DsPIC/PIC32. Good news is, the only person you will be abe to blame when a bug will appear one day or another is you.

Depending where you are located in the product food-chain, ASM is great or bad.

For every compiler on the market, we heard good and bad comments... same things goes for all device programmers, IDE, etc etc etc. What I hate is to learn 3,4,5,6,7...10 different compiler to do a single job.

Knowing your compiler is great, knowing your own limit is great, ASM cover everything, but you must know and admit your personal limit/time.

It's a full piece of crap to say that ASM is faster... it's really up to the pepper back of the keyboard.... hence why performance of each and eavery compiler differ for the same single task.

Time wasting... is this a real waste, or knowledge improvement... who knows? On the other side, who care of a developer knowledge if another do it WAY faster... once it's burned in a black pinned box, and do the job as per the customer requirement, no one will care of the tool you used.

Same bull**** happen with PC... C is better than Basic... euh NO SIR your $%!$%^#@ wrong C#... Delphi... Python....Java is better... crap crap crap... unfortunately, actual market is... faster is better... crap crap crap...

[johnnylynx]

Wow, seems I opened up a can of worms there

I was looking over ASM earlier (from a beginners perspective) and learned how to convert binary to hex (amazingly simple...after a 3-finger scotch!)

Still, ASM, as you all have essentially indicated, is ... a pain.

I'm checking out PDS...and don't see if it supports pickit2 and a programmer (anyone know?).

I think i'll end up purchasing either PDS or PBP...both look great!

Thanks for all you're input!

John.

[mackrackit]

The PICKIT2 will load the generated hex, does not matter who or what created it.

Can of worms?
What did you expect, I like Fords, are they better

[rmteo]

I agree with with Dave, that is why I suggested that you try them out and judge for yourself rather than relying on the opinion of third parties. I did indicate my favorite though - just like Dave did.