Development facilitators

This might be a good time to talk about developer (or technical development procedure) facilitators. Although these are not even regarded as intermediate requirements – and certainly are not considered to be as important as user requirements – some development facilitators could be considered as development procedure requirements that have big impact on the process and speed of development and thus on the project: Time is money.

These development facilitators are important for the project’s success. What are they?

We are talking about having:

• a good stable tool-chain
• good debugging possibilities preferably with hardware assisted debugging capabilities
• relevant pin-outs for scope probing
• event logging
• prototype and (automated) test environments
• a reliable scheduler or (real-time) operating system (for more complex task partitioning)
• a stable software upgrade mechanism

They are required in order to have a speedy quality assured development track. They are considered ‘common sense‘, but seem to be missing in lots of project tracks.

We will briefly touch some related issues. This is NOT an exhaustive list of things to consider.

early ‘printk’ = early logging

Whenever bringing up a device platform for the first time, you will want that first ‘hello world’ echo somewhere, because that means building and executing primitives works, the software survived the start-up code, a first primitive method of logging events exists…

This is a first very important validation of the toolchain, moreover it enables debugging of early hardware platform initialization and drivers.

software upgrade mechanism

Think early about how developers will build, flash and thus upgrade the software. Ask yourself how this will be done during industrialized production or even in the field. In the ever speed-increasing development cycle, ‘service packs’ are a reality. Sometimes, JTAG is not available or cumbersome. Sometimes, the boot and upgrade procedure in the internal bootloader of the micro-controller does not behave as expected… Please allocate time to investigate and evaluate this!

task partitioning = (real-time) operating system or scheduler

If the device is really small and simple, do not bother, but things do get complicated these says. The shift from 8-bit to 32-bit is accelerating. Task partitioning can help to abstract and isolate logic blocks. A real-time scheduler will help you to implement when and how often something should be done, and how to prioritize the different tasks. Is this a facilitator which will speed up the development work and thus the time to market? Yes, it certainly is.

code reuse has licensing implications

A lot of code is already out there. Sometimes the gains by using already existing code are huge. The question is whether it can be used in the commercial product under development. Although, we are big supporters of the spirit of open source, open does not mean ‘free‘ or ‘without implications‘. A license can be a very good reason to use or not to use a good quality library or driver. For prototyping, one can get away with short-cuts, but you will have to deal with it eventually when going from prototype to production candidate. The developer is the first person who has to be aware of such implications; he or she has to signal this to management. Management and legal department decide what to do and bare the responsibility.

prototype safety and robustness

Whenever working with high power devices or high voltages, there is a safety risk (primarily) for the developer but also for other people coming accidentally into contact with the device. ESD issues might arise and deteriorate the device under development. Beware that electric charges can – under certain unfortunate conditions – cross device boundaries and destroy attached devices. A destroyed prototype is costly in hardware and time. Consider opto-isolated communication to protect expensive development equipment and developers ( and maybe customers – but that is a safety requirement 😉 ).

In this context, we can state that

Development facilitators are (embedded) development-technical and procedural best practices that make it easier to develop fast and efficient, and minimize the time-to-market of the target product. They have no impact on end-users or other stakeholders, but they are essential for a successful development track.