📜 ⬆️ ⬇️

Reference Code

Only a fool learns from his mistakes, an intelligent prefers to learn from others


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

Charles and I were stunned with him. Someone creates a critical part of medical equipment with, we believe, limited knowledge of the communication protocol that he will use. He also plans to build this part at the 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, and the “approximate” one does not sound — the translator's note) (I was told in the comments by the demo code —pp) from the supplier’s code.

It is probably unfair to draw such conclusions from just one question, despite perhaps 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 pretty much had to figure out the questions we were interested in from our own experience, which was terribly inefficient. I remember a trip to the arms of vendors to talk with chip developers in order to get inside information about some poorly documented or non-working functionality.

And believe me, I’m totally reusing it, and I think that this is really our only hope of salvation, as the systems get bigger and more complex.
')
But the reference code is replete with errors and is far from complete. It is usually intended to show the developer how to use the functions of the chip. Most experienced developers have scars on their bodies from the 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 -). 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 indicating two problems in our industry today.

The first one is often lousy unimportant code quality from a supplier. In some cases, everything is so bad that a semiconductor company must 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 past.

In some cases, as I know, the results of the work of these engineers are not returned back and are not reflected in the reference code provided to everyone else. They never have time to look for answers to any questions, except for an immediate crisis, thus the updates remain out of attention.

Nevertheless, it is necessary to show leniency 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 to push the chip through the sales door, but it will never receive the required attention to the user's needs. Modern microcontrollers are really complicated. Even the tire can fall apart, the periphery works in countless modes. Hundreds or even thousands of registers must be set correctly. The initialization list today can be 500, 1000 or more pages. The reference code really cannot handle each mode and possible configuration. The cost of developing such a code is huge, and the price is zero.

The second problem is the constant lack of time in the market. Clients simply do not have the time to figure out the nuances of processing all of 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 this 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.

Delightful wonders 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 that a chip manufacturer creates a reference code that is absolutely perfect. There are no mistakes, brilliant documentation and confirmation of the wonderfulness of this code by engineering practice. Who will believe him? Decades of problems created an atmosphere of general distrust. How would the salesperson convince the skeptical that now, of course, he produced what we really want (that’s why they don’t do such a wonderful code - aha. Of course-well)?

When it comes to reuse, we need to 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 the reference code?

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

The solution is obvious - it is necessary to use hardware PWM in such cases, but how do you think somewhere in the documentation this was said? And all downloaded from the official website of Arduino. There is an alternative solution, but there are cockroaches and almost bigger ones. In the words of Comrade Stalin - "Both are worse."
Well, then figs with them with Arduino (although with a fright, the guys consider themselves to be fully grown-up and should be asked accordingly), but just yesterday a bug was found in the reference library (port lwIP) on STM, which manifests itself under certain conditions non-simultaneous power supply to different hardware parts of the device.

Somewhere from six months ago, familiar young engineers did not work with USB reference library from STM on certain modes, and a month later a new version of the library appeared, which earned, for which STM sincere thanks (that these engineers, of course, do not justify in such uncritical use third-party code).

As, in many respects rightly, my colleague pointed out about the same Arduino libraries, their use strongly resembles a cargo cult, that is, do it and you will be happy. And everything is great, as long as everything really works, but if not ... this is where knowledge is required, which, in principle, cannot be given in advance. I would like to understand me correctly - I am not against Arduino, moreover, it is a wonderful ecosystem that tremendously lowered the threshold of entry and attracted a huge number of people to the firmware, but we must clearly understand that it is not a silver bullet, and even when implementing not extremely complex functions can create certain problems that it does not solve. That is, start with Arduino, but then go on - there the most interesting begins.

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

Source: https://habr.com/ru/post/257481/


All Articles