Arduino for STM32

thanks, how naive am i
it seemed it is in the libraries, i'm not too sure if that is after all the issue. either way it builds just fine
wow a huge function, cross sku codes isn't easy

i tried defining VECT_TAB_SRAM, it freezes. i did not attempt a debug.
but my guess is that 2 more things are needed.
- reserve space in sram for the vector tab, i'd guess this needs to be edited in ldscript, not sure how
i'm thinking perhaps reserve it as a c/c++ static array and change the VTOR pointer to there
not sure if there is an existing structure that can be used
i'm not sure what else are the implications, e.g. where else to update so that all the functions would patch the same vector tab in sram
i think another way is to define VECT_TAB_OFFSET so that it sits at the top of sram
but i'd need to move the stack pointer down so that the stack would not clobber the vector tab, not sure how
- copy the vector tab from flash into sram.
- change VTOR to point to sram vector tab

these changes probably need to be done deep down in SystemInit() in system_stm32fyyxx.c
doesn't sound like there is a portable way to do this, except for that possible way using a c/c++ array or structure

i dig a little deeper into HAL adc dma conversion, it turns out HAL has an implementation for it

HAL_ADC_Start_DMA(ADC_HandleTypeDef* hadc, uint32_t* pData, uint32_t Length)
https://github.com/stm32duino/Arduino_C ... dc.c#L1338

initially i'm wondering why the conversion call back looks like an no op implemention
__weak void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc)
https://github.com/stm32duino/Arduino_C ... dc.c#L1529

it turns out these functions seem to be provided for user to *override* !
so ADC_Start_DMA actually patches callbacks to the exact function HAL_ADC_ConvCpltCallback()
https://github.com/stm32duino/Arduino_C ... dc.c#L1407

what that probably means is that somehow HAL would call user code back? the irony is that, the dma interrupt vector call back
is still patched to a default handler
https://github.com/stm32duino/Arduino_C ... 1xc.s#L313

so i'm still missing the dots some where

it seem that the loop need to be closed this way
found an article
https://community.st.com/s/question/0D5 ... rq-handler

it seemed something like define an irq handler and the dma handler structure needs to be passed to HAL_DMA_IRQHandler()
https://github.com/stm32duino/Arduino_C ... dma.c#L747

so the user defined dma irq handler void DMA1_Stream1_IRQHandler(void)
needs to be updated in the interrupt vector table
https://github.com/stm32duino/Arduino_C ... 1xc.s#L313

it seemed difficult to make this 'portable' as the vector tables etc is almost bound to hardware and varies somewhat between skus
f4xx probably use same/similar, but won't be same as m3 f103

@kvv213

Here an example of ADC and DMA usage:
viewtopic.php?f=41&t=110

fpiSTM wrote: Thu Jan 16, 2020 5:31 pm @kvv213

Here an example of ADC and DMA usage:
viewtopic.php?f=41&t=110

Thank you, will try over a week.

ag123 wrote: Wed Jan 08, 2020 11:22 am it seem that the loop need to be closed this way
found an article
https://community.st.com/s/question/0D5 ... rq-handler

it seemed something like define an irq handler

Code: Select all

    void DMA1_Stream1_IRQHandler(void)
    {
	    HAL_DMA_IRQHandler(AdcHandle.DMA_Handle);
    }

....

Just my opinion:
STM32duino (Official) is a fantastic software product that is positioned to allow ArduinoIDE knowledgeable programmers to easily move from traditional Arduino hardware to STM32 hardware. It may also permit non-programmers a stepping stone methodology to directly approach low-cost STM ARM hardware.

Users that represent the professional programming community will most likely avoid the ArduinoIDE and simply move directly to the freely available STM downloadable tools. Therefore, access to the HAL and other supporting functions and structures are natively available and expertly documented.

Novice/hobby users using the ArduinoIDE are best served by using the STM developed ''wrappers" which represent Arduino functionality as documented here: https://www.arduino.cc/reference/en/

(I believe) Using the ArduinoIDE to write sketches that make direct calls into the CMSIS or HAL is inappropriate. It is at this point where you need to decide if you want to really move forward and learn to program and to dedicate some effort in learning to use the professional tools and development environment appropriate to the advanced microcontroller.

Red pill path:
https://www.st.com/en/development-tools ... tools.html

