STM32: Trying to get SPI working with Arduino framework for fast digitalWrite - Page 1
Forum section: electronics / general

author: MathematicalJ
author_rank: Contributor
timestamp: October 28, 2019, 06:41:32 am
content: I have a lot of inter-related questions, but to avoid theXY Problem,my ultimate goal is to get a Blue Pill STM32F103C8 to output a signal to daisy chained shift registers fast enough to scan a 251 key keyboard. The internet claims digitalWrite is very slow, particularly relative to SPI. SPI is also the exact protocol I need for my shift registers, so it seems like the Right Way™ to do what I am trying to do. Here is the bullet-list version of my problems:1. What STM32 library am/should I use?2. The SPI 1 port is behaving very strangely (oscilloscope picts below).3. The SPI 2 port appears to work, but the frequency/clock divider parameter has no effect no matter what its value.4. Also, the "working" SPI 2 port is very slow—slower than the plain vanilla digitalWrite method.5. Switching to Platformio (which I just discovered but already prefer over Arduino IDE), I can't get any output on SPI 2 at all.Now I elaborate on the above.1. Which STM32 library?I had set up Arduino IDE with the STM32 library served fromhttp://dan.drown.org/stm32duino/package_STM32duino_index.json.Today I learned that there are (at least) two STM32 libraries. I don't know which the Dan Brown library is, but I think it's some incarnation of Roger Clark's STM32 library. Platformio uses stm32duino by default, which is clearly different from the Dan Brown library despite having the same name. What are the official libraries? What are the differences?2. SPI 1 port is behaving very strangelyI get MOSI output just barely above the EMF noise floor of a few millivolts with SPI 1 (PA4-PA7) corresponding to the data I send out, as you can see in the attached photo of the noisy output with the crystal clear slave select signal superimposed on the second channel. You'll notice MOSI is generally negative (??). What gives?3. SPI 2 port appears to work... & 4. SPI is slower than digitalWriteSame setup, but using SPI 2 (PB12-PB15), I get the signals I expect, as you can see in the attached photo of my scope. (The slave select is offset below the MOSI signal to see it better.) But there are two related problems with this result: first, the time scale is independent of the frequency/clock divider parameter value given in the sketch; second, the time scale is longer than any value defined in the SPI.h/spi.h headers and longer than a plain vanilla digitalWrite. Using the DMA versions gave identical results.5. Platformio's default STM32duino framework.So I thought I'd try a different library, but I get no signal whatsoever with it—not even the slave select signal this time.Any info or advice is appreciated!

author: iMo
author_rank: Super Contributor
timestamp: October 28, 2019, 08:58:38 am
content: You may ask here at stm32duino sitehttps://mcu.selfip.comThis is the "original" Roger's corehttps://github.com/rogerclarkmelbourne/Arduino_STM32which works fine incl SPI (I've been using it daily).

author: westfw
author_rank: Super Contributor
timestamp: October 28, 2019, 09:09:28 am
content: QuoteArduino, the company, does not currently have any STM32 products, so there is no "official" version of the core or SPI library.I haven't paid attention in a while, but since Roger stepped down, I think the most maintained core is the one that actually has ST involved:https://github.com/stm32duino/Arduino_Core_STM32/The main Arduino support for a board or cpu is usually called the "Core", rather than a library. Libraries are "smaller" pieces of code - the ".json" file you mention is a pointer to an STM32 core, and SPI is a cpu-dependent library that is part of that core.Quote"Very slow" is a relative term. There are faster versions of digitalWrite() out there. SPI normally has a clockrate that is set to a relatively conservative value, and can be set faster.

author: iMo
author_rank: Super Contributor
timestamp: October 28, 2019, 09:21:44 am
content: As you may see above there are basically two "stm32duino" cores which are supportedRoger's core"Arduino_STM32"- based on Leaflabs libraries, focused mainly on BluePills and its derivates, still maintained by stm32duino web site veterans, works fine."Arduino_Core_STM32"- based on STM's HAL, the "new one", maintained by people close to STM, focused mainly on STM's Nucleo boards, accommodating the BluePills as well.History background:Roger started "stm32duino" site some 6y back, while the repo was placed on his github above.Later on, by STM supported folk created github repo with a similar name, focused on the STM's Nucleo products.The Roger's forum served as the support for both cores.In meantime there were 2-3 repos created by veterans, forked from Roger's core, or HAL based.I think the ones based on Roger's core have been merged to the above Roger's core already.In late 2018 Roger announced he is going to close down the "stm32duino" site in April 2019, and he did. The veterans created a new one (see above the link) and there is a "read only old stm32duino" site still available, but partially broken - here -https://stm32duinoforum.com/forum/index_php.htmlFast write/read - there are macros for fast write/read (ie bitbanding based).

