ST's (STM32Cube) software ecosystem is terrible - how can we fix it?

[captbill]

Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193 

[captbill]

Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193

I guess I read the thread too fast. Looks Like the STM32 is up and running on Astrobe. Looks to be going commercial by months end.

[captbill]

Code review!  This is ONE function from stm32f1xx_hal_uart.c (v1.0.1, July 2015)
My comments preceded by the triple-semicolons: ";;;"

Code: [Select]

HAL_StatusTypeDef HAL_UART_Receive(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
  uint16_t* tmp;
  uint32_t  tmp_state = 0;

  tmp_state = huart->State;
  if((tmp_state == HAL_UART_STATE_READY) || (tmp_state == HAL_UART_STATE_BUSY_TX))
;;; Why are there states?  There is no documentation for what the states
;;; are supposed to accomplish...
;;; I suppose we're using tmp_state because huart isn't "locked" yet?
;;; Does this allow polled, DMA, and ISR based uart IO to occur
;;; "simultaneously" (or "not occur" as the case may be)?
;;; How are those supposed to interact?
  {
    if((pData == NULL ) || (Size == 0))
    {
      return  HAL_ERROR;
    }

    /* Process Locked */
    __HAL_LOCK(huart);
;;; locked against what?

    huart->ErrorCode = HAL_UART_ERROR_NONE;
    /* Check if a non-blocking transmit process is ongoing or not */
    if(huart->State == HAL_UART_STATE_BUSY_TX)
    {
      huart->State = HAL_UART_STATE_BUSY_TX_RX;
    }
    else
    {
      huart->State = HAL_UART_STATE_BUSY_RX;
    }
;;; Now we've changed state.  Perhaps this does "real" half-duplex?

    huart->RxXferSize = Size;
    huart->RxXferCount = Size;
;;; Maybe we copy these so that we can do polled and interrupt driven
;;; IO at the same time?  Maybe the states help with that?  Oh well,
;;; a few extra copies won't hurt anything, right?
    /* Check the remain data to be received */
    while(huart->RxXferCount > 0)
    {
      huart->RxXferCount--;
      if(huart->Init.WordLength == UART_WORDLENGTH_9B)
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; So where are we now? huart->RxXferSize and huart->RxXferCount
;;; are intermediate values, and we didn't change the state to reflect
;;; that we aborted the input.  Doesn't this mean that we'll fail all
;;; subsequent attempts at input?
;;; We also didn't unlock anything!
        }
        tmp = (uint16_t*) pData ;
;;; for 9bit data, we recast our pointer.  Ok, I guess.  Since we're
;;; so casual with ASSERT, shouldn't we ASSERT word alignment too?
        if(huart->Init.Parity == UART_PARITY_NONE)
        {
          *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x01FF);
          pData +=2;
;;; OK, we recieved 9bit data and put it in our 16bit buffer.
;;; (uint16_t)0x01FF seems silly.  Doesn't it subsequenlty get promoted
;;; to uint32 to match DR?
        }
        else
        {
          *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x00FF);
          pData +=1;
;;; But WTF did this do?  If parity is turned on, we'll just throw
;;; away that 9th bit and store 8bits instead?  Doesn't the uart do
;;; 9 bits PLUS parity (10bits total)?  If I put it in 9bit mode, don't
;;; I probably want to receive 9bits for each input?
        }
;;; Did I mention how great I feel that my program will be cluttered with
;;; (broken?) 9bit UART code even though I'm unlikely to ever use it?
      }
      else
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; more returing without updating State or lock
        }
        if(huart->Init.Parity == UART_PARITY_NONE)
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
;;; OK. masking unnecessary, but probably optimized anyway.
;;; casting "0x00FF" to uint8_t seems particularly silly.
        }
        else
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
;;; This is OK for 7 databits + parity, and in fact is necessary since the
;;; UART hardware is documented as leaving the parity bit in DR instead
;;; of stripping it as with many other UARTs.
;;; However, this seems like it's substantially broken for any word size
;;; OTHER than 7 bits.  8 databits+parity will only return 7bits to the user,
;;; databits less than 7 will fail to strip the parity bit.
        }

      }
    }

    /* Check if a non-blocking transmit process is ongoing or not */
    if(huart->State == HAL_UART_STATE_BUSY_TX_RX)
    {
      huart->State = HAL_UART_STATE_BUSY_TX;
    }
    else
    {
      huart->State = HAL_UART_STATE_READY;
    }
    /* Process Unlocked */
    __HAL_UNLOCK(huart);
