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."

Comments

buy a Pi

[Anonymous Coward]

just buy a Pi

Re:buy a Pi

[Anonymous Coward]

What does a transistor do and how does it do it?

Re:buy a Pi

[ebno-10db]

What type of transistor?

Re:buy a Pi

[Anonymous Coward]

There are different types? My mind is now blown. I'm going back to python hacking. This is too confusing.

Re:buy a Pi

[Anonymous Coward]

> What type of transistor?

P=NP

Re:buy a Pi

[ebno-10db]

Touché. Hardware and software have more in common than I thought.

Re:buy a Pi

[Anonymous Coward]

The correct answer is: who gives a fuck? Only a handful of people really need to know and we have machines to mass produce them by the peta-quadrillions. Hey, here's some more questions about modern life:

1) What is oil and why is it magical?

2) How is electricity generated and how does it get to you?

3) Where does your industrial farming happen and how does food get get to you?

4) How is municipal water treated and how does it get to you?

5) What does a turbofan do and how does it do it?

6) What is a silicon boule and how is it made?

Etc. Am I to understand that unless you can answer these questions in detail you aren't allowed to use industrial civilization, light, food, drinkable water or machines that fly across the ocean or buy a transistor?

Re:buy a Pi

[sjames]

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.

Re:buy a Pi

[Anonymous Coward]

Buying a Pi isn't really "crossing the divide" - it's more like standing on that glass platform jutting out over the rim and pretending your'e exploring the canyon. :)

Re:buy a Pi

[gl4ss]

knowing most of those things should be a requirement for voting...

dunno why the fuck buy a PI though.

just buy some usb sensors and actuators if that's the thing you want.

Re:buy a Pi

[Anonymous Coward]

Damn, that was a good one.

Re:buy a Pi

[TechyImmigrant]

Bravo!

That article was fucking awful.

[Joining Yet Again]

tl;dr "Software is a bit like hardware but hardware is less virtual."

Am I missing some point here? Maybe this person has achieved something I don't know about that makes their message more relevant than I can see.

Re:That article was fucking awful.

[Anonymous Coward]

It's tough to be negative about someone who appreciates the 6502, but there is a huge difference between putzing around with discrete components and DIPs vs true hardware engineering these days.

Stuff that was hard awhile ago is definitely easier now, but technology has moved on...professional hardware designers are doing much more complex stuff.

Re:That article was fucking awful.

[djupedal]

Reading between the lines, it may be that the point of the (IT/Tech) article was that a woman was the principal, rather than a man.

Yay for that, but otherwise it seems to be celebrating mediocrity. . .

Re:That article was fucking awful.

[Joining Yet Again]

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).

Re:That article was fucking awful.

[Anonymous Coward]

On the one hand, one person's mediocrity is another person's learning experience.

On the other hand, the TFA is a personal journal entry, of personal importance, but it's not news.

Re:That article was fucking awful.

[Anonymous Coward]

Reading between the lines, it may be that the point of the (IT/Tech) article was that a woman was the principal, rather than a man. Yay for that, but otherwise it seems to be celebrating mediocrity. . .

Yes, I got that from the article too. Calling attention to something just because a woman did it isn't going to help make computing more gender-neutral. It is an action in the very opposite direction in fact. "Girls can do stuff too!" implicitly validates the idea that anyone thought they couldn't.

I can't help but notice there are no pics of her that I could find. Though there are references to her gender all over the site. That's a bit odd for someone with a Facebook presence and otherwise saying "hey world look what I did" so not exactly shy. If she is not obese and-or not homely a modest pic would help to dispel those stereotypes of "nerd girls" too.

Re:That article was fucking awful.

[Anonymous Coward]

I find a good way of evaluating gender issues is to take the statement and flip it around, malefemele.

When you do that here, you get: "If he is not obese and-or not homely a modest pic would help to dispel those stereotypes of "nerd guys" too." Which shows you just how ridiculously prejudiced it is.

Re:That article was fucking awful.

[Miamicanes]

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.

Re:That article was fucking awful.

[ArbitraryName]

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".

Re:That article was fucking awful.

[ArbitraryName]

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?

Re:That article was fucking awful.

[sjames]

Stuff that was hard awhile ago is definitely easier now

