Controlling the Uncontrolled

A nice coincidence. Recently, I wrote a bit about choosing a microcontroller and some issues that crop up when people not used to microcontroller design are tasked with automating systems.

My supposition is that, traditionally, most folks in the industry concentrate on designing and choosing microcontrollers and tool sets from the perspective of an expert in embedded design. However, the new world has a lot of people tasked with microcontroller hardware and software design that are not electronics or software engineers. Mechanical engineers are tasked with integrating electronic controls into their systems. Pure digital engineers are being tasked with adding analog sections into their designs. Hardware engineers are having to learn microcontroller firmware programming. That changes the ground rules.

Last week, I signed into a virtual conference on motor control (I started writing this post as I was listening to the virtual conference, but didn’t get around to finishing it until today). I signed in late to start listening to the keynote address by John Hanks of National Instruments, who, at that moment, discussing this very subject. As he described it, domain experts in such fields as solar, wind and other areas are being asked to add additional automation into those systems. As domain experts, they may know more about their field than an EE or SE, but they likely have not been trained in the application of hardware, firmware and software development.

Interestingly, this group has a lot in common with the electronics hobbyist community. In both cases, the concepts and the tools are frequently quite new to them. In both cases, the budget for training and tools is frequently pretty minimal. In both cases, we have smart people who many not be trained in our field.

Those of us that create tools and offer services in this industry need to keep this trend in mind if we want to fully serve the new engineering audience.

Duane Benson
See us at ESC, booth 827

http://blog.screamingcircuits.com/

mbed Development – USB Programming Forever

I’m still fiddling with my mbed. Although, I haven’t put it to real use yet. I’ve got some ideas, but I just don’t have the time these days. One of the nice things about its programming system is that if I do have to step away for a while, it’s easy enough that I don’t have to go through any kind of learning curve again. The plug-and-go USB programming and online IDE is that easy.

Contrast that to one of my little PIC based boards. I recently wanted to do something with one that I hadn’t used for a while. I dug it up and pulled out my programmer. I somehow ended up with two different versions of the programmer software installed on my computer, and I had to try both. My programmer uses the FTDI USB/serial chip, so I had to try and guess which COM port to set my programmer software too.

Six permutations later, I had that figured out. I then loaded up an old known-working hex file and took my best guess at what the fuse settings needed to be and guessed wrong. Tried again and guessed wrong. Tried a dozen different combination and gave up and dug up the PDF of the data sheet. Once I found the setting and translated them to the language used in my programmer’s software, I finally figured it out and got it all working.

Granted, if I were using this every day, I wouldn’t have forgotten all those silly little details, but think about someone learning for the first time. Or, consider a hardware engineer that rarely uses microcontrollers. Once a year or so, some design does need a controller and some programming. I’m a big fan of PICs, but the programming system for many of them seems pretty archaic compared to a product like the mbed.

Duane Benson
I need gravy for the mashed potatoes in yesterday’s post

http://blog.screamingcircuits.com/