I'd like to learn about embedded systems development, but since books are too expensive right now and there's no decent library for 300 miles near me, I think that perhaps writing code and running it on a simulator would be a good idea to get started. Perhaps after a while I can find some secondhand hardware on eBay or something and do the real thing. Are there any significant drawbacks to using a simulator, for instance, will code that relies on timing (if that's ever done) be all wrong when run on the real hardware? Any gotchas for developing on a simulator?
What are the most popular embedded systems chips that employers hire programmers to write code for, and what would be the easier out of these for a beginner to go with? What is the best documented chip? Do simulators simulate I/O well, that is, can I learn a great deal about doing I/O on simulators? Also, are there any good simulators that simulate network connections, i.e. Ethernet? Perhaps by hooking up the simulator to the loopback device?
Am I confusing microcontrollers and "embedded systems" when I think they are really small and I can't write a stinking great big feature-full web server for an embedded system? Do "embedded systems" run really meaty processors like the Pentium? So, is there any distinction between embedded systems development and microcontroller development?
In article , johnathan snipped-for-privacy@fastmail.com.au writes
Have a look at the papers on
formatting link
and ask question here.
Yes. My preference would be the Keil 8051 compiler and simulator. The eval version is size limited not time limited. However you can do similar with eval versions of most embedded compilers for most targets. (IAR, Cosmic, Tasking, etc etc )
Use C (there will now be a 900+ sets of postings arguing why you should C++, Pascal, Mod2, forth and ASM that you can ignore c is used in over
80% of embedded developments with C++ and ASM coming 2nd and third)
8051 Hw is VERY cheap these days. (also PIC not that I like it)
For learning there is no real difference. The simulator whilst not real time does synchronise everything and assumes perfect HW. You can do a LOT with simulators. the KEil does simulate the peripherals.
8051 family (about 600 variants from 40 manufacturers + IP cores) PIC AVR
Any of the 8 bit types.... 8 bit is the most common in terms of numbers of projects.
Ethernet is a whole new ball game... You can do this with some 8051's the Dallas 400 has ether net on it.
Yes but that is not a problem... So does everyone else :-)
Yes. Even 8 bit 8051 types. Atmel do several 51 kits with TCP-IP stacks. (free ones at that!)
Not usually as they require a fan and heat sink. Most comms systems use the far more powerful PowerPC.
The x86 family tends to be use on cut down PC's (See PC104 format).
YEs, No and maybe... ignore the next 600+ posts on this topic. It is as bad as asking which is the right car or who should I vote for.... :-)
Most embedded systems have a Micro controller in them. or a IP core in the case of ACIs and FPGA's but it is not always the case.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
I've been a little confused about embedded vs. micro and such, but now it's starting to make sense.
I seem to recognise the Keil 8051 C Compiler and simulator from somewhere. I wonder if there was a book written about it or something? I must have seen it while browsing Amazon or something.
Whoa! It must take some serious skill to squeeze on a network stack and some basic servers and such. What about filesystems? Is there a common kind of filesystem for embedded systems?
Anyway, before asking too many more questions I'll go and read the link you have. Thanks a thousand times for that. :)
OK, I'm biased, I work for Rabbit, and I may have exagerated on the first answer. But we have good, inexpensive HW, SW and kits for 8 bit processors, and we're happy to take on beginners who aren't going to buy 10,000 units right away. You can have an embedded Webserver running within 10 to 20 minutes after you open the box with our Ethernet enabled products. You can add SSL/HTTPS security for a few lines of code and a few dollars more. You don't need a simulator.
formatting link
formatting link
formatting link
Here's a good book for embedded networking beginners.
But going back to the first point.. you cant go wrong with an 8051... actually you can. lots. but it is a good place to start which is why there are over 50 manufacturers producing 600 different versions that will all run the same core binary.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
Just what is this love affair with the 8051 all about? Apart of course your commercial interest. This processor is 30 years old, it has a primitive instruction set not suited to running pointer intensive languages like C. It has an architecture which is just as usuited to C as well. The chips themselves are not fast, not cheap nor allways available, apart from the basic 40pin version. I can't think of a single good reason for using them these days, if you can then maybe you can enlighten me.
Chris and I don't see eye-to-eye on quite a few things, but we argue quite cordially :) His [other] schtick is, in a nutshell, that the '51 is so widespread that it's a good learning platform because (a) there's tons of IP out there waiting to be reused, and (b) it's a good bullet point on the resume.
To which I would add (c) if you can program the '51 skilfully, you won't have trouble programming an elegant architecture, much like a driver trained on a Yugo won't have much trouble driving a Bentley.
I don't regret the time I spent learning how to program this platform. Among other things, there are a _load_ of ASSPs that use a 51 to do the grunt bit-shuffling work, transferring data into and out of special-purpose hardware on the chip (crypto, A/V codec, etc). Used to be that it was the price king, and I guess as a soft core it still is.
(My potential new employer uses '51s and - ARGH! - COPs, but - amazingly - is migrating some applications to AVR and is dabbling in MSP430, too! I am so happy! Ulf, are you reading this?).
I must have missed the release of the 100MHz AVR - or the 24 Bit ADC MSP430, or the USB_PIC ? Last time I looked at an AVR, the BOOLEAN handling was primitive, and there was no register bank switching : since those two things mattered more in the task at hand, the 80C51 won hands down. The 80C51 was designed as an embedded microcontroller, and it still excells at that task. Like all devices, it has a certain natural Opcode Data and Code 'reach' and outside that, it becomes less efficent. A microprocessor it is not.
If you/your application likes C, and lots of pointers, then the new ARM controllers will make you right at home. Or maybe not, as ARM fails the 'fashion test', being close to 20yrs old ? :)
it has nothing to do with fashion, if you want to use old stuff thats fine with me. I'm still waiting for someone to mention a single factor that makes the
"I must have missed the release of the 100MHz AVR or the 24 Bit ADC MSP430, or the USB_PIC" -Jim Granville
Those are factors that makes the 8051 more suitable for a new design.
When you wrote "it has a primitive instruction set not suited to running pointer intensive languages like C. It has an architecture which is just as unsuited to C as well" I think you expressed your real objection, and a fine objection it is - for those who program microcontrollers in C. That's the high end. Down here where the chips cost less than a dime and the programs are less than 100 bytes long we use assembly language and ponder whether to use an
8051 with onboard peripherals or a 4-bit processor with external peripherals.
--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
have an "impossible" engineering project that only someone like
Doc Brown can solve? My resume is at http://www.guymacon.com/
Say you want a 24-bit delta-sigma DAC on board.. AFAIK only the 8051 core is available in production quantity (at least two suppliers), with ARM availability (one supplier) projected to be in 3rd quarter
2K004. There are other similar examples.
More generally, why in the world would you reject a competitively priced 8051 from consideration in an application where it would be appropriate? For example, the modern Philips 6mm x 6mm P89LPC932FHN.
formatting link
Or an inexpensive OTP P87LPC760BDH (USD0.87 ea/reel from Avnet)
formatting link
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
more suitable than what ? Since the 80C51 is proven, widely available, multi-sourced, low cost, I tend to work from the angle that if a controller can do something the
80C51 cannot, then it might get a look in. [It will help a lot if the alternatve it is multi-sourced]
It may not even be the core that dictates, but a peripheral : eg if you want 24 bit ADCs in a uC, your choice is [guess what core :)] or if you want Ethernet+Flash that might point to the eZ80.... etc
Thus, I can forsee using an ARM variant, when the maths loading dictates, but otherwise change just for the sake of it has low appeal.
They're up to 20 now. And they've always been single-cycle machines. With an "8051," you're never sure if it's 1, 3, 4, 6, or 12 (Yes, I see the SiLabs C8051F120 is ostensibly a single-cycle machine).
Forgive me if I'm skeptical about a microcontroller's ability to distinguish 300 nanovolts (or 180 with a 3 volt reference). If I needed that kind of accuracy, I'd want the ADC a little further away from the CPU clock...
I can understand that. They're pretty new. Check the Microchip web site. The PIC16C745 and 765 support USB 1.1, and the PIC18F2455,
2550, 4455 and 4550 support USB 2.0 (Full Speed, not Hi-Speed). All these chips were released in the last two months.
Not that I much like PICs...
AVR has a Load/Store architecture -- most operations take place on data in the registers. Setting or clearing a bit in a register is one single-cycle instruction (SBR, CBR). The compilers I use reserve up to 13 general-purpose registers (104 bits) for boolean storage. Assigning the value of one boolean to another requires 2 single-cycle instructions (BST/BLD).
Register bank switching can save some time if you have a lot of interrupts occurring that need to be serviced fast. With the AVR, you need to save whatever registers you're going to use yourself. There's a 4-cycle penalty per register (two to save, two to restore).
PICs are horrid when it comes to interrupts -- there is only one, and you have to perform an amazing dance to save state, then you have to find out who generated the interrupt (generally by polling device status registers).
The 8051 only lets you access 128 bytes of RAM without going through the DPTR, and at least 8 of those are reserved for registers (and 8 more for each additional register bank). But the AVR can load a value from any location in RAM in 2 cycles, and has 3 16-bit indirect address registers. Dual DPTR is only available in extended 8051 cores. Implementing the functionality of something like memcpy on a single-DPTR core is... painful.
The one primary and overarching advantage of the 8051 is the fact you can buy it from multiple sources. This provide competition and a multitude of options. Finding a plug-in replacement for a particular chip, however, can be... difficult.
And every time I've tried to get an 8051 into a design, the budgetary
10k pricing has been way out-of-line. Cygnal (SiLabs) in particular. Budgetary pricing >3x the next highest competitor lost the battle before it started.
If the AVR were multiply-sourced, we'd see them at 100 MHz and in the automotive temperature grades (though perhaps not in the same device...).
ARMs are overkill for most applications I've worked on the last 4 years. The AVR does a really nice job at a low cost, and is relatively C-friendly. The avr-gcc compiler is very good.
From a software standpoint, the AVR is my first choice for an 8-bit microcontroller (If you haven't guessed that by now ;-). From a hardware standpoint, the only real problem I've had is temperature grades.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.