how to choose a PIC?

[andersm]

But other features like proper information hiding are harder, and some like inheritance, polymorphism, class templates and other "true" OO features just cannot be done in C.

Both inheritance and polymorphism can be done in C, it just takes a lot more work. After all, most basic C++ features are just compiler automated structures and function pointers. If you program for OS X you run into many examples of object-oriented APIs implemented (at least originally) in C. However I'm not arguing you should do it this way rather than using C++, just that it can be done.

[Kremmen]

OK, let me rephrase: C does not support OO as part of the language definition. This may be trivially so and that is why we have C++. You are right in that you can code the OO functionality using C and elbow grease but i didn't quite mean that. Been there, done it but really, that way you will miss many of the OO rules enforcing that a proper C++ compiler will do for you. Just an example is managing self-pointers to object instances. Can be done but makes for lots of extra work.
I am not familiar with things Mac, but i suspect that we have different levels of OO in mind here.
Object-like code is possible in C but why would you want to do it when C++ is available. But then you already said so.

[ptricks]

I would learn C but also learn some basic assembly too. The reason for knowing assembly is that with chips like the pic the compilers are often slow to catch up with new chip models. If you happen to be using one of these new chips and the compiler version doesn't support it yet, you might not be able to use any of that chips new features without knowing some assembly.   Often you can do things like setting up chip configuration or ports much easier in assembly than relying on a C macro to do it. I like to mix assembly and C and use primarily C for the programming. It also helps to know assembly when you compile a program and it doesn't work correctly yet nothing appears wrong in the C code. Compilers are far from perfect, especially when it comes to pics

[ptricks]

Yeah, going the asm only route is a bit silly in 2012. My most recent additions to the mcu menagerie are msp430 and stm32f4, and I haven't written a single line of asm for either yet. All the asm exposure I've had on those is reading the startup code to get an idea of what's being done there. Other than that it's C all the way.

There  is nothing wrong with using assembly if you are comfortable using it. Where assembly is wrong is when someone doesn't like using it, gets confused using it . I know some very talented pic programmers that only use assembly. One of them wrote a program that creates a UART , interfaces a 16x4 character LCD , and supports an SD card for data, this all runs on a pic16c505 chip, the chip only has 1K of flash and 72 bytes of ram, no hardware UART so it is bit banged, and  he made it all fit.  In the right hands assembly is great, but don't use it just for the sake of using it.


I tried recreating what he wrote with 3 different compilers, none of them could make it fit.

[Kremmen]

If one tries to be objective (no pun intended) then the choice of coding level should be dictated by the highest priority at hand. With this in mind it is faulty logic to suggest something like "always use X in environment Y".
Usually/often the highest priority is to produce bug free, well maintainable code that has sufficient performance for the task at hand. Then a high(er) level language is indicated.
Sometimes, e.g. when implementing library functions where max performance is desired, it _may_ be the correct choice to code near the bare metal.
The highest level of expression/language that is adequate to solve the problem should be used. Those who say otherwise should consider the story of Mel. http://www.cs.utah.edu/~elb/folklore/mel.html

[alm]

Can anyone provide quantitative data on just how effective Microchip's optimisation actually is? (ie. not the manufacturer's claims, but actual project performance and/or code footprint improvements)

I'm not aware of any numbers, and they would be of limited value since it will highly depend on the code involved. For example:

Code: [Select]

uint32_t i;
for (i=0; i < UINT32_MAX; i++);
Might take an hour without optimization, and zero cycles (completely optimized away) with optimization since it does not produce any results. Optimization will also pre-calculate constants at compile time, this explains this result:

For a delay of 300 ms the delay is close to 5% longer (13 ms) without optimization, and a trivial test program grows from 136 byte of flash to 3146 bytes..

[ejeffrey]

There  is nothing wrong with using assembly if you are comfortable using it. Where assembly is wrong is when someone doesn't like using it, gets confused using it .

