To the question of Arduino

Even the wrong decision, implemented with due consistency and energy, leads to success

To begin with, what will not be in this post. There will not be a story about how easy it is to write a program for flashing LEDs. There will be no information on where and at what price you can buy wonderful boards of some wonderful company. There will be no story about how blue the sky was before the appearance of this fiend of hell, and how bad everything is now. There will also be no story about how chaotic the industry was before the appearance of such a wonderful solution, and how everything was fine. There will not even be pictures to attract attention. For all this, not here, there are enough similar posts on Habré already (I’m not trying to offend their authors in any way, but I'm writing a little about something else).

There will be an attempt to understand why Arduino (A) is needed, how it was done, by what methods various problems were solved, and where they (solution methods) could be tried to improve. Undoubtedly, there will be a large number of value judgments, a subjective look, taste, and other delights associated with the discussion of an extraordinary problem. Well, there will be discussions on the topic of why A is not always and not everywhere a cake and how to turn it (A) into it (a cake) (if you look at this matter from the right side, that is, mine).

To begin with, I’ll immediately make a reservation that I did not search for information in the closed sections of specialized forums, did not interview developers of A, did not read the internal documentation and did not use other insider information. All the thoughts that are stated below are an attempt to put ourselves in the place of developers and reflections in the style of “If I were the Minister”. And of course, the fruit of a certain experience gained both in cooperation with A and with other systems for developing embedded software (B or Firmware), which I do on a professional basis. Well, I hope that the preamble is over, the questions of bias in advance I dismiss indignantly, you can get down to business.

So, in order to fruitfully (that is, doing at least something) to work in the development industry of B, it is necessary (really necessary, that is, without this to succeed) to have the following components:

1) The hardware platform on which B operates,
2 ) A software platform that allows you to prepare B for operation on this platform,
3) A communication component that allows you to place this B on this platform,
4) Means of controlling the process of functioning of this B on this platform.

If everything seems to be obvious with the first three components, then the fourth usually falls out of view a little, and this is not a debugger or a monitor at all, although their presence is categorically welcome, but it is also just an elementary process of starting the operation of B or controlling the hang. Now that we have decided on the needs, we will begin to consider how System A allows us to implement them, as well as what could be done better (naturally, in my opinion, because I have no stranger).

Before starting the discussion, there are a few key points to consider. If you believe information from open sources, and everything that I know does not contradict it, initially A was developed with the aim of teaching the basics of programming microcontrollers (MK). Therefore, the main task was to obtain the device as simple as possible for students (that is, unskilled personnel).

Of course, economic factors were also taken into account, but they were not decisive. At present, the scope of A has expanded significantly, and it is actively used both in the DIY sector as a prototype, where the economic factor is also not critical, and in finished devices, where the situation is somewhat different. It is with these aspects in mind that we will continue to narrate.

1. Hardware platform
And the system is a board that contains ALL the necessary components to ensure a complete development cycle (with some reservations, we will consider them later), with the exception of the power source. The latter is implemented outside system A, connecting it does not present any special difficulties, in some cases it is enough to attach to the kit or to purchase a stand-alone standard connecting cable (this is how USB cable sounds wacky).

On this point, you can put a solid five, that is, everything you need is present and you can work with the device.

And now let's move on to improvements, because, as you know, there is no limit to perfection. The main component on board A is a microcontroller (MK), and here questions immediately arise. By what criteria should this MK be selected?

First, first of all, it is necessary to be able to modify the software at minimal cost, this implies the presence on the MK of easily changeable (not ultraviolet-erasable, the one who used, will understand) program memory, and this is unambiguously FLASH, and not the minimum amount, 1K or 2K are unlikely to be acceptable - in A it is implemented at 4+ (at one time it was 5, but time does not stand still).

The second is the choice of MK architecture. Since it was originally planned to use a high-level programming language (most likely, C), the architecture features of the selected MK are not so significant, as long as they do not impede the effective operation of the compiler. For this reason, systems with a hardware limited stack of type i8048 are not acceptable (for them, an effective implementation of the stack language is hardly possible).

These two considerations narrow the space of choice even in our time, and 10 years ago (taking into account accessibility) there was practically a choice between the products of two companies - Atmel (AVR family) and MicroChip (PIC family) and the choice was made in favor of the first company. My attitude towards this choice is neutral, AVR makes good chips, although PIC does not do much worse (or better, it’s a matter of taste). And here was the question of choosing a specific MK family, and here I still would prefer the 89 family, compatible with the I8051 teams, but the authors know better, and they took a crystal from the MEGA AVR family. This solution has both pros and cons, but their discussion is the subject of a more specialized post (and constant holy wars), but we will go over only the tops of the trees.

