Blog Post Actions
Group Actions
Engagement
  • Author Author: DaveYoung
  • Date Created: Date Created
  • Views 261 views
  • Likes 4 likes
  • Comments 4 comments
Related
Recommended

Op Ed: A Microcontroller Course for Everyone!

DaveYoung

image If you've been in electronics for any time at all, it is easy to see a pattern develop between hardware and firmware/software engineers.  As soon as a problem crops up, it is instantly clear to the hardware team that it is the code that needs fixing.  However when asking the software engineers, they confidently state that the hardware is at fault.   When pressed for details, both sides will end up saying something like, “Well, I don't know what is wrong, but I know it can't be related to my part of the design because of _______.”

 

How is it that these assumptions are being made time and time again about the source of the problem coming from the other side?  Much of it probably stems from human nature's inclination to toss any problem over the wall and hope someone else fixes it.  This is likely strengthened by an engineer's confidence in a design they have spent untold hours creating.  But another source is likely rooted in a lack of understanding how the other side of hardware/software works.

 

How can we prevent this unproductive riff raff?  It might help to have anyone involved in electronics (either the hardware or software side) take at least one course in microcontroller design to show the connections (and problems) that occur between hardware and software.   Any piece of circuitry will eventually need to be controlled or communicate with software, and software usually involves the real world at some point.  The most remarkable A/D circuit is useless if the communication bus that the digital signal must pass over does not have the required bandwidth.  Similarly, a beautiful chunk of code written to control an RGB LED matrix won't work if the hardware isn't designed to supply the required amount of power.  A course that forces the engineer to face problems on both sides can be humbling; for example a hardware engineer might spend hours troubleshooting his or her code only to find that the motor was connected to the wrong power rail.

 

An example of such a course, ECE4760, taught by Prof. Batten at Cornell University is now available on YouTube and offers a wealth of information that would greatly help anyone designing in the Electrical Engineering space.  It could be replicated at home thanks to the $10 MSP430 Launchpad and the free development tools.  And while an outside observer won't be able to benefit from in-person instruction, they will be able to easily engage the communities like Element14's MSP430 group or TI's E2E forum.  The best part is that the course is project based, giving students an opportunity to learn the difference between 'This should work' and 'This does work.'

 

Of course this is just one suggestion to give each side a glimpse of the other.  After 5 years in the field any lessons of humility will be mostly forgotten.  Have you noticed the “it's their problem” exchange before?  What do you think would help with it?  Please share your thoughts in the comments.  In the end, we're all on the same team!

  • in reply to DAB

    DAB, blaming someone else for the fault/feature is almost as good as fixing it image

  • in reply to DAB

    Thanks for the story, DAB.  I'm sure that's just one of many from your career.  It seems to be another lesson in words being relative: 'Fixed' to them is very different from 'fixed' to you.

  • Hi Dave,

     

    I completely agree.  As soon as you begin to learn about an MCU you will find that you need to do your homework on both the software (SW) AND the hardware (HW).

     

    Back in the 1970's we used to have great screaming matches over deciding if the HW or the SW was at fault.  Most of it was just good clean fun, though it scared the hell out of management.  Both sides lacked the proper tools to locate and resolve a lot of the problems we encountered.

    Remember these are days before good logic analyzers were available.

     

    My best story is about a system I programmed and was due to go through acceptance testing while I was on vacation.

    When I returned there were half a dozen people outside my office screaming that the ATP failed because of my software.  So I asked the question "It worked fine when I left, what did you do to the system?"  The reply was "Nothing, we just fixed the Hardware!"

    It turned out that their "Nothing" made the test signals incredibly stable, which forced the device under test to miss the discrete signal changes.  I had build the DUT with noice detection software filtering that looked for consistent signal changes and ignored single level changes.  It worked fine in the field as the noise from all the other electronics kept toggling the values to the point where it would detect the changes and position the equipment.

     

    The end of the story was that I had to add software to the test unit to simulate signal noise so that the DUT would work normally.

    So much for fixing the hardware.

     

    It was experiences like these that encouraged me to get my BS in Computer Engineering.  At the time, it was the only degree field that enabled you to get both HW and SW exposure so that you could successfully interface machines together.

     

    So I encourage anyone new to MCU devices to get the training in both as you will find the rest of your life trying to resolve where the problem really is caused and wheather you can fix it with a few compontents or some software changes.

     

    As the Chinese say "May you live in interesting times!"  I believe this was a curse, but then I don't speak Chinese. image

     

    So I am glad that they are training people to appreciate the interface issues.  With devices like the PSOC, the lines between HW and SW are getting even more blurred.   Or is it just my vision?  Oh well.

     

    Good Post,

    DAB