Lpc2000

Hello ALL,

I should writing and reading SPI registers as 8-bit or as 32-bit registers?
LPC is 32bit, but SPI registers have 8 bit. 

-- 
Jaromir
_________________________________________________________________
List sprawdzony skanerem poczty mks_vir ( http://www.mks.com.pl )


[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, "Jaromir" <jaromir.kajdaniak@z...> 
wrote:
> Hello ALL,
> 
> I should writing and reading SPI registers as 8-bit or as 32-bit 
registers?
> LPC is 32bit, but SPI registers have 8 bit. 
> Jaromir

Hello, there's a small example on Philips website.
have a look here :
http://www.semiconductors.philips.com/pip/LPC2132FBD64.html

and look at "AN10369_1: UART/SPI/I²C code examples (date 12-Apr-05)"

I use GCC and in lpc2114.h all registers are defined as
#define SPI_SPxx  (*(REG32 (0xE0020000)))

so I should change to  #define SPI_SPxx  (*(REG8 (0xE0020000)))    ???

  ----- Original Message ----- 
  From: valdef78 
  To: lpc2000@yahoogroups.com 
  Sent: Wednesday, May 25, 2005 10:19 AM
  Subject: [lpc2000] Re: accesing SPI registers


  --- In lpc2000@yahoogroups.com, "Jaromir" <jaromir.kajdaniak@z...> 
  wrote:
  > Hello ALL,
  > 
  > I should writing and reading SPI registers as 8-bit or as 32-bit 
  registers?
  > LPC is 32bit, but SPI registers have 8 bit. 
  > Jaromir

  Hello, there's a small example on Philips website.
  have a look here :
  http://www.semiconductors.philips.com/pip/LPC2132FBD64.html

  and look at "AN10369_1: UART/SPI/I²C code examples (date 12-Apr-05)"





------------------------------------------------------------------------------
  Yahoo! Groups Links

    a.. To visit your group on the web, go to:
    http://groups.yahoo.com/group/lpc2000/
      
    b.. To unsubscribe from this group, send an email to:
    lpc2000-unsubscribe@yahoogroups.com
      
    c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


_________________________________________________________________
List sprawdzony skanerem poczty mks_vir ( http://www.mks.com.pl )


[Non-text portions of this message have been removed]

> I should writing and reading SPI registers as 8-bit or as 32-bit
registers?
> LPC is 32bit, but SPI registers have 8 bit. 

You can access them as 32-bit, but it is wisest to only write zeros in
the undefined bits. Even though some registers are only 8-bit, they
are always spaced apart by 4 bytes.

The header files that come with the GNU-ARM toolchain specify all
registers as REG32. I experimented with setting the proper register
size in the header files (using REG8 for an 8-bit register). When
checking the assembly code, there now were more instructions to read
or write a register. I guess this is why the maintainers of the GNU
ARM toolchain chose to use REG32 exclusively.

By the way, this trick only works in  Little Endian. The LPC2000
series initializes the ARM7 core in Little Endian, but other
controllers may use Big Endian.

Kind regards,
Thiadmer

Jaromir wrote:

> Hello ALL,
>
> I should writing and reading SPI registers as 8-bit or as 32-bit 
> registers?
> LPC is 32bit, but SPI registers have 8 bit.
>
Top of page 183 of LPC2119/2129/2194/2294 manual:

"The SPI contains 5 registers as shown in Table 115. All registers are 
byte, half word and word accessible"

Coincidently, just yesterday I tried modifying my code from REG8 
(unsigned char) to REG32 (unsigned int) to see what effect this would 
have on the assembler, if any.
The assember was the same size and the code ran fine in both cases.

Just remember that the SPI DATA register, and Clock Counter and 
Interrupt registers only have one byte of defined data.

This may vary for other LPC parts in the 21/22 series, so check before 
jumping :-)

Now, can anyone tell me if there is clean, way to generate faster code than:

#define REG(addr) (*(volatile unsigned long *)(addr))
#define REG8(addr) (*(volatile char *)(addr))

in gcc? I don't like the multiple instruction to generate the address 
each access, but maybe that is typical/not bad. I'm
relatively new to ARM and RISC.

   Brett

At 11:37 AM 5/25/05 -0400, Brett Delmage wrote:
>Now, can anyone tell me if there is clean, way to generate faster code than:
>
>#define REG(addr) (*(volatile unsigned long *)(addr))
>#define REG8(addr) (*(volatile char *)(addr))
>
>in gcc? I don't like the multiple instruction to generate the address
>each access, but maybe that is typical/not bad. I'm
>relatively new to ARM and RISC.

I haven't done a comparison of code generation but I use ld in combination 
with gcc for this.

IE in the appropriate ld control file I have something like

/* SYSTEM CONTROL BLOCK */
         /* MAM */

PROVIDE( MAMCR = 0xE01FC000);
PROVIDE( MAMTIM = 0xE01FC004);


PROVIDE( MEMAP = 0xE01FC040);


then in a header file
/* SYSTEM CONTROL BLOCK */
         /* MAM */

extern unsigned char MAMCR;
extern unsigned char MAMTIM;


extern unsigned char MEMAP;

And to reference them in a source file, after including the appropriate 
header of course,

  MAMCR = (unsigned char)ctrl;           /*lint !e930 cast from enum     */
  MAMTIM = (unsigned char)cycle_time;


I find that 'cleaner' than pointer de-references.  YMMV  The biggest 
disadvantage is you end up depending on both the ld file and the header 
file.  I don't know how the code generation compares.

You can see this in the newlib-lpc source.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

At 11:37 AM 5/25/05 -0400, Brett Delmage wrote:

> >Now, can anyone tell me if there is clean, way to generate faster 
> code than:
> >
> >#define REG(addr) (*(volatile unsigned long *)(addr))
> >#define REG8(addr) (*(volatile char *)(addr))

Robert Adsett wrote:

> IE in the appropriate ld control file I have something like
>
> I find that 'cleaner' than pointer de-references.  YMMV  The biggest
> disadvantage is you end up depending on both the ld file and the header
> file.  I don't know how the code generation compares.
>
> You can see this in the newlib-lpc source.

Excellent. Thank you Robert! That is exactly what I wanted to do 
eventually. I have coded that way wih other CPUs and build tools and I 
agree that it is "cleaner".
At this point, I'm learning one new element at a time, and didn't want 
to dive into the linker in that detail yet. This past week I was happy, 
even with rougher code,  to get SPI to work with 3 different (types of) 
devices. The great thing about SPI (not) is that there are so many modes 
that every manufacturer can pick a unique one  :-p   = :o
I am glad to say that the LPC SPI, limited as it is, was up to the 
challenge.

   Brett

I am new to the ARM, but I know from my extensive AVR experience that removing 
the "volatile" directive can lead to bad code.  Is this a problem with what 
you are proposing for the ARM?

Without the volatile direction GCC may optimize access to the hardware 
registers more times, or less times that you expect.  You can end up clearing 
bits unintentionally this way.  For example a status register read may clear 
bits.

On Wednesday 25 May 2005 11:57 am, Robert Adsett wrote:
> At 11:37 AM 5/25/05 -0400, Brett Delmage wrote:

> >#define REG(addr) (*(volatile unsigned long *)(addr))
> >#define REG8(addr) (*(volatile char *)(addr))
...
> I haven't done a comparison of code generation but I use ld in combination
> with gcc for this.
...
> PROVIDE( MAMCR = 0xE01FC000);
> PROVIDE( MAMTIM = 0xE01FC004);
...
>   MAMCR = (unsigned char)ctrl;           /*lint !e930 cast from enum     */
>   MAMTIM = (unsigned char)cycle_time;

-- 
                          http://www.softwaresafety.net/
 http://www.unusualresearch.com/ http://www.bpaddock.com/

Robert Adsett wrote:

> At 11:37 AM 5/25/05 -0400, Brett Delmage wrote:
> 
>>Now, can anyone tell me if there is clean, way to generate faster code than:
>>
>>#define REG(addr) (*(volatile unsigned long *)(addr))
>>#define REG8(addr) (*(volatile char *)(addr))
>>
>>in gcc? I don't like the multiple instruction to generate the address
>>each access, but maybe that is typical/not bad. I'm
>>relatively new to ARM and RISC.
> 
> 
> I haven't done a comparison of code generation but I use ld in combination 
> with gcc for this.
> 
> IE in the appropriate ld control file I have something like
> 
> /* SYSTEM CONTROL BLOCK */
>          /* MAM */
> 
> PROVIDE( MAMCR = 0xE01FC000);
> PROVIDE( MAMTIM = 0xE01FC004);

> then in a header file
> /* SYSTEM CONTROL BLOCK */
>          /* MAM */
> 
> extern unsigned char MAMCR;
> extern unsigned char MAMTIM;

> You can see this in the newlib-lpc source.

Incidentally Robert, I had to add a couple of volatiles to the 
newlib-lpc lpx2XXX.h file in my case where you'd left them out (but most
registers had them). Probably for a case you weren't expecting, but I 
was re-programming PINSEL registers before sleeping.

Gcc had done a trick of moving the updates around since not specified 
volatile and of course it had weird (and non-obvious) results. Only
found the problem eventually by looking at the assembly code.

May be worth having a thought experiment on any other non-volatile 
registers specified.

-- 
Cheers,
Bruce
-------------------------------------------------------------------
     /\\\/\\\/\\\    /   /      Bruce Paterson
    /  \\\ \\\ \\\  /   /    Senior Design Engineer
   /   /\\\/\\\/\\\/   /   8 Anzed Court, Mulgrave, Vic, 3170
  /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
       Tele-IP Ltd.      Email: bruce@...    Icq: #32015991
                         WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------

At 11:54 AM 5/26/05 +1000, Bruce Paterson wrote:
>Robert Adsett wrote:
>
> > You can see this in the newlib-lpc source.
>
>Incidentally Robert, I had to add a couple of volatiles to the
>newlib-lpc lpx2XXX.h file in my case where you'd left them out (but most
>registers had them). Probably for a case you weren't expecting, but I
>was re-programming PINSEL registers before sleeping.
>
>Gcc had done a trick of moving the updates around since not specified
>volatile and of course it had weird (and non-obvious) results. Only
>found the problem eventually by looking at the assembly code.
>
>May be worth having a thought experiment on any other non-volatile
>registers specified.

Your right.  It probably would be.  I try to put them in only where 
necessary.  It's probably worth a check to make sure const is in there as 
often as possible as well.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/