Speed of BeageBoard
se...@post.sk
I'm intersting of this board.It's look very good but practical speed
for user is???
I'm interesting of GPIO (many user too) and controll some other
application.
Can some other make test of speed ????
like this :
set GPIO to log.1
make some calculation (sqrt(real number))
clear GPIO to log.0
and count time (on osciloscop or counter) or count how many time make
this in 1second.
It's very important for me if vant start work with this board.
I now create application and use ARM7 (LPC2148) at 72MHz and it's
slow. But application is RTOS.
Is Beagle Board faster (with linux) or slow. I know this board can
play video ,but?????
pls write any sugestion.
I want create or port some CNC application for this board and Amstrong
distribution.
regards
Koen Kooi
> hi all.
> I'm intersting of this board.It's look very good but practical speed
> for user is???
> I'm interesting of GPIO (many user too) and controll some other
> application.
> Can some other make test of speed ????
> like this :
> set GPIO to log.1
> make some calculation (sqrt(real number))
> clear GPIO to log.0
regards,
Koen
Edward Robbins
This test is sometimes used to rate the speed of RTOSs, but of course is
dependent on GPIO switching time, which doesn't matter if you are comparing
multiple RTOSs on the same hardware, but is important if you want to rate
the speed of the hardware itself. Also consider that if this is the most
important task that would like to perform (GPIO switching) and thus you
would like to rate speed purely for this task, then it would be best to see
if you can run RTLinux on the beagle and run the code in kernel space, this
will be much faster than using standard Linux!
Ed
se...@post.sk
I don't want write own RTOS for this board (I have exist on my
LPC2148).
My question is, if we can make some good success when use Angstong or
Debian distribution and run own code on it.
exist project EMC2 (CNC for Linux) and I'm interesting to port this
project to Beagleboard. Expansion connector suport this idea (many
input or outputs).
On first time we need rate the speed if run code in kernel.
Speed of switching GPIO is fast (few ns) but interesting me a time to
calculate sqrt a real number.
If try it on LPC2148 72MHz then calculate 40us (very very very long
time) . it's slow to genreate acceleration or deceleration speed for
axes.
yes can use some approximation or table (I use approximation). But
Beagle board is 600MHz run.
regards
Leon Woestenberg
On Wed, Sep 24, 2008 at 6:58 PM, <se...@post.sk> wrote:
> If try it on LPC2148 72MHz then calculate 40us (very very very long
> time) . it's slow to genreate acceleration or deceleration speed for
> axes.
>
Using Linux you have to try harder to get real-time, and <40 us is
probably only possible if you
directly do the calculation in the interrupt vector handler.
I haven't done linux-rt benchmarks on any ARMv7 BTW, I am quite
curious to learn what the Beagle
does.
As a reference I have ~400 us threaded interrupt handler latencies for
ARMv5TE XScale IXP420@533 MHz and ~150 for PowerPC
running Linux 2.6.24 / 25 with -rt patches.
I doubt that any real-time Linux patch will achieve <40 us on embedded
processors, but it might get close.
For axes control, I would strongly recommend to use the ARM Cortex
*M3* processor without Linux, instead
maybe take a RTOS. I get <2 us interrupt latencies there, and ~3.5 us
thread scheduling latencies with RTOSses.
I love my Linux, but like a hammer isn't always the appropriate tool,
Linux likewise is not in this case.
Regards,
--
Leon
Leon Woestenberg
On Wed, Sep 24, 2008 at 6:58 PM, <se...@post.sk> wrote:
> yes can use some approximation or table (I use approximation). But
> Beagle board is 600MHz run.
>
Off-topic for the list, but I hate to respond off-list.
Strongly consider the trade-off:
Either:
1) too late with the exact actuator value
2) on-time with a small actuator error
often (2) is what you want for motor control!
So, I do recommend using a (fine-grained) approximation look-up table.
Regards,
--
Leon
Måns Rullgård
> Speed of switching GPIO is fast (few ns) but interesting me a time to
> calculate sqrt a real number.
> If try it on LPC2148 72MHz then calculate 40us (very very very long
> time) . it's slow to genreate acceleration or deceleration speed for
> axes.
> yes can use some approximation or table (I use approximation). But
> Beagle board is 600MHz run.
The Cortex-A8 can calculate the square root of a single-precision
floating-point number in 9 cycles. At 600 MHz, this is 15 ns. If you
need double precision or full IEEE compliance (exceptions, fancy
rounding, etc.), it can take up to 60 cycles (100 ns at 600 MHz).
--
Måns Rullgård
ma...@mansr.com
se...@post.sk
> The Cortex-A8 can calculate the square root of a single-precision
> floating-point number in 9 cycles. At 600 MHz, this is 15 ns. If you
> need double precision or full IEEE compliance (exceptions, fancy
> rounding, etc.), it can take up to 60 cycles (100 ns at 600 MHz).
used to
calculate the square root of double precision.
tomorrow I make test with my board (LPC2148) again and write result to
this forum .
but if Cortex core is more faster like ARM7 then a 100ns at 600MHz is
good value.
try it someone .
regards
Bill Gatliff
Cortex has a few unfair advantages over the LPC2148: raw clock speed, and VFP. :)
b.g.
--
Bill Gatliff
bg...@billgatliff.com
se...@post.sk
provides low-cost single-precision and double-precision floating-point
computation fully compliant with the ANSI/IEEE Std 754-1985 Standard
for Binary Floating-Point Arithmetic. VFP provides floating-point
computation suitable for a wide spectrum.... " Wiki write.
it's not fairly :-(
Cortex is faster.
I will be cry .
make test with GPIO and sqrt ..... .
I must buy one board from digikey.. .
regards