author: iMo
author_rank: Super Contributor
timestamp: October 28, 2019, 09:47:57 am
content: Here you are, a demo you may play with, HTH:Code:// FAST I/O DEMO BENCHMARK// assembled of stm32duino forum code snippets// iMo 10/2019#include "Arduino.h"#define BITBAND_SRAM_BASE 0x22000000#define SRAM_START 0x20000000#define BITBAND_PERIPHERAL_BASE 0x42000000#define PERIPHERAL_START 0x40000000#define BITBAND_SRAM(address, bit) ( *(volatile uint32*)( BITBAND_SRAM_BASE + ((uint32)(address)-SRAM_START) * 32 + (uint32)(bit)*4) )#define BITBAND_PERIPHERAL(address, bit) *( (volatile uint32*)( BITBAND_PERIPHERAL_BASE + ((uint32)(address)-PERIPHERAL_START) * 32 + (uint32)(bit)*4) )#define GPIO_ADDRESS(gpio) (GPIO_START + 0x400 * (uint32)((gpio)-'A'))#define GPIO_OFFSET(gpioLetter) (0x400 * (uint32)((gpioLetter)-'A'))#define BITBAND_GPIO_INPUT(gpioLetter, bit) BITBAND_PERIPHERAL((uint32)&(GPIOA_BASE->IDR)+GPIO_OFFSET(gpioLetter), (bit))#define BITBAND_GPIO_OUTPUT(gpioLetter, bit) BITBAND_PERIPHERAL((uint32)&(GPIOA_BASE->ODR)+GPIO_OFFSET(gpioLetter), (bit))#define ATOI2(s) ((s) ? 10*(uint32)((s)-'0') + (s)-'0' : (uint32)((s)-'0'))#define XPIN_TO_GPIO(pin) (#pin)#define XPARSE_PIN_BIT(pin) (ATOI2(#pin+2))#define XCHECK_PIN_ID(pin) static_assert(#pin == 'P' && >= 'A' && <= 'I' && >= '0' && <= '9' && \(#pin == 0 || (#pin >= '0' && <= '9' && == 0)) && ATOI2(#pin+2) < 16, "Invalid pin ")#define DIGITAL_READ(pin) (BITBAND_GPIO_INPUT(XPIN_TO_GPIO(pin), XPARSE_PIN_BIT(pin)))#define DIGITAL_WRITE(pin,value) do { XCHECK_PIN_ID(pin); (BITBAND_GPIO_OUTPUT(XPIN_TO_GPIO(pin), XPARSE_PIN_BIT(pin)))=(value); } while(0)//port/gpio oriented macros (pins == bitmask of a bit set to 1)#define IO_SET(port, pins) port->regs->ODR |= (pins) //set bits on port#define IO_CLR(port, pins) port->regs->ODR &=~(pins) //clear bits on port//fast routines through BRR/BSRR registers (pins == bitmask of a bit set to 1)#define FIO_SET(port, pins) port->regs->BSRR = (pins)#define FIO_CLR(port, pins) port->regs->BRR = (pins)uint32_t elapsed, i, dummy;void setup() {Serial.begin(9600);pinMode(PB12, OUTPUT);pinMode(PB11, INPUT);}void loop() {elapsed = millis();for (i=0; i<1000000; i++) {//digitalWrite (PB12,1);// DIGITAL_WRITE(PB12,1);// dummy = digitalRead(PB11);//IO_SET(GPIOB, 12);//IO_CLR(GPIOB, 12);FIO_SET(GPIOB, 12);FIO_CLR(GPIOB, 12);// dummy = DIGITAL_READ(PB11);//digitalWrite (PB12,0);// DIGITAL_WRITE(PB12,0);}elapsed = millis() - elapsed;Serial.println(elapsed);delay(1000);}SPI: on the BluePill the SPI1/2 works fine afaik in Roger's core. The max clock of SPI1 is 36MHz, SPI2 18MHz. Both are DMA supported afaik. When properly used it works straight. The stm32F4 is supported as well, incl. SDIO.For example:Code:..SPIClass xspi(1); // work with SPI1void setup(){Serial.begin(115200);xspi.begin();xspi.setClockDivider(SPI_BAUD_PCLK_DIV_2); // SPI1 clock is 36MHz..

