My name is David Lynch and I am the creator of Sabertron Foam Swords with Electronic Scoring.
I am working on an entry-level book on embedded design called "The Maker's Guide to the IoT: MCU Edition." I figured that it could be helpful for a lot of people to follow the blog which is the text of the book that is being published as I write it. I am starting out with basic tasks to help beginners get started but the series will ramp up pretty quickly to cover the use of many of the available peripherals in the EFM32 family of MCUs to interface external devices.
As a computer engineer with many years of experience in x86 hardware and software, transitioning to embedded development was more challenging than I had expected. I wanted to capture my struggles and help pave the way for others so that they could bridge that gap with less pain than I had to endure. So hopefully the series is being written in a way that answers the obvious questions that many beginners ask. I am looking forward to some good discussions on the ideas and examples presented!
The latest post is from Chapter 4, Controlling External Devices: Part 3: Control Off-Board LEDs and the blog series is still in beginner territory. Chapter 5 will introduce clocking, interrupts, and build an LED chaser.
took a peek and went ARRRGH
Solderless breadboard & hookup wire
is about the worst you can suggest, the connections are, at best, erratic and, if some poor sod decides to attach a micro you will end up in a nightmare of reflections with the rise/fall times of todays micros
While this arduous process is sometimes required for ultra-high-speed circuits, it isn’t usually necessary for most MCU-based projects.
you are sadly mistaken, the importance of short lines and close proximity of decoupling has nothing to do with "ultra-high-speed" it only has to do with rise and fall times which will be the same regardless of your clock speed
The solderless breadboard has worked fine for my experiments using I2C and SPI at a few MHz. (I've even run it over several feet with no issues.) But just because it is working great now doesn't mean that it will work for every device in every situation. I understand that and I warn that the system will not be as stable as a regular PCB. If you can get it to basically function, it pays off in fewer board spins. I
learn so much in just trying to get things to work that even if it fails, I will usually learn something that improves the quality of the first PCB.
The speed of the bus impacts the ability to overcome signal integrity issues. The ringing of reflections have plenty of time to settle when the bit times are sufficiently large, as long as the clock edge isn't compromised. I agree that it is the edge rate of the signal that is important, or more importantly the frequencies that make up the edge that matters but the term "High Speed" generally refers to signaling that requires those fast edge rates. After all, Howard Johnson named his book High Speed Digital Design, which is/was the bible on signal integrity.
Thanks for taking a peek. I am new to MCU's so I am sure that you could lend interesting alternatives to the solutions that I present.
it pays off in fewer board spins. I learn so much in just trying to get things to work that even if it fails, I will usually learn something that improves the quality of the first PCB.
true, but not quite
you can spend so much time fiddling with bad connections, "let's try this with a lower clock", ..... that a first spin with a few cuts and wires will save you time and cut down your "aspirin budget". fewer board spins sounds like more than two, I, usually, need no more than two, the first with cuts and wires gives all needed info (unless you ROYALLY screw up with the first which breadboarding would not avoid)
The ringing of reflections have plenty of time to settle when the bit times are sufficiently large, as long as the clock edge isn't compromised
true, but not completely.
a ringing clock will not 'settle'
true, but not completely.
a ringing clock will not 'settle'
This is the truth. You can slow your SPI port down from 10 MHz to 10 kHz, and if the clock is ringing, it can double-clock and you're still hosed.
I agree that there are some limitations to how much of a design that will actually work with a bread board. But I am pretty sure that if I had read "install a PCB-designing software, learn how to use it, learn how to properly design hardware, send the design files to china and wait two weeks" I would have been much more likely to never read the next chapter in this book. I think you have to understand what audience this guide is targeting, and it's people like me, that has no actual experience in building "things". From the start off, I might not even know what I really will end up having on the PCB, so breadboarding might be a quick way for someone just to play around with different components.
Previously, I've had some ideas floating around, but they quickly die of in the "have to learn some PCB tools"-phase. Now that I know that breadboarding actually work for at least the prototyping phase of a project, I'm far more likely to actually do this. You can argue that since I don't want to invest time in learning about PCB manufacturing, I'm not really interested in my project, and that's probably true, but still there's a lot of things that I just want to play around with to see if it's feasible.
Just my $0.02. I think that both approaches are very valuable, but at least from my perspective I'm much more likely to give it a try using David's approach, even given the limitations and the pain I know will come from ringing clocks.
David, I guess you will cover PCB-production later? Will you link that back to this chapter as an alternative approach, if you already know your entire hardware design?
But I am pretty sure that if I had read "install a PCB-designing software, learn how to use it, learn how to properly design hardware, send the design files to china and wait two weeks" I would have been much more likely to never read the next chapter in this book
You do not get my point.
breadboarding can work, but I will, almost, state that breadboarding require more knowledge than PCB layout. We are getting to the adage that "a wire is not a wire". I can give examples, one classic is a supervisor chip that occasionally misfired because there was 5cm trace to the decoupling cap, try handling that with a pegboard. To work with breadboards, especially pegboards, you must constantly think "can this wire be long or not" and a ranking amateur is not likely to have those thoughts. In the tome discussed here I see no "appropriate breadboarding techniques" and no "this will not work on breadboards because..." text
A bit of background:
Over the years, there has, in various fora, been several posts, where the reason for the project not working was insufficient breadboarding technique.
were I in doubt where something would work, I would not do it (see the quote below"). Would I be, while protesting, forced to 'breadboard' something, I would, by far, choose a "solder dot" board over a pegboard. The "solder dot" board will have far shorter connections than a pegboard.
remember "successful testing does not prove the absence of bugs, it only proves the absence of known bugs".
Breadboarding makes it tempting to "try and test" one of the most common reasons for intermittent failures.
One of the nice features of the EFM GPIO pins is that you can select Drive Strength. Keeping a low drive strength should help to prevent ringing. Further, for simple GPIO like driving an LED ringing is of no consequence. And neither is it for an (oversampling) UART. I even think it will not affect I2C too much. But for SPI it can be a real problem. And of course VDD decoupling and crystals never can cross to a pegboard. But in general I agree with Erik that it is much preferred to use soldered breadboard over jumper-wire pegboards for prototyping.
I have seen (my feeble mind do not remember where) a book similar to what you are talking about that came with a PCB where every 'experiment' could be soldered on
I wonder , isn't the mbed , especially with the availability of the easy to use power management API and the mbed-os(for IOT, a bit in the future) a more appropriate abstraction for makers ?