January 17, 2016 at 19:13New domestic motor-control microcontroller K1921VK01T of OJSC NIIET
Somehow the news about the appearance of the new K1921VK01T microcontroller of NIIET OJSC passed by . How is it remarkable? Its peripherals designed to control electric motors (motorcontrol). This is not just a couple of PWM channels. These are nine sophisticated two-channel PWM modules (PWM), of which three are modules (HRPWM) with a “high” resolution mode. These are six separate 32-bit CAP capture modules. Twenty-four (!) Channels of 12-bit ADCs with a flexible launch manager, built-in averager and digital comparators. Two quadrature decoders (QEP), a bunch of communication interfaces, internal user memory, clocks - all this is based on the ARM Cortex-M4F core with a megabyte of on-board flash memory and a performance of 100 MIPS! Interesting?
Actually, in order not to list all the technical characteristics of the product in the article, I am sending it to the page of the manufacturer ’s website . There is both a short list and a full datasheet (though it is always hidden in different corners of the site and at the time of writing, you can download it ... from the table of current developments ). And in the article I’ll better tell you something that is not written in datasheets.
A bit from the history of creation
Work on the microcontroller (hereinafter referred to as MK) began in 2012 by the company NPP Digital Solutions, by order of NIIET OJSC(Voronezh.). Licenses were acquired for the ARM Cortex-M4F core and some communication peripheral modules, and some of the modules were developed by this company independently: PWM modules, an ADC controller (not the ADC itself, but a manager for managing it), a CAP capture module, and a QEP quadrature decoder module. NPP Digital Solutions first produced a microcontroller mockup on the Kintex7 FPGA, which implemented all the logic of the future microcontroller, including the ARM core. But FPGA is a freely reprogrammable product that allows you to correct errors in MK logic if they are detected after passing tests (this is in addition to testing on a simulator). But how to test a motorcontrol microcontroller? In addition to synthetic tests, of course, on the real task of controlling an electric motor! For this, NPP "Digital Solutions" turned to us - inNPF Vector LLC , since we have very extensive experience in the field of electric drives based on MK Texas Instruments
While NPP “Digital Solutions” developed the internal logic of the modules, we at NPF Vector made a stand for testing the future microcontroller. It was a small frequency converter with six transistors (“servo amplifier”), which was connected by control circuits to the prototype microcontroller on the FPGA, and the power part was connected to a small servomotor with Hall position sensors (for checking the CAP module) and a quadrature position sensor (for checking the QEP module ) Our goal was this: to write software for the microcontroller to ensure full vector control of the electric motor using any position sensor of your choice or both at once. And, of course, to report all the problems found in the periphery to “Digital Solutions”.
Despite many of MK’s own tests at Digital Solutions, many errors were found during tests on a live electric motor. Basically, they were associated with an inaccurate implementation of the internal block logic, which was not explicitly described in Texas Instruments datasheets. For example, what should the PWM module produce if the comparison setpoint is set above the timer period? Or if an input signal divider is turned on for a quadrature decoder, should the module detect a change in the direction of rotation by a divided signal or by the original input? The answers to these questions may be obvious to the electric drive, but not obvious to the architect of the microcontroller logic. As far as we could, we caught similar bugs together with Digital Solutions. The drive has successfully worked in vector control without any problems. However, of course, we could not cover all the bugs with such testing - for sure in other tasks the errors will start to come out again. But for this, there is errata and new revisions of microcontrollers: to fix bugs, you must first collect them. After debugging the MK logic on the FPGA with "Digital Solutions", the "wiring" of the MK (or whatever) was doneis it called microcontrollers? Topology?), After which all the results of the work were transferred to NIIET. By the way, we have already found several errors after the release of MK in the "stone", but NIIET considered them critical enough to change the MK layout: they accumulate more - they will fix it.
Title
I must also say that the microcontroller survived several names. At first, during development, it had the code name “MS01”, then the experimental batch of stones was called NT32M4F1, and then it became K1921VK01T (moreover, in some places the letters are written in Russian, in other English letters). Therefore, if you see these names in early articles and publications on this MK, do not be surprised.
How expensive?
Currently (at the beginning of 2016), the NIIET is ready to sell the first batch of microcontrollers, which has already begun to arrive at customers. The crystals are encased partly in plastic, partly in ceramic (so that in critical applications it doesn’t work out how you yourself_you know_what_) The price of a stone in plastic at the end of 2015, it seems, was slightly less than 3 tr, which is higher than the price of TI TMS320F28335 when buying in Russia (at the time of writing, the coefficient for converting “their” prices to “ours” was 76). However, in TMS320F28335 there is no user memory and hours, you need to set the external ones, because of which the cost in the end becomes comparable. This makes K1921VK01T promising not only in terms of import substitution, but also for simple “mercantile interests”. Although this comparison, of course, is not entirely correct - you can find a bunch of examples of cheaper crystals on the Cortex-M4F and with a higher clock frequency, but with less peripherals. Therefore, for simple tasks, the K1921VK01T will be excessively large and expensive. But for the main application (control of electric motors and complex power electronics) - it is competitive.
What do we have with performance?
We made a presentation at the exhibition about this a year ago, the presentation can be found here. Our tests, of course, do not pretend to be particularly accurate - after all, we didn’t run real benchmarks, but “rolled up” the same vector control system into the test (and what else can excite electric drives?). But the brief retelling of the presentation is this: the ARM Cortex-M4F architecture lags behind the C28 TI core DSP in the average calculations required for drive tasks. If you reduce the accuracy of the calculations, where possible, using approximated trigonometric functions and so on, you can reduce this gap to about 15%. But at the same time, the clock frequency of the top C28 cores (the same TMS320F28335) is 150 MHz, and the frequency of K1921VK01T is 100 MHz. Therefore, with all the library optimizations, the K1921VK01T is equivalent in computing power somewhere to the TI piccolo MK series with a frequency of 90 MHz. What can be interpreted as ... very good, in our opinion, because if you correctly use all the hardware bells and whistles of the new MK like DMA and self-filtering ADC measurements, you can save a lot on clock cycles. One way or another, we managed to “cram” in K1921VK01T our most demanding project for performance, based on the TMS320F2810 (150MHz, C28 core), which already crashes into this same 2810.
What do we have with development tools?
And what could be wrong with them, it's ARM! Normal, without any buts. Take any JTAG, any development environment, but ... no, after all, any will not work. “But” is the flash memory firmware. Despite the fact that the ARM core itself is standardized and any JTAG and environment will connect to K1921VK01T, it is not so simple with flash firmware. It seems that each manufacturer of microcontrollers considers it their duty to make their own registers for working with the firmware of their flash memory, so the creators of development tools are tormented with the support of all this zoo. K1921VK01T is not far behind in this regard either - there are also methods of working with flash there. But if for famous manufacturers flash memory programmers (driver, flasher or what should I call it?) In development environments are written and work “out of the box”, then for K1921VK01T everything works only for those environments for which programmers wrote at NIIET. Fortunately, everything is ready for IAR and Keil and examples of projects with firmware instructions can be found onNIIET forum , as well as in the open repository on Bitbucket , which is maintained by NIIET. In addition, we at NPF Vector wrote support for programming flash K1921VK01T for OpenOCD(Open On-Chip Debugger). This is such a layer between the GDB debugger and the iron in the form of different JTAG emulators and different stones. But while we were pulling the “code review” in the OpenOCD repository with conflict resolution, the NIIET developers wrote the same thing, but theirs was better (they also added the user’s burning function besides burning the main flash memory), but ... this is all the lyrics. What does this OpenOCD give? This is a kind of iron abstraction layer, which allows you to create your own free and free development environment for K1921VK01T based on any popular IDE. We at Eve love Eclipse (because the TI Code Composer Studio environment, based on v4, is based on it, we are used to it
Oh yes. There is something else. It is called Codemaster ++ [ARM] . This is a 100% domestic development environment, including compilers, and also designed for K1921VK01T. We examined its first versions a year ago, but found that it was not ready yet, a little in terms of compilers and a lot in terms of ease of code editing (although in this it can compete with the IAR, who knows what I mean). But it’s small and fast, and on the interface it resembles some kind of “hacker” debugger like OllyDbg (compare: one and two ). In general, perhaps someone will be interested. I must say that the developers (company“Fiton” ) tried very hard, even requested at one time our benchmark a la “vector engine control” in order to optimize its compilers.
What do we have with debugging kits?
At the beginning of 2016, four debug boards on K1921VK01T are known in nature. This is our VectorCARD K1921BK01T and others ... from competitors. Ok, so be it, here are the links LDM-HELPER-K1921BK01T and MBS-K1921VK01T . It also seems that the NIIET itself has its own board NIIET_1921BK01T, but on their site, apparently, it is hiding from me - if someone finds a link, I will gladly complete the article. What is the difference between them? We do not sell a bare board, but a kit with an inverter, electric motor, vector control in C source codes (based on what we wrote at the time for Digital Solutions), as well as with a top-level program and CANopen driver for monitoring all processes inside the drive - see our first article. Therefore, if you just want to play with the new MK, blinking an LED or sending data via any communication interface, then it’s best to buy competitor debug boards (although we also have a bare board option for 15 tr, but it’s completely “bare” - some conclusions). However, if you want to create an electric drive on the new MK, then our debugging kit and software can save you half a year or a year of development time (or maybe more, depending on whether you know the theory of the electric drive and whether you have your own debugging and oscilloscope tools similar to ours). If you carefully read the first article, then, probably, remember that debugging a control system for an electric drive without means of visualizing the processes inside is impossible. And if at Texas Instruments the development environment is able to show “out of the box” oscillograms based on the data of the memory array of MK, for ARM in universal development environments (not from a specific manufacturer of MK) such a function is not yet observed (if the developers of Fiton read this - Would you like to modify your Codemaster ++ [ARM] with the oscilloscope builder? It's easy to do it!). In our debugging kit, such means of visualizing waveforms are present, so you can immediately see everything that is supposed to control electric motors: the form of phase currents, voltages, inputs / outputs of all regulators, etc. The price of our kit is large, approximately 130 tr. (only one electric motor with all position sensors currently costs about 30 tr). But for an organization wishing to learn a new product, this should not be critical - a commercial development environment for ARM alone can cost more.
Disadvantages of K1921VK01T
What are the main disadvantages of the new K1921VK01T can be noted now?
• Firstly, this is undoubtedly a crude product, since it was really programmed so far by 10-20 people. When more developers are seated on it, bugs will be detected - new revisions will be released. So get ready. But, nevertheless, they can twist the engines - twisted personally.
• At the moment, the documentation is also damp. There are few errors, but some things are explained ... it is not entirely clear. One could paint a little more detail, give examples. I think over time it will be finalized.
• The microcontroller is very large and sophisticated. This is for someone a plus, for someone a minus. Very few applications cover the full range of its capabilities. NIIET is already thinking about a series of MK based on it, with different buildings and a set of peripherals. But for now - there is only K1921VK01T.
• He has a specific ADC. Often, MK manufacturers install one fast (12 MS / s) ADC module and multiplex it through several channels - for example, this was done by Texas Instruments in the C2000 series. But K1921VK01T has 12 two-channel slow (1.7MS / s) ADC modules operating in parallel. Why is it bad besides the inability to measure something very quickly? If there is one ADC in the MK, then on the controller board you can send calibrated reference signals, say 1V and 2V, to two unused channels, and use them to calculate and compensate for the multiplicative error and the offset error of this one ADC, extending the correction to all channels (the ADC is one ) When there are a lot of ADCs in MK, such a trick will not work - they will all have their own personal errors. We used the calibration trick on the Texas Instruments MK type TMS320F2810 (this is described in the datasheet and recommended), here in K1921VK01T without calibration, we got a lower accuracy of the ADC compared to the calibrated TMS320F2810. We had to make a special stand for calibrating each K1921VK01T ADC module independently and stitch the calibration table in the built-in user memory. Then the accuracy of analog measurements turned out to be comparable (calibration almost does not float away from temperature - it was checked). Probably, NIIET should flash such a table at the factory, it would be convenient. But while the flash is empty. Then the accuracy of analog measurements turned out to be comparable (calibration almost does not float away from temperature - it was checked). Probably, NIIET should flash such a table at the factory, it would be convenient. But while the flash is empty. Then the accuracy of analog measurements turned out to be comparable (calibration almost does not float away from temperature - it was checked). Probably, NIIET should flash such a table at the factory, it would be convenient. But while the flash is empty.
• The frequency of 100 MHz is, of course, rather low, I would like it faster. But that is, that is. Although in some places they write the frequency of 125 MHz - it all depends on the ambient temperature. "Digital Solutions" reported such unofficial information: inside the crystal is designed for a maximum of 125 degrees. Its temperature is about 15 degrees higher than the environment. According to the project K1921VK01T should work at 85 degrees of the environment + reserve, which is guaranteed to be achieved at 100 MHz. In fact, MK can be accelerated above 100 MHz, individual samples worked at 140-170 MHz, but it depends on the sample. Therefore, if the crystal is not overheated, then it can be dispersed, if someone needs it. But if in your application it is hot (+85), then it is better not to bully above 100 MHz.
• There is no official bootloader (programmer) through communication interfaces (CAN, RS). Sewing MK is possible only through JTAG / SWD. Accordingly, if the product controller is in a closed case, then you need to write your bootloader for the desired communication interface. Or wait until NIIET writes. So far, no, but, I think, will appear.
Conclusion
Although what else is the conclusion? It's only the beginning! Finally, there is a domestic microcontroller on which you can really make an electric drive! Prior to this, all existing domestic MKs were either weak by the core or weak by the periphery in order to cope with the tasks of motorcontrol. But now - complete freedom for the most complex control structures and the most complex power unit. I would especially like to note the prospects of this microcontroller for machine servo drives. Until now, in Russia it was not possible to manufacture a fully domestic multi-axis precision machine, since (one of the reasons) there was nothing to make a high-quality servo drive on. Now there is such a microcontroller.