[Deprecated: old core]Introducing the new delivery for STM

Wi6Labs
Mon Sep 19, 2016 8:35 am
Hello Everybody

It’s nice to see the interest of the community about our job on porting the STM32 on Arduino. :D

We would like to introduce our job and to respond to your questions about our choices of implementation.

First of all, the goal of the delivery is to provide the same functionalities that you can have when you buy an arduino Uno and that you need to launch the sketches.
We tried to build something generic and not too much hard to customize.

We decided to divide the project in 2 parts:
-The lib that contains the access to the drivers and to the MCU configuration. The library contains the STM32 HAL. It is compiled independently.
ST requested to use the HAL as it is maintained by the ST teams so you can easily integrate new functionalities :).
-The arduino core with the Wirish interface and the variant.

Their should not have any direct reference to the Hardware registers into the arduino core.

We clearly understand the questions about the memory footprint but this project is a compromise to make the STM32 HAL work the more efficiently with the arduino core, the simpliest way.

So if you have any questions, don’t hesitate and we will try to respond.

BR

Wi6Labs team


RogerClark
Mon Sep 19, 2016 10:08 am
Welcome Wi6Labs

Thanks for posting, I think it will be very useful if we can ask questions about the software you wrote.

We have some questions about how to add more boards from the same MCU series e.g. STM32F1

The old “LibMaple” core supported the STM32F103Cx , STM32F103Rx. STM32F103Vx and STM32F103Zx series

@rickKimbal has started to add a “BluePill” board (STM32F103C8) to the F103 core, but we realised that there were differences in the hw_config and we had to move this file from libstm32f1 to the variant folder.

This is discussed in 2 threads

http://www.stm32duino.com/viewtopic.php?f=48&t=1407

and

http://www.stm32duino.com/viewtopic.php?f=48&t=1406

Also. One thing we need to add is USB CDCACM, I don’t think any of the Nucleo boards have a direct USB connection, but most F103 boards make use of the built in USB port and we have a bootloader we use to upload.

BTW
I think perhaps I should move this whole thread to this section http://www.stm32duino.com/viewforum.php?f=48 as its dedicated to your work ;-)


Rick Kimball
Mon Sep 19, 2016 8:31 pm
@Wi6Labs Do you plan on doing any more changes to the STM32F1 core?

Rick Kimball
Mon Sep 19, 2016 8:51 pm
Wi6Labs wrote:
We decided to divide the project in 2 parts:
-The lib that contains the access to the drivers and to the MCU configuration. The library contains the STM32 HAL. It is compiled independently.
ST requested to use the HAL as it is maintained by the ST teams so you can easily integrate new functionalities :).
-The arduino core with the Wirish interface and the variant.

Their should not have any direct reference to the Hardware registers into the arduino core.
Wi6Labs team


Rick Kimball
Mon Sep 19, 2016 8:56 pm
RogerClark wrote:
Also. One thing we need to add is USB CDCACM, I don’t think any of the Nucleo boards have a direct USB connection, but most F103 boards make use of the built in USB port and we have a bootloader we use to upload.

RogerClark
Mon Sep 19, 2016 9:18 pm
Rick,

Frederic posted a list of the board they intend to support, but it only looked like one board per MCU series.

I will email Laurent, who is team leader for this at STM, as Frederic may now be away on paternity leave.

I think we will need to wait until tomorrow for a response from Wi6Labs, because its getting on for midnight in France

Btw. One other thing I noticed is that the pin names seem to be set using #defines, rather than enum.
If Wi6 are not doing any more work on the F1 core, I agree that more radical changes will be needed.


Wi6Labs
Tue Sep 20, 2016 7:36 am
Roger,

ST developed the NUCLEO board support for:

  • STM32F103RBT6 STM32F303RET6 STM32F429ZIT6 STM32L476RG STM32F091RCT6 STM32L053R8T6

As you know these boards are hardware compatible with Arduino architecture. Now they are also software compatible.
As we said in previous post our goal is to provide generic interfaces to link the Arduino world with the STM32Cube world.
We understand there are multiple ways to implement such kind of “glue”. But we decided to make something very easy to use with the Arduino IDE.

We have some questions about how to add more boards from the same MCU series e.g. STM32F1

