[En-Nut-Discussion] Adding/Modifying Device Drivers

[Andrew Mieczkowski]

Thanks for the input,

 

I have included the at91_spi.c and .h files into my project and they seem to be looking for the specific IRQ handler structure, IRQ entry function, and IRQ control functions that are not included by default and that reside in ih_at91spi0.c and ih_at91spi1.c.

 

The interrupt handler files compile just fine when I included them alone and I run the "make clean" and "make install", but when I include the at91_spi.c file, I get 2 assembler errors (the output follows):

 

C:\DOCUME~1\ANDREW~1\LOCALS~1\Temp/ccA9aaaa.s: Assembler messages:

C:\DOCUME~1\ANDREW~1\LOCALS~1\Temp/ccA9aaaa.s:56: Error: invalid literal constan

t: pool needs to be closer

C:\DOCUME~1\ANDREW~1\LOCALS~1\Temp/ccA9aaaa.s:168: Error: invalid literal consta

nt: pool needs to be closer

make: *** [tcps.o] Error 1

 

 

I have found that when I remove line 104 of code:      outr(AIC_SVR(SPI0_ID), (unsigned int)SerialPeripheral0IrqEntry); 

from ih_at91spi0.c and line 104:                                outr(AIC_SVR(SPI1_ID), (unsigned int) SerialPeripheral1IrqEntry);

from ih_at91spi1.c the errors go away. As this is obviously where the interrupt vectors are set, I know I need these lines, but I do not seem to be able to pacify the compiler. I have compared the code to that used by the UART and EMAC, but they seem to be practically identical, aside from the peripheral constant and the function names of course. I have tried putting the code in one main c-file, including them earlier or later in the code, combining them differently, but I get the same error every time. Perhaps the interrupt handler code is too far away from the interrupt vector table to allow a valid jump and may need to be included earlier in the process to allow it to reside earlier in the program space so that vector is valid? This is just a guess, but it would seem to make sense with the symptoms.

 

I have used SPI so much in the past that I have considered writing some bit-banging routines, or some hard-coded PDC transfer code for the SPI peripheral instead, but I think it would be a shame to do so if I could use the Nut/OS to handle it like a simple UART.

 

Thanks again for your help.

 

Andrew Mieczkowski

 

 

Hello!
 
 
The documentation file dev_2at91__spi_8h.html describes the source
at91_spi.c
This is not a device driver, but a set of functions driving spi 0 on the
at91 architecture. Do they work for as an SW interface to SPI? 
 
I developed a device driver for an Ethernut 2.1 board some time ago and I
took the (avr) uart driver as an example.
It was not necessary to compile it with Nut/OS, I just included the
resulting source .c and .h files into my main program - that was good enough
for me.
 
The key was to understand the 2 structures NUTDEVICE and DCB. NUTDEVICE
needs to be set up to contain some basic information (the logical device
name, for example) and the addresses of the key functions of the driver.
(init, read, write control, ...)
On the other hand, NutRegisterDevice uses the address of the NUTDEVICE
structure to - register - the device and makes it possible "fopen" it by
using the "logical" name used in the NUTDEVICE structure.  
 
hth
 
Ernst
 
-----Ursprüngliche Nachricht-----
Von: en-nut-discussion-bounces at egnite.de <http://lists.egnite.de/mailman/listinfo/en-nut-discussion> 
[mailto:en-nut-discussion-bounces at egnite.de <http://lists.egnite.de/mailman/listinfo/en-nut-discussion> ] Im Auftrag von Andrew
Mieczkowski
Gesendet: Mittwoch, 21. März 2007 18:33
An: en-nut-discussion at egnite.de <http://lists.egnite.de/mailman/listinfo/en-nut-discussion> 
Betreff: [En-Nut-Discussion] Adding/Modifying Device Drivers
 
Hello again,
 
     I apologize in advance for repeating some of the original information,
but I have done so in the attempt to add additional specificity and clarity
to my situation.
 
 
 
     I am using Nut/OS with an AT91SAM7XC256-EK board and I would like to
use the SPI as a communication method similar to the UART. I have the
Yagarto ARM toolchain installed, but I have been using the "make clean"
and "make install" to compile my program for the ARM so far.
 
 
 
    As the UART is so easily implemented, is there a similar driver for SPI
communication somewhere? I have extensively searched for SPI driver
implementations, but the only one I have been able to locate is the one for
a Memory Card. Although this driver exists, I seem to be unable to modify
the source and incorporate it into my project. When I was using the Ethernut
2 board, I could always "rebuild all", but the method to do so for the ARM
seems to be eluding me. I have also seen mention of modification of make
files to perform various functions, but has also not been as fruitful as I
had hoped.
 
 
 
   Any assistance or a point in the right direction would be greatly
appreciated.
 
 
 
Thanks Again,
 
 
 
 
 
Andrew Mieczkowski