STM32 target practicability question
STM32 target practicability question
Hi,
I would like to be able to use Astrobe with STM32 MCUs, to start with probably an STM32F103 on a Maple mini board that I have been using with C. Having tried all sorts of C development environments/software libraries with it I am dismayed with the complexity involved not in what I am writing but just in what is needed to surround it.
How practicable would it be for me to create my own M3 processor module for an STM32F103? I have a good working knowledge of the peripherals and experience with embedded Modula 2.
Also, presumably the executable format created by astrobe is standard and could be loaded by OpenOCD and STLink?
Alternatively has anyone tried loading an executable to an ST Nucleo board via the MBED virtual USB drive loader? This might be even easier.
Thanks in anticipation,
Joe
I would like to be able to use Astrobe with STM32 MCUs, to start with probably an STM32F103 on a Maple mini board that I have been using with C. Having tried all sorts of C development environments/software libraries with it I am dismayed with the complexity involved not in what I am writing but just in what is needed to surround it.
How practicable would it be for me to create my own M3 processor module for an STM32F103? I have a good working knowledge of the peripherals and experience with embedded Modula 2.
Also, presumably the executable format created by astrobe is standard and could be loaded by OpenOCD and STLink?
Alternatively has anyone tried loading an executable to an ST Nucleo board via the MBED virtual USB drive loader? This might be even easier.
Thanks in anticipation,
Joe
-
- Site Admin
- Posts: 511
- Joined: Fri Dec 31, 2010 12:30 pm
- Contact:
Re: STM32 target practicability question
While the code generated by the Astrobe compiler could work on any Cortex-M3 / M4 target, there is a significant amount of development work required to port NXP Cortex-M3/M4 software to targets from other manufacturers (e.g. STM). The differences between the systems from the two manufacturers include:
1. Different memory maps
2. Different upload protocols
3. Different initialisation sequences
4. Different peripheral definitions and register maps
As for the Maple mini board, LeafLabs announced that "As of March 2015, the LeafLabs Maple line and the libmaple library are end-of-life and no longer supported by LeafLabs."
http://www.leaflabs.com/about-maple/
I recommend you investigate acquiring a similar board from the list that we support and you'll be able to proceed without having to bother with any porting effort:
http://www.astrobe.com/boards.htm
1. Different memory maps
2. Different upload protocols
3. Different initialisation sequences
4. Different peripheral definitions and register maps
As for the Maple mini board, LeafLabs announced that "As of March 2015, the LeafLabs Maple line and the libmaple library are end-of-life and no longer supported by LeafLabs."
http://www.leaflabs.com/about-maple/
I recommend you investigate acquiring a similar board from the list that we support and you'll be able to proceed without having to bother with any porting effort:
http://www.astrobe.com/boards.htm
Re: STM32 target practicability question
Thanks for the reply.
What you say is involved is what I expected. Are these parts of the astrobe system accessible to users for it to be possible?
For flashing the executable it may just be easier to use an external programme.
Though LeafLabs have gone on to other things, clones of their boards are widely available and I have good experience of the Maple Mini with LeafLabs' software.
I appreciate that there is a huge difference in effort between what I am suggesting and just buying an NXP board and plugging it in, nevertheless I still think it could be interesting to do.
What you say is involved is what I expected. Are these parts of the astrobe system accessible to users for it to be possible?
For flashing the executable it may just be easier to use an external programme.
Though LeafLabs have gone on to other things, clones of their boards are widely available and I have good experience of the Maple Mini with LeafLabs' software.
I appreciate that there is a huge difference in effort between what I am suggesting and just buying an NXP board and plugging it in, nevertheless I still think it could be interesting to do.
-
- Site Admin
- Posts: 511
- Joined: Fri Dec 31, 2010 12:30 pm
- Contact:
Re: STM32 target practicability question
That should be feasible. You would need to work out how to upload the resulting HEX or bin file to the target using 3rd party software.
Re: STM32 target practicability question
Great. Thanks for being willing to consider this.
I am away from tomorrow till the 10th of April and will be in touch shortly after that to buy the compiler and get started.
I am away from tomorrow till the 10th of April and will be in touch shortly after that to buy the compiler and get started.
Re: STM32 target practicability question
Hello again,
I have a few more questions to make sure I have everything I'll need if I go ahead. I mainly do dynamic control work and I'm wondering whether with Astrobe it will be easier for me to use an M4 processor from the outset. In C I have brewed my own fixed point arithmetic for the M3, but I'm thinking this may not be easy or possible with Oberon.
Does the professional linker allow me to specify the addresses of the code sections so I can use the binary file with any M3/M4 microcontroller (assuming I write the startup/peripherals module)?
If I spend $300 on the M3 compiler, is there any upgrade path to the M4 compiler or is this another $300?
I can't find coroutines included or mentioned anywhere. Is there a way for me to implement these including possibly the FPU context in the case of the M4?
I haven't yet had to use the M3 saturating arithmetic instructions in C, but is there a way of using them from Astrobe if need be?
Thanks,
Joe
I have a few more questions to make sure I have everything I'll need if I go ahead. I mainly do dynamic control work and I'm wondering whether with Astrobe it will be easier for me to use an M4 processor from the outset. In C I have brewed my own fixed point arithmetic for the M3, but I'm thinking this may not be easy or possible with Oberon.
Does the professional linker allow me to specify the addresses of the code sections so I can use the binary file with any M3/M4 microcontroller (assuming I write the startup/peripherals module)?
If I spend $300 on the M3 compiler, is there any upgrade path to the M4 compiler or is this another $300?
I can't find coroutines included or mentioned anywhere. Is there a way for me to implement these including possibly the FPU context in the case of the M4?
I haven't yet had to use the M3 saturating arithmetic instructions in C, but is there a way of using them from Astrobe if need be?
Thanks,
Joe
-
- Site Admin
- Posts: 511
- Joined: Fri Dec 31, 2010 12:30 pm
- Contact:
Re: STM32 target practicability question
At the language level REAL arithmetic in Oberon is the same for Cortex-M3/M4. The only difference is performance as Oberon for Cortex-M4 utilizes the hardware FPU.
If your fixed point arithmetic C routines are not specific to a particular microcontroller I would be surprised if something comparable could not be written in Oberon. If you were using inline assembler or target-specific C code etc. then you could well have problems.
I assume when you say coroutines that you are referring to coprocessor operations? If so, there is currently no explicit control of these supported in Astrobe. Astrobe for Cortex-M4 generates the necessary FPU coprocessor instructions when you use REAL arithmetic operations in your programs.
Support for M3 saturating arithmetic instructions is not currently provided with Astrobe.
If your fixed point arithmetic C routines are not specific to a particular microcontroller I would be surprised if something comparable could not be written in Oberon. If you were using inline assembler or target-specific C code etc. then you could well have problems.
I assume when you say coroutines that you are referring to coprocessor operations? If so, there is currently no explicit control of these supported in Astrobe. Astrobe for Cortex-M4 generates the necessary FPU coprocessor instructions when you use REAL arithmetic operations in your programs.
Support for M3 saturating arithmetic instructions is not currently provided with Astrobe.
Re: STM32 target practicability question
Thanks for your answers and patience.
By coroutines I meant something like the Modula 2 couroutines module http://www.modula2.org/reference/isomod ... ROUTIN.DEF to enable simple task switching to be implemented. I want to be able to implement the simplest prioritised multi-tasking monitor, like FreeRTOS but only the task switching part. This is to give more flexibility than having processing only either in interrupt handlers or a monolithic main loop that must complete jobs sequentially.
Also, I forgot to ask whether its possible to use a hardware debugger like OpenOCD with Astrobe?
By coroutines I meant something like the Modula 2 couroutines module http://www.modula2.org/reference/isomod ... ROUTIN.DEF to enable simple task switching to be implemented. I want to be able to implement the simplest prioritised multi-tasking monitor, like FreeRTOS but only the task switching part. This is to give more flexibility than having processing only either in interrupt handlers or a monolithic main loop that must complete jobs sequentially.
Also, I forgot to ask whether its possible to use a hardware debugger like OpenOCD with Astrobe?
-
- Site Admin
- Posts: 511
- Joined: Fri Dec 31, 2010 12:30 pm
- Contact:
Re: STM32 target practicability question
The Cortex-M3 and M4 targeted versions of Astrobe are designed to create a single embedded application that runs in isolation. There is no OS involved so you do need to use interrupt handlers to handle separate processes.
To get the sort of flexibility you want you would need to use the Workstation or Embedded FPGA-targeted versions of Astrobe. These include the realtime tasking OS known as Project Oberon 2013. No static module linking is required. Tasks consist of related groups of compiled modules. Each module can contain one or more commands (i.e. parameterless procedures). When a command is invoked at runtime, either interactively or programmatically, the corresponding compiled object file for the module, and any dependent module that is not already loaded, is automatically loaded. If dependent modules(s) are already resident in memory these are automatically reused with their existing global context. Unused modules can be unloaded on demand if required to free up space.
The only debugger we have ever used with Astrobe Oberon code is the one included with LPCXpresso. However that was only required to debug assembler-level code when we were working on the code generator of the compiler and were potentially generating invalid instructions and code sequences. With Oberon unless you deliberately go out of your way to break it, you rarely experience the weird and wonderful runtime errors that you frequently encounter when working with C. In our experience when developing realtime embedded applications in Oberon if the runtime error trap handlers can't pinpoint the errors for you, the chances are that you need a scope to work out what is going on.
To get the sort of flexibility you want you would need to use the Workstation or Embedded FPGA-targeted versions of Astrobe. These include the realtime tasking OS known as Project Oberon 2013. No static module linking is required. Tasks consist of related groups of compiled modules. Each module can contain one or more commands (i.e. parameterless procedures). When a command is invoked at runtime, either interactively or programmatically, the corresponding compiled object file for the module, and any dependent module that is not already loaded, is automatically loaded. If dependent modules(s) are already resident in memory these are automatically reused with their existing global context. Unused modules can be unloaded on demand if required to free up space.
The only debugger we have ever used with Astrobe Oberon code is the one included with LPCXpresso. However that was only required to debug assembler-level code when we were working on the code generator of the compiler and were potentially generating invalid instructions and code sequences. With Oberon unless you deliberately go out of your way to break it, you rarely experience the weird and wonderful runtime errors that you frequently encounter when working with C. In our experience when developing realtime embedded applications in Oberon if the runtime error trap handlers can't pinpoint the errors for you, the chances are that you need a scope to work out what is going on.
Re: STM32 target practicability question
Thanks. I just placed my order for the professional edition for the Cortex M3.
I'll see how I get on with that first.
I'll see how I get on with that first.