1

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,hardware 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? healthy pads

2
  • The I2C bus seems like an obvious possibility - have you looked into it?
    – dlu
    Apr 3 '18 at 21:47
  • I am new to all this so I didn't know were to start but I'll check it
    – Abyr
    Apr 3 '18 at 21:49
0

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.

3
  • I know about the fact that stm32 has an I2C and and SPI interfaces and that these are communication protocols , but didn't know how to choose between them , what .questions should be answered to know which is the best for my application and also I wasn't sure that I could transfer features through these interfaces it seemed like a lot of data to be shared
    – Abyr
    Apr 3 '18 at 22:20
  • This may help: Tradeoffs when considering SPI or I2C? - you have hardware for both so it may come down to speed and noise, both of which seem to favor SPI. I haven't looked at the libraries so that may also be a factor.
    – dlu
    Apr 3 '18 at 22:29
  • What about UART and USART can I consider using one of them in this application and why
    – Abyr
    Apr 4 '18 at 10:23
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.