After a long break (5 years) I would like to spend some time with embedded systems programming and I would like to start developing with an apropiate SDK. Goal is to gain experience and some training that is compatible which current industry trends. At the university I had some experience with 80C51, 68HC11, 68000 and a TMS DSP, serial bus programming. I have the feeling that in the current era assambler programming is gone, everything is integrated on a developer enviroment and highler level languajes are used.
After searching the web some interesting projects that use the TI MSP430 were found and I'm encouraged to acquire it's SDK but I'm not sure if that's what industry is asking for. I don't know much about ARM processors or FPGA, CAN bus concepts, are those a good options to start with? And naturally, it may depend on what I want to develop but if you could share some ideas, opinions, information and/or give some direction it would be very kindly appreciated.
Not universally true. HLLs are used extensively these days for two reasons:
HLL compilers for many processors have evolved to the point where they give very good results. Therefore it is attractive to exploit the maintenance, debug and verification advantages of an HLL.
There are simply more very-large-scale embedded projects these days than there were in the past.
However, there are still _vast_ numbers of smaller systems still developed entirely in assembly language. Not just legacy systems, either.
Although it is not 100% aligned with your requirements, self-interest demands that I recommend you to my latest book, which includes a large section on "which chip do I use to become relevant to industry"?
You still should know assembler, but most code is written in HLLs. That trend makes the core less important
The 80C51 is still very widely used, and in this family Silabs have some very good low cost development systems - from $10 up. Their systems include on-chip debug, and a reasonable IDE.
SiLabs newest members in the C8051F41x family have 5V Vcc, 5V IOs, (because they have an on-chip micropower regulator), and 12 bit ADC and DACs, and 50MHz core speed.
The MSP430 is also a nice family, with similar debug support. (but it is single sourced, and needs 3.3V power)
On-chip debug is probably the biggest change in small uC, with even the tiniest new ones from Freescale now offering that.
Wide Vcc is another trend: after a push to lower voltages, chip vendors are realising that 5V is still quite important, and they have figured out how to include voltage regulators on the die, and operate quite large separations in core and IO voltages.
Like SiLabs, the newest freescale devices have on-chip regulators - so these regulators will become like the ADC blocks.
Assembler isn't gone -- depending on the company and it's goals you'll find everything from 100% assembly, through mostly HLL with an itty bitty bit of assembly for the 'hard parts', to purely HLL with a 'board support package' that's written with a great deal of assembly by some guy who's highly paid and considered very weird by the 'normal' folks who can't make a light blink unless WindRiver provides a "Blinky" function in their API.
In many places a knowledge of assembly-level programming, is a plus, particularly if you can couple it to a good understanding of the assembly that's likely to be generated by a compiler -- in some places if you can demonstrate an ability to interface your assembly code to my C code you'll be hired, even if you try to make a pass at the VP of engineering's dog.
There's such a breadth of technologies out there I don't think you need to do much but get yourself hired. I'd suggest you decide where you want to be in five or ten years, get a job that leans in that direction, and keep leaning until you're there.
MSP430 for stuff that fits in 64K, ARM for bigger programs is probably a good starting point. There are still plenty of people using 8051, 6812, and 68xxx (now called "colddragonfireball" or something equally inane).
Still plenty of those.
Don't know what that means.
No more so that 15-20 years ago (at least in my experience).
A lot of people use IDEs, but there are still plenty of people who know how a compiler and linker works. Every project needs at least one, because the IDE sure ain't going to figure out what's wrong. An IDE can only be used to do things that the IDE developers had thought about. I find them to be a huge waste of time.
Not at all. By far the most popular language for embedded systems is C (a low-level language). Very few projects use higher level languages. C++ is being use on some largish embedded systems (if you want to call C++ a higher level language).
It's pretty popular for smallish, low power apps.
ARM is also very popular. CAN bus is pretty simple. The "can in automation" web site has some good overviews.
IMO either the MSP430 or an ARM single chip system (e.g. something from Atmel) would be worth playing with.
Grant Edwards grante Yow! Yow! I threw up on
at my window!
Could you please extend on why is your book not 100% aligned with my requirements? I'm interested buying your book, could you please give me more information, e.g. content index, on Amazon unfortunatelly it is not possible to get that information.
Even worse than the processor name is that they ditched venerable Motorola name for "Freescale" which I thought was some sort of Cocaine/ether combination that blew up in Richard Prior's face and burned him severely. Not really the sort of association you want popping into people's heads, but they didn't ask me.
The next thing you know, HP is going to call their test equipment division something stupid.
Yes, I know HP did in fact spin that division off in an attempt to distance themselves from a hard-won reputation as one of the premier test gear manufactureres, but I can't for the life of me remember what they called the cast off division.
I can almost hear the discussion at Tektronix:
VP1: We should spin off our test equipment division and name it something nonsensical nobody can remember. You know, like HP did with their test equipment and Motorola did with semiconductors.
VP2: But we don't make anything except test equipment. There'd be nothing left to call "Tekronix"
VP1: That's why this is so brilliant! Other corporations have only been able to abandon _part_ of their good name and reputation -- 50% at most. We can get rid of 100%! That's _twice_ as much!"
VP2: Damn, you're right!
Grant Edwards grante Yow! Darling, my ELBOW
at is FLYING over FRANKFURT,
I'm in poor condition tonight to answer that question - having had about an hour's sleep in the past three days :) Let me think about that and maybe I will remember why I said it.
Sure, here is the index. Please note these page numbers are not accurate, since this was cut and pasted from my draft manuscript.
Table of Contents
1-1 About This Book 4
1-2 What is an Embedded Engineer? 6
2-1 Traditional Education Paths into Embedded Engineering 8
2-2 Getting In Without Traditional Education (and Acquiring it Thereafter) 14
2-3 I Write Software - How Much Electronics Must I Learn? 28
2-4 Educational Traps, Dead-Ends and Scams to Avoid 32
2-5 Practical Skills You'll Want To Acquire 37
3-1 Target Audience 42
3-2 Intel (et al) 8051 Variants 46
3-3 Atmel AVR 58
3-4 Texas Instruments MSP430 68
3-5 Microchip PICmicro 78
3-6 Less Common Architectures for Special Needs 86
3-7 What Programming Languages Should I Learn? C++ vs. C vs. Assembly Language in Small Embedded Systems 91
3-8 Brief Ravings on Copy-Protected Development Tools 97
3-9 An Example 8-Bit Project using AVR and Free Tools 101
4-1 Target Audience 136
4-2 Embedded x86 Solutions 138
4-3 ARM 151
4-4 PowerPC 165
4-5 Linux 169
4-6 eCos 180
4-7 What Programming Languages Should I Learn for Large Embedded Systems? 183
4-8 A Final Word on Part Selection 185
Working For Yourself as an Embedded Engineer 190
5-1 Is Self-Employment for You? Risks and Benefits 190
5-2 From Moonlighting to Fulltime Consultant Status - Bookkeeping, Taxes and Workload 192
5-3 Ways to Find and Keep Customers 200
5-4 Iterative Projects: Never-Ending Horror? 205
5-5 Pricing Your Services Appropriately 209
5-6 Establishing Your Own Working Best Practices 213
5-7 More Than A Handshake: The Importance of Contracts 216
Working in a Small Company 220
6-1 Analyze your Goals: Benefits and Downsides of the Small Company 220
6-2 How to Get the Job 222
6-3 Responsibilities and Stresses in a Small Company 225
6-4 Personal Dynamics in Small Companies 228
6-5 Managing Tightly-Limited Resources 230
6-6 Task Breakdown: A Typical Week 235
Working in a Larger Company 237
7-1 Analyze your Goals: Benefits and Downsides of the Large Company 238
7-2 How to Get the Job 239
7-3 Globalization: Outsourcing and Temporary Worker Visas 242
7-4 Procedures and You: Keeping Your Head Above Water 249
7-5 Managing Relationships with Marketing 257
7-6 Task Breakdown: A Typical Week 260
My thoughts completely, boardroom personal share profits probably motivated things more.
We have seen similar in UK with various 're-brandings' of British Telecom and British Airways (dare I mention tailfin logos).
Considering also the semiconductor/opto division was split off in the same split it was stupid.
More likely that the board and Wall Street types think they understand what PCs are but do not understand test equipment, LEDs, displays etc.. This all happened when a new CEO/President took charge of HP.
Paul Carpenter | email@example.com