views:

1164

answers:

10

Hi all, Could someone please tell me if it's possible to burn an 8051 microcontroller with a C++ program? I've tried searching about it online but can't seem to find out for sure if it's possible or not. Keil uses C, but the program I need to write is very string-intensive and C is quite string-unfriendly as compared to C# which is what I'm used to using. At the moment, I'm trying my hand at writing the code in C but it's getting really messy, so I'd be extremely relieved if I could write it in C++ instead.

I would need a C++ compiler that creates a Hex output file that can then be burnt onto the microcontroller. Anyone heard of something I could use? And also, C uses a header file that lets you refer to ports, but when I tried to find out if this header file is used in C++ as well I couldn't find any information on it.

Addition: The microcontroller I'm using is an Atmel AT89C51 with 4K Bytes of Reprogrammable Flash Memory, and 128 x 8-bit Internal RAM. This is actually for a Robot for a project at university and the coding does not actually require OOP. It just has a lot of look up tables that are in 2D string array format. The only reason I wanted to consider C++ was because of how messy manipulating strings seemed to be getting (due to MY lack of expertise in C).

And does anyone know about the header file? C uses #include reg51.h but I tried to find out if this works for C++ and couldn't find anything on it.

+2  A: 

There is a commercial compiler from ceibo.

However if you can use c++ (especially STL string) depends on how much resources (both ROM and RAM you will have.

There's a 8051 site with forums, tutorials and downloads where you may get some more resources for programming the 8051.

lothar
+7  A: 

I would question whether this is really a good idea in the first place. I understand the reasoning behind wanting to use c++ over C in the general case but in the case of an 8-bit Harvard architecture microcontroller I would warn against this.

Things to bear in mind include:

  • Source-level debugging support will be somewhere between poor and impossible.
  • Runtime overhead of OOP on an 8-bit machine. I would strongly recommend doing some serious benchmarking before committing to a tool.
  • Memory isn't cheap in embedded systems and you will no doubt have some address space limitations.

Also, if you really are going to be doing some serious string handling I would recommend using the C standard library rather than a string object library simply because you have better control over in-place substitution and so string copies become glaringly obvious in the code.

Please post a little about the microcontroller you plan to use (Data Memory, Program Memory) and whether there are any performance requirements that must be met so we can help a little more concretely.

mikelong
"Source-level debugging support will be somewhere between poor and impossible". IMHO it won't be different from debugging C. If the target has JTAG it should be fairly strait forward if the debugger has support for it.
lothar
From what I understand, all of the 8051 C++ tools translate to C and use a popular platform such as Keil tools or IAR systems. It is these tools that then perform the IDE debugging support. Of course I could be completely mistaken :-)
mikelong
+1  A: 

You might want to consider providing additional detail about the sort of program that you intend to run on that microcontroller:

You mentioned C++, as well as C# in your posting, both of which are surely not ideally used for heavy string processing on a microcontroller, not to mention that you are probably considering heavy use of the STL, which would furthermore increase the size of the executable?

So what exactly are your primary constraints (RAM, CPU, ROM etc)?

If you really think that you need to do this string processing in an OO fashion, you might want to consider running a lightweight embedded scripting interpreter on the controller, so that you can then provide your string processing routines using the scripting language, while the interpreter itself would be ANSI C compiled to a HEX file (e.g. lua or nasal would both seem like suitable candidates).

However, take into account that a scripting language such as lua will usually impose approximately 100kb+ of overhead in space, Nasal is somewhat more lightweight and may compile down to 50-70 kb if you disable certain extensions.

Also, there are other scripting interpreters available that are specifically meant to be used on embedded platforms.

none
For a processor like this, running a scripting engine would be massive overkill. Far better to write some efficient string routines in C or C++.
Steve Melnikoff
it really boils down to what he needs to be done, there are many other embedded targets like for example routers which also don't provide much more power than say an 8051, but are still using scripting engines, i.e. in order to provide a flexible and browser-usable UI
none
@none - I'm a she by the way! :-)
CodeConfused
Most 8051 controllers i've seen have around 4kb of memory.
rlbond
A: 