Sometimes. 6502 systems come up taking memory for granted. On a modern x86 or ARM, there isn't any system memory when the CPU comes out of reset. It has to initialize the memory controller and the DRAMs themselves before it can use system memory. It's much easier to write the firmware for a 6502 based system.

Re: That article was fucking awful.

[Anonymous Coward]

OpenCores.org and FPGA

Re:That article was fucking awful.

[lisaparratt]

Apparently someone can't operate Google Images.

Re: That article was fucking awful.

[jones_supa]

+1 for this. In the current world situation, FPGAs let a DIY hardware hacker to do a lot of cool stuff with quite free hands. Of course the design tools are proprietary, but they are free of cost and they let you do any kind of implementations that you want.

Re:That article was fucking awful.

[gl4ss]

well do you want to see pics of men who have done sw for 3 decades?

I guess the real problem with the feat is this http://www.6502.org/homebuilt/

Re:That article was fucking awful.

[TechyImmigrant]

> 30-40MHz is the point where stuff that's not properly designed just plain doesn't work)

So design it properly. FFS.

Re: That article was fucking awful.

[TechyImmigrant]

Yes, yes and yes.

There plenty of things to hack in hardware, but if you want to play with digital circuits cheaply, an FPGA is your friend.

Re:That article was fucking awful.

[zwarte piet]

I always assumed a microcontroller on the mainboard does all the setting up before setting starting the processor.

Re:That article was fucking awful.

[sjames]

Alas, no. In the x86 world, the initial code runs without any memory just long enough to set up 'cache as RAM mode' where the cache itself acts as RAM even though there's nowhere to write back/through to. That can be a bit fragile since cache line eviction can still occur and there's nowhere to evict it to. It the late '90s the controllers were a bit simpler and the memory could be set up using only ROM and registers.

To top it off, it's all mostly undocumented and a few chipset manuals are works of pure fiction.

Re:That article was fucking awful.

[Miamicanes]

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.

Re:That article was fucking awful.

[mikael]

When you develop hardware, you use software simulators, FPGA boards with bit files (a binary representation of the hardware circuits that can be stored on flash memory) and actual silicon. The software simulator is meant to simulate the memory mapping and parallel nature of the hardware, the FPGA boards do this a bit quicker, and actual silicon is the real deal. Only the first two can be updated if things don't work as planned unless the hardware has programmable microcode.

Re:That article was fucking awful.

[TechyImmigrant]

Yes. A board with a ground plane is handy for higher frequency signalling. If you have sufficient cash, you can use one the of hobbyist PCB suppliers to build the PCB for you on a 4 or 6 layer process.

An alternative for the home hobbyist is to use impedance controlled wires, like twisted pairs or mini coax, terminated correctly. This is more fiddly, but still doable.

Re:That article was fucking awful.

[Anonymous Coward]

She's not obese. She's not homely, just average-looking...like most people.

She races a car emblazoned "PUSSY WAGEN" :D

Re:That article was fucking awful.

[Anonymous Coward]

Cache line eviction CAN NOT occur, as the cache is invalidated by the reset vector, and the processor initialises with the cache and MMU entirely disabled. Even if the processors BIST is buggy and doesn't do what the chipset manual states it should, all a cache-eviction is going to do is generate some random garbage signals on the DRAM signal lines IF the DRAM controller has been enabled, or nothing if those write transactions arrive at the powered-down DRAM controller. Except for weird crash and reset debug scenarios, we don't care about the contents of DRAM before the system has booted, so it doesn't matter if those stray DRAM writes mess up some of the DRAM contents. In those weird crash and reset debug scenarios, we should be hitting the soft reset vector, and not executing the DRAM initialisation functions.

Re:That article was fucking awful.

[sjames]

Remember, this is cache as RAM. The cache IS the memory the firmware is depending on to function. If it gets evicted, you crash. Imagine a program in C. Now, suddenly zero the stack while it's in a function call and see how it performs.

Meanwhile, the DIMMs are programmed by accessing specific relative locations in memory with the controller set to a special mode. That won't work if other writes get in the way.

Re:That article was fucking awful.

[zwarte piet]

Can't wait till chip manufacturers have their tools so flexible that they can offer to make small series of custom designs for an affordable price and a quick turnaround time, like what pcb prototyping services are now.

Everything is easier today!

[mveloso]

