Guinea pig, or one of the domestic production of MK

Not everything is as bad as it could be, but not as good as we would like.

Before proceeding with the consideration of the implementation of various device drivers in the MK, I would like to decide on the object on which we will implement the above implementation. Of course, you can consider spherical MK in a vacuum, but in this case, any inconvenience that leads to the features of the program, will be considered as something artificially created. If we take the ideal MK as a base (if I could create them, then I probably would have done it a long time ago), then writing a program doesn’t pose any difficulty at all and comes down to two commands: 1) understand the developer’s thoughts and 2) do it. Therefore, some kind of real MK as a base is highly desirable, and how far it is from the ideal will become a measure of the value of the developed software (since it works steadily on this MK, transfer it to any more advanced easy - strong statement, but accept it without proof of).

So, we start to choose the applicant. Most likely, the ARM architecture will not cause any special objections (supporters of PIKs, as well as MIPS and so on, be silent!), Since this architecture is widely distributed and implemented in an enormous number of MCs from various companies. Since this is still about the MK, and not about the SoC, we limit 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 for our purposes it is not essential), you can choose any one and therefore choose the simplest (from the considerations discussed above) , namely M1. And here we are waiting for a small ambush, namely: the M1 version is adapted to build the 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 the MK type 19861 manufactured by Milandr. It is precisely in this that the art of the engineer consists of correctly 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 have been dancing with a tambourine for half a year, and it was not me who chose it, and only because it complied with the requirements for operating conditions. Nevertheless, it is quite possible to show at this MK the places where the rakes are the most popular among the developers of embedded software, well, and hint about the existence of ways to circumvent them (and whether to use these recommendations, everyone decides for himself). In the end, life is so short that it is barely enough to make the required number of mistakes, and even to repeat them is an unaffordable luxury. Immediately I will answer those who suspected the tone of the order in this post and offer to transfer it - first finish reading, there will be a lot of things that are unlikely to be attributed to advertising.
So, what kind of MK we chose as a guinea pig - the usual Cortex-M, which are a dime a dozen (who are interested, see its specifications on the manufacturer's website, GUGL help you) if it were not for some interesting features, namely:
1. The M1 core is rarely 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 (assessment 0).
2. The stated frequency of 144 MHz exceeds the characteristic values ​​for MCs of this class, but there are features, about which later (+1).
3. The amount of program memory in 128 KB and data memory in 48 KB are typical for medium-sized models in the MK families, and here there 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. The battery domain with RTC and NVRAM is not bad at all, if not ... look further (+1).
6. The controller of direct memory access is also not always available - 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 crystal - and this is a rarity (+1)
11. Debugging on JTAG and SWD - standard (0).
12. Temperature range -60 +125 degrees - honest Military c slope in Aerospace (+1).
I hope everyone understands that there are no free pastries and it is the last of the parameters (more precisely, the ceramic-metal case necessary for its provision) has 2 significant drawbacks - the high price and problems with the formation of legs and trimming during installation. Those interested in pricing can check with the manufacturer, I will give only guidelines in rubles - military acceptance 8000+, just metal ceramics 6000+, although (hurray) now there is a version in plastic 400+. There is a development debugging board for Milandr himself, but its price (60k +) may unpleasantly surprise a developer accustomed by a western manufacturer to inexpensive boards. Summing up the results for hardware, we have quite a decent, even competitive development, for a certain group of applications (those who know will understand) with virtually no competitors. At the end we will end up with a barrel of honey and move on to the barrel of a fly in the ointment to justify the promised statements about the non-customized nature of the post.
What we will have in this part of the description:
1. Documentation - it is not easy for me to acknowledge the seemingly obvious fact, but, I agree, it still exists. I think the readers immediately understood my attitude to this part of the development. Dear colleagues from the company Milander, you can not do this. Documentation in general, and in particular for such a specific product as MK, is not something that can be done on a residual basis, but an integral part of the development. Yes, the company has a forum in which many useful things are laid out and questions are often answered promptly. Yes, the company has a competent support service and always answer questions promptly. But all this does not replace error-free, comprehensive and understandable documentation and is by no means an alternative to it, as crutches do not replace legs (they certainly allow you to move, but I would not call this process convenient). At the risk of offending someone, nonetheless I will say - the description (specification) of the MC in places is vague, incomplete, contains errors and numerous omissions, and just on those issues that are of particular interest due to their uniqueness. If you (I appeal to possible users of the MK) 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 of for the authors, based on experience. Fortunately, both the architecture of the MK itself and its individual nodes are licensed from ARM or coincide with AVR counterparts, so you can see the original documentation and much will become clear (-1)
2. What we are all accustomed to for a long time (again, corrupted by Western manufacturers), namely, recommendations for use, 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 the power supply and setting the modes of operation. Information about this is partially scattered in the text of the specification on the MK, and partly simply missing. You can download the debugging circuitry and see there (the developers do this so often), and thank you very much for its availability, but why not make separate AppNotes, it seems to me that firms of the TI class don't create them in vain (-1).
3. That, without which we cannot do (well, I definitely can not) is the development environment for the programs — here is the test. You can use Keil and IAR (which I do) and Eclipse and Fiton (see comments below), probably something else, the forum has settings for programming environments that allow you to work (again, not without glitches, but everything is fixable ). The only note is, again, there is no document of the Getting Started type, where all the configuration steps would be clearly defined (0).
4. That, without which you can do, (but, what the devil, we will do without it) - standard libraries and sample applications. A difficult question - on the one hand, on the forum, you can find examples of accessing the registers of external devices of the MK, both in the form of separate files and in the form of finished projects for the environment, written both in Milandra and in the company Fiton. And although the settings of the projects could be done more carefully, after the minimum correction everything works, and after a small correction it works well. Source codes are provided with pretty significant projects and examples of device implementation. Yes, all this is there, but ... if you take any book on C programming standards for embedded systems (naturally, English-language, well, our narrow market of 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 something can be said) that the authors of the software have read the book and consciously ignore its recommendations. By the way, after exploring this library, I had doubts about the development environment from the same company Fiton. But, on the other hand, the taste of all colors is different and, perhaps, in itself, this style is not so bad, I just got used to something else. Nevertheless, the submitted projects compile and work (according to the principle, this is not a bug, this is a feature of this kind) and, if you don’t go into the implementation details (and there’s often no time, the product was needed yesterday, efficiency issues fade into the background and remain there forever), can be used as a basis for the developer’s own projects (0).
To summarize the thoughtful reader, I outlined the main (briefly, 40 minutes, more, I think it is not necessary), in my opinion, for and against the use of this MC in your developments. As for me, I basically figured out this MK, which means that you can, because personally, despite all the drawbacks, I work with him and therefore I will demonstrate all further examples of software implementation for MK on it (this is how I’m harmful ), thereby promoting its use, so probably all the same post can be considered as advertising. And as for criticism, do not be offended, it’s just a shame that by creating a good (well, really good) product, the developer narrows the area of ​​its possible use to ghetto sizes by insufficient attention to its progress (and competitors are not asleep). Let me remind you once again - while we are sleeping, ALENIs are swinging.