[En-Nut-Discussion] using SPI Controller of AT91SAM7X

[Ulrich Prinz]

Am 13.03.2010 09:36, schrieb Dominik Schröder:
> Dear Ulrich
>
> Thanks for the long wiki article. But I`m sorry, I think I can`t find the
> right answers to my questions... :-)
>
Sorry for that, I know you're searching for the right connections to 
Nut/OS and I wanted to start a bit more basic as this was asked often 
before. I will go further now...

> I have three Displays here. One with the SSD1303, one with the SSD1327 and
> one with the SSD1329 controller. There are similarities between all
> controllers. But your right, in detail, there are differences between every
> controller. This makes it hard to write an universal driver. But this is not
> my Problem, I have implemented !lowlevel! drivers for the SSD1327 and the
> SSD1303 controllers. So I understand how to access the GDDRAM to show some
> chars or pictures... (I try to attach a sample File on this email. If it
> don`t work, I will search for any Webspace...)

You can simply post it to my eMail, no Problem with that.
>
> These displays/controllers working good with the TWI. (Ok, it`s not so fast,
> but it`s enough to show some chars...)
> I think my problem is not to write a new driver (initialization,
> send_command, send_data, show_char ...)  for the SSD1329 controller, my
> problem is to get the data via the SPI device to the display/controller...
> :-(
Attachments are not allowed in a mailinglist, caus it would explode in size.
>
> I hope attached you can find my implementation of the SSD1327 driver. The
> precise question is now, how to change the comm_out / data_out function to
> send the bytes via SPI and not via TWI... :-(
> Can anybody give my some examples about this?
>
Ok, I send you my driver, but it is a bit unsorted for now. I designed a 
plugin board for my companies project and fortunately ordered enough of 
them to take one home. I will clean up the driver tonight and put it 
into Nut/OS. It serves the SSD1303 display. I have to check if I have a 
SSD1325 type here too.
--------------

The Problem with SPI in Nut/OS is, that the driver is not using the 
hardware features of the different chips. On AVR you have to handle /CS 
manually via any GPIO port. With SAM you have lots more options from 
automatic handling of up to four chipselects to DMA (PDC).

What is bothering me as the existing SPI drivers are far to slow for my 
needs, maks it more easy for you to use it.

So first we keep it simple,m later we do it fast :)

Your entry for a device driver is the NUTDVICE. You should look for this 
driver description block on some other drivers.
As I cannot paste it into this email, it simply doesn't fit...

Let's see...
Ok, I continue the wiki text for your reference. It is now a bit puzzled 
but if time goes by I add everything needed to write a fully featured 
display driver.

http://www.ethernut.de/nutwiki/How_to_implement_a_character_display_API#Device_Driver

Have a look and tell me if that fits more the questions you have.

Best regards, Ulrich