Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PIC language?

Status
Not open for further replies.
Ya, Windoze has the best microcontroller tools. I've done some stuff with Piklab, but I run a windoze box at my electronics table. It does dual-boot Ubuntu, but normally runs Windows.

sounds like it .. thing is, my desktop is linux only (fedora) and my job requires linux / osX .. so windoze is not an option for me .. I have one box that is windoze only that I use for elco (when I have time) but would love to have at least dev tools on linux ... anyhow, I'm now trying to dedicate one "room" to elco stuff, and idea is to put spare lap there with windoze (I have some 17" asus w2c hanging around collecting dust and that seams to be ideal elco dev box ... the only thing missing is the serial port, but .. )

As for you never trying GCC for PIC, have you used any of Microchip's compilers? They're all GCC based, as far as I know.

I used only C18 .. not sure if it is gcc based as they would have to be GPL too then, don't they ? The other microchip compilers I never tried... In general, I do not get why they charge for the compilersas putting out there a "good" fully loaded dev tool for free should improve hw sales imho...

I hate to sound like a broken record, but...

:D I got PICC for some 20$ (only up to 16F, so cannot make 18F hex) with some ftdichip evaluation kit and I really like it ... mikroC is 99E (donno if that is "local price" or is same price for "all around the world") and I purchased it as it is a local company, few hundred meters from my appt and I really liked the easyPic hw and all the "test boards" they sell ...

as for 18F uC's .. with so many app notes written in C18, and microchip standing behind it .. i still vote for C18 as "best" irrelevant to the price as the free version lack only optimisation, it is not limited to size of the code nor anything else.

all in all, with 18F being "better" in many ways then "smaller" ones, and prices pretty much "same", I moved 99% of r&d to 18F ...
 
Ya,

As for you never trying GCC for PIC, have you used any of Microchip's compilers? They're all GCC based, as far as I know.


Yes, I believe that is true; the best c compilers for ARM are also gcc based. I will try to shed a bit of light on this if I can. A while back I read an essay in "The Firmware Handbook," edited by Jack Ganssel, called "Understanding Your C Compiler: How to Minimize Code Size." The essay was written by Jakob Engblom, engbloms.se -- welcome page who built compilers for IAR.

I too, used to think:
In general, you will have to use ASM inside C application in many cases when some precision or speed is needed
but now know that one must be very careful doing this.

The money charged for a gcc based compiler is not for the compiler itself, but for the optomization, which is very complex, and where the rubber meets the road, so to speak. (this would explain MicroChips position on C18) Optomization doesn't happen in one pass, it takes many, and happens at both a high and low level. The compiler must understand the code very well to optimize. Doing things like writting bits of code in assembly, or 'smart' coding in C, can actually hurt the way optomization works.
Engblom said:
Using inline assembly is a very efficient way of hampering the compiler's optimizer. Since there is a block of code that the compiler knows nothing about, it cannot optimize across that block. In many cases, variables will be forced to memory and most optimizations turned off.

The output of a function containing inline assembly should be inspected after each compilation run to make sure that the assembly code still works as intended. ....

One thing the writer pointed out was this:
Code:
void delay(unsigned int time)
{
    unsigned int i;
    for (i=0; i<time; i++)
      ;
    return;
}

void InitHW(void)
{
    /* Highly timing - dependent code */
    OUT_SIGNAL (0x20);
    delay(120);
    OUT_SIGNAL (0x21);
    delay(121);
    OUT_SIGNAL (0x19);
}

Now imagine if the compiler optimized that 'useless' for loop:
Code:
void delay(unsigned int time)
{
    /* loop removed */
    return;
}

It looks like I'll be re-reading that interresting essay again tonight.:D

futz said:
I hate to sound like a broken record, but...

I agree here too; for the <$50 I spent on BoostC (eBay purchase) it is by far the best I've tried...

CCS is a close second, but a lot more money (about $500 for the whole package.)
:D I got PICC for some 20$

WOW! That was a great deal! Is there a smiley for envy? :D