author: rs20
author_rank: Super Contributor
timestamp: October 28, 2019, 10:03:56 am
content: This isn't directly helpful to you, but personally I'd strongly advise using Atollic TrueStudio and STM32CubeMX. If you're moving from Atmel to ST, the very last thing you should hold on to is the Arduino IDE, especially given that it's not officially supported in any way, and doesn't support a whole slew of features useful to a newbie and provided by my suggested combination (including, but not at all limited to: a GUI which writes all this bootstrap code for you, official HAL libraries that work, and proper debugging support.)Devboards likes the STM32 Disco and Nucleo series are barely any more expensive than the bluepill, and include a built-in debugger. YMMV, please don't take this as a criticism of your chosen path, it's just what you're dealing with would seem like a horrible, huge backwards step compared to the IDE+devboard chain I'm enjoying at the moment.

author: OwO
author_rank: Super Contributor
timestamp: October 28, 2019, 11:02:59 am
content: Yes, I would say get away from arduino but don't necessarily go for the official SDK and HAL either. The STM32 HAL is a complete mess that is rewritten every few years and don't actually abstract away hardware details in any meaningful way. E.g. something as simple as accessing GPIO is completely different between STM32 families (F0 -> F1), and the HAL doesn't do anything to make this easier.I personally use libopencm3, it's not a HAL but a very thin layer that allows you to directly access hardware with no bullshit. I then provide my own abstractions like a fast WIRING api and some peripheral libraries, which makes my code very easy to port between device families.Some examples here:https://github.com/gabriel-tenma-white/mculib

author: iMo
author_rank: Super Contributor
timestamp: October 28, 2019, 11:03:10 am
content: FYI - I work with Sloeber - that is Eclipse based IDE, with Roger's core (as it works well with all important arduino libs I've been using). The debugger there works too. It has been elaborated in detail on the old stm32duino forum.Thus "arduino" here more-less means: "the megatons of arduino libraries work straight with this core".https://eclipse.baeyens.it/

author: artag
author_rank: Super Contributor
timestamp: October 28, 2019, 11:11:17 am
content: Would have to agree with OwO.Perhaps STMCube has improved since I last tried to use it, but based on previous experience I wouldn't touch it with a bargepole. It was horribly contorted and slow code based not on normal HAL principles of minimising the size of the layer but instead trying to create an single abstraction for the whole STM32 world, with the idea of making it easy for users to migrate through different families. More like an OS than a HAL, but not one that provides portability beyond ST.Arduino libraries aren't always great and are certainly slower than native code, but they're usually better than STM32Cube.

author: ozcar
author_rank: Frequent Contributor
timestamp: October 28, 2019, 11:12:08 am
content: How frequently do you have to scan the 251 keys? I.E. how fast is fast?As for using a Nucleo board with a built in debugger, there is nothing stopping you from using a Blue Pill board with a cheap ST-LINK clone. I have done that with TrueStudio.

