A few words about "our" microcontroller

The article will discuss the domestic MK company Milandr 1886VEU, there will be quite a bit of code and a lot of whining.



This MC is built on the PIC17 core, which is noticeable when developing - since I already have a solid code base for the PIC, it was a bit easier for me to start. Also under this MC you can purchase a debug board - I will write a few words about it too.



I will tell you what problems I encountered while developing the firmware, what I liked and what did not. Everything written is my personal subjective opinion, therefore, I will immediately make a reservation, perhaps problems will be described that are not problems at all, but even very specific features that could have been avoided if I had a lot of development experience.

')

So let's go.



The first thing that anyone who wants to use in their developments MK from Milandra will face in 2017 will be the difficulties with the purchase. Without even mentioning the price, you will most likely need at least some legal entity for this. At least, when I called them in the marketing department and found out about the purchase as an individual, they made it clear to me that in this case it would be easier for me to find some supplier (prices that are even higher). In general, with marketing everything is sad. On the other hand, they have already updated the site, maybe they will reach their marketing policy somehow.

Clumsy documentation

Despite the fact that 1886VE5U was released at least five years ago, the “childhood diseases” have not gone away. When reading technical documentation, it creates the feeling that they were doing it hastily. No, the critical information is there, in principle, present, except that it is rather strangely structured. There are occasional typos in the text, and, in my opinion, the structure of the document itself does not shine with consistency. As a result, when developing, instead of studying a single document, periodically you have to rush between several open windows or look for the currently needed fragments in the main datasheet, which can be located in the document far enough from each other, even if they belong to a single chip unit.



For example, it is strange that the manual for the firmware of the chip is in a separate document. It may be convenient in some cases, but why not make a separate chapter or annex to the main datasheet?



By way of illustration I will give one example. To calculate the speed of the CAN interface, we are offered to use several formulas.



When calculating it turns out that the final formula, in fact, will have five parameters ( BRP, PRSEG, SEG1, SEG2, Fosc ). The formula itself and the dependence of the parameters on the values ​​of the bits in the registers are separated by fifteen pages. As a result, it is easier to make a screen with a table of register values ​​and open it in the paint while you are working with the formula.



In general, even the approach with formulas is still izwart. A clear formula is, of course, fine, but each time recounting values ​​in the mind or on a piece of paper is something else fun. For example, I finally wrote down the formula in Mathcad and counted it in it.



Question to the compilers of the documentation - actually, what was the problem to add just a couple of pages with tables containing basic values ​​for several values ​​of the parameters? There is no need to go far for an example - even in the PIC documentation there are such tables, for example, in the sections on setting the UART speed.



By the way, I would like to separately note an interesting point, perhaps, it will be useful for someone for the future. I do not consider myself to be a CAN interface expert, it is quite possible that this is true for any CAN device, and not only in this particular case. It is also possible that this feature is inherited from the PIC17, although I could not immediately find the PIC17 with the CAN interface.



In general, if we have two devices on the 1886BVEU, one of which works at 16 MHz (a debugging board, for example), and the second at 10 MHz (our piece of hardware), then we will most likely connect them at a low speed, and it is not a fact. And that's why.



Firstly, the maximum speed (for a piece of hardware operating at 10 MHz) with all the dividers turned off is limited to 390.6 kbit / s.



Secondly, at 10 MHz, the change resolution is such that, for example, standard 250, 125 or 100 kbit / s cannot be obtained. According to calculations, the closest is obtained, for example, 104.2 kbit / s ( BRP=1, PRSEG=1, SEG1=5, SEG2=5 ). In general, an error of a few% will somehow be present. I already wrote above - for the present I am not dofig special in this protocol, it is possible that it will work with such an error at low speeds - in the end, this bus has a very large margin on the reliability of data transfer.



As a result, it turned out to be faster to change the 16 MHz resonator on its board. Anyway, I didn’t have the opportunity to check the work at low speeds, and why - I’ll tell you in the next paragraph.

The inability to edit the source code of the firmware for the debug board

In general, the whole "demo program" for working with a debugging board on a PC (it is called, for some reason, Eval12.exe ) is quite poor. From the settings there are literally only the parameters of the COM port, through which you will be connected with the board, that's all. Well, that is, everything. CAN speed cannot be changed through it. It is also impossible to change the parameters of the MC installed in the debug board, although this is very helpful.



When I ran into the difference in CAN physical speeds and calculated all the possible variants using the formula, I realized that for debugging I would have to change the code of the debug board, because I can set the speed of the CAN module in the current version only in the source code when compiling.



Next, I took the source from the folder Demo_CAN, which was on the disk with the debug card, hoping to just recompile them, setting the necessary BRP, PRSEG, SEG1, SEG2. When trying to compile this project, the IDE produced an excellent error:



" . ."



