ANN: STM32F4 GNAT Run Time Systems 20150406

ANN: STM32F4 GNAT Run Time Systems 20150406

[Simon Wright]

This is the fourth release of a GNAT RTS with the GCC Runtime Library
exception for STM32F4 boards.

(a) Tasking is implemented using FreeRTOS[3], which STMicroelectronics
    provide a copy of with their BSP.

(b) I've included a BSP with minimal higher-level Ada interfaces to the
    board hardware: clock, buttons, LEDs, LCD. In addition, there's a
    machine-generated translation of STMicroelectronics' type-specific
    header in stm32f429xx_h.ads, for low-level interfacing.

The release is at
https://sourceforge.net/projects/stm32f4-gnat-rts/files/20150406/.

From its README,

20150406
========

This release has been reorganised from previous releases.

There is one RTS, stm32f4-disco-rtos, and one BSP, stm32f4-disco-bsp.

Changes to the RTS from the previous release:
---------------------------------------------

These units (and supporting units) are now included:

  Ada.Containers.Bounded_Vectors (*)
  Ada.Containers.Bounded_Hashed_Maps (*)
  Ada.Containers.Generic_Array_Sort
  Ada.Containers.Generic_Constrained_Array_Sort
  Ada.IO_Exceptions
  Ada.Streams
  Ada.Task_Identification
  Interfaces.C
  Interfaces.C.Strings
  System.Assertions

  (*) The new iterators (for some F in Foo loop ...) are NOT supported
      (they require finalization).

The STM32F429I_Discovery tree has been moved to the BSP.

The following tickets have been fixed:

  2  Protected spec hides package Interfaces
  14 Last_Chance_Handler doesn’t stop tasking

Tasking is started by calling Start_FreeRTOS_Scheduler.

Re: ANN: STM32F4 GNAT Run Time Systems 20150406

