ELECTRONIC HARDWARE DESIGN

  • Modern hardware design must include software and programmable logic development.

  • It’s frequently essential to develop hardware and firmware simultaneously, since the needs of one may set the requirements of the other.

  • The line between digital and analog design has become fuzzy; successful product development incorporates both.

 

Successful product development capitalizes on the critical role of electronic hardware in manufacture, distribution and the consumer experience. Quality engineering is similarly comprehensive: it maximizes investment in software development, manufacturability, programming, and the consumer experience. Integrated product development is critical to short-term product cycles and long-term profitability.

Focus Embedded specializes in this type of global perspective. Our engineers don’t work in silos; they design within a much broader context. We dive into the minutiae of circuit design while developing customer-specific teams that take a “family doctor” perspective — we recognize the singularity of each patient and the context in which he lives. 

Both analog and digital circuit design are just part of the equation. A modern system may include a programmed microcontroller or microprocessor, a field programmable gate array (FPGA) coded in Verilog or VHDL, software in C/C++, Java, Python, assembly language, or any of a dozen other popular languages. Electronic systems design may also encompass PCB layout, since the copper and fiberglass of a printed circuit board can be a part of the circuit itself at extreme frequencies or low signal levels. With a comprehensive understanding of what’s possible, creativity has the greatest potential to improve ROI.

CHIP DESIGN

  • Economies of scale and manufacturability can guide technology development and selection.

  • Building a single custom chip can have significant cost and reliability advantages over building a circuit board full of non-custom chips.

  • Custom chips discourage intellectual property theft, particularly if they’re locked with a suitably long encryption key.

 

Some projects don’t require a complex printed circuit board (PCB) — much of the complexity could be contained within a single chip, which can offer significant advantages. An engineering approach that recognizes the costs and opportunities of both chip and PCB design enables you to maximize efficiency and profitability throughout development, manufacturing and consumer cycles. We’ll look carefully at every aspect of the project, and can design a chip (FPGA, CPLD, or SoC) or lay out a PCB — whatever gets you from drawing board to the sales cycle with the highest potential ROI.

Integrating discrete circuits in a single chip:

  • Increases economies of scale. Designing a single FPGA, CPLD, or SoC instead of building a PCB can significantly decrease manufacturing and assembly costs, especially over long runs.

  • Decreases the incidence of field failure — which increases consumer satisfaction — the result of fewer parts and fewer solder joints.

  • Decreases product size and power consumption, the result of fewer chips and attendant parts.

  • Decreases the risk of intellectual property theft, regardless of where your products are manufactured. You may find the best prices for circuit board assembly in China, where IP theft is rampant. But it’s possible to program (and crypto-lock) a chip in the United States such that the key piece of the design can’t be stolen and nobody can create a “knock-off” version of your product.

  • Increases the likelihood of passing FCC compliance testing for unintentional radiators.

Focus Embedded designs with FPGA/CPLD chips from Xilinx, Lattice Semiconductor, and Intel (Altera). We develop our hardware descriptions in highly portable Verilog and VHDL hardware description languages. We provide the greatest number of options for porting designs to other chip platforms to ensure that, as products are enhanced and redeveloped, our clients aren’t restricted by either parts availability or price.

Focus Embedded is also a Lattice Semiconductor “LEADER” design partner and a factory-approved engineering design services provider under the Cypress/Infineon Design Partner Program.

Whether you need FPGA/CPLD development in VHDL/Verilog, Cypress PSoC design, an ASIC, or just general electronic product design and development, let’s see if there’s a way we can streamline everything — from your glue logic to the brains of your PWM motor control system to the bridge logic in your switching power supply design to your image acquisition engine — in a single chip.

BOARD SUPPORT PACKAGE DEVELOPMENT

  • Applications developers don't interact with your hardware — they interact with the software API's that live below the app.

  • A good BSP for mediocre hardware will usually get more market traction than a poor BSP for excellent hardware.

  • With an unstable BSP, you'll spend time and money chasing problems at the applications level.

  • If your customer is the applications developer, he'll remember your bad BSP and avoid it.

 

Board support package (BSP) development is where the rubber meets the road and the silicon meets the code. Build an optimized BSP and you open a highway for applications development. Build your BSP poorly, and all you’ll do is create traffic jams.

Without well done low-level firmware development:

  • A new peripheral device may fail to work properly.

  • A seemingly benign change to an operating system can cause an entire system to stop working.

  • Application code debug and kernel aware debug become difficult or even impossible.

  • Application code can be forced to peek and poke down through a hardware abstraction layer (HAL), inviting problems with task scheduling, resource management, memory allocation and cleanup.

Good BSP design requires good device driver design. The first step is understanding the requirements of the operating system (which may bind parts of the BSP as OS kernel calls). BSP development must also include an understanding of the kinds of applications that might eventually make calls into the firmware drivers. The quality (and utility) of a BSP can hinge on the degree to which low-level bit-manipulation functions are abstracted away from any API above them. That way, application developers don’t need to worry about how something like a mapping application for an iPhone gets GPS coordinates or an embedded Linux board talks to a motor controller or position sensor.

