There is an eCAP module in the processor that *perhaps* could be controlled
via a PRU . . . but I have limited knowledge of that peripheral module, and
no hands on . . .

On Sat, Sep 10, 2016 at 6:25 PM, Dennis Lee Bieber <[email protected]>
wrote:

> On Sat, 10 Sep 2016 15:04:23 -0700 (PDT), beezerlm
> <[email protected]> declaimed the following:
>
> >
> >     I have a fairly simple motion control project I was planning on using
> >an Arduino for, but my understanding is that the arduino's 16Mhz clock
> >won't keep up with my encoder pulses.  I will need to process a max of
> >10,000 pulses per second.  The project is to control 1 reciprocating
> >pneumatic cylinder and to simply monitor the position and change direction
> >at a programmable in/out position.  Is this within the capabilities of the
> >BBB?
>
>         Rather fast for a motion encoder... I think my Kenwood transceivers
> only produce 1000 pulses per rotation (well, maybe twice that to account
> for direction), and spinning that dial faster than 1 rotation per second is
> difficult.
>
>         Using the /sys filesystem access is highly unlikely to keep up.
> Memory
> mapping the GPIO block might, or writing code for the PRUs (200MHz -- an
> input loop using 100 instructions is still around 2MHz vs 10kHz)
>
>
>         OTOH: you may be looking at the matter from the wrong side.
>
>         If you need to catch just a position to command some valves...
> Perhaps
> all you need is a simple hardware counter using the pulse stream as an
> input. Full counter range scaled to the full encoder range, trigger set for
> the specific count at the position to activate. Hardware counter is
> probably much faster than a software loop. Getting to the counter from
> plain Arduino may take some experimenting (I've not looked for a preset
> library function)
> https://sites.google.com/site/qeewiki/books/avr-guide/counter-atmega328 ->
> CTC mode on counter 1 (16-bit) might be the type of operation you need.
>
>         The BBB may have something similar, but a quick Google didn't
> blind me
> with anything obvious. Granted, to date the most ambitious thing I've done
> is to prove that a DHT-11 humidity/temp sensor can not be read from Python
> using the /sys filesystem access, nor from a C program using that mode
> either. [Oh... And running the old HINT benchmark -- which, contrary to the
> authors' expectations, didn't really scale well over 20 years: had to cut
> the RUNTM parameter from 1.0 seconds to 0.001 seconds, and still got a
> warning that the 16-bit integer benchmark was too fast for precision]
>
> --
>         Wulfraed                 Dennis Lee Bieber         AF6VN
>     [email protected]    HTTP://wlfraed.home.netcom.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/1la9tbpq2l2aui29c235hsndm6ik8eleun%404ax.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORob_C-bmhDKQ3LzJVH%2B6J5TginQ%3Ds2zAhZQ%3DOkf2ogk3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to