Blue pill path:
https://www.arduino.cc/en/Guide/HomePage

@mrburnette
Don't agree with your option, here are my thoughts:

1. You can use Arduino not only with Arduino IDE. For example, I use it with PlatfromIO IDE joined with Visual Studio Code.
2. Working with a great number of hardware it is better to use a single framework instead of 10 different. For example, I work with AVR, ESP8266, ESP32, and now STM32.
3. Arduino in terms of STM32 provides 10 times faster development than, again, for example CMSIS by ARM.
4. All frameworks has errors and limitations. And in such cases you need to dive deeper, for example, from Arduino to HAL, from HAL to CMSIS etc.
5. The higher level framework is the better it can be moved to another hardware. Arduino in that case is the best comparing to other options for STM32 (except, MBED).
6. Arduino code is lighter for development and further supporting. The code is much easy reading and after a year or two after development is finished I don't need to break my brain trying to understand what exactly a concrete piece of code is doing.

So, in my opinion Arduino is the best framework for cross-platform development including complex projects. But only if you use a proper IDE that supports all the modern software development features (code completion, code on-fly check, debugging etc).

To date it is possible to work with STM32 with at least the following frameworks and tools:

• Arduino (Duino & Maple)
• CMSIS
• libOpenCM3
• MBED
• SPL
• STM32Cube (the HAL)
• Zephyr
• and of coruse assembler with its LL registry style work

So a developer is free to use a correct framework that best fits the task needs.

At my current development I have to move from AVR platform (two different chips, not ATMEGA328) to STM32 (and here I had to switch to more advanced chip during development).

PS. Sorry for the flame

kvv213 wrote: Sat Jan 18, 2020 7:46 am @mrburnette
Don't agree with your option, here are my thoughts:
...
At my current development I have to move from AVR platform (two different chips, not ATMEGA328) to STM32 (and here I had to switch to more advanced chip during development).

PS. Sorry for the flame

I expected flames, but that is OK, because I am right; not saying you are totally "wrong" but your viewpoints are myopic. I am retired from a Fortune 10 company. Our IT environment was massive, so our development environment was strict. Most of our software developers had Master Degrees and many had PhD's. In such a world, our hardware platforms were High Availability Virtual Machines with dynamic failover.

Many (if not most) lessons from a Fortune 10 should translate to small companies. First, developers are "told" the tools to be used for a project; which is to say developers are paid to write code, not select development tools. Development tools are selected through an alliance with software companies and (to a degree) with hardware vendors since h/w is selected for specific software workloads.

In your summary, you have mucked Arduino hardware and software and IDE ... actually Arduino in pure form is Arduino designed hardware, the Arduino core files and the ArduinoIDE. Boards such as the Maple Mini or Blue Pill are not Arduino hardware or even "clones" of Arduino designed boards ... they are as foreign as Paul Stoffregen's Teensy line of boards.

STM32duino (official) is a set of software that allows STM32 microcontrollers to perform in the Arduino ecosystem and allows many Arduino available 3rd party libraries to be used - some libraries require enhancement to function correctly. There are no guarantees provided when one deviates from the pure Arduino environment. STM's Arduino cores support most STM manufactured evaluation boards and by kindness a small number of 3rd party boards commonly known as: Maple Mini, Blue Pill, Black Pill, etc. While STM attempts to support the STM32duino core files on the non-STM hardware, it is a best-effort only: no commitment, no guarantee.

1. You can use Arduino not only with Arduino IDE. For example, I use it with PlatfromIO IDE joined with Visual Studio Code.

Yes, but the core-files are unchanged... only the IDE and "build system" are altered.

2. Working with a great number of hardware it is better to use a single framework instead of 10 different. For example, I work with AVR, ESP8266, ESP32, and now STM32.

So you say. Once you depart from Arduino.cc manufactured hardware, are only playing with pseudo-Arduino hardware with software cores mimicking Arduino language commands and functions. Native hardware must be exposed in some manner; such as dropping into a non-Arduino lower level API. Bad practice as you are completely at the mercy of whomever wrote the "closer to the hardware code/driver/enabler."
But, I agree that most Arduino projects like blinking LEDs, temperature sensors, humidity sensors, and so-forth can be easily supported with the ArduinoIDE ...exactly what I stated, non-professional needs should start and stay in ArduinoIDE. Professionals or those aspiring to develop a commercial product should shy away from Arduino (completely.)