author: rs20
author_rank: Super Contributor
timestamp: October 28, 2019, 11:52:52 am
content: Quote from: artag on October 28, 2019, 11:11:17 amI'm not going to disagree with any of these points; I never claimed STM HAL was highly optimal in any way. But what makes it worth its weight in gold is that for the things you're not really futzing with (USB Serial, Clock Tree, Power Distribution, DMA etc), it just configures it all for you. Who cares if the HAL takes 15 ms instead of 15 us to initialize? And with a proper IDE (unlike Arduino), you can easily explore the HAL implementation to see exactly what it's doing. Yes, I've seen some bad design decisions in there, but it'svisible. For Arduino IDE + libraries to be considered superior, the Arduino libaries have to be 10x better than STM HAL because the Arduino IDE is 10x worse for exploring and debugging the libraries. And that's not even taking into account that newbies have to individually find appropriate Arduino libraries from the wild west for each peripheral they're messing with, whereas it's all just laid out for you by STMCube.This isn't an issue of the code quality than an expert like you can get out of these systems. This is an issue of how easily a newbie can get started using all the features of all the peripherals on their ST MCUs. An overly deeply structured HAL is just irrelevant to this question. Do you think STM32 Arduino is superior for newbies as compared to STMCube with these points in mind?Personally, again YMMV, I've found the experience of using TrueStudio (with STMCube tool providing a big pile of initialization code to get me started on a roll) to be avastlysuperior experience to the frustrating, dark old days of the Arduino IDE -- and that was when I was using actual Arduino boards (so not even throwing the STM32 Arduino spanner in the works.)

author: iMo
author_rank: Super Contributor
timestamp: October 28, 2019, 02:06:38 pm
content: QuoteA newbie is not going to use all the features of all the peripherals on their ST MCU.A newbie wants to take his/her new BluePill and a solderless breadboard, wire an external DS2321 module to it, an I2C IMU module, a few I2C ADCs and DACs modules, an SPI SDcard, and a TFT LCD display.Then he/she wants to spend a Sunday's afternoon writing 60 lines of code having all the stuff working - logging data on the SDcard as well as watch the data on the LCD display.A newbie does not want to mess with reading and debugging libraries.That is the trick..

author: MathematicalJ
author_rank: Contributor
timestamp: October 28, 2019, 04:57:52 pm
content: Thank you all for very helpful information. With 11 replies in less than as many hours, this is easily the most helpful technical forum I've seen!I should say that while I'm new to electronics and MCUs, I'm not new to software engineering, C/C++, assembly language in general, etc. I'm a mathematician/computer scientist by vocation.I didn't mean to start a debate about development environments! It sounds like Roger's library is the most mature and targeted at my device specifically, so I will experiment further with it. It also sounds like results are very dependent on choice of supporting software. Fair enough! I was wanting an easy-to-use "off the shelf" library/core that would get me up and running quickly. My instinct was to avoid macro-based solutions, but there's no principled reason I need to, especially considering how limited my needs are. My device essentially just does one thing. As usual, "more research is needed."Regarding alternative cores, my benchmark for evaluation is how simple the blinky example is using the framework (available in this repo). There isn't a clear winner, but there are definitely clear losers. For my device, it turns outPlatformio supportsboth major arduino cores, CMSIS, and STM32Cube.

author: MathematicalJ
author_rank: Contributor
timestamp: October 28, 2019, 05:25:41 pm
content: Quote from: ozcar on October 28, 2019, 11:12:08 amYou're asking the important questions! The hardware I've built requires 6 bytes be written out to scan one key. This may sound like a lot, but a simple back of the envelope calculation using SPI performance numbers from the internet showed that the Blue Pill would be a healthy order of magnitude faster than necessary, and with asynchronous DMA transfer, the CPU would be free to handle the overhead of reporting events via USB.Except I am getting performance TWO orders of magnitude slower than expected! I get 7 μs/bit (143 KHz) with SPI and 1.5 μs/bit (667 KHz) with Arduino's shiftOut. At the fastest speed, I can scan the entire keyboard at 56 Hz.Exactlyhow fast it needs to be to feel fast enough is somewhat subjective, but 56 Hz certainly isn't enough! For comparison, theKeyboardio keyboardscans the board at 2 KHz.

author: MathematicalJ
author_rank: Contributor
timestamp: October 28, 2019, 05:52:35 pm
content: Quote from: imo on October 28, 2019, 08:58:38 amSorry to be daft, but what's the relationship between these two forums?https://mcu.selfip.com/index.phphttps://stm32duinoforum.com/The second appears to be very quiet despite also hosting the read-only archive of the old forum.

