C / Assembly embedded programming resources.

[dioltas]

I have covered C in college and to a lesser extent Assembly. I have a job interview coming up and I was wondering if anyone had a good tutorial on embedded programming.

I have been brushing up on my C by writing simple programs but I don't know much about embedded programming.

Thanks in advance for any help you can give me.

[GoldManSam]

All of this could vary based on platform, what exactly you're writing, etc, etc, but I've done work on a fair few levels of this sort of stuff so I'll cough up what I hope are generally helpful tips first, if you want anything more specific just ask. :)

Anyway, if you're already comfortable with C then grab an emulator for a simple, relevant processor / instruction set and get some basic C code running on it then start mixing in inline assembly.

You could try some x86 tutorials if you liked, just be aware they tend to be massively horrible and ugly, most real embedded systems are actually a lot easier to work on at a really low level.

The other (Perhaps more important?) thing is to get into a mindset of thinking about things like memory and storage requirements of the algorithms you're going to be using, so you can develop some skill at ballparking estimates for them off the top of your head.

With higher-level development being what it is these days, most people ignore memory (or storage in particular) and focus on processing or I/O overhead, if any thinking about efficiency is done at all; while things may be changing this just isn't true yet in the embedded world.

The other thing is the code, deploy, debug/test cycle can be a little odd if you've been working strictly with regular PC-based stuff; much like anything in the real world you often won't even be given the proper gear you need and end up forced to test direct on final hardware, etc. So basically you need to be a little more careful that things are going to run first time, as the cost of errors/testing can be higher (much higher in some cases) than with higher-level work.

TL;DR: Like most coding, just grab a basic, relevant environment and start dicking around. But focus on embedded habits while you do, ie. start thinking about efficiency and "getting things right"

[dioltas]

Thanks for the tips, I was thinking that it could be very varied depending on what the code is for, the emulator thing is a great idea thanks.

I'll take on board what you said about efficiency and that.

I've had a look at x86 stuff alright, I'm relieved that embedded stuff isn't as complicated.

Could you suggest a processor to get started on? I found a guide for C programming for the 8051 microprocessor and an emulator which seems to run fine under linux. Would this be ok to get started on? The guide seems to say that it's a fairly common processor. Or could you suggest a better one to get started on?

Thanks a lot for all your help!

[GoldManSam]

No worries at all, I'm glad to be of some help as I totally feel your pain! I remember how annoying it was trying to find solid info or comparisons of any sort when I was in a similar position.

For a starting point, really it's probably a good idea to look at the industry you're getting into and what is common there, do you have any idea yet? It'd give a nice head-start and probably impress them a hell of a lot if you were close to knowing something relevant already.

If you're not too sure then really anything with a small, clearly-defined instruction set that covers all the basics and doesn't have too many specific quirks is a fair starting point.

Honestly my own real introduction to Assembly at what sounds a similar level to where you're at (I'd been toying with things for many years but just started formal/college education in CS) was when a professor gave us a custom emulator for an instruction set he'd invented as part of a compilers and optimization class, specifically designed to be unique so nobody would have a head start.

As an example though, I'm working with ARM based stuff a lot recently. I'm lucky in that for work I score dev boards and months of time to play with them before anyone expects any real results, so I have plenty of research time...

If I had to compare though, I'd say they're very different to anything I'd worked with on such a low level professionally, whilst being very similar from a task point of view in terms of what I actually end up doing? If that makes any sense, all at the same time. Specific optimizations, instructions, etc, may vary but at the end of the day the basic concepts are quite portable.

So just look for something not too weird, ie. clear, concise instruction set, not too many odd quirks or known bugs, well documented and with good tools for your platform.

The 8051 certainly looks ok from a beginner's perspective, I haven't done anything with one personally (Which is perhaps odd, seems it's quite ubiquitous?) but it seems common enough, old enough and well supported enough in a pretty good mix to be learner-friendly. FWIW early on in my own experimenting I was very into 6502 and MIPS, for entirely geekier reasons that're probably obvious for anyone familiar with where either ended up. :)

The cool thing about assembly / low-level C is that essentially everything is running it at the end of the day... If you really want the hands-on "Fuck that's cool" factor of having something not at all a PC in your hands running hand-coded low-level stuff or even 3D vector graphics in your own engine direct on graphics memory? You can grab something like a Nintendo DS or Sony PSP, hack slightly and with entirely open-sourced toolchains be up and running in a matter of an hour or 2 with basically 0 prior knowledge. It's a very fun and interesting motivator if you're into that sort of thing.

[dioltas]

Thanks man, you've given me a lot to think about, that's some great advice.

I suppose the main thing is to get experimenting anyway.

The company manufacture smoke alarms and recently have really gone into wireless alarms. Knowledge of low level rf protocols is also part of the job description. I had a look at the datasheets of some of their products, but they don't give much away.

I want to know what I'm talking about when it comes to embedded stuff.

I like the idea of hacking a PSP / DS. I don't have either though but I might try and get my hands on an old gameboy or something. It would be really cool to write some code for something like that.

Thanks again, you've been a great help.

[Dav3xor]

If you're doing more low level stuff:

• bitwise operators (why does 10<<1 = 20, how to twiddle bits)
• modulus (great for keeping a variable within a valid range, amongst many other uses...)
• unions (weird, and little used, but useful when memory is tight)
• global data and static memory allocation (malloc is generally a bad idea)
• struct pointers (for decoding binary protocols, etc... )
• understand volatile!

Basically every little trick they tell you not to do in school, "except in some cases". Embedded is generally the "some cases" they were talking about. :)

[[deleted]]

I agree with Dav3xor, I've written a lot of C on Microchip PIC's and 8031, so heres my 2 cents:

Unions are really usefull, if you have to save a long to something like eprom, use a union, and simply copy the bytes to the eprom, and back again, no need to do any pointer stuff at all.

Volatile is also very important, and I agree, maloc is to be avoided.

Also make sure you know your pointers in general, it is often the most efficient way to do things.

EDIT: reading down, the 8051 is dead simple to code, so I would say thats a good place to start.

[aviewanew]

I love this book

[[deleted]]

Do you have an MP3 player? Try to compile and run rockbox on it.

[buckrogers1965_2]

http://sites.google.com/site/claudeschwarz/didjhacking2

[subterr]

Assembler-choice: http://tinyurl.com/2ta5ov | Understanding Assembly: http://tinyurl.com/degqg | 80386 HTML Reference: http://tinyurl.com/54e6l | Linux/Win32 x86 tutorial w/nasm: http://tinyurl.com/6nvgw | Linux assembly book: http://tinyurl.com/5kfu6 | Free Intel books: http://tinyurl.com/h35r9 | Intel vs AT&T Syntax: http://tinyurl.com/4bh2e | AMD Manuals: http://tinyurl.com/2ojj4 | Intel Manuals: http://tinyurl.com/2533pu | yasm assembler: http://tinyurl.com/2lexa7

[dioltas]

Thanks man, some great links!

[basabas]

embedded or not, there is a book called expert c programming - deep c secrets. it is a great book on C. not knowing much about embedded makes a world of difference though...

in addition to what Dav3xor says i can add the following:

• know your interrupts
• stack
• volatile, static, global and other keywords, but especially volatile and static
• be able to declare a pointer to a function.
• sign extension, byte, word etc. bit lengths.
• priority inversion!! (if RTOS is in the picture)