Geez, when I started programming all you had with stdclib. Now I have teams of people who know orders of magnitude more than I do doing my bidding. It's great!

Seriously, though, everything is easier these days. There's a ridiculous amount of stuff out there, if you have enough time to plow through it all.

Re:Everything is easier today!

[Zero__Kelvin]

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.

If the point is that you can still do old school low frequency projects from the ground up ... 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.

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.

Re:Everything is easier today!

[Anonymous Coward]

"It is, however, easier to fool yourself into thinking it is easy,"

I've noticed that disease in space and 3D printing stories.

Re:Everything is easier today!

[Anonymous Coward]

It helps when so much software is open source and/or written in JavaScript these days.

I remember back in the olden days when HyperTalk was relevant, HyperTalk scripts were inherently open source (unless obfuscated) in the same way that JavaScript code is inherently open source. I wished really hard that more software could be open source, and a couple of decades later, my wish has come true.

Re:Everything is easier today!

[queazocotal]

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.

Re:Everything is easier today!

[Anonymous Coward]

Even worse using your example:
1. Your cellphone has to undergoes external lab certification for FCC compliance, UL etc for safety compliance - schedule, cost
2. Your cellphone has to be tested with your carrier customer to make sure that it works with their network.
3. You have to deal with component shortages and the various lead time and any stock issues for the components.

If any changes due to 1 & 3, you have spin the board and goes through the process again. Hopefully #2 can be resolved with just a firmware update.

Hardware has setup charges for the plastic injection mold, PCB, production set up charges, cost to stock inventory of part (also including parts that you had in one rev but not used any more), test equipments (own or rental)

Re:Everything is easier today!

[ArbitraryName]

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.

No one made that claim, Don Quixote. Settle down. It's a lot easier to do what you did in the 80's and 90's now though, simply because there's a lot more easy to find information.

Re:Everything is easier today!

[Anonymous Coward]

2. Your cellphone has to be tested with your carrier customer to make sure that it works with their network.

Umm, what? I can use any GSM/HSPA phone with my carrier as long as it supports the correct frequencies and is FCC certified.

Re:Everything is easier today!

[Anonymous Coward]

>If the point is that you can still do old school low frequency projects from the ground up ... 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.

Field-programmable gate arrays have come a long way. Granted, you won't be making any Itaniums but no one person could hold a design of that size in their head anyway.

Re:Everything is easier today!

[Anonymous Coward]

Yes, because someone actually tested it. The stations software+hardware used by the customer does not necessarily implement the protocol 100% the same way as the one you tested with. Even if it was exactly the same frequency it's possible to make a device that works on the cell towers of company A but not those of company B.

Re:Everything is easier today!

[Anonymous Coward]

And the best thing about using the 6502 is that you can even run it in JavaScript!

Re:Everything is easier today!

[flimflammer]

I think you missed the point. They're not saying doing things at the bleeding edge today is easier than the bleeding edge yesterday, they're saying doing the things bleeding edge yesterday are easier today.

Re:Everything is easier today!

[sydneyfong]

There's a ridiculous amount of stuff out there, if you have enough time to plow through it all.

That is what makes it hard these days. And once a while you still have to write programs using the standard C libraries (stdclib is C++, you lucky bastard ;-p)

Re:Everything is easier today!

[xtal]

Bollocks.

The transmission line tools are all there. I've done board up ARM designs in a basement, from the IC through to bootloading.

It wasn't wire wrap cheap, but it wasn't undoable, either. There are solid reference designs you work from. My budget was about $35,000 in 2005.

What's different today is documentation is very good, everywhere, there are lots of reference designs, and places to get help. If the platform you're working on doesn't have those, you go somewhere else.

The Pi has a full set of open designs. Tell me where you were going to find those in the 90's?

Re:Everything is easier today!

[zwarte piet]

Nobody makes you use clocks in the Gigaherz range. Atmel and numerous other brands still make 8 bit microcontrollers that can go as low as 32khz or as high as 20Mhz. Is up to you and all the hf stuff happens in the chip anyway. Recently designed a vending machine controller with an all thru-hole board and a clock of 3.386Mhz. No problem.

Re:Everything is easier today!

[zwarte piet]

Wirewrapping and blinkenlichten. Sounds like fun. :)

Re:Everything is easier today!

