An experimental rabbit, or one of the domestic production MK
Not everything is as bad as it could be, but not as good as we would like.
Before starting to consider the implementation of the drivers of various devices in MK, I would like to decide on the object on which we will implement the aforementioned implementation. Of course, you can consider a spherical MK in a vacuum, but in this case, any inconvenience leading to the features of the implementation of the program will be considered as something artificially created. If we take it as a basic ideal MK (if I knew how to create them, I would probably do it for a long time), then for him writing any program does not present any difficulty at all and comes down to two commands: 1) understand the thoughts of the developer and 2) do it. Therefore, some real MK as a basic one is highly desirable, and how far it is from ideal will become a measure of the value of the developed software (since it works steadily on this MK,
So, we begin to choose the applicant. Most likely, the ARM architecture will not cause any special objections (supporters of PIKs, as well as MIPSs and so on, be silent!), Since this architecture is widespread and implemented in a huge number of MCs of various companies. Since this is still about MK, and not about SoC, we restrict ourselves to the level of Cortex-M. Since I personally do not see much difference between M0, M1, M3 and M4 (of course it is and I see it, but it is not essential for our purposes), we can choose any and therefore choose the simplest one (from the considerations discussed above) , namely M1. And here we are waiting for a small ambush, namely: the M1 version is adapted to build MK as part of the FPGA, so a separate crystal with such an implementation is not easy to find. Fortunately, it does exist, and we can quite reasonably choose an MK type 1986BE1T manufactured by Milander. This is precisely what the engineer’s art consists of: competently substantiating and proving the inevitability of a decision that has already been made due to various (including subjective) factors. In fact, with this MK I’ve been already half a year
So, what kind of MK we chose as an experimental rabbit - the usual Cortex-M, which are a dime a dozen (for anyone interested, see its specifications on the manufacturer’s website, Google to help you), if not for some interesting features, namely:
1. The core M1 is not often found in ready-made solutions, but it does not create any special problems, its differences from M0 are not so significant as to complicate software development (score 0).
2. The claimed frequency of 144 MHz exceeds the characteristic values for MK of this class, but there are features, which will be discussed later (+1).
3. The amount of program memory of 128 KB and data memory of 48 KB are typical for medium models in the MK families, and here is one representative (+1).
4. There is a wide (32 bits of address and 32 bits of data) fast configurable interface to external memory, which is also a rarity (+1).
5. Battery domain with RTC and NVRAM - not bad at all, if not ... see below (+1).
6. The controller of direct access to memory - also not always available - is not bad at all if ... (+1).
7. ADCx8, DACx2, timerx4, temperature sensor, SSIx3, UARTx2 - more or less standard set (0).
8. USB FS Host / device with PHY - not bad, but not unique (0).
9. CANx2, GOST 18997, GOST 52070x2 - not bad, but for an amateur (+1)
10. Ethernet 10/100 MAC - not bad plus PHY in a chip - but this is a rarity (+1)
11. Debugging by JTAG and SWD is standard (0).
12. The temperature range is -60 +125 degrees - honest Military with a bias in Aerospace (+1).
I hope everyone understands that there are no free cakes, and it is the last of the parameters (more precisely, the ceramic-metal case necessary for its provision) that has 2 significant drawbacks - the high price and problems with leg formation and trimming during installation. Those who are interested can specify the pricing policy from the manufacturer, I will only give landmarks in rubles - military acceptance 8000+, just metal ceramics 6000+, although (cheers) now there is a version in plastic 400+. There is a development board for the development of Milander itself, but its price (60k +) may unpleasantly surprise a developer accustomed to inexpensive boards by a Western manufacturer. Summing up the hardware, we have a completely worthy, even competitive development, for a certain group of applications (those who know will understand) have practically no competitors. This ends with a barrel of honey and move on to
What we will have in this part of the description:
1. Documentation - recognition of a seemingly obvious fact is not easy for me, but, I agree, it still exists. I think readers immediately understood my attitude to this part of the development. Dear colleagues from the company Milander, you can’t do this. Documentation in general, and especially for such a specific product as MK, is not something that can be done on a residual basis, but an integral part of development. Yes, the company has a forum on which a lot of useful things are laid out and questions are often promptly answered. Yes, the company has a competent support service and always promptly answers questions. But all this does not replace error-free, comprehensive and understandable documentation and is in no way an alternative to it, just like crutches do not replace legs (they certainly allow you to move around, but I would not call this process convenient). At the risk of offending someone, nevertheless, I will say that the description (specification) of MK is sometimes inaudible, incomplete, contains errors and numerous omissions, moreover on those issues that are of particular interest in connection with their uniqueness. If you (I refer to possible MK users) do not know thoroughly the architecture of similar MKs, it will be very difficult for you, since many places in the description have to be thought out for the authors, based on existing experience. Fortunately, both the architecture of MK itself and its individual nodes are licensed by ARM or coincide with AVR counterparts, so you can see the original documentation and much will become clear (-1) If you (I refer to possible MK users) do not know thoroughly the architecture of similar MKs, it will be very difficult for you, since many places in the description have to be thought out for the authors, based on existing experience. Fortunately, both the architecture of MK itself and its individual nodes are licensed by ARM or coincide with AVR counterparts, so you can see the original documentation and much will become clear (-1) If you (I refer to possible MK users) do not know thoroughly the architecture of similar MKs, it will be very difficult for you, since many places in the description have to be thought out for the authors, based on existing experience. Fortunately, both the architecture of MK itself and its individual nodes are licensed by ARM or coincide with AVR counterparts, so you can see the original documentation and much will become clear (-1)
2. What we are all used to for a long time (again, corrupted by Western manufacturers), namely, recommendations for use, and so, they simply do not exist. I'm not talking about any documents explaining the features of the application, but about the simplest things, such as connecting power and setting operating modes. Information about this is partially scattered throughout the text of the specification on MK, and partially is simply not available. You can download the circuit board for debugging and look there (developers often do this), and thank you very much for its presence, but why not make separate AppNotes, it seems to me that TI class companies are not in vain creating them (-1).
3. What we can’t do without (well, I definitely won’t) - the development environment of the programs - there is an offset. You can use both Keil and IAR (which I do) and Eclipse and Fiton (see the comments below), probably, something else, the forum has settings for programming environments that allow you to work (again, not without glitches, but fixable ) The only caveat - again, there is no document such as Getting Started, where all the configuration steps would be clearly stated (0).
4. What you can do without (but what a devil we can do without it) are standard libraries and sample applications. The question is not simple - on the one hand, on the forum you can find examples of accessing the registers of external MK devices, both in the form of separate files and in the form of ready-made projects for the environment, written both in Milan and in Fiton. And although the project settings could be made more accurate, after a minimal correction everything works, and after a small correction it works well. Sources of rather significant functional projects and examples of device implementations are provided. Yes, all this is, but ... if you take some book on C programming standards for embedded systems (of course, English-speaking, well, our narrow market for developers is not interesting for domestic publishers), then the above texts can be added to this book under the slogan "How not to write programs for the sun or find 12 errors." I got the feeling (undoubtedly wrong, but it can be hit) that the authors of the software read the book and consciously ignore its recommendations. By the way, after getting acquainted with this library, I had doubts about the development environment from the same Fiton company. But, on the other hand, all colors taste different and, perhaps, such a style is not so bad in itself, I’m just used to something else. Nevertheless, the presented projects are compiled and work (by the principle - this is not a bug, it’s such a feature) and, if you don’t go into the implementation details (and often there isn’t time for this, the product was needed yesterday, efficiency issues are fading into the background and stay there forever)
To summarize to a thoughtful reader, I have outlined the main ones (briefly, 40 minutes, more, I think, not necessary), in my opinion, the pros and cons of using this MK in your developments. As for me, I’m