jfsimon1981_c has quit [Read error: Connection reset by peer]
<set_>
Is there a simultaneous function? Ha.
Shadyman has joined #beagle
<set_>
It will be 10:00 soon. I will calm down. Sheesh.
<set_>
I guess the issue now is hiding the assignment of functions in other functions.
<set_>
Argh!
brook has quit [Remote host closed the connection]
<set_>
So, maybe the motors all do not want to move in formation simultaneously. Does anyone think this could be the truth about the PCA9685 on the ServoCape and the attachment to the BBB?
vagrantc has joined #beagle
<zmatt>
very unlikely
<zmatt>
it's probably just you
<set_>
I just found a .swp file.
<set_>
I thought nano was smarter. I got dumber!
<zmatt>
?
<zmatt>
anyway, afk again
<set_>
It was my file.py but called file.py.swp and...
<set_>
Dang it
brook has joined #beagle
brook has quit [Ping timeout: 246 seconds]
brook has joined #beagle
brook has quit [Ping timeout: 252 seconds]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
<zmatt>
a .swp file is normally a temporary file created by a text editor while you're editing a file
vagrantc has quit [Quit: leaving]
<zmatt>
when you close the editor the .swp file will be removed, but if you e.g. have a crash or you power cycle the board while a text editor was still over, the .swp file is left behind
<zmatt>
this allows unsaved changes to be recovered in case of a crash, but if you don't care you can safely remove the .swp file
<set_>
Right.
<set_>
My board is crashing due to my poor coding experiences.
<set_>
It works but I am altering the source to handle multiple servo movements consecutively on many servos.
<set_>
So, since my coding is backwards, I am getting stuck!
<set_>
I put the handling of assignment in the public domain and left private domains to call what was in the public domain but incorrectly so far.
<set_>
I am very excited that my BBB still works after so many premature shutdowns.
<set_>
cold servos and a premature crash that is unwarranted is not fun!
<set_>
...Off to read more...
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
jfsimon1981_c has joined #beagle
jfsimon1981_b has quit [Read error: Connection reset by peer]
brook_ has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
jfsimon1981_b has joined #beagle
jfsimon1981_c has quit [Read error: Connection reset by peer]
aussetg has quit [Remote host closed the connection]
aussetg has joined #beagle
ikarso has joined #beagle
jfsimon1981_c has joined #beagle
jfsimon1981_b has quit [Read error: Connection reset by peer]
vigneshr has quit [Quit: Connection closed for inactivity]
otisolsen70 has joined #beagle
aussetg has quit [Ping timeout: 252 seconds]
otisolsen70 has quit [Remote host closed the connection]
aussetg has joined #beagle
otisolsen70 has joined #beagle
jfsimon1981_b has joined #beagle
jfsimon1981_c has quit [Read error: Connection reset by peer]
aussetg has quit [Ping timeout: 252 seconds]
aussetg has joined #beagle
florian has joined #beagle
Shadyman has quit [Remote host closed the connection]
jfsimon1981_c has joined #beagle
jfsimon1981_b has quit [Ping timeout: 252 seconds]
ikarso has quit [Ping timeout: 255 seconds]
ikarso has joined #beagle
uart0_person has joined #beagle
<uart0_person>
Hello
<uart0_person>
So I am trying to do a time sensitive operation in python. How can I use the pru to set a timer interrupt?
<zmatt>
uart0_person: that sentence doesn't really make sense
<zmatt>
if you want a timer in python, neither a timer interrupt nor pru is of any relevance
<zmatt>
conversely, if you need the sort of timing accuracy that requires pru, then use pru rather than python
ikarso has quit [Quit: Connection closed for inactivity]
<uart0_person>
Ok, let me reformulate
<uart0_person>
I want the timing that pru provides for a python script
<zmatt>
yeah sorry that sentence still doesn't make sense
<uart0_person>
why not?
brook has joined #beagle
<zmatt>
the limiting factors for timing precision in python code is the general slowness of python and the timing unpredictability of any process that runs in linux userspace
<zmatt>
there's nothing pru can do to change either of those things
<uart0_person>
so it's better if I code the pru with C
<zmatt>
what sort of timing accuracy are you looking for anyway?
<uart0_person>
it's for a pid
<uart0_person>
I want the samples to always have the same interval between the
<uart0_person>
them*
<zmatt>
samples of what?
<zmatt>
and you haven't actually answered the question
<zmatt>
there are many solutions for any given problem, pru may be appropriate for some purposes or overkill for others
<zmatt>
like, if you program PRU in assembly you may be able to execute code with 5ns or 10ns timing precision... but that may be complete overkill in many cases
<uart0_person>
I want to make a pid that gets called at regular intervals and I want to make sure these intervals are precise. I discovered I could have that using a timer interrupt
<uart0_person>
I don't know how precise they need to be
<uart0_person>
but I want it to be more precise that just using a python script and using the time library
<zmatt>
if you don't know how precise they need to be, then how do you know python isn't meeting your needs?
<zmatt>
if you want something better, step 1 would be using e.g. C instead of python
<zmatt>
also, 14:25 <@zmatt> samples of what?
<zmatt>
if you're talking about sampling the ADC then the right solution is to configure the ADC to use whatever sample rate you desire and stream the sample data using iio
<zmatt>
then the samples are taken at an exact interval (with the only variability being due to clock jitter, which is negligible) and your program can be synchronized to the rate at which adc data becomes available
<uart0_person>
it would be samples of a flow meter arriving via uart
<zmatt>
lol, and what baudrate are you running at?
<zmatt>
and do you need to poll the flow meter or does it sample periodically for you? since in the latter case you obviously don't need any sort of timer
<uart0_person>
wait sorry, not uart
<uart0_person>
it will i2c
<uart0_person>
it will be i2c
<uart0_person>
it has a fast response of 5ms
<zmatt>
5ms is not fast, 5ms is slow as hell
<uart0_person>
sorry, < 5 m
<uart0_person>
%ms
<uart0_person>
5ms
<uart0_person>
yeah, I forgot it doesn't matter if you have a quantum computer if the one transmitting the samples isn't as fast
<zmatt>
nothing you do via i2c is particularly fast, a single data transfer takes hundreds of microseconds
<uart0_person>
I was only thinking the program needs to be fast, but forgot about the hardware
<uart0_person>
is python good enough for 5ms?
<zmatt>
in the end it'll depend on the actual code you write
<zmatt>
python is in general not great for performance
brook has quit [Remote host closed the connection]
<uart0_person>
ok
<uart0_person>
I am not great at estimating these timing parameters
<uart0_person>
I will first try in python and then see how fast it goes
<zmatt>
so build a test and measure
<zmatt>
in the end, how you write your code will matter more than your choice of language
<uart0_person>
I have this bad habit like, imagine you have a situation which you have two options but if you choose wrong, it won't cause damages, you could just go and test it and you know which is right and which is wrong
<uart0_person>
I have the habit that I think I need to research everything about it before making a decision
<uart0_person>
instead of just making a code and testing , I keep fixated on finding how to use a pru timer
<zmatt>
pru has nothing to offer for you
<zmatt>
in this context
<zmatt>
pru isn't even useful/needed if you wanted to use a hardware timer in python, but additionally, using a hardware timer in python wouldn't actually get you better timing than using a normal timer
<zmatt>
hmm, does python's asyncio not have a decent periodic timer API built-in? that seems dumb
<uart0_person>
?
brook has joined #beagle
uart0_person has quit [Ping timeout: 244 seconds]
buzzmarshall has joined #beagle
mag has quit [Ping timeout: 246 seconds]
mag has joined #beagle
buzzmarshall has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
florian has quit [Quit: Ex-Chat]
vagrantc has joined #beagle
mag has quit [Remote host closed the connection]
mag has joined #beagle
Guest35 has joined #beagle
<Guest35>
hello
Guest35 has quit [Quit: Client closed]
Guest50 has joined #beagle
Guest50 has quit [Client Quit]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 240 seconds]
lucascastro has joined #beagle
otisolsen70 has quit [Quit: Leaving]
nslu2-log has quit [Quit: Disconnecting from stoned server.]
nslu2-log has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
lucascastro has joined #beagle
lucascastro has quit [Quit: Leaving]
zjason` is now known as zjason
brook_ has quit [Remote host closed the connection]