The site is a bit slow to load but if you are new to working with Arduino's and other small boards like that and want to play around with them it is worth the wait.
Title nit-pick: I'd have used 'low level programming' rather than 'hardware programming', programming hardware has a different meaning.
And TIL that there is a distinction between programming on the hardware and programming the hardware, might be something to look into
Nonetheless them learning embedded systems programming is still an interesting read! Especially when coming from a language like C#
Aside, I'm curious what resources you used to self teach hdl/fpga development. I have a formal background so I usually give poor explanations to people without any background. It's hard to figure out where I can start from when people ask questions.
Languagevise coming from C# and learning c or c++ for low-level programming was quite smooth, also coming from python was the hard part, that was a lot of comforts I had to give up.
But as I am also learning some micropython, I might write about porting stuff to it in the future.
Where as when doing hardware programming, you have to necessarily understand the individual hardware to program and control it - there is often no abstract software lawyer in between to make this task easier for us. And the hardwares are quite diverse.
Even books. I read ~two Arduino books that would write something along the lines of "we need a pull-up resistor to keep the pin from floating", without ever explaining what floating pins, pull-up, and pull-down resistors are. The concepts are not all that hard, except that they are often not properly defined or explained.
I'm especially concerned about the track width and clearance and stuff. For 12V and I think a max of 8A I calculated 2mm width, 0.6mm clearance, 1.5mm via diameter and 0.75mm via drill diameter.
Most PCB houses can handle 8mil (0.2mm) traces and clearance with no problems.
Best thing way to handle vias in high current designs is to avoid them. Run the trace from point A to point B on the same layer. Second way is to use planes for distribution. Other things you can do. Make sure there isn't a thermal relief. Use multiple/arrays of vias.
Other than that, it's pretty foolproof, so enjoy the process!
In any case, I sort of went the other way. I started in hardware, and gravitated towards software.
I think that each discipline could learn from the other, as most hardware, these days, relies on software as a critical part of its operation, and a lot of software is written as if the hardware on which it depends, doesn't exist.
I look forward to reading it, once the site is back up.
Good stuff. Welcome to my world, although I seldom work on any kind of firmware, anymore. I'm mostly about driver-level stuff, and I try to leverage platform transport, as much as possible.
I have blown up $40,000 (in 1987 dollars) devices with software errors.
Why do you have to obfuscate the language so much with technical jargon? Just say 'the costliest mistake'.
Just imagine a whole team of people working on a combination of hardware and software, some of the hardware prototype level floating point gear obtained directly from the manufacturer under NDA (that's non disclosure agreement) and then someone decides to drop a dime into the machine.
The dime is the investment, the time it took to cause the damage the factor that you normally would use to indicate your positive gain on that investment, in this case a couple of milliseconds and a few hundred thousand dollars was gone beyond recovery. Project down the drain.
I guess when you explain it it is no longer that funny, and HN is more than capable of decoding the original.
Fortunately a heroic 7400 quad nand gate sacrificed itself to save anyone. He said all that was left was the leads sticking out of the PCB.
My cousin hooked up VCC and gnd backwards and blew up a prototype RISC processor. Only a dozen working ones in existence. Please sir may we have another?
How on earth did you blow something up from software? I'm guessing you were touching power delivery from software for some reason?
I was designing ATE systems, and I accidentally delivered 240 volts to a 110 volt configuration, and discovered the fuse didn't work.
"The most basic pins are digital pins, they can only either be on or off. You would, for example, use them to check if a button is pressed. Or if you use them as output, turning a led on or off."
[intermediate content deleted for brevity...]
"And while those pins cannot output a true analog signal, they can use a technique called PWM to approximate one by only switching the signal on for some time."
Fascinating! Knew about digital pins before this, and PWM generally speaking (with respect to PC fans, power supplies, etc.) -- and yet, I did not proverbially put "2 + 2 together" in my head! (For some inconceivable reason I always conceptualized PWM as analog/multiple waves per unit time, in nature...) Yup, makes a ton of sense!
Anyway, thanks for the great article!
People, like Ben Eater, are making great kits.
Components are not so expensive. You can (and will) fail. Get more, get gear, try again.
One can get good gear, scope, meter, solder station, etc... at good prices. Used pro gear is a good option too.
Making things, signal generator, logic analyzer, are also fun projects.
And there are many programming options from assembly to Python showing up.
I love this stuff and often couple it with retro computing. The speeds are low enough to make most things possible for fairly new comers.
Jump in. It is fun!
Great post OP.
Weird, the breakout pin between IO21 and IO19 is silkscreened GND, but the label says NC, not connected. The dev board datasheet says that pin is not connected, which would be a fun trap for someone who tried to use that pin as a ground, but a different schematic on the site says it's tied to module ground. They don't seem to have a PDF of the actual PCB anywhere I can find.
With very modular devices, it's easy to avoid that - since you're basically building stuff like as with lego bricks, and things are abstracted form you - but if you need / want to build your own sensors, or customized setups, you'll need to know a thing or two about electronics / circuit analysis and design.
There is a cost for equipment and parts when working with hardware.
Creating effects in the physical world with your code feels awesome. Learning and building physical tech is just awesome all around.
I would also be interested in some good self study suggestions.
But of course, software engineer has no particular definition and lots of people use the term to describe themselves, even if they have no real engineering background.
Lately I started experimenting with radios. It is difficult. Let me know if someone has a good guide they read.
Will fix the bit about the PWM in a second