;;; more state stuff.

    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}


Just for a comparison, here is the COMPLETE In.Mod for Astrobe Oberon (UART input module/library). It compiles to 364 BYTES!

Code: [Select]

MODULE In;
(* ========================================================================= 
   Astrobe Library Functions for Formatted Input 
   Ref: Programming in Oberon - Reiser & Wirth, ACM Press 1992

   (c) 2010-2013 CFB Software   
   http://www.astrobe.com 
   
   ========================================================================= *)

IMPORT Convert;

CONST
  CR = 0DX;
  LF = 0AX;
 
  (* Possible result values *)
  noError* = Convert.noError;
  overflow* = Convert.overflow;
  syntaxError* = Convert.syntaxError;
 
TYPE
  GetCharProc* = PROCEDURE (VAR ch: CHAR);
 
VAR
  GetCh: GetCharProc;
  result*: INTEGER;

PROCEDURE* UndefinedGetCh(VAR ch: CHAR);
BEGIN
  ASSERT(TRUE, 20)
END UndefinedGetCh;

 
PROCEDURE* Init*(g: GetCharProc);
BEGIN
  GetCh := g
END Init;


PROCEDURE Char*(VAR ch: CHAR);
BEGIN
  GetCh(ch)
END Char;


PROCEDURE String*(VAR s: ARRAY OF CHAR);
VAR
  i: INTEGER;
  ch: CHAR;
BEGIN
  REPEAT GetCh(ch) UNTIL (ch > " ");
  i := 0;
  WHILE (ch > " ") & (i < LEN(s)) DO s[i] := ch; GetCh(ch); INC(i) END;
  IF i < LEN(s) THEN s[i] := 0X END
END String;


PROCEDURE Int*(VAR n: INTEGER);
VAR
  buffer: ARRAY 12 OF CHAR;
BEGIN
  String(buffer);
  Convert.StrToInt(buffer, n, result)
END Int;


BEGIN
  Init(UndefinedGetCh)
END In.

[dannyf]

#your 'software ecosystem problems' will be a thing of the past if he is successful. #

Writing bug free software is super easy: everyday, millions of programmers try to do it.

[captbill]

#your 'software ecosystem problems' will be a thing of the past if he is successful. #

Writing bug free software is super easy: everyday, millions of programmers try to do it.

True...but how many are succeeding?

(This is the one and only post in the bug tracker: )

http://www.astrobe.com/forum/viewtopic.php?f=5&t=452

[westfw]

Just for a comparison, here is the COMPLETE In.Mod for Astrobe Oberon

Code: [Select]

Astrobe Library Functions for Formatted Input 

Since I'm being fussy (what else IS a "code review:!), I feel compelled to point out that the code you quoted does entirely different stuff ("formatted input") than the code/module that I quoted (HW level driver.)  The equivalent driver-level code would all be hidden in the "GetCharProc" procedure, and the quoted portion only provides a "dummy" version thereof (assuming that I'm reading the unfamiliar language correctly.)


On  a somewhat related note, does anyone know if ST pays attention to bug reports and/or code suggestions on the Cube/HAL libraries?
I'm not really inclined to spend a lot of time contributing to libraries with objectionable licenses, but since I've essentially already written up several bugs, I might as well send them somewhere...

[captbill]

Just for a comparison, here is the COMPLETE In.Mod for Astrobe Oberon

Code: [Select]

Astrobe Library Functions for Formatted Input 

Since I'm being fussy (what else IS a "code review:!), I feel compelled to point out that the code you quoted does entirely different stuff ("formatted input") than the code/module that I quoted (HW level driver.)  The equivalent driver-level code would all be hidden in the "GetCharProc" procedure, and the quoted portion only provides a "dummy" version thereof (assuming that I'm reading the unfamiliar language correctly.)


On  a somewhat related note, does anyone know if ST pays attention to bug reports and/or code suggestions on the Cube/HAL libraries?
I'm not really inclined to spend a lot of time contributing to libraries with objectionable licenses, but since I've essentially already written up several bugs, I might as well send them somewhere...

