Oberon programming UAV

All kind time of day.

Articles about Oberon often mention the use of Oberon in programming satellites, hydropower, nuclear power plants and so on. Harsh industrial software systems. Of course, I would like to have real code examples for each case, but it is not always possible, and therefore, it seems that there are no products. To remedy this situation, today I would like to tell you about programming the drones to Oberon.

Since I'm never with the UAV did not work, and the microcontroller only for the flashing led used (with the help of Oberon, of course), I was asked to talk about their work and active community member of Oberon-developers in Russia. His name is Alexander.

Hereinafter A. Alexander, O. — oberon87

O.: a Few words about your work.
A. I work for a company that develops unmanned aerial vehicles, and I write software for automatic control systems aircraft. The planes are used mainly for aerial photography.

O.: Why Oberon, because in the market there are a lot of microcontrollers and languages (mainly C)?
A. We appreciate the reliability of the onboard software.

Early automatic control systems (in the 2000's and earlier) were performed on the microcontrollers MCS 51, and was written in Pascal and Assembler using compiler EmbeddedPascal. MCS 51 at the time, was chosen because of its popularity.

But gradually the resources of the microcontroller was not enough, the compiler contained errors (which are bypassed using Assembly language) because of the complexity of the MCS 51 architecture, new microcontrollers and the compiler of the firm Astrobe, and in 2010 we began to write programs in the programming language Oberon under the NXP LPC2000 microcontrollers. <...> Another difference of the new system from the previous one in that the new is built on more cheap and compact sensors, which did not exist before.

The ARM architecture is simpler than the MCS 51, and the programming language Oberon is simpler than Pascal, but still in the implementation of the Astrobe compiler had bugs that were gradually found and corrected.
I actually don't use all the features of the language Oberon — do not use dynamic memory and the garbage collector.

I don't like the syntax of C language.

O.: used, how is writing code in Oberon, how easy/difficult?
A. As I wrote, we appreciate the reliability of the onboard software. The use of a simple programming language helps you write robust programs. Oberon just so is it was conceived. The compiler must also be reliable. That is also simple. In order for the compiler was simple, should be simple programming language and target architecture. Such architecture is RISC.

In 2014 I wrote my Oberon compiler for modern processors with architecture of ARMv7-M (Cortex-M4F) based on compiler Oberon->RISC from Project Oberon Niklaus Wirth, and the program for new automatic control system was written using it.

The compiler was easy to write because it was already written (and because it's the right division of functions in frontend and backend), and I just needed to rewrite the compiler back-end (code generator), and write the linker. And since the programming language is simple and the architecture ARMм7-M is simple, then it takes a lot of time. In order to write a compiler, I needed only to study architecture ARMv7-M some features of modern microcontrollers (STM32 and LPC) for writing a linker.

When writing system modules for microcontrollers NXP used an User Manual for the STM32 Reference Manual and datasheet. Documentation from NXP I liked it more than the ST Microelectronics. To understand the ambiguous places in the Reference Manual had to watch the Keil source code libraries.
When I wrote the compiler, I made a few mistakes, but quickly they found and fixed as of this writing, the program of the autopilot, which is immediately experienced on hardware-software model. One mistake due to carelessness (I used the register as a parameter when generating one instruction), two due to the fact that I had to optimize one place, and this change demanded a change elsewhere in the code generator, and immediately I guessed. And two of three errors were found in the original compiler (one was probably made due to carelessness, the other two were identical).

After I wrote the compiler, it was necessary to write the base system modules to support microcontrollers for engine tuning (PLL) and to work with peripherals. It was also easy to do.

O.: Can you give an example code?
A. Not found anything that you can cite as an example. Well, here, a simple integer implementation of a filter WOOFER:
the

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;

IntRC END.

O.: Thanks for the info.

As you can see from the interview, in order to start working with Oberon and improve the reliability of its products, it is not necessary anything, except desire. Each stage of the development is so simple that even writing about it is nothing.
Drink carrot juice!
Use Oberon for microcontrollers!

P. S. and don't forget to visit Russian Oberon-community for more information

Article based on information from habrahabr.ru