I didn't like Mikro at all, and don't understand how anyone who doesn't like windoz would like it. The reasons are that it has no MPLab integration, so I can't just download the program to the chip, as I don't have their propriety programmer... I have no access to thier propriety libraries....

The trouble with the libraries on the above two compilers is that they are closed, and when things go wrong it is tough to find out what is going on. Yes, CCS has open source 'driver' code, but a lot of things are behind the scenes. Best to write your own, or use libraries which include the source code so you can figure out how they are working.

OK, I'm off to read that essay.:D
 
but now know that one must be very careful doing this.

That is why one must know his compiler :)
I do system development so this is pretty important for "normal" dev too, especially for uC dev.. most "good" ones enable you to pragma part of the code to "tune" the optimisation :)

WOW! That was a great deal! Is there a smiley for envy? :D

The "DEV" kit was ~100$ .. 80$ without PICC and 100$ with PICC, only 1 year "update/support" and only pic16F and less (no pic18F support).. the DEV kit was bit "overpriced" but in general, it got me started and 100$ is ~60E ? that's less then box of cigarettes.

I didn't like Mikro at all, and don't understand how anyone who doesn't like windoz would like it. The reasons are that it has no MPLab integration, so I can't just download the program to the chip, as I don't have their propriety programmer... I have no access to thier propriety libraries....

in general, "preaching to the quire" :) .. but at the time I was "coming back" to uC programming (I'm pretty fed up with making "virtual" stuff and really wanted to make something one can "touch" and as I got some free time on my hands, I decided to get back to elco, mine old, forgotten, love), the MikroC was "cheapest" in regards to, the ppl making it work near me, I could purchase as company, they had EasyPic4 board that is great dev tool for beginners so it was "best by" at the time.

The major "flaws" are, exactly what you mentioned:
- no integration with mplab
- cannot debug anything (easypic + mikroc is only combo, you cannot debug using easypic + mplab, nor mikroc + pickit ..) if you go "outside mikroelektronika tools"
- closed source libraries (this is actually *the* biggest problem)

now, the compiler itself is "great" (not the IDE, IDE is awful), the asm code is pretty good, optimisations are pretty nice and they offer pretty good support .. as I said, for beginner - they really rule with all the "dev boards and extension boards"

Now, when I'm not such beginner as some time ago, I use pickit2 and breadboards and simulators and ... and I rarely use mikroC at all .. I switched mostly to C18 as I moved also most of the r&d to pic18F ... (and yes, r&d == play)

I hope I will get some free time in next few weeks to do a small C compiler comparison (the asm output comparison of some "usual" compiler problems)... it might be good article for the next version of junebug :D
 
Yes, optimised C compilers produce truely appallingly bad code :p

:eek:

At least you don't advocate writing in hex and hand assembling from the op codes.:p

Iillogical and very difficult to follow. :D

And, (Mr. Spock,) I thought I was old and set in my ways.:p


That is why one must know his compiler :)

Yes, that was the thrust of the essay.:)

The "DEV" kit was ~100$ .. 80$ without PICC and 100$ with PICC, only 1 year "update/support" and only pic16F and less (no pic18F support).. the DEV kit was bit "overpriced" but in general, it got me started

Still a great deal, as CCS charges ~$125 for each compiler... for the small PICs (12xx) that compiler was bundled with MPLab. I like the whole package deal though, as it includes a chip editor, terminal (even though I usually use other terms) and lots of goodies... The best part about CCS is their truly great forums!

My experience getting started was even more expensive... I was in Korea at the time, and using OSX. I had been proud of that(arrogant even?:eek:) as I didn't have to use Windows. I bought a Comfile PIC BASIC SBC there for about $100 and couldn't connect to the Mac under Soft PC. Frustrated, I went out and bought a windoz box for a few hundred more.
I had fun for about a week, then decided that it was too easy, and $100 for each project was too much. Now that I had windoz and a parallel port....
I went out and spent a couple of hundred more on a (comfile) chip programmer, and started learning assembly. I wanted to be able to count on my hardware, rather than work at debugging both hard and software at the same time, so got a development board from the same store more $$:p