Yes, actually, the In.Mod and Out.Mod work in conjunction with an mcu specific Serial.Mod for the complete UART functionality. I was just giving an idea of some actual code. Here is the Out.Mod and Serial.Mod for the LPC1769:

Code: [Select]

MODULE Out;
(* ========================================================================= 
   Astrobe Library Functions for Formatted Output 
   Ref: Programming in Oberon - Reiser & Wirth, ACM Press 1992

   (c) 2008-2011 CFB Software   
   http://www.astrobe.com 
   
   ========================================================================= *)

IMPORT Convert;

TYPE
  PutCharProc* = PROCEDURE (ch: CHAR);
 
VAR
  PutCh: PutCharProc;

PROCEDURE* UndefinedPutCh(ch: CHAR);
BEGIN
  ASSERT(FALSE, 20)
END UndefinedPutCh;

 
PROCEDURE* Init*(p: PutCharProc);
BEGIN
  PutCh := p
END Init;


PROCEDURE Char*(ch: CHAR);
BEGIN
  PutCh(ch)
END Char;


PROCEDURE String*(s: ARRAY OF CHAR);
VAR
  i, sLen: INTEGER;
BEGIN
  i := 0;
  sLen := STRLEN(s);
  FOR i := 0 TO sLen - 1 DO PutCh(s[i]) END;
END String;


PROCEDURE Ln*();
BEGIN
  PutCh(0DX);
  PutCh(0AX)
END Ln;


PROCEDURE Int*(n, width: INTEGER);
VAR
  buffer: ARRAY 12 OF CHAR;
  i, bLen: INTEGER;
BEGIN
  Convert.IntToStr(n, buffer);
  bLen := STRLEN(buffer);
  FOR i := 1 TO width - bLen DO Char(" ") END;
  String(buffer)
END Int;


PROCEDURE Hex*(n, width: INTEGER);
VAR
  buffer: ARRAY 12 OF CHAR;
  i, bLen: INTEGER;
BEGIN
  Convert.IntToHex(n, buffer);
  bLen := STRLEN(buffer);
  FOR i := 1 TO width - bLen DO Char(" ") END;
  String(buffer)
END Hex;


BEGIN
  Init(UndefinedPutCh)
END Out.

 

Code: [Select]

MODULE Serial;
(** ========================================================================= 
   Astrobe Library Functions for Serial IO via UART0/2/3
   
   Target: LPC176x family microcontrollers
   
   Refs:
     NXP LPC176x/5x User Manual UM10360

   (c) 2012-2015 CFB Software   
   http://www.astrobe.com 
   
   ========================================================================= *)

IMPORT MCU, SYSTEM;

CONST
  UART0* = 0;
  UART2* = 2;
  UART3* = 3;
 
  (* Parity *)
  none*    = {};
  odd*     = {3};
  even*    = {3, 4};
  forced1* = {3, 5};
  forced2* = {3, 4, 5};
 
VAR
  URBR: INTEGER;
  UTHR: INTEGER;
  UDLL: INTEGER;
  UDLM: INTEGER;
  UIER: INTEGER;
  UIIR: INTEGER;
  UFCR: INTEGER;
  ULCR: INTEGER;
  ULSR: INTEGER;
  USCR: INTEGER;
  UACR: INTEGER;
  UICR: INTEGER;
  UFDR: INTEGER;
  UTER: INTEGER;
 
PROCEDURE* TxReady*(): BOOLEAN;
  RETURN SYSTEM.BIT(ULSR, 5)
END TxReady;


(** Send a single character using polling *)
PROCEDURE* PutCh*(ch: CHAR);
BEGIN
  REPEAT UNTIL SYSTEM.BIT(ULSR, 5);
  SYSTEM.PUT(UTHR, ch)
END PutCh;


PROCEDURE* RxReady*(): BOOLEAN;
  RETURN SYSTEM.BIT(ULSR, 0)
END RxReady;


(** Receive a single character using polling *)
PROCEDURE* GetCh*(VAR ch: CHAR);
BEGIN
  REPEAT UNTIL SYSTEM.BIT(ULSR, 0);
  SYSTEM.GET(URBR, ch)
END GetCh;


