[En-Nut-Discussion] SPI Bus

[Thiago A. Corrêa]

Hi,

On Thu, Feb 26, 2009 at 6:19 AM, Ole Reinhardt
<ole.reinhardt at embedded-it.de> wrote:
> Hi Thiago,
>
> just some ideas for testing your driver:
>
> First I'd use a logic analyser or just a good digital scope to log and
> see if your driver does what you expect from it. At least you can test
> the writer side with this equipment.

Unfortunally, I only have an osciloscope available. :(
I was able to see the clock signal and MOSI changing states as I
transfer data, but since I didn't get a reply from the LCD I couldn't
see the MISO.

> Using a dataflash would be a good idea too. You could try to use the
> NutOSs dataflash driver or even just send some simple commands on your
> own. You can for example try to just initialize the dataflash and see
> what happens. Again, the logic analyser would be a good help to take a
> look into the bus.

I suppose I could take some code from the drivers to do that. But it
would be nice if we could get a sample out of it.
I created a "displayd" sample to test the LCD, but since it didn't
work as SPI, it would need to be redesigned or scrapped.
The idea was to just copy whatever comes from TCP socket to the
display, then I would get a test and we would get a new sample :)

If I create a sample dataflash, how would I initialize it's contents?
I don't have any experience outside urom filesystem. :(

> Do you have a mmc/sd card installed? The NutOS mmc driver is well tested
> and you can try to make it working with your SPI implementation.

Yes, the EVK1100 has an MMC slot. To do that, I would have to
implement an spi_mmc.c driver right? That uses the SPI Bus. Currently
I see some using the bit bang spi only, or am I missing the one using
the bus?

> Last but not least, use an AVR spi slave. Then you can controle and
> debug byte by byte.

I was hopping to get by with only the dev kit for the bus driver. Much
later on, when we merge the AVR32 port, I would certainly like to take
a look at hooking up an ATRF230 and perhaps make it a driver with the
IFTYP_NET type. But that's too far ahead for me :)

>> I was trying to test writting a driver for the DIP204 display (KS0073
>> in serial mode) found on the EVK1100. But looks like this is not
>> exactly SPI compliant, as it doesn't transfer bytes back to the host
>> on all and each send, which is incompatible with the SPI Bus from
>> ethernut.
>
> Do you have a datasheet? If you like I could take a look into it. I have
> made some experience with the SPI bus though (on AVR, AT91, XScale,
> Blackfin)

Information is scarse on that. I know it's an KS0073 controler in
serial mode. The manufacturer provides this:
http://www.lcd-module.de/eng/pdf/doma/dip204-4e.pdf

and that PDF points to this Samsung KS0073
http://www.lcd-module.de/eng/pdf/zubehoer/ks0073.pdf

I used the Software Framework driver as a basis, and implemented it
with the SPI Bus API, which should make it platform independent:

http://code.google.com/p/ethernut-uc3/source/browse/trunk/nut/dev/spi_dip204.c

But since the Atmel driver does writes without reads I'm guessing SPI
isn't the proper interface for that, even though Atmel used it.
The way it is, it just freezes at the spi bus transfer routine, as a
reply never comes for the initialization commands. I can only get past
initialization if I change the SPI bus driver not to wait for a data
receive when the receive buffer from the upper layer is null. Thus my
question wheather that is valid for SPI or not, to transmit without
receiving. From the AVR32 datasheet, it says it isn't. But then again,
Atmel violated that statement on their driver.

Thanks,
   Thiago A. Correa