Slashdot Mirror

← Back to Stories (view on slashdot.org)

Crossing the Divide From Software Dev To Hardware Dev

Posted by timothy on from the switch-hitting-by-hitting-switches dept.

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

68 of 105 comments (clear)

  1. That article was fucking awful. by Joining+Yet+Again · · Score: 1, Insightful

    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.

    1. Re:That article was fucking awful. by Anonymous Coward · · Score: 1

      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.

    2. Re:That article was fucking awful. by Joining+Yet+Again · · Score: 4, Interesting

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

    3. Re:That article was fucking awful. by Miamicanes · · Score: 2

      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.

    4. Re:That article was fucking awful. by ArbitraryName · · Score: 4, Informative

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

    5. Re:That article was fucking awful. by ArbitraryName · · Score: 2

      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?

    6. Re:That article was fucking awful. by sjames · · Score: 1

      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.

    7. Re:That article was fucking awful. by lisaparratt · · Score: 1

      Apparently someone can't operate Google Images.

    8. Re: That article was fucking awful. by jones_supa · · Score: 1

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

    9. Re:That article was fucking awful. by gl4ss · · Score: 1

      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/

      --
      world was created 5 seconds before this post as it is.
    10. Re:That article was fucking awful. by TechyImmigrant · · Score: 1

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

      So design it properly. FFS.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    11. Re: That article was fucking awful. by TechyImmigrant · · Score: 1

      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.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    12. Re:That article was fucking awful. by zwarte+piet · · Score: 1

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

    13. Re:That article was fucking awful. by sjames · · Score: 1

      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.

    14. Re:That article was fucking awful. by Miamicanes · · Score: 2

      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.

    15. Re:That article was fucking awful. by mikael · · Score: 1

      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.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    16. Re:That article was fucking awful. by TechyImmigrant · · Score: 1

      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.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    17. Re:That article was fucking awful. by sjames · · Score: 1

      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.

    18. Re:That article was fucking awful. by zwarte+piet · · Score: 1

      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.

  2. Everything is easier today! by mveloso · · Score: 1

    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.

    1. Re:Everything is easier today! by Zero__Kelvin · · Score: 4, Informative

      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.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    2. Re:Everything is easier today! by queazocotal · · Score: 4, Informative

      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.

    3. Re:Everything is easier today! by ArbitraryName · · Score: 1

      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.

    4. Re:Everything is easier today! by flimflammer · · Score: 1

      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.

    5. Re:Everything is easier today! by sydneyfong · · Score: 1

      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)

      --
      Don't quote me on this.
    6. Re:Everything is easier today! by xtal · · Score: 1

      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?

      --
      ..don't panic
    7. Re:Everything is easier today! by zwarte+piet · · Score: 1

      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.

    8. Re:Everything is easier today! by zwarte+piet · · Score: 1

      Wirewrapping and blinkenlichten. Sounds like fun. :)

    9. Re:Everything is easier today! by Zero__Kelvin · · Score: 1

      Can you read?

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    10. Re:Everything is easier today! by Zero__Kelvin · · Score: 1

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

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    11. Re:Everything is easier today! by Mr.CRC · · Score: 1

      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.

  3. Run! by sycodon · · Score: 3, Insightful

    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.
    1. Re:Run! by GiganticLyingMouth · · Score: 1

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

    2. Re:Run! by fliptout · · Score: 1

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

      --
      A witty saying proves you are wittier than the next guy.
    3. Re:Run! by slew · · Score: 1

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

    4. Re:Run! by gl4ss · · Score: 1

      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.

      --
      world was created 5 seconds before this post as it is.
    5. Re:Run! by leaen · · Score: 2

      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?

    6. Re:Run! by AmiMoJo · · Score: 2

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  4. Not that simple by wiredlogic · · Score: 1

    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.

    --
    I am becoming gerund, destroyer of verbs.
    1. Re:Not that simple by Hans+Lehmann · · Score: 1

      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.

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
  5. There is no divide by Anonymous Coward · · Score: 1

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

  6. Re:buy a Pi by ebno-10db · · Score: 1

    What type of transistor?

  7. Convergence is happening by FishOuttaWater · · Score: 1

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

    1. Re:Convergence is happening by 0123456 · · Score: 1

      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.

  8. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  9. Re:buy a Pi by Anonymous Coward · · Score: 2, Funny

    > What type of transistor?

    P=NP

  10. Re:buy a Pi by ebno-10db · · Score: 1

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

  11. Hardware is essential by Murdoch5 · · Score: 2

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

    1. Re:Hardware is essential by artor3 · · Score: 2

      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.

    2. Re:Hardware is essential by Murdoch5 · · Score: 2

      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.

    3. Re:Hardware is essential by jones_supa · · Score: 1

      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.

    4. Re:Hardware is essential by Murdoch5 · · Score: 1

      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.

    5. Re:Hardware is essential by sydneyfong · · Score: 1

      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?

      --
      Don't quote me on this.
    6. Re:Hardware is essential by Murdoch5 · · Score: 1

      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.

    7. Re:Hardware is essential by sydneyfong · · Score: 1

      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.

      --
      Don't quote me on this.
    8. Re:Hardware is essential by Murdoch5 · · Score: 1

      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.

    9. Re:Hardware is essential by sydneyfong · · Score: 1

      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.

      --
      Don't quote me on this.
  12. Re:buy a Pi by sjames · · Score: 2

    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.

  13. Re:Give it up already by Anonymous Coward · · Score: 1

    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.

  14. Re:buy a Pi by gl4ss · · Score: 1

    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.

    --
    world was created 5 seconds before this post as it is.
  15. Even more than one thinks by chthon · · Score: 2

    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.

  16. A modern drawback by bjs555 · · Score: 1

    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.

    1. Re:A modern drawback by terryk29 · · Score: 1

      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.

  17. Re:Give it up already by Joining+Yet+Again · · Score: 1

    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.

  18. Hardware is just petrified software. by crovira · · Score: 1

    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.

    --
    MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
    1. Re:Hardware is just petrified software. by hamster_nz · · Score: 2

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

  19. Re:buy a Pi by TechyImmigrant · · Score: 1

    Bravo!

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  20. Go the FPGA way. by hamster_nz · · Score: 2

    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.