PROCEDURE* SetUartNo(uartNo: INTEGER);
VAR
  UBase: INTEGER;
BEGIN
  CASE uartNo OF
    UART0: UBase := MCU.U0Base
  | UART2: UBase := MCU.U2Base
  | UART3: UBase := MCU.U3Base
  END;
  URBR := UBase+000H;
  UTHR := UBase+000H;
  UDLL := UBase+000H;
  UDLM := UBase+004H;
  UIER := UBase+004H;
  UIIR := UBase+008H;
  UFCR := UBase+008H;
  ULCR := UBase+00CH;
  ULSR := UBase+014H;
  USCR := UBase+01CH;
  UACR := UBase+020H;
  UICR := UBase+024H;
  UFDR := UBase+028H;
  UTER := UBase+030H
END SetUartNo;


PROCEDURE* ConfigurePins(uartNo: INTEGER);
VAR
  pconp, select: SET;
BEGIN
  SYSTEM.GET(MCU.PCONP, pconp);
  SYSTEM.GET(MCU.PINSEL0, select);

  IF uartNo = UART0 THEN
    pconp := pconp + {3}; 
    (* P0.2 Bits 5:4 = 01 TXD UART0 *)
    (* P0.3 Bits 7:6 = 01 RxD UART0 *)
    select := select - {5, 7} + {4, 6}
  ELSIF uartNo = UART2 THEN
    pconp := pconp + {24}; 
    (* P0.10 Bits 21:20 = 01 TXD UART2 *)
    (* P0.11 Bits 23:22 = 01 RxD UART2 *)
    select := select - {21, 23} + {20, 22}
  ELSIF uartNo = UART3 THEN
    pconp := pconp + {25}; 
    (* P0.0 Bits 1:0 = 10 TXD UART3 *)
    (* P0.1 Bits 3:2 = 10 RxD UART3 *)
    select := select - {0, 2} + {1, 3}
  END;
 
  (* Power on *)
  SYSTEM.PUT(MCU.PCONP, pconp);

  (* Assign UART function to GPIO port *)
  SYSTEM.PUT(MCU.PINSEL0, select)
END ConfigurePins;


PROCEDURE* SetFormat*(wordLength, stopBits: INTEGER; parity: SET);
VAR
  ulcr: SET;
BEGIN
  ASSERT(wordLength IN {5..8}, 20);
  ASSERT(stopBits IN {1, 2}, 21);
  ASSERT(parity - {3..5} = {}, 22);
  SYSTEM.GET(ULCR, ulcr);
  ulcr := ulcr - {0..5} + parity + BITS(wordLength - 5);
  IF (stopBits = 2) THEN ulcr := ulcr + {2} END;
  SYSTEM.PUT(ULCR, ulcr)
END SetFormat;


PROCEDURE* SetFDR(udlm, udll, mulVal, divAddVal: INTEGER);
CONST
  divisorLatchAccess = {7};
VAR
  ulcr: SET;