The third prerequisite is the simplicity of software modification in MK, implemented in the form of ISP (In System Programming) technology, which allows you to change the software on MK in the composition of the board without exposing it to the effects associated with the violation of the structural integrity of the product (translating into Russian, unnecessarily remove MK from the board). Many crystals meet this requirement, including the one chosen by the developers - solid 5.

Nevertheless, MK is on the board in the block (I'm talking about the original solution), which, of course, makes it easier to find possible malfunctions by replacing (and this problem was undoubtedly relevant, given the use of A for training purposes and all the related circumstances ), but at the same time, creates additional opportunities for malfunctions and increases the cost of the device. Maintaining such a solution also imposed certain restrictions on the constructive implementation of the chosen MK, since the pads for QFP cases significantly outperform similar devices for DIP and PLCC, and the latter also require special devices to extract the MK from the block, so the DIP option was chosen - 5 -.

What components are still located on board A? First of all, it is a power stabilizer with a reverse polarity protection circuit (serial diode), which does not make it easy to take and kill an MK with an overstated or negative voltage, you will first have to kill the stabilizer (which, however, is not a particularly difficult task and has been repeatedly implemented). Given that it was primarily intended to supply power through a USB connector, this solution is certainly acceptable.

A quartz (non-ceramic) resonator with capacitors allows you to set a quite stable (within reasonable limits) frequency compared to a ceramic resonator, which can only be worse than the built-in oscillator, which is known for extremely high deviations from the nominal value (see the documentation).

A start-up circuit in the form of a RC timing chain (but for some reason without a discharge diode, although taking into account the features of the power supply in the training mode, it is not particularly needed, but for the implementation of devices that are constantly under power, clones A are also usually required ) with an additional button that allows you to restart the device without turning off the power and with an additional reset signal from the programmer via capacitor isolation (we'll talk about the latter a bit later).

Pads for connecting additional devices (shields) to which all MK contacts (except service ones) are output, plus power and reset signals.

LEDs to indicate the presence of power and activity of different nodes of the board A, as well as a general-purpose LED, which are proposed to flash in numerous manuals.
In general, almost everything that is needed is needed, so put 5-.

And now let's move on to the last, but not least, hardware component - the programmer. First of all, a few words about the programming technique in general.

Downloading malware in MK can be done either using a hardware loader (or let's call it built-in) or using software (let's call it external). The question of terminology here is by no means simple and ambiguous, but we must agree on what we are talking about.

The main difference between the built-in bootloader is that the possibility of its functioning is provided at the production stage of the MK and cannot be modified by the user (or rather, it can, but this process is nontrivial and potentially reversible). This can be a real hardware module, or a software module located in a special area of ​​program memory. In any case, during the functioning of the built-in bootloader, normal MK operation (execution of user programs) is impossible. If we consider purely hardware boot loaders, they can be implemented on the basis of the following interfaces (in order of decreasing the number of necessary contacts) JTAG, (4/5 + 1 (0)), SPI (3/4 + 1), SWD (2+ 1), DebugWire (1), of course, not counting the ground and given the input Reset (+1). All these interfaces provide full access to MK resources,

It is also possible to implement an embedded software module (the so-called Boot-Loader), which is closer to the external bootloader in operation, with a number of differences, but they are less common than hardware ones (this was true for the times when A was created, now the situation is not so clear) .

The external (software) bootloader is a special software that is indistinguishable from B in terms of operation, and which uses the special hardware capabilities of MK to access MK resources to modify program memory. In this case, the necessary information is obtained through any standard interface - UART, USB, Ethernet, Wireless interfaces that are part of the MK. When implementing this option, a number of problems arise that are not only unsolvable, you just need to know about their existence. Among them are ensuring the joint functioning of B and the process of modifying program memory, monitoring the integrity and restoration of program information in case of failures in the programming process, and the issue of transferring control from the loader to the main program. The last question will be considered in more detail a little later,

What are the advantages of the built-in bootloader:

1) it is not killable, that is, the user cannot make it impossible to use it without a special non-trivial procedure. Some users in their questions claimed that they succeeded, but I am inclined to believe that this is possible only because of the limited equipment available to them. Personally, I have been working with Atmel MC for quite some time and I must declare with all responsibility that killing the crystal as a whole, although not easy, is possible, but I have never succeeded in “corrupting” the debugging interface (we do not consider cases of physical damage).

2) it is standardized by the manufacturer, as a rule, it is very detailed in the documentation, therefore there is a significant range of programming devices and boot programs, both from the crystal manufacturer and third parties. If they do not suit you, then you can make your own programming system, as I once did on the basis of the ByteBaster device and self-written programs.

