To the question about Arduino

Even the wrong decision, put into life with proper consistency and energy, leads to success

To begin with about what in this post will not be. There will not be a story about how to easily write a program for flashing LEDs. There will be no information about where and at what price you can buy wonderful boards of some wonderful company. There will not be a story about how blue the sky was before the advent of this fiend, and how bad everything is now. There will also be no story about how chaos the industry was in before such a miraculous decision appeared, and how everything turned out well. There will not even be pictures to attract attention. Behind all this is not here, such posts on Habré are already enough (in no way do I try to offend their authors, but I’m writing a few about something else).

There will be an attempt to understand what Arduino is for (A), how exactly it was done, what methods various problems were solved, and where they (solution methods) could be tried to be improved. Undoubtedly, there will be a large number of evaluative judgments, a subjective view, tastes, and other delights associated with the discussion of an extraordinary problem. Well, there will be reasoning on the topic of why A is not always and not everywhere a cake and how to turn it (A) into it (cake) (if you look at this business from the right, that is my side).

To begin with, I’ll just make a reservation that I didn’t search for information on the closed sections of specialized forums, didn’t interview the developers of A, didn’t read the in-house documentation, and didn’t use other insider information. All the thoughts that are further set forth, there is an attempt to put themselves 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 acquired in cooperation with A, as well as with other embedded software development systems (B or Firmware), which I do on a professional basis. Well, I hope, the preamble is over, I reject the questions about engagement with indignation, you can get down to business.

So, in order for fruitful (that is, doing at least something) to work in the area of ​​development B, it is necessary (really necessary, that is, without it there is no way) to have the following components:
')
1) The hardware platform on which B operates,
2) A software platform that allows you to prepare B to function on this platform,
3) A communication component that allows you to place a given B on a given platform,
4) Means of control of the process of functioning of this B on this platform.

If everything seems to be obvious with the first three components, then the fourth one is usually somewhat out of sight, and this is not a debugger or monitor at all, although their presence is categorically welcomed, but simply an elementary process of starting the operation of B or hovering control. Now that we have decided on the needs, we will begin to consider how System A allows us to implement them and what could be done better (naturally, in my opinion, because I don’t have a stranger).

Before embarking on the discussion, there are several circumstances that should be considered. If you believe information from open sources, and everything that I know does not contradict it, A was originally designed to teach the basics of programming microcontrollers (MC). Therefore, the main task was to get the device as simple to use as possible for the trainees (that is, low-skilled staff).

Of course, economic factors were also taken into account, but were not decisive. At the present time, the scope of application A has significantly expanded, and it is actively used both in the DIY sector as a prototype, where the economic factor is also not critical, and in ready-made devices, where the situation is somewhat different. It is with these aspects in mind that we will conduct further narration.

1. Hardware platform
And the system is a fee that contains ALL the necessary components to ensure the full development cycle (with some reservations, we will look at them later), with the exception of the power supply. The latter is implemented outside of system A, connecting it does not present any particular difficulties, in some cases it is enough to attach a standard connecting cable or an independent standard cable to be purchased (a USB cable sounds like this in a scientific manner).

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

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

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

The second is the choice of architecture MK. 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 interfere with the effective operation of the compiler. For this reason, systems with a limited i8048 type stack are unacceptable (for them, efficient implementation of the stack language is hardly possible).

These two considerations narrow the space of choice even in our time, and 10 years ago (considering availability) 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 in this choice is neutral, AVR makes good chips, although PIC does not make much worse (or better ones, it's a matter of taste). But then there was the question of choosing a specific MK family, and here I would still prefer the 89 family compatible with the commands from I8051, but the authors know better, and they took the crystal from the MEGA AVR family. This solution has both pluses and minuses, but their discussion is the subject of a more specialized post (and constant sacred wars), but we will only run over the tops of the trees.

The third prerequisite is the simplicity of software modification in the MC, implemented as an ISP (In System Programming) technology, which allows changing software on the MC as part of the board, without exposing it to impacts related to the violation of the structural integrity of the product (translating into Russian, without the need for remove MK from the board). This requirement is met by many crystals, including the one chosen by the developers - solid 5.

However, the MC 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 educational purposes and all the related circumstances ), but at the same time, creates additional opportunities for the occurrence of faults and increases the cost of the device. The maintenance of this solution also imposed certain restrictions on the constructive implementation of the chosen MK, since the pads for QFP housings significantly outperform similar devices for DIP and PLCC, and the latter also require special tools 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 supply stabilizer with a reverse polarity protection circuit (a serial diode), which does not allow you to simply take and kill MK with an overestimated or negative voltage, you will first have to kill the stabilizer (which, however, is not a particularly difficult task and has been repeatedly implemented). Considering that the power supply through the USB connector was mainly meant, this solution is certainly acceptable.

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