Then Comfile came out with an ICD2 made under licence... I had to have it.:D Mine is cool; it is rectangular, not round. I also 'had fo have' the nice development board with the RJ11 jack on it...:p The board was a great deal and I wish I had bought many more as they have stopped making them...


I hope I will get some free time in next few weeks to do a small C compiler comparison (the asm output comparison of some "usual" compiler problems)... it might be good article for the next version of junebug :D

That would be awesome!:)
 
Last edited:
Well I know Bill is up with the times, I've heard him talk about it.:)

One day Sir Nigel is going to try out C, and there will be no looking back.:p

I didn't mind looking up the op codes (6502) too much, or punching them in on the darn keypad, but what I hated was when the power went down.....
:(
well, at least I didn't have to look up the codes again, but if the program was any length, even punching it in again was not fun, especially if it did much of anything useful.

The mnemonics, and a software assembler made things much faster than looking up the hex, didn't they?:)
 
Last edited:
Well I know Bill is up with the times, I've heard him talk about it.:)

One day Sir Nigel is going to try out C, and there will be no looking back.:p

I didn't mind looking up the op codes (6502) too much, or punching them in on the darn keypad, but what I hated was when the power went down.....
:(
well, at least I didn't have to look up the codes again, but if the program was any length, even punching it in again was not fun, especially if it did much of anything useful.

The mnemonics, and a software assembler made things much faster than looking up the hex, didn't they?:)

It's what was available at the time, initially all I had was hand assembly and 1K of RAM (including video display RAM), next I added an extra board which provided more RAM, space for EPROM, a cassette interface, and a simple single pass assembler. The cassette interface required it's read program typing in as HEX before you could use it :D - once you're typed the write program in, the first thing you did was save that to tape, so it was only the read part you had to type in every time.

Next was an upgrade to a multi-pass assembler, complete with tape software in EPROM - which made life MUCH easier.

After that came 10K of MicroSoft BASIC in ROM, and even later, Forth on cassette.

Those were the days! :p
 
It's what was available at the time, initially all I had was hand assembly and 1K of RAM (including video display RAM), next I added an extra board which provided more RAM, space for EPROM, a cassette interface, and a simple single pass assembler. The cassette interface required it's read program typing in as HEX before you could use it :D - once you're typed the write program in, the first thing you did was save that to tape, so it was only the read part you had to type in every time.

So the write program was like a monitor program? You were setting up the hardware as well... 16 address lines? Would have been a challenge to debug, no?

The trainer boards we were given had a monitor program burned to an EEPROM. Thankfully I didn't have to climb that hurdle!:p

Those were the days! :p

At least you didn't say 'good old days!:p
 
There was a simple monitor program in EPROM, this allowed you to enter HEX code in memory, run the code, set breakpoints etc.

The tape routines were all typed in initially, but once you'd typed the 'tape write' routines in, you could write it to tape and never need to type it again. The 'tape read' routine though needed typing in before you could read anything.

Once I upgraded to the enhanced monitor, this included an assembler, and the tape routines in EPROM - made life MUCH easier.
 
There was a simple monitor program in EPROM, this allowed you to enter HEX code in memory, run the code, set breakpoints etc.

The tape routines were all typed in initially, but once you'd typed the 'tape write' routines in, you could write it to tape and never need to type it again. The 'tape read' routine though needed typing in before you could read anything.

Once I upgraded to the enhanced monitor, this included an assembler, and the tape routines in EPROM - made life MUCH easier.


OK, makes total sense. Thanks!:)
 
That is why one must know his compiler :)
Very true. I recently started with MicroChip's C30 compiler for the dsPIC and was curious about dsPIC assembly so I looked at the generated assembly code. What looks efficient in C is not necessarily true of the generated code:
Code:
LATBbits.LATB1 = 1;
LATBbits.LATB2 = 1;
//Compiles into this:
  078E  A822CC     bset.b 0x02cc,#1
  0790  A842CC     bset.b 0x02cc,#2