3) in addition to the functions of loading B, it can be used for other purposes, in particular, monitoring the status of the target program, as well as debugging B, although this feature is not implemented everywhere.

4) it is located in a special section of program memory and can provide access to the target program for its functions as a library (as done in Cube), there are certain difficulties from the point of view of the linker, but they are completely solvable.

Now a little about the shortcomings - there are few of them, but they are, namely:

1) it is indestructible and, accordingly, unmodifiable; the cons resulting from this are obvious, although not so significant. If you really need your bootloader, then you can always resort to double boot - first, using the built-in bootloader, load and launch the secondary (your) bootloader, and it does everything you need. True, in the case of Flash memory with a page organization, you may need to double erase, which will reduce the MK resource, but it is quite significant and this fact should not be significant, in addition, you can use the results of the built-in bootloader to erase the corresponding page. In summary, I would not recommend this way, the method with an external program is preferable,

3) it can be used for monitoring, but at the same time the interface becomes unavailable for communication with user devices, unless special measures are taken, but they are not taken, since I personally do not consider the jumpers as a solution.

4) it is located in the program memory and therefore takes the place of the target program, which may be a problem in certain circumstances.

The second interesting question is the interaction of the bootloader with the target program from the point of view of control transfer, because your MK will not always start with the loading of new content. The solution to this issue lies within the chosen paradigm of using the bootloader. The watershed passes along the line of initial inclusion - either you choose at the moment of switching on what exactly starts to function - the main program or bootloader, and this will require some hardware resources, for example, the configuration foot of the MK, or after startup the bootloader functions (here without options) and then he must decide to transfer control to the target program, either under the control of an external signal again, or upon reaching a certain condition, usually a period of inactivity of the external interface.

Now that we have realized the problems, we can see how they are solved in A, here we have adopted the option of an external bootloader with a transition to the user program after a delay of inactivity, the chain of information flow begins with USB, which turns into UART, goes to the MK and is processed by the bootloader in reprogrammable memory MK. Consider this solution in more detail.

The choice of the USB interface is undoubtedly the luck of the developers, since it is currently the de facto standard peripheral interface and it is equipped with almost all possible devices, also a good solution from the point of view of organizing the power supply of the A module (5+).

The converter to the programming interface on the FTDI chip - here my attitude is somewhat more complicated. Of course, at the time, this crystal set the tone in this market segment, but the branded version did not differ in low price, and numerous clones clashed with branded drivers (if someone understands what exactly the company did not like the standard Serial driver from the OS, share the info, I just can not understand such a solution). But then it rolled downhill - the bitwise manipulation mode could not be attributed to the advantages of this crystal, and the serial port was made easy, which led to the next implementation.

At the same time, a lack of reliance on a proprietary driver pops up - to ensure the bootloader starts from any state of the MK, a system restart is used by supplying a signal to track information from the UART, and it is implemented in a non-standard way, due to which clones A on other converters are unstable (strictly speaking, generally do not work, but they can be helped by the reset button on the board).

Another drawback of the implementation is that after the restart, the bootloader always starts to work, and the exit from it occurs after a waiting time, during which all the pins that are not directly involved in the boot, are in the third state, which can lead (and lead) to certain problems in functioning connected devices, if during the design of level-sensitive circuits external pull-up resistors were not laid.

Serial port as an exchange device for programming - a standard interface is used, which allows you to implement a communication channel with the target program through one device with a loader (+), but makes it difficult to use this interface to communicate with external devices (-).