Our Approach

At Focus Embedded we’ve done BSP’s for a wide variety of target boards, including those with the following processors:

  • ARM and ARM-Cortex variants

  • SHARC, Blackfin, ADSP-2100 and ADSP21000 DSP’s

  • TMS320 DSP variants

  • 8051 Microcontroller

  • x86, including embedded variants

  • PowerPC

  • Motorola/Freescale Coldfire

  • Freescale Kinetis

  • Freescale QorIQ

  • TI OMAP and Sitara processors, especially as used in BeagleBoard and BeagleBone variants

  • Microchip PIC and dsPIC

  • TMS320

  • Cypress M8 core / FX and FX2 USB endpoint controllers

  • Cypress PSoC (ARM-Cortex M variants, usually, although occasionally M8 or 8051 on older parts)

  • Intel 80C196

  • TI MSP430

We write in primarily C or assembly language, the two most popular for low-level bit manipulation.  (That said, we’ve done designs in C++ and Python when customers asked.) We’re familiar with processors that carry legacy features, such as odd paging schemes or segmented addressing, as well as real and protected modes. We also do power management device driver support for mobile devices.

We use both the software and hardware sides of the brain, so we can switch gears as needed. As FPGA designers, we’ve done cross-development with FPGA’s as memory-mapped peripherals connected to host processors and defined FPGA registers in “include” files, improving sync with similar header files on the software driver side. The result, even when we’re not doing the hardware design, is a much better BSP.

Because we maintain a team with a wide variety of expertise, we can quickly decipher an existing hardware design and develop a solution — we aren’t pausing to consult with outside expertise. Often, it’s our FPGA experience that enables us to make suggestions about what to incorporate on either side of the FPGA-driver interface, resulting in a better BSP and better HDL source code.

And sometimes we’re putting a soft core (or exploiting a hard core) processor in an FPGA.

We’re always up for joint development with your hardware team.

Take a look at our project portfolio and let’s talk about how we can accelerate your hardware and application code development.

SOFTWARE/FIRMWARE DESIGN

  • Applications developers are rarely embedded developers. Understanding how to build application software doesn’t translate into writing the driver that gets the most out of your hardware.

  • Determining which parts of your code are time critical is something that should be done at the outset of the development cycle.

  • A good user interface can be misleading. Code can look “almost done” when, in reality, there’s nothing under the hood.

  • When applications code is completed before the drivers or BSP are defined, that code may have made so many assumptions about what lies beneath as ultimately to be useless.

 

It’s easy to forget about embedded systems. But there are myriad interfaces we engage to control physical microprocessors and microcontrollers. And as with hitting the brakes or turning the steering wheel, each keystroke cam correspond to a real-world effect in the embedded space below the application programming interface (API) and the operating system.

The utility and the lifespan of every electronic product is directly related to how well these invisible programs are written, and how well program developers understand the physical characteristics — both the opportunities and the limitations — inherent in the underlying control systems that make everything function. The subtleties of real time deadlines and the particular timing requirements of control systems can make your electronic products impressively responsive or sluggish and frustrating. It’s all in the embedded system.

The 90% Under the Hood

It’s easy to focus on the user interface. It’s what we see; it’s the elegant exterior. But a beautiful car that doesn’t run is nothing more than a fiberglass sculpture.

The more critical the response, the more thoroughly we must understand how a simple set of operations — in both code and silicon — translates into definable, measurable processes. Without that understanding, your steering wheel might fail to turn the tires and your brakes may take just a second too long to engage. And the undesirable real-world effects of poorly built, time-critical algorithms can equal or exceed a car wreck.

We do quite a few rescue operations on projects where the menus and screens work exceedingly well, but the instrument below the user interface doesn’t work at all. We can create an effective software development kit (SDK) for new or existing hardware that can minimize or eliminate the need to redevelop the product or its components.

Before you go back to the drawing board, give us the opportunity to determine if you should. The fix may simply be a matter of focusing on optimally-written embedded software.

An Application, By Itself, Has No Application

An applications developer can provide a very good mockup of a system to present to potential investors. But application software lives on a different plane from the embedded software that makes your finished product operational. Without a defined interface and a well-written board support package (BSP), your application won’t run efficiently. (It may never run at all.) 

We’re experts at getting projects back on track, but rescue operations mean that development money was wasted. That’s why we love the blank sheet: co-creating applications and embedded systems hardware/firmware maximizes your investment. 

We write application software. We develop hardware. We understand the space below the device driver as well as the API above it. When you’re designing a new car, you need a team that understands how the driver, the mechanic and the road work together to get you where you’re going. You need the kind of comprehensive focus that we offer at Focus Embedded.

INTEGRATED SYSTEM & PRODUCT DESIGN

  • Most failed projects were doomed on the first day, when somebody defined the problem incorrectly.

  • Black boxes are great, except when you miss a subtle point about what's in them.

  • The really hard problems are solved with old-school math first and newfangled technology second.

 

