Using STM32 to replace old peripheral chip but it needs 8-bit parallel data bus to communicate with the Core like 8051

[zhiyongwoo]

Can STM32 able to replace an old peripheral that required 8-bit parallel data bus and communicate between 8051 MCU. We can't modify the 8051 MCU and we can't use FPGA too.

I know FSMC is very close solution to my case but in my situation, the STM32 is not the core/host MCU instead it act as a device/peripheral.

The data bus speed is at 3MHz. The 8051 require to read back the data from STM32 before 3rd clock cycle of the 3MHz.

Possible to use FSMC in this situation? or using highest clock speed like 180MHz STM32 to act on the data bus as fast as possible?

[Tesla DeLorean]

STM32 doesn't behave the way you want.

You could use a pin associated with a TIM_CHx, input capture mode, and having the DMA2 trigger from that same source, writing a word to GPIOx->ODR or GPIOx->BSSR

Not sure you could use EXTI to respond quick enough, you'd need to show expected interaction (full) with the 8051 via a timing diagram.

[TDK]

So you have 1us to respond to a command.

It would be tight, but you could use some amount of SPI/DUALSPI/QUADSPI in some configuration to read in data and respond.

Not sure on the FSMC questions.

[Jack Peacock_2]

You can use the FMC if you place a 74HC573 type octal latch between the STM32 data bus and the 8051. Write a byte to the latch, configuring the FMC as a SRAM/NOR flash type device. When the RD* strobe (combined with CS* if needed) from the 8051 occurs the latch output is enabled on falling edge. Use the RD* rising edge to an EXTI pin to signal the STM32 to write the next byte. This also gives you true tri-state connection to the 8051 data bus side, in case you have multiple devices on the bus.

For a block transfer use the RD* rising edge connected to a timer capture pin, as described earlier, as a DMA trigger to transfer the next byte to the latch. No IRQ latency with that approach, should easily handle 3MHz as long as the STM32 has a faster system clock to handle DMA and FMC latency.

Jack Peacock

[Tesla DeLorean]

Would have perhaps helped if the OP had been more broad in their initial post.

If the peripheral operates in a stateful fashion, data could be written to a couple of latching registers, with self setting/clearing status bit and those serviced by an STM32 EXTI in a manner timely enough to meet or exceed the original device. Could definitely be done using discrete logic, although it might be easier with a CPLD/FPGA

Sort of things built with 74 series 244, 245, 273 and 374 type devices in days of yore.

[waclawek.jan]

Maybe you want to have a look at the new PSSI interface

https://community.st.com/s/question/0D50X0000C9eznY/parallel-synchronous-slave-interface-pssi-hosttohost-appnote-or-example

JW

[zhiyongwoo]

At the moment I am using EXTI to respond and with the core freq running at 84MHz, it took almost 200nS to reach the IRQ handler code.

The method you mention looks like it may be able to reduce the IRQ latency? May I know which chapter I should refer to in order to use your suggested method?

[Tesla DeLorean]

With external buffers/latches the EXTI latency can be hidden in the interactions with the registers, ie pretending to be a PIO, FDC or UART/SIO device.

Assuming an F4, but not specific. Try starting with the DMA chapter in the Reference Manual, and the trigger sources, work back to the TIM and GPIO.

DMA2 on the F4/F7 needed for memory-to-memory transactions as GPIO registers not on an APB

[zhiyongwoo]

Great. Yes looks like having TIM capture interrupt is faster.

What about moving the code into RAM to execute is faster than running on Flash. Does this affect my DMA memory to memory operation? or make it even slower?

Do you think I should go into this direction too?

[berendi]

Moving code to RAM might indeed make DMA operations slightly slower, if they both are contending for the same RAM module, but the difference is negligible.