[Zero__Kelvin]

Can you read?

Re:Everything is easier today!

[Zero__Kelvin]

"My budget was about $35,000 in 2005."

I did mine for less than $300.00. See the difference?

"The Pi has a full set of open designs. Tell me where you were going to find those in the 90's?"

I told you ... I designed one myself from the ground up. Now if your point is that it is much easier to design hardware if you just buy it pre-designed and pre-made, then I totally agree with you. Buying it pre-designed and manufactured is indeed easier than designing it yourself.

Re:Everything is easier today!

[Mr.CRC]

Thru hole, in 2013? Jeez, I'm even designing mostly SMT for home projects like Nixie clocks. I find SMT easier to work with than PTH.

Run!

[sycodon]

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.

Re:Run!

[Anonymous Coward]

But those worlds can be so incredibly fascinating...

Re:Run!

[GiganticLyingMouth]

... software follows no laws.

Tell that to my compiler. I'd say if anything software is very structured; you have a limited pool of recognized syntax that can be combined in specific ways. If you're using a library, you have to adhere to its API. Ultimately your code will be running on some processor, which has a limited set of instructions it can perform. Software has no laws? Hardly.

For your own sanity, stay away.

Sounds like it might already be too late for you...

Re:Run!

[Anonymous Coward]

Yeah but hardware is mass-produced in China, at least with software you have some hope of working in North America.

Re:Run!

[Anonymous Coward]

Well said. And that's why there is no such thing as a "Software Engineer". When everyday software is truly provable, then programmers can move up the ranks and join electrical and mechanical engineers.

Until then, they're programmers, developers or even some cool new hipster term you want to apply. But not engineers.

Re:Run!

[Anonymous Coward]

Yeah but hardware is mass-produced in China, at least with software you have some hope of working in South Asia.

Fixed.

Re:Run!

[Anonymous Coward]

Engineering isn't about proof, that's math. Engineering is about tolerances.

Re:Run!

[Anonymous Coward]

> Until then, they're programmers, developers or even some cool new hipster term you want to apply. But not engineers.

What elitist crap. Engineering just means designing and building things based on a scientific understanding of how they work. That's what programmers do. The understanding comes from computer science. Yes, it's immature and not formalized, but it's honest-to-goodness engineering nonetheless.

Or do you think no engineering was ever done before IEEE came along?

Re:Run!

[fliptout]

FWIW, many states' engineering licensing boards are starting to offer a software engineering licensing exam.

Re:Run!

[slew]

State PE (principle and practice of engineering) exams have had software options since I took them back 23 years ago. The main thing new is that it used to be an small optional element of the Electrical Engineering discipline, eventually became a larger optional element of the Electrical/Computer Engineering discipline, and now (just starting last year) Software Engineering test is available as it's own discipline.

The just released pass rate for the new PE-SW test is pretty dismal (~50%) compared to the PE-Electrical/Computer test (tends to hover around 66%). This is probably because many people who took the test the first go-around probably only had background as "programmers" or "developers", and few have a broad enough background (or studied sufficiently for the test), to understand and score well in all the elements of the test.

The software elements of the Electrical/Computer Test were more geared towards programming questions, and computer design issues which is probably more comfortable material for the typical EE-turned-programmer. In contrast, the PE-SW test covers stuff like UML, Software security audit (like common criteria), maintenance, testing, requirements management, etc... (in addition to traditional programming and algorithms stuff). A good portion of the test is a bunch of generic engineering stuff that many programmers/developers never bother to learn.

FWIW, back 23 years ago, getting a PE license for computer stuff wasn't really worth much unless you lived in Texas (that state is super picky about anyone that even hinted about being an engineer or a business offering engineering services if they weren't licensed). The company I worked for was forced to create a new title for all the FAEs (field applications engineers) because of this restriction although Texas PE board eventually relented and gave field engineers and test engineers a PE waiver to be compatible with the rest of the world.

I'm guessing that the PE-SW is really only gonna be valuable if you are working on government contracts. Not saying it wouldn't be a good for SW engineers to up their "engineering" game, but often what starts as licensing often morphs into a lever to limit the number of people in the profession (basically like a guild). Given that any limits will likely just accelerate the migration of SW offshore, I doubt any attempt to make PE-SW a requirement will go anywhere...

