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

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.

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

Isn't this going to be limited to the GPIO switching speed?

IMHO
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!

hmmmm.
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.

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.

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).

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).

I don't study a Cortex-A8 core, and don't know how many ARM7 cycles is
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 .

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).

I don't study a Cortex-A8 core, and don't know how many ARM7 cycles is
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 .

Cortex has a few unfair advantages over the LPC2148: raw clock speed, and VFP.

Cortex has a few unfair advantages over the LPC2148: raw clock speed, and VFP.

"VFP technology is a coprocessor extension to the ARM architecture. It
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