The start-up circuit in the form of a time-dependent RC chain (but for some reason without a discharge diode, although taking into account the characteristics of power in the training mode, it is not really needed, but for the realization of devices that are constantly under power, it is absolutely necessary and clones A, as a rule, have ) 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 through a capacitor junction (we'll talk about the latter a little later).

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

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

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

Download VPO in MK can be carried out either using a hardware loader (or call it still built-in) or using software (let's call it external). The question of terminology is by no means simple or unambiguous, but we must agree on what we are talking about.

The main difference of the built-in loader is that the possibility of its functioning is provided at the production stage of the MC and cannot be modified by the user (or rather, it can, but this process is nontrivial and potentially reversible). This may be a real hardware module or a software module located in a specific area of ​​program memory. In any case, during the operation of the built-in loader, the normal operation of the MC (execution of user programs) is impossible. If we consider pure hardware 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 taking into account the input Reset (+1). All these interfaces provide full access to the MK resources, and some can also be used to control the execution of B (for debugging).

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

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

What are the advantages of the built-in bootloader:

1) it is not killed, that is, the user cannot make its use impossible without a special non-trivial procedure. Some users claimed in their questions that they succeeded, but I am inclined to believe that this is possible only because of the limited equipment they have at their disposal. Personally, I worked with Atmel's MK for a long time and must declare with all responsibility that it was not easy to kill the crystal as a whole, but it was possible, but I didn’t manage to “debug” the debugging interface (we do not consider cases of physical damage).

2) it is standardized by the manufacturer, as a rule, very detailed in the documentation, therefore there is a significant range of programming devices and load programs, both from the chip manufacturer and third-party companies. 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 functions of downloading 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 realized everywhere.

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

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

1) it is not killed and, accordingly, is not modified, the minuses resulting from this are obvious, although not so significant. If you really need your own bootloader, then you can always resort to dual boot - first, with the help of the built-in bootloader, you load and start the secondary (your) bootloader, and it does everything necessary. True, in the case of Flash memory with page organization, you may need double erasure, which will reduce the resource of the MC, but it is quite significant and this fact should not be significant, in addition, you can use the results of the built-in loader to erase the corresponding page. In summary, I would not recommend such a path, the method with an external program that translates your format into the format of the built-in loader and then transfer the received data in standard mode looks preferable.

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

4) it is located in the program memory and therefore takes up space from the target program, which can be a problem in certain circumstances.

The second interesting question is the interaction of the loader with the target program from the point of view of the transfer of control, because your MC will not always be launched with the loading of new content. The solution of this issue lies within the chosen paradigm of using the loader. The watershed passes along the initial power-on line - either you choose at the moment of switching on what exactly starts to function - the main program or the loader, and this will require some hardware resources, for example, the MK configuration foot, or after starting the loader (here without options) and then he must decide to transfer control to the target program, either under the control of the external signal again, or when a certain condition is reached, as a rule, in the external interface inactivity period. Both of these methods are not free from flaws and represent a choice between bad and not the best and are peculiar only to the external loader.

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

The choice of the USB interface is undoubtedly a success for the developers, since it is by now a de facto standard peripheral interface and almost all possible devices are equipped with it, as well as a good solution from the point of view of powering the A module (5+).

The converter to the programming interface on the FTDI chip - here I have a somewhat more complicated relationship. Of course, at one time this crystal set the tone for this market segment, but the corporate version did not differ in its low price, and numerous clones clashed with the brand drivers (if someone understands what the company did not suit the standard Serial driver from the OS, share the info, I just can not understand this decision). But then it rolled on an incline - the bit-manipulation mode can not be attributed to the advantages of this crystal, and the serial port was made easy, which led to the next implementation.

— UART, , ( , , ).

— , , , , , ( ) , .

— , (+), (-).

, , . USB ( ), ,
— SPI ( ) UART , , I2C, 1wire, SWD ( , ). , ( ) -. , USB ( , ).

, , , , - , , , .

, ( ) , 3 4. ( ), , ( FTDI), , . -USB — , .

, - , , . , — , . , , TI . , , , , .

( , ), . GCC . , , , . , , , . , ( , - , , 4.

, Wiring , , . , , - , , , 4--.

( ST Cube), ( ) . , — STM TI, ESP Intel. — , , , ( ), ( ) , , .

— ( ), , — 5-, .

— , UART , , , . , , — 3-- ( ).

( , , ) , — . , , ? , , . , ( , ), , , ( , , ) .

, , , ( , ) , , , .

Ps. , ( ) , , .