Efficient strategy to acquire multiple spi interfaced sensors data in parallellover several spi buses?

Ask QuestionAsked todayActive todayViewed 17 times0

I want to continuously acquire temperature from many ( ~20) thermocouple MAX 31856 all on one PCB ultimately. This chip interface with spi. The project language is python Because of the sensor latency, One multislave spi bus will be too slow.

So I would like to break down the sensors in several (4 or 5) independent spi buses that I could address in parallel with multithreading from a small computer ( raspi or other) on One addressable bus. I have found mcu with 2 spi master but none with more than that. I am considering using small mcu like the raspi pico for example and address them separately over an usb bus but i have not found any project doing that. Is there a problem with that approach? What will be other alternatives?usbsensorspiparallelbusShareCiteEditFollowFlagasked 1 hour agojf_vt111 bronze badge

• One thing that will be too slow for sure is your PC fluff running Python. That’s the wrong tool. Unless you have any harder real-time requirements, you could either just mux slave select or make a SPI daisy chain. What you need to do is to write a specification. What is the real-time response of the system overall? How are the sensors placed physically? What are the distances? How much data is there? From there on you can pick a suitable SPI setup and a MCU. – Lundin 1 hour ago 
• Ok I can add more specifics as per the Max 31856 datasheet one measurement takes ~200ms. 20 sensor on one spi bus ~4sec. the system already exists in Python with many other sensors and loop in 400ms without these new sensors. we can accept a loop time up to 1s but no more. There is jno distance this is a lab setting that will be ultimately integrated on One pcb, – jf_vt 1 hour ago 
• Surely you can read from the sensors even if they have no new data. Just read away once per ms or so, no higher baudrate is needed. Muxing /SS is the simplest solution but you could probably use daisy chain here too, to save a little bit of BoM. There seems to be no need for several SPI buses. – Lundin 1 hour ago 
• we can definitively try. we have a prototype for that.we just did not think of it thank you for suggesting it. – jf_vt 1 hour ago
• Why not analogue multiplex the thermocouples and let the MCU do the selection. Done this many times. Use a decent InAmp to provide common gain channel and a half-decent ADC for digitization. Requires just one SPI device (the ADC) and optionally something to drive the multiplexer select lines. – Andy aka 1 hour ago 
• This is possible but difficult to do in order to guarantee accurate measurements. Just look at the datasheet of the max 31856 that adress accuracy issues. This chip is already doing the hard work for us and provide a digital output. – jf_vt 1 hour ago
• Rpi Pico with two core M0 and two SPI controllers might do the job. You can use HC154 4-to-16 line decoder to chip select any one of sixteen MAX 31856’s at one time, Using 4 GPIO pins. Ref: 74HC154PW 4-to-16 line decoder/demultiplexer – Nexperia nexperia.com/products/analog-logic-ics/i-o-expansion-logic/…. Cheers. – tlfong01 6 mins ago    

Add a comment

2 Answers

ActiveOldestVotes0

If you want to multiplex your devices using the USB interface, make sure you:

1. Have an external USB hub

or

2. The data collector system has USB hub on-board

USB is a 1:1 peer-to-peer interface.

ou can’t just wire in parallel the extarnal devices.ShareCiteEditFollowFlaganswered 1 hour agoEnrico Migliore57822 silver badges66 bronze badges

• I agree with that and I could not found one project where it was done, this is why I am asking for advice as there might be non obvious difficulties or roadblock with that solution – jf_vt 1 hour ago

Add a comment0

RS485 is the right answer for your problem.

It’s master-slave interface meant for fairly high speed (up to 10 Kbyte/s) and long distances (up to 1 km).

Slave devices can be wired in parallel.

It requires a UART interface on the microprocessor. All microprocessors have at least one.

It requires a very simple software stack that you may find by googling: “serial communications C driver”.

The CAN interface will also do because it’s the automotive version of RS485 but it’s far less used in the maker’s world.ShareCiteEditFollowFlaganswered 1 hour agoEnrico Migliore57822 silver badges66 bronze badges

• The OP clarified in comments that this might end up a single PCB solution, so RS485 would be completely overkill and means you have to drag in de-centralized microcontrollers. The MAX parts used by the OP are also fairly low level. I see no reason not to use SPI. – Lundin 1 hour ago
• (As for CAN vs RS485, the main reason people still pick RS485 is “I don’t know CAN” – CAN is superior in almost every single way. There’s even CAN FD nowadays if you need more extreme data rates.) – Lundin 1 hour ago

Add a comment