<mattb00ne>
zmatt: not sure what I am doing wrong only adding fields to the message
<mattb00ne>
crashes immediately
<mattb00ne>
I have decoder running on PRU0 and this running on PRU1
<set_>
GenTooMan: It was 95 degrees today for almost all day! We are in for an early storm this year! LA in da' hizzy!
<set_>
Speakin' of the weather...
<set_>
I still have not found a nice set up yet.
starblue3 has joined #beagle
<set_>
I saw the weather stuff that can be accessed via the new PocketBone Grove Kit thing. Does this handle weather too?
<set_>
I mean, I saw the GPS on it. This is a start.
<set_>
Sorry mattb00ne, please proceed.
* set_
staying quiet now for my sake!
starblue2 has quit [Ping timeout: 272 seconds]
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 252 seconds]
<mattb00ne>
its ok seems zmatt is not herer
<mattb00ne>
i will lurk
<mattb00ne>
I need his help I am stummped!
<set_>
mattb00ne: I am back! I would help but I know less than the average human.
<set_>
Should I look anyway?
<mattb00ne>
if you want
<set_>
Okay.
<set_>
Off to look!
<set_>
I see something that stands out.
<set_>
Not me!
<set_>
ha.
<set_>
Your Python source has a C comment in it.
<set_>
That is one thing I noticed off the start of review.
<set_>
Back to it!
<mattb00ne>
besides
<mattb00ne>
that
<mattb00ne>
must of messed up cut and paste
<set_>
Is core.load the output file?
<set_>
Oh. that comment is a union?
<set_>
Hey!
<set_>
Can the classes all be the same, i.e. ctypes.Structure?
aswin has quit [Quit: Lost terminal]
<set_>
I had some issues w/ classes a while back.
<set_>
I would run the source to find out what happens but I will take your word for it. I do not want to crash my bbb again...I have done it enough for smaller reasons.
<set_>
mattb00ne: I will try to find a class representation that i am discussing from OOP.
<set_>
I just do not know now of a way around classes w/ objects that are the same.
<set_>
I was thinking of inheritance or multiple inheritance. Maybe calling them differently may help (trial and error). I can try real quickly.
<set_>
Now...for starters! I have not a clue what your end result may be currently or ever.
<set_>
I am going to boot.
<set_>
i will try it out.
<set_>
Dang. it! 30 minutes.
<mattb00ne>
lol
<mattb00ne>
i know i am not comfortable with C at all
<mattb00ne>
i am thinking it has to do with a memory map error
<mattb00ne>
just not sure where
<mattb00ne>
I like stepping through code to debug and you cannot do that with C
<set_>
Oh.
<set_>
I am working on the Python now. Who knows? I may come across a act that may simplify the classes I see.
<set_>
Does the C source, that I have not looked at currently, use or get used by the Python source?
<mattb00ne>
yes the C runs on the PRU
<set_>
Okay.
<set_>
So, the Python just starts the C running?
<mattb00ne>
yes
<set_>
Okay.
<set_>
I am trying to get bearings here. I want to help but there are specific instances of Python and C I have not-a-clue on how to utilize.
<set_>
So, i will try the classes from the start to test.
<set_>
https://pastebin.com/raw/nnrTiTcA is something to think about w/ Inheritance. I mean, I do not want to write the source for you but...
<set_>
Multiple Inheritance may help here.
<set_>
I found that on Python Docs. along w/ a simple tuple.
<set_>
So, you can call your lists or tuples or whatever. And...this matters if you are trying to alter the tuples, lists, dictionaries later. Some of those cannot be altered later, i.e. privately or publicly...
<set_>
But...you understand.
<set_>
I mean...if you are publishing that idea, you know more than I think I know.
<set_>
Let me see what you are using. Back to the source!
<set_>
Hey...
<set_>
What is [ ( ) ] in python?
<set_>
I am unfamiliar w/ this idea...
<set_>
Oh. It is a tuple in a list.
<set_>
?
<set_>
Anyway...mattb00ne: I will keep trying. If you get bored, just reply once I get back!
set_ has quit [Quit: I thought I saw a puddy-cat...]
set_ has joined #beagle
<set_>
Okay...so the tuple cannot be changed. Does your source update the tuple?
<mattb00ne>
it does not
<set_>
Okay. Well, it is not that idea.
<mattb00ne>
yeah all I do to the orignal script is add fields to that message structure
<mattb00ne>
but something breaks
<mattb00ne>
i am probably missing an update
<mattb00ne>
if I strip it out it works
<mattb00ne>
arg
<mattb00ne>
i am gonna sleep on it
<set_>
Fine. Think!
<set_>
I will be back too! Who knows? I may come up w/ other ideas on why things break or may work.
<set_>
Just another idea before i am completely done for tonight...Where is the ascii characters you are looking to decode?
<set_>
Anyway...out for now.
mikkel has quit [Ping timeout: 244 seconds]
mattb00ne has quit [Ping timeout: 268 seconds]
mikkel has joined #beagle
calculus has quit [Ping timeout: 272 seconds]
calculus has joined #beagle
set_ has quit [Ping timeout: 252 seconds]
vagrantc has joined #beagle
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
rob_w has joined #beagle
russell-- has joined #beagle
russell-- has quit [Changing host]
johanhenselmans has joined #beagle
rcn-ee has quit [Ping timeout: 272 seconds]
set_ has joined #beagle
Posterdati has quit [Ping timeout: 252 seconds]
Posterdati has joined #beagle
<zmatt>
it's just a structure alignment issue... but it seems mattb00ne isn't here right now
Shadyman has quit [Quit: Leaving.]
Posterdati has quit [Ping timeout: 252 seconds]
Posterdati has joined #beagle
GenTooMan has quit [Ping timeout: 268 seconds]
GenTooMan has joined #beagle
mattb00ne has joined #beagle
<mattb00ne>
not sure why Idisconnected
<zmatt>
mattb00ne: unless I missed it you didn't mention what the indicated crash was, I'm assuming the assert on line 68 (ddr.msg_size == sizeof(Message)) ?
<zmatt>
stream.cc:60 ? there's no abort on line 60 of the code you pasted, is that pastebin the exactly same version of the code you're running?
<mattb00ne>
probably not i tried and failed a bunch of times. let me start over and run
<mattb00ne>
just so I am clear. To adjust the size of the message I should only have to change it in two spots
<zmatt>
the problem is almost certainly that python and clpru have different assumptions about struct field alignment
<mattb00ne>
and would this code be sensitive to running on core 1 vs core 2
<mattb00ne>
the memory addresses
<zmatt>
clpru imposes no alignment requirements, while python assumes natural alignment
<mattb00ne>
ok
<zmatt>
core 0 vs core 1 you mean, and no I see no reason why it would be
<mattb00ne>
ok
<mattb00ne>
just checking
<mattb00ne>
what does natural alignment mean
<mattb00ne>
brb
<zmatt>
it means that each field is at an offset that's a multiple of the size of the field, so each 16-bit field is at an even offset, and every 32-bit field is at an offset that's a multiple of four. that in itself is satisfied by your layout, but the problem is that if you have an array of your struct the next struct would itself no longer be naturally aligned since your struct size is not a multiple of 4 ...
<zmatt>
...bytes
<zmatt>
the easy fix is adding some dummy field(s) to pad it to a multiple of 4 bytes
calculu5 has joined #beagle
calculus has quit [Ping timeout: 272 seconds]
<mattb00ne>
oh ok
<zmatt>
that's why I said I assumed the abort was due to assert( ddr.msg_size == sizeof(Message) );
dinuxbg_ is now known as dinuxbg
<zmatt>
ddr.msg_size is the size of Message according to python, sizeof(Message) is the size of that struct according to clpru
<mattb00ne>
I think it was but I was all over the place putting stuff in and taking stuff out that I bastardized your code at this point.
<mattb00ne>
trying to strip it back to the beginning when it was working ie before I messed with it
<zmatt>
clpru doesn't include any implicit padding hence deemed Message to be 18 bytes
<zmatt>
python added implicit padding to ensure natural alignment hence deemed Message to be 20 bytes
<zmatt>
that's why it's a good idea to use git and commit often (especially whenever it's working), so you can easily see what you did and have the ability to go back to any previous state
<mattb00ne>
yeah true
<mattb00ne>
well let me get back to working code and I will pop in but basically it sounds like I just need add up the bytes used for my full message and then pad to next mutliple of 4 using a spacer variable
<zmatt>
maybe there's a way to force clpru to use natural alignment
<zmatt>
try changing "struct Message" to "struct __attribute__((aligned(4))) Message"
<mattb00ne>
also if I wanted to stick an input variable like a uint8 at the front of memory and use an offset that wont matter since I am still on a multiple of 4?
<zmatt>
the easy way to ensure individual struct fields are naturally aligned is to sort them by size: 32-bit fields first, then 16-bit fields, then 8-bit fields
<mattb00ne>
ok I will do that
<mattb00ne>
I think I was already by accident
<zmatt>
yep
<mattb00ne>
ok let me mess with this and I will report back
<mattb00ne>
the buffer seems faster than my repeated calls for data
<zmatt>
?
<mattb00ne>
this whole thing was prompted by the inefficiency of my loop where I just poll the sensors repeatedly
<mattb00ne>
though I have not had it working yet, just seeing the idx print out super fast semms like this will be a big improvment
<zmatt>
not sure what you mean by that... the point of this message buffer was having a reliable way to transfer your measurements to python
<mattb00ne>
yeah
<zmatt>
you probably want to change the ringbuffer full handling to drop messages if the ringbuffer is full rather than doing abort(), unless it's imperative that python doesn't miss a single message and crashing is preferred to dropping any measurement
<mattb00ne>
I will see I think I will be consuming messages fast enough that it wont be a problem but if it is I will change
<zmatt>
on the python side you can detect when this happens due to ids being skipped, i.e. the "assert msg.id == lastid" would fail (and should then be replaced by more graceful handling of dropped messages)
<zmatt>
yeah you can leave it for now, you'll know right away if it happens
<zmatt>
just mentioning it so that if it happens, you know what to do
<mattb00ne>
cool!
<mattb00ne>
ok let me tinker
<mattb00ne>
thank you sir!
<mattb00ne>
why did we change servers btw
<mattb00ne>
i was on free node for the longest
<mattb00ne>
i like it is much easier to look at logs on this one
<mattb00ne>
last one just gave you a dump
<zmatt>
in place of that assert, (msg.id - lastid) & 0xffffffff would yield the number of messages dropped
<mattb00ne>
ok
<zmatt>
I guess you missed the whole freenode kerfluffle, lemme see if I can find an article that summarizes it
<zmatt>
mattb00ne: what tipped the scales in the end for #beagle and many other channels that were still in "wait and see" mode was that in response to a few channels explicitly closing their freenode channel to users (https://freenode.org/static/img/rsync-forced-move.png) Andrew Lee changes the freenode policy to require primary channels to remain "open" (without defining what that means) and then 2 hours ...
<zmatt>
...later had a bot drop, hijack and forcibly reopen hundreds of channels that merely had "libera" in the channel topic, even if it was just something like "we also have presence on libera"
<mattb00ne>
dang
<mattb00ne>
doesnt he have enough money
<mattb00ne>
reading the article it sounded like he was just donating and then he felt he owned irc
<mattb00ne>
oh well it seems like that blew up in his face
<zmatt>
and then they spent the rest of the day restoring channels to their original owners since apparently they had not made a backup of channel registrations before having a hastily written bot trash hundreds of channels
<zmatt>
yeah the problem is that freenode didn't particularly need money, and definitely didn't need him
<zmatt>
and his meddling resulted in the operator staff leaving, which are the people that make an IRC network what it is
<zmatt>
subsequently they also managed to loes their mailserver (which also means they lost control over a database of email addresses, which they should have reported under GDPR but didn't), and I just now read that freenode inexplicably banned all of IRCCloud: https://twitter.com/IRCCloud/status/1404153550159159298
Duality has joined #beagle
shoragan[m] has quit [Ping timeout: 244 seconds]
mvaittin has quit [Read error: Connection reset by peer]
jkridner[m] has quit [Read error: Connection reset by peer]
shoragan[m] has joined #beagle
mvaittin has joined #beagle
jkridner[m] has joined #beagle
rob_w has quit [Remote host closed the connection]
Guest67 has joined #beagle
<Guest67>
hello, I need a volunteer who have some Beagle boards for a benchmark; the board must not be on any CPU load (IDLE state/doing nothing at all), what you shall do is running an OpenSSL command that take 1.5m with (CPU will be 100%) to test crypto algos speed; for a student academic project
<zmatt>
I guess I could do that... you can also find various crypto benchmarks here: http://bench.cr.yp.to/ I know that they have some beaglebones among their test systems
<Guest67>
zmatt thank you, however I need the data from that method specifically
<zmatt>
I'm curious what is the point of gathering this data?
<Guest67>
comparing RSA vs NIST-P256 in openssl
<Guest67>
as a reason to move from RSA-based PKI for TLS/SSL to ECC-based one
<Guest67>
so I need to see data from various embedded boards
<Guest67>
I have some questions, what board do you have, the OS, and is it 64bit?
<Guest67>
"armv7l" I guess not a 64-bit ARM
<zmatt>
I was about to say the first line answers your last question
<zmatt>
this is a beaglebone black running debian buster
<zmatt>
I guess I can also test my bbx15
<Guest67>
Yes I won't mind that, I noticed the ECC perf in 64arm is 2 times faster than 32arm in RPi, but the RSA stays the same (i guess b/c of 'options:bn(64,32)' vs "options:bn(64,64)") in the output
<zmatt>
looks like this patch should apply cleanly to older kernels
<tigerxy>
I guess I have to patch and rebuild the kernel?
<zmatt>
maybe if you ask rcn-ee nicely he'll include it in the patchset for his kernel packages, or you can drop it in as a local patch and build kernel packages yourself using his build scripts
<tigerxy>
Ok. Thanks
m-atoms has joined #beagle
mattb00ne has quit [Ping timeout: 244 seconds]
Guest67 has left #beagle [#beagle]
lucascastro has joined #beagle
mastermind has joined #beagle
mastermind is now known as mattb0ne
<mattb0ne>
ok I borked something
<mattb0ne>
I do not get an out an out crash but I am not incrementing
<mattb0ne>
ok
<mattb0ne>
fixed it
<mattb0ne>
i am going to save this as my starting point
<mattb0ne>
zmatt: I am confused here
<mattb0ne>
so I am trying to merge the stream buffer with the encoder stuff.
<mattb0ne>
so I have the encoder on PRU0
<zmatt>
what do you mean by that?
<mattb0ne>
and I am just reading the value with a pointer
<zmatt>
I yeah the encoder's current value can simply be read whenever you need it
<mattb0ne>
I am getting weird behavior on the buffer side where it is changing
<zmatt>
uhh you're reading the position once outside the loop in main()... also you're not doing anything with the position argument passed to send_message
<mattb0ne>
the position variable is looping between 600,000 and 700,000
<zmatt>
your code isn't filling in msg->position, you commented it out
<mattb0ne>
so what value is in there garbage
<zmatt>
yes, just whatever happened to be in memory
<mattb0ne>
ok there we go
<mattb0ne>
so another question
<mattb0ne>
when I start the code the value is zero in there
<zmatt>
the position value from the encoder? I imagine it'll be zero initially when the encoder starts yes, you'd need to check the encoder's code
<mattb0ne>
if I move it the one way it goes up like we
<mattb0ne>
1,2,3, etc
<mattb0ne>
if I got the other way it loops and starts with a big number
<mattb0ne>
which is fine
<zmatt>
yes it's a 32-bit integer
<mattb0ne>
what is wierd is I cannot go back to 0 once I do that
calculu5 has quit [Ping timeout: 252 seconds]
<zmatt>
uhh what
<zmatt>
that makes no sense, it should just increment from 4294967295 to 0
<mattb0ne>
it starts with the left most digit
calculus has joined #beagle
<zmatt>
oh I see, it doesn't erase the text in your terminal when the line gets shorter
<mattb0ne>
oh ok
<mattb0ne>
is there a format spec I can do
<mattb0ne>
maybe pad with zeros
<zmatt>
one fix is to use fixed-width formatting like position={position:08x} so that the line never gets shorter
<zmatt>
or you can add a special sequence at the end that will erase till end of line... one sec
<zmatt>
that \x1b[J at the end will erase anything behind the cursor in the terminal
<zmatt>
if you want to know the signed difference between two position values, subtract them and run that value through this helper function: https://pastebin.com/xJapFVHR
<zmatt>
e.g. if for each received message you'd want to know how much the position changed since the last message you'd do something like https://pastebin.com/fUiAkSzy
<mattb0ne>
ok
<mattb0ne>
now I am putting in the load cell
<mattb0ne>
slow, steady and systematic
tigerxy has quit [Quit: Client closed]
<mattb0ne>
ok
<mattb0ne>
here i I am stuck
<mattb0ne>
the core does not crash but it does not increment
<zmatt>
the various uart functions still use __halt() to indicate errors, if you use abort() instead you'll know which one triggered
<zmatt>
can't you issue a software reset from python?
<zmatt>
or at least halt automatic reporting and flush the uart buffer
<mattb0ne>
let me try that I think that is how I stopped it before I just need to send a command.
<mattb0ne>
is there an easy way for the c code to read the ecap
<mattb0ne>
like I have the scripts to do it from python
<mattb0ne>
would be nice to just bury that in the c code
<zmatt>
you also had code to do it from C I'm pretty sure
<mattb0ne>
was yucky
<mattb0ne>
lol
<mattb0ne>
let me look
<zmatt>
in fact, that was the sole reason for setting up ecap in the first place
<zmatt>
in fact, I remember I gave a whole bunch of variants
<mattb0ne>
yeah I could do in cycles
<mattb0ne>
i settled on the python because it was easier
<zmatt>
there's no point in python reading pru ecap, what's the purpose of that? (other than for debugging)
<mattb0ne>
but rethinking this I may want to force my self in the C. I think my problem was it was based on the cycles and you had to do a lot to get it into seconds
<zmatt>
no you don't, nor do I get why pru needs it in seconds
<zmatt>
right, that version is in units of 65536 cycles (0.32768 ms)
<mattb0ne>
well since I am sending the reading out to python to have the timestamp with it. My other option is to just as soon as I get the message append the time with these functions
<zmatt>
also that looks wrong
<mattb0ne>
I may just stick with that
<zmatt>
return now += (uint16_t)( ( CT_ECAP.TSCTR >> 16 ) - now );
<zmatt>
it should be that
<zmatt>
if you want to know when the reading was taken, stick this timestamp into the message
<zmatt>
python can easily convert it to whatever format is preferred for the user interface
<mattb0ne>
ok this is in ns right ?
<zmatt>
you can definitely also have pru provide a timestamp in seconds and nanoseconds, I've given code for that too, but that takes up more space and I don't hugely see the point
<mattb0ne>
ok
<zmatt>
do make sure python sets up ecap correctly for whatever type of timestamping you use
<mattb0ne>
meaning what I have c code that starts the ecap I think
<zmatt>
why do you have ecap initialized by c code?
<zmatt>
difference trade-offs are possible of course between precision and range, but 2^16 cycles seemed like a fine value for your purposes and is slightly more efficient than most other choices
<zmatt>
or you could just use timestamp_cycles() for maximum precision, the fact that it wraps every 21 seconds doesn't really seem like a problem to me
<mattb0ne>
ok
<mattb0ne>
yeah this will work
<zmatt>
if pru sticks timestamp_cycles() into the message, then python can unwrap it and convert to seconds: https://pastebin.com/0Xnn4FJu
<zmatt>
this will correctly keep track of time as long as no more than 21 seconds passes between messages processed, which is fine since you're expecting to be receiving many messages per second
<mattb0ne>
orefect
<mattb0ne>
perfect*
<zmatt>
you then don't need the more elaborate timestamp() function in pru
<mattb0ne>
yup
starblue3 has quit [Quit: WeeChat 2.3]
starblue has joined #beagle
<zmatt>
for reference, this would be how to get a seconds+nanoseconds timestamp in pru using eCAP: https://pastebin.com/TkFpy87h note the different initialization. but I don't recommend using this, it's just harder to work with
<mattb0ne>
I should put all these zmatt nuggets on a website
<mattb0ne>
what does the f in the print statement buy you
<mattb0ne>
sometimes I see it sometimes I dont
<mattb0ne>
not sure what hte significance is
<zmatt>
f'' is a formatted string
<zmatt>
meaning python will parse the {} expressions and replace them by their expansions
<zmatt>
remove the f and you'll immediately see what I mean
<mattb0ne>
lol
mturquette has joined #beagle
<mattb0ne>
ok
<mattb0ne>
so I have this working outside my program and moving it back in is causing problems
<mattb0ne>
what is special about this line assert( 0x80000000 <= (uint32_t)ddr.msgbuf );
<zmatt>
verifying the message buffer address is remotely sane
<mattb0ne>
so if I am crashing there
<mattb0ne>
per the code
<zmatt>
then shit is very fucked
<mattb0ne>
my memory address is getting perverted or something
<zmatt>
it probably just means the DDRLayout structure isn't getting initialized properly by python for whatever reason
<zmatt>
before the core is started
<mattb0ne>
got it
<zmatt>
(ddr_layout in the python code)
<mattb0ne>
right
<mattb0ne>
so I needed to swizzle it around so I put that part in my widget init function
<mattb0ne>
basically just added a bunch of self.XXXXXX
<zmatt>
it needs to be after the pru program is loaded but before it is started
outrageous has joined #beagle
<mattb0ne>
oh ok
<mattb0ne>
ok that was it
<mattb0ne>
so when you put a program on a PRU
<mattb0ne>
it is also setting up the memory stuff
<mattb0ne>
i guess I am asking clumsily why I need to load before running that code
<zmatt>
that variable is in initialized memory yes
<zmatt>
hence loading the pru program will overwrite that memory
<set_>
Hey!
<set_>
What are you guys doing?
<mattb0ne>
zmatt helping with that issue I had yesterday
<set_>
Oh...okay. How is it going so far?
<mattb0ne>
good
<set_>
Nice!
<mattb0ne>
it is fixed
<set_>
No joke?
<set_>
Nice and double pickle!
<mattb0ne>
have a small issue in that I need run it twice but I think it has to do with how I exit
<set_>
Oh.
<mattb0ne>
not sure why but I will tackle that later
<set_>
Okay.
<set_>
Well, I guess I will not rewrite history today. Dang it!
<set_>
I was hoping to get some classes action and some functions in.
<mattb0ne>
zmatt: I will alternate between it working and a hard crash with the following SystemExit: core halted at pc=11
<mattb0ne>
i am not getting a line from stream.cc
<mattb0ne>
if I run it again the problem goes away
<mattb0ne>
but the next run will crash
<mattb0ne>
same error
<mattb0ne>
weird
<set_>
I am actually trying to get the PRU_CGT and PRU SW Support Package to install correctly on the am335x to use it! Hmm.
<mattb0ne>
whats that do
<set_>
v5.7 and v2.3.3 but I do not know what to do w/ the .out files so far.
<mattb0ne>
just examples
<set_>
Right.
<set_>
Examples for building blocks.
<set_>
I compiled the source on WSL2 and then sftp to the BBB.
<set_>
But...
<set_>
I am not sure exactly what to do from that point forward.
<zmatt>
mattb0ne: have you replaced every __halt() other than the one in abort_at() by abort() ?
<zmatt>
i.e. the ones in uart_recv_byte, uart_recv_line, and receive_measurement
<set_>
I have all these .out files, .pp files, and so on. I have been reading the clpru Docs. to see if I can use the current source in any way fashionable.