Lpc2000

I think the basic problem is that the LPC213x SPI can only handle 8- 
to 16-bit transfers, and the Atmel device requires longer ones.

A simple way around this is to "bit-bang" the interface (i.e. use 
all pins as GPIO and drive them all in software). This is easy 
enough to do for SPI interfaces. Performance might take a bit of a 
hit, and you have to watch how interrupts may interfere with timing.

Brendan

--- In lpc2000@yahoogroups.com, "gogotimmo" <tah2k@...> wrote:
>
> Hi-
> 
> I am having probles with the LP32138 SSP (SPI) interface to an 
Atmel 
> dataflash (AT45DB161). I believe it has to do with the chip select 
> implementation. To read the status register of the Atmel 
dataflash, 
> for example, the device requires an opcode 'write' followed by 
> a 'read'. The write works fine, but the 'read' fails. I believe it 
is 
> failing because the chip select gets deasserted between the read 
and 
> write, thereby resetting the internal state machine of the data 
flash. 
> The datasheet of the atmel memory has timing diagrams that show 
the CS 
> asserted throughout the entire transfer with no transitions 
between 
> frames.  Actually, it looks like the LPC2138 spi chip select gets 
> deasserted between each frame in a continuous transfer. If true, 
this 
> bites. The only workaround I can think of is to use a GPIO pin to 
> drive the CS manually. Since I'm already out of pins, this isn't a 
> great option for me. I thought of tricking the SPI peripheral by 
> sending an 8-bit opcode justified in a 16-bit frame, which would 
> probably work, but will fail when reading an array of memory 
> addresses. These Atmel dataflash devices are extremely popular, so 
> someone must have had similar issues.
> 
> Also, I don't mean to sound rude, but I have already looked at the 
SPI 
> code examples. 
> 
> Any help is appreciated-
> Thanks-
> Tim
>