A recent thread in the Real Time Embedded Engineering Group on LinkedIn raised some interesting issues among developers when they were asked about their most difficult problem areas. Do these sound familiar?
- Unrealistic development schedules set by managers who don’t understand development
- Deficient documentation of the processor
- Insufficient errata; struggling with a problem for two years, contacted the manufacturer with no result, and 1 year later there is the errata.
- Finding and resolving timing issues
- Weak or poor tools: debuggers, emulators
- Bosses expecting if I kneel or spend time with the device it may relent and start working
- Learning NEVER to use a device/processor/controller if there aren’t many ‘how to, why, when” questions on Google. The device is too good to be true or else you end being the only using and fighting the problem.
- Low level debugging and overall performance of the system
- Hardware/software co-development. Finding root causes when both the code and the hardware are suspect.
- A paucity of available low-level-embedded example code
- Hardware debugging, especially during software integration on a new design where all hardware unit tests showed OK but putting it altogether creates a side effect.
- A badly written device driver delivered with the H/W; caused havoc and a delay of more than 4 months
- S/W interface which was way too complex to interpret on an embedded system
Of course at Quadros Systems we would argue that starting with the right software platform can make a big difference. RTXC Quadros RTOS-based software is delivered fully integrated with working drivers and interfaces with a binding to your chosen tool environment. Start with the provided sample project and you are good to go. Our Release Notes with tool caveats can reduce the learning curve up front, and save valuable time when development crunch time begins. We know our customers save weeks, if not months, over developing a product using free or poorly tested software.