There are several commercial compilers available. The number 1 in the industry is from Keil Software.

Chris Lively
I've used Keil before too. IMHO, their IDE is the best option for 8051 C development. -- But my scans of the website lead me to conclude they do *not* offer C++ compilers for 8051's. Am I missing something?
Nate
I just spoke with one of their dev's, and you're right. It is C only. So, my answer doesn't really meet the OP's requirements. ;
Chris Lively
+2  A: 

IAR Systems have a 8051 compiler which can compile C++ natively (no translation to C), and source level debugging shouldn't be a problem either.

JesperE
Here's a link for IAR's C/C++ 8051 compiler: http://iar.com/website1/1.0.1.0/244/1/
Nate
Thanks, post updated. I was just too lazy to dig up the link.
JesperE
A: 

You could try to convert the C++ code to C code and then compile it with your existing C compiler. See here for a few links to compilers which can convert C++ to C.

You should be able to create a Makefile which calls the C++ compiler and then runs the C compiler afterwards.

It's not the most elegant solution but it really is pretty unusual to use C++ on small devices such as the 8051.

Disclaimer: I have not actually tried this so good luck! If it were me, I'd stick to C and write some robust string-handling functions.

Adam Pierce
A: 

Others have mentioned that there are C++ compilers for the 8051. I'd guess your main issue with those is going to be cost. Lots of companies will let you write assembly for free but charge for the C or C++ compiler. We're probably talking a few hundred dollars here.

My main question is what is getting 'messy' in your code? What features are you trying to use in C++ that is getting messy in C? Some of the features in C++ don't translate well to such a minimal embedded environment (streams, constructors, destructors, etc). C can do many of the object-oriented type functions with structs. Other functions should just be avoided (anything with dynamic memory management).

I'd make an effort to make it work in C before potentially spending lots of money and getting code that is large, slow and unwieldy.

Stephen Friederichs
I'm beginning to think you're right, Stephen. :(There just isn't anything easily available.
CodeConfused
+1  A: 

IAR appears to offer a C/C++ compiler for 8051's. -- But in full disclosure, I have only used Keil's C compilers for 8051 development.

As for your header-file concerns: The header files are often distributed by either the IDE vendor or the hardware manufacturer and often provide a symbolic representation of your register mappings. A modest amount of massaging may be required to incorporate a C-based header file into a C++ project. -- If you're about to switch IDE's / compilers you can often expect some massaging of your source code to accomodate the new compiler. (Read: accessing C code from a C++ code-base often causes me to stop for a day to do it right.)

Nate
A: 

It sounds like you want a C++ compiler so that you can use std::string. std::string requires a heap. You won't have a usable heap with only 128x8 bits of internal RAM, especially not for std::string objects Consider that if you read an 80-character string from a serial port, that consumes over 60% of your available RAM. Are you also going to use external RAM? How much?

Does your firmware really need to handle string processing at runtime? For example, does it send/receive commands as strings via a serial port or some other interface? If so, you should isolate the string handling from the rest of your code as much as possible, and use tokens (enumerated types or #defined integral constants) elsewhere. If not, you will have a lot less trouble fitting your logic into your processor's constrained memory by using tokens instead of strings.

Also, if you do need to do string parsing, you may be better off writing a state machine that processes characters one at a time, so that you don't have to deal with full strings. Again, 128 bytes is not a lot of space for string processing.

bk1e
Just a clarification. As you know, std::string is just a typedef for basic_string, with char and an allocator. Instead of that bulk allocator, a custom allocator can be implemented, where no heap memory is used.
Johann Gerell
@Johann Gerell: I suspect that writing a custom STL allocator that manages strings stored in ROM would be significantly more difficult (if even possible) than rewriting the string processing in C. Keep in mind that the OP's target system has only 128 bytes of RAM and 4 KB of flash. That means that the lookup tables must be stored in flash.
bk1e
A: 

Why not use a C string library? Like bstrlib or similar? C++ just isn't what you need for this microcontroller.

rlbond