Which is way more efficient than this:
Code:
LATBbits.LATB2 = LATBbits.LATB1 = 1;
//Which compiles into this mess:
  07C2  A822CC     bset.b 0x02cc,#1
  07C4  BFC2CC     mov.b 0x02cc,0x0000
  07C6  FB8000     ze 0x0000,0x0000
  07C8  D10000     lsr.w 0x0000,0x0000
  07CA  604061     and.b 0x0000,#1,0x0000
  07CC  604061     and.b 0x0000,#1,0x0000
  07CE  DD0142     sl 0x0000,#2,0x0004
  07D0  202CC1     mov.w #0x2cc,0x0002
  07D2  784091     mov.b [0x0002],0x0002
  07D4  B3CFB0     mov.b #0xfb,0x0000
  07D6  60C000     and.b 0x0002,0x0000,0x0000
  07D8  704002     ior.b 0x0000,0x0004,0x0000
  07DA  B7E2CC     mov.b 0x0000,0x02cc
 
Last edited:
Very true. I recently started with MicroChip's C30 compiler for the dsPIC and was curious about dsPIC assembly so I looked at the generated assembly code. What looks efficient in C is not necessarily true of the generated code:
Code:
LATBbits.LATB1 = 1;
LATBbits.LATB2 = 1;
//Compiles into this:
  078E  A822CC     bset.b 0x02cc,#1
  0790  A842CC     bset.b 0x02cc,#2
Which is way more efficient than this:
Code:
LATBbits.LATB2 = LATBbits.LATB1 = 1;
...snip...
//Which compiles into this mess:

Wow, no kidding on that one, eh?:p
 
//Which compiles into this mess:

:)
you gave a perfect example of why "one needs to know his compiler". There are many examples like that one, and many compilers do same things differently. In general case, it is often needed, especially with "cheaper" compilers to write "basic style code" in C to get the best asm output. The "C programmers should not use GOTO" statement is invalid when it comes to uC programming.

What I found to be the biggest problem is lack of pragma's to modify optimisation behaviour for code segments, also, many compilers out there lack basic function modifiers like "inline" and have pretty poor implementation of macro's. That's imho the "code" part of the compilers that produce "unintended behaviour" and decrease productivity. On the other hand, the "inventing hot water" part in regards to configuration of the uC is my personal nightmare, there is as many ways to configure the uC as there is compilers, from mikroelektronika (mikroC, mikro*) way to keep all this configuration in "project description" - away from the source file, trough "inventive" flag names used in some compilers up to the microchip compiler with it's "unique" way of handling this. Do not let me start on how port's and bit's are accessed...

One can usually get acquainted with ones compiler of choice but moving code from one to another is proving to be real pita as every developer think "they know the best"
 
Last edited:
arhi,

I feel some of what you said is somewhat out of date.

Inexpensive realitivly fast uC's with larger memories can be used for most applications. This allows the programmer to live with code that is not great in terms of speed and size. (this is the part of the argument we use to justify the use of compilers)

The goto should be used with caution, Using it to save a few cycles or bytes of code would be a very bad idea in my book. In most cases proper use of functions, loops, returns, and break should keep goto out of most programs.

3v0
 
3v0, I agree 100% but I still use C with 16F and 12F... and they are not at all "with larger anything" :) .. with 18/24/30F is a different story, and there are really only few rare reasons why would one use goto, inline asm etc ..

in any case, if you know your compiler you will decide between use of for(;;){} vs while(1){} .. discourage use of a=b=constant; if compiler is unable to process it properly.... etc etc ... I will try to find some time to do some comparison in next few weeks, probably when I return from sweden.

at the end of the day, it all comes up to what you need and what you use, when using 16F, every tick counts and every byte count :) hence, some "hand optimisations" might help big time .. with "big ones" you do not have to worry :) most of the time
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top