Re:Run!

[gl4ss]

I think you mixed up mathematicians and engineers.

engineering isn't about absolute proofs, it's just abut having expertise to know that a certain solution is good enough and doable for the job at hand. be it a house, navigation clock, ditch or a football that needs to be created.

Re:Run!

[leaen]

Engineering isn't about proof, that's math. Engineering is about tolerances.

No engineering is about responsibility.
If you call yourself a engineer be prepared when somebody asks:
Who is responsible for this crap?

Re:Run!

[AmiMoJo]

Hardware is created, finalized and shipped.

If only that were true. Almost all older devices have some kind of bodge in them. A wire soldered on here, an extra resistor there. Sometimes you can't even see where they realized a component value was wrong and re-fitted all their existing stock. The only reason it's less common now is that more things have firmware and can be bodged via a software upgrade.

Not that simple

[wiredlogic]

Designing something that runs close to the DC end of the spectrum like a 6502 requires far less engineering know how than pushing into the high speed domain beyond 100MHz. That doesn't invalidate the value of designing with "old" tech when if will suffice but it isn't a viable way to change career paths.

Re:Not that simple

[Hans Lehmann]

I don't necessarily agree. If you're designing the chips, then designing high speed devices today (what with all of the simulation & layout tools available) isn't really any more difficult than it was for the guys that designed the 6502. Likewise, if you're designed a product that uses those chips, you have enough tools at your disposal to make sure the design somewhat works at the first iteration, compared to back then when you might spend weeks wire wrapping and reworking a prototype board before you could think of paying someone to lay out a PCB with tape and mylar. Myself, i went the other way. Started out as mostly a hardware designer with 8080's and analog video gear, now I'm mostly software and write CUDA programs to do the same thing.

There is no divide

[Anonymous Coward]

If you don't know both, you are only using half your brain

Re:That article was fucking

[Anonymous Coward]

hardware can be immensely satisfying, because you end up with something you can hold in your hand when you’re done.

That's what she said! Literally.

Convergence is happening

[FishOuttaWater]

I was trained in college as a HW guy, did a few boards and ASICs, and now I'm a SW guy. Hardware is increasingly done in ASIC's / programmable gate arrays, and PLD's which are now written in programming languages like Verilog and VHDL. It's much like software, but massively parallel. With machines coming with more and more cores now, the differences are shrinking rapidly. The real difference is that it costs hundreds of $k to compile the final package in silicon. ;-)

Re:Convergence is happening

[0123456]

The real difference is that it costs hundreds of $k to compile the final package in silicon. ;-)

Only hundreds of thousands? From what I remember, our masks alone used to cost $1,000,000+, and a 'cheap' metal layer fix for a chip bug was about $50,000.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Give it up already

[ArchieBunker]

Is the lack of documentation hampering your development? You wouldn't have much of this high end technology if had companies not sunk development money into it and licensing to recoup their costs.

Re:Give it up already

[Anonymous Coward]

Oh quit whining! If you expect me to give a shit about those poor little companies who are only trying to recoup their cost by bilking their uses and hiding their specs? Fuck you, asshole.

Re:Give it up already

[Joining Yet Again]

Progress happens despite the excesses of capitalism, not because of them.

Companies would also be more profitable with slaves, but they don't stop producing when slavery is outlawed. It's up to the society that protects these profiteers' property to regulate them as it judges best.

Re:Give it up already

[Anonymous Coward]

And these companies wouldn't have any money or even exist without customers, so using your line of justification, we get to do what we want and they should be thankful.

Re:Give it up already

[Anonymous Coward]

^This. After slavery was outlawed, plantation owners came up with sharecropping.

Hardware is essential

[Murdoch5]

Without having a good understanding of hardware development you can not be a good Desktop or Embedded level developer.

Re:Hardware is essential

[artor3]

I strongly disagree with that notion. It's important for developers to understand how the hardware is architected in some cases, but that's not the same as having an understanding of hardware design. The developers don't need to know about coupling or latch-up or impedance matching. If they do, that's a sign that the hardware engineers did something very, very wrong.

Re:Hardware is essential

[Anonymous Coward]

I have noticed in my own thinking that sometimes understanding too much of "how hardware does this thing" prevents me from designing a good software interfaces...