If your goal is to have fun, sure.  If your goal is to produce code that does the job at hand with a minimum of bugs and minimum development time, then no, assembly is almost never the right choice.  People who say things like "I am used to assembly, I can code Bug Free (tm) code just as well and just as fast as in a higher level language" are wrong.  Always.  They may be very talented individuals, and they may produce good code in assembly, but they always turn out to produce better code in a higher level language.  Assembly programs tend to have fewer features and more limitations than programs written in higher level languages because of the difficulty of doing very simple mundane things like dynamic memory allocation.  Sometimes this gives the appearance of being more reliable but that is a false comparison.  An equally simple program written in a higher level language would have been completed faster and with fewer bugs.

Yes, in certain instances it is required.  The extremely small memory footprint of the smallest MCUs is one of a few remaining legitimate use cases.  Compilers can actually produce fairly compact code, but there is generally a bit more fixed overhead that can be a problem in such small environments.  Also, the complexity of the program you can fit is limited anyway, so doing it in assembly is feasible.  Likewise there are still a few use cases in high performance computing.  Of course accessing hardware specific features like IO and synchronization primitives often requires bits of assembly -- wrapped in higher level functions and eventually added to the platform library.

Even in high performance computing, a fundamentally conservative community that has always been skeptical (with good reason) of the promised advances touted by systems programmers, assembly is disappearing.  On modern CPUs, maximizing ILP, optimizing cache layout, making best use of SIMD, and targeting special purpose processors like GPUs and FPGAs is just too hard for humans to do when they are stuck counting instructions.  Give them a higher level language and the means to express the problem more clearly, and they produce better, faster code.  There is still plenty of hand tuning going on, it is just at a higher level.

[ptricks]

If your goal is to have fun, sure.  If your goal is to produce code that does the job at hand with a minimum of bugs and minimum development time, then no, assembly is almost never the right choice.  People who say things like "I am used to assembly, I can code Bug Free (tm) code just as well and just as fast as in a higher level language" are wrong.  Always. 

Not always, you may not be able to produce code as fast or accurate  in assembly as you can using C but there are people who can do it and are doing it and those people are paid very well for their work. Unfortunately there is not a lot of people who understand assembly anymore and that creates a shortage of people that can write compilers, drivers and firmware for embedded devices. Things that work on the low level like initializing a processor for the first time when no compiler exist because it is a new design. I asked someone at a large semiconductor company, not allowed to say which one, how many people here really understand the chip well enough to be able to write the compiler or code all the low level stuff ? The reply was 6 people, 2 were over 55 years old, 2 had just started from college, 2 had been on the job for 1 year or more. The company was basically hoping the senior employees could teach the few interns they could get enough to take over but they were not optimistic.   That was millions of dollars in product depending on 6 people and only 2 able to write code by themselves. There just isn't enough engineers wanting to know the low level stuff anymore. You can find plenty of graduates that know C or how to plug up a micro to a jtag or use the ide to program the chips, but the ones that know how to create all that stuff so programmers can use it are few. 

Back on topic, I stand by what I said. Learn C but don't ignore assembly completely, it doesn't hurt to learn it and it does help to better understand why a certain C instruction is taking so long to execute, why the compiler keeps tossing out errors that make no sense, or being able to debug a program down to the core level.  Using the microchip ide you will want to understand what all the registers mean and how the values are changing and why.

[nctnico]

Most of the people (like myself) that know that kind of low level stuff are freelancers nowadays.

[westfw]

Can anyone provide quantitative data on just how effective Microchip's optimisation actually is? (ie. not the manufacturer's claims, but actual project performance and/or code footprint improvements)

1) It's only the 8bit compilers that have awful optimization in the free versions.  The 16bit and 32bit compilers are gcc, which has its own optimizations that would be hard to remove.
2) the 8bit unoptimized code is awful.  The sort of crap that people have used since the dawn of time to bad-mouth compilers, like someone took the three-operand pseudocode that beginning compiler classes tell you to emit, and wrote a naive translation to machine code. (this is being charitable.  The uncharitable explanation is that they have introduced deliberate anti-optimizations.)
Here are some quotes from the PICList mailing list, circa 2009.  (Note that one of the sad things is that Microchip can fix this at any time, but probably no one will trust their free versions again.)

Code: [Select]

Look how they do 'Var = 0;' :

bcf    STATUS,C
movlw   0
btfsc   STATUS,C
movlw   1
movwf   Var

'Var = 1;'

clrf   Var
bsf   STATUS,C
rlf   Var,f

