Software Design by Focus Embedded
 

Key Points

  • Applications developers are usually not embedded developers. What's taught to tbe computer science major is usually insufficient knowlege for interacting with hardware.
  • Determining which parts of your code are time critical is something you should do at the start of development.
  • Applications development efforts can get you a user interface long before you have underlying code that runs, but this is a mixed blessing.
  • With a good user interface, code can look "almost done" when in reality, it's maybe 10% done at best.
  • Get too much applications code done before your drivers or BSP are defined, and you may code yourself into a corner where your software will never work.

Software/Firmware Design

There are several different flavors of software development company out there, and it pays to know what you’re buying, particularly if in the end you need a real time embedded system. (Unfortunately many people don’t realize that this is what they need until it’s too late, so as a supplier of these skills, we at Focus Embedded spend as much time as we can educating potential customers, even if we know they’ll later choose some other new product design and development firm over our own.) Many is the software application developer who’s spent the bulk of his working life too far removed from the actual microprocessor or microcontroller that’s running his application code to be able dig down into the embedded space below the “application programming interface” (API) or his operating system (with all its available resources and system calls) and catch all of the subtleties that may go with hard real time deadlines or the highly particular timing requirements of control systems.
 
Frequently when someone not heavily schooled in advanced mathematics (such as Laplace Transform or Fourier Transform Theory, for example) approaches engineering software development, if there’s a component that requires development of time-critical algorithms, he overlooks it and places his emphasis on the development of a user interface. We therefore see many projects that come to us as “rescue operations” where the menus and screens work exceedingly well, but the instrument below that user interface doesn’t work at all. Thus our job is often to create the software development kit (SDK) for a piece of hardware that may not as yet have one. As experts in embedded systems design and control systems engineering, that’s our forte.
 
A product development customer, unless he’s quite technical himself, may lump together the upper layer application code and lower layer embedded code all under one heading of simply “software.” And although an applications developer can get you the kind of very good mockup of a system that’ll serve as a talking point for discussions with potential investors, sometimes that’s as far as he can take you. And without a defined interface to what may then be a non-existent hardware “board support package” (BSP), he may well code you into a corner. We’re experts at getting people and their projects back out of those tight spaces, but we’d rather meet the fellow who may need embedded systems firmware written before he discovers this fact the hard way on his own.
 
Mind you, we’re application software writers as well. So we know what applications developers are looking for if we’re not to be the writers working in “app space.” But we can swing both ways as needed. And as hardware developers, we’re aware of the space below the device driver as well as the API above it.
 
But it’s precisely this knowledge that makes us very specifically an embedded software development company.