Slashdot Mirror
Ask Slashdot: Sources For Firmware and Hardware Books?
First time accepted submitter cos(0) writes "Between O'Reilly, Wrox, Addison-Wesley, The Pragmatic Bookshelf, and many others, software developers have a wide variety of literature about languages, patterns, practices, and tools. Many publishers even offer subscriptions to online reading of the whole collection, exposing you to things you didn't even know you don't know — and many of us learn more from these publishers than from a Comp Sci curriculum. But what about publishers and books specializing in tech underneath software — like VHDL, Verilog, design tools, and wire protocols? In particular, best practices, modeling techniques, and other skills that separate a novice from an expert?"
Perhaps this would be the book you need? http://www.kickstarter.com/projects/nickblack/the-finest-machine :D
I am an embedded software engineer who does some hardware/electrical engineering too. Unfortunately there is very little material on this subject specifically. Basically you need to learn how to code in C (not C++ or C#, raw C), learn some electronics and then maybe learn VHDL/Verilog as well. You then put it all together in your own mind.
It is really hard to recruit people with those skills so they are worth having. You will need some hands on experience though. You can simulate wire protocols and some hardware but none of the simulations are particularly good practice for real life, and employers will want examples of work anyway. A university level course would be best.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
It's not a book, but this book chapter is more-or-less compulsory reading for someone planning to get into HDL programming:
A structured VHDL design method
Pirate Party UK
and many of us learn more from these publishers than from a Comp Sci curriculum
Not me, man. And, don't get me wrong, I love pragprog and I worship O'Reilly and NoStarch. Hell, I review books for them on Slashdot! But no book would have been able to teach me about automata theory or linear algebra and differential equations like my college courses did. I'm sorry but I must argue that there's a lot of application and implementation to be gleaned from these books -- not so much on the theory and foundational concepts. At least for me there's something really difficult about reading a book about really "far out there" concepts and truly understanding them without human intervention. Maybe I'm just stupid but I find the best tech books show me "little jumps" while my college courses were the only way I could make "the big jumps" in knowledge quickly enough.
Plus, going to a liberal arts college meant general requirements that furthered me along in ethics, philosophy, etc more than these books did. I wouldn't go selling a college education short even though it seems to be the popular thing to bash these days.
My work here is dung.
Quite often the best references are datasheets for microcontrollers. This is where I have gained the bulk of my knowledge.
I would also look at what the Association for Computing Machinery has. I had a memebership a while back and it seems they had so resources on this topic. In fact looking back they have a book called VHDL for Programmable Logic, which I have no idea if it what you are looking for, but there you go.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
I read the free ebook titled Free Range VHDL out of pure interest. Found it will written, but as I'm no engineer I cannot tell if it's exactly what the poster is asking for. But might be worth a read. http://www.freerangefactory.org/
A Computer Engineering curriculum is much better than a traditional CS degree for this type of work, so you might look at what texts are being used in high quality CE programs. The Embedded Systems Conferences from UBM are also a good source of training for low level firmware implementation.
- Grab a couple books on C/C++ and Verilog. I highly recommend "Fundamentals of Digital Logic with Verilog Design", great for both learning and for reference. For C/C++, I've always been a fan of the Sam's "Learn __ in 24 hours" books.
- Get yourself a FPGA development card, so you can get some "hardware play" in and familiarize yourself with some development tools. I have an Altera DE1 educational card that's a few years old, but it's got endless blocks on it (displays, LEDs, buttons, flash, SDRAM, VGA, sound... you name it) which makes it a great little card for embedded system learning. There's a whole set of Verilog and Nios (embedded processor) tutorials available for it, and lots of online hackers who have ported x86 processors (Zet project), hardware emulations of the NES, etc... to it. Xilinx and Actel also make some nice evaluation boards that seem to be targeted fairly often by hobbyists.
Other than that... you can study the heck out of wire protocols, but you'll probably forget everything you learn unless you end up implementing it. You're better off trying to learn as many general things as you can - how to create well organized C/C++ and Verilog code, making your designs meet timing and such - so that if you end up having to implement something, you've got the basics already in place and don't need too much incremental learning. Also if you have some fun ideas for FPGA projects, implement your heart out - that sort of stuff looks great on a resume.
Good luck!
There isn't any. It's VMs all the way down now. Hardware is so 20th century.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I recently taught myself VHDL and used Pong P. Chu's book. I liked it quite a bit. It did an especially good job of reinforcing the mindset of approaching VHDL programming as digital circuit design, not software design.
Just like software project, you'll need to actually dive in to learn anything outside of quoting books. Experience is what separate the junior engineers from the fresh out of school.
You can get "free" CPLD/FPGA vendor tools from the big 3 chips suppliers - Xilinx, Altera and Lattice. There are restriction on the design tool - either size/the chips selection, but other than that they are more than generous for some large non-trivial real life designs. The environment also have simulations again with some limitations on speed and/or size which would not be an issue. The same vendors and 3rd parties also have evaluation boards should you decided to go the next step of downloading the design onto the target chip.
As for wired protocol, it is up to you to find the sources from the official standards themselves. Most of them (except USB/Ethernet and some open standards) require some payments. Everything else (i.e books, pre-standards floating on the web) are okay for understand, but should not be the basis for claiming standard compliance without reading up on the real standards and/or 3rd party testing lab.
"skills that separate a novice from an expert" is hands on experience... It is not something you can get in a book or utube.
Both VHDL and Verilog provide you with 1001 ways of designing crappy circuits which don't work. This book tells you precisely which language constructs to use to get good synthesis results which will work equally well with FPGA and ASIC. For most experienced designers this is considered 'obvious' stuff, but if you're new to HDL design, this is a must read on the way to becoming an expert.
I'm really enjoying the testbook for the VHDL/FPGA RTL design class I'm taking now. RTL Hardware Design Using VHDL: Coding for Efficiency, Portability, and Scalability by Pong Chu. It doesn't bog down talking about all possibilities the language allows for legal syntax. The author really seems to focus on common practice for coding into a chip. There's very little if any testbench/simulation in this book, so look elsewhere for that, this one is all about the circuit design. Rather than only explaining what an FSM is, or just that you need a combination of registers and combinational logic, it gives some good suggestion on how to organize your code, such as using two or three separate processes rather than a single one. It talks about coding styles to minimize logic stages for some types of circuits. And it's the first one to explain why getting latches in synthesis is "bad" in a way I could understand, where other books just seem to say "don't allow latches" and I didn't understand why. I find this very refreshing now, as my first exposure to VHDL back in the mod 1990's had a terrible textbook that left me horribly confused about how to do anything useful with the language. And that was very frustrating as I was very interested in FPGAs, and there was no Verilog course at my university. After working with Verilog for the past few years at work, Chu's VHDL textbook has made it a lot easier for me to see how to create Verilog as well, rather than just read to understand other people's code. Chu has some other books that come in VHDL and Verilog pairs. They have project examples to play with in an inexpensive FPGA board. Check them out too.
For firmware and coding hardware, look for books on Embedded style programming, and about driver development. Look up some programmer guides for some ARM chips, they will tell you register definitions and fields and such to program to. I don't know how good these will be, but on my todo list are "Essential Linux Device Driver", "Linux Device Drivers, 3rd Edition", and "Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development". I looked at "Atmel AVR Microcontroller Primer: Programming and Interfacing (Synthesis Lectures on Digital Circuits and Systems) " which may be a good example of some of this as well, and check out some Arduino project books, that seems likely to talk about some of this stuff as well. A reviewer of one of the many AVR books says to go look up the http://www.avrfreaks.net/ website for some free such info. They and similar sites for Pic and Arm should have some relevant information for you. If these all seem too much of the "this is the language" or "this is what the hardware looks like" but not enough of "common practice is to..." type, maybe get a kickstarter project going to make what you need, and start interviewing people that do this every day.
This is where I started about a year ago:
http://www.fpga4fun.com/
Got a Xilinx dev kit, and it didn't take me too many weeks to get my project up to a stage where other people started using it.
Besides programming, a background in general electronics does help. Even if you're coding in a somewhat C-like language, it's nothing like a sequential program, but a description of hardware with real, physical parallelity. To me, it often helps to look at a circuit diagram to understand some debugging issues.
Data sheets from chip manufacturers are essential for some of the trickier points. If you need to choose between the two largest players, I recommend Altera over Xilinx, as they are somewhat more open, but mostly there are no huge differences.
Escher was the first MC and Giger invented the HR department.
For projects with limited resources, it is quite normal to use a subset of the language. For example, you may eschew use of the heap library functions in C, or the use of floating point calculations.
I too use C++ (a subset), even for embedded systems as small as AVR. Having a restrictive environment doesn't mean you can't use object classes and templates.
The main risk with using C++ in a tight memory space is hidden use of the heap (for example in the STL). I don't find that code bloat is a problem if you know what you are doing.
First, I'd suggest deciding what you want to focus on -- firmware (embedded programming) or HDL. If you're coming from a CS background, you might want to start with digital systems and computer architecture before plunging into HDL. Designing a CPU at the gate level will teach you more about how the hardware works than writing a page or two of behavioral HDL. These basics are also good for embedded programming. Without knowing more about your background, it's hard to know what to suggest. If you're coming from PC application programming (or, god forbid, web scripting) with no electronics or low-level background, get ready for a shock -- you're not in Kansas anymore. Personally, I'd suggest starting with some basic 8-bit AVR or PIC projects, since there's a lot of material on the net to help you. I've mostly learned on the job, so rather than giving you books, I'll suggest some topics to study:
Software .text so you can parse the error messages when your program gets too big for the chip it's in. Read this article for some hints in a PC app context.
1. C programming in general and pointers in particular. Use this as a bridge to assembly.
2. Enough assembly to understand what sort of operations there are and how they're used. Don't bother writing huge programs in assembly; just make you sure you can read your debugger's output. This is a good chance to figure out whether your CPU has a hardware multiplier (probably) and divider (probably not). This tells you which operations are fast and which are dog-slow.
3. Where all the pieces of your program go in memory (code and constants in flash, data in RAM). Learn about standard assembly sections like
4. Bit twiddling. AND, OR, XOR, inversion, shifting. Basically, any C operator listed under the "bitwise" section.
Hardware (theory)
1. Registers. CPU registers. Memory-mapped IO registers. Read-only vs. writable registers. Reset states of registers. You're going to be dealing with a lot of registers.
2. General-purpose IO pins and all their features. Look at a schematic in a microcontroller datasheet and understand input/high-impedance vs. output vs. input with an internal pull-up/down. Maybe driver current strength if you want to make *big* blinking lights.
3. Clocking. Where the clock comes from (crystal? internal oscillator?), how precise it is, how it's divided down, and how to turn off the division so the chip will run at full speed.
4. How to read a datasheet. Figure out what voltage(s) you need to power the chip and what (if anything) should be connected to each pin on power-up. Datasheets are very long. Learn to skim.
5. How to limit the current on LEDs with resistors so they don't blow up.
6. How to use a linear voltage regulator to get a clean 5V out of whatever DC power source you can Frankenstein together.
7. At least a cursory knowledge of voltage, current, and Ohm's law. Know how to determine power dissipation in a resistor (compute it) or an LED (read it out of the datasheet).
Hardware (bench-top)
1. How to use a multimeter. Spring for a nice auto-ranging one on eBay.
2. How to wire up a breadboard. Don't bother soldering yet; this is much easier. Hint: keep your wires short and neatly-arranged. Get a wire stripper and learn how to use it.
3. (Optional) If you have some money to throw around, pick up a bench-top power supply off of eBay. A triple-output supply is the most you'll ever need, but single-output is fine for simple MCU projects. This is more convenient and reliable than cutting up a wall wart.
4. (Even more optional) If you have a lot of money and are pretty serious, get a digital storage oscilloscope (NOT an analog-only scope, unless it's really cheap). This will do wonders for your debugging. Buy used unless you're rich or hard-core. Bench-top electronic tools are not cheap.
5. Find a local electronics store. Fry's is a decent choice (for tools, too!), and many cities have smaller but cheaper
Visit the