1. 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.
    Dismiss Notice

PIC language?

Discussion in 'Microcontrollers' started by uaefame, Nov 5, 2008.

  1. arhi

    arhi Member

    Joined:
    Apr 17, 2008
    Messages:
    887
    Likes:
    12
    Location:
    Belgrade, .rs
    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 .. )

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

    :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 ...
     
  2. BeeBop

    BeeBop Active Member

    Joined:
    Dec 22, 2005
    Messages:
    1,281
    Likes:
    23
    Location:
    Vancouver Canada

    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:
    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.
    One thing the writer pointed out was this:
    Code (text):

    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 (text):

    void delay(unsigned int time)
    {
        /* loop removed */
        return;
    }
     
    It looks like I'll be re-reading that interresting essay again tonight.:D

    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.)
    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
     
  3. 3v0

    3v0 Coop Build Coordinator Forum Supporter

    Joined:
    Jul 14, 2006
    Messages:
    9,404
    Likes:
    227
    Location:
    OKLAHOMA USA
    Well put.

    A good compiler preforms optimizations that will suprise many/most good asm programmers. That has been true for over 20 years.

    The BoostC compiler is a great buy.
     
  4. dave

    Dave New Member

    Joined:
    Jan 12, 1997
    Messages:
    -
    Likes:
    0


     
  5. Nigel Goodwin

    Nigel Goodwin Super Moderator Most Helpful Member

    Joined:
    Nov 17, 2003
    Messages:
    39,331
    Likes:
    653
    Location:
    Derbyshire, UK
    ONLINE

    Yes, optimised C compilers produce truely appallingly bad code :p
     
  6. 3v0

    3v0 Coop Build Coordinator Forum Supporter

    Joined:
    Jul 14, 2006
    Messages:
    9,404
    Likes:
    227
    Location:
    OKLAHOMA USA
    Iillogical and very difficult to follow. :D
     
  7. arhi

    arhi Member

    Joined:
    Apr 17, 2008
    Messages:
    887
    Likes:
    12
    Location:
    Belgrade, .rs
    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 :)

    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.

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

    BeeBop Active Member

    Joined:
    Dec 22, 2005
    Messages:
    1,281
    Likes:
    23
    Location:
    Vancouver Canada
    :eek:

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

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


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

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


    That would be awesome!:)
     
    Last edited: Nov 7, 2008
  9. Nigel Goodwin

    Nigel Goodwin Super Moderator Most Helpful Member

    Joined:
    Nov 17, 2003
    Messages:
    39,331
    Likes:
    653
    Location:
    Derbyshire, UK
    ONLINE
    That was how I first started programming, as most did back in the early days of micro-processors.
     
  10. blueroomelectronics

    blueroomelectronics Well-Known Member

    Joined:
    Jan 21, 2007
    Messages:
    12,536
    Likes:
    170
    Location:
    Toronto, Canada
    Same here on an RCA COSMAC1802.
     
  11. Nigel Goodwin

    Nigel Goodwin Super Moderator Most Helpful Member

    Joined:
    Nov 17, 2003
    Messages:
    39,331
    Likes:
    653
    Location:
    Derbyshire, UK
    ONLINE
    Mine was 6502.
     
  12. BeeBop

    BeeBop Active Member

    Joined:
    Dec 22, 2005
    Messages:
    1,281
    Likes:
    23
    Location:
    Vancouver Canada
    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: Nov 8, 2008
  13. Nigel Goodwin

    Nigel Goodwin Super Moderator Most Helpful Member

    Joined:
    Nov 17, 2003
    Messages:
    39,331
    Likes:
    653
    Location:
    Derbyshire, UK
    ONLINE
    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
     
  14. BeeBop

    BeeBop Active Member

    Joined:
    Dec 22, 2005
    Messages:
    1,281
    Likes:
    23
    Location:
    Vancouver Canada
    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

    At least you didn't say 'good old days!:p
     
  15. Nigel Goodwin

    Nigel Goodwin Super Moderator Most Helpful Member

    Joined:
    Nov 17, 2003
    Messages:
    39,331
    Likes:
    653
    Location:
    Derbyshire, UK
    ONLINE
    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.
     
  16. BeeBop

    BeeBop Active Member

    Joined:
    Dec 22, 2005
    Messages:
    1,281
    Likes:
    23
    Location:
    Vancouver Canada

    OK, makes total sense. Thanks!:)
     
  17. kchriste

    kchriste New Member Forum Supporter

    Joined:
    Jul 23, 2006
    Messages:
    3,677
    Likes:
    47
    Location:
    Victoria BC, Canada
    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 (text):
    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 (text):
    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: Nov 8, 2008
  18. BeeBop

    BeeBop Active Member

    Joined:
    Dec 22, 2005
    Messages:
    1,281
    Likes:
    23
    Location:
    Vancouver Canada
    Wow, no kidding on that one, eh?:p
     
  19. arhi

    arhi Member

    Joined:
    Apr 17, 2008
    Messages:
    887
    Likes:
    12
    Location:
    Belgrade, .rs
    :)
    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: Nov 8, 2008
  20. 3v0

    3v0 Coop Build Coordinator Forum Supporter

    Joined:
    Jul 14, 2006
    Messages:
    9,404
    Likes:
    227
    Location:
    OKLAHOMA USA
    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
     
  21. arhi

    arhi Member

    Joined:
    Apr 17, 2008
    Messages:
    887
    Likes:
    12
    Location:
    Belgrade, .rs
    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
     

Share This Page