New to Embedded Software

Embedded systems is itself a huge topic with a vary wide scope - talking toys to UAV's all come under the real time banner. Did you have a narrower idea of where you wanted to fit into the spectrum?

C is still king in the lower end embedded market. I would suggest buying yourself some cheap hardware that comes with good demos that you can get your teeth into. Demo and eval hardware is now often sold at what must be cost price, so you can buy a selection. You can download free and evaluation versions of compilers too so can get up and running for very little cost. The Demos section of the FreeRTOS.org WEB site provides plenty of example low cost tool chains and hardware.

I guess I would like to work on projects with a real scientic twist, during my university work placement I go to write software that interacted with a time domain reflectrometry probe to measure oil levels in water coolant pumps in Nuclear reactors. Something similar in nature would be great but I am open minded.

Buy a few development boards and compilers and then build things. If these things won't be on your work-related resume, perhaps put up a "things I built and how I built them" web page to show prospective employers that you're not "just" a Delphi developer.

Languages: C and assembler.

Operating systems. None. This is work at the bare metal level.

Know your way around an oscilloscope and logic analyzer. Be able to design and build your own interface circuits and read/understand the schematics for the things to which you'll be interfacing.

Sparkfun has a lot of dev boards and project ideas. A good "get your feet wet" project could be to read the voltage at an A/D port and display the results on a generic HD44780-based character LCD display (these are widely available as inexpensive "surplus" if you're not overly particular about the size of the display).

For chips, my own preference in the 8/16/32 bit categories are Atmel AVR, TI MSP 430, and NXP LPC2000 ARM7s. Your mileage may vary. I like Imagecraft compilers for all of these but there are many other options, including flavors of gcc.

You'll probably get lots of advice, much of it conflicting. With that warning, what I'd do is to start with two uC families, an 8-bit (suggest 80C51 or AVR) and a 32-bit (suggest ARM7). Get a simple development board for each family, one with buttons, leds, an LCD character display, and whatever else catches your fancy). Find suitable software tools (the board mfgr can point you in the right direction) and start writing simple programs - you can find lots of ideas on the net. As was mentioned, C is the primary language you will need to learn because it is ubiquitous in the embedded field. Having said that, you should also learn enough about the assembly languages of your chosen families to be able to at least understand the code produced by the compiler. I'd even recommend you write a couple of small programs in assembly, because I think you'll get a better sense of what's happening under the hood. Others may disagree.

One critical skill you will need to learn is how to use interrupts. Become comfortable using interrupts for timing, communications and other events. Get a feel for doing the time-critical work inside the interrupt while leaving additional work to be done in the background. Learn how to access interrupt-read and interrupt-written data safely. Learn about "volatile".

Finally, install an RTOS on one of your boards (the ARM board would be my choice), and learn how to write responsive embedded software on top of an RTOS. Responsiveness is one of the keys in the embedded world, RTOS or no RTOS. Being frugal with limited system resources is another - things like not filling up your limited RAM with strings that could live in flash, making judicious use of 8-bit variables (and even bit variables) on 8-bit devices, etc.

It's a fun and interesting field. Good luck!

Mike

Funny you should suggest that. I just wired up a little comms test unit with an AVR ATmega48, 3 slide pots and an LCD display, to send out test commands and data over an RS485 line. The LCD display comes from a batch I must have bought 20 years ago, and then forgot I had them. It works just fine. The linear slide pots I just bought from Mouser, OTOH, turn out to be audio taper. Oh well, not a big deal for my purposes.

Mike

Yup. I agree with your earlier post that one of the first things to learn is how to properly interact with a chip's interrupt structure. My generic Hello, World for a new microcontroller (and, I suspect, many other folks do this too) is to toggle a selected I/O pin at a 1 Hz rate based on a timer interrupt. That gets most of the kinks out of the tool chain and gives a basic understanding of the chip and its peripherals.

The HD44780 interface, though, is a good learning tool. RS, R/W* and E do what? How does the crazy initialization work? Read the busy bit or do fixed intervals? If the busy bit, what to do if the display is unplugged and not-busy never occurs? Embedded development means it's embedded in or with something else and understanding the incomplete, incorrect, or contradictory documentation for that something else, and often building a benchtop model of parts of it, is a big part of the game.

Right, and if doing fixed intervals, how do you wait 40us between chars? For that matter, how do you generate a 500ns E pulse on a 20 or 60 or 100 MHz processor? It actually takes a bit of thinking.

But once you've got the display running you've got a great debugging aid. And if you (the newbie) can create an HH:MM:SS display that keeps correct time using a timer interrupt, and only updates the display when a change occurs, and can do other processing in the background, you're well on your way.

Mike

On Sun, 9 Nov 2008 11:00:25 -0800, Scott wrote (in article ):