[Jedi Tek'Unum]

On Monday, April 6, 2015 at 12:27:11 PM UTC-5, Simon Wright wrote:
> This is the fourth release of a GNAT RTS with the GCC Runtime Library
> exception for STM32F4 boards.

Nice!

One issue that can immediately cause problems for people is that STM frequently releases new versions that replace the old - and I mean the old is *gone*. I have not been able to find 1.3.0 that the RTS is based on.  When I played with an earlier release the current version was 1.4.0 which I was able to get working by making some changes including in FreeRTOSConfig.h. Now I see they only have 1.5.0 available - haven't tried it yet.

Have you given any thought to how this could be handled?

I might have time to take a crack at it but only if you aren't planning on working in that area soon...

Re: ANN: STM32F4 GNAT Run Time Systems 20150406

[Simon Wright]

"Jedi Tek'Unum" <jeditekunum@gmail.com> writes:

> On Monday, April 6, 2015 at 12:27:11 PM UTC-5, Simon Wright wrote:
>> This is the fourth release of a GNAT RTS with the GCC Runtime Library
>> exception for STM32F4 boards.
>
> Nice!
>
> One issue that can immediately cause problems for people is that STM
> frequently releases new versions that replace the old - and I mean the
> old is *gone*. I have not been able to find 1.3.0 that the RTS is
> based on.  When I played with an earlier release the current version
> was 1.4.0 which I was able to get working by making some changes
> including in FreeRTOSConfig.h. Now I see they only have 1.5.0
> available - haven't tried it yet.
>
> Have you given any thought to how this could be handled?
>
> I might have time to take a crack at it but only if you aren't
> planning on working in that area soon...

Now I have GCC 5.1, this issue, and one of my own projects with a
lurking bug that needs major rework to fix - fun all round! I will
certainly get on to this (just downloaded 1.5.0).

In the mean time, I think it would be legitimate to make the 1.3.0
version available? (plus the patches needed to make it compilable on
Unix systems - mainly replacing \ by /).

You *should* only need the Cube package if you're going to rebuild the
RTS or the BSP - or include C sources - since libbsp-rtos.a includes a
complete set of binaries.

Re: ANN: STM32F4 GNAT Run Time Systems 20150406

[Jedi Tek'Unum]

On Wednesday, April 22, 2015 at 3:59:26 PM UTC-5, Simon Wright wrote:
> Now I have GCC 5.1, this issue, and one of my own projects with a
> lurking bug that needs major rework to fix - fun all round! I will
> certainly get on to this (just downloaded 1.5.0).

In my 35+ years working in the world of "big iron" I am constantly
disappointed with portability hell in just the Unix zoo - even in the
context of "standards". I only recently started playing with the embedded
world and it makes the Unix world look like nirvana! Somebody needs
to develop an industry standard HAL that the chip vendors can all
implement.

> In the mean time, I think it would be legitimate to make the 1.3.0
> version available? (plus the patches needed to make it compilable on
> Unix systems - mainly replacing \ by /).

I didn't have any issues using 1.4.0 on OS X.

> You *should* only need the Cube package if you're going to rebuild the
> RTS or the BSP - or include C sources - since libbsp-rtos.a includes a
> complete set of binaries.

I got it to build with 1.4.0 with only minor changes so its not holding me
up. I prefer building everything from scratch in my embedded work...

Re: ANN: STM32F4 GNAT Run Time Systems 20150406

[Tero Koskinen]

23.4.2015, 15:40, Jedi Tek'Unum kirjoitti:
> On Wednesday, April 22, 2015 at 3:59:26 PM UTC-5, Simon Wright
> wrote:
>> Now I have GCC 5.1, this issue, and one of my own projects with a
>> lurking bug that needs major rework to fix - fun all round! I will
>> certainly get on to this (just downloaded 1.5.0).
>
> In my 35+ years working in the world of "big iron" I am constantly
> disappointed with portability hell in just the Unix zoo - even in
> the context of "standards". I only recently started playing with the
> embedded world and it makes the Unix world look like nirvana!
> Somebody needs to develop an industry standard HAL that the chip
> vendors can all implement.

There is one, it is called CMSIS - Cortex Microcontroller Software
Interface Standard, see
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

In this case, ST just is not that good at software development.
Their Stdperipheral and Cube libraries are quite buggy or hard to use
and many prefer "raw" register access instead.

Personally, I haven't really seen any need for common HAL across
different ARM MCUs. Differences between ARM Cortex-Mx MCUs are usually
related to peripherals (uart, spi, i2c, timers) and vendors implement
the peripherals slightly different way to allow some specific use case.

Some concentrate on performance and have DMA transfers, others target
low-power use and have features like "sleepwalking" (peripherals
working while CPU is sleeping). I think it would be somewhat hard
to create easy to use HAL for these. (If nothing else, you either
have maze of compile time conditions or a large binary size.)

If you want to have some sort of HAL, but don't want to or cannot
use CMSIS, you can use a RTOS, which provides its own HAL.

Or with a little bit planning, you can create Ada code, which
works on AVRs, MSP430s, and 32-bit ARM MCUs. Just separate
the platform/architecture specific code in their own packages.

Yours,
  Tero

Re: ANN: STM32F4 GNAT Run Time Systems 20150406

[Simon Wright]

Tero Koskinen <tero.koskinen@iki.fi> writes:

> 23.4.2015, 15:40, Jedi Tek'Unum kirjoitti:
>> On Wednesday, April 22, 2015 at 3:59:26 PM UTC-5, Simon Wright
>> wrote:
>>> Now I have GCC 5.1, this issue, and one of my own projects with a
>>> lurking bug that needs major rework to fix - fun all round! I will
>>> certainly get on to this (just downloaded 1.5.0).
>>
>> In my 35+ years working in the world of "big iron" I am constantly
>> disappointed with portability hell in just the Unix zoo - even in the
>> context of "standards". I only recently started playing with the
>> embedded world and it makes the Unix world look like nirvana!
>> Somebody needs to develop an industry standard HAL that the chip
>> vendors can all implement.
>
> There is one, it is called CMSIS - Cortex Microcontroller Software
> Interface Standard, see
> http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

I first thought CMSIS would be the way to go. ST's CMSIS is implemented
in FreeRTOS, and CMSIS's approach to task creation seemed excessively
clumsy compared to the FreeRTOS version, and FreeRTOS has a wider
applicability than CMSIS, so it seemed like a better bet.

> In this case, ST just is not that good at software development.  Their
> Stdperipheral and Cube libraries are quite buggy or hard to use and
> many prefer "raw" register access instead.

Not a lot of experience with this, but I found dealing with the register
access straightforward and no more complicated (indeed, less
complicated) than handling the STMCube version.

For STMCube 1.5.0 vs 1.3.0, the only change I've had to make in that
small sample of code (GPIO-related) is that ST used to split the 32-bit
BSRR register into 16-bit BSRRH and BSRRL; the newer way seems closer to
the reference manual.