Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
From http://www.altdevblogaday.com/2011/08/06/demise-low-level-programmer/:
"When I started programming many of the elements we take for granted now, did not exist. There was no DirectX and not many compatible libs were available for the free compilers of the day. So I had to write my own code for most basic programs, keyboard handlers, mouse handlers, video memory accessors, rasterizers, texture mappers, blitters… the programs I wrote then were 100% my own code and I had to be able to handle anything and everything."
I am looking for advice on how to learn more about low-level programming. For example, writing a keyboard/mouse driver, a vga driver or basic function like malloc.
What is the best way to approach this? I am an undergraduate CS student and had courses about computer architecture/assembly where we wrote a simple pipelined processor in VHDL on DE0-nano FPGA. I have a decent C programming knowledge.
It seems to me difficult to learn that stuff on a modern x86 computer. Are microcontrollers better (like arduino board) ? Or FPGA (but my DE0-nano seems limited) ? Or maybe buy an old computer like Commodore 64 to learn like the people back then ?
And is there any resources like book on this subject ?
I would recommend a microcontroller approach, msp430, avr, or one of the many arms. You can get an msp430 or one of the arm launchpads from ti for about 10-20 bucks, you can find stm32 based discovery boards for 10-20 bucks as well, the stm32f0 (cortex-m0) is simple, basic. The stm32f4 is loaded with stuff like caches and an fpu, but still a microcontroller.
I think the microcontroller approach will take you back to the roots, very basic stuff, the hardware doesnt have video usually or hard drives or anything, but you do learn how to master the tools (compiler, linker, etc) and how to read the manuals, etc.
You could just fast forward to linux capable hardware like the raspberry pi or beaglebone. At all levels but in particular the linux capable levels, in addition to the manuals for the video chips, usb chips, etc you also will want to use the linux source code to learn from. Understand that the linux drivers are often very generic and often contain code to drive a whole family or whole history of hardware from one vendor, so a bunch of the code may not match anything in the manual, but some will and that is where you will get over the hump of understanding what the manual is saying. Doesnt mean you have to re-write linux in order to use this information.
Start small take it one step at a time, pcie and video alone from scratch is a major task, if you start there you are quite likely to fail unless you already have the knowledge and experience (if you did you wouldnt be here asking).
An approach you can also take is bochs or something that emulates an old 8086 DOS system, and if you can find some good, old, dos/8086 based manuals you can poke at regisiters, cga mode, vga mode, etc. The disc controllers can be difficult still, etc...
There are plenty of arm, avr, msp430, mips, etc (and x86 but I wouldnt go there for this until later) instruction set simulators that would avoid the cost of hardware and also avoid the cost of damaging the hardware and having to buy more (it happens even with lots of experience), even better writing your own instruction set simulator...vba some nds simulators, working your way up to qemu.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I would like to learn something about embedded development. I think the best thing would be to buy hardware stuff and play with it but I don't know where to start and, if possible, I would like not to pay too much....
If you have experience in this field, which would be the best road to follow?
I assume you mean real embedded and not embedded linux or some other operating system thing.
All above are good, sparkfun.com is a GREAT resource for sub $50 cards. Dont buy the embed. The armmite pro is nice, trivial to bypass the high level canned package and load your own binaries (I have a web page on how to do it if interested).
Stellaris is good, the 811 is easy to brick so be careful, the 1968 eval board is not a bad one. The problem with the stellaris boards is almost all of their I/O is consuemed by on board peripherals. The good thing about the stellaris eval boards, based on what you are wanting to do is that all the I/O is consumed by on board peripherals. Lots of peripherals for you to learn how to write embedded code for.
You are going to eventually want a jtag wiggler, I recommend the amontec jtag-tiny, it will open the door to a number of the olimex boards from sparkfun. the sam7 and stm32 header boards are good ones as well.
the lillypad is a good starting place for arduino (sparkfun), same price as the arduino pro mini, but you dont have to do any soldering. get a lillypad and the little usb to serial thing that powers it and gives you serial access to program it. Just like the armmite pro I have a web page on how to erase the as-shipped flash and have a linux programmer that lets you load any binary you want not just ones limited to their sandbox.
avoid PIC and 8051 unless you are interested in a history lesson. the PIC32X, not sure my first one is in the mail, it is a MIPS 32 not a PIC core.
the ez430 msp430 board is a very good one, the msp430 has a very nice architecture, better than the avr.
You can get your feet wet in simulation as well. I have a thumb instruction set emulator, thumbulator.blogspot.com. Thumb is a subset of the arm instruction set and if you learn thumb then you can jump right into a stellaris board or stm32. My sim does not support thumb2, the thumb2 processors also support thumb, the transition to thumb2 from thumb is trivial.
avoid the stm32 primer boards, avoid the stm32 primer boards, avoid the mbed2 boards, avoid the mbed2 boards, avoid the lpcxpresso boards, avoid the lpcxpresso boards!!
I recently found a behavioral model of an arm in verilog that you can simulate your programs, have not played with it much. qemu-arm is probably easier, not a bad place to get your feet wet although it can be frustrating. Which is why I wrote my own.
ARMS own armulator is out there, in the gdb source release for example, easier than qemu-arm to use, but can be frustrating as well.
go to codesourcery for arm gcc tools. use mspgcc4.sf.net for msp430 tools. llvm is rapidly catching and passing gcc, if nothing else I expect it to replace gcc for the universal cross compiler tool. at the moment it is much more stable and portable than gcc when it comes to building for cross compiling (because it is always/only a cross compiler wherever you find or use it). the msp backend for llvm was an afternoon experiment for someone, sadly, I would really like to have that supported. If you use llvm, use clang not llvm-gcc.
If you want to get your feet wet, get a cheap evaluation board like Stellaris LM3S811 Evaluation Kit (EK-LM3S811) which is $50 at Digi-Key then download CodeSourcery G++ which provides free command line tools or the IAR Kickstart Edition which allows you up to 32KB of code.
I would suggest starting up with MSP430. The MSP430 launchpad is quiet cheap. Alternatively, you could start up with the Stellaris (ARM Cortex M3) Boards. You can use the already provided libraries first to start developing apps rite away and then start writing your code for configuring and getting things done by referring the data sheet.You also get example codes, relevant documents and Keil 32K limited evaluation version. If you want to do things write from scratch, then get an ARM based board with IO breakout headers and start working. Lot of them are available from vendors like Olimex. One word of caution ARM is difficult to start with if you are working from scratch with little or no idea about embedded. So if you are looking for something easier go for AVR or 8051, but 8051 core is too old. So, Stellaris would be a good option in my opinion with their already available driver libs and codes.
Well, depending how much money you want to spend, and how much development expertise you have, you could either get an Arduino (arduino.cc) or a FEZ Domino (C# .NET) (tinyclr.com). Both are premade MCUs, with all the tools you need to start developing out of the box.
The Arduino is going to be very simplistic, but probably better for a beginner. The FEZ is a little harder to work with, but FAR more capable. Both have the same physical pinout, so you can use "shields" between them
I would recommend a kickstart kit from iar systems. They're fairly complete and work out of the box.
http://www.iar.com/website1/1.0.1.0/16/1/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have completed my degree in Computer Engineering. We had some basic electronics courses in Digital Signal Processing, Information Theory, etc. but my primary field is Programming.
However, I was looking to get into Embedded Systems Programming, and I have NO knowledge of how it is done. However, I am very keen on going into this field.
My questions :
What are the languages used to program embedded systems?
Will I be able to learn without having any basics in electronics?
Any other prerequisites that I should know?
Without a doubt, experience or at least a significant understanding of digital electronics and low level computer engineering is required. You'll need to be able to read device datasheets and understand them. Scopes, multimeters, logic analyzers, etc... are tools of the trade.
C is used mostly, but higher level languages are sneaking in slowly.
Getting started in Embedded Systems is a complex task in itself, because it is a very vast field with numerous options in hardware and software.
What are the languages used to program embedded system programs?
Assembly Language, C, C++, Python, C# and others.
Will I be able to learn without having any basics in electronics?
Learning embedded systems without the basic knowledge of electronics would not be a good idea. Embedded systems is a mix of hardware and software. You can follow the approach of learning-by-doing instead of going through the lengthy and detailed text books.You can refer to this blog
to learn embedded systems by doing practicals, step by step. It will help you to get started from the scratch.
Any other prerequisites that I should know?
Basic electronics, digital electronics, knowledge of microcontrollers and C programming. Since you are from computer science background you would need a development board of any 8-bit microcontroller (students of EE and ECE have enough knowledge and background to build it on breadboard or pcb) to get started. (Don't prefer simulators in the start, you might get your concepts wrong!).
You have to accept constraints and be able to work with them:
CPU speed
scarce memory
lack of networking facilities
custom compilers and OSes
custom motherboards and drivers
debugging with a logic analyzer
weird coding and testing practices
...
The reward is a deep understanding on what is going on.
VHDL, Verilog, and FPGA's are serious players in this arena as well. With a good background in CS, plenty of commitment, and maybe some MIT OpenCourseware you'll be able to pull off something good. A good knowledge of cpu architectures and some ASM will go a long way too.
I went into that field with no knowledge of how it was done as a fresh graduate and quit after 1,5 years. So, what I say may be a little bit rusty, and definitely not comprehensive.
The language we were using was C. But at that time, the disc space was 4MB and memory was 8MB on the devices we were developing for, and I know that C was used due to its libraries' tiny footprint. Apparently, performance was a criterion as well.
As to basic electronics, for an entry level position almost none is necessary. You will gain the required information and experience with time.
Not prerequisites, but having experience in the operating system internals and system development is definitely a plus.
Embedded systems are generally programmed in C, although there are systems at the ends of the range which use assembler when code space or timing is really tight (or there is no decent C compiler available), and at the other end, C++ up to .NET compact. It depends on what you mean by embedded systems, they go from really small microcontrollers with a few hundred bytes of RAM and program space, up to the smartphone type of device running a full multitasking operating system and user interface.
You'll get further in the higher end of this range without a background in electronics, because its less tied to the hardware and more similar to desktop development. As you go down the range of applications, a knowledge of electronics, analogue and digital, and power supplies, noise issues, compliance issues, heat issues and others all combine to make a really challenging design environment.
Start by reading some of the links here and embedded.com
The one thing that I have not seen mentioned in the answers so far is that up until now you have probably done most of your coding in the context of an operating system. In many (perhaps most?) cases, with firmware as opposed to software, you will not have the convenience and benefits of coding on top of an operating system. This is why so many of the other answers indicated that a good knowledge of electronics was critical.
As others mentioned, embedded can mean many things. In my world (Aerospace and Defense), we work with real-time operating systems (VxWorks and Integrity are the biggest players) and occasionally Linux. We program in C primarily, although C++ is also used as well if the project has decided to use Object Oriented Programming and Modeling.
So, as for the Pre-Reqs, C for sure. You really need to learn all about C, including BIT wise operations, dealing with hex values, pointers, all the low level stuff. Assembly as well, but I only use it for debugging the hardest stuff nowadays. You need to know enough to read and understand.
I think An Embedded Software Primer is a great start to change your thinking towards embedded. Handling interrupts, real-time issues, etc...
As Mickey mentioned, sometimes you don't even have an OS. In these cases, you usually write your own task manager of some sort, but that usually wouldn't be something for the newbie to start with. Good luck.
Languages: C, Assembler, Processing, Basic and a whole variety of others, it depends on what platform you're using as to what's available.
You might get more specific information if you ask the same question at ChipHacker or Electronics Exchange which are both stack exchange style sites (like this is) but geared to electronics and "physical computing".
You'll want to get pretty comfortable with C and build a solid understanding of assembly. In systems / embedded, usually you're working with small amounts of memory and slower processors, so you need to understand how to use limited resources wisely.
If you're getting into this as a hobby, pick up a gumstix board or an arduino, these dev boards will give you hundreds of hours of learning and fun.
If you're trying to make a career of this, find a job where the projects sound interesting and get your hands dirty. Take every task that comes your way and ask yourself how you can do better and learn from this task.
Either way, have fun and happy coding!
Learn C. Learn to apply C to all problems. Other languages can wait. Eventually assembly will help and no programmer should be without the use a scripting language.
Depending on what embedded targets you use there could be very little difference between a PC and your target. With little electronics background this would be your easiest entry.
Small processors will give you the the steepest learning curve but you will learn the most about embedded programming. However with no electronic background this can present extra problems you might not have the skills to solve yet.
Eventually you will have to learn electronics if you want to make further progress beyond the basics.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which family should I start to learn? (Never did any programming on microcontroller)
Today AVR and PIC are probably the most common microcontrollers among hobbyists. Both have a very wide range of device variants and both can be used to achieve similar results.
For a beginner I would suggest AVR due to various reasons:
AVR family (tiny, mega) is coherent and easy to understand. The architecture is powerful and modern, and is especially suitable for C compilers. AVRs can of course be programmed in assembly too.
Due to its C-friendly architecture, there are quality C compilers available, both commercial and free. The ubiquitous GCC is ported to AVR and called avr-gcc.
For getting started all you really need is a handful of basic components, the AVR chip itself and a breadboard. Even the programming cable between PC and AVR can be built essentially for free (a so called wiggler). However, several commercial development kits are available, most notably Atmel's own STK500. A commercial development kit is more expensive way for getting started, but doesn't require practically any prior knowledge about electronics. Some development kits contain for example LCD displays so it's easy to get interesting stuff done.
It has a rich hobbyist community.
PIC is notorious for its peculiar architecture. Many love PIC for this, some hate it. AVR is more straightforward and doesn't seem to cause as much extreme and polar opinions.
Both AVR and PIC are used in many serious commercial applications. However, they are not the only options of course. My personal favorite microcontroller for both hobby and commercial work is Silicon Laboratories' C8051 family, most notably C8051F530. There is an excellent free C compiler and assembler for the C8051 family called SDCC.
Summary: There are lots of options, but please don't let that overwhelm you. Just pick one and start learning with it. Microcontrollers are, really, surprisingly easy to master once you just decide to get going!
My boss picked up the basics using AVR within a week without prior experience.
I would suggest AVR. It has far surpassed PIC as the microcontroller platform of choice for general hobbyist projects. Most notably, consider the Arduino (and other *duino) platform, which provides a high end AVR in an easy to interface and popular form factor.
I very much prefer the AVR over PIC, whose architecture I find a bit messy. This may be just me, and it won't trouble you if you can write in a high level language, most likely (some dialect of) C.
Since you're new to microcontrollers I presume performance will not be the issue, so instead I would look for availability of development tools: prototyping boards, IDE and simulation/debugging tools. Personally I liked AVR Studio (Atmel's free development environment) a lot.
Jason mentions the TI's MSP430, which is an excellent controller indeed, especially if you're in very low power applications. But I wouldn't recommend it for a newbie, since configuration is a bit cumbersome. (I recall that the description of the oscillator covered 20+ pages in the user manual.)
Some people commented on the strange (and C unfriendly) architecture of the PIC micro. This is true of the smaller PICs, but the 16 bit chips (PIC24F, dsPIC30, etc) have very clear architectures that work very well with C.
The PIC24F line has the ability to assign pins to functions (timers, A/D, serial I/O) on the fly, making it a bit easier to design with. The MPLAB environment for debugging and development is quite nice.
I've done some PIC programming - mostly because I liked the idea the chip were only a dollar or two. However, for a beginner, making a decision solely on price is premature optimization.
Programming in assembler is an experience. You basically have to learn about 100 concepts before you can blink an LED. (Watchdog timer, reset pins, 8-bit counters/overflows, delay loops, hex, binary, bit-masking, interrupts, interrupt service requests, IO ports, etc.) It's all very educational - and a great feeling to get so close to the machine - but being able to code something in C will hide some of this complexity so you can focus on results. For this reason I would say go with the AVR. (And I believe the prices are now closer to PICs.)
Also: If you're interested in getting things done (and don't mind spending ~$30) check out the arduino. A guy selling them at my local electronics shop was saying he's selling tons of them to art students. (It uses the IDE from the Processing project, and compiles code with avr-gcc.)
Update: Fixed comment that Arduino runs interpreted code. Also updated the approx Arduino price.
I don't understand what the big deal with arduino is, it will ruin your chance of ever understanding what is actually happening. I program with AVR's and PIC's regularly, basically there is not much difference, I can't see what the big fuss is all about.
However for a beginner stay away from arduino, it may be simple, but thats the trap, it gives you no concept of hardware architecture, and no idea what is happening behind the scenes, the stuff beginners need to learn to be an effective programmer.
When I was a beginner I started out with an ATmega32 a $20 USBasp programmer, AVR Studio (Free) and AVRDude (Comes with WinAVR) and followed the intro tutorials in AVR Freaks.
That is all you need, Done!!!
P.S. If you want to really learn how to program micros and have the time learn the assembler for your micro and you will be 20 times the C programmer than someone who started out using arduino.
My vote goes to PIC for the extreme variety of devices availables. But I must say that when I started to use PICs, they was almost nothing else. Maybe now things are changed.
I vote for TI's MSP430 series. I've used PICs extensively (also Atmel chips a little) and by far the most important thing to me is a good debugging IDE. TI has done a pretty good job on this, and their C++ compiler works really well. You can get going with an eval board for less than $100 including an IDE + USB-debugger. The PICs have better & more diverse hardware peripherals, but MPLAB is a piece of crap and the only C++ IDE for PICs is one by IAR which is rather expensive. (more than $2K)
I/we chose PIC mostly because there is more peripheral hardware for the same price. And more importantly, you can't even find comparable AVRs. I did choose one of the legacy free versions though (started with PIC18, migrated to dspic33)
The IDE is free, the (C) compiler is free in the student version (that disables optimization after the first month). Entry level programmers are fairly cheap too. If you have heaps of interrupts, counters and timers, there is a chance you won't need optimization at all. A programmer straight from Microchip is $30.
Note that the above remarks about AVR catering more to HLL development are slightly outdated unless you really go for the legacy architectures like PIC12 and 16.
One typically programs the more modern PIC18 (8-bit) and the 16-bit architectures (24F,30F and dspic33 which are based on the same principal core) in C. The 16-bitters even use GCC. There are also MIPS based 32-bitters now, but they rival more with ARM in the audio/video processing scene. Strangely enough, the modern ones are often cheaper than the old ones. Probably they are produced on in a more modern process that has higher yields.
Another note: meanwhile Microchip/PIC bought Atmel/AVR, but I assume that for the first few years that won't affect the productlines much.
I'm really looking forward to the 60MIPs ethernet enabled 16-bitter that is going to be released this summer (afaik streetprice just above EUR 10)
If you just want to know what is MCU programming, start from Arduino is a good idea. It's cheap, with a novice-friendly IDE (based on processing programming language, which has a similar syntax with C).
But this did not answer your quesiton, beacuse altough Arduino is based on AVR, you cannot feel there is an AVR MCU behind that modern IDE. :)
I had much more success with PIC while I was just getting started. I tried to get a simple starter kit from Arduino and just couldn't get a good basic kit without spending more than $100-200 nickel and diming the setup together. Got a great little starter kit from PIC for about $40 and it has everything: IDE, programmer, starter board with built in circuitry for demos and tutorials. One purchase. Also, the PIC environment was very easy to get set up and working. I was playing with it within an hour.
My first experience with microcontrollers was with an OOPic-R. It allowed me to make simple robotic experiments without worrying too much about the code. The object oriented programming flow makes everything work fast and is easy to program.
Recently, I tried another variety of PIC's, the dirt cheap PICAXE. The included programming interface is a breeze to work with. Also, to physically interface the PICAXE, you only need an RS-232 port to program it and two pins on the chip (no need to do level shifting). I've embedded the PICAXE in very small containers (SMD and DIP chips available) and it has worked quite well.
I have no experience with programming microcontrollers in assembly. If you want to try that, the AVR might be more suitable because of it's bigger user community.
As far as I know, the cheapest way to program an AVR using ATMEL's tools is the ATMEL AVR ISP mkII for 35$. You can find third-party programmers for 10-15$.
I would make my choice based on availability of a C cross-compiler. In the past, that would make AVR the choice. I'm not sure what the status is now.
I've programmed a PIC in assembler, and it was not much fun. C is much nicer in many ways.
http://www.arduino.cc/
HTH
On of the best features of AVR is the community in the forums at www.avrfreaks.net. You get a bunch of experienced electronics engineers hanging out, willing to help newbies to get going.
I would say that i fount the 8051 microcontroller the most easiest and Atmel has come up with microcontrollers with so many inbuilt functions .... but still people are more preferably using the AVR's... my hand would go up with the 8051 family ( if found comfortable ) else the AVR's ...
I love AVR. its easy to program and resources available. there are few community like arduino works with it.
Some more dicussion about the superiority of AVR, on the other Stack Overflow:
http://embeddedgurus.com/stack-overflow/2009/04/pic-stack-overflow/
The popularity of 8 bit PICs baffles me. It’s architecture is awful –
the limited call stack is just the first dreadful thing. Throw in the
need for paging and banking together with the single interrupt vector
and you have a nightmare of a programming model. It would be one thing
if this was the norm for 8 bit devices – but it isn’t. The AVR
architecture blows the PIC away, while the HC05 / HC08 are also
streets ahead of the PIC. Given the choice I think I’d even take an
8051 over the PIC. I don’t see any cost advantages, packaging
advantages (Atmel has just released a SOT23-6 AVR which is essentially
instruction set compatible with their largest devices) or peripheral
set advantages. In short, I don’t get it! Incidentally, this isn’t an
indictment of Microchip – they are a great company and I really like a
lot of their other products, their web site, tech support and so on
(perhaps this is why the PIC is so widely used?)
I started on a Motorola M68HC11, it was simple enough. I think you'll get about the same experience with any 8Bit controllers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Given my background as a generalist, I can cover much of the area from analog electronics to writing simple applications that interface to a RDBMS backend.
I currently work in a company that develops hardware to solve industry-specific problems. We have an experienced programmer that have written business apps, video games, and a whole bunch of other stuff for PC's. But when I talk to him about doing low-level programming, he simultaneously express interest and also doubt/uncertainty about joining the project.
Even when talking about PC's, he seems to be more comfortable operating at the language level than the lower-level stuff (instruction sets, ISR's). Still, he's a smart guy, and I think he'd enjoy the work once he is over the initial learning hump. But maybe that's my own enthusiasm for low-level stuff talking... If he was truly interested, maybe he would already have started learning stuff in that direction?
Do you have experience in making that software-to-hardware (or low-level software) transition? Or, better yet, of taking a software only guy, and transitioning him to the low-level stuff?
Edit:
P.S. I'd love to hear from the responders what their own background is -- EE, CS, both?
At the end of the day, everything is an API.
Need to write code for an SPI peripheral inside a microcontroller? Well, get the datasheet or hardware manual, and look at the SPI peripheral. It's one, big, complex API.
The problem is that you have to understand the hardware and some basic EE fundamentals in order to comprehend what the API means. The datasheet isn't written by and for SW developers, it was written for hardware engineers, and maybe software engineers.
So it's all from the perspective of the hardware (face it - the microcontroller company is a hardware company filled with hardware/asic engineers).
Which means the transition is by no means simple and straightforward.
But it's not difficult - it's just a slightly different domain. If you can implement a study program, start off with Rabbit Semiconductor's kits. There's enough software there so a SW guy can really dig in with little effort, and the HW is easy to deal with because everything is wrapped in nice little libraries. When they want to do something complex they can dig into the direct hardware access and fiddle at the lower level, but at the same time they can do some pretty cool things such as build little webservers or pan/tilt network cameras. There are other companies with similar offerings, but Rabbit is really focused on making hardware easy for software engineers.
Alternately, get them into the Android platform. It looks like a unix system to them, until they want to do something interesting, and then they'll have the desire to attack that little issue and they'll learn about the hardware.
If you really want to jump in the deep end, go with an arduino kit - cheap, free compilers and libraries, pretty easy to start off with, but you have to hook wires up to do something interesting, which might be too big of a hurdle for a reluctant software engineer. But a little help and a few nudges in the right direction and they will be absolutely thrilled to have a little LED display that wibbles* like the nightrider lights...
-Adam
*Yes, that's a technical engineering term.
The best embedded programmers I've worked with are EE trained and learned SW on the job. The worst embedded developers are recent CS graduates who think SW is the only way to solve a problem. I like to think of embedded programming as the bottom of the SW pyramid. It's a stable abstraction layer/foundation that makes life easy for the app developers.
"Hard" is an extremely relative term. If you're used to thinking in the tight, sometimes convoluted way you need to for small embedded code (for example, you're a driver developer), then certainly it's not "hard".
Not to "bash" (no pun intended) shell scripters, but if you write perl and shell scripts all day, then it might very well be "hard".
Likewise if you're a UI guy for Windows. It's a different kind of thinking.
Why embedded development is "hard":
1) The context may switch to an interrupt between each machine instruction. Since high level language constructs may map to multiple assembly instructins, this might even be within a line of code, e.g. long var = 0xAAAA5555. If accessed in an interrupt service routine, in a 16 bit processore var might only be half set.
2) Visibility into the system is limited. You may not even have output to Hyperterm unless you write it yourself. Emulators don't always work that well or consistently (though they are way better than they used to be). You will have to know how to use oscilloscopes and logic analyzers.
3) Operations take time. For example, say your serial transmitter uses an interrupt to signal when it is time to send another byte. You could write 16 bytes to a transmit buffer, then clear interrupts and wonder why your message is never sent. Timing in general is a tricky part of embedded programming.
4) You are subject to subtle race conditions that occur only rarely and are very difficult to debug.
5) You have to read the manual. A lot. You can't make it work by fooling around. Sometimes 20 things have to be set up correctly to get what you are after.
6) The hardware doesn't always work or is easy to damage, and it takes a while to figure out that you broke it.
7) Software repairs in embedded systems are usually very expensive. You can't just update a web page. A recall can erase any profit you made on the device.
There are probably more but I've got this race condition to solve...
This is very subjective I guess, his reasons could be many. But if he's like me, I know where he's coming from. Let me explain.
In my career I've dedicated 6 years to the telecom industry, working a lot with embedding SDK middleware into low-end mobile phones etc.
Most embedded environments I've experienced are like harsh weather for a programmer, you constantly have to overcome limitations in resources etc. Some might find this a challenge and enjoy it for the challenge itself, some might feel close to "the real stuff" - the hardware, some might feel it limits their creativity.
I'm the kind who feels it limits my creativity.
I enjoy being back in Windows desktop environment and flap my wings with elaborate class designs, stretch my legs a few clockcycles extra, use unnecessary amounts of memory for diagnostics etc.
On certain embedded units in the past, I hardly had support for fseek() (an ANSI C standard file function). If lucky, a "watchdog" could give clues to where something crashed. Not to mention the pain of communicating with the user in single-threaded preemptive swamps.
Well, you know what I'm getting at. In my opinion it's not necessarily hard, but it's quite a leap, with potentially little reuse of your current experience.
Regards
Robert
There is a very real difference in mindset from user-level application development (ie, general purpose PC or Web applications) to hard deadline, real-time response application development (ie, the hardware/software interface).
Interrupts, instruction sets, context switching and hard resource constraints are relatively unknown to your average developer. I'm assuming here that your 'average developer' is not an Electrical/Electronic or other Engineer by training.
The transition for this developer you mention may be well outside his comfort zone. Some of us like stretching like that. Others of us may have decided the view isn't worth the climb.
Likewise, folks who've been in the hardware area (ie, Engineers) often have difficulty with the assumptions and language of software development.
These are gross generalities, of course, but hopefully give some insight.
He needs to be comfortable with the low-level stuff, but mostly for debugging and field issues. There is a serious learning curve depending on the architecture, but not impossible. On the other hand, the low-level code takes (in general) more time and debugging than higher-level code. So if you need to be going back to low-level all the time, then perhaps something isn't right in the design. Even for the embedded controls I've built, I spend the vast majority of time in high-level code. Although when you have issues, it is extremely advantageous to have a very good low-level knowledge.
I am an EE turned Software Engineer. I prefer programming low level. Most software developers classically trained that I know do not want to operate at this level they want apis to call. So for me it is a win win, I create the low level driver and api for them to use. There is a "new" degree, at least new since I went to college, called Computer Engineer. Hmm, it might be an electrical engineering degree not computer science, but it is a nice mix of software and digital hardware basics. The individuals that I have worked with from this field are much more comfortable with low level.
If the individual is not comfortable or willing then place them somewhere where they are comfortable. Let them do documentation or work on the user interface. If all of the work at the company requires low level work then this individual needs to do it or find another job. Dont sugar coat it.
I also think they will enjoy it once they get over the hump, the freedom you have at that level, not hindered by operating systems, etc. Recently I witnessed a few co-workers experience for the first time seeing their software run under simulation. Every net within the processor and other on chip peripherals. No you dont have a table on a gui (debugger) showing the current state of the memory, you have to look at the memory bus, look for the address you are interested in, look for a read or write signal and the data bus. I worry about the day that silicon arrives and they no longer have this level of visibility. Will be like an addict in detox.
Well, I cut my teeth on hardware when I started reading Popular Electronics at age 14 – this was BEFORE personal computers, in case you were wondering and if you weren’t well, you know anyway. lol
I’ve done the low level bit-bang stuff on the 8048/51 microprocessor, done PIC’s and some other single chip variations and of course Rabbit Semiconductor. (great if you're into C). That’s great (and fun) stuff; Yes, there is a different way of looking at things – not harder, but some of that information is a bit harder to come by as it isn’t as discussed as the software issues. (Of course, this depends on the circle of friends with which you associate, eh).
But, having said all of this, I want to remind you of a technology that started to bridge the gap for programmers into the world of hardware and has since become a very MAJOR player and that is the .NET micro framework. You can find information on this technology at the following;
http://msdn.microsoft.com/en-us/embedded/bb267253.aspx
It addresses some of the same issues that .NET web development addressed in that you can use some (quite a bit, actually) of your existing PC based knowledge in the new environments – Some caution, of course, as your target machine doesn’t have 4 GIG of RAM – it may only have 64K (or less)
Starting in version 2.5 of the .NET micro framework, you have access to networking and web services – way kewl, eh? It doesn’t stop there … Want to control the lights in your house? How about a temp recording station? All with the skills you already have. Well, mostly -- Check out the link.
The SDK plugs into your VisualStudio IDE. There are a number of “Development Kits” available for a very reasonable amount of cash – Now, what would normally take a big learning curve in components, building a circuit board and wiring up “stuff” can be done reasonably easy with a dev kit and some pretty simple code – Of course, you may need to do the occasional bit bang operation, but more and more sensor folks are providing .NET micro framework drivers – so, the hardware development may be closer than you think…
Hope it helps...
I like both. Embedded challenges me and really gets me going in a visceral way. Making something that affects the macro physical world is very satisfactory. But I've had to do a lot of catch up on the electrical/electronics end, since my bachelor's is in computer science. I've a pretty generalist background, where I studied ai, graphics, compilers, natural language, etc. Now I'm doing graduate work in embedded systems. The really tough part is adjusting to the lack of runtime facilities like an operating system.
Low-level embedded programming also tends to include low-level debugging. Which (in my experience) usually involves (at least) the use of an oscilloscope. Unless your colleague is going to be happy spending at least some of the time in physical contact with the hardware and thinking in terms of microseconds and volts, I'd be tempted to leave them be.
Agreed on the "hard" term is quite relative.
I would say different, as you would need to employ different development patterns that you won't use in other kind of environment.
The time constraint for instance could requires a learning curve.
However being curious, would be a quality for a developer, wouldn't be?
You are right in that anyone with enough knowledge not to feel completely lost in an area (over the hump?) will enjoy the challenges of learning something new.
I myself would feel quite nervous being moving to the level of instruction sets etc as there is a huge amount of background knowledge needed to feel comfortable in the environment.
It may make a difference if you are able to support the developer in learning how to do this. Having someone there you can ask and talk through issue with is a huge help in that sort of domain change.
It may be worth having the developer assigned to a smaller project with others as a first step and see how that goes. If he expresses enthusiasm to try another project, things should flow on from there.
I would say it is not any harder, it just requires a different knowledge set, different considerations.
I think that it depends on the way that they program in their chosen environment, and the type of embedded work that you're talking about.
Working on an embedded linux platform, say, is a far smaller jump than trying to write code on an 8 bit platform with no operating system at all.
If they are the type of person that has an understanding of what is going on underneath the api and environment that they are used to, then it won't be too much of a stretch to move into embedded development.
However, if their world view stops at the high level api that they've been using, and they have no concept of anything beneath that, they are going to have a really hard time.
As a (very) general statement if they are comfortable working on multithreaded applications they will probably be ok, as that shares some of the same issues of data volatility that you have when working on embedded projects.
With all of that said, I've seen more embedded programmers successfully working in PC development than I have the reverse. (of course I might not have seen a fair cross section)
"But when I talk to him about doing low-level programming, he simultaneously express interest and also doubt/uncertainty about joining the project." -- That means you let him try and you prepare to hire someone else in case he doesn't pass the learning curve.
i began as a SW engineer i'm now HW one !
the important is to understand how it works and to be motivated !