Successful new product design and development often depends as much on knowing what problem you’re solving as it does on how to implement the solution. You can be an outstanding software development company, control systems engineering consultant, FPGA developer, or embedded systems design service provider; but if you’re coming up with the wrong solution to a misunderstood challenge, all the technical skill on the planet isn’t going to stop you from designing something the market doesn’t want or that doesn’t even go together correctly when all the pieces are assembled.

On the flip side, beyond a certain point a high level “black box” approach that ignores the details of implementing a design at the deeply embedded systems level will result in many critical design criteria being ignored. And the result may also be a design where manufacturability hasn’t been considered at all, which can be a nail in an economic coffin when it finally comes time to make and sell your product.

Usually when we inherit an electrical engineering or embedded systems project that’s floundering and we have to put it back on track, it’s reached the point of trouble via one of three paths. Sometimes a “systems integrator” with limited experience looking into the internals of the systems he’s integrating has missed key points about how they’ll really play together. Sometimes somebody who may be familiar with the implementation of parts of a design at circuit level hasn’t seen the bigger picture as far as how they all go together. (This is the classic “blind men and the elephant scenario.) And sometimes somebody’s overlooked some critical detail of physics or mathematics that has less to do with the reduction of a concept to practice via the electronic circuits than it does with the algorithm or formula behind it all.

When you need your entire system to run properly and can’t afford to leave its proper functioning to chance, you owe it to yourself to find a product development consulting company like Focus Embedded. We can do the hard math up front, outline the major components of the system with the knowledge that comes with having spent time looking inside black boxes, and then finish the job with computer engineering, control systems engineering, instrumentation design, hardware design, software design, and overall embedded product design done right.

Getting things in Focus will get you from concept to reality.

HUMAN FACTORS DESIGN

  • Even in embedded design it's imperative that developers remember that there's a human user out there somewhere.

  • Functionality without usability renders a product functionally useless.

  • Good design is good from top to bottom, and the more the API between applications developer and embedded developer suits the needs of them both, the more likely the final product will be usable by real human beings.

 

 Are machines here to serve us, or have we humans already sold our souls to serve the machines? If you’ve ever gone through the agonies of trying to rebuild a crashed computer or recover an erased hard drive – or if you’re reading this as you sit in the waiting room of the local auto repair facility – right about now you may be wondering. Buried in that question of, “Who is the master and who is the slave?” is frequently a stinging indictment of the quality and usability of many of the world’s user interfaces.

In new product development, any proof of concept should take into account that at the very end of the trail blazed by all that new technology is the living, breathing human being who has to use it. We often think of ergonomics in the context of where the controls on our automotive instrument panel are placed or whether our driver’s seat comes with lumbar support and a heater under our backside. But the human design element turns up in a whole lot more places than a car interior, and human factors should be considered for much more than just medical equipment design or the development of biometric systems. Ultimately we all have a connectedness to the machinery at the very bottom of the technology food chain while we’re interacting with the user interface at the very top.

As developers of real time embedded systems, control systems, and electronic hardware; at first blush it might seem that we at Focus Embedded would be among the very last people interested in human factors design. After all, above the applications programming interface (API) lies all the software and user interface design that demands cognizance of how humans work. Below that API, embedded firmware and low-level hardware is only ever interacting directly with other hardware and software – not real people.

It’d thus be easy enough for us to shrug and say, “We don’t deal with end users, so we can just code to the API specs and punt the whole ‘user’ question onto somebody else.” And a lot of engineering consulting companies and product development service bureaus that work in the embedded space do precisely that.

The hard reality, however, is that this approach results in products that though they be functional have poor usability. You won’t build a cult following of dedicated users (except among extreme masochists) with user interfaces that fall significantly short of those designed by Apple. And that means that if you’re an embedded design consulting company (which Focus Embedded is), you’d better be aware that your customer may well be the human being assigned the job of using your low-level firmware or hardware in a way that’s pleasing to his customer, that human being who is the end consumer. Apple remembered this well when they built the board support package (BSP) and software development kit (SDK) for the iPhone, and the result is that they’re now leveraging the efforts of tens of thousands of applications developers worldwide who genuinely enjoy coding for Apple iPhone products.

Conversely, if you’re in the embedded development space and you’re making your API’s clunky and cumbersome for that person doing applications development, there’s an excellent chance that what he presents to the end customer is also going to be clumsy, inelegant, and unpopular. Much like the chef back in the kitchen, if you’re the embedded systems designer you may never see the guy in the dining room. Only the waiter may do that. But like as not, that diner is going to see you when the plate with his dinner is put on his table. Or to use a metaphor from home building, once the foundation is poured crooked, there’s a limit to what even the best framing carpenter can do as each floor of the house gets put on top of it to make the upper floors straight.

Indirectly what’s done in the embedded space touches everyone – and most of all touches the human being who ultimately uses the device and either recommends it to his friends or pans it publicly on any of the “rate this product” bulletin boards out there.

Don’t underestimate what happens below what you think you can see. Keep your humanity in Focus.