Big STM32 boards topic

End Devices (Nodes)
148

Just quickly, updated ArduinoCore-stm32l0.

LSE is now calibrated via TCXO. This brings RTC close to +/- 1ppm. Was way more than the speced +/- 20ppm on the boards I measured.

Also the PPS pulse out of the GNSS is now hooked up for the GNSS library. It forwards UTC into the RTC (also RTC library), as well as doing phase correction, so that the subseconds of the RTC are aligned with the top of the second coming out of GNSS (CAM-M8Q for Cricket).

Kind of rather nice, if your sensor node is running for a long, long time.

What has not been done (yet) is to apply long term RTC correction via GNSS.

What would also be interesting is to use the Frequency Error feedback of SX1276 to estimate the aging of TCXO. But that implies that the gateway has a more stable clock than the node …

4 Likes
149

Which pinmapping are you using for STM32F103?
Currently I am using:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = PA4,
.rxtx = LMIC_UNUSED_PIN,
.rst = PA2,
.dio = {PA3, 1, 2},
};

150

There is new code for the ArduinoCore-stm32l0:

FskRadio API / Class
LoRaRadio API / Class

Both of them are the first revsision, so things will change.

The LoRaRadio class allows direct access to the SX127x LoRa part of the Semtech radio. Simple async transmit/receive. The receive part implements a packet queue. so that more than one packet can be buffered/processed. CAD is supported as well.

The FskRadio class allows direct access to the SX127X FSK part of the Semtech radio. FSK/GFSK, no OOK. The packet engine allows SyncWord/Length/Address/CRC based filtering. Packets can be up to 255 bytes.

Both classes were done in a way so that they have the same look and feel as the LoRaWAN class. Internally the same radio stack is used for all 3 of them.

There is no documentation yet (no surprise there ;-)), but there are examples to test things out quickly. To get a quick overview over the concept, here the main include files:

FskRadio.h
LoRaRadio.h

Questions and suggestions are welcome.

4 Likes
151

I got one of the LoRaM3-D F303 boards and am trying for a couple of days to be able to program it from Arduino on a couple of different systems. In all cases I’m running into the basic problem that I don’t understand where are the path settings. On Ubuntu it can’t find the compiller. On Arch I finally managed to compile the LoRaReceiver sample sketch but it says it can’t find dfu-util even though I have a lot of copies of that in various places:

java.io.IOException: Cannot run program “{path}/dfu-util”: error=2, No such file or directory

Does anybody know which “path” it’s babbling about and where to set it? If it was using the system $PATH it would surely find it.

I have https://github.com/BSFrance/BSFrance-stm32.git cloned in ~/Arduino/hardware so I would expect that it would try to run ~/Arduino/hardware/BSFrance-stm32/stm32/tools/linux64/dfu-util/dfu-util

152

I know there is platform.txt (actually there are quite a few of those) but those tend to use relative paths too. e.g. Arduino/hardware/BSFrance-stm32/stm32/platform.txt defines tools.dfu-utilc.path.macosx and .windows but nothing for linux; and those two paths use runtime.hardware.path which I guess is elsewhere; it doesn’t seem to be defined in any of the platform.txt files.

I’m not sure whether the BSFrance hardware package is supposed to depend on the official Arduino_STM32 package, but I have that installed too, so there is also Arduino/hardware/Arduino_STM32/STM32F1/platform.txt and Arduino/hardware/Arduino_STM32/STM32F4/platform.txt. And there is a system one: /usr/share/arduino/hardware/platform.txt

153

I ran into similar problems on Windows.
The BSFrance STM32 Arduino Core on GitHub is incomplete and has some rough edges (I expect that it will not to be updated any soon).
After copying the core from GitHub repository https://github.com/BSFrance/BSFrance-stm32, you will additionally have to copy the ARM tool chain and Arduino tools for STM32 into the core’s directory structure.
IIRC ARM tool chain version 5.x will not work and I think I used version 7.x instead which can be downloaded here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
The STM32 Arduino tools can be downloaded here: https://github.com/stm32duino/Arduino_Tools

In Windows I placed the BSFrance core in Documents\Arduino\hardware\BSFrance-stm32.
I renamed subdirectory stm32 to STM32 to prevent library incompatibility warnings during compilation (related to incorrect casing in library.properties files of certain libraries included with the core).

On Windows the ARM toolchain goes into:
Documents\Arduino\hardware\BSFrance-stm32\STM32\tools\win\gcc
and the tools go into: Documents\Arduino\hardware\BSFrance-stm32\STM32\tools
(Latter with a separate subdirectory per OS. Note: for Linux there are two: linux and linux64.)

You will probably have to tweak one or more paths in platform.txt for dfu-util and possibly for the gcc toolchain.
I don’t exactly remember. Have not touched it in months.

For more information on custom(izing) Arduino cores see: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

I have no experience with Arduino on Linux so I’m not sure if there are any OS specific overrides for Linux. The Arduino documentation is not clear about that.
But you can use the versions without OS override (which are the default values) and may add:
tools.dfu-util.path={runtime.hardware.path}/STM32/tools/linux64/dfu-util

All you need will be in your home folder (I guess) in ~/Arduino/hardware (similar to Documents\Arduino\Hardware on Windows). You will need to install it there yourself.
My guess is that on Linux the BSFrance STM32 Arduino core should be put in directory: ~/Arduino/hardware/BSFrance-stm32.

In file ~/Arduino/hardware/BSFrance-stm32/STM32/platform.txt variable {runtime.hardware.path} will point to above directory so you can use it to specify full paths within the core’s directory tree.

The other platform.txt files you mentioned are from other installed STM32 Arduino cores (Roger Clark’s STM32 F1 and F3 Arduino cores, see www.stm32duino.com and Cores).