The old “LibMaple” core supported the STM32F103Cx , STM32F103Rx. STM32F103Vx and STM32F103Zx series

If you want to support other STM32 series we advice you to modify the library (libstm32f1). You can generate an archive with the makefile in build_gcc (some modifications are required). If you need more information on how to generate archive, we can help you.
Please also check the system/Drivers/CMSIS/Device/ST/STM32F1xx/Include for the list of supported boards.

Rick,

@Wi6Labs Do you plan on doing any more changes to the STM32F1 core?

Only if there is bug in the Arduino IDE for the STM32F103RB.

BR

Wi6Labs team


RogerClark
Tue Sep 20, 2016 8:20 am
Thanks @Wi6Labs

RogerClark
Tue Sep 20, 2016 11:44 am
@wi6Labs

is possible can you read this thread

viewtopic.php?f=48&t=1407&start=40

There are already some questions about how we can add support for F103Vx and F103Zx series boards.

It looks like the code in libstm32f1 does not handle GPIO Ports, D E F or G, so we will need to update multpile files e.f. digital_io.c to add support for these GPIO ports ( the same probably applies to MCUs with more USARTS and also some F103 MCUs have UART as well as USARTS.

To create create a new variant, it looks like we may need to make a complete copy of libstm32 F1 ( in the system folder), but this is not ideal, as it will lead to a duplication of a lot of functions, which will be identical in many different boards.

So it alos looks like we woll need to split the global initialisation structures from inside files like digital_io.c and perhaps make a new file e.g digital_io_config.h which contains the global definitions structure.

I realise Wi6Labs will not be making any additional variants, but it would be very helpful if you could answer questions related to the code design etc, and perhaps suggest methods so we can support multiple additional MCUs in each series.

Thanks

Roger


Slammer
Tue Sep 20, 2016 12:29 pm
There is no problem to implement GPIO for as ports we like, eg PA, PB, PC, PD, PE, PF, etc…. in the library.
It is easy to check if a specific port is defined, as HALMX defines the peripheral bases if the peripheral exists. As I can see, some ifdef’s are needed if we have to keep the same source files for GPIO, UARTS, etc at least for the checking of a peripheral existence. I know that you dont like ifdef’s but the other way to have multiple versions of library is the worst thing we could make.

Rick Kimball
Tue Sep 20, 2016 1:01 pm
Question about the stack configuration for @Wi6Labs

In the STM32F1 core, can you explain how the stack is used? If I look at the linker file:
https://github.com/stm32duino/Arduino_C … ASH.ld#L49

The variable _estack is set to an address in the middle of RAM.
_estack = 0x20001FFF;

In addition, it is an odd address instead of even.

Why isn’t this variable set to the actually top of RAM (0x20005000) ?

-rick


Wi6Labs
Wed Sep 21, 2016 1:02 pm
Rick,

It is a mistake. __estack must be set to 0x20005000, the last address of the SRAM.
We will report it to ST who will push the patch soon.

Thanks Rick.

Wi6Labs team


Rick Kimball
Wed Sep 21, 2016 3:30 pm
@Wi6Labs

What would be the best way of adding a new variant that has different pin assignments than the variants you are supplying?

[Note:] I did read your previous answer and was looking for verification that that is indeed your solution.

You seem to say that for each board we need to create a new library? Pins seem to have their attributes described in both the variant directory and the library directory. You can’t just redefine an analog pin with PWM to use another pin in the variant.cpp file, it has to also match the information in the analog.c in the library directory.
[/Note]

-rick


Wi6Labs
Fri Sep 23, 2016 11:54 am
Roger / Rick,

To answer to your questions how to add a new board:

Firstly, the project is base on Nucleo boards, so there is some feature not implemented in the core code (under system/libstm32f1).
So, you need to add some code in sources (as you have already done). You should create a new folder in variant for each board added. And you should generate the library for the new board (there is a makefile in system/libstm32f1/build_gcc). This makefile must be completed with the options of the new board.
Finally, to use the board with Arduino, you should complete the board.txt with the parameters of the new board.

You seem to say that for each board we need to create a new library? Pins seem to have their attributes described in both the variant directory and the library directory. You can’t just redefine an analog pin with PWM to use another pin in the variant.cpp file, it has to also match the information in the analog.c in the library directory.
You are limited in pin functions. So we need to define also in analog.c the pin configuration. In variant.cpp you just signal to Arduino how the pin can be used.

BR
Wi6Labs team


stevestrong
Fri Sep 23, 2016 1:41 pm
What is actually the “pins assignment” meaning? Is it the pinout of the respective board?
So, for instance, if I have two boards with the same chip (let’s say: STM32F407VET6), do I really have to make a new folder for each board variant?
Wouldn’t be more effective to separate the chip variants, and not the board variants?
I mean, when I am using the GPIOs, I always use the “PAx” style, so that even if the board is different, I get the same functionality for the same pin when the same chip is used.
Or am I missing something?

Wi6Labs
Fri Sep 23, 2016 2:51 pm
stevestrong,

In the Arduino spirit you have one folder by board.
In your case, we understand that the hardware of your boards (that use the same chip) is different.
So we advice you to create 2 folders in variant.
Maybe it is not the best way in your case but we are opened for other solution from the community.

Wi6Labs team.


Rick Kimball
Fri Sep 23, 2016 3:11 pm
@Wi6Labs

What if I wanted to add all the pins on the Nucleo boards and use the Morpho header with the Arduino core. What would be the best way to accomplish that?

I guess what I’m getting at, in a a round about way, is that the way the library and variants work together isn’t optimal. The library has pin knowledge. I contend that any pin knowledge should only be known by the variant. I’m suggesting that the library should be just that, a set of routines that can be used with any variant and any set of pin descriptions for the same chip. Any thoughts on that?

-rick


Ollie
Fri Sep 23, 2016 3:39 pm
Rick, I do completely agree with you. The library should be available for any variant. Most of the “board” functions should be just for mapping the physical chip pins to items on the board, such as internal components or exposed pins.

+++ Ollie


RogerClark
Fri Sep 23, 2016 8:34 pm
Guys

I had a couple of emails from STM and Wi6Labs, and basically it appears that Wi6 were only requested to create a system to handle Nucleo boards and hence had not designed a very flexibly architecture.

They sent me the handover document (which they said is confidential), but it doesn’t contain anything that we don’t already know, as its intended audience appears to be anyone that doesn’t know about the Arduino IDE and the structure of the third party cores.

I’d really like to get the first pass BluePill code into the repo this weekend, so I suppose I could just action Rick’s PR, but I’m still inclined to take a complete copy of libstm32 and make libstm32f103cx so that BluePill can be a variant of this, as could Maple mini


Rick Kimball
Fri Sep 23, 2016 8:49 pm
RogerClark wrote:
… but I’m still inclined to take a complete copy of libstm32 and make libstm32f103cx so that BluePill can be a variant of this, as could Maple mini

RogerClark
Fri Sep 23, 2016 9:01 pm
Thanks Rick

danieleff
Sat Sep 24, 2016 4:35 am
Wi6Labs wrote:Roger,

ST developed the NUCLEO board support for:

  • STM32F103RBT6 STM32F303RET6 STM32F429ZIT6 STM32L476RG STM32F091RCT6 STM32L053R8T6

Wi6Labs team


RogerClark
Sat Sep 24, 2016 5:45 am
Daniel

The only source code released by STM, so far, has been for the Nucleo F103RB and the Nucleo L4 boards

My understanding is that they will release the source code for the other boards they listed, but that’s all they are going to do.
There are no plans to create “boards” (variants) for the Discovery series boards, let alone any generic boards or the Maple mini etc.

Unfortunately, it seems that the structure of the STM Core has not been designed with supporting mutliple boards using variants of the same MCU.

So we are going to have to work out how to do this ourselves, and probably re-factor the code.
But of course we need to try to not break the operation of the Nucleo boards which STM have already tested and verified is working.

Hence I’m in the process of making complete copies of the folder that is used to generate the Nucleo F103RB, so that we can make radical modifications to it if necessary.

Note. Actually, we’ll need to change the Nucleo F103RB code as well, as Rick has already found an error in the linker file.
But I expect we will keep changes to a minimum so that they are only bug fixes.


RogerClark
Sat Sep 24, 2016 12:21 pm
See http://www.stm32duino.com/viewtopic.php … 227#p18227

Pito
Sat Sep 24, 2016 12:27 pm
I doubt STM will pay a single cent to someone to support boards other than Nucleos or Discovery..

RogerL
Mon Sep 26, 2016 3:56 pm
I have been away off-grid for the last week so have missed most of the excitement. I have a couple of questions:

I see the Nucleo STM32L476RG is one of the supported boards. Has anyone on here got one working with the new core?

What is the situation with libraries. If I wanted to use, say, existing Arduino wire, MIDI and I2C LCD libraries, are they likely to work without too much hassle?

Sorry if these are basic questions. I was about to start a new project based on a Mega 2560 board but am concerned about whether I will have enough program space so am reviewing my options. My current STM32 experience is limited to loading blink programs on F103 boards.


RogerClark
Mon Sep 26, 2016 9:04 pm
I dont think one person may have tried the L4 nucleo, but I cant remember who.
( but I could be mistaken)

STM said they would send me a few boards to test with, but they seem to have got lost in the post :-(

Re:Libraries

I dont think anyone has tested them yet, but the Core comes with the standard libs like Wire and SPI.
But no USB support at all.
I’m currently working on adding USB serial, but to get all the USB devices working well, actually requires quite a major overhaul of the STMCubeMx generated code, as we need a Composite USB device and I dont think the Cube has an option to generate example code like that.

I am sure we could get individual USB devices, like MIDI and HID working one at a time, but this is far from ideal


Slammer
Mon Sep 26, 2016 9:09 pm
I am working with L4 series but for now I didn’t test much of the ST core, some basic I/O, simple serial and some I2C devices.
The L476 is an exceptional MCU (my favorite STM32 MCU) and you can test also the core of GrumpyOldPizza from http://www.stm32duino.com/viewtopic.php?f=42&t=1092
It is for a custom L476 board (dragonfly), it is very well written, on top of CMSIS (optimized), with complete core functions (and more than that), definitely a very good piece of code.

More for DragonFly (photos, schematics, pcb) here: https://www.tindie.com/products/onehors … ent-board/


Ollie
Mon Sep 26, 2016 11:35 pm
Slammer,

What are the features and functionality in Dragonfly STM32L4 that you like in comparison to Teensy 3.2/3.5/3.6? They are in same price range, but Teensy has more I/O, higher performance, and excellent S/W libraries.

Cheers, Ollie


RogerClark
Tue Sep 27, 2016 12:54 am
Ollie wrote:

What are the features and functionality in Dragonfly STM32L4 that you like in comparison to Teensy 3.2/3.5/3.6? They are in same price range, but Teensy has more I/O, higher performance, and excellent S/W libraries.

Cheers, Ollie


Slammer
Tue Sep 27, 2016 1:40 am
I don’t have Dragonfly or Teensy board, just a L476-Nucleo and the L476 is the MCU of my choice for a custom board under development. For this reason I am evaluating code and hardware as I am studying the chip. I think that any new design must be based on new STM32 chips, like L475/6 or L431/2 as they offer many and improved peripherals, large memories, good performance and very good value.

RogerClark
Tue Sep 27, 2016 2:20 am
It would be good if Baite or Vcc-Gnd started producing a small board using those devices

RogerL
Tue Sep 27, 2016 9:50 am
Thanks for your comments guys.

The Dragonfly board looks interesting, but the price for a board delivered to the UK is 45 UK pounds (with probable additional customs charges on top) —- a bit over my budget for this project. I can get a Nucleo STM32L476RG board for 11 UK pounds from Farnell, so that’s a better option for me if I can get it to output MIDI and support a 1602 LCD or other small display device.

Edit: Just to clarify, I don’t need MIDI over USB —- I just plan to wire the TX pin to a 5-pin MIDI jack.


GrumpyOldPizza
Tue Sep 27, 2016 4:23 pm
Ollie wrote:Slammer,

What are the features and functionality in Dragonfly STM32L4 that you like in comparison to Teensy 3.2/3.5/3.6? They are in same price range, but Teensy has more I/O, higher performance, and excellent S/W libraries.

Cheers, Ollie


GrumpyOldPizza
Tue Sep 27, 2016 4:34 pm
RogerL wrote:Thanks for your comments guys.

The Dragonfly board looks interesting, but the price for a board delivered to the UK is 45 UK pounds (with probable additional customs charges on top) —- a bit over my budget for this project. I can get a Nucleo STM32L476RG board for 11 UK pounds from Farnell, so that’s a better option for me if I can get it to output MIDI and support a 1602 LCD or other small display device.

Edit: Just to clarify, I don’t need MIDI over USB —- I just plan to wire the TX pin to a 5-pin MIDI jack.


RogerL
Tue Sep 27, 2016 5:19 pm
GrumpyOldPizza wrote:
Sorry about the pricing. Perhaps we’ll do a cheaper board with a L433 or such. Please keep in mind that STM’s Nucleo boards are sold below cost. It’s kind of hard to compete against that.

Slammer
Tue Sep 27, 2016 5:34 pm
Additionally Dragonfly and Teensy are high density 4 layers boards, much more expensive than 2 layers….

danieleff
Wed Sep 28, 2016 10:55 am
RogerL wrote:
What is the situation with libraries. If I wanted to use, say, existing Arduino wire, MIDI and I2C LCD libraries, are they likely to work without too much hassle?

RogerClark
Wed Sep 28, 2016 11:20 am
danieleff wrote:

Will there be a define that can be used to ifdef in the libraries, like there are already ifdefs used for ESP8266, Teensy…?

GrumpyOldPizza
Wed Sep 28, 2016 3:38 pm
RogerClark wrote:danieleff wrote:

Will there be a define that can be used to ifdef in the libraries, like there are already ifdefs used for ESP8266, Teensy…?

RogerClark
Wed Sep 28, 2016 9:49 pm
I only used the underscores as this was the Arduino standard at the time ( as far as I could see).

But perhaps they are redundant


zmemw16
Thu Sep 29, 2016 9:47 pm
i’ve always thought they were from a coding standard for defining ‘system’ aspects.
the underscores help their uniqueness, but i’m never sure whether it should be one or two of those. :D

stephen


danieleff
Mon Oct 03, 2016 11:16 am
The F1 code uses HAL_GetTick() for millis() calculation but the L4 uses the TIM5 timer in clock.c. Why is that?

RogerClark
Mon Oct 03, 2016 8:17 pm
Interesting

I wonder if my drystone test results are correct as the show a 80MHz L476 is considerably slower than a 72MHz F103 ( albeit the F103 tests use libmaple and the L4 use STM’s HAL based core)

Perhaps an interrupt is wasting a lot of processing power, or the millis() isnt accurate on the L4 core


Wi6Labs
Tue Oct 04, 2016 2:37 pm
danieleff wrote:The F1 code uses HAL_GetTick() for millis() calculation but the L4 uses the TIM5 timer in clock.c. Why is that?

edogaldo
Tue Oct 04, 2016 4:02 pm
Wi6Labs wrote:ST developed the NUCLEO board support for:

  • STM32F103RBT6 STM32F303RET6 STM32F429ZIT6 STM32L476RG STM32F091RCT6 STM32L053R8T6

Wi6Labs
Wed Oct 05, 2016 1:31 pm
edogaldo wrote:Wi6Labs wrote:ST developed the NUCLEO board support for:

  • STM32F103RBT6 STM32F303RET6 STM32F429ZIT6 STM32L476RG STM32F091RCT6 STM32L053R8T6

RogerClark
Wed Oct 05, 2016 8:00 pm
I think the Arduino ARM based boards e.g. the Due, use systick for millis()

So perhaps this is the norm for Arduino cores. ( libmaple also uses systick for millis())

If systick is available, it seems the logical way to maintain a millisecond counter as there is no MCU CPU overhead for this operation.
I.e the MCU hardware prescales the master clock and then auto incremenets a register.

I wonder what other use systick is performing on the L4 core if its not counting millis()

I presume it must be doing something else, otherwise a general purpose timer is being wasted for millis() when it could be used for something else


Slammer
Wed Oct 05, 2016 9:16 pm
Specially for the arduino API, I dont find a reason not to use systick. Arduino’s millisecond timer is an always-on timer with fixed period.
Systick is not available on all ARM cores but all members of STM32 family have systick, so, it is not problem to use it globally.

RogerClark
Wed Oct 05, 2016 11:08 pm
@slammer

Do the Cortex M0 also have it ?

I know the nRF51822 Cortex M0 does not have systick, but this is probably something to do with the nRF51 hardware and not that its a Cortex M0


Slammer
Wed Oct 05, 2016 11:42 pm
SysTick is an optional part of Cortex design, but I think that all STM32’s even the smallest members of F0x0 they have it.

GrumpyOldPizza
Thu Oct 06, 2016 12:13 pm
RogerClark wrote:@slammer

Do the Cortex M0 also have it ?

I know the nRF51822 Cortex M0 does not have systick, but this is probably something to do with the nRF51 hardware and not that its a Cortex M0


RogerClark
Thu Oct 06, 2016 8:28 pm
Interesting point about the power to run the timer.

That is a considerable amount of current for a low power device.

I dont suppose there is any point changing this for the Nucleo L4 but on the other boards, If Wi6 decide to use a timer for millis, I think we will probably end up changing it back to using systick


mailhouse
Sat Nov 05, 2016 12:50 am
Should this crash the board? nucleo-64 stm32f103rb and stm32l476rg show same behavior
void TIM2_IRQHandler(void) {
if (TIM2->SR & TIM_SR_UIF)
{
Serial.println("TIM2 Interrupt");
}
TIM2->SR = 0; // reset the status register
}

void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
delay(3000); // open your serial console already

RCC->APB1ENR |= RCC_APB1ENR_TIM2EN; // enable TIM2 clock

TIM2->PSC = 36000; // clock speed should be 72MHz, so 72MHz/36000 = 2KHz
TIM2->ARR = 2000; // 2KHz clock/2000 = 1Hz so interrupt handler should run once a second
TIM2->DIER |= TIM_DIER_UIE; // enable update interrupt
NVIC_EnableIRQ(TIM2_IRQn); Serial.println("Interrupt set");
TIM2->CR1 |= TIM_CR1_CEN; // counter enabled
Serial.println("Timer 2 enabled");
}

void loop() {
// put your main code here, to run repeatedly:
Serial.println(TIM2->CNT);
delay(50);
}


danieleff
Thu Nov 24, 2016 11:46 am
@Wi6Labs what is the reason for
uint32_t apin = ulPin&0x0000000F;

RogerClark
Thu Nov 24, 2016 8:33 pm
sounds like several issues going on.

1. Crash when using timers.

2. Limiting analog pins to low pin numbers

3. HAL_Delay not workinb correctly on the L4

Re:2

I guess this was put in for Nucleo boards. But i am not sure what purpose it performs, i.e it turns pin 16 into pin 0 etc

I am not sure what happens on an AVR Arduino board if you do an analogWrite on pin 16


nikosx
Tue May 09, 2017 6:19 am
Hello.
I am using STM32F1xx Cores 2017.1.20 with an STM32 VL Discovery STM32F100RB. Having problems with using integrated DAC channels.
I’ve used both dac_write_value & analogWrite but with no results (code stucks or does nothing), even when i did some changes in g_current_init_id of analog.c

However, ADC functions work OK !!!

Think the DAC code is incomplete. What’s the situation ?

Thanks,
Nick


edogaldo
Tue May 09, 2017 7:04 am
You sure STM32F100RB has DAC?!
Afaik only HD mcus (from xC on) have DAC..

nikosx
Tue May 09, 2017 1:44 pm
YES !! it has 2 DAC outputs (dual DAC). It’s both in the STM32VLDISCOVERY board manual Fig 6, block diagr. 12 bit DACs, table 4pinout, PA4 DAC1, PA5 DAC2, also same info in STM32F100xx ref. manual….
Also, there IS code inside analog.c …..

nikosx
Tue May 09, 2017 1:46 pm
Sorry, didn;t understand the HD mcu …..

edogaldo
Tue May 09, 2017 7:13 pm
nikosx wrote:Sorry, didn;t understand the HD mcu …..

ag123
Tue May 09, 2017 7:41 pm
stm32f103RBT6 (Medium density) is just 1 point lower than stm32f103RCT6 (High Density)
http://www.st.com/en/microcontrollers/s … tId=LN1565
and the high density version has DAC, i did have a stm32f103rbt6 board https://www.olimex.com/Products/Duino/S … INO-STM32/ as well, no DAC, the only good thing is more of the gpio and afio pins are broken out hence more functions are accessible compared to say stm32f103c8t6 or stm32f103cbt6 (the blue pill / maple mini)

nikosx
Tue May 09, 2017 9:48 pm
οκ!

nikosx
Sat Sep 16, 2017 8:42 pm
Hello.

Got a new nucleo 64 with an STM32F103RB (apart from the L476) and trying to port a program from an M4 TI Arm chip – same arduino framework…. Part of the code using serial for GPRS interfacing works OK. However i’m trying to find out Timer’s use and libs (not HAL) to help with this as -compared to the other ARM chip the timers low level use is much more complicated…

Any help with this ?

thanks


nikosx
Mon Nov 06, 2017 4:56 pm
Is there any (generic or specific) guide or code to use timer interrupts with STM core, in one -shot or periodic mode ?
Thanks !

ChrisMicro
Mon Nov 06, 2017 8:11 pm
I don’t know because I used the timer only in the STM32GENERIC framework:

https://github.com/ChrisMicro/STM32GENE … neWave.ino


fpiSTM
Tue Nov 07, 2017 8:39 am
Currently there are no API.
It’s planned to extend TIMER API.
Anyway, as @ChrisMicro shows in its example you could use directly the HAL to use a timer.

nikosx
Tue Nov 07, 2017 9:15 am
Thank you very much !! Thanks ChrisMicro for the code. I’ll give it a try…. It’s OK using HAL as it works…
I’ve used HAL before but i had problems compiling with the callback function…

Off to try the code….

Nick


nikosx
Tue Nov 07, 2017 9:51 am
Unfortunatelly it does not compile and gives an error

(Arduino IDE)
timer.c:(.text.TIM3_IRQHandler+0x0): multiple definition of `TIM3_IRQHandler’

sketch\sketch_nov07a.ino.cpp.o:sketch_nov07a.ino.cpp:(.text.TIM3_IRQHandler+0x0): first defined here

or VS Arduino
Timer1F030.ino:25:17: error: conflicting declaration of ‘void TIM3_IRQHandler()’ with ‘C’ linkage
Timer1F030.ino:previous declaration with ‘C++’ linkage

work is done in Nucleo F030RB with STM core…. i think the code you have is not with STM core….

as far as i remember i had similar problems with Timer handler declaration in the past…. first time i tried to use HAL for timers…


nikosx
Tue Nov 07, 2017 9:55 am
My problem is how to reference Timer Interrupt Handle and not get an error….. In the past i managed to setup timer to count (with HAL) but i could not have access to Timer handle to do some usefull job….

nikosx
Tue Nov 07, 2017 9:57 am
@fpiSTM : What’s the correct way to reference TIM3_IRQHandler in the code and not get an error ?

fpiSTM
Tue Nov 07, 2017 10:46 am
Hum, currently none as it is defined in the timer.c of the core.

As a workaround, you can comment this one in the core:
https://github.com/stm32duino/Arduino_C … er.c#L1077

then it should be ok.
As said it will be extended and more user friendly.


nikosx
Tue Nov 07, 2017 12:09 pm
Thanks again !!!

there should be something, else why the compiler is complaining ??? :)

i’ll give it a try…


nikosx
Tue Nov 07, 2017 12:20 pm
line 1077, timer.c :

void TIM3_IRQHandler(void)
{
if(timer_handles[2] != NULL) {
HAL_TIM_IRQHandler(timer_handles[2]);
}
}


nikosx
Tue Nov 07, 2017 12:27 pm
Found 2 time.c, put code in comment, same error….

where this file should be ?


fpiSTM
Tue Nov 07, 2017 3:41 pm
could you provide the sketch you used.
In fact the error is that the TIM3_IRQHandler(void) is already defined in the core.
As it is a weak one, you should be able to comment it.

nikosx
Tue Nov 07, 2017 4:16 pm
Ok…. Does NOT compile for VS 10 + VS Arduino but it did compile and run OK for ARDUINO IDE…
it also workd OK
code below

// for ARDUINO to compile
// timer.c in
// C:\Users\Nick\AppData\Local\Arduino15\packages\STM32\hardware\stm32\2017.8.31\cores\arduino\stm32
// commend TIM3_IRQHandler

static TIM_HandleTypeDef s_TimerInstance =
{
.Instance = TIM3
};

extern “C” void TIM3_IRQHandler(void)
{
static boolean flag = false;
static int32_t index = 0;

if (__HAL_TIM_GET_FLAG(&s_TimerInstance, TIM_IT_UPDATE) != RESET)
{
__HAL_TIM_CLEAR_IT(&s_TimerInstance, TIM_IT_UPDATE);
if (flag)
{
digitalWrite(LED_BUILTIN, HIGH);
flag=0;
}
else
{
digitalWrite(LED_BUILTIN, LOW);
flag=1;
}
}
}

void setup()
{
pinMode(LED_BUILTIN, OUTPUT);

HAL_NVIC_SetPriority( TIM3_IRQn, 0, 0 );
HAL_NVIC_EnableIRQ ( TIM3_IRQn );

s_TimerInstance.Init.Prescaler = 48000; //APB1 TIM3 has 48Mhz

s_TimerInstance.Init.CounterMode = TIM_COUNTERMODE_UP;
s_TimerInstance.Init.Period = 100-1; // prescaler gives 2khz time base
s_TimerInstance.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
s_TimerInstance.Init.RepetitionCounter = 0;

__HAL_RCC_TIM3_CLK_ENABLE();

HAL_TIM_Base_Init ( &s_TimerInstance );
HAL_TIM_Base_Start_IT ( &s_TimerInstance );
}

void loop()
{

}


nikosx
Tue Nov 07, 2017 4:19 pm
it became very close to code i’ve tried before in VS arduino and got the same error as today

TestF030.ino:31:17: error: conflicting declaration of ‘void TIM3_IRQHandler()’ with ‘C’ linkage
TestF030.ino:previous declaration with ‘C++’ linkage
Error compiling

Thing is VS is so much better / faster than Arduino IDE and (apart from this timer issue) works OK with ST nucleo boards….
still could not find the file that uses to change as did with arduino….


nikosx
Tue Nov 07, 2017 6:59 pm
The only way to compile in VS is to make it

extern “C++” void TIM3_IRQHandler(void)

but in this case, code does NOT run !!!!!


Rick Kimball
Tue Nov 07, 2017 7:08 pm
It would be nice if you split this conversation over to a new thread nikosx. Your issues have little to do with the STM core and all to do with your choice of development tools along with misunderstanding of C vs C++ name mangling and linking.

nikosx
Tue Nov 07, 2017 9:14 pm
Hi Rick.

Yes i’m not an experienced C++ programmer….

I put here the problem since i’m using STM core and not some other framework that handles timers in another way….

As far as i can see STM core does not have yet API for timer’s use but has internal definitions that pose problems even using HAL to have timer & interrupts… It seems to me the problem is not that easy to solve…

I don’t know somewhere else to put it since it refers only to STM core…. Have you something in mind ?


Rick Kimball
Tue Nov 07, 2017 9:22 pm
[nikosx – Tue Nov 07, 2017 9:14 pm] –
I don’t know somewhere else to put it since it refers only to STM core…. Have you something in mind ?

Yes start another thread in this forum subsection and title it: “Problems using STM core with Visual Studio 10”

The minute you mentioned this:
nikosx wrote:Ok…. Does NOT compile for VS 10 + VS Arduino but it did compile and run OK for ARDUINO IDE…
it also workd OK


fpiSTM
Thu Nov 09, 2017 10:26 am
Rick is right. It should be in a dedicated topic.

Anyway, I’ve tested your sketch.
So, first issue is the multiple definition of the TIM3_IRQHandler.

I think the best fix is to define it as WEAK.
I’ve tested and it is ok.

extern “C” is mandatory to avoid any c++ function name decoration.


nikosx
Thu Nov 09, 2017 4:37 pm
Hello.

a) Where do you think should the topic be ?

b) I know extern “C” is mandatoty but where should the WEEK be put ?

thanks


Leave a Reply

Your email address will not be published. Required fields are marked *