'Var = 2;'

clrw
iorlw   2
movwf   Temp
movf   Temp,w
movwf   Var

And so on... </quote>


[AndyC_772]

That was millions of dollars in product depending on 6 people and only 2 able to write code by themselves. There just isn't enough engineers wanting to know the low level stuff anymore.

Arguably that pretty much sums up the size of the job market for people with that specific skill, though.

I very much doubt the company in question has ever advertised a six figure salary for engineers who are capable of programming in assembler and willing to make a career out of it - and I can virtually guarantee that they'd get plenty of good applicants if they did. If the skill is so key to the project's success, and so hard to come by, then it becomes expensive - and that's just the law of supply & demand.

I'm a bit surprised there aren't more engineers at least willing to do it, though. If a CPU is brand new then it absolutely has to be learned afresh, of course. By definition, nobody at all has prior experience with it.

I did a lot of programming in assembler back in university and beforehand, back when the BBC micro was the machine to have, and programming it in 6502 assembler was the way to get better performance out of it. When the Archimedes came out I learned ARM assembler too, which was a joy to use by comparison.

The last assembly language project I did was my final year university project, which was done on an early PIC where it was the only option. It was an absolute pig to do, and using assembler really got in the way of concentrating on the real task at hand which involved reading the inputs from sensors, performing some mathematical operations on the measurements, and then clocking the results out to a display. The chip wasn't particularly constrained by memory or speed, and it's a job which would have been much, much better done in a high level language.

Thankfully I've not had to program in assembler since, though I do now regularly write VHDL which uses a lot of the same skills and mindset.

[mrflibble]

I'm using C++ with STM32F1xx, which is essentially the same. My code runs equivalently on the F4 and VL Discovery boards (with mods to the linker script). I thought about using an MSP430 until codespace issues started to crop up.

Hey, good to hear that C++ is viable on STM32 . During the frustration inducing part of my stm32f4 learning curve I tried C++, but that was one bridge too far at that time. Plenty of errors at the link stage. At this point I am sloooowly getting a handle on things, so I'd like to try again. Are there any particular linker flags / libs that I should be using?

[mrflibble]

There  is nothing wrong with using assembly if you are comfortable using it. Where assembly is wrong is when someone doesn't like using it, gets confused using it .

There is plenty wrong with using assembly, even if you are comfortable using it. What's "wrong with it" is that it takes up valuable development time, which IMO is better put into coding functionality. Also higher level generally translates to better maintainability. And from the business perspective it translates to a larger pool of average people writing average code that are then perfectly capable of managing the code base. This as opposed to the magical awesomely clever and handsome rockstar coder that codes asm faster than you do C. And that is with his off hand. Blindfolded. Without coffee on monday morning.

But sadly enough the world supply of these mythical creatures is limited, so IMO on average you are better of with mundane boring high level languages.

[mrflibble]

I did a lot of programming in assembler back in university and beforehand, back when the BBC micro was the machine to have, and programming it in 6502 assembler was the way to get better performance out of it. When the Archimedes came out I learned ARM assembler too, which was a joy to use by comparison.

...

Thankfully I've not had to program in assembler since, though I do now regularly write VHDL which uses a lot of the same skills and mindset.

Hey, that all sounds familiar. Although in my case it was Z80A first, then 68000. 68k asm on ye olde amiga certainly was a breath of fresh air. Memory mapped peripherals, yay!

These days not much call for assembler here either. And if I reeeeeally feel the urge to exercise the low level skills it's verilog over here. If that doesn't scratch the low level itch there's always click-n-crash in fpga editor in case you're in the xilinx camp. ;-)

[nctnico]

Thankfully I've not had to program in assembler since, though I do now regularly write VHDL which uses a lot of the same skills and mindset.

You're much better off regarding VHDL as a high level language which it is. Otherwise you'll be doing lots of typing on stuff which could easely be solved by a 3 line function. Just for fun look for priority encoder examples. 9 out of 10 will show an equation for each output combination and 1 out of 10 will show a 3 line function which will work for any number of inputs.

[AndyC_772]

I think you'd like my arbitrary n-bit CRC calculator.

[ptricks]

But sadly enough the world supply of these mythical creatures is limited, so IMO on average you are better of with mundane boring high level languages.

