<zmatt>
or run debian buster on the rpi, e.g. in a container, to get a similar toolchain
<zmatt>
bullseye (which is the latest stable release of debian) uses gcc 10
<zmatt>
in general, when cross-building from one debian/ubuntu system (using the distro-provided toolchain and multiarch support) to another you'll want to use very similar versions on both
<zmatt>
mattb0ne: sorry, I fell asleep... and ehh, you can put it whereever convenient I guess? I don't quite remember where you're currently putting what
<zmatt>
mattb0ne: the decoder is declared as unsigned because that makes the most sense for a counter that wraps
mattb0ne has quit [Ping timeout: 272 seconds]
mattb0ne has joined #beagle
<mattb0ne>
zmatt do you have that paste bin with the pru memory addresses
<set_>
Mo memory!
<set_>
Guys.
<set_>
I did not get the job on the motor enabled, infrared detection, gate thing.
<set_>
Boo.
<set_>
I know.
<set_>
But...I am going to keep trying. The more, the merrier.
<set_>
Go, go, gadget, GSoC. I hope everyone does well. I am still just building and learning. Mo enablement!
mattb0ne has quit [Ping timeout: 256 seconds]
<tenchiro>
zmatt thank you so much! Let me try upgrading the BBB to one of these newer version. I really appreciate that. Yes, there is a note about that in the PX4 docs to keep the versions similar, I just couldn't figure out how to do it. I didn't realize there are newer versions of debian I can use on the BBB. Thank you.
<tenchiro>
Also, I am trying to follow these instructions, however after flashing the monthly, I get a 403 error when I try to access the card to configure the wifi.
<tenchiro>
I have flashed the monthly build and rebooted my beaglebone, however I cannot seem to access it to configure the wifi. It does connect and I can see the files in the local drive. However when I try to follow the instructions, it says "access forbidden 403". I am able to connect through wifi, but I get the same error when I try to access the
<tenchiro>
ipaddress 192.168.8.1. And advice would be appreciated. Thank you.
CygniX has joined #beagle
ds2 has quit [Ping timeout: 272 seconds]
ds2 has joined #beagle
lucascastro has joined #beagle
<Archana>
Hello!
<Archana>
Dang it.
Archana has quit [Remote host closed the connection]
set_ has joined #beagle
<set_>
Hello...this is catch up period! What did I miss?
<set_>
And why are people not in school?
<set_>
Where are the books, the people, and the BBBs?
<set_>
Nothing anymore, anymore nothing ever?
<set_>
Argh.
<set_>
Anyway, times are tough but it must be tougher than expected for some.
<set_>
So, I will retreat to la-la-land once more (since I am perfect). Ha.
* set_
must be goodie-two-shoes!
<set_>
I found some new lib. from a Phd. fellow. Self-proclaimed or not, he has it down pat w/ the BBB for specific kernels and images.
<set_>
It was a relief to find other people are still willing to share around their builds, i.e. no matter how difficult things are for some people.
CygniX has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
CygniX has joined #beagle
<mattb0ne>
whats the difference between dram and iram
<mattb0ne>
for the PRU
CygniX has quit [Excess Flood]
CygniX has joined #beagle
<set_>
mattb0ne: First one to find out, wins?
<set_>
It is not a game. I am being serious!!
<set_>
I will search while you search. The first one that finds the answer must post it.
<set_>
Are you game
<set_>
?
<set_>
28 minutes and counting!
<mattb0ne>
i am game
<mattb0ne>
I need to find the logs to get old pastebins
<mattb0ne>
this was before the migration to libra chat
<set_>
No, in the big book!
<set_>
TRM. We can learn how exactly to chat about what the machine understands.
<set_>
the am335x understands a lot but our chat w/ one another is lacking in this dept.
<set_>
Are we discussing the am335x still and the PRUs onboard?
tenchiro has quit [Ping timeout: 250 seconds]
<set_>
5000 large on pages to review. It is almost mind numbing but it shall be fun, fun, fun!
<set_>
I am saying that b/c it is boring to review the TRM alone.
<set_>
W/out conversing about it, it just disolves itself into nothingness.
<set_>
I mean...the beagleboard.org people just put out fresh images. Why not?
<set_>
I am not saying you have to have my email address, home address, or to reciprocate in that manner. Chat and TRM about the am335x or am5729 is all. Period.
<set_>
Well, no issue. I will just keep reviewing it until my boards die or I slaughter them off by accident. Crude garbage is what I think you think I am typing, i.e. hence this last post about the TRM and my langauge skills. English and not Python3 or C/C++ is what I am discussing...oof.
<set_>
no issue!
mattb0ne has quit [Ping timeout: 276 seconds]
<set_>
Well, there goes that...I never get it.
<set_>
Everyone always yells, "You got it!" Nope, I sure do not.
mattb0ne has joined #beagle
<set_>
10:00!
mattb00ne has joined #beagle
mattb0ne has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
vigneshr has quit [Quit: Connection closed for inactivity]
tenchiro has joined #beagle
buzzmarshall has quit [Remote host closed the connection]
mattb00ne has quit [Ping timeout: 240 seconds]
set_ has quit [Remote host closed the connection]
wonko-the-sane has quit [Quit: leaving]
mattb00ne has joined #beagle
set_ has joined #beagle
otisolsen70 has joined #beagle
vigneshr has joined #beagle
tenchiro has quit [Quit: Client closed]
tenchiro has joined #beagle
Siegurd has joined #beagle
<Siegurd>
HI! Sorry for leaving yesterday with spidev2.1 problem. I will try to investigate the problem and report on success.
Siegurd has quit [Quit: Client closed]
Siegurd has joined #beagle
florian has joined #beagle
j0rd has quit [Ping timeout: 248 seconds]
<tenchiro>
Good evening, I hope you can help. I've updated my Beaglebone blue with the lates debian 5.10.106-ti-r41, but it seems the devices are not properly configured. When I run a driver test with robotcontrol, I get:
<tenchiro>
ERROR: ti-pwm driver not loaded for hrpwm0
<tenchiro>
ERROR: ti-pwm driver not loaded for hrpwm1
<tenchiro>
ERROR: ti-pwm driver not loaded for hrpwm2
<tenchiro>
ERROR: ti-eqep driver not loaded for eqep0
<tenchiro>
ERROR: ti-eqep driver not loaded for eqep1
<tenchiro>
ERROR: ti-eqep driver not loaded for eqep2
<tenchiro>
PASSED: pru-rproc
<tenchiro>
ERROR: uart1 driver not loaded
<tenchiro>
ERROR: uart2 driver not loaded
<tenchiro>
ERROR: uart4 driver not loaded
j0rd has joined #beagle
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
<kveremitz>
I'm guessing there are some overlays missing there .. at the very least for the serial ports
<mattb00ne>
zmatt: I am confused on how to access PRU1 private memmory on the github you have pruss.dram1 (offset 0x02000 in pruss, up to 8KB) but I have been using #define position_var ((uint32_t const volatile *)0x00002000) to reference PRU0 private memory
<mattb00ne>
if I want to plop a big array in private memeory for PRU I am tempted to put (offset 0x00000000) but that sounds like it would be PRU0 private area
<Siegurd>
Yes, spidev1.1 works! on mini image as spidev2.1 on usual 4GBimg
xet7 has joined #beagle
<set_>
Awaken!
<set_>
It is not 10:00 yet!
<set_>
tenchiro: The PWM and UART needs a refinement on the newer kernels. I tried it too.
<set_>
I am surprised the PRU-RPROC driver is working now. That is good news!
<set_>
When compiling the source, probably b/c of changes in 8 to 10 gcc, there are errors that need tending.
<tenchiro>
Thank you for the responses. I greatly appreciate it. Is this something I can correct or something I'd need to wait. Thank you.
<set_>
I say jump on in! Compiling the source is the first step to "doing it w/ class."
<set_>
Do you know C/C++ well?
<set_>
I think the source is written in C/C++. It will be helpful when trying to handle errors and debugging.
ikarso has joined #beagle
xet7 has quit [Remote host closed the connection]
Shadyman has quit [Quit: Leaving.]
xet7 has joined #beagle
<tenchiro>
C and C++ are not a problem. Though I'd be concerned my knowledge of the os architecture is not sufficient for building entirely from the ground up. My goal was to get the PX4 going. But I've got some cross dependency conflicts with my build environment, the cross compilers and the older os version on the beaglebone blue. All I really need is a
<tenchiro>
version that supports one dot version of clib. 2.29 vs 2.28. 5.10 has 2.31 which is sufficient but for this device issue. Maybe I can go backwards one or two releases when the gclib is > 28 but the devices were still working?
<set_>
Oh no.
<set_>
I am not saying from start to finish but there are entries you can output to file for seeing what exactly happens in the build of librobotcontrol.
<set_>
That is one step towards something.
xet7 has quit [Remote host closed the connection]
<zmatt>
tenchiro: try installing the latest 4.19-ti kernel, see if that resolves the problem
<zmatt>
tenchiro: also, ignore set_
<zmatt>
:P
tenchiro has quit [Ping timeout: 250 seconds]
<zmatt>
tenchiro: I can't easily check right now if those drivers are for some reason not being enabled on the 5.x kernel or if it's just a compatibility-issue with librobotcontrol, but in either case downgrading the kernel to the one used in the stable images should probably fix it
<zmatt>
(my guess would be it's a compatibility issue)
mattb00ne has quit [Ping timeout: 240 seconds]
kveremitz has quit [Ping timeout: 240 seconds]
<set_>
No, not me!
* set_
attentionize me.
<set_>
Hey...are you guys going to be ready?
<set_>
you know...for GSoC trials and tribulations! Send all output to file!
kveremitz has joined #beagle
buzzmarshall has joined #beagle
<set_>
For instance: set_ is the Main Man, Number One of all > truth.txt
<Siegurd>
Can I turn off recovering journal? or cleaning files?
mattb00ne has quit [Ping timeout: 246 seconds]
mattb00ne has joined #beagle
Guest79 has joined #beagle
<Guest79>
Hi. I am looking to write a variable which is a double to a file. Then I am looking to read this variable from the file upon next power cycle on. Any help would be appreciated.
<mattb00ne>
hmmm
<mattb00ne>
you could add something to run on boot
<mattb00ne>
not sure the exact steps but seems google solvable
Guest79 has quit [Quit: Client closed]
<mattb00ne>
i would wait for the zmatt
jfsimon1981_c has quit [Ping timeout: 246 seconds]
mattb00ne has quit [Ping timeout: 246 seconds]
ketas has quit [Ping timeout: 248 seconds]
<zmatt>
Siegurd: sure, if you do that then it'll instead do a full filesystem check and/or fail to boot due to filesystem corruption
ikarso has joined #beagle
<zmatt>
Siegurd: what do you mean by "after enabling r-o file system" ?
<zmatt>
if the filesystem is truly readonly then it has no reason to do a journal recovery (which only happens after power failure while the filesystem was mounted read-write"
<zmatt>
)
mattb0ne has joined #beagle
<mattb0ne>
why oh why wont C let me declare an array
<mattb0ne>
does the PRU not support arrays
otisolsen70 has quit [Quit: Leaving]
<zmatt>
most likely you're doing it wrong
<zmatt>
mattb0ne: also, on the PRU cores, 0x0000 - 0x1fff always refers to the core's own private ram and 0x2000-0x3fff to the other core's private ram
<zmatt>
so on core1, 0x2000 will be dram0 rather than dram1
<mattb0ne>
I striped a lot out because I was getting so many errors
<mattb0ne>
for the life of me I am not sure why my Signal struct is throwing an error
<mattb0ne>
i tried a couple things no dice brb
tenchiro has joined #beagle
<zmatt>
is this C or C++ ? because those initializers inside a struct are only permitted in C++
<zmatt>
also, why did you copy-paste parts of my sys_gpio.h header into your source file? just leave the header be as it is and #include it
<zmatt>
also, you're not actually reading the position var inside your loop, just a logically cached copy of it
<zmatt>
and there's plenty more questionable here, but I'm not sure I have the energy to explain right now
<zmatt>
there's also a bunch of points I already made last time you seem to have ignored, e.g. you shouldn't use unsigned integers for the error, or A
<zmatt>
and you probably can't use the control_signal directly as PWM value without scaling (using a right-shift), since doing so would leave you with pretty much no resolution in your coefficients
<zmatt>
e.g. right-shifting it by 16 would give you 16 fractional bits for your coefficients
<mattb0ne>
lol
<mattb0ne>
well starting at the top
<mattb0ne>
this is C and I am just trying to create an array of ints for my input signal
<mattb0ne>
I had a lot incorporated but the thing threw out alot of errors so I was starting from working code since it was on a different computer I wasnt actively referencing it
<mattb0ne>
so I made a lot of mistakes again
<mattb0ne>
how do I make a struct with an array in it for the PRU
<mattb0ne>
that is my most pressing question
<zmatt>
how you put an array into a struct is not an architecture-dependent question, it's purely a C question
<zmatt>
and you got it almost right, the problem is the initializers you added
<zmatt>
like I said, you can't do that in C
<zmatt>
why are you putting this into a struct anyway?
<zmatt>
also, why are there two arrays? don't you just need a single array of data values?
<mattb0ne>
I am a bit worried about tracking with time so I was going to include that as well so I can check
<mattb0ne>
though I guess I would just need dt
<zmatt>
if you want to write it from python, just declare it as a global variable in pru shared memory, just like 'ddr' and 'shmem'
<zmatt>
uhh, what do you mean?
<zmatt>
just make each element one time-step
<zmatt>
obviously
<mattb0ne>
right
<mattb0ne>
long day
<mattb0ne>
so your saying just put it in memory from python and do not declare it in the C program?
<zmatt>
I just literally told you to declare it in the C program
<mattb0ne>
sorry long day missed that
<zmatt>
same as ddr (line 92) and shmem (line 93)
<zmatt>
or you could put it into the SharedVars struct
<mattb0ne>
now I do want to put it in PRU1 private memory
<zmatt>
but maybe declaring it separately is nicer
<zmatt>
why?
<zmatt>
I would advise against that, leave pru1 private memory for the compiler's own stuff
<mattb0ne>
ok
<mattb0ne>
is there a website that explains that right shifting stuff
<mattb0ne>
that sailed over way over my head
<zmatt>
dunno, any tutorial on programming that covers integer arithmetic?
<zmatt>
right shifting is basically just dividing by a power of two
<zmatt>
(and rounding down)
<zmatt>
likewise, left-shifting is multiplying by a power of two
<zmatt>
by right-shifting at the very end, all your constants need to be multiplied by that same power of two, which means you now have the ability to specify them with some actual precision
<mattb0ne>
i get it
<zmatt>
you can't stick 0.25 into an integer, but you *can* stick 0.25*65536 into an integer
<mattb0ne>
right
<mattb0ne>
why is it better to use compile time constants
tenchiro has quit [Quit: Client closed]
<zmatt>
efficiency
<zmatt>
although it might not matter too much I guess
<zmatt>
just avoid division, that gets emulated in software (pru has no native way to divide numbers)
<zmatt>
but you don't need division anyway, or dt for that matter: if you look closely, all it does it scale your Ki and Kd coefficients
<zmatt>
and you need to tune those anyway
<mattb0ne>
yeah if I am assuming dt will be constant i can get away with it
<mattb0ne>
i am just wondering how true that would be
<zmatt>
also, like I said, put a range limit on your control_signal ... i.e., set it to zero if it gets negative, and likewise clip it to a suitable maximum value (i.e. max_pwm_value << 16, if you're using control_signal >> 16 as pwm value)
<mattb0ne>
it would be easier if I could fit 1000 points in there
<mattb0ne>
right I am going to do that I just needed get something to compile before adding that
<zmatt>
if you use 16-bit integers for your data points, 1000 points is 2KB
<zmatt>
and yes, dt should definitely be a constant
<zmatt>
there's no good reason for it not to be
nparafe has joined #beagle
<zmatt>
btw, you do realize __delay_cycles( 10000 );
<zmatt>
is only 50 microseconds?
<mattb0ne>
yeah I haven't gotten there yet but that was on the list to fix
<mattb0ne>
as you can see I did not get very far with this
<zmatt>
also, don't put stuff like receive_measurement() in send_message()
<mattb0ne>
If I make my A_0 compile time constants would I also need the Kp and stuff to be that as well
<mattb0ne>
how should I do it
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
I'd pass the relevant into to send_message() ... but receive_measurement is too important to bury inside send_message() since your whole loop is synchronized to that... which you seem to have forgotten yourself as well, considering you put a pointless __delay_cycles() in your loop
<zmatt>
likewise you should sample *position_var only once per loop, and you need it in multiple places
<zmatt>
didn't you eventually also need the measured force (i.e. the result of receive_measurement()) for something in your control algorithm?
<mattb0ne>
sort of abandoned for now. I change force vs time into position vs time thinking it would be easier to PID control
<mattb0ne>
i got a non-linearity due to the magnets
<zmatt>
regardless of how or what your control algorithm will look like, I'd suggest an outline like https://pastebin.com/FuJzCuX9
<zmatt>
for debugging you may also want to include the output value of your control loop in the message sent to python
<zmatt>
if the output loops like a random number generator, you may need to tweak your coefficient s;-)