Get any little development board with a PIC or AVR from Sparkfun. The PIC folks used to have a board that has a nice little compiler and all the goodies. You don't want to get frustrated setting up and debugging a GCC environment. Get one with a TFT display and an A/D converter. Assign yourself the task of making it into a digital oscilloscope and a voltmeter and a frequency meter. Switch modes by pushing a button.

If you are really starting from scratch and are out of touch with working with bits and hex and shifting and all the little machine code tricks and logic manipulations, I would suggest something quite different. Forget the worries about hardware and compilers. Get a development kit from Rabbit Semiconductor (ZWorld). It is a grown up Z80 at about 50 MHz (all those TI calculators the schools use are Z80 -- the HP's are ARM7) but it doesn't matter. They have a very nice mature C variant called Dynamic C and good documentation and sample code and interrupt handling examples plus phone support.

Yes the C is a little eccentric, but it is easier to get started with and much easier to manage and use. The processor is not one of the currently popular types, but that doesn't matter. You solve the same problems the same way. There is a demand for experienced Rabbit programmers.

I used it once in a legacy 4MHz Z80 based plywood mill moisture controller and bumped it to 48 MHz with one of ZWorld's modules, then did a few other new jobs for the same company using the same hardware module. They were able to get buying volume up and the modules were very inexpensive.

I had never touched a Z80 before the project, and aside from rejuvenating S-100 systems, never will again. I would have used an ARM7 but the managers were uncomfortable with the change and saw it as a risk. No big deal. It is all ones and zeros.

In fact, I have an unopened development system if you want to buy one cheap. I have been saving it for an occasion where I need to start from scratch with no design and a laptop with no compilers, etc. (and no internet access if need be) and get something going very quickly.

But I think you need a display so you can do the oscilloscope and similar products.

-- Charlie Springer

FYI I'm just doing my first 44780 LCD/AVR project, and I found this software

martin

I see a lot of people are already talking about specific evaluation boards which are good advice for the first foray into embedded programming but for me that is missing an intermediate step. If you only know Delphi then you are right - you need to learn more about general software software development. What languages did you learn at Uni? I was taught four - C, SML, Java and MIPS assembler.

All those languages are fundamentally different in nature and require you to think in different ways. One you are competent with a range of languages such as these, switching to another language is annoying and inconvenient, but nothing more than that because you can put e.g. your SML hat on while getting to grips with Haskell or whatever. Even my four doesn't cover all eventualities, since e.g. stack based languages like Forth and PostScript are different again, but I found I had sufficient background to easily get to grips with PostScript at least, when I needed it.

The language of choice for most embedded work these days is C (not C++) so I suggest learning that if you are not already competent in C. Learn it well and I'd recommend a particular focus on low-level implementation of various data structures, since that is the biggest culture shock compared to higher level languages. A knowledge of assembler is also useful background - it doesn't really matter for what chip (although x86 is probably the wrong place to start) and it needn't be particulary thorough - just enough that you know what is happening under the hood.

Once you know C well, and roughly how C language structures correspond to machine instruction sequences then you will have a much deeper understanding and at a lower level. Then is the time to start thinking about eval boards.

... snip ...

I assume you are talking about the display interface. You can't use the busy signal until after initialization is complete, so you will have to depend on local delays, such as counting instructions. After initialization is complete you can use the busy bit. Read the docs - it is quite straight forward.

... snip ...

You need to know about hardware, C, assembly language, and most important, be able to think. With luck you will get into systems that use better languages, such as Pascal and Ada, but don't count on it.

Thanks, CB, but I'm well aware of the HD44780 init sequence, having done one in C or assembler for several processor families.

The reason that I suggested that task to the guy wanting to get his feet wet in embedded development is that the docs are probably NOT going to be straightforward to somebody not accustomed to bit-twiddling, setup/hold requirements, and the like. The "questions" above were some, not all, of the things the OP might need to think about.

Keil do good compilers etc and you can get limited evaluation versions. Their Demo / prototyping boards are good value and there are lots of example projects.

A few key things - multi threaded ? you must master this. If you have a motor that must be controlled then that must be controlled all the time, and can't wait for user input, so user your Delphi to gain experience of Multi Threaded applications and how to ensure they never give a wrong result. This is fairly new on the desktop - but in the embedded world everything is multi-threaded. In the embedded world crashes are not permitted, so worry about how your multi threaded applications guarantee that the data is never corrupted. Also how would you detect a failure and gracefully recover from it.

Peter

Eden Electronics The embedded system Specialists

When I think of lower end embedded market I think mostly of 4-bit and 8-bit,

We found one with 16K ROM for $0.25 at 25,000 pcs. Our C compiled app is around 8K, so plenty of room to grow.

You have to search outside digikey, if you are serious about cost.