I didn’t understand the protection mechzyms - it’s obvious that you can use some pieces of code from the demo program and write your own, but the fact that I can’t edit the demo program’s code for the debugging board so much personally surprises me the same absurd.

Mess in header files

I took the folder " komplekt_1886BE5 \ Demo programs " from the disk that came with the debug card.



There were separate folders with source codes of examples of working with CAN and LIN.

At the same time, the following header was included in main.c of these sources:



#include <mil1886BE5_1.h>



Actually, in those examples where it was included, this header was in the examples folder.



Further, following the advice of technical support (taking this opportunity, I want to thank these worthy citizens for their patience and professionalism - they helped me solve a couple of stupid questions) I downloaded IDE (Dev-C ++ some ancient version) and compiler (CC7A) from the site of Milandra.



What was my surprise when the IDE refused to compile my source with the above header. Then it turned out that with the compiler under my chip there is a header - 1886VE5.h



To use pieces of code from the source code of the demo board, we had to spend more time replacing the names of the registers with the values ​​from the new header. After that, I managed to collect my program with parts from the demo examples, which worked as I expected it to.



Probably the examples for the test samples somehow got on the disk, decide whether it is normal or not. In technical support for this question in general, only they were surprised - they say I should not have these header files at all.



In general, the problem is not critical, but the sediment, as they say, remains.

The environment, the compiler and them, ahem ... features

As a medium and compiler for the 1886BE5U, Milander suggests that we use the IDE1886 (based on Dev-C ++) bundle and CC7A. In general, I can’t say anything particularly bad about the environment - it works fine with the programmer, the debugger also seems to debug well, except that the syntax highlighting is sad, of course. Surely there are some plug-ins or something else, but by default it’s almost a Vindus notepad - it highlights the keys, inclusions and some keywords, the editor’s bonuses end there.



From the small shoals of UX - my experience was not enough to figure out how I can add the register I need into the observables. By the name of the variable and address (as described in the manual), the IDE does not add them for some reason. It is strange that the IDE itself cannot display all the registers available for monitoring.



One more thing, of course, rather speaks of my little developer experience, but what was my surprise when, after a few hours of tinkering with the debugger and trying to figure out why, the compiler-generated code works so strangely in the documentation that the int type By default, this compiler has a size of 8 bits, not 16, as is customary in the same XC8 for the PIC.



Therefore, I say banality, but still - carefully study the documentation before developing =)



The next feature of the compiler generally put me in a stupor for a while. It is quite possible, here I will once again demonstrate my low competence - it may be that this compiler is just tuned to some old C standard of the year of the 90th, when this was the norm, but I just don’t know it, or something something like that. In general, in order not to be unfounded, I will give a little code, I hope the community will judge.



The compiler is completely incapable of digesting such a simple construction:

 TXSTA1 = ((CSRC & 0x01) << 7) | ((TX9 & 0x01) << 6) |((TXEN & 0x01) << 5) |((SYNC & 0x01) << 4); 

To this he simply gives out the sacramental: "Unable to generate code."



In order for him to understand what I want from him, I have to paint it with a banal and volume code:

 temp0 = ((CSRC & 0x01) << 7); temp1 = ((TX9 & 0x01) << 6); temp2 = ((TXEN & 0x01) << 5); temp3 = ((SYNC & 0x01) << 4); 

Apparently, he just has a certain level of nesting of brackets, deeper than which he does not even try to parse the code and falls out with an error.



No, well, seriously, I understand that the functionality of the compiler seems to be due to its price, but in 2017 one could already teach him how to disassemble it.

At last

There is another point, probably related to the architecture of the kernel. In the description for the 1886B5U on Milandra’s site, one can find a mention that it is built on the PIC17 core. I understand that this feature is peculiar to all controllers on the PIC17 core - when an interrupt occurs, they do not save the state of the registers, respectively, this point should be implemented programmatically if necessary. Frankly speaking, this also struck me - really, it was impossible to implement this in hardware in 1886 BE5U.



In general, having tried to write for this MC, I was forced to poke around in the assembler code, to figure out what kind of digits are there in the “RAM” window during debugging and so on. It certainly improved my qualifications as a developer, since I began to understand a little better what was inside and how it worked. However, after the same Microchip (which is often scolded for “insane” Errata), coding under “our” MK is felt directly like programming under some 386th in DOS. By the way, about Errata - there is nothing like Errata of this MK at all.



I don’t diminish the dignity of our developers from Milandra - the piece of hardware itself seems to be working right for me, but software support and development environments look as if they are doing everything in a hurry. Returning to the question raised in the heading - comparing IDE1886 with the same MPLAB is by no means in favor of the first. The only advantage of IDE1886 is its compactness and the ability to work without installation, but I don’t think these are critical moments.



I really hope that over the next few years, developers will be able to tighten this figure to the level of leading brands.