The world of (names of, supported functionality, compatibility of and references to different) Arduino cores for STM32 is not transparant and confusing. :thinking: :crazy_face: Much different than Arduino for AVR, SAM(D) and ESP32.

3 Likes
154

Do you have any plans for supporting STM32L1?

(STM32L1 is present on e.g. RAK WisTrio LoRa Tracker RAK5205).

1 Like
155

The short answer is no.

The long answer ends up in being no as well. L1 is missing a lot of things that L0/L4 have. Like the LPTIM/LPUART peripherals, or the independent clocking for USART / I2C. My interest is really ultra low power setups, and by that L1 is kind of obsolete.

If you are interested in a nice asset tracker, I’d like to point out GNAT. MAX-M8Q, which can track GPS and GLONASS in parallel. BMA400, with a sleep current of 160nA …

2 Likes
157

Dear all, I have read the thread but at the end I am not able to understand whether these platforms are easy to use or not with LoRaWAN.
To simplify my question: if I want to substitute a Lora32u4 with one of these, mostly because of memory constraints, which one is ok and easy to make it function (with Arduino IDE possibly)?
Thanks.

158

If you want to develop with the Arduino framework the problem is that there are many STM32 variants and many are not (or not well) supported with a corresponding Arduino Core.
So if you want to develop with Arduino the choice in STM32 variants that you can choose from is limited. A cheap Microchip AVR alternative is the ‘bluepill’ STM32 board. It can be used with the LMIC library.
STM32 development with Arduino is not a smooth ride, unless you have a good Arduino Core that supports the specific STM32 MCU you want to use.

@GrumpyOldPizza did a good job porting the SAM(L) Arduino Core to STM32 and he has also ported the Semtech LoRaWAN client (LoRaMac-node) reference implementation (instead of LMIC) but unfortunately his core supports only a select few models of the STM32 family.

Other alternatives for a more powerful MCU than AVR/ATmega32(u4) that are well supported for Arduino development are the Microchip SAM MCU’s and the Espressif ESP32. However, there currently exists no common/popular ESP32 (LoRa) boards suitable for low-power applications (if that is what you want). For SAM I don’t know.

3 Likes
159

Thanks - I have played with ESP32 too.
Regarding STM32, I was looking at the BSFrance boards, that are complete for LoRaWAN - I am not sure, but the closest to bluepill seems the LoRaM3-D F103, hopefully this could make things easier.

160

I have experimented with the BSFrance LoRaM-3D boards + Arduino framework (and have looked into their Arduino core) but for certain reasons BSFrance’s support for these boards has been underwhelming.
I have reported several issues almost a year ago but have not gotten any responce since. Also the BSFrance-stm32 Github repository has not been updated since.
A real pity because the LoRaM-3D boards appeared to be a nice addition to existing AVR and ESP32 LoRa boards and are powered with ARM MCU’s.

Like existing popular ESP32 LoRa boards, the current version of the BSFrance LoRaM-3D boards were not designed with low-power in mind (even while one of them has STM32 L151 MCU).

1 Like
161

Ok, you discouraged me :slightly_smiling_face:.

2 Likes
162

I would have preferred the opposite :slightly_smiling_face:
(good Arduino support from STMicroelectronics for a wide range of STM32 MCU’s).

163

The problem with all of this is that it’s rather complex. To deliver something that actually works, you cannot just throw things together quickly.

I had picked STM32L0 because of the Murata module. STM32L1 is kind of obsolete. If you need more horsepower, then STM32L4 would be the pick (and I’ll add support for that one eventually). It’s just not feasible to support everything under the sun.

So what is bad about just picking one of the board with the Murata module and get going ?

1 Like
164

The Things Network Community is diverse. Part of it is commercially oriented while another part is not, i.e. people who are not getting paid for their TTN adventures (e.g. hobbyists).
For commercial applications it may not be an issue to shelve $40+ for a muRata based board, but for non-commercial applications price is definitely an issue.
Low price is exactly why AVR (ATmega328), ESP32 and STM32 (‘bluepill’) based boards have become popular, where prices start at around $1.50 for a board (LoRa support not yet included).

165

Here is the reality. A nice LoRaWAN board costs between $40 and $99 (the ST GNSS variant). If you go cheap via e-bay you can get something for $20 (but not with GNSS and other goodies). So it’s really $20 vs. $40.

How much time do you kill with the $20 board to get things not working ? I do value a hour of uninterrupted time (may it be to play with electronics or going riding my road bike) for me at way more than $20 …

N.b. “BluePill” is cheap precisely because it’s obsolete …

1 Like
166

It’s up to decide for everyone themselves what they want to pay for a (basic) LoRaWAN node and this thread is not the place to discuss that. There are enough people interested in TTN and LoRaWAN that are not willing to pay a few hundred bucks for a hand full of nodes only to get familar with the technology or experiment with nodes for their hobby.
A muRata based LoRaWAN board on eBay for $20? Do you have some links?

167

I would concur with @bluejedi, we all have different views on the reality, i.e. the value of our time.

There is no right or wrong here.

168

And there is nothing wrong with folks picking their solution. My point is just that I have a problem understanding why somebody would want to save a few dollars (or euros) on the hardware, and then getting stuck with a non-functional setup due to the software.

I did not state there is a $20 Murata based board out there (actually, I have no clue). I just quickly looked up what the cheapest other LoRaWAN capabable board was, including shipping. The Murata based ones are all around $40, give or take.

Please also understand that my interest is really to experiment with low-power devices. I do not get a kickback from Murata or such. It just turns out to be the sweat spot, everything considered.

1 Like