<mattb0ne>
what is the simplest timer you can use on the pru
<mattb0ne>
i know there are times
<mattb0ne>
timers but I was hoping for a pure C example
<mattb0ne>
by timer I mean HW timers on the board
<mattb0ne>
zmatt: can you make a simple timer PRU example. I want to add a delay in my C code but I am not sure how to do that. I tried looking in the stdlib but it seems embedded linux does not have a sleep or delay function
<set_>
Does that work w/ the clpru? I do not know.
<set_>
I have larger issues right now but I may be able to help in a bit, i.e. search TI's docs. on clpru on usleep!
<set_>
We have a pallet shortage in this "awesome" state. yea. Now, I need to run around town instead of doing cool things. Blah.
xet7 has joined #beagle
<set_>
13.2.12 in the guide should give some insight.
<set_>
interesting...so. Even w/ $usleep(int) or $usleep(whatever), it does not function in assembly. So, usleep is out. Hmm.
mattb0ne has quit [Ping timeout: 260 seconds]
vd has quit [Quit: Client closed]
vd has joined #beagle
<set_>
Hey! You need to have a non-function-like macro to handle time!
<set_>
maybe something called __delay_cycles(int); <<< Try that w/ your pru_cfg include directive.
mattb0ne has joined #beagle
vd has quit [Ping timeout: 256 seconds]
mattb0ne has quit [Ping timeout: 264 seconds]
mattb0ne has joined #beagle
<mattb0ne>
back
<mattb0ne>
so timers
<mattb0ne>
set_ you do anything like that
<set_>
it is past 10:00 but sure, I will chat. If I get kicked, I will be gone for a bit and then stay quiet.
<set_>
No. I do not mess w/ timers, i.e. not even in regular ARM ideas.
<set_>
I thought you were trying to make a macro for sleeping...
<set_>
I was researching some ideas while you were gone.
<set_>
p. 4436 in the TRM shows ideas. What do you want to know? I mean, are you using clpru w/ macros or .asm files w/ a .c file and clpru?
<set_>
So, say we start a .c file, i.e. main.c and we plan on using it. I find many online. But...we need to make sure the .asm file has the .cdecls annotation showing our main.c file as "main.c"
<set_>
I do not know how much you are willing to chat here but Molloy has many files available still...
<set_>
So, make a .asm file w/ your required arguments. I know there are other files needed. It is not just some .c and .asm files we are using here.
<set_>
I think there are our included directives, macro defininitions, and whatever else I read earlier. It is 287 pages long and that is just the clpru guide. So, this may just be the longest conversation in chat history.
<set_>
One thing...I thought w/out macros, one could not use printf in .c files and have them articulated/compiled into .asm files. But...Molloy says yes but it was on an older kernel and an older clpru v (I am sure of it). Anyway, if you reply. Okay. I will keep chatting w/ you.
<set_>
...
<mattb0ne>
researching
<mattb0ne>
will probably pass out
<mattb0ne>
will be on tomorrow
<mattb0ne>
tahnks for the suggestions
<set_>
Yeppers!
vd has joined #beagle
<set_>
Outside of "Yeppers!," why do you halt conversation so easily when you want more info?
<set_>
I know you just want PRU answers and not theory. W/ theory, comes understanding that can be put to use. It is not simple to just say, "I like dogs," and know every facet of everything dog related but blah. I am a ___________. So, good tiding.
buzzmarshall has quit [Quit: Konversation terminated!]
ikarso has joined #beagle
vd has quit [Quit: Client closed]
rob_w has joined #beagle
otisolsen70 has joined #beagle
CrazyEddy has quit [Ping timeout: 264 seconds]
starblue has joined #beagle
CrazyEddy has joined #beagle
dinuxbg has quit [Ping timeout: 245 seconds]
florian has joined #beagle
pbrobinson is now known as pbrobinson_AFK
lucas_ has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
<zmatt>
mattb0ne: there are lots of ways to create delays or timers with different properties. what's your use-case though? the original outline of your PRU program was that it was fully synchronized to the load cell, which was set up to automatically perform measurements at a fixed (and iirc pretty high) rate, and PRU program was an infinite loop that synchronously receives each measurement and then ...
<zmatt>
...immediately after that does everything else (sample encoder position, update outputs, send message to python)
<zmatt>
mattb0ne: if you insert a delay into that it will break things, the load cell will continue to send data and will overflow the uart
<mattb0ne>
good point
<zmatt>
if you need to do something "later" the solution is to use a timer, which can be easily implemented in software since you already have a function that produces a timestamp
<mattb0ne>
i am trying to work around the behavior where the load cell needs a bit more time to settle and give the right reading at each position
<mattb0ne>
so I wanted to sneak a delay by stopping the motor for a second
<mattb0ne>
so the delay would be spacing out writes to the A and B channels
<zmatt>
this seems odd.. if the load cell can't cope with varying loads, why does it have the option to sample thousands of times per second? there'd be no point in doing that if it requires the load to be stable
<zmatt>
ok just over a thousand samples per second (specifically 1200 sps) but still :P
<zmatt>
I see it has configurable filters... maybe an excessively aggressive filter has been configured?
<zmatt>
see section 5.4 of the manual
<zmatt>
default filter is IIR filter 3
otisolsen70_ has joined #beagle
otisolsen70__ has joined #beagle
otisolsen70 has quit [Ping timeout: 256 seconds]
otisolsen70_ has quit [Ping timeout: 256 seconds]
<mattb0ne>
i do not understand it myself
<mattb0ne>
so the application measures the force when two magnets get close
<mattb0ne>
so obviously when the distance between the magnets is at the minimum the force should be the strongest
<mattb0ne>
the angle always seems to fall just after that point
<mattb0ne>
the motor wont rotate at really slow speeds
<mattb0ne>
but when I control by hand the max force is where it is supposed to be
<zmatt>
I have no idea what you're trying to describe
<zmatt>
(the step response is the output of the filter if the actual load instantaneously changes)
Shadyman has quit [Remote host closed the connection]
<mattb0ne>
let me look
<mattb0ne>
i was trying to say that the load cell is calling the peak late
<mattb0ne>
that or the decoder is too fast for the load cell
<zmatt>
or, like I said, the load cell's filter is messing you up
<mattb0ne>
that is probably it
<zmatt>
maybe try IIR filter 1, or FIR filter 0, or even no filter
<mattb0ne>
because I was messing with it
<mattb0ne>
lol
<mattb0ne>
did you make the spread sheet zmatt
<mattb0ne>
so does this mean that the higher that FIR filter number is the slower it is to change value
<zmatt>
yeah just to get an impression of what the filter step response looks like
<zmatt>
these are the IIR filters
<mattb0ne>
so if the load is actually changing it will be delayed?
<zmatt>
(there's not enough info about the FIR filters to be able to plot anything for them)
<mattb0ne>
ok I need to read
<mattb0ne>
I think I moved the setting FIR 6
<zmatt>
the FIR filters probably cause more delay than the IIR filters
<zmatt>
well, depending on setting I guess
<zmatt>
actually I don't know, there's really not enough info about the FIR filters
<zmatt>
the IIR filters are adequately specified however
<mattb0ne>
i will turn off filtering and see how that changes things
<mattb0ne>
thanks for the suggestion
<zmatt>
it looks like higher filter settings also cause lower output rate, at least for the FIR filters
<mattb0ne>
like you said at my baudrate I am getting data quite fast so it should keep up with the decoder stream
<zmatt>
the decoder isn't a stream
<mattb0ne>
right it is just a read
<zmatt>
it simply provides the current position whenever you want it
<mattb0ne>
so they should always be synced so it really is processing issue at the digitizer
<mattb0ne>
EM100
<mattb0ne>
let me go test
<mattb0ne>
also need to read up on IIR and FIR filters
<zmatt>
the EM100 is the limiting factor, which is why your main loop was structured the way it is
lucas_ has quit [Quit: Leaving]
dinuxbg has joined #beagle
rob_w has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
tigerxyz has joined #beagle
<tigerxyz>
Hi, I am trying to cleanup BBBw system for release. in /lib/firmware folder, there are several large files: such as dra7-ipu1-fw.xem4, etc. Is safe to remove them?
florian has quit [Quit: Ex-Chat]
vd has joined #beagle
<rcn-ee>
tigerxyz, dra7 stuff is for am57xx, clean away
<tigerxyz>
@rcn-ee thank you
<rcn-ee>
tigerxyz, remove these apt projects: firmware-am57xx-opencl-monitor firmware-am57xx-opencl-tidl
<rcn-ee>
tigerxyz, btw, what image are you using, the "tidl" firmware files shoudl only be installed on a 'tidl' image, thus you shouldn't see some of those..
<tigerxyz>
there is a service: ti-ipc-dra7xx.service, it is exited, don't know what is about, removal?
<rcn-ee>
tigerxyz, ipu is ipumm-dra7xx-installer package..
<tigerxyz>
I am using Buster 10, 4.19.50-ti-r20
<rcn-ee>
tigerxyz, Buster (what date? on the file)... nuke: ti-ipc-dra7xx
<tigerxyz>
When I list services installed: ● networking.service loaded failed failed Raise network interfaces
<rcn-ee>
tigerxyz, is that with 2019.07.07 ?
<tigerxyz>
I guess networking.service can be disabled, right?
<tigerxyz>
Yes
<rcn-ee>
no idea, connman shoud have been defualt.. but it's probally a bug we fixed since that date..
<tigerxyz>
It has RED colored
<tigerxyz>
connmantctl is working and wifi network is ok.
otisolsen70__ has quit [Quit: Leaving]
<tigerxyz>
I checked dmesg after system is booted: there is a warning: WARNING: CPU: 0 PID: 1467 at drivers/net/wireless/ti/wlcore/main.c:808 wl12xx_queue_recovery_work+0x64/0x68 [wlcore]
<zmatt>
networking.service failing most likely means there's bad configuration in /etc/network/interfaces
<zmatt>
that last warning could benefit from some more context but it I think it's the wifi driver warning that it's recovering from a firmware crash, which did tend to happen every now and then at least on older firmware (I don't see any in the kernel logs of the test bbbw at work), fortunately the driver seems to have a pretty good crash recovery mechanism
<zmatt>
rcn-ee: did you link the right thing? I don't see any dmesg warnings there
<rcn-ee>
it's in the middle...
<rcn-ee>
it's a long debug log that runs every 15minutes on every device.. (base url)
<zmatt>
I have no idea what I'm supposed to see in that log
<rcn-ee>
bascily, dmesg shouldn't have any warnings, i've back ported a few wlan0 fixes..
<zmatt>
wlcore is loaded near the end of the log and there's no error or warning there
<rcn-ee>
users's running an old kernel... 4.19.50-ti-r20, my device log is with: 4.19.94-ti-r68 i've spent some time backporting wl18xx fixes..
ikarso has joined #beagle
<zmatt>
ohh I misread what you said, I read it as "if you're seeing warnings like this" and thought you linked to an example, sorry
<rcn-ee>
i had another user on our work forum ask the same question about an hour before, kinda wondering if it's the same guy... basiclly dealing with an issue with an old kernel that was fixed. ;)
<zmatt>
regardless, those wifi firmware crashes were not particularly impactful in my experience, just a bit spammy in the kernel log, but iirc the driver recovers without even dropping the wifi connection (which is kinda neat)
michaelo has quit [Quit: Lost terminal]
mattb0ne has quit [Ping timeout: 268 seconds]
lucascastro has joined #beagle
behanw has joined #beagle
tigerxyz has quit [Quit: Client closed]
lucascastro has quit [Ping timeout: 260 seconds]
lucascastro has joined #beagle
Guest79 has joined #beagle
<Guest79>
Has Anyone here used OpenBSD on their beaglebone-original?