Go Down

Topic: How to communicate as slave with SPI at 8MHz (Read 151 times) previous topic - next topic

HexTank

Sep 16, 2016, 12:22 pm Last Edit: Sep 16, 2016, 03:11 pm by HexTank
I have a hardware issue to overcome, I have a board that is using SPI as communication that is clocking at 8MHZ, I can't control this rate, but I'm wanting to use an Arduino as a slave device, which unfortunately can only clock at CLK/4 which is generally 4MHZ, reliably.

I can control the rate at which bytes are trasnfered, just not the incomming bit banging per byte. So what options are there? I though of maybe dealing with the MOSI line using an off board shift register, as I think that should suffice as MISO can run at CLK/2. MISO can't run at CLK/2, that's not how it works *facepalm*

But ideally some IC that can act as a SPI buffer for both directions would be ideal if such a thing exists.

So, has anyone attempted a similar thing and what solutions did you come up with?

Robin2

I don't know the answer. But your Title does not seem to me to convey the problem and, if so, someone who does know the answer may not bother to read your Thread.

It seems to me a better title would be "How to communicate with SPI at 8MHz" - but I am not an expert.

You can change the title if you edit your Original Post.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

HexTank


CrossRoads

Atmega328P Datasheet 19.5.2,
19.5.2 SPSR - SPI Status Register
Bit 0 - SPI2X: Double SPI Speed Bit
When this bit is written logic one the SPI speed (SCK Frequency) will be doubled when the SPI is in Master
mode (see Table 19-5). This means that the minimum SCK period will be two CPU clock periods.
When the SPI is configured as Slave, the SPI is only guaranteed to work at fosc/4 or lower.

Thus, 8 MHz transfers should not be counted on to work in Slave mode, only in Master mode.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

HexTank

Exactly what I put in the original post, bar it being a C&P from the data sheet? Hence my asking for a solution via an off board IC if available, or other.

CrossRoads

#5
Sep 16, 2016, 03:28 pm Last Edit: Sep 16, 2016, 04:07 pm by CrossRoads
How about this - use a FIFO in between? Each device will access the FIFO as a master, writes on one side and reads on the other, with both sides then capable of 8 MHz transfers.  Or a dual port SRAM. Or fake a dual port SRAM, with one side writing then flipping a control line to let the other side know to read the SRAM, with buffered control lines. I'll draw up a diagram.
http://www.digikey.com/product-search/en/integrated-circuits-ics/memory/2556980?k=sram&k=&pkeyword=sram&pv1291=862&FV=268001d%2Cfff40027%2Cfff80434%2C2380061&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize=25

Same concept can be used with other memory types (SRAM, FRAM, EEPROM) and 5V devices also.
One- or two-line notification can be used. With one-line, each would read the line and only access the part when the line was not pulled low by the other side, with internal pullups enabled, or an external pullup.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

HexTank

I suppose that's one solution, although the overhead of writing to an SRAm with the additional SPI commands required would cripple overall data rates.

I did think of doing back to back shiftregisters, in a similair way, but no extra SPI commands need to be issued, but not sure how feasable that actually is (I suspect there comes a point where there's so much off board logic - it's perhaps better finding an alternative board for the job, like an STduino or some such)

HexTank

I like the sram idea though, it could be used for better bulk transfering.  The only issue with my application is that the master has to poll the slave (as only SPI pins are availble) to ask if we need to start a conversation, so there are syncronization issues there on how can access the ram, and when.

CrossRoads

#8
Sep 16, 2016, 04:13 pm Last Edit: Sep 16, 2016, 04:18 pm by CrossRoads
How large are the data transfers to be made? I would think that 8 MHz transfers on both sides would yield the best results, vs 8 MHz on one side and 1/2 that on the other.  You could even go as big as 128K x 8, with all buffers powered from 5V, and just 2 buffer chips needed.
http://www.digikey.com/product-detail/en/microchip-technology/23LC1024-I-P/23LC1024-I-P-ND/3543083
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

HexTank

Most of the time it might be 2 bytes, others, more.

The general gist is.

Master asks slave (if one is attached) should we do stuff.
If so, Master then acknowledges reciept and asks for N bytes, depending on command.
This is hampered somewhat as the following is how the hardware is layed out.

SBC(CPU) -> Interface(SPI controller - no scope for modifying) -> arduino -> PC (for shooting stuff back to the SBC)

As the SBC doesn't directly interface with the SPI layer, it writes to an address which starts the signalling, there's no way for the SBC know when things are done, it has to send data to address, wait a few clocks, then read back.

You're correct in that one side can't run at at 1/2 and one at 1/4, but as the 1/2 can't lower its speed, then the 1/4 side needs some middle man to do the grint work.

The problem lay in your last diagram, there are no extra pins to do the handshaking, I merely have the 4 SPI pins to work with.

I suspect two shift registers from the interface, one to write to and one to read from, and use the SS to determine when to write back, this of course means finding 16 data pins on the arduino, adding a bus expander or having back to back shift registers 2x2.  Then things get complicated.

CrossRoads

"As the SBC doesn't directly interface with the SPI layer, it writes to an address which starts the signalling, there's no way for the SBC know when things are done, it has to send data to address, wait a few clocks, then read back."

If you're doing it that way, then leave out the handshaking pins.  Why would you need 16 data pins on the Arduino?
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

MorganS

What about a clock divider? Halve the clock rate in hardware and then have the master request two bytes?

These all seem like silly solutions to a silly problem. How is it that you can control the master and make it do strange requests on a buffer chip but you can't change its SPI speed?
GoForSmoke: "What GShield? You never mentioned a shield."

HexTank

@Crossroad 16 pins would be needed to talk to two shift registers, unless you had back to back shift registers. No handshaking means contention issues with your double master method.

@MorganS it's not doing any mystical magical strange request, the SBC just has a port from the CPU it can write to and read from, a third party card with its own CPLD does the translation, if I just lowered the clock on the carrd via crystal, the whole board would misbehave, the CPLD code is proprietary else I'd have changed it and not even posted this topic. :)

I've ordered a Maple Mini now anyway which is somewhat overkill, but pricewise the same, so moot.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy