Communication between Raspberry Pi and STM32

Question

I am working on an ECG signal processing project to detect heart arrhythmia in real time and notify the doctor via SMS , initially I was using a raspberry pi 3 b+ for the processing an AD8232 ECG acquisition sensor to get the ECG signal and a SIM808 GSM module to send SMS messages since the websites providing that service are not available in my country, however I just discovered that the Pi does not contain an ADC and that I will need to use an external module to perform the conversion. I have an STM32 F4 so I thought I might use it's ADC and perform the signal processing there as well since it contains a digital signal processing which is faster, and then send the results to the Pi, the results are the features of the signal needed for the classification we're using SVM. Finally it will send the SMS to the doctor.

To sum up, my questions is how can I communicate between the Pi and the STM32 to share these features?

I am sharing a lot of details about the project because I need an opinion about this solution – finally one more question for those who have used ECG sensors are these Healthy Pads reusable?

Answer 1

A quick look at the STM32 F4 info on Wikipedia shows that it has I2C and SPI interfaces as well as a lot of GPIO pins. At first thought I2C or SPI seem like a better choice than GPIO both for economy of pins and because they handle a lot of the inter-device protocol issues for you so that you can focus on getting the data you need from the STM32.

You sound like you have given this a fair bit of thought and you must be pretty comfortable with a lot of this project...

So, at the risk of stating the obvious and hoping that I'm not way off base, a good way to start might be to block out the functionality and where the responsibilities lie – for example it sounds like you're planning to do EKG capture on the STM32 and communication with the SIM808 and, I assume, coordinate things and provide the user interface with the Pi – so the next step could be to decide how the devices exchange information and build a simple mock up to test the interfaces. Try to minimize the coupling between components so that you can test each one on its own.

I'll stop for now, it feels like too much unasked for advice, but feel free to ask more questions. Hopefully others will jump in as well.

Answer 2

Very late to the party, but here is my take, since I had a different project with the same microcontroller/PI hardware. . . It may help someone in the future.

Iy my project, the Pi is used as the master controller, and for displaying results, accepting user inputs (e.g. parameter changes, etc.)

The STM is a satellite I/O controller, driving outputs in response to either master controller commands or in response to input events.

The STM also monitors inputs at speed, buffers results, and when polled reports the results back to the master controller.

After consideration and some experiments, I chose one of the STM's SPI channels as the intercommunication for several reasons.

1. The only inter-communication is between one STM and one Pi. No multidrop, although the second SPI channel on the Pi is used to read/write to a SPI FRAM to persist data. So the multi-slave capability of IIC, while sometimes very useful, was not needed.

2. The speed is much higher for SPI.

3. Using SPI left the STM's IIC channel free in case I needed to add a bunch of IO in future iterations, or for similar designed with different IO needs. In fact, I did just that on another device that only needed a lot of outputs and not a terribly fast speed.

4. I had total control of the comm protocol, so I could optimize things for SPI. IIC devices are often more chatty. I did implement C0BS for rudimentary error checking, but that was not expensive.

5. The SPI transactions are bidirectional and interleaved. I only had summary data coming back to the master controller, so I could get it at the same time the master controller sent a command or polled the STM.

All in all, it worked fine. My only concern is that the WiringPi library is no longer being supported by Gordon, and he hasn't released the source code for his last revision. Some day I may need to dig in an write a kernel driver to replace that C library.

Hope everything worked out for you.