3. Arduino in terms of STM32 provides 10 times faster development than, again, for example CMSIS by ARM.

I expect such statements, but it simply is not true unless you are taking some Arduino example code and using that as a starter for your project. Many Arduino users are not programmers (professional sense), rather they are "makers" who can program sufficiently well to incorporate sample code, sensor libraries, and display libraries into a final working project. To all of you reading who take this approach, rejoice since this is why the Arduino ecosystem was created many years ago.

4. All frameworks has errors and limitations. And in such cases you need to dive deeper, for example, from Arduino to HAL, from HAL to CMSIS etc.

No, not all frameworks have errors. Most pseudo-frameworks (wrappers) impose limitations and "makers" may view this as an error; likely it matches the Arduino API and is just restrictive of what the native uC can accomplish.

5. The higher level framework is the better it can be moved to another hardware. Arduino in that case is the best comparing to other options for STM32 (except, MBED).

Arduino is an ecosystem. You talk about moving only the Arduino software functionality - the Arduino API.

6. Arduino code is lighter for development and further supporting. The code is much easy reading and after a year or two after development is finished I don't need to break my brain trying to understand what exactly a concrete piece of code is doing.

This statement is simply incorrect ... if true, we would all be using BASIC.
What should be said is that all IDE's provide mechanisms for including programmer comments and that capability will easily provide for documentation needed in code sections.

In my project folders, I always have a Notes.h page where additional thinking, links, ASCII diagrams can be added. Some environments like Cypress automatically builds the documentation.

My final, thoughts: STM32duino is not Arduino in that it will not provision Arduino.cc official hardware. It is a software wrapper service that hides STM code and creates an API to mimic Arduino sketch capability (syntax) on many evaluation boards that utilize a STM microcontroller. Not all of the uC hardware capabilities may be available to the programmer and some adjustment may be required to 3rd party libraries.

If you "need" to communicate with HAL from your Arduino-sketch, you are in the wrong programming environment.


Ray

Arduino, partly derived from processing and wiring
http://wiring.org.co/

considerably, simplified a beginner's approach getting in touch with mcus. the api has been kept simple in part to achieve the most common denominator across mcus. But more recently some features are creeping into the api (e.g. analogWrite) which to some extent isn't a common feature in mcus.
it is partly emulated using pwm on a r-c output and the luckier ones has a dac. But otherwise, it isn't quite common across the board.

it turns out is sufficient an abstraction to run on (nearly) all mcus, in a sense it is a thread, or perhaps kernel that runs on a thread.
in that loop(), you can hook an event loop, or simply in that way u could emulate (fake) a multi-tasking os.

one of my favourite tricks in stm32duino is that asm("wfi") is to wait for interrupt, so it'd only work on arm based mcus (or cpus). it would otherwise run in a busy loop with 'high' cpu load.
And as it turns out, in the 'old' (original) libmaple core, the arduino api delay() and millis() is implemented using systick, set at 1ms
this 'informal' practice, is enormously useful, especially on these single threaded mcus.
so in this case asm("wfi") is to wait for the systick interrupt

hence, rtos(es) as well, hijacked (hooked) the systick interrupt, and emulates *context switching*. but if you start with the blue pill (stm32f103c8), you have only 20k sram, trying to distribute fixed blocks of memory (e.g. stack) for each thread would ultimately run out of memory in no time.

so that loop() + that asm("wfi"), still works. it is deemed 'cooperative multi-tasking'. i think microsoft made a very early version of windows run that way, the whole of it. i think arduino and other *duinos* trace that pathway, just on mcus.
this event loop is abstracted in that simple loop(), after all node js https://nodejs.org/en/ works that way too

what is the 'big deal' about this loop() approach, it turns out, for all c functions local variables are allocated on the stack & you can keep state in global variables. when the function returns the stack is unwound & you get back your 20k sram, kind of a rudimentary 'dynamic memory management'.
it is kind of why the fatter os-es can't squeeze into the blue pill, while stm32duino runs fine
stm32 is really system on a chip - cpu, dma, gpios, spi, uart,usb, fpu, memory etc all in that one chip