Yep, with languages it's horses for courses.
Languages with strict bounds-checking and perhaps automated garbage collection (eg: Modula2, etc) are more suited to applications which involve complex data-structures and a lot of dynamic memory allocation.
C is (IMHO) the best alternative to assembler when you want to cut the fastest code and retain maximum control over how your processor handles things.
As for managing memory allocations, ensuring pointers are correctly referenced etc -- well that's down to programmer discipline and good practice. A bad programmer can write bad code in any language.
One thing I found when moving from PC-based systems to MCU-based ones is that life is much simpler in the MCU world. The interface between the MCU and "the real world" is usually far more clearly defined and the absence of "wetware" in the input stream makes it far easier to come up with a solid specification in the first place.
I wouldn't write an accounting suite in C (although I have been forced to in the past) and I wouldn't write a realtime MCU-based process controller in COBOL either :-)
Someone had mentioned that http://www.mikroe.com/ is a good place to begin. It offers tutorials, book, kits, etc.
I use that too
they are good for starting but the libraries are crap
Could you please specify this? I used a lot of their libraries, almost no problems.
On Their forum you see sometimes minor complaints, but there are other options now with their Libstock.
I use the PIC16F690 to control all of the solar powered LED lights in my home via a networked master/slave system. All of the code was written in assembler using MPLAB and a PICSTART Plus programmer. I like the low overhead and device level control of assembler. I still have over half the programming space remaining in the master controller.
For the future people reading this thread let me put a history of some of the embedded platforms I've used for hobby purposes and lessons learned:
1) PIC16F84 + RS232 programmer - I paid a lot of money for the ancient chip (it was 10 years ago and it was already ancient). It needs crystal and caps to be able to do something. Spent most of the time fiddling with wires, getting the chip in an out of the programming socket, reading assembler code examples.
Firmware upgrade time took about 2 minutes, including chip swapping.
Lessons learned: get the newest pin-compatible chip. Try to aim for integrated oscillator and wide operating voltage range. Go for the biggest memory given the same footprint.
2) AVR Butterfly - this was a complete dev platform based on an AVR Mega169. It was pretty similar to how Arduino is today BUT it had also some necessary peripherals included: display, buttons, piezo, battery. I spent most of the time trying to set up the toolchain and study the incredibly complicated examples (for a beginner) to make something useful. I picked it up again two years ago was able to program some stuff on it with the experience I gained in the mean time.
Firmware upgrade time took about 30 seconds, as I remember.
Lessons learned: integrated hardware helps a lot, so it pays to buy a thing that has most of the stuff you want included. You will want an LCD and buttons, you will want easy USB uploading. Toolchain and user support makes all the difference for a beginner.
3) PIC16F628 + PicKit2 - pretty rewarding experience because there was already a lot of support back then (5-6 years ago) for PIC MCUs. The pickit is especially nice because it can power the breadboard project, view the outputs on its signal analyzer, view the debug data on its RS232 terminal. Whenever you feel like experimenting with a new PIC just pop out the old chip from the breadboard and plug in a new one. Then spend some time rewiring because every pin is in a different place.
Went through MPLAB, asm, HiTech Picc, SourceBoost, back to MPLAB X because no toolchain provided exactly what I wanted for specific projects. SourceBoost had a nice IDE but the compiler was not free and the simulator was buggy. MPLAB had an accurate simulator but awful IDE. Microchip's ASM compiler was free but what hobbyist uses assembly? (except for fun or challenge). PICC was nice but VERY limited in its free version and costs a lot of money for the paid version (as far as I remember).
Firmware update time: about 15 seconds, I had to manually switch to the PicKit tool.
Lessons learned: a tool that offers the basic electronics bench tools is well received. Ok, a soldering iron and a multimeter might be in every house (though not necessary) but a nice power supply, signal analyzer and scope are not. Productivity and learning go up as fiddling time goes down. Switching compilers and IDEs is a pain, every one has different coding conventions, shortcuts, names for pins.
4) MSP430 launchpad - I don't remember ever using it. I got it two years ago because it was cheap. I might go back to it, see the stellaris section.
Lesson learned: unless the new dev platform offers more than the previous platform you are used to it will stay unused. In my case the low-power stuff wasn't very interesting and the board wasn't particularly powerful compared to the PICs I used. I also had to learn a new IDE (TI proprietary stuff) and coding style.
5) Stellaris Launchpad - this one stayed in my drawer as well for a few months. Then I watched some tutorials and got interested in its capabilities. After installing the toolchain I saw that it was actually Eclipse in disguise, a tool I've used almost every day for the past 8 years or so.
The board is quite overpowered but has a pretty low community support so I had to struggle with it. What kept me going was the familiar Eclipse environment and STEP BY STEP debugging. I cannot overemphasize the importance of this, being able to step through your code and check the memory and registers after each line. And on the REAL unit, not in the simulator.
Oh, firmware uploading time is about 2 seconds, the time it takes for the project to build.
Given that I know understand what the Stellaris[ware] ideology is like, I might go back to the MSP430 to use it for low-cost, low-power projects. It's most of the times cheaper than having your own design.
Lessons learned: choose a tool with a well-supported IDE. If you don't know what, choose Eclipse, it's pretty much industry standard and free, with support for a lot of languages from ASM to PHP and really nice code automation features. Choose something with step-by-step debugging whenever possible, it will make life a lot easier.
6) Arduino - I don't have one and will probably not have one unless it's very cheap or absolutely needed for something. BUT, it would be first on my beginner recommendation choice. It is like I recomend iPads to non-tech savy friends seeking advice for a tablet, even though I haven't used iOS in years.
It has the best community support, most hardware projects that you can just copy and paste, every add-on imaginable and bearable tools.
I think the only downside is the price, you are practically paying a premium for all this stuff. However, once you are confident enough you can build your own 'Arduinos', which are actually just a bootloader on a 3$ chip and some surrounding stuff.
That still leaves the problem of shields, which have again a pretty high markup just for bearing the 'shield' or 'arduino compatible' tags. But again, with consumption comes volume and competition which helps to bring the prices down and quality up.
I do have some other stuff in my drawers that I've never touched (like TI Chronos) so it makes sense to buy once and buy smart.
The MikroE stuff is very nice, but Arduino is now like an industry standard and I would choose a good community support over an good commercial support any time.
Phew, that'a long rant, I might be getting bored.
Perhaps I should add the higher end development platforms here: Raspberry PI and Android.
Raspberry PI:
Very nice hardware capable of doing most of the stuff a beginner would want to do. Currently it is still of a learning curve setting up the toolchain but it's getting there. It has GPIO and that all that you need for blink-a-led. It has HDMI and provided that every house has a modern TV, DVD player or home cinema you should have the display and sound part solved.
If you get bored of it you can still set it up to serve your USB hard drive over the network or some similar utilitarian projects, so it should not end up in a drawer.
Android:
It took me about 30 minutes including reading the tutorials to have my first program running on the phone. Well, that's also because I'm very used to Java, but it shouldn't take much more for anyone.
It doesn't have GPIO, so you can't really blink a led or control a motor but it's more of a unifying platform, because you can control your bluetooth and wireless projects via a touchscreen.
Cost-per-hardware is as inexpensive as it can get. I bought a new phone for 50E and it has the following features: WiFi, Bluetooth, 480x320 color touch screen with backlight, three capacitive buttons, four hardware buttons, two cameras, two speakers, microphone, light sensor, close proximity sensor, temperature sensor, stereo out, mono in, accelerometer, compass, 3G connectivity, one week battery life. For those wondering, it's the Huawei Ideos X3.
"Pointers are a really great and efficient method to deal with data and functions."
And unfortunately, NOT a good way to deal with strings. At least, not as is usually done...
"Pointers are a really great and efficient method to deal with data and functions."
And unfortunately, NOT a good way to deal with strings. At least, not as is usually done...
You have to deal with buffer overflows anyway. Or have I missed what you're talking about?
"Pointers are a really great and efficient method to deal with data and functions."
And unfortunately, NOT a good way to deal with strings. At least, not as is usually done...
True. I have several functions and wrappers to prevent buffer overflows.
NOT a good way to deal with strings.
You have to deal with buffer overflows anyway. Or have I missed what you're talking about?
No, you wouldn't. Or not fatal ones, anyway (comparing to other languages, like BASIC, here.) That's on top of being difficult to use. Strings are a fundamental enough data type that they should have (IMO) more fundamental support built into the language. Having to write:
dest = realloc(strlen(dest) + strlen(src) + 1);
dest = strcat(dest, src);Instead of
dest = dest + src;is ridiculous, and displays fortran-era thinking. In any language there should be a treatment of strings that allows users "typical" usage, without having to worry about the tools behind the curtain, or pointers, or details of the dynamic memory allocation system, or the details of the structures actually use to implement strings. This is probably getting into a weight of run-time-environmemt that the C designers were uncomfortable. But other languages (BASIC, PL/1, PASCAL, and on and on) didn't seem to have huge problem doing it in a useable and reasonable way.
String handling is one of C's weakest points, that's for sure. Not much can be done since that is the way the language has been defined and it is too late to think about changing it.
C++ to the rescue. If the default string classes don't work for you, just roll your own, or extend the existing implementation with your own functionality.
C++ to the rescue. If the default string classes don't work for you, just roll your own, or extend the existing implementation with your own functionality.
C++ strings on a micro? Yikes.
Personally, I'd say that C strings are exactly what you want (on a microcontroller) for dealing with text that doesn't change (i.e., string constants). When you start talking about streams of text that are sent/received with the outside world via UARTs or whatever, you should probably be thinking in terms of buffer objects.
C++ to the rescue. If the default string classes don't work for you, just roll your own, or extend the existing implementation with your own functionality.
C++ strings on a micro? Yikes.
Personally, I'd say that C strings are exactly what you want (on a microcontroller) for dealing with text that doesn't change (i.e., string constants). When you start talking about streams of text that are sent/received with the outside world via UARTs or whatever, you should probably be thinking in terms of buffer objects.
If you are happy with the C string then you have no problem. My reply was meant to suggest an alternative for those who do have a problem. While the C++ std::string might be a bit on the heavy side in a modest 8 bit MCU, i don't see a problem in writing a basic string class around say a Pascal style string where you have the length stored explicitly. The few bytes needed to store the vtable shouldn't matter unless you truly have heaps of dynamic strings. The upside is that you can hide all kinds of implementations in the inheritance tree, from simple fixed allocation strings to as dynamic and mutable as you want to have. And of course the differences are hidden by the polymorphic access methods. Look at Arduino for instance; it has a string class, and the 328 inside an Arduino is far from a powerhouse MCU.
... The upside is that you can hide all kinds of implementations in the inheritance tree, from simple fixed allocation strings to as dynamic and mutable as you want to have.
If you can use std::string without dynamic memory allocation or exceptions, then perhaps its OK. I suspect that's not the case though, and both of those are deal-killers for "serious" embedded work.
Look at Arduino for instance; it has a string class, and the 328 inside an Arduino is far from a powerhouse MCU.
True, but the Arduino is more of a hobby/learning platform that intentionally relaxes some of the usual requirements of embedded development.
NOT a good way to deal with strings.
You have to deal with buffer overflows anyway. Or have I missed what you're talking about?
No, you wouldn't. Or not fatal ones, anyway (comparing to other languages, like BASIC, here.) That's on top of being difficult to use. Strings are a fundamental enough data type that they should have (IMO) more fundamental support built into the language. Having to write:
dest = realloc(strlen(dest) + strlen(src) + 1);
dest = strcat(dest, src);Instead of dest = dest + src;is ridiculous, and displays fortran-era thinking. In any language there should be a treatment of strings that allows users "typical" usage, without having to worry about the tools behind the curtain, or pointers, or details of the dynamic memory allocation system, or the details of the structures actually use to implement strings. This is probably getting into a weight of run-time-environmemt that the C designers were uncomfortable. But other languages (BASIC, PL/1, PASCAL, and on and on) didn't seem to have huge problem doing it in a useable and reasonable way.
You can't have it all :-) C coders should use safe string functions and/or write their own convenience functions to deal with strings. If you prefer a language which does all the string magic for you, you don't need to worry about the details, i.e. you get the job done faster, but the compiler creates larger binaries and the program runs slower. If you have to deal with string details yourself you got full control and also the key to optimize things. Since most C coders already invented their wheels they simply recycle that code and it won't take much longer to finish the job.
BTW, there's one point with strings where all languages suck: parsers.
If you can use std::string without dynamic memory allocation or exceptions, then perhaps its OK. I suspect that's not the case though, and both of those are deal-killers for "serious" embedded work.
std::string won't work without a heap since it allocates the char arrays from there. As to the general principle of avoiding dynamic memory like the plague, i'm not so sure. Try writing an embedded Ethernet implementation without dynamic buffers (the thing i happen to be working at this time). Can be done i guess, but IMO that would be shooting yourself in the other foot. The bogeyman in dynamic allocations everyone seems to fear is a) the undeterministic nature of the allocation itself and/or b) memory overruns/leaks. True, they can be problems but those issues are far better controllable in C++ since it supports some of it in the syntax. You need to pay attention to your allocation algorithms and strategy but if you can be happy with less than fully flexible heap with garbage collection and suchlike, relatively foolproof implementations are possible. But yes, i grant the point that with dynamic memory, badly behaving code can kill the app. Of course if you use a MCU with memory protection and are willing to handle the exceptions...
[...]
True, but the Arduino is more of a hobby/learning platform that intentionally relaxes some of the usual requirements of embedded development.
That was only an example. Once again: roll your own and be happy. Or if not, you can blame the guy in the mirror
At one of my former employers I wrote a linked-list dynamic memory handler. It has its own API to walk through linked blocks of memory and in the end I also had malloc, realloc and free working while keeping memory consumption completely in check.
Did the a similar thing for a lowly Arduino. A camera dolly controller where all the control actions were implemented as a dynamic linked list with persistence into the EEPROM. Since i used C++ it was a class tree with inheritance and new, delete implemented using malloc and free. Worked like a charm.
std::string won't work without a heap since it allocates the char arrays from there.
That's what I thought. I've looked at the std::string code a few times, but like a lot of STL it takes a long weekend and several pots of coffee to actually figure out how it works.
For server-side programs, std::string (with exceptions) is just fine. When I used to do Java stuff, I had no problem with Java's String, which has equivalent magic inside. But when you're driving a car with an automatic transmission, you can't really complain about the power brakes.
As to the general principle of avoiding dynamic memory like the plague, i'm not so sure. Try writing an embedded Ethernet implementation without dynamic buffers (the thing i happen to be working at this time). Can be done i guess, but IMO that would be shooting yourself in the other foot.
Ha! Well, one of my current projects is fixing up a Bluetooth HCI stack that runs on MSP430. Every packet is malloc'd and free'd, which is potentially dangerous because there's tremendous opportunity for heap fragmentation. 8K of RAM and they're hitting the memory allocator several times a second even when the RF is quiet. I didn't write this code, it's just my job to fix it.
It's certainly possible to "prove" that your malloc/free new/delete calls aren't going to fragment the heap and crash your device. But once you get to that level of certainty, you've already done most the work to statically allocate pools of objects. For me, the static allocation issues are more familiar and I'd rather start off that way than be forced to go there when things break.
If you can use std::string without dynamic memory allocation or exceptions, then perhaps its OK. I suspect that's not the case though, and both of those are deal-killers for "serious" embedded work.
But this subthread started from westfw wanting "dest = dest + src;" semantics for strings - at that point dynamic memory allocation is already a fact of life.
[...]
Ha! Well, one of my current projects is fixing up a Bluetooth HCI stack that runs on MSP430. Every packet is malloc'd and free'd, which is potentially dangerous because there's tremendous opportunity for heap fragmentation. 8K of RAM and they're hitting the memory allocator several times a second even when the RF is quiet. I didn't write this code, it's just my job to fix it.
It's certainly possible to "prove" that your malloc/free new/delete calls aren't going to fragment the heap and crash your device. But once you get to that level of certainty, you've already done most the work to statically allocate pools of objects. For me, the static allocation issues are more familiar and I'd rather start off that way than be forced to go there when things break.
I am not suggesting that it wouldn't be a good idea to allocate the memory statically. One strategy is to assign a pool of buffers and just reserve and release them (inside the implementation, but not in the sense of generic dynamic resources). Another successful (dynamic) scheme is to only allocate/free a set of discrete block sizes. That way the heap won't actually fragment because there is always a correctly sized block in the free pool. You just have to see that the allocator is able to pinpoint it (or create one of course, if a free one doesn't exist). This does not avoid the problem of exhausting the heap, but it does mitigate fragmentation.
But this subthread started from westfw wanting "dest = dest + src;" semantics for strings - at that point dynamic memory allocation is already a fact of life.
It doesn't have to be. "Strings" could always be MAXCHARS long, for instance.
It is a common aspect of poor software engineering to think that a feature should do all things for all purposes. I'd be perfectly happy to let "complex" string tasks be relegated to pointers to dynamically allocated regions of bytes, if only the "simple" little string tasks that show up in almost all programs could be done safely by beginners without having to understand all the things that can go wrong with pointers. (recently seen: "char *mystring; sprintf(mystring, "%i %i", 99999, 12345);")
BASIC has reasonable string support, for instance. EAGLE's ULP language looks like C, but has (reasonable) strings added. It can't be that hard. People just get hung up on stuff like "it'll have to have automatic garbage collection, and carefully avoid fragmentation of the dynamically allocated memory, and be absolutely as efficient as inhumanly possible, and..."
But this subthread started from westfw wanting "dest = dest + src;" semantics for strings - at that point dynamic memory allocation is already a fact of life.
It doesn't have to be. "Strings" could always be MAXCHARS long, for instance.
It is a common aspect of poor software engineering to think that a feature should do all things for all purposes. I'd be perfectly happy to let "complex" string tasks be relegated to pointers to dynamically allocated regions of bytes, if only the "simple" little string tasks that show up in almost all programs could be done safely by beginners without having to understand all the things that can go wrong with pointers. (recently seen: "char *mystring; sprintf(mystring, "%i %i", 99999, 12345);")
If you ever programmed with Delphi you can see where that leads to: about 4 or 5 different string types each with a bunch of conversion functions and each has its unique features you'd like to have in the other. On the other hand: universal is good until is becomes a quest for the holy grail.
I started with an Arduino starter kit. I highly recommend it! The controller is and code is VERY well documented on the arduino web site. Now I play with all sorts of microcontrollers. Learning code with it paved the way for learning other languages. Just my $0.02
I started with a PIC16F84 more than 10 years ago, and I still belive it is a very good choice to begin with. Even though it is a very outdated uc, it has an extremely low amount of built in hardware peripherals. Therefore very few registers, which usually gets beginners confused. A very simplistic, low register count, low instrunction count, with tons of project on the internet. So if you can grab one cheaply, (becouse there are far more powerful modern uc's much cheaper) it is a very good controller to start with.
I would recommend PICKit or just a USBAsp programmer and go with bare AVRs - best way of learning is to implement the chip itself without any shield garbage around it!
Start with something small like the ever popular ATMega 8 or ATTiny series chips.