The problem with that is most of those using the high level languages have no idea what is going on underneath. They only know that if they use this macro or this function it is supposed to generate the program they want, when that doesn't work you have programmers that spend hours scratching their head.  I have no issue with using high level languages , but when people don't understand what is going on underneath it leads to problems. I compare it to people that learn electronics by using IC , these people panic when a certain IC isn't available for what they need, they are so used to having a packaged chip that they can't even think about using discrete electronics. I see the people using arduino do this quite a bit, they learn the easy stuff but when something breaks they have no clue how to fix it in hardware or software.

[mrflibble]

The problem with that is most of those using the high level languages have no idea what is going on underneath.
...
I have no issue with using high level languages , but when people don't understand what is going on underneath it leads to problems.

The problem with humans is that they behave like humans. Using one tool or another is no guarantee for understanding or success. This sort of thing has less to do with using asm vs C and more with a certain mindset.

I compare it to people that learn electronics by using IC , these people panic when a certain IC isn't available for what they need, they are so used to having a packaged chip that they can't even think about using discrete electronics.

Hey, I resemble that remark! I do okay in the digital domain, but analog is not really my strong suit. So I take it you build up fractional-N synthesizers from transistors? Well, I am perfectly happy using National TI or AD parts for that.

I see the people using arduino do this quite a bit, they learn the easy stuff but when so

mething breaks they have no clue how to fix it in hardware or software.

Oi! No dissing the arduino crowd, they are a good source of amusement. XD And besides that, if a platform like Arduino opens up the electronics playing field to more people I say gogogo! Even if that means mediocre implementations. Everyone has to start somewhere...

[Bored@Work]

And besides that, if a platform like Arduino opens up the electronics playing field to more people I say gogogo!

You will change your mind once one shows up in an application on which your safety depends.

The bad thing with the Arduino crowd is that the moment they manage to blink a LED they think they are embedded engineers. And the job is not complete until they have glued a fscking Arduino to everything. A few years, maybe just a year, and the first of these "embedded engineers" will show up in the industry.

That will be a bit like what happened in the new economy, when suddenly every ditch digger became an "HTML programmer", and tried to pass as a programmer once the new economy was over.

[dfnr2]

Back on topic, I stand by what I said. Learn C but don't ignore assembly completely, it doesn't hurt to learn it and it does help to better understand why a certain C instruction is taking so long to execute, why the compiler keeps tossing out errors that make no sense, or being able to debug a program down to the core level.  Using the microchip ide you will want to understand what all the registers mean and how the values are changing and why.

That is more to the mark.  Outside of the most trivial applications, direct assembly should be avoided (and quarantined where needed for hardware setup, etc.) in professional applications, especially if the cost of bugs could be high. 

However, every programmer should learn the machine/assembly language and register-level programming of the target chip, and should inspect the compiler output strategically to ensure that code generation is correct.

[mrflibble]

Excuse the 100% self-interest motivated bump ...

I'm using C++ with STM32F1xx, which is essentially the same. My code runs equivalently on the F4 and VL Discovery boards (with mods to the linker script). I thought about using an MSP430 until codespace issues started to crop up.

Hey, good to hear that C++ is viable on STM32 . During the frustration inducing part of my stm32f4 learning curve I tried C++, but that was one bridge too far at that time. Plenty of errors at the link stage. At this point I am sloooowly getting a handle on things, so I'd like to try again. Are there any particular linker flags / libs that I should be using?

I'm hoping this escaped your attention... if not, feel free to ignore it. In any event I'd really appreciate some quick pointers on C++ for the stm32 should you have any. Thanks in advance!

[andyturk]

In any event I'd really appreciate some quick pointers on C++ for the stm32 should you have any. Thanks in advance!

Sorry, I wasn't paying attention...

Well, the key thing is use C++ in an embedded environment. STM32 is the same as Stellaris, is the same as everyone else's ARM, etc. I recommend yagarto's arm-none-eabi gcc, but I think any C++ will do.

Here are the compiler switches I use (currently):

-fno-rtti -fno-exceptions -fms-extensions -Wno-pmf-conversions -Wno-unused-parameter -Wno-psabi -std=gnu++0x