Of course, when things have gone south, the most valuable asset is a guy who can debug the whole chain (C, VHDL, HW) while dancing and making you a cup of coffee at the same time.

Re:Hardware is essential

[Murdoch5]

I would venture that if you ask any modern computer science student about things like, CPU / MPU state, I/O load, Pipeline state, Memory allocation at the byte level, CPU / MPU interruption and more, they couldn't answer you. All of these and more need to be actively in your head well you code. It doesn't matter if you are writing a music player like iTunes of an Embedded Firmware, you need to approach the problem from the bare metal up.

I have a friend taking a Software Engineering degree right now and when I look at his code I shutter. Well his code is pretty and utilizes managed run-times and style, it's generally a resource disaster and he's admitted to me they don't even have a course on resource management. He can't tell me how many bytes of memory his program will use, how to optimize the pipeline for better run-time, how to save I/O loading through DMA requests and etc... Basically he can't answer any of the questions that determine if his program will actually be optimized or just a standard sluggish, not responding windows program.

If he had a good understanding of hardware and thought more like an embedded developer he would be able to answer questions like this and instead of using X resources he would able to put a number down and measure aspects like run-time performance, register allocation, DMA access and more. It's not just him, his entire class is like this and from what I know about the profs it's not going to get better anytime soon.

Desktop programmers need to understand hardware in order to become good programmers because all the modern concepts of software development don't mean jack if you can't at the end of the day express the state of the system you're work on.

Re:Hardware is essential

[Anonymous Coward]

Desktop programmers need to understand hardware in order to become good programmers because all the modern concepts of software development don't mean jack if you can't at the end of the day express the state of the system you're work on.

While I believe your argument holds merit today with regard to embedded systems like mobile phones, you're way off base on desktop apps. It's still cheaper to throw more hardware at the problem than it is to spend a bazillion man hours optimizing for a percent here, and a percent there of increase. The most important aspect is to lean on reliable well-trusted libraries (e.g. STL) and know what data structure to use where.

The days of talking to the blitter from the Amiga's 68k in assembly (and the spiritual ancestors that followed) at the assembly level are gone for most of us.

Re:Hardware is essential

[Anonymous Coward]

Please explain how new programmers today can use concepts like register allocation and DMA access when their tools (programming languages) don't even expose these. Even C compilers nowadays ignore the register keyword...

Re:Hardware is essential

[jones_supa]

I have a friend taking a Software Engineering degree right now and when I look at his code I shutter. Well his code is pretty and utilizes managed run-times and style, it's generally a resource disaster and he's admitted to me they don't even have a course on resource management. He can't tell me how many bytes of memory his program will use, how to optimize the pipeline for better run-time, how to save I/O loading through DMA requests and etc...

But how would he even know that stuff? The issues you are describing are very platform-specific and deep down to hardware. They should be mostly the problem of the compiler and operating system.

I agree though that you have to know what happens under the hood to be a good programmer. That could mean, for example: knowing a bit about executable formats, how a CPU works (registers, program counter, flags...), what kind of init code does the compiler insert, how are stack and heap organized, and how to use a debugger.

Re:Hardware is essential

[Murdoch5]

Software Engineering courses need to be updated to include hardware based design and understanding courses. Like you clearly pointed out, you need to understand what goes on under the hood to be a good programmer.

Re:Hardware is essential

[sydneyfong]

All of these and more need to be actively in your head well you code.

These are all distractions for the things that matter.

He can't tell me how many bytes of memory his program will use

Cross compile to 64 bits and the answer will be different. Use a different C++ compiler and the answer might be different. Compile for a different OS and the answer might be different (some structs have different sizes on different platforms).

how to optimize the pipeline for better run-time

This should be done by the compiler. Besides, are you assuming an x86 CPU? You *do* know software these days are expected to be portable across CPUs, right?

how to save I/O loading through DMA requests

WTF? Are you still programming in DOS? How do you enforce DMA enabled I/O without hacking into the kernel under a modern OS?

can't answer any of the questions that determine if his program will actually be optimized or just a standard sluggish, not responding windows program

Slow windows programs are poorly coded in many more ways that the ones you mentioned.

If he had a good understanding of hardware and thought more like an embedded developer

If he thought more like an embedded developer he'd be an embedded developer.

