Adding wifi to STM32

[JMart.5]

Hi everybody,

I am working on a project based on the Nucleo-L152RE.

I collect large amounts of data from several sensors (high sample rate) and store the data in a micro sd card. When measure is over I would like to send the raw data to a phone using WIFI (tried bluetooth but speed is not enough for me) .

I have never added wifi connectivity before. Im quite overwhelmed with too much information out there...

What do you recommend me to use?

I've been trying with the ESP8266 but there is too much information out there and I cannot find a good example of what I want. I don't want to set up a webserver.

Do you now any good tutorial or documentation that could help me here?

I am using STM32CubeMX,STM32CubeIDE, STLinkV2 and HAL

Thqnks and stay safe!

[TDK]

ESP8266 is by far the easiest, IMO.

> I collect large amounts of data from several sensors (high sample rate) and store the data in a micro sd card. When measure is over I would like to send the raw data to a phone using WIFI (tried bluetooth but speed is not enough for me).

I don't think you're going to find an example that has exactly what you want. It's a learning process. Try to replicate an existing example, or take parts from it and go from there.

[berendi]

I have some doubts that storing "large amounts of data" to a SD card would work. SD cards can have write latencies up to 250 ms. How long does it take for the samples to fill up the 80 kBytes of RAM on the L152RE?

How large are exactly those amounts of data?

[Harvey White]

The ESP8266 should be avoided when in the 8 pin board, and here's why, especially if you use an RTOS. The UART/USART in the ST chips has effectively no fifo at all, and when you task switch, you can miss data or overrun the USART data register. While the ESP chip does have flow control, those pins are not brought out on the 8 pin board. So to avoid missing data, you need either flow control or you need a FIFO that's big enough to hold enough receive data (where the problem is) during task switching times.

The ESP-12 form factor (the multiple pin version of the ESP chip on a carrier) does have flow control, so if the USART can be enabled with flow control, it's possible that the internal USART will work. That is not the approach I took. I used a separate I2C chip, the SC16IS750, which is a serial to I2C chip. I2C plays nice with an operating system. The SC16 has built in flow control and a 64 byte FIFO. The SC16 flow control lines can connect directly to the ESP.

The ESP can be set up peer to peer, with a serial passthrough of data. That's effectively writing to a serial port and having the data come out the other end as a serial port, which your program can access as a socket.

That might be a good start.

[turboscrew]

I kinda think that in STM32s, the DMA is meant for "add-on FIFOs".

[Harvey White]

As I understand it, you don't have a way of looking at the FIFO pointers under DMA, so that's not quite as useful as it might be, since I don't have an idea how much data is there. There was something important missing when I looked at DMA. I never got an answer to whether or not DMA worked if interrupts were turned off (as they are when context switching tasks). If they are, then we still might miss data.

Not at all sure that the HAL level drivers were ever designed to be able to work with an operating system. If so, I haven't found that part of the documentation.

Sometimes it seems better to throw hardware at the problem.

[TDK]

> As I understand it, you don't have a way of looking at the FIFO pointers under DMA, so that's not quite as useful as it might be

You can use the relevant DMA stream's NDTR register to see exactly how many bytes are available. It's really quite convenient. I use circular DMA for outgoing and incoming UART streams and it works very well.

[berendi]

> I never got an answer to whether or not DMA worked if interrupts were turned off

DMA works even if you don't enable any interrupts at all. Just make sure the software looks at the buffer before it overflows, it doesn't matter how.

> Not at all sure that the HAL level drivers were ever designed to be able to work with an operating system.

They were designed to work in simple examples, not in real life projects.

> If so, I haven't found that part of the documentation.

HAL being barely documented, and users working based on assumptions is a significant part of its problems.

> Sometimes it seems better to throw hardware at the problem.

HAL effectively prevents throwing the hardware present in the MCU at problems.