Embedded system programming
-
Hi everyone, I have some spare time these days and I wanted to get into some embedded microcontroller programming. Can someone suggest a good place to start (books, web references, kits). There seems to be so much material, it is really difficult to know where to start! Thanks, Pankaj Without struggle, there is no progress
-
Hi everyone, I have some spare time these days and I wanted to get into some embedded microcontroller programming. Can someone suggest a good place to start (books, web references, kits). There seems to be so much material, it is really difficult to know where to start! Thanks, Pankaj Without struggle, there is no progress
The PIC series of MCUs are cheap and in common use. Check out Digikey[^] for inexpensive development kits. These usually come with an evaluation board, cables to interface to a serial port on your computer, a compiler or assembler program, sample code, and enough documentation to get you started. This isn't the only option, of course. Most manufacturers of microcontrollers offer evaluation kits directly, but the PICs have been around for a long time, and are quite affordable. Another option is the Rabbit2000, made by ZWorld IIRC - I ordered one years ago, but never got around to doing anything with it. It was under $100US. Regardless of which processor you choose, the principles you'll learn are common to all controller types, though the implementation details - instructions (opcodes), memory addressing methods, specialization features, etc - will vary wildly. If you're interested in signal processing, Texas Instruments (TI) offers a broad line of DSPs - a type of MCU optimized for signal processing - and they're very generous about supplying free samples. Have fun! A solid understanding of what goes on under the hood can only make you a better programmer.:-D Some people think of it as a six-pack; I consider it more of a support group.
-
The PIC series of MCUs are cheap and in common use. Check out Digikey[^] for inexpensive development kits. These usually come with an evaluation board, cables to interface to a serial port on your computer, a compiler or assembler program, sample code, and enough documentation to get you started. This isn't the only option, of course. Most manufacturers of microcontrollers offer evaluation kits directly, but the PICs have been around for a long time, and are quite affordable. Another option is the Rabbit2000, made by ZWorld IIRC - I ordered one years ago, but never got around to doing anything with it. It was under $100US. Regardless of which processor you choose, the principles you'll learn are common to all controller types, though the implementation details - instructions (opcodes), memory addressing methods, specialization features, etc - will vary wildly. If you're interested in signal processing, Texas Instruments (TI) offers a broad line of DSPs - a type of MCU optimized for signal processing - and they're very generous about supplying free samples. Have fun! A solid understanding of what goes on under the hood can only make you a better programmer.:-D Some people think of it as a six-pack; I consider it more of a support group.
Hey Roger, Thanks for all the info! I have a feeling this is going to be fun! Pankaj Without struggle, there is no progress
-
Hey Roger, Thanks for all the info! I have a feeling this is going to be fun! Pankaj Without struggle, there is no progress
My last adventure in embedded programming was about 25 years ago, and I still miss it. Curiously, a couple of years ago I had several conversations with Lauren about it, and found that she misses it as much as I do. I guess it's something that gets in your blood, and you never get over the god-like feeling of being in total control of what the hardware does. Every bit and and operation is under your total control, without the interference of an imperfectly understood operating system. On the flip side, every wayward instruction, forgotten interrupt, missed RET instruction is totally your own fault, and you can't blame it on Microsoft. It's like your first adventure in the kitchen without Mom, scary but fun, every time you run a new compilation. Enjoy!:-D Some people think of it as a six-pack; I consider it more of a support group.
-
Hi everyone, I have some spare time these days and I wanted to get into some embedded microcontroller programming. Can someone suggest a good place to start (books, web references, kits). There seems to be so much material, it is really difficult to know where to start! Thanks, Pankaj Without struggle, there is no progress
It depends on how far you want to go, a resonable target board and C compiler should set you back less than $100 but you will probably have to do some assembly language for the startup code. The last PIC C compiler I saw had quite a few limitations due to the structure of the PIC. The 8051 or any variants are a good starting point and Kiel is a decent RTOS and compiler. Elaine :rose: The tigress is here :-D
-
My last adventure in embedded programming was about 25 years ago, and I still miss it. Curiously, a couple of years ago I had several conversations with Lauren about it, and found that she misses it as much as I do. I guess it's something that gets in your blood, and you never get over the god-like feeling of being in total control of what the hardware does. Every bit and and operation is under your total control, without the interference of an imperfectly understood operating system. On the flip side, every wayward instruction, forgotten interrupt, missed RET instruction is totally your own fault, and you can't blame it on Microsoft. It's like your first adventure in the kitchen without Mom, scary but fun, every time you run a new compilation. Enjoy!:-D Some people think of it as a six-pack; I consider it more of a support group.
I miss embedded work too, possibly because you tend to get much more involved with the project as a whole. The tigress is here :-D
-
Hi everyone, I have some spare time these days and I wanted to get into some embedded microcontroller programming. Can someone suggest a good place to start (books, web references, kits). There seems to be so much material, it is really difficult to know where to start! Thanks, Pankaj Without struggle, there is no progress
A big problem with just learning it is that every solution has distinct enough requirements that it's difficult to generalize learning across all possible platforms. Having said that, I can think of two general rules from the embedded programming I've done: 1) Reliability is all important. Your code must be completely predictable. Errors can't lock up the system (in worse case, some systems can reset themselves; others can't.) 2) Size is critical. Even on systems with "lots" of memory, it seems you always need more. One impact of this is that you have to be very aware of how your language of choice really works; how memory allocations are made, etc. If you use embedded C++, you have to be very deliberate about what methods are virtual and which aren't, etc. Based on both these factors, I suppose there's one overriding rule: KISS--keep it simple stupid. Or, make it as simple as possible but no simpler. (BTW, you could get something like eCOS, Windows CE or Embedded XP and use your PC to learn some embedded principles.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Hi everyone, I have some spare time these days and I wanted to get into some embedded microcontroller programming. Can someone suggest a good place to start (books, web references, kits). There seems to be so much material, it is really difficult to know where to start! Thanks, Pankaj Without struggle, there is no progress
I've worked with a few different (some would say bizarre) embedded controllers, including the ubicom SX series (don't get me started...). you'll find lots of "hobbyist" support for the PIC series of chips, and if you want to experiment with embedded "stuff" without getting too deeply into the details all at once, check out the basic stamp that will give you a lot of the features of the PIC with an easy programming language and a simple programming interface. I've recently started investigating the zilog Z8encore series, and the more I look, the more I like. they're cheap, relatively fast, vaguely familiar (based on the Z80 instruction set, which is distantly related to the x86 set), come with lots of on-chip goodies, and the developement system (chip, eval board with fancy doodads, in-circuit programmer, C compiler, debugger, and IDE) is going for around $40. that's just plain hard to beat.
-
I've worked with a few different (some would say bizarre) embedded controllers, including the ubicom SX series (don't get me started...). you'll find lots of "hobbyist" support for the PIC series of chips, and if you want to experiment with embedded "stuff" without getting too deeply into the details all at once, check out the basic stamp that will give you a lot of the features of the PIC with an easy programming language and a simple programming interface. I've recently started investigating the zilog Z8encore series, and the more I look, the more I like. they're cheap, relatively fast, vaguely familiar (based on the Z80 instruction set, which is distantly related to the x86 set), come with lots of on-chip goodies, and the developement system (chip, eval board with fancy doodads, in-circuit programmer, C compiler, debugger, and IDE) is going for around $40. that's just plain hard to beat.
Thanks! I will look into these. Pankaj Without struggle, there is no progress
-
My last adventure in embedded programming was about 25 years ago, and I still miss it. Curiously, a couple of years ago I had several conversations with Lauren about it, and found that she misses it as much as I do. I guess it's something that gets in your blood, and you never get over the god-like feeling of being in total control of what the hardware does. Every bit and and operation is under your total control, without the interference of an imperfectly understood operating system. On the flip side, every wayward instruction, forgotten interrupt, missed RET instruction is totally your own fault, and you can't blame it on Microsoft. It's like your first adventure in the kitchen without Mom, scary but fun, every time you run a new compilation. Enjoy!:-D Some people think of it as a six-pack; I consider it more of a support group.
Curiously, I don't miss embedded programming (or its close cousin, device driver writing). I've written embedded stuff for Intel microprocessors and PIC's, and device drivers for MS-DOS and OS/2. It was satisfying when I got it working correctly, but the debugging experience was usually really unpleasant. My description of OS/2 device driver debugging was 'it's like being a cardiologist who goes in rectally'. I think the final satisfaction from an embedded project was as much a sense of relief as anything else. In conventional application development, you have the same satisfaction of getting the application working correctly. Meeting functional requirements is just the start, however. On top of that, there are other satisfactions based on both how the app does it's job and the user's reaction. With conventional apps, you can take advantage of higher levels of abstraction in the programming language (C++ vs. C or assembly language), which affords internal elegance. In embedded programming, under the KISS philosophy (Keep It Simple Stupid), you are better off keeping things as 'vanilla' as possible. Embedded apps don't get 'oh wow' reactions from their users. They take the bits in, they put the bits out, the machine blinks its lights, and you're done. Conventional apps, you get that if you've done a good job.
Software Zen:
delete this; -
Curiously, I don't miss embedded programming (or its close cousin, device driver writing). I've written embedded stuff for Intel microprocessors and PIC's, and device drivers for MS-DOS and OS/2. It was satisfying when I got it working correctly, but the debugging experience was usually really unpleasant. My description of OS/2 device driver debugging was 'it's like being a cardiologist who goes in rectally'. I think the final satisfaction from an embedded project was as much a sense of relief as anything else. In conventional application development, you have the same satisfaction of getting the application working correctly. Meeting functional requirements is just the start, however. On top of that, there are other satisfactions based on both how the app does it's job and the user's reaction. With conventional apps, you can take advantage of higher levels of abstraction in the programming language (C++ vs. C or assembly language), which affords internal elegance. In embedded programming, under the KISS philosophy (Keep It Simple Stupid), you are better off keeping things as 'vanilla' as possible. Embedded apps don't get 'oh wow' reactions from their users. They take the bits in, they put the bits out, the machine blinks its lights, and you're done. Conventional apps, you get that if you've done a good job.
Software Zen:
delete this;Gary R. Wheeler wrote: Embedded apps don't get 'oh wow' reactions from their users. They do when it's never been done before, and that's what my experience with them accomplished. I suppose that now it's a lot less fun, since firmware is so ubiquitous, but when I was doing it almost nothing used firmware. I like your analogy, though - embedded programming can be very tedious and painful. When you have 1024 bytes of program memory to work with, and your code requires 1026 bytes, somebody's going to lose some hair before it's over. I wouldn't do it again just for fun; it's just too hard. But it was fun to get paid to do it, and that I'd do again anytime. Some people think of it as a six-pack; I consider it more of a support group.
-
Gary R. Wheeler wrote: Embedded apps don't get 'oh wow' reactions from their users. They do when it's never been done before, and that's what my experience with them accomplished. I suppose that now it's a lot less fun, since firmware is so ubiquitous, but when I was doing it almost nothing used firmware. I like your analogy, though - embedded programming can be very tedious and painful. When you have 1024 bytes of program memory to work with, and your code requires 1026 bytes, somebody's going to lose some hair before it's over. I wouldn't do it again just for fun; it's just too hard. But it was fun to get paid to do it, and that I'd do again anytime. Some people think of it as a six-pack; I consider it more of a support group.
Roger Wright wrote: They do when it's never been done before, and that's what my experience with them accomplished. Hmmm. It seems to me that the audience for an embedded app has to be a lot more sophisticated to generate the same level of appreciation. They need to have the ability to appreciate what you've done. In my case, I guess I'm after simple strokes to my vanity :-O. I've been at the top of the pay scale for software types for some time now, so the money doesn't make as much of an impression. I like getting reactions from users. When I was doing mostly embedded stuff, I didn't get that as much. Roger Wright wrote: embedded programming can be very tedious and painful I think that's what I was really trying to say. The level of satisfaction I achieve, versus the amount of mental pain experienced, is so much greater with conventional applications as opposed to embedded. I'm old enough now that enduring pain for pain's sake, or for the macho bragging rights, just doesn't have the same allure it used to. Now, if you're talking about going for a 6 mile run, or a 50 mile bike ride, that's a different story... ;)
Software Zen:
delete this;