BEGIN
  SYSTEM.GET(ULCR, ulcr); 
  SYSTEM.PUT(ULCR, ulcr + divisorLatchAccess);
  SYSTEM.PUT(UDLM, udlm);
  SYSTEM.PUT(UDLL, udll);
  IF (mulVal # 0) OR (divAddVal # 0) THEN
    ASSERT((mulVal >= 1) & (mulVal <= 15), 23);
    ASSERT((divAddVal >= 0) & (divAddVal <= 14), 24);
    SYSTEM.PUT(UFDR, LSL(mulVal, 4) + divAddVal)
  END;
  SYSTEM.PUT(ULCR, ulcr - divisorLatchAccess);
 
  (* Enable and clear FIFOs *)
  SYSTEM.PUT(UFCR, {0, 1, 2})
END SetFDR;


PROCEDURE InitEx*(uartNo, udlm, udll, mulVal, divAddVal: INTEGER);
BEGIN
  ASSERT(uartNo IN {UART0, UART2, UART3}, 20);
  SetUartNo(uartNo);
  ConfigurePins(uartNo);
  SetFormat(8, 1, none);
  SetFDR(udlm, udll, mulVal, divAddVal)
END InitEx;


PROCEDURE Init*(uartNo, baudRate: INTEGER);
BEGIN
  InitEx(uartNo, 0, MCU.PCLK DIV (16 * baudRate), 0, 0)
END Init;


END Serial.


[jnz]

Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193

I guess I read the thread too fast. Looks Like the STM32 is up and running on Astrobe. Looks to be going commercial by months end.

Cool? I guess this might be an option if I wanted to abandon my all tools and buy something new? AND CODE IN AN OBSCURE LANGUAGE...

This is no better than the other "buy our tools and we'll give you a library" that is really just probably as bad as any other mfgs lib, the only difference is now you're locked into a new tool as well.

I'm just not impressed when everyone thinks they can do a better job - yet almost no one seems to be able to prove it... Less impressed when the solution isn't in C.

[westfw]

Code: [Select]

        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; So where are we now? huart->RxXferSize and huart->RxXferCount
;;; are intermediate values, and we didn't change the state to reflect
;;; that we aborted the input.  Doesn't this mean that we'll fail all
;;; subsequent attempts at input?
;;; We also didn't unlock anything!Ah well, it turns out that I'm wrong and this code isn't as broken as I thought.
UART_WaitOnFlagUntilTimeout() resets huart->state and does the unlock operation.  (I find that a bit surprising, but I'll take "surprising" over "broken.")

[captbill]

Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193

I guess I read the thread too fast. Looks Like the STM32 is up and running on Astrobe. Looks to be going commercial by months end.

Cool? I guess this might be an option if I wanted to abandon my all tools and buy something new? AND CODE IN AN OBSCURE LANGUAGE...

This is no better than the other "buy our tools and we'll give you a library" that is really just probably as bad as any other mfgs lib, the only difference is now you're locked into a new tool as well.

I'm just not impressed when everyone thinks they can do a better job - yet almost no one seems to be able to prove it... Less impressed when the solution isn't in C.

Gee, I don't know. Show me a language that you can stare at for 20 minutes and already see a working UART stack for an STM32.

The only file that needs modifications is the Serial.Mod, which will be STM32 specific. Most of the code will remain intact even here. This is mostly initialization, which of coarse everyone can see by a casual read of it.

How is that an OBSCURE language? Could you write a full UART stack for a uC on a whim with your tools? Hey, I'm a newb to all this low level uC stuff too and even I feel confident I could do this in a couple of hours, assuming the MCU.Mod is complete and no newbie gottchas happen to me.

[Kjelt]

@westfw  its 7 and i am just awake so a d don,t feel like taking a code review but before you judge code think about some things, like that stm32 are mostly run with an rtos onboard and if you see "locks" and sm's,  think about semaphore and re-entrant code.
Life is a box of chocolates but some other routine can be eating them while your routine was still busy choosing 

[richardman]

This is no better than the other "buy our tools and we'll give you a library" that is really just probably as bad as any other mfgs lib, the only difference is now you're locked into a new tool as well.

I'm just not impressed when everyone thinks they can do a better job - yet almost no one seems to be able to prove it... Less impressed when the solution isn't in C.

In case I am implicated ;-P This just came in our mailbox, unedited:

//start review
I used arduino for quite a few years tinkering and building projects. Recently, I decided to take an idea out of the world of arduino and into the world of true embedded systems. I started my search for a simple way to create an embedded system that i could put into a commercial product. I found the answer and then some by using Jumpstart microbox from Imagecraft. I found Imagecraft originally by searching for a compiler to use with avr MCUs but after a month and a half of reading and looking at code. I was no closer to my goal of creating a commercial MCU. Then Richard at Imagecraft suggested i try their Jumpstart Microbox with the Jumpstart API. After looking at a few examples, I knew this was going to be a much easier and faster way for me to get my code onto a micro controller. I ordered a Jumpstart Microbox kit, and it was at my door a few days later. I had their example programs running within 30 minutes. A 32 bit 84 MHz micro controller was under my control (a mechanical engineer with little c programming experience). The example code and documentation from Imagecraft was very easy to follow and understand. I was able to use a 32 bit micro controller just like i would an arduino. I couldn't be more impressed with this product. If you are interested in making a commercial product or learning more about micro controllers, and you want or need to use a powerful micro controller. Jumpstart microbox is the answer period. The last thing and probably the best thing about this product is the customer service. The guys at Imagecraft would answer any question i had within minutes no kidding. They even answered questions i didn't know i would need to ask. Excellent job Imagecraft.
//end review
-- Wesley Roberson

[Kjelt]

In case I am implicated ;-P This just came in our mailbox, unedited:

This Jumpstart microbox from Imagecraft is your product right?
First I want to say that I personally welcome alternatives. For the quick get going, prototyping and non SW engineers this could be a viable way to go.
Then, what is the overhead of your product in codesize because all the people here are ranting about how large the ST libs are, but what I think I am reading 1,2,3 on your website is that you have added another gluelayer on top of the ST libs, or did you indeed rewrite them?
So can you give some ballpark figures in k ROM , RAM it ads up to?
Are you forced to use the API or can you write your own c-code functions and integrate seamlessly?
Do you run an RTOS , can users use it directly or again through the forced API?
Is there a 100Mb/s IP stack available OpenSSL interface compatible?
Perhaps start another topic since it is going a bit offtopic here.

[obiwanjacobi]

Ring/CircularBuffer: I am not intimately familiar with the STM32's but I think I read somewhere (DMA?) that it has hardware ring buffers? Not sure, though...
[2c]

[richardman]

This Jumpstart microbox from Imagecraft is your product right?
First I want to say that I personally welcome alternatives. For the quick get going, prototyping and non SW engineers this could be a viable way to go.
Then, what is the overhead of your product in codesize because all the people here are ranting about how large the ST libs are, but what I think I am reading 1,2,3 on your website is that you have added another gluelayer on top of the ST libs, or did you indeed rewrite them?
...

I will just make some quick answers here. If there are further discussions, I will make a new thread (or anyone else is free to create a new one). Our main product is the JumpStart C for Cortex-M compiler. It's C90 with most useful C99 features (lacking variable sized array as the main missing feature) and basic C++ class support. JumpStart API is a functional API (i.e. not just a thin layer on top of the hardware), currently available for STM32F0xx, F4xx, and soon F7xx series. It does NOT sit on top of the ST lib, although we do use their header files. It is possible to mix and match code from ST's lib and JSAPI, and in fact, until we fill out more of the API, it would be required for more in-depth stuff. You can also write your own.. Basically, JSAPI does not takes over per se, it's just a set of C functions using C++ style classes.

As for other middleware, we are busy working on porting the most popular ones, resource permitting, but it's almost certainly that we will write our own message passing RTOS (we have one but with limited functionality for the AVR that was written a number of years ago) with dual licensing: basically free and Open Source for non-commercial use, and very reasonable fee for commercial use (e.g. much more reasonable than other dual license RTOS) and the goal is definitely to make it compatible with most Open Source middleware stacks.

// ADDED
The JumpStart MicroBox is our complete hardware/software kit particularly suitable for students/hobbyists and engineers new to the Cortex-M world to get started, especially for folks with only familiarity of 8-bit MCU or Arduino.

[bazsa56]

Ring/CircularBuffer: I am not intimately familiar with the STM32's but I think I read somewhere (DMA?) that it has hardware ring buffers? Not sure, though...
[2c]

Indeed, configuring a circular buffer is very easy with an STM32F1 using DMA, probably the same for other types of mcu's as well.

Just about to finish a product that uses the SPL with GCC + eclipse, 48 pin STM32F1. So far things have been going smoothly. No major issues or problems or anything. The cheap st-link v2 also worked fairly well. The code is mostly finished. Very happy with the end result, especially since this is the first time we ended up using a 32 bit mcu in a product.

[dannyf]

The JumpStart MicroBox is our complete hardware/software kit particularly suitable for students/hobbyists and engineers new to the Cortex-M world to get started, especially for folks with only familiarity of 8-bit MCU or Arduino.

The STduino (arduino on STM32F1 boards) would be a much better alternative for the Arduino folks, for its source level compatability: just copy-and-paste your AVR source code, and compile / upload in the same IDE.

Plus its ability to go native, all in the comfort of gcc-arm.

Nothing beats that.

[Koen]

On  a somewhat related note, does anyone know if ST pays attention to bug reports and/or code suggestions on the Cube/HAL libraries?

I've submitted bug fixes on ST's forum and they've always made it to the next release (months later).

[markone]

I will just make some quick answers here. If there are further discussions, I will make a new thread (or anyone else is free to create a new one). Our main product is the JumpStart C for Cortex-M compiler. It's C90 with most useful C99 features (lacking variable sized array as the main missing feature) and basic C++ class support. JumpStart API is a functional API (i.e. not just a thin layer on top of the hardware), currently available for STM32F0xx, F4xx, and soon F7xx series. It does NOT sit on top of the ST lib, although we do use their header files. It is possible to mix and match code from ST's lib and JSAPI, and in fact, until we fill out more of the API, it would be required for more in-depth stuff. You can also write your own.. Basically, JSAPI does not takes over per se, it's just a set of C functions using C++ style classes.
-snip

"Code size limited to 128K bytes of flash"

https://imagecraft.com/index.php?option=com_opencart&Itemid=148&route=product/product&product_id=55

Is it a commercial decision ?

[andyturk]

Yes, actually, the In.Mod and Out.Mod work in conjunction with an mcu specific Serial.Mod for the complete UART functionality. I was just giving an idea of some actual code. Here is the Out.Mod and Serial.Mod for the LPC1769:

I'm sure Oberon is an interesting language, but I wouldn't want that UART code in my system. First, it's got scoped variables that must be initialized each time you want to use a different UART (see SetUartNo(...)). What if you want to use two UARTs? Do you really want to keep re-initializing all the time?

And calculating those register locations (e.g., "ULCR := UBase+00CH;") involves hard-coded hex constants mixed in with the rest of the driver code. All those constants should be defined somewhere else, preferably with no code/behavior attached, and be generated from a .svd file (in the case of ARM).

The Oberon page on wikipedia mentions garbage collection as a feature of the language. Nope, I don't want that either.

[MT]

I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

Yes , he might have a peculiar name, situated on strange planet Astrobe and working on top elite project Oberon but one question remain, is he a super hero?

[jnz]

Gee, I don't know. Show me a language that you can stare at for 20 minutes and already see a working UART stack for an STM32.

The only file that needs modifications is the Serial.Mod, which will be STM32 specific. Most of the code will remain intact even here. This is mostly initialization, which of coarse everyone can see by a casual read of it.

How is that an OBSCURE language? Could you write a full UART stack for a uC on a whim with your tools? Hey, I'm a newb to all this low level uC stuff too and even I feel confident I could do this in a couple of hours, assuming the MCU.Mod is complete and no newbie gottchas happen to me.

"PROCEDURE* TxReady*(): BOOLEAN;" is not showing me a working UART code, regardless of how many minutes you stare at it. If anything, what you posted is worse than the topic at hand. You posted someone else's atrempt of a "universal" library that removes what the processor is actually doing in order to dumb it down - but also in a "new" language that is wholly incompatible with any existing code, libraries, third party middleware, operating systems.

Yes, I can write a full UART stack in Keil for the STM32. That's what we're all talking about here, is that many of us have done just that becsause of preferences in the way we want to write vs what STM provides as vendor libraries. It's not the difficulty I care about, it's the duplication of work that is stupid.

If you are a newb, using "simplified" / "opaque" libraries that hide all the scary code from you are a sure way to make sure you'll never learn what's really going on with embedded programming. Doing it in some obscure (yes, definitely) language is also a surefire way to make sure you'll only have one avenue of help with it as well. I can imagine nothing worse for a newb than to use a solution like that.

[Karel]

If you are a newb, using "simplified" / "opaque" libraries that hide all the scary code from you are a sure way to make sure you'll never learn what's really going on with embedded programming.

I couldn't agree more.
I wrote all libraries myself (SPI, I2C, UART, FAT32, SD-card).
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

[Sal Ammoniac]

I couldn't agree more.
I wrote all libraries myself (SPI, I2C, UART, FAT32, SD-card).
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

 
I do the same, but wrote my own TCP/IP stack. I do draw the line at USB, however.

[dannyf]

For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

Do you write your own Linux? Do you want your own word processor? Do you want your own compiler? Do you want your own Android? Do you write your own Windows? Do you write your own ECM / infotainment in your car? ...

At some point, you have to stop. The fact that you made your stop differently from others doesn't by itself make your stop right for them.

You don't have to agree with the compromise they made but you have to appreciate the compromise they made.