author: ozcar
author_rank: Frequent Contributor
timestamp: October 28, 2019, 08:39:00 pm
content: Quote from: MathematicalJ on October 28, 2019, 05:25:41 pmOn a Blue Pill I'd take a guess that it would be possible scan 256 keys at at least 1KHz - depending on what else you have to do, and how many pins you need for other purposes.25 years ago (!) I used an 8-bit 6802 running at 1MHz to scan 128 keys, and I managed to do it at around 50Hz (and using only the onboard RAM, a whopping 128 bytes). That was using four output pins to a 74LS154, and 8 input pins, with the status of 8 keys being read and checked simultaneously. On the Blue Pill you could use say PA0-PA7 to read the status of 8 keys at a time, and then check for required action for 32 keys at a time.

author: MathematicalJ
author_rank: Contributor
timestamp: October 29, 2019, 02:12:16 am
content: Quote from: ozcar on October 28, 2019, 08:39:00 pmYes, for sure. The problem is, I designed my hardware around the assumption that I could get much higher switching speeds out of just 3 pins. I still think I probably can once I figure out the stupid little thing I'm doing wrong. But in the worst case scenario, it's not that hard for me to scrap my original design. We can't learn without making mistakes! I am tempted to just write the whole thing in assembly. At the very least it would be fun.That MC6802 is a legend. Aren't they still being produced? You had, what, 2KB of ROM? Meanwhile my very meager keyboard test code takes up half of the 64KB of Flash memory on my MCU. I have been slowly collecting famous historical processors with a fantasy of making some kind of visual historical diorama, something likeBen Eater's 8-bit computermeetsthe life-size 4004 at the Intel Museum. If anyone has any historical processors they want to give away... I'll even pay postage!

author: westfw
author_rank: Super Contributor
timestamp: October 29, 2019, 03:42:59 am
content: QuoteMy interpretation of early history:The Leaf Labs folks developed STM32F103 hardware ("Maple") code based on the ST libraries of the time. (stmlib, back then?)Performance was poor, so they re-wrote everything in bare-metal code, including their own peripheral definitions (because of license worries?)Leaf Labs went on to other things, Roger Clark took over the Maple code base, and did a lot of work getting it to run on assorted STM32 platforms and boards (mostly STM32F1xx-based.)Because of the bare-metal approach from (2), porting to other STM32 chips was difficult, and ST wanted to have broader support, so they encouraged/developed the new HAL/LLL based core (which is better than the old libraries?)(I haven't been paying much attention, so that may not be totally accurate. But I think it's close.)

author: Siwastaja
author_rank: Super Contributor
timestamp: October 29, 2019, 06:05:36 am
content: If you are a computer scientist with C, C++ and some assembly experience, it shouldn't be a big problem to just ditch all these libraries and frameworks and start writing your application bare metal for your specific MCU.The "easy" beginner libraries tend to be easy only in a very limited sense. Maybe their developers intended you to read a temperature sensor and print the result on an LCD. If this is case, this particular use case likely works, and likely is easy. But once you hit a wall, you need to face the actual learning curve. Sometimes, it's because the library/framework doesn't support some crucial feature implemented by the peripherals (especially true if multiple peripherals need to be configured to work in conjunction; think about timer synchronization for example), sometimes it's because of performance; in a real embedded system, you often need to do multiple things at the same time, respond to interrupts, process things in microseconds in an ISR, and so on.And those libraries that can deal with all the problems, tend to be something that don't abstract properly, and mayincreasethe amount of code you need to write, while the opposite is why the libraries are normally used.

