Go Down

Topic: DUE serial speeds (not USB) (Read 626 times) previous topic - next topic

weird_dave

I'm considering options for connecting a DUE to a FPGA running at 50MHz. An easy (for me) option would be to use a serial protocol (3v3 level RS232 style), but I'm struggling to find information on what baud rates are available. I'd like to run at the highest speed possible to keep the latency down. Non-standard speeds are completely acceptable to me :) .
The SAM3X datasheet suggests that baud rates of the master clock divided by multiples of 8 are achievable, so I was considering a divider of 32 (19 on the FPGA) for a baud rate error of 0.25% at 2.625Mbit/s.
Does that sound reasonable? Something like Serial1.begin(2625000);


weird_dave

After much thought, I think implementing a simple SPI slave on the FPGA should be easy and allow a much faster transfer rate.
This page:
https://www.arduino.cc/en/Reference/DueExtendedSPI
Suggests I can transfer bytes in both directions simultaneously along the lines of:
Code: [Select]
for (byte i=0; i<128; i++)
{
  RxBuffer[i] = SPI.transfer(4, TxBuffer[i]);
}

Does this seem like a sensible option? I suspect 28MHz transfer should work well.
(I admit there is a waste in RAM by having the buffers the same length in that example, but for simplicity, meh ;) ).

Rufe0

Just out of interest why do you need the high data rate?

If it's to trigger an event or something like that then it would be better to simply toggle a pin on the FPGA and connect it to an interrupt pin on the arduino.

weird_dave

There's a lot of data going back and forth over a network, the Arduino is there to make the Ethernet part of the equation simple. I could control the wiznet chip with the FPGA directly but I'm trying to make this as easy as possible. This particular project isn't Arduino-centric, all of the work is already on the FPGA, I'm just looking  at a simple option to transfer data to another FPGA via ethernet, adding arduino's and wiznet chips would seem to be the least hair pulling solution.

Rufe0

Fair enough but personally I would have thought you'd be better off incorporating it into your FPGA design but I don't have any experience with them.

weird_dave

It's certainly possible, but it's a lot of work, potentially faster as well as there are no software overheads (nothing between SPI commands for example).
I'm wondering what the potential there is for a parallel read or write of 8 bits, ideally I'd want a byte input and a byte output rather than a bidirectional byte worth of pins, safer on the oopsie moments...

Go Up