Reply by Michael Johnson October 3, 20052005-10-03
Hi Dave,

It seems that S0SPCR has sprouted extra bits on the LPC213x and LPC214x.
The CrossWorks LPC21xx header file was generated from the register
description of an LPC2124 which doesn't have these extra bits. The next
release of CrossWorks has header files for each LPC device to avoid
these problems. For the time being can you modify your copy of LPC21xx.h
from

#define S0SPSR (*(volatile unsigned char *)0xE0020004)

to

#define S0SPSR (*(volatile unsigned short *)0xE0020004)

which should help out.

Regards
Michael

>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@lpc2..., "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@lpc2..., "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@lpc2..., 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
>>>>
>>> >
>Yahoo! Groups Links




An Engineer's Guide to the LPC2100 Series