Oberon in UAV programming
Good day to all.
Oberon articles often mention the use of Oberon in programming satellites, hydroelectric power stations, nuclear power plants, and so on. Severe industrial software systems. Of course, I would like to have real code examples for each case, but this is not always possible, and therefore it seems that there are no products like that. To correct this situation today I would like to talk about programming UAVs on Oberon.
Since I never worked with a UAV myself, and used a microcontroller to use LEDs for flashing only (with the help of Oberon, of course), I asked to tell about my work an active participant in the Oberon developer community in Russia. His name is Alexander.
Further in the text A. - Alexander, O. - oberon87
')
O .: A few words about your work.
A .: I work in a company that develops unmanned aerial vehicles, and I write programs for automatic aircraft control systems. Aircraft are used mainly for aerial photography.
O .: Why is Oberon, because there are a lot of microcontrollers and languages on the market (mostly C)?
A .: The reliability of onboard programs is important to us.
Programs of early automatic control systems (in the 2000s and earlier) were run on MCS 51 microcontrollers and were written in the Pascal and Assembler programming languages using the EmbeddedPascal compiler. The MCS 51 at the time was chosen because of its popularity.
But gradually the resources of the microcontroller began to be missed, the compiler contained errors (which were avoided using assembler) due to the complexity of the MCS 51 architecture, new microcontrollers and the Astrobe compiler appeared, and since 2010 we began to write programs in the Oberon programming language under the NXP LPC2000 microcontrollers. <...> Another difference from the previous system is that the new one is based on the use of cheaper and more compact sensors, which were not there before.
The ARM architecture is simpler than MCS 51, and the Oberon programming language is simpler than Pascal, but still there were errors in the Astrobe compiler implementation that were gradually found and corrected.
In fact, I do not even use all the features of the Oberon language - I do not use dynamic memory and garbage collection.
I also do not like the syntax of C.
O .: What did you use, how did you write the code in oberon, how easy / difficult is it?
A .: As I already wrote, the reliability of onboard programs is important to us. Using a simple programming language helps to write reliable programs. Oberon is just as it is, it was conceived. The compiler must also be reliable. That is, if possible, too simple. In order for the compiler to be simple, there must be a simple programming language and a target architecture. This architecture is RISC.
In 2014, I wrote my Oberon compiler for modern microcontrollers with the ARMv7-M architecture (Cortex-M4F) based on the Oberon-> RISC compiler from Project Oberon Niklaus Wirth, and the program for the new automatic control system was written using it.
The compiler was easy to write because it was already written (and because it contains the correct separation of functions into frontend and backend), and I just had to rewrite the background compiler (code generator) and write the linker. And since the programming language is simple and the architecture of ARMm7-M is simple, it did not take long. In order to write a compiler, I only needed to study the architecture of ARMv7-M and some features of modern microcontrollers (STM32 and LPC) for writing a linker.
When writing system modules for microcontrollers NXP used User Manual, for STM32 - Reference Manual and datasheet. I liked the NXP documentation more than the ST Microelectronics. To understand the ambiguous places in the Reference Manual, I had to look at the sources of Keil libraries.
When I wrote the compiler, I myself made a few mistakes, but I quickly found them and corrected them as I wrote the autopilot program, which I immediately experienced on a software-hardware model. One error due to carelessness (indicated the wrong register as a parameter when generating one of the instructions), two due to the fact that I had to optimize one place, and this change required a change in the code generator elsewhere, but I did not immediately guess . And two more three errors were found in the original compiler (one was probably made due to inattention, the other two were of the same type).
After I wrote the compiler, I also had to write basic system modules to support microcontrollers — to configure the kernel (PLL) and to work with the peripherals. It was also easy to do.
O .: Can you give an example code?
A .: I did not find anything that can be cited as an example. Well, here is a simple integer implementation of the low-pass filter:
O .: Thanks for the info.
As you can see from the interview, in order to start working with Oberon and increase the reliability of their products, you do not need anything but desire. Each stage of development is so simple that there is nothing to even write about it.
Drink carrot juice!
Use Oberon for microcontrollers!
PS and do not forget to visit the site of the Russian Oberon community for more information.
Oberon articles often mention the use of Oberon in programming satellites, hydroelectric power stations, nuclear power plants, and so on. Severe industrial software systems. Of course, I would like to have real code examples for each case, but this is not always possible, and therefore it seems that there are no products like that. To correct this situation today I would like to talk about programming UAVs on Oberon.
Since I never worked with a UAV myself, and used a microcontroller to use LEDs for flashing only (with the help of Oberon, of course), I asked to tell about my work an active participant in the Oberon developer community in Russia. His name is Alexander.
Further in the text A. - Alexander, O. - oberon87
')
O .: A few words about your work.
A .: I work in a company that develops unmanned aerial vehicles, and I write programs for automatic aircraft control systems. Aircraft are used mainly for aerial photography.
O .: Why is Oberon, because there are a lot of microcontrollers and languages on the market (mostly C)?
A .: The reliability of onboard programs is important to us.
Programs of early automatic control systems (in the 2000s and earlier) were run on MCS 51 microcontrollers and were written in the Pascal and Assembler programming languages using the EmbeddedPascal compiler. The MCS 51 at the time was chosen because of its popularity.
But gradually the resources of the microcontroller began to be missed, the compiler contained errors (which were avoided using assembler) due to the complexity of the MCS 51 architecture, new microcontrollers and the Astrobe compiler appeared, and since 2010 we began to write programs in the Oberon programming language under the NXP LPC2000 microcontrollers. <...> Another difference from the previous system is that the new one is based on the use of cheaper and more compact sensors, which were not there before.
The ARM architecture is simpler than MCS 51, and the Oberon programming language is simpler than Pascal, but still there were errors in the Astrobe compiler implementation that were gradually found and corrected.
In fact, I do not even use all the features of the Oberon language - I do not use dynamic memory and garbage collection.
I also do not like the syntax of C.
O .: What did you use, how did you write the code in oberon, how easy / difficult is it?
A .: As I already wrote, the reliability of onboard programs is important to us. Using a simple programming language helps to write reliable programs. Oberon is just as it is, it was conceived. The compiler must also be reliable. That is, if possible, too simple. In order for the compiler to be simple, there must be a simple programming language and a target architecture. This architecture is RISC.
In 2014, I wrote my Oberon compiler for modern microcontrollers with the ARMv7-M architecture (Cortex-M4F) based on the Oberon-> RISC compiler from Project Oberon Niklaus Wirth, and the program for the new automatic control system was written using it.
The compiler was easy to write because it was already written (and because it contains the correct separation of functions into frontend and backend), and I just had to rewrite the background compiler (code generator) and write the linker. And since the programming language is simple and the architecture of ARMm7-M is simple, it did not take long. In order to write a compiler, I only needed to study the architecture of ARMv7-M and some features of modern microcontrollers (STM32 and LPC) for writing a linker.
When writing system modules for microcontrollers NXP used User Manual, for STM32 - Reference Manual and datasheet. I liked the NXP documentation more than the ST Microelectronics. To understand the ambiguous places in the Reference Manual, I had to look at the sources of Keil libraries.
When I wrote the compiler, I myself made a few mistakes, but I quickly found them and corrected them as I wrote the autopilot program, which I immediately experienced on a software-hardware model. One error due to carelessness (indicated the wrong register as a parameter when generating one of the instructions), two due to the fact that I had to optimize one place, and this change required a change in the code generator elsewhere, but I did not immediately guess . And two more three errors were found in the original compiler (one was probably made due to inattention, the other two were of the same type).
After I wrote the compiler, I also had to write basic system modules to support microcontrollers — to configure the kernel (PLL) and to work with the peripherals. It was also easy to do.
O .: Can you give an example code?
A .: I did not find anything that can be cited as an example. Well, here is a simple integer implementation of the low-pass filter:
MODULE IntRC; (* Alexander Shiryaev, 2015.01 *) TYPE RC* = RECORD rc*, n*: INTEGER END; PROCEDURE Init* (VAR rc: RC; x, n: INTEGER); BEGIN rc.rc := LSL(x, n); rc.n := n END Init; PROCEDURE Set* (VAR rc: RC; x: INTEGER); BEGIN rc.rc := LSL(x, rc.n) END Set; PROCEDURE ASR1 (x, n: INTEGER): INTEGER; BEGIN IF x > 0 THEN INC(x, LSL(1, n - 1)) END RETURN ASR(x, n) END ASR1; PROCEDURE Update* (VAR rc: RC; x: INTEGER): INTEGER; PROCEDURE ASR2 (x, n: INTEGER): INTEGER; BEGIN IF x > 0 THEN INC(x, LSL(1, n) - 1) END RETURN ASR(x, n) END ASR2; BEGIN rc.rc := rc.rc + ASR2(LSL(x, rc.n) - rc.rc, rc.n) RETURN ASR1(rc.rc, rc.n) END Update; PROCEDURE Get* (rc: RC): INTEGER; BEGIN RETURN ASR1(rc.rc, rc.n) END Get; END IntRC. O .: Thanks for the info.
As you can see from the interview, in order to start working with Oberon and increase the reliability of their products, you do not need anything but desire. Each stage of development is so simple that there is nothing to even write about it.
Use Oberon for microcontrollers!
PS and do not forget to visit the site of the Russian Oberon community for more information.
Source: https://habr.com/ru/post/258695/
All Articles