Embedded Software Development Services: What They Are (And How Not to Pick the Wrong Partner)
Technical Summary
For readers who want the short version before the long one — here is what this article covers and what we believe matters most.
What embedded software development services actually are. They are the design, writing, testing, and long-term maintenance of the software that runs directly on a microcontroller (MCU), system-on-chip (SoC), or FPGA — not on a desktop computer or in the cloud. The deliverables typically include firmware, drivers, any HDL code with complete testbenches, an RTOS or embedded Linux configuration, and the documentation needed to maintain all of it for years after launch.
The stack at a glance.
- Firmware — low level drivers, interrupt service routines, clock configuration management, watchdog handling, peripheral initialization, and the main control loop or scheduler if running on bare metal.
- RTOS or Embedded Linux — FreeRTOS, Zephyr, or ThreadX for tight deadlines and small footprints; embedded Linux for systems that need a full ecosystem of device drivers and protocol stacks.
- Drivers and protocol stacks — SPI, I2C, UART, USB, CAN, Ethernet, BLE, Wi-Fi, LoRa, cellular.
- Hardware/software co-design — pin assignment, clock planning, MCU selection, BOM and COGS estimates, PCB and assembly cost pre-planning.
- Testing and validation — simulation, “shake and bake” testing, EMC compliance, and verification artifacts that an auditor will accept. UL and CE compliance designed in from the start – often as a cooperative effort with the testing laboratories before trouble emerges.
The five-stage process. Requirements and discovery → architecture and technology selection → development → integration and testing → deployment and handover. The shape rarely changes; what changes is the duration of each stage and the depth of regulatory work involved. What also rarely changes is that work done up-front is handsomely rewarded on the back side.
What separates a good partner from an expensive one. Domain expertise in the relevant vertical (medical, aerospace, industrial, consumer, instrumentation), credible technical depth, a real portfolio of comparable successful products, open and disciplined communication, documentation that holds up under inspection, and clean IP definition before any code is written. Most failed engagements fail because one of these was skipped.
Bottom line. Embedded software is the foundation underneath the application. When it is solid, nobody notices. When it cracks, everybody does. Pick a partner who lives in this layer every day, not one who treats it as a side service.
The rest of the article unpacks each of these points in detail.
Your board just came back from the fab. It is beautiful. Your app team's UI is polished enough to demo to investors. Yet two weeks before launch, the firmware is crashing every six hours, the Bluetooth stack drops packets the moment anyone looks at his smart watch within twenty feet, and nobody can agree whether the bug lives in a driver, the RTOS configuration, or the MCU's power management.
Welcome to the place where many hardware products go to die.
It is also exactly where embedded software development services earn their keep. This piece is about what those services actually are, what a real engagement looks like, and how to separate a partner who will get you to product launch from one who will quietly burn six months of your runway. If you are already familiar with our competencies, consider this the long-form version. If you are new to all this, read on — it is the map we wish every founder had before his first hardware project.
The Foundation Nobody Sees (Until It Cracks)
Applications get all the attention. They are pretty. They are what the user sees. And if the app crashes, everyone knows whose fault it is.
Embedded software is the opposite. When it works, nobody notices. When it doesn't, you find out at the worst possible moment — usually in a customer's hands, often in front of a camera. It is the foundation. It is the wiring behind the drywall. It is the reason your product either feels like a premium device or feels like it came free in a cereal box.
Embedded software development services cover the design, writing, testing, and long-term care of the code that runs directly on your silicon — a microcontroller, an SoC, or an FPGA — rather than on somebody's laptop. That software reads sensors, drives motors, supervises radios, services interrupts in microseconds (or less), keeps watchdogs fed, and generally holds everything together when the battery is low, the temperature is wrong, or the user has done something you never imagined.
Put another way: the app usually gets the credit. The embedded layer frequently gets the blame. Which is why it is worth getting right.
Embedded Software Development Services: What's Under the Hood
A provider offering real embedded software solutions works across the whole stack at once. Here is what lives there.
Firmware
Firmware is the code burned into the MCU that runs from the instant power is applied. Reset vectors. Clock trees. Watchdog configuration. Peripheral initialization. The main control loop — or the scheduler or RTOS, if you have graduated beyond running instructions on bare-metal. Good embedded firmware development services deliver code that is modular, testable, and resilient to the stuff that kills lazy firmware in the field, such as brown-outs, illegal addresses, stuck interrupts, and stack overflows. A well-written firmware image recovers gracefully. A poorly-written one freezes in the customer's hand and may even require removing a battery (or worse) to recover.
Board Support Packages (BSPs)
The BSP is the link between the silicon and everything above it. It is the thing that lets an application developer call radio_send() without knowing which DMA channel, which interrupt priority, or which clock gate had to be touched.
A good BSP for mediocre hardware will outsell a bad BSP on brilliant hardware every time. A bad BSP is where your schedule goes to die — the app team will spend weeks chasing ghosts that turn out to be register misconfigurations one layer below. Our view of BSPs is laid out in more detail on our services page, but the short version is that it shouldn't be treated as an afterthought. It is often the heart (or at least the skeleton) of the product.
RTOS and Embedded Linux
Somewhere between a "bare-metal while(true) loop" and a full desktop operating system is where many modern products live. For tighter deadlines and smaller memory footprints, an RTOS like FreeRTOS or Zephyr gives you predictable task scheduling and microsecond-range interrupt latency. For bigger SoCs with networking, filesystems, and a user-facing OS layer — and where the ability to meet a hard real-time deadline is not as critical — embedded Linux provides an ecosystem with a wide range of common drivers and protocol stacks for free, provided you can trim, configure, and secure it.
Picking between bare-metal, RTOS, and Linux is an architectural decision. It affects cost, power, certification, and battery life. It should happen early in the design process, after the needs for peripheral support and hard schedule deadlines have been fully thought through.
Drivers, Stacks, and the Messy Middle
SPI, I2C, UART, USB, CAN, Ethernet, BLE, Wi-Fi, LoRa, cellular. Each is its own rabbit hole, and the chips designed to support each of them come with vendor-supplied sample code that can range from "complete and stable" to "hurriedly thrown together." Part of the job of an embedded software development company is knowing when to trust the vendor's driver, when to patch it, and when to throw it out in favor of a proper rewrite.
A good embedded designer who has been in the business long enough to know the makers of chips will know which companies thoroughly debug their example code and write proper documentation, and which push good chips out the door with bad collateral and expect to offer plenty of FAE support on the back side to make up the deficit. That kind of support is wonderful if you work for the kind of megacorporation that has leverage enough to get it. If you are a startup, you may not be able to get any chip vendor's attention — in which case having a good embedded systems designer on your side can mean the difference between your first product launch and your company's failure.
Hardware/Software Co-Design
Hardware and firmware can't be built in isolation. Proper or incorrect pin assignments can mean the difference between a driver that works well or one that cannot run at all. (If the transmit pin of your UART got blocked because its pin was assigned to some other function, you are not talking to anyone.) Clock choices affect power budgets and serial data error rates. Sometimes the difference between a clock created from a crystal and one created from an RC timing circuit can make the difference between a serial connection working and one having so much jitter that nothing can lock up. An MCU that looks cheap on a BOM spreadsheet can cost you six weeks if it is short one timer or one SPI bus. We have written about this elsewhere, but it is worth repeating: the cheapest time to fix a hardware mistake is before the board has been fabricated. The most expensive time is after it has shipped.
Testing and Validation
Basic tests under emulation on a development host under laboratory conditions are the easy part. The hard part is the testing that comes under real-world conditions.
But by the time you go into any test situation, you don't go there to find out how your device will perform. You go there already knowing — because you have done a thorough analysis and written and run plenty of simulation testbenches (if you are developing programmable logic), or you have stress-tested your system using the statistical tools of SPICE.
It bears remembering that in any good development effort for an FPGA, well over half (and probably closer to two-thirds to three-quarters) of the code you write should never be a part of the final product. It is the code against which your device is run in simulation, well before you ever get to the lab.
Yes, this takes more time up front, and for a while, it can appear as if nothing is happening on the project at all. But the last question anyone should ever ask is, "When can we get a board?" If you want a PCB that badly, badly is exactly how you will get one. It is the up-front thinking and imagining of corner cases that will force you to realize just how your actual synthesizable code should be structured.
If the project seems to be going slowly in the beginning, yet somehow comes together with blazing speed at the end, it is because somebody was smart enough to do the hard work up front. Planning to test and validate on day one is the best way to avoid an infinite loop of trying to shoehorn in corrections when test and validation are only starting — and are only starting to find the big problems too late in the design cycle.
How the Embedded Software Development Process Actually Goes
Engagements vary in size, but the shape rarely does. Here is the arc.
1. Requirements and discovery. This can take from a few days to a few weeks. The team figures out what the device must do, what it must cost, how long it must run on a battery, what certifications it has to pass, and what happens if any of those change. The deliverable is a written requirements document and a risk register.
This is also where market windows and realities get defined, the question of what makes a “minimum viable product” gets addressed, and contingency plans are laid out if the market moves or the window opens or closes.
2. Architecture and technology selection. This is not the place to skimp. Here is where you make choices about MCUs, what is done in analog and what is done in digital, and what RTOS or full desktop OS (Linux, anyone?) you may exploit. If you have a wireless stack, here is where you define it and set the basic requirements for bandwidth, latency, and acceptable error rates. This is the point of partitioning between hardware, firmware, and application. The deliverable is an architecture document, block diagrams, and possibly a very rough draft of a BOM.
This is also where we often get involved with founders who are talking to VCs. Investors generally don't want every detail (unless they are really nerdy), but the system architecture is what turns a pitch deck into something an investor's technical advisor won't tear apart.
At the other end of the food chain, this is also where we chat with our manufacturing partners. Not all great ideas come from degreed engineers, and the wisdom of the guy who’s been building things on the assembly line for the past few decades is not to be taken lightly.
3. Development. Now, depending on project complexity, we are into the long midsection of the voyage. Firmware, drivers, and (if applicable) a BSP get written in parallel. Code reviews happen on merges and branches. This is where software and hardware engineers negotiate how much is done by each, and how hardware will be designed to support software optimally — without simultaneously adding so many parts that the BOM cost increases unacceptably or reliability suffers.
It can be more expensive to develop software than to put hardware together, but software, being an idea (not a physical thing), is paid for only in development, not with every unit shipped. And it is a basic truism that the more parts you put in a system, the more parts there are that can break.
Our CEO drives a base-model car with a stick shift and no accessories because he has better things to do on his weekends than auto repair.
4. Integration and testing. Here is where software meets the hardware that has come off the actual assembly line, not evaluation boards cobbled together in the lab. Drivers get validated against actual peripherals. Actual timings and voltage levels get measured on logic analyzers and oscilloscopes, not simulators. Power gets profiled and checked against the original budget in a variety of real-world uses. Bugs may surface, but if the simulations were done properly, they are relatively minor and easily correctable. They are not the kinds of problems that require a massive redesign because somebody was lax in considering all of the corner cases.
If you got to integration and testing quickly but it seems you can never get out of it, you did something sloppy early on. If you have the feeling that you arrived at integration uncomfortably late but that suddenly everything is going more quickly than anyone expected, it is because you put in the effort up front.
5. Deployment and handover. Here you have actual signed production firmware and manufacturable hardware. You have gone through the process of flashing code during manufacturing. Because you got your CM involved back when the PCB was still in layout, he’s not left figuring out how to put a bunch of square pegs in round holes. Because you got somebody in purchasing to look at your preliminary BOM’s, there’s not somebody out in the gray market now trying to find a pound of unobtanium or a pack of non-existors.
And if you have done your work well, you are passing along the kind of documentation that means that when the customer calls you back, it is because he wants you to do his next project, not because he can't understand what you did on the last one.
A mature partner also plans for what happens after launch: making security patches, handling remote updates, and presenting the alternatives he thought through in anticipation of the day the silicon vendor tells you that some key part of your design is going end-of-life.
A good embedded design partner always strives to make what he has done so portable that he never has a gun to your head to force you to return to him. The best design firms put you in the best position to choose anyone to engage on the next outing — because the best design firms know that they are always the best choice for the smart shopper.
How to Pick a Partner Who Won't Wreck Your Schedule
Picking the wrong embedded partner can be a costly mistake, and it is doubly expensive precisely because the real damage often shows up quite late in the design cycle. It is quite easy to conceal poor choices behind flurries of activity, and often it can be the apparent lack of immediate action that is the clue that somebody is thinking a problem through thoroughly — before running off wildly to solve the wrong problem or head down an avenue that doesn't end with a shipping, revenue-producing product.
It is thus worth considering your potential partner in the context of the following.
Domain Expertise
Medical, aerospace, industrial controls, consumer, instrumentation — each one has its own regulatory and reliability rules. A team that shipped a Bluetooth toothbrush is not automatically qualified to build an FDA-approved or IEC 62304-qualified infusion pump. Ask where they have worked. Ask what went wrong. Honest answers to the second question are often worth more than a polished answer to the first.
Technical Stack and Capabilities
Do they work with your target silicon? STM32, NXP, TI, Nordic, Infineon/Cypress, Xilinx/AMD, Lattice? Do they have FPGA skills, analog analysis and design capability, and PCB layout in-house? Or are you about to become a project manager across four vendors who don't talk to each other?
Portfolio and Relevant Experience
Ask for case studies in your vertical. Our portfolio includes everything from a shirt-pocket video projector for 3M to a Mars Rover cruise stage vehicle — a spread that forces you to get good at a lot of different things. When you are evaluating anybody, look for range and depth. One without the other is a warning sign.
Communication Process
Weekly demos. Written status reports. A shared issue tracker. Time-zone overlap that allows for actual conversation, not just asynchronous ping-pong. A partner who can't commit to this up front won't suddenly become more communicative when things get hard.
Documentation Quality
Ask for a redacted manual or test plan from a past project. If the sample is weak, yours will be too. This is the cheapest, most reliable tell we know of.
And don't be bashful about writing your user's manual at the beginning of a project as a part of your product's definition. If you can't explain what you are trying to do to someone who just bought your widget, maybe it is time to circle the wagons for another product requirements discussion.
IP Protection
Who owns the code? Who owns the toolchain scripts? What about any reusable libraries? Sort this out before anyone writes a line of code. Not after.
Consider code portability if you are going to build a company (or a company division), not just one product. And recognize that free software is often worth every penny you pay for it. Don't let "open source" become "open sores."
The Short Checklist When Evaluating a Potential Partner
- Has shipped comparable products in comparable industries.
- Can name the chips (MCUs, SoCs, PLDs/FPGAs, analog front ends, etc.) and software (RTOS, toolchains, IDEs, etc.) they recommend — and justify why.
- Has a written test strategy, not a hand-wave.
- Will show you sample documentation on request.
- Has clear IP terms and, where appropriate, source-code escrow.
- Has references you can actually reach by picking up the phone and calling.
The Usual Ways Projects Go Sideways
Most failed embedded software outsourcing engagements fail in the same handful of ways. Dodging these will put you ahead of the majority.
Picking on price alone. Embedded bugs are cheap in the lab and catastrophic in the field. The cheapest hourly rate that produces fragile hardware or firmware is the most expensive thing on your spreadsheet.
Skipping early prototyping. Two weeks on a breadboard can kill a bad assumption before you commit to a custom PCB spin. A PCB spin costs real money and, worse, real calendar time.
Fascination with having a PCB. Sometimes delaying the making of a board accelerates the completion of a project, particularly when hardware and firmware are tightly coupled or there are potential weak links that would benefit from additional testing before Gerber files ever go out. The cost of a PCB is a highly predictable thing. Tell a board shop how many layers, what trace and space, what impedance requirements, etc., and they’ll give you costs and turnaround times that are quite reliable. The time and cost to do anything novel is not predictable and it should be given priority. Ninety percent of the time, “When can we get a board?” is not the question you should be asking. Fixating on the things that are readily quantifiable at the expense of paying attention to the ones that are a lot harder to define is approaching the process of developing anything novel completely backwards.
Unclear IP ownership. Clarify this in writing up front. Don't discover at delivery that your toolchain scripts belong to somebody else — or that there was some royalty model built into something that got used along the way, and you will now be paying for what should have been covered in NRE cost with every unit you ship forevermore.
And don't line yourself up in the crosshairs of someone else's legal department. Companies have been broken even when not guilty of wrongdoing simply because some large corporation with a vast legal department (full of lawyers with time on their hands) found a way to create a nuisance lawsuit and extort money in an out-of-court settlement.
The same source-control system that handles the configuration management to keep dead bugs in their graves may one day be the very thing that documents how you developed and patented or copyrighted something independently — long before someone else claims some kind of infringement.
Weak documentation requirements. If the contract doesn't specify documentation deliverables, you won't get them. Then your next engineer will rewrite the product documents from scratch, on your dime. And he’ll put in all of the work required to understand something that was never more than “tribal knowledge” that didn’t get passed down.
Poor alignment between hardware and software. When the EE and the firmware engineer aren't talking regularly, hardware pin assignments get locked before software needs are considered, and a feature you needed in software quietly becomes impossible. Did you need enough of an external bus to run DMA, but the pins required are already allocated to GPIO? That could have been avoided early if people had just been communicating.
Treating the drivers that would make for a solid BSP as an item to address after the first PCB has been built. We have already said it once, but it is still worth saying twice. Anything you might find in a BSP is the bridge from hardware to software. Underinvest here and every future feature costs twice as much to build — if it can be built at all.
FAQ
What's the difference between embedded software and firmware?
Firmware is closely related to embedded software. Firmware is the low-level code that directly controls hardware and lives in non-volatile memory on the device. Embedded software is the whole stack — firmware plus middleware, application code (if there is any), and sometimes even a user interface (again, if there is one), all running on the device itself.
For something to be embedded, it has to be completely out of the reach of a user — except, perhaps, when it is installed via a carefully controlled update (and even then, the user can only touch the update application, not the actual code being updated). Firmware is generally by definition embedded software, since it is not something a user can touch directly and it lives in that gray area between hardware (a physical thing) and software (a purely algorithmic abstraction).
How much do embedded software development services cost?
It depends. A single firmware module on a small MCU might land in the tens of thousands of dollars. A full product with embedded code, Linux, communication stacks, and regulatory documentation runs into six figures. The main cost factors are complexity, requirements for certifications (FDA, FCC, IEC, DO-178C, UL, CE, etc.), and the maturity of the hardware at the start.
Mature hardware, however, is no guarantee of a low price if it is designed poorly. We have on occasion had to put square pegs (such as a FIR lowpass digital filter) into a microcontroller that was chosen by someone who had no understanding of digital signal processing. Commandeering an onboard timer and carefully aligning interrupts so as to get ADC sample windows to open perfectly isochronously and deliver spectrally pure data would have been a good deal easier if the original designer had read at least the first chapter of any book written by Alan Oppenheim and Ronald Schafer — before he chose GPIO port pins at random and blocked a sizable number of key bits of timer hardware internally on the chip.
Good mature hardware is helpful. Bad mature hardware will drive up your bill significantly, which is why we recommend hiring a good embedded design firm in the first place.
How long does a project take?
It varies. Typically, simpler projects are doable from cocktail-napkin sketch to first shipping product in seven to nine months. Larger projects obviously take longer.
For reference, the handheld projector on our portfolio page began in March, and we were delivering a complete prototype at the end of the year. Full production began after Chinese New Year (which came late that year), and our customer (who had manufacturing facilities in Shenzhen) was astounded at how quickly he got from the design we handed off to him to a product he was making. But we had already worked with our own US-based contract manufacturer to come up with a design that we all knew would translate well to East Asian volume builds.
The motorcycle wiring update (also on our portfolio page) took about three months from concept to first PCB, but we were dealing with a relatively simple 1970s-vintage electrical system to start with. The first iteration of that PCB has by now logged a couple million miles, given the number of bikes in which it was installed. A second iteration was completed in less than a month, but this was only to add some power supply filtering to reduce interference for one particularly electrically-noisy aftermarket ignition system that a few of our customers had installed. Once in a very long while (in this case, a few weeks of riding, usually), an ignition spike could upset the embedded controller just enough to cause it to reset. Very few of our customers even noticed, since a software watchdog immediately caught the problem and reset the system so quickly that it was as if it had never happened. (Only the exceedingly sharp-eyed noticed that for a split second every few hundred miles, one of the turn indicators on the bike would blink as the software recovered.) But knowing that this little issue existed with just this one ignition system, on the next revision of PCBs we added a choke to an incoming power line and did a little extra supply bypassing. Good internal documentation and a well-designed PCB made the patch trivially easy, and the second revision was on the road in less than a month. Most early customers haven't bothered to return Rev 1, even after we alerted them all to this minor quirk.
Can portions of embedded software development be outsourced?
Yes, and on occasion, we collaborate as one of several firms working on a project. Specialist firms may carry deep experience with highly specific silicon, an unusual RTOS, or a narrow vertical, and that expertise could be uneconomical for us to replicate in-house for a single product. The keys to making this work are clear requirements, frequent communication, and having partners who will work with your hardware team, not around them. Our work on the NASA Mars Perseverance Rover project is a good example. Hundreds of contract firms worked on subsections of that project, and no one firm did it all. JPL had excellent management and outstanding science teams. They just had a very small hole in which our work fit well. In that case, we were the specialist firm, actually.
Additionally, our core team includes people who have spent decades in the electronic design business and are quite well networked. So we keep on speed dial a collection of people (many of whom are retirees who wish to stay active, or are thirty-somethings who hit it big in tech, retired early to a mansion and yacht, and still like to dabble). Each of these people has been thoroughly vetted and has likely worked with someone on our regular staff for twenty or thirty years. And each of them is a subject matter expert in his domain.
At the same time, people constantly outsource to us. Our CEO's former boss calls him regularly to say, "My budget is tight and they won't let me hire, but I do have permission to rent your people for a bit."
Just getting into the business of embedded systems requires mastery of multiple engineering skills (analog circuit design, digital circuit design, PCB layout, chip design, software/firmware design, etc.), so the people you encounter who can genuinely do the work have had to put in at least twenty years after college (or in many cases, graduate school) to learn them all. There are relatively few really good embedded engineers, and they generally all know each other (or at least know someone who knows someone). With that size of community, highly efficient teams rapidly assemble and disassemble to meet customer development requirements. None of us is at all territorial, either, since the unemployment rate for the best embedded designers is consistently negative. There is just more work than we all can do, so those of us who are any good are happy to pass it around when it makes sense.
What industries use embedded software development services?
Just about any industry that ships physical things: medical, industrial, automotive, aerospace and defense, consumer electronics, IoT, instrumentation, robotics, energy.
What languages and technologies are common in the microprocessor world?
C is the dominant language today, largely because ARM is so heavily used in the embedded space, and the GNU C compiler (and variants of the Eclipse development environment) have spread with the spread of ARM. It has helped tremendously that over the past three decades chip makers have done so much to improve their tool suites — and in particular the passing of things like symbol tables to reference what's happening in an emulator to what was written in C source code and cross-compiled on some other host. Everyone here at Focus Embedded can remember programming in assembly code at some point because there just wasn't a C compiler for the target chip back in the day. Or if there was, the in-circuit emulator couldn’t make sense of the symbol table – if there even was one. But those bad old days are largely a part of the 20th century, not the 21st.
C++ really hasn't made large inroads in the embedded space yet, although the concepts inherent in the "object model" for C++ were almost immediately adopted in the embedded community, even when a lot of embedded designers were still programming in assembly language and applying object-oriented design philosophy there. And all good HDL programming is inherently object-oriented. HDL modules are just too hard to simulate and debug any other way, and the object model neatly fits the concept of instantiating a submodule of HDL code under a specialized (and hopefully reusable) testbench.
On the silicon side: ARM Cortex-M and Cortex-A, and a range of FPGAs rule the roost. Years ago, x86 was a force in the market, but with the ongoing legal battle between AMD and Microsoft (and a memory model from the 1970s), x86 has tended to go by the wayside. We are all old enough here to have used embedded x86, and we have repaired a few legacy systems in our time. (Heck, we have even fixed bugs in somebody else's 8051 code not that long ago.) But it is not common these days. The Microchip PIC has largely gone the same way as the 8051, although we still have PIC tools and PIC expertise — mostly because we have supported other people's legacy designs.
On the operating-system side: FreeRTOS and embedded Linux are the dominant forces, particularly among cash-strapped startups that can't afford the investment in things made by folks like Wind River and Green Hills. For people with more money, or with a legacy system that demands it, VxWorks and INTEGRITY are out there. But with Amazon taking over the handling and dissemination of FreeRTOS (and with its price of "zero"), it is becoming a hard OS to turn down — particularly when maintaining a small memory footprint is paramount.
Combining all of the above is the Arduino ecosystem. Although it is a great little system for getting quick proof-of-concept designs in front of investors (with a minimum of really heavy duty programming), it is a hard ecosystem to bring to market in a new product unless the starting point was one of the ARM core processors (not one of the old 8-bit Atmel AT-Mega units) and the goal is to migrate to another ARM quickly. Unfortunately, the Arduino "Sketch" code rarely comes along for the ride, so there is a bit of rewriting involved — usually translating into C.
Really, though, the best embedded designers have seen it all and probably cut their teeth on things as ancient as the 8051, 80186, or 80C196. Not that any of us would use such a thing today, nor would we write in assembly code — although all of us still can and are able to use an assembler when something is so time-critical as to require it. But the best of us have stayed current, and the smartest of us were all betting on some combination of ARM and GCC fifteen years ago when the marketplace was still shaking out.
What languages and technologies are common in the programmable logic world?
These days, there are essentially three programmable logic vendors left, as most others have exited the market in one way or another, either by being bought out or simply being driven out of business. AMD long ago spun out Vantis, which has since been absorbed by Lattice Semiconductor. Cypress Semiconductor made some lovely CPLDs thirty-five years ago, but aside from migrating the technology into their PSoC line of parts (which are now being sold by Infineon), they made a graceful exit, as did Texas Instruments, which saw more money in a lot of other things they could have been running in their wafer fabs. Actel has been absorbed by Microchip, although they still haven't really made a large dent in the market. “Programmable antifuse” is a neat technology, and it still plays well in certain niches where radiation hardness matters. But it’s not even close to the mainstream anymore.
Today, the big three are Xilinx (now owned by AMD), Altera (now owned by Intel), and Lattice Semiconductor (which was nearly bought by a Chinese investment firm until the deal was scuttled by the first Trump administration on national security grounds). Lattice continues to run as an independent company.
Xilinx and Altera own the high end of the FPGA market, and they often compete both on the density of their seas of gates as well as the peripherals their chips contain. (For example, cellular telephone companies use these chips extensively in their tower electronics just because of the presence of high-speed SERDES peripherals in those chips that may cost as much as $30,000 each.) Xilinx and Altera have heavy development software investments in their Vivado and Quartus IDEs, respectively.
Lattice Semiconductor owns the lower end of the market space, and instead of competing on margins tends to compete on volumes of lower-priced chips. Lattice's primary software tools include Radiant and Diamond, which are targeted at specific chip types in the portfolio.
The dominant languages in the world of programmable logic are Verilog and VHDL, the former of which has C-like syntax and the latter of which looks a lot more like Pascal. Verilog is not nearly as strongly typed, making it more flexible — but dangerously so. VHDL is less likely to give a programmer a headache from some mistyped object somewhere, but it lacks Verilog’s flexibility. Verilog will allow you to write things that no sane person would write, but on occasion that’s an advantage when crafting a testbench to simulate something no sane user would do. Insane users are, after all, out there.
We program in both hardware description languages, although what is far more important is that we build testbenches well before we even think of writing the first line of synthesizable code. We also do not use vendor tools (such as those from Intel, AMD, or Lattice) to simulate code initially, since by not doing so we generate source that is reusable in any technology, not something that is likely to be locked to one silicon vendor. We use more than one simulation engine. Typically, we combine ModelSim, Aldec Active-HDL, and a truly ancient (and correspondingly persnickety) copy of Silos to simulate all modules. If a module can get through all three simulators without any of them complaining, and if we didn't start using vendor macros early, we end up with clean, highly portable code when we are done. This takes a bit more work up front, but most of us have at some point in our lives compiled PALASM or ABEL for the 16R4 or 22V10. If pressed, most of us could craft an ASM with D-flop transition tables and Karnaugh maps, although in this day and age the only reason to do so is to develop an understanding of what silicon compilers do – so you don’t write code (particularly if it's Verilog) that will reduce to something unexpected. In any case, we’re all old enough to have elevated thresholds of pain, having lived in a world where every gate and flop counted and there was no expert system to help you with anything – or to lead the unwary hopelessly astray.
The Short Version
Embedded software is the layer that decides whether your product feels solid or falls apart the first time somebody uses it outside a lab. The right partner treats firmware, BSP, drivers, and testing as first-class deliverables, works elbow-to-elbow with your hardware team (or, like us, has a highly competent hardware team of their own), and leaves you with documentation and tooling that outlast any single engineer.
The wrong partner will ship code that just compiles.
If you are planning a new device, modernizing an old one, or trying to rescue a project that is stuck somewhere between hardware and application, talk to a team that lives in this layer every day.
Get a quote. Start a conversation.
Continue reading:
Mars Rover Cruise Stage Vehicle