Parallel bus configuration - Page 1
Forum section: electronics / projects

author: ricko_uk
author_rank: Super Contributor
timestamp: May 12, 2020, 01:48:45 pm
content: Hi,I am implementing a one-direction 8-bit bus between a Rasperry Pi and a micro. The Pi is always the master and the data direction is alway only from the Pi to the micro.Apart from the 8-bit bus lanes I am thinking of using the following signals:- 8-bit bus lanes- DATA_AVAILABLE (output from the Pi indicating tot he micro it wants to send data)- DATA_READ (output from the micro confirming it has read the data)Is anything missing? Do you think I might need any other signals?Thank you

author: madires
author_rank: Super Contributor
timestamp: May 12, 2020, 02:59:59 pm
content: How do you want to implement the bus on the second MCU? Polling the control line DATA_AVAILABLE regularly or interrupt driven?

author: ricko_uk
author_rank: Super Contributor
timestamp: May 12, 2020, 03:04:35 pm
content: Thank you Madires,it needs to be as fast as possible so definitely INT driven. Why? Any suggestions or guidelines?Thank you

author: madires
author_rank: Super Contributor
timestamp: May 12, 2020, 04:16:28 pm
content: If you use the interrupt driven approach you basically need just a strobe line. For example, the RasPi could set the data bus and pull the strobe line high to indicate that there's data to read. The IRQ on the other MCU is triggered by the strobe and the IRQ handler reads the data bus. Figure out the timing for whole process including safety margins and you'll have a very simple bus protocol.

author: duak
author_rank: Super Contributor
timestamp: May 12, 2020, 04:55:21 pm
content: I've found it's nice to know from the software & diagnostics side that the destination micro has accepted the data so I wouldn't give up the DATA_READ line. This gives an indirect indication that the micro is working properly.It can be handy to have a RESET or INIT signal to the micro to put it in a known state.

author: ricko_uk
author_rank: Super Contributor
timestamp: May 12, 2020, 07:08:49 pm
content: Thank you Duak and Madires!!

author: Ian.M
author_rank: Super Contributor
timestamp: May 12, 2020, 08:10:49 pm
content: If you really want as fast as possible, it may be worth looking at using the Pi's SPI interface as its DMA capable and can run at speeds up to 32Mb/s (4MB/s). I'd lay odds that's a good bit faster than you can bit-bang parallel GPIO, unless you are coding 'bare metal' and running without an OS. The hardware can handle DMA transfers of up to 65535 bytes, and default buffer size is 4096, so you could potentially dump a 4096 byte block of data to your target in fractionally over 1us. Unfortunately I understand SPI slave mode is borked, and there is no possibility of flow control once a transfer is started when the Pi is a master, so your target, once its initially ready, has to be able to accept the whole data block at the rate the Pi is sending it. To get a byte strobe pulse, you'll need a fast divide by eight counter driven by the SPI clock, and held cleared by /CS high so its synchronised to the transfer. You'll also need a *fast* SIPO shift register to handle the SPI to parallel conversion.

author: ricko_uk
author_rank: Super Contributor
timestamp: May 14, 2020, 11:12:33 pm
content: As always, thank you Ian!!I didn't know about the Pi's DMA, large SPI buffer and 32Mbps. I think that might be the best solution!!Thank you!

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 15, 2020, 12:21:02 am
content: If fast transfer is importent, then how fast do you want it?Have you thought about the BeagleBone Black?It's not the fastest Linux capable board around, but it's got 2 built-in PRU's(Programmable Realtime Units).Those are basically 2 microcontrollers which have their own program, but also have access to a shared region of the BBB's RAM.I think you can transfer about 100MiB/s this way.Programming the PRU's was a bit difficult in the beginning, but since a few years (I think 2018) you can apparently program them with GCC.