he would be able to answer questions like this and instead of using X resources he would able to put a number down and measure aspects like run-time performance, register allocation, DMA access and more

It's not unreasonable for code these days to run on at least ARM, ARM64, x86 and x86-64. Maybe you actually do remember the number of registers that each architecture has, and understand all the optimizations that every compiler uses for reducing registers used, AND you #ifdef your code for each of these cases to optimize the performance.

Or, you're just 20 years out of date regarding industry practice in software development. Apparently, willfully so.

Desktop programmers need to understand hardware in order to become good programmers because all the modern concepts of software development don't mean jack if you can't at the end of the day express the state of the system you're work on.

Embedded programmers need to understand electronics in order to become good programmers because all the modern concepts of programming don't mean jack if you can't at the end of the day express the state of the system you're working on.

Electronic engineers need to understand quantum physics in order to become good engineers because all the modern concepts of electronics don't mean jack if you can't at the end of the day express the quantum state of the system you're working on.

Do you understand the quantum-physical state of the machines you're working on? What makes the computer-hardware level so important for programming, besides the fact that you're apparently obsessed with it yourself?

Re:Hardware is essential

[Murdoch5]

If you're going to port your code to multiple architectures then you need to understand the architectures and all the in's / out's that make them run. if you're going to program in C++, C#, C, ASM, Matlab, COBOL and etc... you need to understand how they use memory and the size of different aspect of the language. You should never just fall back and let the OS run your code without thinking how it's going to run your code and how your code will interact with your hardware. You can always tell when a programmer has no concept of hardware because the code will reflect bad design and bad resource allocation, on the same regard you can always tell a truly great programmer because the code will reflect the hardware on which it runs. If desktop programmers thought more like embedded developers we would see much better code and much better end products.

On side a note you should always have access to your DMA controller, and if you need to hack open the kernel to get access then stop using that operating system. If you can get in and control a DMA controller manually for your program you can optimize the hell out memory and I/O access and take your program from a fast program to a truly blazing program.

Re:Hardware is essential

[sydneyfong]

You should never just fall back and let the OS run your code without thinking how it's going to run your code and how your code will interact with your hardware

Look, when I write Javascript, the most I would do is to look at how the 4 major browsers execute the code. I don't think about what the OS would do. Heck, given the ever evolving state of Javascript engines these days, I don't even know what the browser actually does. Does that make 99.99% web developers out there bad programmers?

When I write Java, it could end up running on Windows, Linux, MacOS, or Android, even on other platforms. The heavily optimized JVM handles the hardware/OS level optimizations for me, why should I bother?

Even when I write C, the code is supposed to be portable across different platforms and architectures -- even ones that have not been invented yet.

Linux itself supports dozens of CPU architectures. A proper linux program should be able to run on all of them. Do you understand what the hardware does on all of these architectures? Even if you think you do, you're just guessing.

The hardware level is just the wrong level of abstraction in programming. It's been the case for a LONG time. Just take your blazing fast DOS program and keep it.

Re:Hardware is essential

[Murdoch5]

Well first of all I said desktop programming and not web programming, Java Script would be classified as a web language and not a desktop language. Secondly Java is a horrible concept, it's entire basis is to create a virtual machine you run on instead of sitting right on the OS, well I can agree it's a wide spread and commonly used language I still hate it, Lastly you can have what every belief you want but I don't agree, if someone if going to take my C code and move it to a Blackfin arch then so be it but just don't come ask me for help when it doesn't work, you keep talking about DOS but that almost proves my point that hardware has taken a back seat and it shouldn't, if you don't understand hardware then how are you going to write a driver or a serial data logging interface? How are you going to be able to port between x86 and a Coldfire DSP? If it works by the sheer luck of the FSM then so be it but in general it won't, you need to know hardware to be a good programmer and a good developer should be just at home writing a RTOS as writing as a C# desktop app.

Re:Hardware is essential

[Anonymous Coward]

Electronic engineers need to understand quantum physics in order to become good engineers because all the modern concepts of electronics don't mean jack if you can't at the end of the day express the quantum state of the system you're working on.

Uh, no.

I am an EE, I design SoCs. I don't know much about quantum physics, maybe the solid state physicist who designs the device package for the lithographic process I'm using does, but I just use the device models that my fab gives me. While quantum physics explains why transistors work, how the devices behave can be understood entirely by statistical models and design rules.

