Imprecavo contro il nuovissimo ordinamento quando Nicola Calipari ha detto :
vedo che sei italiano, ti do un consiglio in lingua potabile :D la vera distinzione non è fisica nè architetturale, la distinzione si fa in base all'utilizzo che fai della macchina. Puoi capire il mondo dei sistemi embedded anche con un normalissimo x86: hai le seriali, il processore, la ram, la MMU ecc... certo, è una macchina complessa e non è il top per iniziare. Tu citi l'ARM9. l'ARM9 puoi usarlo con un sistema operativo tipo Linux o Android e allora non devi preoccuparti di seriali, display e così via o puoi usarlo "bare-metal" andando a spostare i dati a manina nella memoria prima di farli uscire sulla seriale e così via. Un utilizzo o l'altro fanno la differenza tra un sistema embedded e uno no. Quello che oggi si chiama "sistema embedded" è solo quel che 30 anni fa si chiamava "computer" e per utilizzare il computer si studiava l'informatica, nè più nè meno e l'informatica non la si impara con Java nè Android nè altro. (Curiosità: l'informatica è nata anni prima del primo calcolatore). Un normale corso universitario su "Architetture dei Calcolatori" è solitamente un buon primo passo per entrare in questo mondo, seguito da "Sistemi Operativi" e simili. A quel punto dovrai cercare di capire cosa è un sistema real-time, i requisiti che ha, come lo si programma e dove le cose possono andare male. Altra cosa: lascia perdere Java per questo mondo. Java non solo poggia su un sistema operativo di alto livello, ma poggia anche su di una Virtual Machine che non ti lascia assolutamente il controllo sulla macchina. Ripassa il C e i rudimenti dell'assembler, uno qualunque.
Come piattaforma per iniziare ti suggerisco un AVR a 8bit o un ARM7 (lpc2103 o simili). Non hanno MMU ma sono ricchi di periferiche con cui iniziare a fare esperimenti..
Don't buy a book. Buy a board and start playing with it. The books that you'll find yourself using are the device datasheets and user's manuals.
A really good place to start is with an Arduino. Not very expensive and there is a large user community to help you with ideas for projects. Once you're used to thinking "embedded" then you can try out some of the many other processor families out there.
Febhas (the embedded training company) has a NINE WEEK FULL TIME intensive course to convert IT Graduate programmers to Embedded.
Having seen your other post re the vending machine you are in a very deep hole. You are not going to learn on the job and self taught in 2 months whilst producing a prototype. Mistakes made on this could ruin the company. (I have seen it done)
Out-source the design and prototype. I can recommend various people who are very good with vending machines
Regards Chris
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
This is exactly what I did. My first board was a HC08 board from Motorola SPS (this was before the Freescale spin off).
Of course it helped that I was a professional programmer and that I had already been playing with Linux device drivers on a PC as well as doing things like dropping a PCI card into a VMS box and writing a device driver for it. (For the benefit of any employers watching, both the latter operations were for hobbyist purposes and were carried out on my _own_ equipment. :-))
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Having said that, you can find texts, tutorials, application notes, seminars, etc. that will expose you to *instances* of embedded system design ("How to use feedback for optimal control of a stepper motor", "How to design an MTOS/RTOS", "How to implement bumpless transfer in process control", etc.). But, there is no systematic way of "teaching" embedded systems -- just like there is no systematic way of teaching "problem solving".
Can you recommend a book that will teach you how to design a chair? Or a shovel? (you can probably find an explanation of the design of *a* particular chair... but, can you find a book that tells you how to design *chairs* -- in general? And what about other pieces of furniture??)
By far, the biggest part of embedded system design is a good understanding of the application. Unlike desktop applications where the user is expecting to interact with "a computer", is typically seated (comfortable), has "ample time" for the interaction and probably *some* sort of support system, in the embedded world, the user is "using a tool". Designed for a particular purpose(s). (ever seen a manual for how to use -- or design -- a HAMMER??)
Learning the skills required to use the tools/components that go *into* making that "tool" is only a small part of the problem. E.g., before you can make a chair, you need to learn basic carpentry (assuming the chair is to be made of wood; you would also need to learn basic metalworking to be able to make chairs of *metal*!). How to use power/hand tools to manipulate the wood into the desired shapes, joinery, etc.
You'd also need some basic understanding of wood, itself, to know how to select the appropriate species of wood and the "cuts" that will give you the desired visual characteristics or long-term dimensional stability (a chair that ends up "twisting" as the wood dries would be a crappy chair!). Ditto for metallurgy.
I.e., these are the parallels to knowing how to use serial ports, USB ports, high speed busses, communications technologies, operating systems, etc. Once you have them under your belt, you're just *barely* qualified to start looking into how they can be used in embedded applications. A furniture maker surely wouldn't want you building (let alone DESIGNING!) chairs before you had those basic skills; neither would you be qualified to design/implement an embedded system!
[sure, any jamoke can pick up a few 2x4's, nail them together into something that *looks* (crudely) like a chair... but not many folks would want to use or *buy* it! Likewise, that same jamoke can hook up a PC to a bunch of motor controllers and "make" a robot. How many of *those* do you think General Motors would want working on it's production lines??]
Over the years, the one thing I have learned is how relatively insignificant particular "technologies" are to successful design. It's comparable to learning the programming language du jour.
The bigger issue is understanding your application and its needs. Being able to understand what would make your "solution" right (or wrong!) for that application. Being able to understand the hidden aspects of the application that the "customer" often can't (consciously) identify -- but that, nonetheless, have a marked impact on the usability and acceptance of your system/solution/device.
In your vending machine example (elsewhere), someone who has never operated a "route" would be oblivious to the issues that relate to servicability, convenience, reliability, etc. If you've never actively explored the means by which devices are "hacked", you'll never be able to protect against those (and other -- as yet unencountered) hacks. If you've never had to repair a machine "on location", you won't appreciate the value of BIST and other diagnostics (dragging a machine back to the shop just to determine that a power supply has failed is a *huge* waste of resources!). If you've never been an Owner/Operator, you won't appreciate the value of
*inexpensive* FRU's (since vendors often seek to maximize
*their* profits instead of thinking about the Owner/Operator's TCO).
You'll undoubtedly find all sorts of "rules" about what you can and can't do with the technology as applied to embedded systems. Almost all are *wrong* in some (*large*) set of applications! (You can't use an interpreted language; you can't use a slow processor; you can't use a FAST processor; ... you can't use a CHAINSAW to make chairs!) The better your understanding of your application, the better qualified you will be to understand what you can and can't *really* do in solving it. And, in evaluating a priori how "good" your solution is likely to be!
[you really need to "grok" your application; others can give you a hand with the technologies but only you can do *this*!]
Sorry to be so metaphysical... but, maybe save you a side-trip chasing down resources of dubious value.
Android is the only Java platform I can think of now. I don't know how much of it is pure Java. But I do know that there are no printer drivers, serial drivers or disk drivers. I don't know of too many people crazy enough to write MDB (Multi-Drop Serial Bus) driver in Java.
Just visited the Android site. I saw some references to Linux 2.6 kernel. Can someone confirm or rebut that they are using Linux kernel? If so, all device drivers much be in C, not Java.
A lot of java, some C, mostly for parallel computing.
Python and matlab for personal pleasure.
o
Yes that's the plan. But since I'm working also to learn, and since it's better to outsource having some knowledge on the matter, I thought about educating a little bit myself, at least so that I can understand the difference between a serial port and a MDB port :)
In which case you have a VERY steep learning curve.
Sounds like a good idea.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
??? Why would he? If you've got the knack for problem solving it shouldn't be too bad. Sure it would help if he had experience doing lower level stuff or some HW stuff... with his short timeline he definitely needs to outsource... but it's good to learn :)
formatting link
is a book that we used in a class for an intro to overall system design and the embedded design process with a mix of hardware and software concepts. Really very general, supplemented by separate software and hardware design classes.
I agree you should grab a board and tinker. Arduino is good if you are a complete noob at doing this kind of thing, otherwise go with some of these:
Worse. They make the serial port (or "whatever" other trivial bit of hardware they are presenting -- and describing in absurd detail!) seem magical and imply that you are now a member of a special, secret *club* with this Special Knowledge (unknown to Members of The Public).
I just consider those *software* technologies. :> I believe they are no different than the "hardware" technologies -- all can be "taught" (learned from a book).
Yeah, and it is usually pretty obvious when you come across a system designed by someone like this. Sort of like someone teaching themselves how to write code, etc.
I find chasing down current research trends helps expose me to new ideas -- as well as what folks think is (or soon *will* be) possible with existing technology. E.g., when Athena started, the idea of having your own *personal* VAX seemed insane! Nowadays, folks would grumble if LIMITED to a VAX's horsepower!
[I've been envious of some of the projects at CMU in recent years -- wishing I'd had similar opportunities when I was in school]
And, as you read them, be critical of what they proclaim. App notes are notoriously buggy. "Rules" are almost always oversimplifications. Even texts are frequently riddled with errors (either in authorship, editing or publication). Etc.
The problem there is that most folks have very narrow experiences in individual application domains. So, you are unlikely to be exposed to something (someone) that isn't germane to that particular application domain. It is surprising to see how people entrenched in one particular application domain react to ideas "ported" from other domains. ("Wow! Why didn't *I* think of that??")
Viewed optimistically, that is the *beauty* of designing in this arena -- there is *always* something new you can learn and some new/clever way of approaching a boring old problem!
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.