author: iMo
author_rank: Super Contributor
timestamp: October 29, 2019, 09:36:37 am
content: Quote from: MathematicalJ on October 28, 2019, 05:52:35 pmAs I have explained in my above posts - thehttps://mcu.selfip.com/index.phpis the de-facto successor of the former stm32duino.com (which served as the forum for several years and was closed down 6months back).Thehttps://stm32duinoforum.com/forum/index_php.htmlis the read-only (and a bit broken) last version of the stm32duino.com from April 2019.So for people who want to work with so called "Roger's core"https://github.com/rogerclarkmelbourne/Arduino_STM32(I've been using a 3-4y old version happily, the github shows they still maintain it) the mcu.selfip.com is the new support and forum site where the veteran experts sit and help you when you ask.As westwf wrote - the Roger's core is pretty mature, fast, works with almost all "arduino compatible" libraries you may find straight. The experts there spent a lot of time with fine tuning of the core and improving its performance.The main reason, why they started to play with HAL was an expectation the HAL based core will allow an easy porting between dozens of various STM32_XYZ chips.The former "stm32duino" movement originated from BluePill board, and say 5-6 similar F103 boards, later enhanced to F407 boards. Their intention with Roger's core had been to focus on and stay with F103 (and with F407 too) and not to start mess with other families.There is an USB bootloader for F103 variants they fine-tuned in past athttps://github.com/rogerclarkmelbourne/STM32duino-bootloaderPS:It makes no sense to start elaborate the architecture and academical aspects of sw engineering related to the stm32duino's Roger core, imho.It is a mature tool which works, for people who want to create a working system around a BluePill board (and its STM32F103/F407XYZ Black, Yellow, Red, etc. derivatives) easily and fast,while utilizing any existing "arduino compatible" libraries you may find on the web.All STM32F103C8 based BluePills got 128kB of flash, therefore creating large builds (ie FreeRTOS based) with decent performance (up to 128MHz overclocked) around a $1.50 board is something some people are still impressed with.That is all

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: October 29, 2019, 08:39:50 pm
content: Quote from: westfw on October 29, 2019, 03:42:59 amMy contribution was relatively minor, but I took Maple's no longer supported code for STM32F103 and repackaged it for the newer Arduino IDE. Then Roger picked it up and did a fantastic job with it.I occasionally help out with Open Source projects, often with little consequence, but in this case my little nudge helped spawn the stm32duino ecosystem so I'm quite pleased with that.We should also thank LeafLabs for trying to create an ARM alternative to Arduino that wasn't Atmel, and leaving their code open source when their products never really took off.

author: iMo
author_rank: Super Contributor
timestamp: October 30, 2019, 11:04:30 am
content: FYI - With following code running on the BluePill, with built in function shiftOut(), and 16 74HC595 registers, toggling all 128 pins 0/1, 1000x in a loop takes 443ms..Code:/*ShiftRegister74HC595.h - Library for easy control of the 74HC595 shift register.Created by Timo Denk ([url=http://www.simsso.de]www.simsso.de), Nov 2014.Additional information are available on http://shiftregister.simsso.de/Released into the public domain.*/#include "74HC595.h" // iMo 2019 - made the name of .h shorter :)// create shift register object (number of shift registers, data pin, clock pin, latch pin)ShiftRegister74HC595 sr (16, 0, 1, 2);void setup() {Serial.begin(115200);}void loop() {uint32_t etime;etime = millis();for (int i = 0; i < 1000; i++) {sr.setAllHigh(); // set all pins HIGHsr.setAllLow(); // set all pins LOW}etime = millis() - etime;Serial.println(etime);}

author: iMo
author_rank: Super Contributor
timestamp: October 30, 2019, 04:21:23 pm
content: With SPI (instead the shiftOut() ) the above code withQuoteand 10.000x toggles in the loop takes 479ms.

author: ag123
author_rank: Contributor
timestamp: December 09, 2019, 06:17:18 am
content: going a little off topic and adding fuel to the fire, here is my little 2 cents.libmaple core-https://github.com/rogerclarkmelbourne/Arduino_STM32has been my personal favorite only because i've spent time working on it and is more familiar with its structure.libmaple core has its origin in leaflabs maplehttp://docs.leaflabs.com/docs.leaflabs.com/index.htmlhttps://www.leaflabs.com/mapleroger and a whole community made improvements to it and still today is a pretty popular but *informal community* core.that said libmaple core has its origin in stm32f103c(8,b} and this is the defacto supported mcuthe community (notably stevstrong check thathttps://mcu.selfip.comand rest has added supported for some additional cores, notably F407(VE - ZG), F401, F411 and F303 those support are mostly only available on steve's forkhttps://github.com/stevstrong/Arduino_STM32. that said the implementation is embryonic and is community developedmost of other stm32 mcus (e.g. m0) are never tested and can be deemed 'unsupported', but you may try to develop a whole core for it if one choose to, it is a community effort and can be deemed 'you are on your own' , 'make your own features if you need it' about it. the community used to be very active and lots of things are tried, the continuation is slowerhttps://mcu.selfip.comthis again is informal and running on a pc by a volunteer.Vassilisofficial corehttps://github.com/stm32duino/Arduino_Core_STM32https://github.com/stm32duino/wiki/wikithis core is developed by ST (ST's employees literally) and some of the community members in this same stm32duino community are writing some contributions and added to the 'official' core. it is CubeMX, HAL based and the arduino api is laid on top of that.the benefit here is that as it is HAL (some more than a 100 megs of libraries) based it works across a much larger (possibly all or most) of the stm32 mcu families.so if one wants to use an mcu that is other than stm32f103 or f407, f401, f405, f411the official core is probably the best bet. one can use HAL if features are 'missing'. of course this takes a detour from Arduino, but you get the features of the mcuthe official core tends to have a little more bloat for thin and light apps e.g. a blinky on stm32f103 (blue pills, maple minis and all the 'compatible' boards)libmaple core is thinner and lighter in that respects but limited only to mainly the stm32103 (and stm32f4, f303 - steve's fork)for the community libmaple core, if you 'run out of features', take those verbose and nicely written up stm32 mcu reference manuals & start coding them yourself, there is no assurance that a particular feature is there.there is actually 1 more (community) core developed at the height of it, one'd just need to do some web searches for it.stm32f103 boards are popular simply because if you seach up the keyword on ebay, aliexpress, you would find lots of vendors offering the boards for a rather low cost.'blue pill' (the popular nickname) is deemed $2 but often priced higher (including shipping)other reasons include that it is a lot faster than uno (just search youtube for the videos), arm based and has more sram / flash and 32 bits and it has pretty fast ADCs (2msps on stm32f103)(there is 1 more reason that i personally think it has weight, but not necessarily so for other arduinoers.stm32f103 and the 'higher' mcus has a full fledged usb device built-in, hence it is a generic usb device, one can implement the various protocols usb-serial is there in default, and one can develop usb-hid, usb-mass storage, usb-* if one is so inclined. the only unfortunate thing is that it is a full speed interface and not high speed interface)in perspective, the official core and libmaple core are literally an arduino flavored O/S on stm32 mcus

author: ag123
author_rank: Contributor
timestamp: December 09, 2019, 08:20:24 am
content: Quote from: MathematicalJ on October 29, 2019, 02:12:16 ami've been wanting to try out a similar project i.e. a diy mechanical keyboard and i think my intended designs coincide with yours, but i've not literally worked on it.among the things to note, on stm32 after you setup the peripheral e.g. SPI it is (may be) necessary to enable the gpio pins for output.i've once played with the timers all the peripherals settings are 'correct' and i'm wondering why i'm not getting the timer signal output on the pin.the moment i enabled the pin for (gpio) output, i get a full perfect square wave signal. that may explain your woes on SPI1 (the PAxx ones)accordingly SPI on stm32f103 (maple mini or blue pill) can be pretty fast perhaps 10s of mhz? like 20mhz?you can find many of such youtube videosthere is a particular SPI library shipped with the libmaple core in the libraries. try that if you are using the libmaple core.for the official core i'm not familar with it but you could perhaps find more information in the wikiyou could use each of the 2 forums mentioned to post a question for the official core perhaps someone may drop some pointersanother feature on stm32(f103) is DMA, it is one of the 'not for newbies' stuff, but many of the fast (mhz range) dma triggering and port reading stuff are dma driven.there have been some experiments to optimise codes reading or writing pins on stm32 but apparently it seemed there is a bottleneck and is slower than dma.i think part of the reason is that programs runs from flash has wait states etc, so it may possibly run (much?) faster if run from sram.still it is quite a bit of effort to code and optimize for thatthese has been some of the featured projects/attempts early on as the libmaple core matureshttps://github.com/pingumacpenguin/STM32-O-Scopehttps://satoshinm.github.io/blog/180105_stm32scope_building_an_amazing_10_oscilloscope_with_an_stm32_blue_pill_lcd_touchscreen_and_stm32-o-scope_software.htmltoday if you try the stm32f303cc accordingly it has 4x5mhz ADC, so in theory if you do quad interleave it is possible to achieve 20msps adc speeds ! i think there is a literal open sourced oscilloscope based on thati've been wanting to try that but not (yet) attempted itrobotdyn is one of them that ships a f303cc based boardhttps://robotdyn.com/catalog/development-boards/stm-boards-and-shields.html