DMA in general and in particular

    If I knew where you would fall, I would lay straws

    Many developers of embedded devices have heard about the existence of DMA (Direct Memory Access) - the Russian-language DAP (Direct Access to Memory), but they use it much less often than it (DAP) deserves it. By the way, I will mention precisely this abbreviation, but not because I am such a stubborn patriot and an opponent of English-language borrowing, but only because I am too lazy to switch the keyboard layout once again.

    The main reasons for the insufficient use of DAP in MK programs are three: 1) the relative complexity of this device, which, together with 2) a lack of understanding of the benefits of its use, leads to a reluctance to learn and master this device (as they say in such cases, the older sister does not order - for those who in the tank is about the laziness that we were born before), weighed down by 3) the lack of good and understandable examples of the use of the MPD in the manuals supplied with MK. And if the first two reasons are clearly subjective, the third is undoubtedly objective and the paranoid awakens inside me and insists that this was done specifically with the goal of preventing domestic MK developers from reaching advanced levels, somewhere above 60 (something that suffers and other developers around the world, paranoidly ignored,

    Nevertheless, without jokes, indeed, in the examples, at best, there is a module for setting up an individual RAP channel, and you will not find a system connected to the RPS driver in examples of applications (even in CMSIS you will not find, well, there really is an objective reason - I’ll write a post about him - I will mention). Why it is so in fact - I don’t know, but the crystal developers know better, the only reasonable justification that comes to my mind is that the RAPs are quite specific, so “you can’t just get it and take it” to transfer the code from another source, but in view of The low demand for RAP in real developments, the absence of such examples is not considered a significant drawback. To fill the knowledge gap indicated by me, a real post is intended (an immodest statement, but if you don’t praise yourself, you go all the time like a spit), so

    Nevertheless, I must warn the impatient reader that he will not find here a silver bullet that can be safely included in his designs, but only (but this is a lot) will find some thoughts and approaches that will facilitate him building his own systems on MK with the use of RAP. That is, I will put the flags in the places where the rake exactly lies, but I can’t guarantee that there will be no unmarked rake, which, however, does not prevent you from throwing the flags in the figs and walking the rake yourself. In general, those who read my posts must have noticed that I am not focusing on WHAT should be done and HOW exactly, but on WHY I recommend doing just that.

    So, DAP is a part of MK equipment that allows sending data between various components of a given MK (and the system with its participation) without attracting processor resources (more precisely, with minimal involvement, since doing anything in the MK system generally WITHOUT processor involvement - a bold and far-reaching thought).

    The main idea of ​​these devices is that when a program is executed, not every command calls a system bus to external devices or RAM (access to program memory is not considered), therefore, a device serving a system bus has idle cycles that it would be nice to use something.

    Another reason contributing to the creation of DAP was the appearance of high-speed input-output devices, the maintenance of which on the polling required a significant processor time, and interrupt service was almost impossible. The forerunner of the DAP should be considered the so-called peripheral processors in the mainframe architecture with local memory, which were then transformed into real DAP, which solve data transfer problems between high-speed input-output devices and the main RAM and are part of the hardware that controls a specific external device.

    There was a picture (for example, in DCK), when one WU worked according to the RAP, and the second - according to interruptions or even in the polling cycle (MX driver, if anyone remembers). When the first MCs appeared, in which the memory is integrated into the chip, the creation of devices with DAP external to the chip became a very non-trivial task and, of course, the DAP migrated inside the MK and became part of its architecture. This process was not linear in progressive and can be found both on the basis of the 51st architecture with support for DAP, and on the basis of Cortex-M3 based MC with a rich set of peripherals, but without support for the DAP (e.g., Stellaris). Nevertheless, in the majority of modern MCs based on ARM, DAP is present and we can proceed to study them and, for a start, dwell on the consideration of their features.

    As mentioned above, the main purpose of the RAP is the transfer of data between different devices with minimal involvement of the processor. As a rule, one of these devices is the main memory of MK, although sometimes it is possible to transfer between two external devices, so from memory to memory. Some RAPs support such capabilities, some do not, and this should be considered when choosing a MK.

    The next important characteristic is the number of simultaneously transmitted transmission channels - in the sense, of course, that at each moment of time only one piece of data can be transmitted on the bus, but there can be several requests that will be serviced alternately, again with minimal CPU resources. Naturally, the minimum number of MAP channels is -1 (fewer channels are unlikely to be operational), the maximum is almost unlimited, the real limit may be the number of external devices + 1 (for memory-memory type requests), but nothing (except the cost) can interfere make us arbitrarily many channels of the RAP.

    The next feature can be considered a request servicing mechanism in one channel. Let us dwell on this moment in more detail and analyze in general terms the operation of one request of one channel of the RAP.

    In order to make a transfer, we should inform the RAP about our intentions, that is, where we want to transfer data from, where they should be sent, how much data should be transferred, transfer modes (more on this later), and, possibly, service information. We can place this information either in the registers responsible for the operation of the DAP (the outdated method and we will understand why later) or in the system’s RAM, in the latter case it should be either a special allocated memory area so that the DAP knows where to get the information , or in some register of the RAP should be placed information about exactly where in the RAM the data is located (in the usual language, we must put a link). It is the latter method that is used, since it has the following advantages:

    So, after the specified transmission is completed, we will receive a signal about the end of the transmission (most likely in the form of an interrupt) and we may well need to start the next transmission as quickly as possible. If we set the transfer parameters in registers, then either we cannot modify them before the end of the current transfer, or we can make shadow registers. If the register contains a link to the data that defines the transfer (TCB - Transfer Control Block - Transmission Control Unit-BUP), then we can configure the BUP for the next transmission in advance for the next one and, at the end of the current transfer, change only the link in the RAP register .

    In practice, there are a variety of combined circuits, mainly with the aim of saving MK equipment - a pointer to a memory area that contains 2 or more BUPs that cycle through as it is executed, a pointer to the next BUP in the service field of the current BUP, hierarchical access when the BUP contains indications of the sequence of BUP, which are actually executed and so on.

    In the above cases, we will also need a special tag that indicates the completion of all the requested transfers so far, which will be among the service information. Among other service information, there are often tags that indicate the transmission mode (bit depth of the transmitted data, step and direction of changing the addresses of the receiver and sender, information for the memory management module ...).

    Now let's move on from the consideration of the RAP in general to the consideration of a specific implementation, namely, the MK of the Milander 1986VE1T firm.

    Why to him? Well, firstly, I work with him, secondly, he has a sufficiently rich MPD in terms of capabilities, and thirdly, he has rich features (this is not a bug, this feature is such a yes, yes, it’s from this category) that make working with MK is an exciting activity, after which working with analogues from well-known manufacturers will seem easy and simple.

    First, the good news - the PDP supports 32 independent access channels - one for each external device as part of the MK and one for memory-memory transfers. In addition, as you already understood from the previous sentence, the PDP supports all possible forwarding modes, namely: WU-memory registers, WU-registers, WU registers, memory-memory, and if it seems to you that this should be so, then this is completely not so, and different modes function slightly differently and are not always implemented.

    Further, the PDP supports different data formats: 1 byte, 2 bytes and 4 bytes (a word in our architecture), as well as different types of address increment of the source and receiver separately: by 1, by 2 and by 4 (decrement is not supported). The RAP has a system of arbitration of serviced channels with the ability to assign flexible priorities for each channel and a configurable elementary transaction size (the number of transmissions of one channel for which arbitration is performed). In addition, each channel can have up to 2 MCUs, which can be replaced by a cyclic system, or work in a hierarchical mode, and at the same time a single mode is also possible.

    To maintain balance, let’s say about less good. Again about the documentation - if you do not know how the RAP works, then from the documentation of the company you definitely will not know about it. The documentation is clearly translatable, there are translation errors that greatly distort the meaning, there are also very inaudibly described places, but in general it can be enough for a trained developer if you are used to conjecturing for the author. Of the more significant drawbacks (of course, compared with the ideal device) - significant bus resource costs (6 accesses per 1 transfer, although maybe I misunderstood something) and a number of features, about which a little later.

    And here we are waiting for:

    Ambush No. 1 from developers - interruption from the end of the transfer does not appear in external devices. That is, we have one interrupt vector at the end of the transaction from any of the programmed channels. Moreover, there is no register in which the number of the channel that completed the transaction would be stored, or at least a bit register with flags. That is, the only way to determine the number of the channel that completed the transfer is to sort through all the channels and look at the corresponding TCB fields, and we will have to do this in the interrupt handler, which should take a minimum time. The obvious solution - to transfer the channel search to the lower half of the processing driver does not work, because we are expected:

    Ambush No. 2 from the developers - the interruption is potential and we cannot stop the work of the upper half without dropping it explicitly. Moreover, there is also an

    ambush No. 3 from them - we cannot reset the interrupt by manipulating the RAPs, but must reset the permission to generate queries in the registers of the external device. Yes, yes, just like that, the RAP driver must know something about the composition of the registers of serviced devices, it is hard to imagine a more monstrous violation of the encapsulation principle (and it is also true for hardware design). I don’t know what the developers of the RAP were smoking, but, as it is written by Gaiduk, “something very interesting”. That is, you may not believe it, but if we prohibit the passage of requests from the corresponding channel and prohibit its processing, then we will NOT RESET the interruption anyway.
    Something turned out to be more letters than it was planned, so let’s leave readers to reflect on the difficult situation in which the main character of the story finds himself, which is especially true on Friday night, and I’ll write it To be continued ...

    Also popular now: