Reference code

Original author: Jack Ganssle
  • Transfer

Only a fool learns from his mistakes, a smart one prefers to learn from strangers


My active correspondent Charles Manning sent me a link to a question from the Nordic Semiconductor website. This question, literally: “Which BLE profile will satisfy ECG signals in the best way and is there an example code for the ADC from this profile? I’ve been looking for some time and can’t find it. ”

Charles, and I along with him, were stunned. Someone creates a critical part of medical equipment with, it seems to us, limited knowledge of the communication protocol that he will use. He also plans to build this part on a reference (if anyone offers a good translation of this term I will be grateful - “exemplary and reference” are not very suitable - in Russian, these two terms contain a slightly different meaning, but “approximate” doesn’t sound — note of the translator) (I was prompted in the comments by the demo code -pp) code from the supplier.

It is probably unfair to draw such conclusions from just one issue, despite the possibly chilling consequences for users. And I'm not going to ban forums - they are a great way to share knowledge. In the pre-Internet era, we all had to pretty much figure out the issues of interest to us from our own experience, which was terribly inefficient. I remember going to the arms of the vendors to talk with the chip developers in order to get inside information about some poorly documented or broken functionality.

And, believe me, I am completely and completely for reuse, and I think that this is really our only hope for salvation, because the systems are getting bigger and more complicated.

But the reference code is replete with errors and far from complete. It is usually intended to show the developer how to use the functions of the chip. Most experienced developers on the body have scars from episodes when they figured out why some parts of this code do not work. Some of them are just awful (and some are even worse -pp). Charles uses Nordic and claims that their code is a cut above the rest, but it is nonetheless a reference code.

The person who asked such a question can be an extremely competent developer who will analyze the code before using it. But this is a symptom that points to two problems in our industry today.

The first one is often lousypoor quality code from the supplier. In some cases, everything is so bad that a semiconductor company needs to keep a large team of its engineers at the customer’s site to help bring the product to market. Of course, this only happens for those who buy a huge number of chips, and small consumers, or even those who buy hundreds of thousands, fly by.

In some cases, as I know, the results of the work of these engineers do not go back and are not reflected in the reference code provided to everyone else. They never have time to look for answers to any questions other than an immediate crisis, so updates are left out of focus.

Nevertheless, it is necessary to show indulgence to suppliers - after all, their mission is to sell chips. The reference code is free and therefore perceived as free. That is, it must exist in order to push the chip into the sales door, but will never get the required attention to the user's needs. Modern microcontrollers are really complex. Even a tire can fall apart, the peripherals operate in countless modes. Hundreds or even thousands of registers must be set correctly. The initialization list today may be 500, 1000 or more pages. The reference code really cannot handle each mode and possible configuration. The development cost of such a code is huge, and the price is zero.

The second problem is the constant lack of time in the market. Customers simply do not have the time to figure out the nuances of processing all these peripherals as well as they need to create reliable code if they want to stay on the crest of a wave. The solution is to reuse the reference code. If it were a perfect world, reuse would be at the level of the object code, all reusable code would be qualified, and all customers would have complete confidence in the code.

Amazing miracles will accompany the IoT explosion in the coming years if the situation remains so bad.

Unfortunately, there is a subtle meta-reflection on what is good. Suppose the chip maker creates a reference code that is absolutely perfect. No errors, brilliant documentation and confirmation of the greatness of this code by engineering practice. Who will believe him? Decades of problems have created an atmosphere of general distrust. How would the seller convince the skeptics that now he, of course, has produced what we really want (which is why they don’t do such a great code - huh. Of course -pp)?

When it comes to reuse, we should think about pyramids. They were built on an incredibly solid foundation. In the world of firmware, too often, this pyramid is upside down.

What is your experience with reference code?

Further from the translator is the answer to Jack's question.
About two weeks ago I saw on the blog a question about the failures of servo machines under Arduino. I found the code of the library used, looked, was horrified - they form the software PWM, tugging their legs with their hands in the timer interrupt, therefore, naturally (or as they say, of course) when the processor loads with another interrupt (and in that case it was a stack of wireless protocol support, the source code of which I did not find, but which most likely, following the modern mode, is executed in the interrupt mode), the duration of the PWM pulses can expand by an indefinite amount.

The solution is obvious - you need to use hardware PWM in such cases, but, do you think, somewhere in the documentation about this was said? Moreover, everything was downloaded from the official website of Arduino. There is an alternative solution, but their cockroaches are almost bigger there. As Comrade Stalin said, “Both are worse.”
Well, figs with Arduino (though for some reason, the guys consider themselves quite old and should be asked accordingly), but just yesterday a bug was found in the reference library (lwIP port) on STM, which manifests itself under certain conditions under non-simultaneous supply of power to different hardware parts of the device.

About six months ago, STM’s USB reference library didn’t work for certain young engineers in certain modes, and a month later a new version of the library appeared, which worked, for which STM sincerely thanks (for these engineers, of course, it does not justify such an uncritical use third-party code).

As, in many respects, my colleague pointed out about the same Arduino libraries, their use is very similar to cargo cult, that is, do it and you will be happy. And everything is fine, as long as everything really works, but if it doesn’t ... this is where knowledge is required, which adherence to given rules cannot give in principle. I would like it to be understood correctly - I am not against Arduino, moreover, it is a wonderful ecosystem that amazingly lowered the entry threshold and attracted a huge number of people to the firmware, but we must clearly understand that it is not a silver bullet in any way, and even when it’s not extremely complex functions can create certain problems that it does not teach to solve. That is, start with Arduino, but then move on - the fun begins there.

PS. So I can’t understand why the same Jack reads his “More Firmware, Faster” firmware course every year in 5-6 countries, but we don’t have anything like that and are not expected. We do not need strong engineers? I can’t believe it. Or is it a reluctance to learn? Or in the reluctance to pay for school (for your or your employees)? I have no answer to these questions, there is only a statement of fact.

Also popular now: