I agree with TJF, It's best not to use interpreted languages( scripting languages ) if you want reasonably deterministic behavior. In fact, this might be a job better suited for a PRU. Not because this task would require a lot of speed, but because when I think of motor stability, I think of deterministic code.
The only way your code will be guaranteed to be deterministic. Would be to run it on a PRU. If you do however feel that a PRU is unnecessary. A compiled language such as C should be used. Hell, use golang if it makes you feel good. So long as the language is not interpreted. On Mon, Aug 1, 2016 at 5:19 PM, Dennis Lee Bieber <[email protected]> wrote: > On Sun, 31 Jul 2016 10:32:18 -0700 (PDT), > [email protected] declaimed the > following: > > >my goal is to read serial data from an IMU that sends packets of data in a > >high speed and make stabilization program for 2 motors. > >it doesn't need it to be super fast, it needs to update at around 20-30 > >times a second tops. > > > You haven't specified the size of said packets, but at 20Hz, > you've got > a full 50mSec between updates. For comparison, that is over two normal > time-slices for Windows 7 processes. The Linux scheduler seems to adjust > time-slices based on load and "nice" value: > > http://unix.stackexchange.com/questions/156708/does-the-timeslice-depend-on-process-priority-or-not-under-completely-fair-sched > > Either way, if the process is blocking on I/O requests, there's > probably enough CPU available to handle it. At high speed serial > (115200bps, 8N1), you are looking at 5760 bits in a 50mSec window, or 576 > bytes [start, 8bits, stop => 10 bits/byte]. I suspect your data is probably > closer to 50 bytes, so call it 5mSec to read... That gives you [using Win7 > value] another 15mSec to process the data and generate output before > getting swapped out by the scheduler. Of course, if you are the only > process really doing anything, the odds are that the scheduler will just > bring you back into running state <G> > > Since the low-level I/O, even from Python, is rather optimized (C > runtime library), I doubt it will be a concern. > > >>> def looper(): > ... strt = time.time() > ... endt = strt + 0.050 > ... l = 0 > ... while time.time() < endt: > ... l += 1 > ... print "Loops completed: %s" % l > ... > >>> looper() > Loops completed: 413376 > >>> > > That's on a 3.4GHz Win7 box. > > Hmmm... the BBB seems a bit slower than I'd expected -- or > time.time() > is returning greatly different units between Windows and the BBB > > login as: debian > Debian GNU/Linux 7 > > BeagleBoard.org Debian Image 2015-11-12 > > Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian > > default username:password is [debian:temppwd] > > debian@beaglebone:~$ vim looper.py > debian@beaglebone:~$ python looper.py > Loops completed: 4131 > > Only 1% of the speed on the Win7 box?! > > Seems consistent though... Adding some arithmetic... > > >>> def looper(): > ... strt = time.time() > ... endt = strt + 0.050 > ... l = 0 > ... while time.time() < endt: > ... l += 1 > ... _ = l * l > ... print "Loops completed: %s" % l > ... > >>> looper() > Loops completed: 219002 > > > > vs > > debian@beaglebone:~$ vim looper.py > debian@beaglebone:~$ python looper.py > Loops completed: 2406 > > I'd been thinking maybe 25% (1GHz 32-bit vs 3.4GHz 64-bit)... > Floating > point may be killing it, since I don't think the BBB has double precision > hardware (could be wrong). > > > > -- > 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/hfnvpbdd97g1jcvicb072dd62qe6hb0vgc%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/CALHSORpBL70Db8yeXc2nYo%2BLny8tGD6P_6pAqB%3DRTWfkPnPzTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
