Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: LPC2131 SPI problem

2005-10-03 by drb5599

Charles,
If SPI only does 8-bit, why are there option bits in the Control 
Register (S0SPCR) to send and recieve 8, 9, 10,11,12,13,14,15,16 
bits of data?  The user manual pretty clearly indicates that the SPI 
is capable of this operation.
Did I miss something?  I don't see any "*" to indicate the option is 
only available on some parts of the family?

FYI, My real target processor is the LPC2141, but I am doing this 
development on the LPC2131.  According to the user manuals SPI 
description, they look identical.  
I currently have my SSP pins assigned to other functions so I can 
not use them. 
If you could please tell me where you read the SPI will only do 8-
bits, I would appreciate it.

Thanks again to everyone for the help
Dave



--- In lpc2000@yahoogroups.com, "charlesgrenz" <charles.grenz@s...> 
wrote:
> Hi, I am not sire about the 2131, but the 2138 has a SPI and SSP. 
The
> SPI only does 8 bit and the SSP allows from 4 (?) to 16 which is
> programmable.
> 
> Charles
> 
> --- In lpc2000@yahoogroups.com, "drb5599" <dbutler@c...> wrote:
> > Thanks for the good info guys.  I am looking at the assembly 
code 
> > for changing the SPI registers.  It's just a couple simple lines:
> > 
> > 165: S0SPCR = 0x0C24;  // Changed to 12-bits per transfer for 
LCD 
> > format. 
> > 0x0000215E  2124      MOV       R1,#0x24
> > 0x00002160  4829      LDR       R0,[PC,#0x00A4]
> > 0x00002162  7001      STRB      R1,[R0,#0x00]
> > 
> > you can see that the assembly code just puts the 0x24 in R1, the 
> > upper byte is gone?  Why would it do this?  I am using the 
memory 
> > and register watch windows as I step thru this code.  It is very 
> > clear to see that the upper byte is just ignored.  It's like the 
> > compiler thinks the S0SPCR register is 8-bits instead of 16. 
> > Ah..............
> > That just made me look in the LPC21xx.h file where:
> > #define S0SPCR         (*((volatile unsigned char *) 0xE0020000))
> > yes, it is defined as a char so it will only look at the first 
byte.
> > So I changed the char to short.
> > NO......it still does not work.????
> > 
> > Yes, I am using a GPIO for SEL.  That seems to work fine, I just 
> > can't change the size of the SPI buffer?
> > 
> > -Dave
> > 
> > 
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, Rob Jansen <rob@m...> wrote:
> > > Dave,
> > > 
> > > > So I configured the SPI control register to operate in this
> > > > mode.
> > > >
> > > > S0SPCR      =   0x0C24;
> > > > ...
> > > > However, when I step thru my code, and look at the S0SPCR 
> > register,
> > > > it
> > > > is written with a 0x0424!!!!!!!!!!!!!
> > > 
> > > Strange, I tried this on my 2138 and there it all works (to 
say, 
> > writing 
> > > to the register works).
> > > Should work on the 2131 also.
> > > I wrote a small program 
> > > (http://www.myvoice.nl/electronics/files/io-test.zip) to read 
and 
> > write 
> > > registers and memory - served me well a few times. typing "w 
> > e0020000 
> > > c24" will write to the memory location and read it back 
> > afterwards. 
> > > Typing "r e0020000" will read the memory. I used this program 
> > myself 
> > > already a few times - as soon as I don't trust the hardware I 
> > start 
> > > poking around in the chip ...
> > > 
> > > If writing to the register works, can you singlestep through 
the 
> > > assembly code (that's an istep in ARM AXD) or at least see the 
> > assembly 
> > > code and the CPU registers?
> > > 
> > > > Also I am new to LCD's never programmed one before, the 
format 
> > of the
> > > > data looks really strange.  If anybody knows some good 
tricks for
> > > > interfacing an LCD with a serial interface, I would be 
grateful.
> > > 
> > > I checked out the controller spec 
> > > (http://mxhaard.free.fr/spca50x/Doc/LCD/1621.PDF ?) and the 
> > interface 
> > > indeed is a bit strange compared to the I2C displays I am used 
to. 
> > Only 
> > > the command mode uses 12 bits, it you write data to the LCD 
you 
> > should 
> > > switch to 14 bits mode.
> > > 
> > > It should however be fairly easy, CS to a GPIO pin, WR to SCK 
and 
> > the 
> > > data pin of the LCD to MOSI. Configure CPOL=1 and CPHA=1 (see 
213x 
> > user 
> > > manual), LSBF=0. This gives SOSPCR =  0x0C6E to send the 
commands 
> > and 
> > > after initialization switch over to 0xE6E for 14 bits to send 
the 
> > first 
> > > 4 databits to a given address. Sequential datawrites should 
then 
> > be done 
> > > in 8 bits mode.
> > > This is why you should use a GPIO pin for the CS line. Sending 
> > commands 
> > > is now like:
> > > 
> > >     CS = Low, S0SPCR = 0x0C6E, S0SPDR = cmd, wait for SPI 
transfer 
> > > complete, CS = high.
> > > 
> > > Data:
> > > 
> > >     CS = Low, S0SPCR = 0xE6E, SOSPDR = addr/data, wait for SPI 
tr. 
> > > compl, S0SPCR=0x86E, S0SPDR = data/data, wait, (more data), CS 
= 
> > High
> > > 
> > > You cannot use SSEL for the CS line, the SSEL line will go 
> > inactive 
> > > between datatransfers.
> > > 
> > > Think I still prefer an I2C display, SPI only makes sense if 
you 
> > have a 
> > > larger (graphical) display.
> > > 
> > > Good luck,
> > > 
> > >     Rob

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.