1) -fno-rtti turns off run time type information. You probably won't need it and it leads to code bloat.
2) -fno-exceptions does what you think. Exception handling is a good thing, but it also bloats the code because the compiler has to generate two exits for each basic block. Embedded apps generally do without.
3) -Wno-pmf-conversion allows the compiler to convert a pointer to a member function like void (A::*fn)() to something like void (*fn)(A*). This is obscure, but I've used it for object-oriented callbacks.
4) -Wno-unused-parameter turns off complaints about unused parameters in function definitions.
5) -Wno-psabi turns of warnings related to varargs.
6) std=gnu++0x enables GNU extensions to C++

Your environment will need to have some way of taking control once the CPU comes out of reset. This isn't necessarily a C++ thing, but C++ does add a requirement to call all of the compiler-generated static initialization code. The linker strings together all the compiled constructors for each file/module and creates an array of function pointers. After the CPU comes out of reset and before the call to main(), somebody needs to call those functions. This is might be already handled by your environment, but if not, you'll have to write a little loop. Technically, you should also call destructors after main() exits, but that basically never happens for an embedded app.

Occasionally you may run into situations where the compiler generates a call to some strange function that you have to stub out. For instance, you'll see references to __cxa_pure_virtual() are generated if you declare pure virtual functions. I'm not sure why this isn't part of the standard library, but I had to stub it out like this:

Code: [Select]

extern "C" {
  void __cxa_pure_virtual() {
    for(;;);
  }
  void *__dso_handle = NULL;
};

The main thing with C or C++ is to avoid dynamic memory allocation, since there probably isn't enough free memory to effectively use a heap. In the C world, this leads to lots of global variables. With C++, it's much better since you can put everything in objects (i.e., compiler managed structs) and then declare a handful of global objects which represent the entire state of your program.

[Kremmen]

[...]
The main thing with C or C++ is to avoid dynamic memory allocation, since there probably isn't enough free memory to effectively use a heap. In the C world, this leads to lots of global variables. With C++, it's much better since you can put everything in objects (i.e., compiler managed structs) and then declare a handful of global objects which represent the entire state of your program.

You have a point but still, never say never I have used dynamically instantiated classes successfully in Arduino, and in that particular application i considered it the path of least problems. In that case i created the program steps of a programmable camera dolly as a linked list of action objects whose precise number of course depends on the contents of that particular sequence program. Worked like a charm even in the puny RAM of a Mega328.
Another, perhaps even better reason not to use dynamic allocation, at least in safety critical applications is the nondeterministic nature of dynamically allocated memory. It wouldn't do for say a nuclear reactor controller to run out of allocatable memory due to fragmentation and delayed or nonexistent garbage collection... (Not that that specific application would be left to one single microcontroller anyway).

[andyturk]

You have a point but still, never say never I have used dynamically instantiated classes successfully in Arduino, and in that particular application i considered it the path of least problems.

Sure, it can work and it's not hard if you simply assume your allocations will always succeed. To be correct, however, you should consider that those dynamic calls could fail, and then what? On a small device with minimal UI, you can't really pop up a dialog and alert the user. Halting is one option, and rebooting is another, but neither is very attractive for a device in the field.

But if it actually is safe to assume all allocations will succeed within the limited memory available, then that means there is an upper bound on what your program actually needs. Making those bounds explicit is the main difference between dynamic vs static allocation. For instance, if your Bluetooth gizmo only needs to communicate with two peer devices, you can pre-allocate (at compile time) buffers and such for those two connections and guarantee you won't have to handle an out of memory situation.

This is the approach taken by ChibiOS (a very nice open source RTOS) and it works incredibly well. C++ makes it even easier because the compiler will generate most of the initialization code for you (as long as you've written constructors).

[nctnico]

The main thing with C or C++ is to avoid dynamic memory allocation, since there probably isn't enough free memory to effectively use a heap. In the C world, this leads to lots of global variables. With C++, it's much better since you can put everything in objects (i.e., compiler managed structs) and then declare a handful of global objects which represent the entire state of your program.

That depends on how you define dynamic memory. I always use a scheduler so there is only one 'process' doing something. This means that every process has the entire stack size at its disposal. It is a very efficient use of memory.