Problem with QSPI.... communication speed?

[zippo445]

hi,
I'm using a MOD5270 I with the NetBurner QSPI driver to drive a SPI device.
device is responding in an erratic way...

the problem is probably around communication speed.
the devices SPI specs are the following : delay of 0.5ms after CS assertion, 125kHz max clock speed. it seems that the minimum clock speed I can reach with the 5270 is around 147kHz... any ideas on how I could slow this down to 125kHz?

thanks,

philippe

[yevgenit]

125kHz max SPI clock speed is seem unbelieveble low. The usual max SPI clock speed is a few megahertz.

Possibly, you can browse the source code of uC OS and change the PLL multiplier from 10 to any lower value.

[zippo445]

thanks for the reply...

>> 125kHz max SPI clock speed is seem unbelieveble low. The usual max SPI clock speed is a few megahertz.

indeed, it is very slow. the device is based on a Atmega8 and should be able to go faster but I don't have the source code for it and can't reprogram it....

for now I've partially succeded by rewriting a simple SPI driver inspired by the code found in <mmc_mcf.cpp> (the EFFS SPI driver) and transmitting the bytes one at a time.

I will eventually try to get the hand on the source for the device MCU to speed the comm. up and use the QSPI high level routines provided by netburner.....

philippe

[sblair]

Hey guys,

I think I'm facing the same situation. I'm trying to interface to a display using SPI that has a max clock speed of 125khz. I'm on a MOD5270 here. Is there any way to slow the SPI clock speed down low enough? What about I2C?

Here's the data sheet for the display I'm using: http://www.newhavendisplay.com/specs/NH ... SW-BBW.pdf

Thanks!
Scott

[seulater]

// BYTE QSPIInit( DWORD baudRateInBps = 2000000, BYTE transferSizeInBits = 8,
// BYTE peripheralChipSelects = 0x0F, BYTE chipSelectPolarity = 1,
// BYTE clockPolarity = 0, BYTE clockPhase = 1, BOOL doutHiz = TRUE,
// BYTE csToClockDelay = 0, BYTE delayAfterTransfer = 0 );


QSPIInit( 10000000, 8, 0, 1, 0, 0, TRUE, 0, 0);

[mhoyt]

If you can't get the QSPI peripheral to run as slow as you'd like, you could always just switch the QSPI pins over to GPIO and bit-bang the SPI protocol.
--Mike

[lgitlitz]

I think 145KHz is the slowest you are going to get at the default clock speed. What device are you talking to? I don't think I have seen any SPI peripherals with a max clock that low. I agree with mhoyt, SPI is one of the easier communications to bit bang with GPIO. Another option is reducing the system clock speed. This will effect performance for everything else but at least it will get your QSPI clock down. You can reduce the clock speed for the QSPI transfer and then bring it back up when you are finished. There is a post with an example for reducing clock to conserve power here: http://forum.embeddedethernet.com/viewt ... ?f=7&t=512

[seulater]

zippo445, tell us the device you are using. We can better help with more information.

@sblair, i would switch to I2C protocol for using this display. I2C is a slower protocol and would be better suited for talking to that display.

[sblair]

Hey guys,

This is the display I'm trying to talk to which takes both SPI and I2C. It states a max 100kHZ clock speed for both protocols. So if it doesn't look likely to get the SPI that slow, will it be possible to get the I2C that low?

http://www.newhavendisplay.com/specs/NH ... SW-BBW.pdf

Thanks!
Scott

[seulater]

honestly i would go with mhoyt idea. That is a ridiculously slow LCD interface for both SPI and I2C.