Introducing the new delivery for STM

The official STMicroelectronics Arduino core
User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: Introducing the new delivery for STM

Post by 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.

User avatar
RogerClark
Posts: 6370
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Introducing the new delivery for STM

Post by 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
Posts: 24
Joined: Wed Jul 08, 2015 12:54 pm
Location: England

Re: Introducing the new delivery for STM

Post by 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.

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: Introducing the new delivery for STM

Post by 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
[disclaimer, I wrote the SW for Dragonfly]

First off Teensy 3.5 & Teensy 3.6 have higher performance. Hands down. It's a faster CPU. If you compare Dragonfly to Teensy 3.2, then Dragonfly is faster, has more usable peripherals than Teensy (5 UARTs, 3 SPI, 3 I2C exposed, backpads for a MPU9250+BME280 sensor board). There is a 16MB NOR flash on the board with a FAT file system on it, which you can use in your Arduino sketch, or simply access via USB/CDC. So lot's more in terms of features.

Then there is SWDIO/SWCLK accessible, which means you can do real debugging with this board (unlike Teensy, where this odd bootloader chip is in your way).

RSN I hope there will be a microSD addon available (need to finalize the software for it), which means that you'll get the same feature set as Teensy 3.5/3.6 in a smaller form factor.

Software wise there are quite a few goodies that might be of interest (just reporting what's there, not what is planned):

(1) Async IO for CDC/Uart/SPI/Wire. An example is this API here:

Wire.transfer(uint8_t address, const uint8_t *txBuffer, size_t txSize, uint8_t *rxBuffer, size_t rxSize, bool stopBit, void(*callback)(void));

This allows you to initiate a complex write/read I2C transaction, and when done get a callback. So your main sketch does not need to wait (Wire.requestFrom() or Wire.endTransmission()) for the data to be received/send.

(2) DMA on Uart/SPI/Wire, per default. Most Async IO uses DMA to avoid having to wakeup the CPU all the time. A composite Wire write/read transfer takes only 2 interrupts ...

(3) Most of the blocking Arduino style APIs put the CPU into a sleep mode. For a simple "Blink" sketch Dragonfly gets down to about 5.6mA, while Teensy 3.2 is @ 38mA (3.5 is @ 53.7mA, 3.6 is @ 73.1). So even without going to extreme measures Dragonfly is really, really low power. Ah, and clocks can be set to 16/24/32/48/64/72/80 MHz, so that even more power savings are available.

(4) There is a real EEPROM emulation available (the one in the STM Core will given you about 48 write cycles per byte only, the one in the STM32L4 core about 400k).

(5) getVBAT() / getVREF() / getTemperature() are exposed to make the ADC path really useful.

(6) explicite control over timer blocks to allow fine control of PWM outputs (to say control an ESC directly):

analogWriteFrequency(uint32_t pin, uint32_t frequency)
analogWriteRange(uint32_t pin, uint32_t range)


Well, back to hardware. STM32L4 has I2C peripherals that allow you to do FM+ (i.e. 1000kbit/sec). SPI has a builtin CRC16 which is used to do the CRC calculations for the SPI/SDCARD code (yes, this code also detects failures on this path and does retries and such). STM32L4 has a sigma-delta peripheral, which allows you to connect PDM microphones directly. The QSPI interface to a serial NOR flash was already mentioned.

So if you compare Teensy 3.2 vs. Dragonfly, the latter one wins hands down on pure hardware merits.

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: Introducing the new delivery for STM

Post by 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.
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.

My grief with the Nucleo line is that on the Arduino headers you have 2 I2Cs, 1 SPI port, and 2 UARTs (whereby 1 UART is hardcoded to also be USB/CDC). There is no USB exposed, other than throu the ST-Link interface (which limits your UART USB/CDC bridge to about 11kB/sec as opposed to a real USB/CDC implementation which gets about 500kB/sec).

Yes, you can use the morpho headers, but because some of the pins are arranged in an odd manner for making the Arduino stuff work, your usable pins are all over the place. Not impossible for bare metal or mbed, but utterly confusing software wise, and messy if you start with DuPont wiring.

In my personal tool-chest, the Nucleo/Discovery boards are great if I want to go bare metal, and quickly prototype something simple (or something which is bolted onto a Discovery board), but if you want to have something polished for a simple Arduino type environment those platforms are lacking.

RogerL
Posts: 24
Joined: Wed Jul 08, 2015 12:54 pm
Location: England

Re: Introducing the new delivery for STM

Post by 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.
I wasn't really complaining about the price, just saying that its beyond my budget for this project. I appreciate what you say about the Nucleo pricing.
GrumpyOldPizza wrote: Yes, you can use the morpho headers, but because some of the pins are arranged in an odd manner for making the Arduino stuff work, your usable pins are all over the place. Not impossible for bare metal or mbed, but utterly confusing software wise, and messy if you start with DuPont wiring.
This is the main reason I have been a bit slow off the mark getting into STM32 boards in general. I am a bit dyslexic and often struggle to get 2 wires connected round the right way. The project I am about to start is a MIDI step sequencer which will have 2 banks of 16 press buttons, plus assorted other buttons, encoders and LED controllers. Not too bad on a Mega 2560 where you have 2 rows of 16 basic I/O pins on the end of the board with the multifunction pins sequentially arranged along the side, but likely to be a nightmare on the Nucleo board as it stands. I would probably end up making up a strip board lash-up to mount the Nucleo on which breaks out the Nucleo pins to custom headers matching my application, but it would be a real rats nest.

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: Introducing the new delivery for STM

Post by 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
Posts: 318
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Introducing the new delivery for STM

Post by 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?
I downloaded the arduino library manager list, and compiled them to this core with python script and make (not with arduino gui, there are a few errors because of this).
http://danieleff.com/stm32/
A lot of them already compile fine (Although successful compilation might not mean it actually works.). Some errors can be fixed fast, for example copying avr/pgmspace.h from the other core (I guess).

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

User avatar
RogerClark
Posts: 6370
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Introducing the new delivery for STM

Post by 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...?
We currently use __STM32F1__ (for the F1 ) and __STM32F4__ etc for the others.

This was mainly because the IDE seems to auto generate these defines based on the folder name of the core.

But I think its perhaps the best schema to continue with, as we can't guarantee that libraries that compile for the F1 would compile for the F4 without any changes.

I know the HAL is supposed to provide a unified interface, but in practice there are differences in the structures that the HAL functions require to be setup and passed to the HAL functions - this is, For Example, because the F4 has some extra GPIO speed settings that the F1 doesn't

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: Introducing the new delivery for STM

Post by 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...?
We currently use __STM32F1__ (for the F1 ) and __STM32F4__ etc for the others.

This was mainly because the IDE seems to auto generate these defines based on the folder name of the core.

But I think its perhaps the best schema to continue with, as we can't guarantee that libraries that compile for the F1 would compile for the F4 without any changes.

I know the HAL is supposed to provide a unified interface, but in practice there are differences in the structures that the HAL functions require to be setup and passed to the HAL functions - this is, For Example, because the F4 has some extra GPIO speed settings that the F1 doesn't
Would it make sense to come up with some guidelines as to what to use for those defines ? The STM32L4 core for example offers more features than the STM based code, which in turns has a few quirks that applications might need to work around. Following ESP8266's lead, I simply keyed off "STM32L4", but that might not be good enough ?

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest