Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Software Hardware

Crossing the Divide From Software Dev To Hardware Dev 105

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."
This discussion has been archived. No new comments can be posted.

Crossing the Divide From Software Dev To Hardware Dev

Comments Filter:
  • by Zero__Kelvin ( 151819 ) on Friday October 18, 2013 @08:06PM (#45171085) Homepage
    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.
  • by queazocotal ( 915608 ) on Friday October 18, 2013 @08:43PM (#45171275)

    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.

  • by ArbitraryName ( 3391191 ) on Friday October 18, 2013 @11:36PM (#45172229)
    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".

"Here's something to think about: How come you never see a headline like `Psychic Wins Lottery.'" -- Comedian Jay Leno

Working...