A few words about "our" microcontroller

In the article, we will talk about the domestic MK of the company Milander 1886BE5U, there will be very little code and a lot of whining.

This MK is built on the PIC17 core, which is noticeable during development - since I already have a solid code base for PIC, it was a little easier for me to start. You can also purchase a debugging board for this MK - I will also write a few words about it.

I will tell you what problems I encountered while developing the firmware, what I liked and what not. Everything written is my personal subjective opinion, therefore, I’ll make a reservation right away, maybe problems will be described that are not problems at all, but even features that could be avoided if I had a lot of development experience.

So let's go.

The first thing that a person who wants to use MK from Milander in his designs in 2017 will face is the difficulty with buying. Without even mentioning the price, for this you most likely will need at least some legal entity. 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 (whose prices are even higher). In general, everything is sad with marketing. On the other hand, they have already updated the site, maybe their hands will reach the marketing policy somehow.

Clumsy documentation

Despite the fact that at least five years ago, 1886BE5U came out at least, “childhood diseases” did not go away. When reading technical documentation, it feels like they were doing it hastily. No, critically important information is, in principle, present there, only it is structured rather strangely. Typos occasionally appear in the text, and the structure of the document itself, in my opinion, does not shine with consistency. As a result, when developing, instead of studying one single document, you periodically have to rush between several open windows or look for fragments that are currently needed in the main datasheet, which can be located in the document far enough from each other, even if they belong to the same block of the chip.

For example, it’s 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 application to the main datasheet?

I will give one example as an illustration. 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 bit values ​​in the registers are spaced fifteen pages apart. As a result, it’s easier to make a screen with a table of register values ​​and open it in a pint, while you deal with the formula.

In general, even the approach with formulas is one more thing. A clear formula is, of course, wonderful, but every time counting the values ​​in the mind or on a piece of paper is still a pleasure. For example, I, as a result, sawed the formula in Mathcad and considered it already.

The question for the compilers of the documentation is, in fact, what was the problem of adding just a couple of pages with tables containing basic values ​​for several parameter values? You don’t have to go far for an example - even in the PIC documentation there are such tables, for example, in the sections on setting UART speed.

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

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

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

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

As a result, it turned out to be faster to change the 16 MHz resonator on your board. One way or another, I did not have the opportunity to test work at low speeds, and why - I will describe in the next paragraph.

Inability to edit firmware source code for debug board

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

When I came across the difference in physical speeds of CAN and calculated all possible options using the formula, I realized that for debugging I would have to change the code of the debugging board, because you can set the speed of the CAN module in the current version only in the source code during compilation.

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

"Программа защищена. По вопросам приобретения обратитесь в компанию МИЛАНДР."

I did not understand the protection mechanisms - it’s obvious that you can use some pieces of code from a demo program and write your own, but the fact that I can’t just edit the demo code programs for the debug board personally really amaze me, it's absurd.

The mess in the header files

From the disk that came with the debug board, I took the folder " komplekt_1886BE5 \ Program Demo ".

There were separate folders with source codes for working with CAN and LIN.
At the same time, the following header was included in main.c of these sources: 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 most worthy citizens for their patience and professionalism - they helped me solve a couple of stupid questions) I downloaded the IDE (Dev-C ++ from some ancient version) and the compiler (CC7A) from the site of Milandra. Imagine my surprise when the IDE refused to build my source with the header specified above. Then it turned out that with the compiler, my header goes under my chip -

#include





1886VE5.h

In order to use the pieces of code from the source code of the demo board, we still had to spend time replacing the register names with the values ​​from the new header. After which I managed to build my program with parts from demo examples, which worked as I expected from it.

Probably the examples for test samples somehow got to the disk, is it normal or not, decide for yourself. In tech support, they were only surprised at this question - they shouldn't have these header files at all.

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

Environment, compiler and them, ahem ... features

As an environment and compiler for 1886BE5U, Milander offers us to use a bunch of IDE1886 (based on Dev-C ++) and CC7A. In general, I can’t say anything really bad about the environment - it works fine with the programmer, the debugger also seems to be pretty decent debugging, except that the syntax highlighting is sad, of course. Surely there are some plugins or something else, but by default it’s almost like a Windows notebook — it highlights comments, inclusions and some keywords, the editor’s bonuses end here.

Of the small jambs of UX, my experience was not enough to figure out how can I add the register I need to the observables. For the variable name 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 observation.

Another point, of course, speaks more about my little experience as a developer, but what was my surprise when, after several hours of picking the debugger and trying to figure out why the assembler code generated by the compiler works so strange, I read in the documentation that the type intof by default, this compiler has a size of 8 bits, not 16, as is customary in the same XC8 for PIC.

Therefore, I will say banality, but nevertheless - carefully study the documentation before development =)

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 - maybe the fact is that this compiler is just sharpened by some old C standard of the year 90, when it was the norm, but I just don’t know that, or whatever 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 absolutely 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."

So that he understands what I want from him, I have to paint it in a banal and voluminous 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 compiler’s functionality is apparently due to its price, but already in 2017, you could somehow teach him how to disassemble it.

In the end

There is another point, probably related to the architecture of the kernel. In the description for 1886BE5U on the site of Milander, you can find a mention that it is built on the PIC17 core. I understand that this feature is common to all controllers on the PIC17 core - when an interrupt occurs, they do not save the state of the registers, respectively, this moment must be implemented programmatically if necessary. Frankly speaking, this struck me as well - was it really impossible to implement this in hardware in 1886BE5U?

In general, when I tried to write for this MK, I was forced to poke around in assembler code, to figure out what kind of digits they were in the “RAM” window during debugging and so on. This, of course, improved my qualifications as a developer, as I began to understand a little better what is inside and how it works. However, after the same Microchip (which is often blamed for the "crazy" Errata), coding for "our" MK feels just like programming for some kind of 386th in DOS. By the way, regarding Errata - there is nothing like Errata to this MK.

I don’t detract from the dignity of our developers from Milandra - the piece of iron seems to have gotten working fine for me and it works, but here the support for the software and development environment looks like they are doing everything in a hurry. Returning to the question raised in the title - comparing IDE1886 with the same MPLAB is not in favor of the first. The only advantage of IDE1886 is its compactness and the ability to work without installation, but I do not think these are such critical moments.

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