RTOSes can significantly ease the development of complex products, which can translate into faster development cycles. They often support compartmentalizing code into tasks, implement cross-task communication mechanisms, and commonly include abstractions (“drivers”) for platform-specific hardware, which makes porting firmware to new hardware easier. Because of all that, they also introduce overhead in code size and CPU usage, which is not acceptable for all projects.
Interrupt handlers almost always need to finish their execution quickly—the details depend on the device and application—and this limits the complexity of what can be done in their code. Also, the context in which the interrupt handler code is executed can, for either hardware or software reasons, prevent the usage from within the interrupt handler code of:
If you need a custom ASIC developed, we’ll be the first to advise you that we are not the right company for that. We’re happy to refer you to someone else.
If you’re looking for us to fund the product development in exchange for per-unit payments after launch, we’re not a good fit. It’s just not part of our business model.
There is always a leap of faith at some level because we’re in the world of creating solutions that don’t exist yet. But, if it’s an embedded system/subsystem you need, chances are we can help because we’ve successfully developed and delivered over 500 embedded solutions.
If we engage in a Requirements and Architecture definition effort, we’ll:
A requirements spec or a statement of work from you is a great place to start. If you don’t know how to create this or don’t have the time, reach out here and we can help you to formulate one.
The information we need generally falls into these categories:
T&M mostly, but we’ll certainly entertain other arrangements.