I'm not even sure what "quantum state of the system" means, what I'm concerned about is whether there will be sufficient voltage on the gate by the next clock transition to make my timing model close, and how much I'm dissipating to make my thermal model close.

Re:Hardware is essential

[sydneyfong]

Exactly my point. The people designing a language, the OS and the compiler should know something about the hardware, but the programmer only needs to know what the API guarantees.

Woah...

[Anonymous Coward]

Don't do an image search for Quinn Dunki Nude. You won't get what you expect.

Not Equal To

[Anonymous Coward]

I am an analog designer, and I don't even understand completely how to implement 1Ghz+ speed designs because all of the stuff I design is low frequency instrumentation. I have wire-wrapped an 8088 and programmed it in assembly and was the last microprocessor class at my university to do so. Now they add stuff to a microprocessor board which teaches you much less (but also takes less time than the 20+ hours per a week to wirewrap). I would recommend the experience to anybody with a computing background. It will teach you the fundamentals of computing. I would also encourage all software developers to also understanding how to program assembly. I've done a lot of different things in a lot of different areas (FPGA's, DSP, uProcs and analog design) , and there are so many gotchas along the way with any one of these areas, even by reading books and books to gain some working knowledge it still takes years of implementation to become proficient. I thought I was good at FPGA's until a senior engineer tore apart my design. One problem I have with software engineers is the "I can fix it anytime" mentality. Revisioning a board takes days at the least and costs 100's of dollars, it is not like pressing the run button in a software simulator. If your going to do a project, plan it out and then do it, don't fiddle with the software or hardware until it works.

Even more than one thinks

[chthon]

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.

A modern drawback

[bjs555]

I love hardware. Built a 6800 machine on solderless breadboards quite a few years back. Kind of a dumb thing to do durability wise, but it was quick and easy. That brings me to my point. Many new devices these days are only available as surface mount devices. Have you ever tried to solder one of those bad boys into a circuit? The Arduino and its ilk are great but shields and stuff are basically pre-built and component level design is becoming a lost art. Well, I suppose you could say that the advent of ICs turned discrete transistor design into a dying art to an extent. Of course, things that can be done today are magical compared to 20 years ago. Ch-ch-ch-changes.

Does anyone know of an inexpensive and easy way to work with surface mount devices? Prototyping SMT boards are available from Schmartboard and others but they sure aren't inexpensive.

Re:A modern drawback

[terryk29]

Re. Schmartboard adapters, here's a 0.5 mm pitch QFP to 0.1" adapter. It's 10 bucks. OK, a BGA one is $45. But still, what are you looking at that you don't find inexpensive enough? What family of devices are you wanting to work with?

Aside from hacking some existing proto- or dev-board with the device you want to work with (e.g. with short patch cables or headers to a breadboard or other daughter proto-boards), you should consider just biting the bullet and learning to design and solder your own SMT PCB's.

Sure, you may not have a completely tested and threshed-out design on a rats-nested breadboard to work from, but OTOH designing and having fabbed simpler double-layer (or even 4-layer) moderate-speed boards is now very accessible*. Part of it is accepting that for projects you're serious about (or, of course, stuff that's "work"), the first board may not be final, so go ahead and make one that gets you up and running with an initial design (which you have the experience to be confident in) but for which you may still be patching interfaces to, etc. If you know it's not final, you can save a bit of money by skipping the silkscreen and soldermask.

*Depending on what you're doing, you will have to become acquainted with proper layout techniques re. EMI/noise to some degree.

Hardware is just petrified software.

[crovira]

I fail to see the difficulty, or the divide, since hardware is a question of petrifying some software to enhance the operation of certain algorithms.

I remember reading articles several years ago by Chuck Moore about what he was doing to control a silicon foundry to produce chips which would hard wire some algorithms in silicon while leaving the rest as software implementations in Forth.

TILs (Threaded Interpreted Languages) lend themselves very well to this.

The level of interpretation, and the repetition of interpiling, depends on what you define and cache as interpreted code. That is only one step away from petrifying it in silicon.

Re:Hardware is just petrified software.

[hamster_nz]

Not quite - hardware is only good at petrifying O(1) algorithms. They have to be tightly bounded in space and time.

Go the FPGA way.

[hamster_nz]

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.