Now that we have reviewed the existing implementation, we can offer an improved one. At the same time, we save the USB interface (they are not looking for good), we realize the ability to use standard OS drivers,
we organize interaction with MK with at least two interfaces - SPI for boot purposes (we use the built-in loader in MK) and UART for interaction with the target program, both with the ability to disable drivers as a user’s command, the implementation of additional interfaces like I2C, 1wire, SWD will look pretty good (all those who do not require additional hardware). For all implemented interfaces, a monitoring function is highly desirable, which turns our board (let's call it AND) into the basis of a micro-laboratory. It is hardly possible to implement all these Wishlist on a chip of a standard interface converter, therefore, the interface to the PC is based on an inexpensive controller with built-in USB (there are already similar implementations on one MK, but they retain A interface style and only that).

An alternative to this option is to implement an external bootloader that is identical to the existing one, but on the same chip, which is both an interface converter and a target MK, which can improve the weight and size and cost characteristics of the board, but here you need to consider the disadvantages inherent in such a bootloader and weaken them as much as possible, monitoring standard interfaces is also difficult.

What I don’t really like in A is the presence on the board of components that are not always in demand during independent functioning (meaning work on the fly) related to functions 3 and 4. Such components will always (almost always) be necessary, since it is necessary to ensure physical contact with an external programming device, but in this case I personally think they are somewhat redundant (FTDI chip), which leads to an increase in cost, board size and device consumption. Then the presence of a mini-USB connector on the board will be a big question - only to supply power, but here you need to think.

Speaking in principle, I would still make the programmer as a separate device, which would reduce the cost and size of the board, due to a certain decrease in the usability. By the way, many other development systems В implement a certain hybrid - there is an extended version of the board with a built-in programming device and truncated versions of the boards, for control of which the extended version is used. So, in particular, does TI in its evaluation sets. Probably, such an option would be nice, but only for the option of using a board as the basis of real devices, for training purposes, this approach is clearly inconvenient.

Well, it seems like we finished the review of the hardware (if I forgot something, recall in the comments), now a little about the development environment A. It is built as a shell on the GCC compiler and was originally intended to facilitate the work of a poorly trained user. The shell implements a little syntactic sugar, eliminating the need for some routine actions that actually take place in writing a C program, but at the same time is limited to using a standard preprocessor and compiler with all its shortcomings. In addition, the user is provided with standard libraries that facilitate interaction with MK equipment, and an interface to them is described. I note in passing that the quality of these libraries can be a subject of discussion (see my post on the management of pins,

There is a common opinion that A has its own Wiring programming language, nothing more than a misconception caused by unscrupulous statements by marketers, there is only an interface to libraries. But it’s a pity, by the way, introducing your preprocessor with advanced meta-programming capabilities would be very helpful, and some features of working with the equipment were implemented much easier and more reliable than in standard C, so there are 4-- for this position.

Very useful in this add-on language would be a means of a generalized description of hardware settings with the generation of the necessary code for a specific MK with visualization tools for such a description (something like ST Cube), but the creation of such a product clearly went beyond the intentions (and maybe capabilities) of the developers platforms. The fact is that in recent years A compatible systems on crystals of various companies have appeared - these are STM and TI, and exotic ones like ESP and even Intel. And if everything is clear with the last one for me - well, there is no market for it, it doesn’t need an A compatible board with such a connector and SUCH price, although with SUCH capabilities, then the others mentioned compare favorably with the original A crystals in terms of built-in hardware units and their capabilities (keeping low cost),

The interaction of the development environment with hardware - the programming process itself is not bad (taking into account the comments about the drivers), there is the possibility of customizing the bootloader, taking into account the accepted paradigm - 5-, minus for insufficient informational content of error messages and the lack of verification of the type of programmable device in the standard delivery.

But managing the program’s work is bad enough - it’s only possible to restart at any time, regardless of the state of the target MK program, and minimal debugging tools in the form of debugging printing via the UART interface, and the built-in debugging monitor is absent as a class, debugging output in case of busy serial channel not provided, standard debugging interfaces are not involved. In general, in such cases, out of courtesy, I say that debugging tools are present in the complex - a solid 3-- (all ratings are given on a five-point scale).

Well, at the end of the post (it’s time to round off, and it turned out more than I already planned) I would like to answer the question that the reader must have raised - I am for A or against. It seems that at the very beginning I kind of hinted that I would try to maintain objectivity, but in whose direction would it be? So, I do not belong either to haters or to the cult of admirers of A. From one side we see statements that the use of A is incompatible with professionalism (in general, a professional is able to operate with any tools, love or hate them is not included his duties), on the other hand, we come across statements that the person who wrote the sketch for reading data from the temperature sensor (as a rule, did not write,

The truth, as always, lies in the middle, it has such a cute property and it consists in (again, in my opinion) that A is a good entry-level kit that allows you to quickly build devices of a certain complexity, an excellent platform for starting the development of a subject area, but one must well understand the limitations of this platform and in no way stop at the first step of a rather long staircase.

PS. I’m thinking about creating a course on embedded programming, an integral part of which (the initial course) would be a modified Arduino board, what is your attitude to such a project, express it in the survey.