WHICH CORE?!

Post here first, or if you can't find a relevant section!
windyyam
Posts: 9
Joined: Tue Oct 27, 2020 11:56 am

Re: WHICH CORE?!

Post by windyyam »

fpiSTM wrote:
Wed Oct 28, 2020 7:25 am
Try

Code: Select all

digitalWriteFast(PC_13,HIGH);
digitalWriteFast(PC_13,LOW);
Yes that would do the work. But it's a bit tricky as it does not use the same pinname. If someone's really in need for IO speed they probably manipulate port register instead. Just for compatible reasons if digitalWrite with normal Pin name and some optimization flag could do something better than memory look up table that would be the best solution, but for some reasons O2 and LTO seems not working on ST core so I don't know what that will be.

User avatar
fpiSTM
Posts: 848
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 33
Location: Le Mans
Contact:

Re: WHICH CORE?!

Post by fpiSTM »

windyyam wrote:
Wed Oct 28, 2020 8:35 am
but for some reasons O2 and LTO seems not working on ST core so I don't know what that will be.
I've tested and it works with O2, result is 18686. For LTO, This is not a stable feature and never advise to use it.
Don't know why it does not work on your side. Which arm non eabi you used ?

Note that with the digitalWriteFast in O2: 1298

GonzoG
Posts: 80
Joined: Wed Jan 15, 2020 11:30 am
Answers: 5

Re: WHICH CORE?!

Post by GonzoG »

windyyam wrote:
Wed Oct 28, 2020 8:35 am
fpiSTM wrote:
Wed Oct 28, 2020 7:25 am
Try

Code: Select all

digitalWriteFast(PC_13,HIGH);
digitalWriteFast(PC_13,LOW);
Yes that would do the work. But it's a bit tricky as it does not use the same pinname. If someone's really in need for IO speed they probably manipulate port register instead. Just for compatible reasons if digitalWrite with normal Pin name and some optimization flag could do something better than memory look up table that would be the best solution, but for some reasons O2 and LTO seems not working on ST core so I don't know what that will be.
It's not that tricky.

Code: Select all

digitalWriteFast(digitalPinToPinName(pin),val);
Just define makro:

Code: Select all

#define digitalWriteF(a,b) digitalWriteFast(digitalPinToPinName(a),b)
#define digitalReadF(a) digitalWriteFast(digitalPinToPinName(a))
And it's as easy to use as normal digitalWrite.

Also with STM core port manipulation isn't always faster. It's faster for input registers but much slower than digitalWriteFast with output registers. (using O2 and O3 optimization)

windyyam
Posts: 9
Joined: Tue Oct 27, 2020 11:56 am

Re: WHICH CORE?!

Post by windyyam »

fpiSTM wrote:
Wed Oct 28, 2020 10:21 am
windyyam wrote:
Wed Oct 28, 2020 8:35 am
but for some reasons O2 and LTO seems not working on ST core so I don't know what that will be.
Don't know why it does not work on your side. Which arm non eabi you used ?
I think I'm using the 1.9.0 STM core from the Board Manager so the arm toolchain come with is 9.2.1-1.1.
The O2 works, but not O2 + LTO.
Anyway, I think Roger's core will still be useful for history reasons as long as bluepill f103 are still overwhelming the market, until they replace with blackpill f4xx

windyyam
Posts: 9
Joined: Tue Oct 27, 2020 11:56 am

Re: WHICH CORE?!

Post by windyyam »

GonzoG wrote:
Wed Oct 28, 2020 10:47 am
It's not that tricky.

Code: Select all

digitalWriteFast(digitalPinToPinName(pin),val);
This actually works, thank you. To tell you the truth I'm confused. Aren't digitalWrite already calling digitalWriteFast? How they are making difference?


Edit: I've write a sketch to compare with different method, only to be more confused

Code: Select all

#define digitalWriteF(a,b) digitalWriteFast(digitalPinToPinName(a),b)
#define digitalReadF(a) digitalWriteFast(digitalPinToPinName(a))
/*void digitalWriteMy(uint32_t ulPin, uint32_t ulVal){
  digitalWriteFast(digitalPinToPinName(ulPin),ulVal);
}*/
void setup() {
  // put your setup code here, to run once:
  pinMode(PC13, OUTPUT);
  Serial.begin(115200);
}
void loop() {
  // put your main code here, to run repeatedly:
  unsigned long lasttick = micros();
  for(int i=0;i<10000;i++){
    digitalWriteF(PC13, HIGH);
    digitalWriteF(PC13, LOW);
  }
  unsigned long nowtick = micros();
  Serial.print("digitalWriteF: ");
  Serial.println(nowtick - lasttick);
  
  /*lasttick = micros();
  for(int i=0;i<10000;i++){
    digitalWriteMy(PC13, HIGH);
    digitalWriteMy(PC13, LOW);
  }
  nowtick = micros();
  Serial.print("digitalWriteMy:");
  Serial.println(nowtick - lasttick);*/

  lasttick = micros();
  for(int i=0;i<10000;i++){
    digitalWrite(PC13, HIGH);
    digitalWrite(PC13, LOW);
  }
  nowtick = micros();
  Serial.print("digitalWrite:  ");
  Serial.println(nowtick - lasttick);
}
on STM core,
with Os flag, the output is:
digitalWriteF: 2474
digitalWrite: 18320
with O2 flag:
digitalWriteF: 3027
digitalWrite: 18458

but, if I uncomment everything,
with Os flag:
digitalWriteF: 17489
digitalWriteMy:22771
digitalWrite: 19713
with O2 flag:
digitalWriteF: 3024
digitalWriteMy:2741
digitalWrite: 19009

