Lpc2000

Hello All,

For a while I'm thinking to make a benchmark code which to run on all 
boards with ARMs we already have: Philips LPC2xxx, OKI ML67Q5xxx, TI 
TMS470, ST STR711&STR712, Analog devices ADuC7xxx, Cirrus EP9301, 
Atmel SAM7S.
Although the core is same, all they access the peripherials at 
different speeds, have different cache, Memory accelerators etc.
What we would like to see is how each of these ARMs perform the code 
from internal/external RAM, SDRAM, internal/external Flash, how they 
run Thumb and Arm code, how fast they can toggle their GPIOs etc.
This will allow us then when we have project to decide better which 
ARM will best do the job better than others
I did some googling and found some Dhrystone and Weatstone codes, 
which basicly run some Timer then do some maths and read back the 
timer and see how long it took to perform this.
I'm sure many peoples of this list have more experience in this so 
any ideas and suggestions are welcome.
Another idea is to compiler this code on the different compilers we 
have licensees for: IAR EWARM, Rowley CrossWorks, Keil uVision and 
GCC of course, so we can benchmark how efficient these compilers run 
on the different ARMs from the different vendors.

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430  
(http://www.olimex.com/dev)

Hi,

I did benchmark different architectures / tool-chain
combo by running the same dhrystone code.

You can see the table here:
http://geocities.com/michaelanburaj/downloads/dhry.gif

Also code size comparison by using different
tool-chains:
http://geocities.com/michaelanburaj/downloads/code_lpc.txt

You can do similarly for GPIOs too (switching time) by
measuring it using a LA.


Cheers,
-Mike.

--- tsvetanusunov <tusunov@...> wrote:

> 
> Hello All,
> 
> For a while I'm thinking to make a benchmark code
> which to run on all 
> boards with ARMs we already have: Philips LPC2xxx,
> OKI ML67Q5xxx, TI 
> TMS470, ST STR711&STR712, Analog devices ADuC7xxx,
> Cirrus EP9301, 
> Atmel SAM7S.
> Although the core is same, all they access the
> peripherials at 
> different speeds, have different cache, Memory
> accelerators etc.
> What we would like to see is how each of these ARMs
> perform the code 
> from internal/external RAM, SDRAM, internal/external
> Flash, how they 
> run Thumb and Arm code, how fast they can toggle
> their GPIOs etc.
> This will allow us then when we have project to
> decide better which 
> ARM will best do the job better than others
> I did some googling and found some Dhrystone and
> Weatstone codes, 
> which basicly run some Timer then do some maths and
> read back the 
> timer and see how long it took to perform this.
> I'm sure many peoples of this list have more
> experience in this so 
> any ideas and suggestions are welcome.
> Another idea is to compiler this code on the
> different compilers we 
> have licensees for: IAR EWARM, Rowley CrossWorks,
> Keil uVision and 
> GCC of course, so we can benchmark how efficient
> these compilers run 
> on the different ARMs from the different vendors.
> 
> Best regards
> Tsvetan
> ---
> PCB prototypes for $26 at http://run.to/pcb 
> (http://www.olimex.com/pcb)
> PCB any volume assembly
> (http://www.olimex.com/pcb/protoa.html)
> Development boards for ARM, AVR, PIC, MAXQ2000 and
> MSP430  
> (http://www.olimex.com/dev)
> 
> 
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

> I did benchmark different architectures / tool-chain
> combo by running the same dhrystone code.
> 
> You can see the table here:
> http://geocities.com/michaelanburaj/downloads/dhry.gif
> 
> Also code size comparison by using different
> tool-chains:
> http://geocities.com/michaelanburaj/downloads/code_lpc.txt

pretty interesting to see that GCC make shorter code than ADS :)
All benchmarks I've seen on ARM, Keil etc web site show that GCC 
usually produces twice bigger code, while you test show other!
 
> You can do similarly for GPIOs too (switching time) by
> measuring it using a LA.

we'll certainly do this, preliminary info we received shows that 
Atmel SAM7 can drive GPIOs twice faster than LPC i.e. 60Mhz LPC can 
drive up to 5Mhz GPIO (12 clocks per port toggle) while SAM7 do the 
same for 6 clocks 

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
(http://www.olimex.com/dev)

May be I missed something but the program compiled with GCC and the
one with ADS seem to have nothing in common. Is it correct that these
are totally different programs compiled with GCC and ADS?

Bob

--- In lpc2000@yahoogroups.com, "tsvetanusunov" <tusunov@m...> wrote:

> 
> > I did benchmark different architectures / tool-chain
> > combo by running the same dhrystone code.
> > 
> > You can see the table here:
> > http://geocities.com/michaelanburaj/downloads/dhry.gif
> > 
> > Also code size comparison by using different
> > tool-chains:
> > http://geocities.com/michaelanburaj/downloads/code_lpc.txt
> 
> pretty interesting to see that GCC make shorter code than ADS :)
> All benchmarks I've seen on ARM, Keil etc web site show that GCC 
> usually produces twice bigger code, while you test show other!
>  
> > You can do similarly for GPIOs too (switching time) by
> > measuring it using a LA.
> 
> we'll certainly do this, preliminary info we received shows that 
> Atmel SAM7 can drive GPIOs twice faster than LPC i.e. 60Mhz LPC can 
> drive up to 5Mhz GPIO (12 clocks per port toggle) while SAM7 do the 
> same for 6 clocks 
> 
> Best regards
> Tsvetan
> ---
> PCB prototypes for $26 at http://run.to/pcb 
> (http://www.olimex.com/pcb)
> PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
> Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
> (http://www.olimex.com/dev)

Hi,

That was very a quick & incomplete report about code
size (gcc vs SDT 2.51)

[
http://geocities.com/michaelanburaj/downloads/code_lpc.txt
]

ADS may produce better code results than SDT 2.51.

[ FYI: The results were based on the same C source
files & built with -O2 option ]

Though GCC produces small sized individual objects,
the final image (raw binary) size is much larger when
compared with SDT. This is because of the libraries.
GCC\ufffds libraries take up huge amounts of code & data
spaces.

Cheers,
-Mike.



--- lpc2100_fan <lpc2100_fan@...> wrote:

> 
> May be I missed something but the program compiled
> with GCC and the
> one with ADS seem to have nothing in common. Is it
> correct that these
> are totally different programs compiled with GCC and
> ADS?
> 
> Bob
> 
> --- In lpc2000@yahoogroups.com, "tsvetanusunov"
> <tusunov@m...> wrote:
> > 
> > > I did benchmark different architectures /
> tool-chain
> > > combo by running the same dhrystone code.
> > > 
> > > You can see the table here:
> > >
>
http://geocities.com/michaelanburaj/downloads/dhry.gif
> > > 
> > > Also code size comparison by using different
> > > tool-chains:
> > >
>
http://geocities.com/michaelanburaj/downloads/code_lpc.txt
> > 
> > pretty interesting to see that GCC make shorter
> code than ADS :)
> > All benchmarks I've seen on ARM, Keil etc web site
> show that GCC 
> > usually produces twice bigger code, while you test
> show other!
> >  
> > > You can do similarly for GPIOs too (switching
> time) by
> > > measuring it using a LA.
> > 
> > we'll certainly do this, preliminary info we
> received shows that 
> > Atmel SAM7 can drive GPIOs twice faster than LPC
> i.e. 60Mhz LPC can 
> > drive up to 5Mhz GPIO (12 clocks per port toggle)
> while SAM7 do the 
> > same for 6 clocks 
> > 
> > Best regards
> > Tsvetan
> > ---
> > PCB prototypes for $26 at http://run.to/pcb 
> > (http://www.olimex.com/pcb)
> > PCB any volume assembly
> (http://www.olimex.com/pcb/protoa.html)
> > Development boards for ARM, AVR, PIC, MAXQ2000 and
> MSP430
> > (http://www.olimex.com/dev)
> 
> 
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo

Lies, damned lies, statistics and benchmarks.  In about that order ;)

An accurate indisputable benchmark I've found generally covers too narrow 
an area to have a general use. For example pin toggling can be made a 
fairly bulletproof benchmark but really doesn't matter unless you have a 
particular need to toggle a pin quickly.  Likewise it's fairly easy to time 
a null loop but that says little about how an application will behave.  The 
benchmark is that case is accurate, indisputable and pointless (or nearly so).

A benchmark that purports to be generally useful generally is not accurate 
and indisputable.  The classic whetstone and dhrystone benchmarks have been 
the subject of endless disputes (and IIRC compiler tweaking).

Having said that they can provide some order of magnitude checking.  They 
can be useful but remember they all come with biases (some of them not 
apparent).

As a sage once said the only benchmark with any meaning is the application 
you are going to run.

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

Michael Anburaj wrote:
> Though GCC produces small sized individual objects,
> the final image (raw binary) size is much larger when
> compared with SDT. This is because of the libraries.
> GCC\ufffds libraries take up huge amounts of code & data
> spaces.

Do you mean libgcc? Or newlib?

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

> Lies, damned lies, statistics and benchmarks.  In about that 
order ;)

hehehe, this is why we would not use any code put on the web pages of 
compiler vendors for sure ;)
 
> An accurate indisputable benchmark I've found generally covers too 
narrow 
> an area to have a general use. For example pin toggling can be made 
a 
> fairly bulletproof benchmark but really doesn't matter unless you 
have a 
> particular need to toggle a pin quickly.

this is one of our application, we are developing USB-JTAG for ARMs 
and toggling GPIO ports is quite important for this application, so 
AT91SAM7Sxx with build in USB and toggling twice faster GPIO ports is 
definitely winner for this kind of application

>  Likewise it's fairly easy to time 
> a null loop but that says little about how an application will 
behave.  The 
> benchmark is that case is accurate, indisputable and pointless (or 
nearly so).
> 
> A benchmark that purports to be generally useful generally is not 
accurate 
> and indisputable.  The classic whetstone and dhrystone benchmarks 
have been 
> the subject of endless disputes (and IIRC compiler tweaking).

I understand this, but I like what Richard @ FreeRTOS did:

- test setup
- 16bit math
- 32bit math
- floating math
- bubble sort
- data block memory move
- conditional branching

(let me know what elese we are missing here)

these are the basic codes used in any application, so benchmarking 
them at different ARMs may be useful when you choose device for your 
future application 
and of course none of above can be considered as biased toward some 
compiler ot other, they will just show how good the compilers handle 
them

> As a sage once said the only benchmark with any meaning is the 
application 
> you are going to run.

completely agree, but if you see xx% improvement in your data memory 
move for instance on LPC (with 32 bit external data bus) toward OKI 
(with 16 bit external data bus) this will mean something when you 
decide which one to use in your time critical project who does 
transfer large amounts of memory blocks to the external memory right?

we'll release the codes on our web together with the benchmarking so 
everyone will be able to re-produce these tests, we are just currious 
and don't want to prove that one ARM is better than other

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430  
(http://www.olimex.com/dev)

At 03:22 PM 2/27/05 +0000, tsvetanusunov wrote:
> > An accurate indisputable benchmark I've found generally covers too narrow
> > an area to have a general use. For example pin toggling can be made a
> > fairly bulletproof benchmark but really doesn't matter unless you have a
> > particular need to toggle a pin quickly.
>
>this is one of our application, we are developing USB-JTAG for ARMs
>and toggling GPIO ports is quite important for this application, so
>AT91SAM7Sxx with build in USB and toggling twice faster GPIO ports is
>definitely winner for this kind of application

That raises a question, I haven't seen answered.  How does the pin toggling 
speed compare between an LPC running at full speed (60 MHz, no slowdown on 
the peripheral bus) and an SAM part at it's equivalent full speed?  The 
only comparisons I've seen refer to pin toggling efficiency rather than 
maximum rate.

> > A benchmark that purports to be generally useful generally is not accurate
> > and indisputable.  The classic whetstone and dhrystone benchmarks have 
> been
> > the subject of endless disputes (and IIRC compiler tweaking).
>
>I understand this, but I like what Richard @ FreeRTOS did:
>
>- test setup
>- 16bit math
>- 32bit math
>- floating math
>- bubble sort
>- data block memory move
>- conditional branching
>
>(let me know what elese we are missing here)
>
>these are the basic codes used in any application, so benchmarking
>them at different ARMs may be useful when you choose device for your
>future application
>and of course none of above can be considered as biased toward some
>compiler ot other, they will just show how good the compilers handle
>them

Biases will be there regardless.  They will be there in the underlying 
assumptions made about how the code should be structured.  In what compiler 
options should be picked etc...  If they use the same general purpose code 
for all combinations of compiler/micro than they are biased by not using 
the combination to it's best effect.  If they use combination specific 
optimizations they are biased by not comparing identical cases.

In the case of the various ARM micros, whether the micro was optimized to 
run thumb or standard code could have a significant effect on the outcome.

> > As a sage once said the only benchmark with any meaning is the application
> > you are going to run.
>
>completely agree, but if you see xx% improvement in your data memory
>move for instance on LPC (with 32 bit external data bus) toward OKI
>(with 16 bit external data bus) this will mean something when you
>decide which one to use in your time critical project who does
>transfer large amounts of memory blocks to the external memory right?

Perhaps.  It would depend on how closely the memory activity in the 
benchmark matched that in the application.  And whether it used optimized 
assembler or standard library code or a simple C routine or.....

If your application spent 50% of it's time in moving blocks of memory (or 
maybe only 1% but in a time critical portion) for instance it would make 
sense to use hand optimized assembly (and whatever hardware assists the 
micro might have).  In that case the benchmark could be rather specific to 
each micro.  A micro with a DMA peripheral might be better suited to the 
task even if a simple loop measurement on it was significantly slower than 
it's competitors.

>we'll release the codes on our web together with the benchmarking so
>everyone will be able to re-produce these tests, we are just currious
>and don't want to prove that one ARM is better than other

Before spending too much time you should at least take a look at the eembc 
benchmarks.  They've spent a lot of effort attempting to put together a 
representative set of loads for benchmarking for embedded applications.


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

> That raises a question, I haven't seen answered.  How does the pin 
toggling 
> speed compare between an LPC running at full speed (60 MHz, no 
slowdown on 
> the peripheral bus) and an SAM part at it's equivalent full speed?  
The 
> only comparisons I've seen refer to pin toggling efficiency rather 
than 
> maximum rate.
both devices run up to 60Mhz, so LPC @60Mhz toggles with 5Mhz, while 
SAM7 @60Mhz toggles with 10Mhz.

> Biases will be there regardless.  They will be there in the 
underlying 
> assumptions made about how the code should be structured.  In what 
compiler 
> options should be picked etc...  If they use the same general 
purpose code 
> for all combinations of compiler/micro than they are biased by not 
using 
> the combination to it's best effect.  If they use combination 
specific 
> optimizations they are biased by not comparing identical cases.

I see your point, but note that we don't do this for the compiler 
vendors but for ourself, so we'll structure the code as we usually do 
when we write our own code, then we'll try to achieve the best effect 
options for each compiler, i.e. something we do usually when we write 
our apps. Again this will be our own study for our own purposes, but 
we'll make the results public.

> Perhaps.  It would depend on how closely the memory activity in the 
> benchmark matched that in the application.  And whether it used 
optimized 
> assembler or standard library code or a simple C routine or.....

indeed, but it will be same code on different hardware platforms, so 
the better hardware will handle better same code (I guess) 

> Before spending too much time you should at least take a look at 
the eembc 
> benchmarks.  They've spent a lot of effort attempting to put 
together a 
> representative set of loads for benchmarking for embedded 
applications.

I'll definitely take look at eembc, the time spent will be not so 
much to consider it. As I wrote this will not pretend to be the WMPBA 
(worlds-most-preciese-benchmark-for-arms ;) but will be useful for us 
and probably many others.

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430  
(http://www.olimex.com/dev)

Hi, 

> > Before spending too much time you should at least take a look at
> the eembc 
> > benchmarks.  They've spent a lot of effort attempting to put
> together a 
> > representative set of loads for benchmarking for embedded
> applications.
> 
> I'll definitely take look at eembc, the time spent will be not so 
> much to consider it. As I wrote this will not pretend to be the WMPBA 
> (worlds-most-preciese-benchmark-for-arms ;) but will be useful for us 
> and probably many others.

The full suite EEMBC benchmarks are too big for many small micros, such
as the LPC2104, I think.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

Hi Robert,

> That raises a question, I haven't seen answered.  How does the pin toggling 
> speed compare between an LPC running at full speed (60 MHz, no slowdown on 
> the peripheral bus) and an SAM part at it's equivalent full speed?  The 
> only comparisons I've seen refer to pin toggling efficiency rather than 
> maximum rate.

I can answer that I think.
I recently was timing / finetuning an ISR, and for all purposes I was calling the handler
from a loop with a toggle on it like so :

for(;;)
    {
    event_irq_handler();
    PIOA_ODSR ^= 0x04;
    }

My timing was done at 55.296 MHz, Thumb code, and both in RAM and then from Flash
with 1 FWS -  GCC Level 2 Opt.
When first looping the XOR alone, I got a 162.77 nS period or 6.14 Mz.
Then, I also inserted a SODR just before despatching the function pointer from AIC_IVR,
and a CODR after return back into the IRQ handler. (* see below)
When marking some other points in the code with triggers through I/O, at one stage I got
patterns like this :

____---------_____-------______
    
      |   T1   | T2  |  T3  |

T1 = 100 nS
T2 = 50 nS
T3 = 60 nS

The 50 nS low time in the middle is PIOA0.3 switched low and then high.
It's not repetitive of course, but if it was that would equate to almost 20 MHz....
If it's in less looping code, I find the I/O will sustain 8-10 MHz TRUE throughput 
(The APB after all is only 2 cycles)...
Obviously the instruction sequence must have been such that stalls on the pipeline are much lower, and
I've seen several times that Thumb code from Flash executes significantly faster than ARM code.
(the prefetch I guess)

It doesn't beat the LPC2000 MAM of course, that's indisputable - Flash throughput truly seems to
approach 90-95% of RAM throughput.
But fact remains that I measure significantly higher I/O throughput, and without the excessive 
current hog of setting VPBDIV to 1 on LPC2000.

Hope this helps...

( * ) Note :
I only use IRQ vectoring through AIC_IVR, and with a func pointer.
Reason is that GCC :
1.    Still doesn't work properly with IRQ attributes for pro/epilogue.
2.    When using an ENTRY_ISR() and EXIT_ISR() macro, even pushing all R0-R12,
       and declaring function as "naked", it really goes to town :
       I had an IRQ where I used a local variable.
       In specific code setups, the compiler was writing to the local variable by using a 
       stray pointer on R12. (it failed to load R12 properly before indirection with it).

This really peaved me off, it took hours to find it. My RS232 TX ring buffer was 
occasionally being written with a weird character. (the low 8 bits of R12 from within the ISR)
Bugger it !!!
Now I only use IRQ by reading IVR and loading into func pointer...


Cheers,
Kris


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

At 05:21 PM 2/27/05 +0000, Paul Curtis wrote:
> > > Before spending too much time you should at least take a look at
> > the eembc
> > > benchmarks.  They've spent a lot of effort attempting to put
> > together a
> > > representative set of loads for benchmarking for embedded
> > applications.
> >
> > I'll definitely take look at eembc, the time spent will be not so
> > much to consider it. As I wrote this will not pretend to be the WMPBA
> > (worlds-most-preciese-benchmark-for-arms ;) but will be useful for us
> > and probably many others.
>
>The full suite EEMBC benchmarks are too big for many small micros, such
>as the LPC2104, I think.

Certainly a concern, but I just took a look at the results for an 
ST20  (under automotive and industrial) and code sizes for the various 
benchmarks ranged from 1106 bytes to 8505 bytes.  It's not clear how much 
RAM was needed but some of the benchmarks would need very little.  The 
matrix ones might need a fair amount but I would not be surprised if they 
fit as well. hmm, 4x4 matrixes in double precision, say 1/2 doz takes less 
than 1K, that covers a lot of the ground required in an embedded system.

And there are also the 8/16 bit benchmarks which are likely to be more 
considerate of memory concerns.

In any case the tests could certainly be done even if a test or two had to 
be omitted due to ram limitations.  The bigger issue would be access to the 
source code since that is only available to members.  Whether it's worth 
the effort for someone to build a more open alternative.....


>--
>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
>CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

" '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

At 04:51 PM 2/27/05 +0000, tsvetanusunov wrote:
> > That raises a question, I haven't seen answered.  How does the pin 
> toggling
> > speed compare between an LPC running at full speed (60 MHz, no slowdown on
> > the peripheral bus) and an SAM part at it's equivalent full speed?  The
> > only comparisons I've seen refer to pin toggling efficiency rather than
> > maximum rate.
>both devices run up to 60Mhz, so LPC @60Mhz toggles with 5Mhz, while
>SAM7 @60Mhz toggles with 10Mhz.

Thanks

<snip>
> > Perhaps.  It would depend on how closely the memory activity in the
> > benchmark matched that in the application.  And whether it used optimized
> > assembler or standard library code or a simple C routine or.....
>
>indeed, but it will be same code on different hardware platforms, so
>the better hardware will handle better same code (I guess)

You are more optimistic about that than I.  At least at the level of 
differences the tests are likely to bring out.  I don't really expect the 
tests to be any more meaningful than comparing clock rates, especially 
since we are talking about the same core.  The basic problems are the 
definition of better and combining low level narrow benchmarks to produce 
any sort of guide to higher level combined performance (there is no 
guarantee that they correlate).

For instance, while I would expect a single PID measurement would scale to 
the use of PIDs in an application I wouldn't assume that measuring 
multiplication and addition would allow me to estimate the performance of a 
PID.

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

Robert Adsett <subscriptions@...> schrieb am Sun, 27 Feb 
2005 00:08:22 -0500:


> As a sage once said the only benchmark with any meaning is the 
> application you are going to run.

The problem is, peoble believe in pure numbers, may it be port toggling or
task switching.

-- 
42Bastian Schick

Do any of the LPC ARM's have faster SPI ports (like maybe with a FIFO),
or are they all basically the same as LPC210X?

I thought I saw mention here that one of them had a slightly faster SPI
implementation, but I can't find any such part now.

--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> Do any of the LPC ARM's have faster SPI ports (like maybe with a FIFO),
> or are they all basically the same as LPC210X?
> 
> I thought I saw mention here that one of them had a slightly faster SPI
> implementation, but I can't find any such part now.


The SPI of the LPC213x is 4 times faster (max 30MHz).

Andreas

> The SPI of the LPC213x is 4 times faster (max 30MHz).

OK.  Thanks.  Can you really make use of this speed without a FIFO or
DMA?

SPI Related question:

I'm having trouble getting the SPI running on a LPC2119. I have the below
setup routines and running in RAM. I'm waiting to probe the clocks but
nothing is happening. My design is called out to read another uC's IO that's
bit bagging byte data out where its sync to operate as a slave device so its
IO is tied to the LPC2119 MISO. I don't have my MOSI tied to anything other
than a pull-up.

Any help would be greatly appreciated..

Regards


1. SET PORT DIRECTION FOR SPI EVEN THOUGH I THOUGHT SELECTING THE MODULE
WILL OVERRIDE IT!
IO0DIR |= (SEQ1 | SEQ3 | VOLTAGEFLT | BYPASS | OVERRIDE | TP3  | RW422 |
DETRSTn | SCK0 | MOSI0 | SSEL0);

2. SELECT MODULE
PINSEL0	0x00001505	turning SPI0 and SSEL0 on!

3. INIT FUNCTION TO ENABLE SPI AT 25Khz GIVEN 20MHz CLOCK WITH VPB = 0!
void InitSPI0()
{

  PINSEL0 |= (SCK_0 | MISO_0 | MOSI_0);

  //Set module as Master
  S0SPCR |= 0x20; //(MSTR);

  //Set Control Register
  //S0SPCR |= 0x80; //Enable hardware spi interrrupt

  //Set Clock rate
  S0SPCCR = 200;  //20Mhz/4 = 5Mhz/200 = 25Khz.

}

4. SEND BYTE OUT PORT
void SPI0ByteWrite(char byte)
{
  S0SPDR = byte;
}

Nothing happens! Any clues...

Ronnie Leighty
Principle Engineer
2802 Leslie Rd
Tampa, FL 33619
voice (813) 630-1229 ext. 111
fax     (813) 630-2619

-----Original Message-----
From: James Dabbs [mailto:jdabbs@...]
Sent: Monday, February 28, 2005 9:34 AM
To: lpc2000@yahoogroups.com
Subject: RE: [lpc2000] Re: SPI Performance



> The SPI of the LPC213x is 4 times faster (max 30MHz).

OK.  Thanks.  Can you really make use of this speed without a FIFO or
DMA?




Yahoo! Groups Links

--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> > The SPI of the LPC213x is 4 times faster (max 30MHz).
> 
> OK.  Thanks.  Can you really make use of this speed without a FIFO or
> DMA?

Hi,

the LPC213x has an FIFO for 8 frames (4..16Bits).

Andreas

--- In lpc2000@yahoogroups.com, "Ronnie Leighty" <rleighty@a...> wrote:
> SPI Related question:
> 
> I'm having trouble getting the SPI running on a LPC2119. I have the
below
> setup routines and running in RAM. I'm waiting to probe the clocks but
> nothing is happening. My design is called out to read another uC's
IO that's
> bit bagging byte data out where its sync to operate as a slave
device so its
> IO is tied to the LPC2119 MISO. I don't have my MOSI tied to
anything other
> than a pull-up.
> 
> Any help would be greatly appreciated..
> 
> Regards
> 
> 
> 1. SET PORT DIRECTION FOR SPI EVEN THOUGH I THOUGHT SELECTING THE MODULE
> WILL OVERRIDE IT!
> IO0DIR |= (SEQ1 | SEQ3 | VOLTAGEFLT | BYPASS | OVERRIDE | TP3  | RW422 |
> DETRSTn | SCK0 | MOSI0 | SSEL0);
> 
> 2. SELECT MODULE
> PINSEL0	0x00001505	turning SPI0 and SSEL0 on!
> 
> 3. INIT FUNCTION TO ENABLE SPI AT 25Khz GIVEN 20MHz CLOCK WITH VPB = 0!
> void InitSPI0()
> {
> 
>   PINSEL0 |= (SCK_0 | MISO_0 | MOSI_0);
> 
>   //Set module as Master
>   S0SPCR |= 0x20; //(MSTR);
> 
>   //Set Control Register
>   //S0SPCR |= 0x80; //Enable hardware spi interrrupt
> 
>   //Set Clock rate
>   S0SPCCR = 200;  //20Mhz/4 = 5Mhz/200 = 25Khz.
> 
> }
> 
> 4. SEND BYTE OUT PORT
> void SPI0ByteWrite(char byte)
> {
>   S0SPDR = byte;
> }
> 
> Nothing happens! Any clues...
> 
> Ronnie Leighty
> Principle Engineer
> 2802 Leslie Rd
> Tampa, FL 33619
> voice (813) 630-1229 ext. 111
> fax     (813) 630-2619
> 
> 
> -----Original Message-----
> From: James Dabbs [mailto:jdabbs@t...]
> Sent: Monday, February 28, 2005 9:34 AM
> To: lpc2000@yahoogroups.com
> Subject: RE: [lpc2000] Re: SPI Performance
> 
> 
> 
> > The SPI of the LPC213x is 4 times faster (max 30MHz).
> 
> OK.  Thanks.  Can you really make use of this speed without a FIFO or
> DMA?
> 
> 
> 
> 
> Yahoo! Groups Links

Hi Ronnie,

what have you done with the SSEL0 pin ?
It must be logical high to enable the SPI.

Andreas

I go it to work! But I had to select SSEL other words:

PINSEL0 = 0x00005505;

Boy that blows. I can't use multiple peripherals on that bus unless I
neglect leave SSEL open and use other IO!

Regards

Ronnie Leighty
Principle Engineer
2802 Leslie Rd
Tampa, FL 33619
voice (813) 630-1229 ext. 111
fax     (813) 630-2619

-----Original Message-----
From: haack0815 [mailto:lpc_arm@...]
Sent: Monday, February 28, 2005 10:16 AM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: SPI Performance




--- In lpc2000@yahoogroups.com, "Ronnie Leighty" <rleighty@a...> wrote:
> SPI Related question:
>
> I'm having trouble getting the SPI running on a LPC2119. I have the
below
> setup routines and running in RAM. I'm waiting to probe the clocks but
> nothing is happening. My design is called out to read another uC's
IO that's
> bit bagging byte data out where its sync to operate as a slave
device so its
> IO is tied to the LPC2119 MISO. I don't have my MOSI tied to
anything other
> than a pull-up.
>
> Any help would be greatly appreciated..
>
> Regards
>
>
> 1. SET PORT DIRECTION FOR SPI EVEN THOUGH I THOUGHT SELECTING THE MODULE
> WILL OVERRIDE IT!
> IO0DIR |= (SEQ1 | SEQ3 | VOLTAGEFLT | BYPASS | OVERRIDE | TP3  | RW422 |
> DETRSTn | SCK0 | MOSI0 | SSEL0);
>
> 2. SELECT MODULE
> PINSEL0	0x00001505	turning SPI0 and SSEL0 on!
>
> 3. INIT FUNCTION TO ENABLE SPI AT 25Khz GIVEN 20MHz CLOCK WITH VPB = 0!
> void InitSPI0()
> {
>
>   PINSEL0 |= (SCK_0 | MISO_0 | MOSI_0);
>
>   //Set module as Master
>   S0SPCR |= 0x20; //(MSTR);
>
>   //Set Control Register
>   //S0SPCR |= 0x80; //Enable hardware spi interrrupt
>
>   //Set Clock rate
>   S0SPCCR = 200;  //20Mhz/4 = 5Mhz/200 = 25Khz.
>
> }
>
> 4. SEND BYTE OUT PORT
> void SPI0ByteWrite(char byte)
> {
>   S0SPDR = byte;
> }
>
> Nothing happens! Any clues...
>
> Ronnie Leighty
> Principle Engineer
> 2802 Leslie Rd
> Tampa, FL 33619
> voice (813) 630-1229 ext. 111
> fax     (813) 630-2619
>
>
> -----Original Message-----
> From: James Dabbs [mailto:jdabbs@t...]
> Sent: Monday, February 28, 2005 9:34 AM
> To: lpc2000@yahoogroups.com
> Subject: RE: [lpc2000] Re: SPI Performance
>
>
>
> > The SPI of the LPC213x is 4 times faster (max 30MHz).
>
> OK.  Thanks.  Can you really make use of this speed without a FIFO or
> DMA?
>
>
>
>
> Yahoo! Groups Links

Hi Ronnie,

what have you done with the SSEL0 pin ?
It must be logical high to enable the SPI.

Andreas






Yahoo! Groups Links

> Hi,
> 
> the LPC213x has an FIFO for 8 frames (4..16Bits).
> 
> Andreas

Thanks!  Looking now I see I missed your main point -- while the "SPI"
on this part is a garden variety LPC SPI module, the "SSP" is a separate
SPI-compatible module with its own FIFO.

Next question: is there a user's guide/pricing/delivery schedule for
this series?

--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> > Hi,
> > 
> > the LPC213x has an FIFO for 8 frames (4..16Bits).
> > 
> > Andreas
> 
> Thanks!  Looking now I see I missed your main point -- while the "SPI"
> on this part is a garden variety LPC SPI module, the "SSP" is a separate
> SPI-compatible module with its own FIFO.
> 
> Next question: is there a user's guide/pricing/delivery schedule for
> this series?

Hi,

for the usermanual take a look into the filesection of the forum and
you can now order the 2138 from your distributor.
Ask your distributor for the price. 

Andreas

--- Alex Holden <alex@...> wrote:

> 
> Michael Anburaj wrote:
> > Though GCC produces small sized individual
> objects,
> > the final image (raw binary) size is much larger
> when
> > compared with SDT. This is because of the
> libraries.
> > GCC\ufffds libraries take up huge amounts of code &
> data
> > spaces.
> 
> Do you mean libgcc? Or newlib?

Not, sure.. I am using pre-built GNU-ARM binaries.

> 
> -- 
> ------------ Alex Holden -
> http://www.alexholden.net/ ------------
> If it doesn't work, you're not hitting it with a big
> enough hammer
> 
> 
>  
> Yahoo! Groups Links
> 
> 
>     lpc2000-unsubscribe@yahoogroups.com
> 
>  
> 
> 
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250