Slashdot Mirror
Crossing the Divide From Software Dev To Hardware Dev
First time accepted submitter szczys writes "Quinn Dunki spent decades developing software before she fabricated her own 6502-based computer. Here she talks about crossing between software and hardware (or the other way around) and why this is easier today than it has been in the past."
Run the opposite direction!
Software is made up of worlds created by people hopped up on caffeine and suffering from too little sleep. Hardware follows physical laws, software follows no laws.
Hardware is created, finalized and shipped. Software is a never ending dreary of bug fixes, upgrades and incompatibility.
For your own sanity, stay away.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
No. Everything is not easier today. In the mid 1990s I designed a small microcontroller based PC/104 compatible motherboard, wrote a bootloader and small OS for it, as well as the PC Application to download the firmware images to the system. Nobody could ever do that with today's processors. I wire-wrapped the entire prototype, which was possible because the clock frequency was low enough. These days you need to understand RF Analog to do PCB layout, because at 1+ GHZ clock speeds every line radiates and receives like an antenna. You have to really know your stuff, and it is literally impossible to wire wrap it. Even if you really do know your stuff, you need cash, and lots of it, to go from CAD/CAE files to working prototype.
... well obviously. But if the claim is that it is easy to do the hardware and software for a complete system on a par with contemporary designs? No friggin' way. Period.
If the point is that you can still do old school low frequency projects from the ground up
It is, however, easier to fool yourself into thinking it is easy, but if someone who actually knows what they are doing looks at your code they will have trouble deciding if they should laugh or cry.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Yeah, nowt wrong with playing with a 6502 - I grew up on them - but building a 6502-powered toy requires only a few tens of dollars, moderate skill with a soldering iron, and the ability to vaguely follow any of several dozen short articles on putting together a simple 8-bit machine.
Of course it's cool to build your own hobby quality 6502-based machine. And there are probably lots of EEs who would fail at such a project without assistance - not because it's wildly complex but because it's sufficiently esoteric. But that doesn't mean you're qualified to pontificate on the transition from pro s/w to pro h/w development just because you've built such a machine. The tools, goals, risks, breadth, imagination, etc. put into a hobby product are quite different from that put into a pro product.
To take another example, with my ham radio hat on I get involved in lots of cool projects which would never make for a saleable product, but which I'd never get the chance to do professionally anyway, because relevant demand is satisfied for the average consumer in a very different way (e.g. almost everyone is happy with relying on a huge amount of private and political infrastructure to communicate globally).
To expand - and put this more in the context of a mobile phone class device say.
Why open-source software works is:
Widely available repository of code.
Many people able to review it, or sections of it, and understand it.
Ease of submitting tested patches.
Hardware has problems that don't really fit well with this.
The open schematic is the trivially easy part, and not really a problem.
(though in practice, you need a schematic with copious links to design documents, which isn't well solved by open tools).
The number of people who can review it is rather smaller - as you can't
open up a c file, and see a clear error or awkwardness in code that can be edited.
For all but the most basic errors, you are going to have to sit down and
read several hundred pages of hardware documentation about how the chips in question work, in addition to having in-depth knowledge about the circuit design, and costings of likely changes.
Now, you've done this, and generated a patch that you think (for example) lowers the supply current by 1%.
Compile - test.
On a PC, this takes a couple of minutes.
For something of a smartphone class, a one-off PCB may cost several hundred dollars. Then the parts will cost another several hundred dollars in small quantities, as well as being difficult to obtain.
Now, you have to solder the parts onto the board, which is a decidedly nontrivial thing - and if you decide you want someone else to do this, it's probably another several hundred dollars.
So, you're at the thick end of a thousand dollars for a 'compile'.
Now, you boot the device, and it exhibits random hangs.
Neglecting the fact that you are going to need several hundred to several thousand dollars of test equipment, you now have to find
the bug.
Is it:
A) The fact that unlabled 0.5*1mm component C38 is in fact 20% over the designed value, as the assembly company put the wrong one in.
B) C38 has a tiny bridge of solder underneath it that is making intermittent contact.
C) The chipmaker for the main chip hasn't noticed that their chip doesn't quite do what they say it will do, and the datasheet is wrong.
D) You missed a tangential reference on page 384 of the datasheet to proper setup of the RAM chip, and it is pure coincidence that all models up till now have booted.
E) Because you're ordering small quantities, you had to resort to getting the chips from a distributor who diddn't watch their supply chain really carefully, and your main chip has in fact been desoldered from a broken cellphone.
F) Though the design of the circuit is correct, and the board you made matches that design, and all the parts are correct and work properly, the inherent undesired elements introduced by real life physics means it doesn't work.
G) A completely random failure of a part that could occur with even the best design, and best manufacture.
G - may mean that it's worthwhile making two or more of each revision - which of course boosts costs.
Hardware is nasty.
This gets a lot less painful of course for lower end hardware. For very limited circuits, which can be done on simple inexpensive PCBs, and be easily soldered at home - costs of a 'compile' can be in the tens of dollars, or even lower.
> What type of transistor?
P=NP
The biggest barrier to doing cool stuff NOW with homebrew hardware is DRM. Or, more precisely, the fact that any SoC infected by HDMI or the ability to do hardware-accelerated h.264 is going to be encumbered by viral licensing terms that make it nearly impossible for anyone smaller than Logitech to get their hands on real sourcecode and unredacted datasheets for the best chips out there... or even the ones that are 17 steps down from the top, and so ghetto, not even $7 media players from China embedded in HelloKitty knock-off dolls use them anymore.
Before anybody mentions the Pi... it's actually one of the PRIME EXAMPLES of this problem. Yes, there are chips out there that can do things like DVI output that aren't licensing-encumbered... and they cost about 20 times more to do 5% as much. Every single cheap-but-powerful chip out there capable of doing hardware-accelerated video is crushed by DRM-infected licensing and cloaked in MPEG-LA-enforced secrecy.
The Atmel AVR chips kind of ushered in the first renaissance of homebrew electronics. Anybody who remembers the late 90s knows what I mean... the dark era when -- almost overnight -- computer bus speeds skyrocketed to levels that were almost hopeless (16-20MHz is roughly the point where you have to start thinking about things like impedance, crosstalk, and RFI... 30-40MHz is the point where stuff that's not properly designed just plain doesn't work). Microsoft's full-on assault on the parallel port -- the last port on a modern PC that was fast enough to do realtime bitbanged i/o, but slow enough to interface directly with homebrew hardware -- was basically our equivalent of the Roman Empire's fall... not with a bang, but more of a whimper (parallel ports still sort of worked post-NT, but GETTING them to work was an act of endless agony, at least whenever you had to do it on a virgin PC).
The Pi is a bittersweet next step. On one hand, TCP/IP was the deathblow for 8-bit MCUs. Yeah, Wiznet gave us a few more years of life support, but with the Pi, we're now in a situation where it costs more to pair up a Wiznet chip with something like an Atmega 2560 than it does to just buy a Pi. And the Pi finally gave us something that historically was always brutally expensive... abundant cheap ram (anybody who's ever felt the sting of implementing XRAM on an AVR knows what I'm talking about here, especially if you were masochistic enough to try doing it with a breadboard). On the other hand, the Pi to the AVR is kind of like a 400MHz Coppermine Pentium III vs a 16Mhz NEC V-20... it's faster and cheaper, but we're right back in "this board is a half step away from being a de-facto IC" territory. For now, we still have I2C and SPI, but I dread the dark day when someone starts selling "hobbyist" boards that only have USB and a HDMI port.
The next renaissance will be FPGAs... probably, right around the time the older patents owned by Xilinx and Altera start to expire. Right now, even moderately advanced FPGAs are breathtakingly expensive for what you're really getting... and god help you if your needs go beyond what their free tools will allow you to do. Software tool costs are particularly tragic in the Atmel arena. They actually have an entire line of AVR chips that hardly anybody knows about, and even fewer hobbyists actually touch, that are fairly cheap & are basically an AVR with an onboard CPLD in lieu of the usual i/o. The problem is, the development tools to program them aren't just non-free... they're so absurdly expensive, you'd almost think they don't *want* anybody to buy or use those chips.
Without having a good understanding of hardware development you can not be a good Desktop or Embedded level developer.
I don't know why Slashdot linked it, but Quinn Dunki is very regularly featured on HackADay for her technical ability, not "because she's a woman".
You find it "odd" that a woman in technology doesn't plaster pictures of herself all over? Is this your first day on the internet? Do you go to male software developers' websites and find it "odd" if you can't find a picture?
Why don't you know those things? At least in overview?
Some people are actually curious about technology of all sorts and have an interest in understanding it. As a software developer, I find having a decent knowledge of the hardware to be quite helpful.
I am a fan of the people who build their own computers from MSI components.
I discovered microprocessors around 1980, when I was 14 years old, but here in little Belgium I was never able to do something with that knowledge at that time, but my interest got me a bachelors degree in electronics, and a good (better) understanding on how software works. I was always interested in FPGA, but it is only since 2010-2012 that I got finally a possibility to do more than programming. I got my master degree in electronics, and on the way I learned VHDL (one of the reasons that I wanted to go for my master degree), and got an interesting school assignment about on the fly reconfigurable hardware and a thesis involving the Spartan-6 Atlys board.
Also, since 2004 I have been working on and off studying Common Lisp, and processor emulators.
Well, since September 2012 I have been designing a simple microprocessor, for which I first did the implementation of an assembler in Common Lisp, and a simulator, and start of this September I finally got around implementing the simple computer system in VHDL. I was surprised how easy it was, given that I only have about 1 to 2 hours a day in the evening to work on things. It is currently a 16-bit thing which uses 64kB of FPGA block RAM.
Thus, with software knowledge and VHDL, it should become even easier to build custom microprocessors.
And I am not even crossing this line. It has always interested me to go for both hard- and software, but due to circumstances I ended up more on the side of software.
Having the room for doing electronics properly is not that easy. One needs a place committed to it, which can not be used by other people in the family. For that reason, I like the concept of FPGA development boards. It lets me do what I want to, without needing to invest in dedicated space.
The Atlys board gives me all I need for growing in the future. The first part should be to make the system run using the on-board serial controller, so that I can control it through a terminal program, having access to a keyboard and a character terminal.
And I am not done with software, because one of my goals is to write a Lisp system for running on the system, and then start to optimize the ISA for better performance. Other things: go to a 32-bit implementation and start using the on-board 128 MB RAM memory.
I've taken the high tech way to designing hardware - FPGAs. So far I've built quite a few bits and bobs - 200MHz GPS referenced frequency counters, a 60 stage Mandelbrot pipeline (12B Ops per second @ 200MHz), SDRAM controllers, my own processors, video adapters, and implemented the DVI-D protocol. I've even worked out how to make a chip with 1Gb/s outputs work at 1.5Gb/s - yay! 1080p! Everything is in a HDL (Hardware Description Language) so can be used by others on their own projects. It isn't that expensive - dev boards start less than $100.
As Quinn points out it takes a very long time to get everything working correctly - you software guys don't know how lucky you have it!
I've put some of my projects on my wiki at http://hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects if anybody wants to take a look.
Not quite - hardware is only good at petrifying O(1) algorithms. They have to be tightly bounded in space and time.
OK, more precisely... 30-40MHz also happens to be the point where the demands imposed by a "proper" design ALSO outstrip what you, as an individual, can build with a home-etched 2-layer circuit board, hand solder, and/or troubleshoot when it doesn't work reliably. It's the point where things like 4-layer circuit boards with ground planes and solder masks become non-negotiable requirements. And it's the line in the sand where getting multiple devices to coexist and share that same high-speed bus becomes a REAL problem.
Witness the clusterfuck failure of 40MHz VL-bus. There's a reason why the industry took a step backwards to 33MHz for PCI, and so many budget motherboards had only 2 or 3 slots... it was just too hard/expensive/unreliable to go faster, and adding more PCI slots required additional active buffering circuitry. 40MHz VL-bus generally worked fine for local-bus video when the chips were soldered to the motherboard, and was generally "OK" if you had exactly one VL-bus slot on a high-quality motherboard with exactly one high-quality video card plugged into it... but was a complete NIGHTMARE of crashes if the board and/or card cut corners, and was almost always -- without exception -- flaky under any conditions if you tried to use TWO VL-bus cards. I know, because I made the mistake of buying a Promise VL-bus caching hard drive controller circa 1993 or 1994, and saw my system's reliability go down the TOILET the moment I connected it.
I can almost guarantee that if Woz's first home computer had been his original Apple I design, but built in China with a hypothetical 50MHz COG 6502 under a glob of epoxy on a credit-card sized circuit board, and the original Apple expansion bus exposed as a block of tiny test points with 25-mil spacing at that same 50MHz bus speed, he probably would have thrown in the towel in frustration and given up on trying to bitbang NTSC color video or make an affordable floppy drive controller for it. Certain things are just beyond the realistic ability of a hobbyist (or even many small companies). The line between 16MHz and 40Mhz isn't necessarily razor-sharp, or even a brick wall, but it's absolutely *there*, and anyone who tries to build something at home that's substantially faster than 16Mhz is eventually going to run into (or trip over) it.