Interfacing of arm core M0 mcu with spartan 3e FPGA

[Gautam Sadarangani]

I need to interface stm32f030 mcu with basys2 spartan 3e fpga.

I know of two methods which might work but Im not sure of :-
1) connecting using rs 232
2) connecting using spi protocol

if there is any other method let me know....

I need guidance on how to accomplish this interfacing, I dont need to program the fpga using the mcu, I will program each separately

 

[shaiko]

The FPGA side can be viewed as infinitely versatile - allowing many implementation options for almost any communication protocol.
The MCU is more dependent on the available peripherals (if you want to stay efficient timing wise). If timing requirements aren't very tight - you can implement your protocol via GPIO "bit banging".

As long as you have the required physical layer on both sides - you have many options...

Do you have the schematics for the PCB with the STM32F030 on it?

 

[FvM]

From serial protocol candidates, SPI involves usually the lowest effort at the FPGA side. It's also the fastest protocol if supported by a hardware interface in the µP, which is the case with ARM.

Makes SPI is the obvious way.

 

[Gautam Sadarangani]

Thanks for the advice

I have the schematics for the stm discovery board

The link for it is
https://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00092306.pdf

its on the last page of this pdf

 

[Gautam Sadarangani]

Thanks, going ahead with the spi choice

 

[shaiko]

Instead of choosing between "protocol names" - I suggest you learn the properties of the most common protocols and from that deduct the pros & cons when applied for your application.

For example:

SPI -

Good:
Allows faster speed.
Doesn't require synchronization logic on the slave side.

Bad:
Requires more wires (may be a deal breaker).

Good/Bad (depends on your application - you decide):
Full duplex - Tx and Rx happen at the same time.
Master - Slave protocol. Transactions are initiated by the Master.

 

[FvM]

Instead of choosing between "protocol names" - I suggest you learn the properties of the most common protocols and from that deduct the pros & cons when applied for your application.

Don't you think that the OP can perfectly learn about serial protocols by implementing one and experiencing the pro and cons?

Knowledge can remain quite abstract if you don't apply it to real problems.

 

[shaiko]

Don't you think that the OP can perfectly learn about serial protocols

Sure - where did I say otherwise?

I doubt that the communication protocol is the essence of the OP's project - I think it's an (important) element in the bigger application.
In that case selecting one communication scheme over the other may come with problematic "features" that may dictate less then optimal design of the application.

I wanted to emphasize - that there's no "correct" answer.

The thing I find most problematic in having SPI interconnect 2 (big) systems is the inability of the slave to initiate transactions.

 

[Gautam Sadarangani]

Sure - where did I say otherwise?

I doubt that the communication protocol is the essence of the OP's project - I think it's an (important) element in the bigger application.
In that case selecting one communication scheme over the other may come with problematic "features" that may dictate less then optimal design of the application.

I wanted to emphasize - that there's no "correct" answer.

The thing I find most problematic in having SPI interconnect 2 (big) systems is the inability of the slave to initiate transactions.

Thanks for bringing it to my attention , in my project the slave will need to initiate communication so
I will think about USART too and then decide

 

[FvM]

Presuming that the communication is regularly carried out by the ARM, an interrupt line would be the usual method to signal a service request from the FPGA. You can even use SPI MISO line for this purpose without losing another pin pair.