i am newbie asking ,is this the board for me

i am newbie , been looking for a board and there are lots out there , i am running a raspberry pi 2 , to slow , any way . i would like a nice fast little computer to run my cnc , which board it right foe me

If you google you can find multiple CNC projects based on BBB, such as this list
http://blog.machinekit.io/p/hardware-capes.html#BeagleCNC
Google is your friend (in this case).

BBB also has the PRUs which can be very useful in realtime motion control.

Bruce

On Sun, 22 Nov 2015 02:09:09 -0800 (PST), Marc Wells
<marcwells50@gmail.com> declaimed the
following:

i am newbie , been looking for a board and there are lots out there , i
am running a raspberry pi 2 , to slow , any way . i would like a nice
fast little computer to run my cnc , which board it right foe me

  I suspect I'm not the one who should be answering (I don't think I've
managed to get my BBB to flash an LED using Python yet...
Javascript/Bonescript demo, yes... Python, no).

  However, in order to answer the question, one needs to understand what
aspects your are finding "to(o) slow". Number crunching algorithms or I/O?
If I recall, the R-Pi, as with the BBB, handles GPIO via special entries in
the Linux file system. That is going to be slow on any board since one
basically has to open/write/close the special device files to make any
change in state on the GPIO.

  If it is the number crunching side, rather than the I/O control side,
the R-Pi 2B is a quad-core Cortex A7 at 900MHz with 1GB RAM (
Buy a Raspberry Pi 2 Model B – Raspberry Pi ). The BBB is
a single-core Cortex A8 at 1GHz with half the RAM (
Beagleboard:BeagleBoneBlack - eLinux.org ). The R-Pi 2B, if the
multiple cores are used, should be faster for number crunching.

  If my understanding of GPIO via the Linux file system is proper, there
likely isn't much of a difference between 900MHz and 1GHz -- especially not
if the cores on the R-Pi2B are in play so one is number crunching while the
other is running an I/O thread; the BBB would have to alternate the
functions.

  OTOH, the BBB does have a pair of specialized PRUs designed to have
faster, direct access to the GPIO. But they aren't programmed using the
common OS tools -- and they will end up running in parallel.

  You may really be looking at a coprocessor system -- Linux computer
with add-on microcontroller... Say an Arduino Due programmed to handle the
actual CNC machine, with its (relatively) high-speed GPIO capability, while
using the R-Pi2B as the number cruncher, and sending path commands (simple
"MOVE TO x, y, z" to the Due; the Due then implements the step commands to
actually reach that position. The Due (a Cortex M3 as I recall) may even
have enough power to handle simple spline computations -- "SPLINE FROM
x1,y1,z1 THROUGH x2,y2,z2 END x3,y3,z3").

  The TIVA TM4C boards use variations of ARM Cortex M4F processors with
lots of add-on peripherals (interrupts, the 123 board has enough timers
that one could dedicate a timer to each track of a soap-box derby coarse
and still have left-overs [6 32-bit that can be split into 12 16-bit, AND 6
64-bit splitable into 12 32-bit]; the 1294 "connected" has Ethernet and
lots of memory for a controller, you likely don't need the 129E "crypto
connected" with hardware encryption modules). The TIVA controllers can be
programmed using TI-RTOS -- real time OS. (You will need CCS6 to program
RTOS, but if you want simple, there is Energia -- a TIVA specific fork of
the Arduino IDE)

  Emphasis: TIVAs are controllers [TI considers them evaluation kits for
the chips themselves, not as a hobbyist product like an Arduino, they'd
like you to buy hundreds of the chips for embedding in your own products].

  And yes, I'm rambling... Too many boards, not enough time {BBB, TIVA
TM4C123, TM4C1294, TM4C129E, Arduino Due, Uno, Mega2560, BASIC Stamps 2,
2p, 2px, Propeller -- the BS2 is really overpriced by modern standards, and
a handful of PIC chips}

Denis,

while GPIO was found being slow, there was some attempts to use the DeviceTree. Since the Linux kernel 3.8, it is part of the system. Here are some links:

https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview
http://chiragnagpal.com/examples.html

Especially the second one, gets the performance from 3.5kHz up to 2.8MHz. What is more - it seems to be possible to do some changes during the runtime (Device Tree overlays)

Well, I am no HW expert, just a former scripting guy, so sorry if I am confused :slight_smile:

Cheers,
Petr

Dne neděle 22. listopadu 2015 20:06:31 UTC+1 Dennis Lee Bieber napsal(a):

Yes, machinekit is a very sophisticated G-code itnerpreter and motion control program. It uses the built-in PRU microcontroller to generate step pulses at high rates and with accurate timing. There is a “CRAMPS” board that holds up to 6 Pololu-style stepper driver modules. It is mostly aimed at 3D printers, but can be used for any small machine that uses stepper motors. The CRAMPS board plugs onto the BBB like a larger cape. The PRU has direct connection to a limited set of I/O pins.

It is also possible to directly address the GPIO pins from the Arm processor, although there is some delay in the interconnect system of the chip. This still allows you to control them directly from a C or other program with under 200 ns delay. It does require your program to run with SU privileges. It also requires you to set up the pin mapping, which is not documented as well as it ought to be.

Jon

It is also possible to directly address the GPIO pins from the Arm processor, although there is some delay in the interconnect system of the chip

This is true of the PRU as well, for many of the GPIO pins. However, the largest issue the ARM processor has to contend with, is the operating system. So, a userland application that directly accesses GPIO registers in order to achieve what needs being done. Can often be performant / deterministic enough. A Linux userland application can never be deterministic 100% of the time - However. A PRU application on the other hand, can be.