What's going wrong? Is there anything wrong with my sketch? How would that make such big differences?
I can see huge difference from the oscilloscope so this is not something that have been "optimized away". The only guess I can make is there is something to do with inline functions, but I still don't get the general answer to the result above

Edit2: By declaring inline and move function body into digitalWrite in wiring_digital.h, digitalWrite now behaves the same as digitalWriteF, even in Os(when no digitalWriteFast is used in the sketch). And I think functions declared in the sketch file autonomously is declared inline for the compiler.
Last edited by windyyam on Wed Oct 28, 2020 10:36 pm, edited 5 times in total.

mrburnette
Posts: 311
Joined: Thu Dec 19, 2019 1:23 am
Answers: 1

Re: WHICH CORE?!

Post by mrburnette »

windyyam wrote:
Wed Oct 28, 2020 11:18 am
...
Anyway, I think Roger's core will still be useful for history reasons as long as bluepill f103 are still overwhelming the market, until they replace with blackpill f4xx
IMO:
Roger's core (libmaple heritage from LeafLabs.com) is solid code from 2009 era which has been enhanced by Roger & community (Stm32duinoforum.com) for several years. Generally speaking, it is monolithic in architecture and suitable for hobbyists, small projects, and prototyping efforts. The world has changed lots since 2009 and so has the libmaple code as well as the GCC tools.

The STM Official core for Arduino is a set of wrappers around industrial-strength commercial code and is suitable for newbies as well as seasoned programmers. It allows projects to utilize Arduino methodology for prototyping under ArduinoIDE and allows professionals to move to the STM complete toolset using the same underlying low-level code and libraries.

One really should not compare these two codebases as it is simply inappropriate and may force one into a serious mental state where there is no way back to normal. :o Additionally, there is no guarantee that 3rd party libraries will function correctly: end-user must validate/fix.

Arduino is big in the Maker Universe and many people are familiar with the environment - at least enough to create a blinkie and do that repeatedly.

As STM produces evaluation boards in the Nucleo and Discovery series, it makes business sense for them to have an ArduinoIDE "core" of files which permits their boards and chips to be utilized in the Arduino ecosystem where numerous commercial products are available for attachment; a major part of Adafruit's business is based upon providing breakout boards. In that STM produced an ArduinoIDE core for a large majority of their microcontroller product line is commendable and was a large effort by a few dedicated engineers. I do not view it as a commitment to the Arduino, rather it is a commitment to the users of their evaluation products.

Arduino-centric thinking and the ArduinoIDE are really only an environment. All pertinent board/uC files are scripts. Arduino is just a framework of JAVA code that manages the output from the ArduinoIDE editor (or other chosen editor.) There is no native compiler or native linker in Arduino-land. The link below explains what happens, pay special attention to automatic creation of prototypes as many users do not understand this process.
https://arduino.github.io/arduino-cli/s ... d-process/

Finally, all of the sources for Arduino, STM32 core, and Roger's core are on GITHUB so feel free to grab the sources and dig into them.


Ray

feluga
Posts: 47
Joined: Wed Mar 18, 2020 2:50 am

Re: WHICH CORE?!

Post by feluga »

Nice analysis, mrburnette!
I like the way you described the STM32 Arduino scenario!

windyyam
Posts: 9
Joined: Tue Oct 27, 2020 11:56 am

Re: WHICH CORE?!

Post by windyyam »

mrburnette wrote:
Wed Oct 28, 2020 4:32 pm
The STM Official core for Arduino is a set of wrappers around industrial-strength commercial code and is suitable for newbies as well as seasoned programmers. It allows projects to utilize Arduino methodology for prototyping under ArduinoIDE and allows professionals to move to the STM complete toolset using the same underlying low-level code and libraries.
Yes, I totally agree with you Ray. By every meaning ST's core is better for sure. Just I've got so many projects relying on Roger's core and some of them
optimized(low level access), it's a matter of time for me to migrate to ST core, maybe start with new projects :D

mrburnette
Posts: 311
Joined: Thu Dec 19, 2019 1:23 am
Answers: 1

Re: WHICH CORE?!

Post by mrburnette »

windyyam wrote:
Wed Oct 28, 2020 9:56 pm
...
Yes, I totally agree with you Ray. By every meaning ST's core is better for sure. Just I've got so many projects relying on Roger's core and some of them
optimized(low level access), it's a matter of time for me to migrate to ST core, maybe start with new projects :D
The adjective "better" is not how I would choose to describe Official core verses Roger's version of libmaple; rather, both cores have a reason for existing. My discussion above is only intended to show why more than one core exists and why some choose one direction, or the other: it is a personal choice hopefully dictated by need (or project requirements for those software engineers that believe in doing such analysis.)

My intent is not to be biased in using one core over the other or to be critical of informed selection. But I do hope my discussions are helpful for readers to decide the appropriate path forward. Members every week seem to be questioning which core should be crowned as "better" ... the fact is, it is not a contest: use what works for you: realizing certain limitations.

Ray

ag123
Posts: 517
Joined: Thu Dec 19, 2019 5:30 am
Answers: 1

Re: WHICH CORE?!

Post by ag123 »

Just 2 cents
I prefer (libmaple) rogers core due to a personal preference, I messed with the codes and is more familiar with it, it is also kind of simpler to learn the codes if you bother to review codes in both cores. STM's core has HAL
as underpinnings , the whole set of HAL codes is designed to support almost the entire suite of STM32 socs, and it support many specific hardware features that is simply absent in libmaple core, but as a result ifind it considerably large and more complex. But that said it is far easier if you are trying to write codes that can work portably across STM 32 multiple socs and boards.

Hence, my opinion is that projects that aim for portability should target STM core for the best portability on STM32 line of mcus

Post Reply

Return to “General discussion”