SparkFun Forums 

Where electronics enthusiasts find answers.

Everything ARM and LPC
By tgil
#155629
I am looking for anyone to chime in on what they recommend to use on LPC micros: C or C++ and why. I have always used C, but it seems there are advantages to using C++ (stronger type checking for example). What do you think?
By cfb
#155683
I would not recommend either C or C++ if you are really serious about type safety and reliability. However, if you do not want to consider anything else, your best bet would be to choose a system which allows you to check that your code conforms to the MISRA guidelines for the use of C / C++ in critical systems:

http://en.wikipedia.org/wiki/MISRA_C

We took a different approach altogether and ported Niklaus Wirth's ARM Oberon compiler so that we could use it to target the LPC2000 and Cortex-M3 MCUs. As Oberon is a direct descendant of Modula-2 it is ideal for use in devloping type-safe and reliable software and has additional features suited to the sort of low-level programming required when targeting MCUs. We now sell and support the resulting development system (Astrobe):

http://www.astrobe.com

An analysis of the MISRA guidelines showed that about 70% were redundant when applied to the Oberon programming language - it does not allow you to shoot yourself in the foot as easily as you can do with C.

There have also been some encouraging recent developments enabling the C# programming language to be used to develop embedded software:

http://en.wikipedia.org/wiki/.NET_Micro_Framework

Unfortunately, the larger footprint required for the .NET Micro framework (300kB ROM, 64 kB RAM) rules it out for many of the smaller MCUs typically used by SparkFun customers.
By stevech
#155738
Seems to me that MISRA doesn't apply to a hobby or non-life-support product.

IMO, C++ is the best choice for smaller (non-Linux/Android) ARMs including the LPCs.
By fll-freak
#155765
MISRA was targeted for life safety systems like a "sticky accelerator", or ABS braking system. But that does not make its rule set invalid for every day operation. I use MISRA for both work and home to great advantage.

As for the C or C++ issue, I would have to say I have a distinct bias towards C. Part of the issue are some very bad experiences early on with C++ when it was molasses slow and buggy. But even today, I shy away from C++ for embedded work. If you start using standard library or STL classes, you get to take on the risk that they may be using malloc/free/new/deletes that you are not aware of. And in my world, dynamic memory allocation is the top most sin.
By tgil
#155808
Interesting comments. I've heard of MISRA but haven't used it much. At one point, I even bought a copy of the standard.

It seems the general consensus (in this discussions and others) is that C is preferable over C++. C++ has stronger type-checking and other features that could be great for embedded. People seem to shy away from it because of the run-time resources required: dynamic memory allocation, run-time typing, exception handling. All of those can be omitted, but it is tricky.
By fll-freak
#155811
The "general consensus" here is only a few samples. Not really enough for a good idea as to what is going on in the industry. I know of people that use C++ in embedded systems. But these tend to be large system using Power PCs, large memory banks, and a small to medium nuclear power plant to run it on. On the other extreme are the MSP430/PIC type processors where you might only have 256 solitary bytes of memory and assembler might be your only option to take advantage of all the power savings.

Dynamic memory allocation for the life critical applications I am involved in is strictly discouraged. I have even heard of one automotive ABS system that did not run their code in a loop. Each iteration of the code caused a full reboot of the processor as a massive overkill garbage collection mechanism. But it does make testing very simple!

As for MISRA, there are some very good practices to be taken from it. There are also a few "WTF" rules that simply do not make and sense. So we have developed a style guide that allows us to waiver the totally idiotic rules and fully implement the rest. Out compiler of choice provides for automated testing of many of the rules. Some are simply not possible to automate and are either ignored because they are of no value to us, or are part of the peer review checklist.
By cfb
#156373
"Dr. Dobbs" recently published an article by Andrew Binstock about C and C++ titled "Why Code in C Anymore?":

"The traditional reasons for preferring C to C++ have been steadily whittled away. Are there any good reasons to still use C?":

http://www.drdobbs.com/cpp/why-code-in- ... /240149452
By fll-freak
#156378
One reason is to make the code more understandable and maintainable! C++ was supposed to help these two characteristics of good code, but most often it is a hindrance. When you have all those fancy things like polymorphism and template classes they get used for everything. At some point you get soooooo removed from what is going on it makes maintenance impossible. Now part of that should be tempered by good peer reviews, but if you get a bunch of C++ yahoos on a project peer reviewing each other than the quality of the code suffers.
C on the other hand forces a significant degree of obviousness (baring obfuscation yahoos!). I wish there was a C+ language that allowed for some of the better features of C++ but without the crazy features. Or perhaps a version of C++ where a configuration file would allow or disallow certain structures.
As it stands, my C coding standards and practices make my code modular like C++ classes and yet retain the obviousness and no reliance of new/delete (even hidden ones).
User avatar
By viskr
#156385
While we still use C (can't teach old dogs and all that), in our effort to support Sketch we had to add C++ support to our pre-configured gcc tools.

In doing so we found that there was not much of an overhead penalty for going with C++ in most things. A couple exceptions, which could probably be fixed involved strings which seem to have a lot of probably useless code on the C++ side.

While our tools target the LPC devices we use, they are general purpose enough for the entire line of LPC parts. Devices we use include the LPC814, LPC1114, LPC1751, LPC1756, LPC2103, LPC2106, LPC2138. If someone has a downloader for ST parts, that could probably be added.
By cfb
#156395
fll-freak wrote:I wish there was a C+ language that allowed for some of the better features of C++ but without the crazy features.
When I have to use something other than Oberon / Component Pascal / Delphi, C# is the next best alternative for me.
C developers would be more comfortable with the C-like syntax and general behaviour of C# and Generics seem to be a better solution to the problem that Templates were supposed to solve. NXP has an implementation of the .NET micro framework for the LPC2387 and LPC2388 called FEZ:

http://ics.nxp.com/support/tools/fez/
By cfb
#156399
viskr wrote:If someone has a downloader for ST parts, that could probably be added.
STM's STM32 Discovery boards include built-in ST-Link programming hardware which uses a USB connection to your PC and STM's STM32 ST-Link Utility software to program the boards. You can download a copy of ST-Link from here:

http://www.st.com/web/en/catalog/tools/PF258168

We used the ST-Link software ourselves to load the flash ROM of a couple of different STM32 Discovery boards to run our LPC1xxx Cortex-M3 Oberon executables:

http://www.astrobe.com/forum/viewtopic.php?f=7&t=206

The process is similar to using NXP's LPC-Link software to program the Cortex-M3 LPCXpresso boards.