<mattb0ne> doesn't like this line
<mattb0ne> if( lsr & 0x1e )
<zmatt> means there's an uncleared error in the uart, probably an overrun
<mattb0ne> ok
<mattb0ne> is there a way to flush the uart
<mattb0ne> on start up
<zmatt> simplest way is by just reinitializing it after you've sent the reset command (or stop auto-transmit command, whatever you're using) to the thing
<mattb0ne> ok
<mattb0ne> brb
mattb0ne has quit [Read error: Connection reset by peer]
mattb0ne has joined #beagle
vagrantc has joined #beagle
mattb0ne has quit [Ping timeout: 272 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
starblue1 has joined #beagle
starblue has quit [Ping timeout: 244 seconds]
Shadyman has joined #beagle
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 268 seconds]
mastermind_ has joined #beagle
GenTooMan has quit [Ping timeout: 272 seconds]
GenTooMan has joined #beagle
<set_> 10:00!
Guest64 has joined #beagle
Guest64 is now known as zero88
mastermind_ has quit [Ping timeout: 244 seconds]
m-atoms has quit [Ping timeout: 250 seconds]
<set_> Making automatic locks w/ the MotorCape!
vagrantc has quit [Quit: leaving]
russ_ is now known as russ
waldo323_ has joined #beagle
waldo323 has quit [Ping timeout: 244 seconds]
zero88 has quit [Ping timeout: 250 seconds]
rob_w has joined #beagle
ikarso has joined #beagle
LetoThe2nd has joined #beagle
philenotfound has joined #beagle
otisolsen70 has joined #beagle
<otisolsen70> Where can I see what the meaning of the blue blinking LEDs are? (assuming it has not been changed from the defaults)
<otisolsen70> On a beagleboard green
thinkfat has quit [Ping timeout: 272 seconds]
<zmatt> otisolsen70: usr0 = heartbeat, usr1 = sd card access, usr2 = cpu activity, usr3 = eMMC access
<zmatt> by default
<otisolsen70> zmatt, and if they all blink in tandem?
alan_o has quit [Ping timeout: 244 seconds]
<zmatt> that's normally only used by the flasher (to indicate failure)
<zmatt> most commonly happens when people try to reflash their beaglebone but messed things up (e.g. their sd card isn't bootable (either because it's broken or because the flasher image has been written to it incorrectly) or they're trying to reflash an old beaglebone black pre-rev-C (with only 2 GB of eMMC) with an image that doesn't fit)
<zmatt> *their sd card isn't bootable and they managed to modify eMMC to attempt to reflash itself
<zmatt> can you give more context on what you're doing exactly?
alan_o has joined #beagle
<zmatt> (sorry for the slow response, my attention is mostly elsewhere at the moment)
xet7 has quit [Quit: Leaving]
Guest6449 has joined #beagle
Guest6449 is now known as zero88
mastermind_ has joined #beagle
<otisolsen70> zmatt, that would make sense... I have dd'ed the image onto an microsd card and put it into the sd card reader of the bbg. Then I boot it up. But it just starts flashing. What am I doing wrong?
<zmatt> which image?
<otisolsen70> zmatt, this is a debian buster image
<zmatt> no, which image _exactly_? (full filename preferably)
<otisolsen70> zmatt, it is a custom image. I changed it and thus made the filename myself.
<zmatt> is it supposed to be a flasher?
<otisolsen70> zmatt, I believe it was made based on this image: https://debian.beagleboard.org/images/bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz
<otisolsen70> zmatt, sorry I am a total beginner regarding beagleboards. So I am not too familiar with the terminology. What does flasher mean here?
<zmatt> just to clarify, what's the progression of led activity?
<otisolsen70> zmatt, right now they are all lit up constantly.
<otisolsen70> A few minutes ago they were sweeping from side to side. Previoysly, they ware all blinking in tandem.
<otisolsen70> So I have seen these three states.
<zmatt> a flasher is an sd card image configured to boot into the eMMC flasher, which will reflash eMMC
<otisolsen70> Then after yet more time, they just turn off completely. I think the BBG just powers off.
<zmatt> sweeping side to side is the flasher in operation
<zmatt> all leds on followed by poweroff is flasher completion
<otisolsen70> zmatt, oh. So does that mean I need to take out the mmc and then just boot it up?
<otisolsen70> I was not aware that it would transfer the image ONTO the bbg. Is that what you are saying it is doing?
<zmatt> *take out the sd card
<otisolsen70> I guess that makes sense...
<zmatt> that's what the behaviour you're describing is suggesting it's doing yes
<zmatt> the only oddity is all leds flashing together, which indicates a flasher failure
<otisolsen70> Not it blinks more "organically" in what looks like disk activity, etc.
xet7 has joined #beagle
<zmatt> (I'm not aware of any condition that could lead to flasher failure that would resolve by retrying, the usual reason is the sd card image not fitting on eMMC)
<otisolsen70> zmatt, yeah! Now it actually booted up!
<otisolsen70> Wow. I spent way too long on this....
<otisolsen70> zmatt, thanks a lot!
<zmatt> btw, generally speaking it's a good idea to verify the contents of an sd card after writing an image to it, or writing the sd card using a tool that will automatically do so for you (like Etcher).
<zmatt> sd cards are not always reliable, and corruption occurring on the sd card can result in the flashed system being subtly broken
<otisolsen70> zmatt, ok. I typically just write to the sd card and then run "sync". Then I think it should be ok?
<zmatt> that doesn't verify the contents in any way
<otisolsen70> zmatt, of course, I could read back the sd card into sha256sum and compare with the image sha256sum
<zmatt> that's the manual way yes, be sure to read the correct number of blocks
<zmatt> and that you're not reading it from disk cache
<otisolsen70> zmatt, yeah. So will I brick the bbg if I put a corrupt image on it?
<zmatt> (but that's usually not a problem since the image is almost certainly much bigger than the disk cache)
<zmatt> no
<zmatt> it's not possible to brick a beaglebone by flashing a broken image, you can always just reflash it again (worst case if you break the bootloader in a weird way you may need to hold the S2 button during power-up to bypass the bootloader on eMMC)
<otisolsen70> zmatt, ok. Good to know
rob_w has quit [Quit: Leaving]
xet7 has quit [Remote host closed the connection]
thinkfat has joined #beagle
set_ has quit [Ping timeout: 252 seconds]
tigerxyz has joined #beagle
<tigerxyz> Hi, GoodMorning: How to generate and apply patches for kernel building?
<tigerxyz> Thank you
<zmatt> so for the current 4.19-ti kernel series you'd use the ti-linux-4.19.y branch of https://github.com/RobertCNelson/ti-linux-kernel-dev/
<zmatt> if you have a patch that cleanly applies then I suggest saving that in a new directory patches/local/ and adding dir 'local' to patch.sh; if you then run ./build_deb.sh you should get a deb-packaged kernel with the patch
<zmatt> (like I say in line 11, it's a good idea to configure a custom version suffix for your custom kernel)
<tigerxyz> I checked out: https://github.com/RobertCNelson/linux-stable-rcn-ee ; git checkout 4.19.50-ti-r20 -b temp
<zmatt> yeah don't do that, that will just make your life much harder
<zmatt> using the build repo makes it trivially easy to maintain a custom patchset, and the build script takes care of the entire process with ready-to-install debian packages as end product
<tigerxyz> I was following Robert's instructions, using his building scripts.
<zmatt> which instructions?
<zmatt> his build scripts do not involve https://github.com/RobertCNelson/linux-stable-rcn-ee
<tigerxyz> I used: linux-stable-rcn-ee/yakbuild$ ./build_kernel.sh for the version 4.19.50-ti-r20. It has been successfully built
<zmatt> ehm, yakbuild is a separate repo that doesn't have anything to do with https://github.com/RobertCNelson/linux-stable-rcn-ee
<zmatt> I don't fully get what the story is of yakbuild vs his main build repos like https://github.com/RobertCNelson/ti-linux-kernel-dev/
<zmatt> they seem to operate similarly
<zmatt> I've never used yakbuild myself
<tigerxyz> Maybe it is only under the version I checked out. yakbuild is inside the linux-stable-rcn-ee with 4.19.50-ti-r20 checked out
<tigerxyz> needs to be cloned: git clone https://github.com/RobertCNelson/yakbuild into the folder linux-stable-rcn-ee
<zmatt> so it's not in it, you just put it in it yourself
<tigerxyz> I was told by him
<zmatt> it presumably detects if the parent directory is linux-stable-rcn-ee and uses that are source tree (or at least as local git repo)
<tigerxyz> I guess so. I just want to apply patches for bluetooth fix, and rebuild the kernel.
<zmatt> anyway, the procedures seem to be the same, it looks like the difference is that https://github.com/RobertCNelson/ti-linux-kernel-dev/ will pull the upstream TI linux kernel source tree and apply rcn's patchset on top (and this is also where this patchset is maintained afaik) while yakbuild will grab that already-patched source tree from linux-stable-rcn-ee and only apply local patches on top
<zmatt> either should work fine for this purpose
<tigerxyz> Let me try. If I have troubles I'll be back to ask you for help
<zmatt> I'm guessing it still creates a KERNEL subdirectory with the source tree?
<zmatt> if so, apply your patch there and run tools/rebuild_deb.sh like my notes mentioned
<tigerxyz> Under linux-stable-rcn-ee it contains kernel folder with source code
<zmatt> it works in that directory directly?
<zmatt> it doesn't clone it?
<tigerxyz> the kernel folder is created when checking out the version
<zmatt> ???
<zmatt> hmm it's also not clear how to configure a custom version suffix when using yakbuild, that seems annoying
<tigerxyz> cd ./linux-stable-rcn-ee/
<tigerxyz> git checkout 4.19.50-ti-r20 -b tmp
<zmatt> looking at the script it should definitely create a KERNEL subdirectory (in yakbuild)
<tigerxyz> You are right. KERNEL is under yakbuilt. I think its binaries during compiling. kernel contains source
<zmatt> I don't think it uses the parent directory at all, or at most it uses it as a place to clone the linux tree from
<zmatt> I'm wondering if you misunderstood what he said
<tigerxyz> under yakbuild, it contains patches folder
<tigerxyz> You may be right. I don't know kernel (has .c files) is acutally used or not.
<zmatt> yes, those are applied to the source tree in KERNEL after it's checked out, whenever you do a full rebuild (i.e. ./build_deb.sh rather than tools/rebuild_deb.sh)
<zmatt> what do you mean by "kernel"
<zmatt> are you talking about the "kernel" subdirectory of the linux kernel source tree? because that's just one small portion of the linux kernel, it's not relevant in this context (other than simply being part of the linux kernel source tree)
<tigerxyz> kernel is (all small cases) is the folder under linux-stable-rcn-ee root folder
<zmatt> yeah that's just one of many subdirectories
<zmatt> that you'll also find in KERNEL/
<zmatt> can you share what exactly robert said? I'm wondering if you just misunderstood something
<zmatt> yeah exactly what I expected
<zmatt> you first asked where to download the source code of 4.19.50-ti-r20, which he answered
<zmatt> you then asked about building a kernel, he then pointed you to yakbuild as the easy way to build a specific kernel version
<zmatt> those sets of instructions are otherwise unrelated
<rcn-ee> tigerxyz, what issue are you having? yakbuild was setup to build "really old" tags, as the normal repo, if you checkout a specific commit, it may only work with ancient distro's..
<zmatt> he did not instruct you to clone yakbuild inside linux-stable-rcn-ee
<zmatt> hi robert
<rcn-ee> hey zmatt
<tigerxyz> so for patching. Do I have to diff the KERNEL folder with bluetooth-next?
<zmatt> he doesn't want an ancient build, he just wants to test a patch on top of current 4.19-ti
<zmatt> tigerxyz: do you stlil have the link to the commit?
<rcn-ee> ah this is the bluetooth-next thing..
<zmatt> maybe rcn can just drop it into his patchset, problem solved :P it sounded like a useful thing to have anyway
<rcn-ee> which commit?
<rcn-ee> was it a bluez issue that was resolved in kernel land?
<zmatt> no it's a kernel issue solved in kernel land
<zmatt> nothing to do with bluez
<zmatt> it looks like it should cleanly apply to 4.19
<zmatt> it just suppresses spam
<rcn-ee> (had another bluetooth question pop up over the weekend while working in the brewery... something about bluez broke something..)
<tigerxyz> Ok. So apply the patches after a clean build and rebuild?
<rcn-ee> tigerxyz, ./build_kernel.sh (wait for makeconfig to pop up..), ctrl-c/ctrl-c... cd ./KERNEL/ ; patch -p1 <... ; cd ../ ; ../tools/rebuild_deb.sh
<zmatt> meh, error: net/bluetooth/hci_event.c: patch does not apply
<tigerxyz> Thank you, let me try.
<zmatt> why doesn't it apply
<rcn-ee> it's not clean......
<zmatt> git-am doesn't use any fuzz? maybe the offset is just too big
<tigerxyz> patch just for hci_event.c as posted by zmatt?
<rcn-ee> fixed it..
<tigerxyz> fixed? on which version
<rcn-ee> localy, the hci_event.c had changed..
<rcn-ee> git clone -b ti-linux-4.19.y https://github.com/RobertCNelson/ti-linux-kernel-dev ; cd ./ti-linux-kernel-dev ; ./build_deb.sh
<tigerxyz> Ok. Thank you
<zmatt> tigerxyz: to save your disk space, you can toss the linux-stable-rcn-ee directory you have (including the yakbuild checkout you did inside it)
<tigerxyz> Nice. Save me headache, too
<zmatt> rcn-ee: does yakbuild have a way to add a custom version suffix, like BUILD+=-custom0 in version.sh in ti-linux-kernel-dev ?
<zmatt> yakbuild's version.sh has no BUILD variable
<rcn-ee> we could just add it.. main goal was to rebuild an old tag..
<zmatt> fair, but why would anyone want to rebuild an old tag if not to customize it?
<rcn-ee> true, we could add the BUILD tag, then sed the patches/defconfig to add the appended build name..
<rcn-ee> tigerxyz, builds fine..
<zmatt> maybe even add it by default... I'm personally much in favor of making sure customized builds can't be confused with (or replace) your official packages
<tigerxyz> @rcn-ee, echo 0 > /var/lib/systemd/rfkill/platform-481a6000.serial:bluetooth”, then it works. but when I reboot the system, the value will be reset to 1 . Why it reset to 1?
<rcn-ee> so the bootup default is 1... just by setting to 0, doesn't keep it between reboots.
<zmatt> ew why are you manually poking in /var/lib/ ?
<zmatt> actually rfkill state is normally persisted across reboot by systemd I think?
<zmatt> have you tried toggling it the normal way, using rfkill ?
<rcn-ee> rkill can be a pos.. systemd/rfkill/kernel all play with it..
<tigerxyz> For some reason, it is automatically reset to 1. We have one board, bluetooth device cannot be reset.
<tigerxyz> I found the post by Robert
<rcn-ee> that one isn't related to bluetooth/rfkill..
<zmatt> rcn-ee: my understanding is; rfkill utility controls the state in the kernel, systemd (specifically systemd-rfkill.service) performs save/restore across reboot
<rcn-ee> that sound true, if it works. ;)
<rcn-ee> looks like my fix is: /usr/sbin/rfkill unblock all || true
<tigerxyz> I thought the firmware for bluetooth can be reloaded by:
<tigerxyz> hciattach /dev/ttyO3 texas 115200 flow
<zmatt> does setting systemd.restore_state=0 in the kernel parameters have any effect? (this suppresses restoring rfkill from /var/lib on boot)
<rcn-ee> tigerxyz, 'hciattach' routine was "added" into the kernel land a couple of years back.. (v4.14.x or so era)
<zmatt> the following tools have all long been deprecated: ciptool gatttool hciattach hciconfig hcidump hcitool rfcomm sdptool
<zmatt> "They're no longer receiving updates and at some point may be removed."
Guest759 has joined #beagle
<zmatt> "bluetoothctl has superseded them and generally supports more functionality and newer reversions of the bluetooth spec"
Guest759 has quit [Client Quit]
<zmatt> rcn-ee: connman also messes with rfkill
<zmatt> to add to the fun
<zmatt> rcn-ee: https://wiki.archlinux.org/title/ConnMan claims "Warning: connman grabs rfkill events. It is most likely impossible to use rfkill or bluetoothctl to (un)block devices"
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt> suggesting to use connmanctl enable instead
<zmatt> sounds like a very connman thing to do :P
<zmatt> it loves to hog everything it touches
waldo323__ has joined #beagle
<rcn-ee> haha
<rcn-ee> zmatt, so maybe a little hackish.. what if we grab an un-used, but pull-ed/pull-down gpio and say that is our "switch" then move rkfill to use a gpio instead of random software state?
<zmatt> hardware block and software block are independent
<zmatt> (both need to be unblocked for the device to work)
<rcn-ee> dang it.. was hoping it would make it easier to unblock..
<rcn-ee> i should just kill rfkill in the kernel..
<zmatt> but if connman is the culprit then the fix is enabling it using connmanctl
<zmatt> (or ditching connman in favor of systemd-networkd, which is what I do on our beaglebones ;)
xet7 has joined #beagle
waldo323_ has quit [Ping timeout: 272 seconds]
calculu5 has joined #beagle
calculus has quit [Ping timeout: 272 seconds]
ikarso has joined #beagle
Stanto has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]
Duality has quit [Ping timeout: 272 seconds]
pi__ has joined #beagle
Stanto has quit [Remote host closed the connection]
mvaittin has quit [Quit: Client limit exceeded: 10000]
LetoThe2nd has joined #beagle
jkridner[m] has quit [Quit: Client limit exceeded: 10000]
akaWolf has joined #beagle
tigerxyz has quit [Quit: Client closed]
akaWolf has quit [Quit: leaving]
mastermind_ has quit [Remote host closed the connection]
akaWolf has joined #beagle
mastermind_ has joined #beagle
akaWolf has quit [Client Quit]
akaWolf has joined #beagle
akaWolf has quit [Client Quit]
mastermind_ has quit [Ping timeout: 272 seconds]
akaWolf has joined #beagle
mastermind_ has joined #beagle
akaWolf has quit [Client Quit]
Stanto has joined #beagle
akaWolf has joined #beagle
akaWolf has quit [Quit: leaving]
akaWolf has joined #beagle
mastermind_ is now known as mattb0ne
<mattb0ne> hey zmatt i get this error thrown if I try to initialize the uart more than once
<mattb0ne> raise RuntimeError( "I/O object should be closed before reinitializing UART" )
<zmatt> that's because the I/O object should be closed before reinitializing UART
<zmatt> (it should also be closed before starting PRU, so you should already be doing that anyway)
mvaittin has joined #beagle
<mattb0ne> how can I close it ?
<zmatt> with the close method? :P
<zmatt> on the I/O object
jkridner[m] has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
zero88 has quit [Quit: Client closed]
<mattb0ne> UART doesnt have a close method
<mattb0ne> AttributeError: 'Uart' object has no attribute 'close'
<zmatt> the I/O object (uart.io) does
<zmatt> (it is implicitly opened the first time you access uart.io)
<mattb0ne> ok
<mattb0ne> would a dram call from python interfere with the message streaming
<zmatt> no idea what you could mean by that
<mattb0ne> i ask because for some reason when I port to my program i lose the ability to read the position
<mattb0ne> so I map to core_0 a position variable so I can read it without launching the C code
<mattb0ne> i am wondering if that is interfering with the core_1 reading it or something
<mattb0ne> grasping at straws
<mattb0ne> there is something interfering with the position reading that is always zero when I run it within my program
<mattb0ne> works fine when I run it as a stand alone scrip
<zmatt> are you forgetting to start the decoder program on core 0 ? :P
<zmatt> mapping shared variables in python is just some administrative bookkeeping on python's side, it has no relevance to pru
<mattb0ne> i start the decoder on startup so should be running let me confirm by running my other method
<zmatt> also, you changed your code to print outside the loop that reads the messages, be sure to deal with the possibility that there are no messages at all (e.g. return) instead of printing bogus values
<mattb0ne> the force works fine
<zmatt> ok
set_ has joined #beagle
<mattb0ne> it is just the position so I know the messages are being sent correctly
<mattb0ne> just weird
<zmatt> well then presumably there's some kind of bug in your code, dunno what you're doing
<mattb0ne> yeah i am not sure how I can only partially break it
<mattb0ne> i would expect to bork it
<mattb0ne> the positive is my old way is borked as well
<mattb0ne> so it is consistent
<mattb0ne> now to find the error
<zmatt> probably just a bug in your c code then?
<mattb0ne> c code works since the python script you game me works beautifully
<mattb0ne> so the pru coding is fine for both cores
thinkfat has quit [Quit: Konversation terminated!]
thinkfat_ has joined #beagle
thinkfat has joined #beagle
thinkfat_ has quit [Read error: Connection reset by peer]
<set_> PRU!
<set_> elusive and complicated!
thinkfat has quit [Client Quit]
thinkfat_ has joined #beagle
<mattb0ne> I am not sure I cam blame the PRU
<set_> That shows how to load the .bin file to the PRU.
<set_> or .out file or whatever.
<mattb0ne> lol not doing remote proc
<set_> Oh.
<mattb0ne> i am on the uio train
<set_> Oh.
<set_> Okay.
<zmatt> and loading the binary is not the problem
<set_> Oh.
<set_> What is the issue?
Stanto has quit [Read error: Connection reset by peer]
<zmatt> once he figures that out, it'll probably no longer be one
<set_> Ha.
<set_> Have you gotten to the Linux Driver for UIO yet?
<zmatt> ?
<set_> Is there not a Linux Driver like UIO.c for Linux like w/ the RPROC?
<zmatt> what about it?
<set_> Well...I was just figuring that could be a start if not an answer.
<set_> Let me go and pretend to care more. I will brb after looking at the UIO driver.
<zmatt> set_ .. this is like telling someone who's stuck trying to solve a math problem "Have you tried using a pencil?"
<mattb0ne> would check core work with core_0 with some alteration?
<zmatt> mattb0ne: no
<zmatt> there's not really anything to check on core 0 anyway
<set_> Oh.
<mattb0ne> well I an wondering if it is stopped for some reason
<set_> You guys already referenced the uio libs and docs?
<mattb0ne> nothing to do with uio
<mattb0ne> it is just my code
<set_> Okay. Okay.
<mattb0ne> or something about my code that is not compatible
<zmatt> mattb0ne: there's nothing in the decoder program that can cause it to halt
<zmatt> once it runs, it runs
<mattb0ne> all I do in my code for core_0 is run it
<mattb0ne> so it is on
<zmatt> that's all there is to do with it
<set_> Enable, stop, and then start right?
<zmatt> set_: please stop talking
<set_> Fine.
<set_> Okay.
<set_> Can I at least reference the UIO kernel HowTo?
<zmatt> set_
<set_> Fine.
<zmatt> "Can I at least reference the pencil catalogue?"
<zmatt> NO
* set_ likes to be quiet...
<mattb0ne> its not going to help I appreciate the effort
<mattb0ne> there is a bug/error somewhere
<mattb0ne> on my side
<mattb0ne> aggrevating bug
<zmatt> set_: the kernel documentation for uio is actually almost completely irrelevant for how uio is even being used for pru
<set_> Okay. But...the simple kernel module they list may prove valuable is all I wanted to say.
<set_> Not to copy and paste it...
<zmatt> nothing you're saying is valuable in any way shape or fashion, it's just a stream of noise
<set_> Just to reference it.
<set_> Fine.
<set_> Noisy set_ is calming down now.
<thinkfat_> those bugs can be aggravating indeed, but usually i
<thinkfat_> it's a good thing to turn your own code upside down to fix it
<thinkfat_> this has often turned up other odd stuff that needed fixing :)
<mattb0ne> i am going to establish just reading with that dram map
<mattb0ne> and just add stuff until it breaks
<mattb0ne> very annoying
<mattb0ne> especially when the isolated code works beautifully
<mattb0ne> could the pins cause this
<mattb0ne> so I actually had a back up version where I was reading the position with dram mapping
<mattb0ne> like my overlay messing up something ?
<mattb0ne> I am going to make the updates and see when it breaks
<mattb0ne> does pru_initialize clear the program on the PRU
<mattb0ne> pruss.initialize
<zmatt> yes
<mattb0ne> there we go!!!
<zmatt> it initializes the entire subsystem including both cores
<zmatt> that's its entire purpose
<zmatt> what did you think it did?
<mattb0ne> i dunno but i start the decoder on core 0 but then run that so it stops the core and hence my behavior
<mattb0ne> arrrggggg
<mattb0ne> well i found it
<mattb0ne> did not seem to impact the uart though
<mattb0ne> because the force was working
<zmatt> because you did all that after pruss.initialize() I assume?
<zmatt> like, pruss.initialize() is normally the very first thing you do, like it was in your standalone script
<mattb0ne> prior to the script i did not call it
<mattb0ne> just the individual things individually like pwm.initilize
<mattb0ne> uart initialize
<mattb0ne> i guess that is how I got around it
<mattb0ne> when I merged codes I added it at the end and it wipes out my other core
<zmatt> https://pastebin.com/RNsn92i0 line 11: pruss.initialize()
<zmatt> very first thing you do with the pruss object after creating it
<zmatt> which is absolutely the correct place to do so
<mattb0ne> you are right I am just saying up until now I have not been calling it
<mattb0ne> works now
<mattb0ne> hooorrayyyyy
<mattb0ne> set_: the situation was resolved
calculu5 has quit [Ping timeout: 240 seconds]
<set_> Party at @zmatt's place!
<set_> Well, maybe not but yesssss!
<set_> I am glad.
<set_> I was performing this command to find all my /uio files: sudo find | grep uio
<set_> I found tons!
<mattb0ne> lol
<set_> I even found a program that can show off uio insides: lsuio.
<set_> So...for instance, if lsuio works on the BBB, one could use it to see uio-sysfs attributes.
<set_> I found uio_pruss.h too!
<zmatt> set_: LOOK AT ALL THESE PENCILS!!!
<set_> Fine.
<set_> @zmatt: You are so angered by how things are from my perspective.
<set_> Stop it! Stop being so blah. Be yay!
<set_> For instance, yay...set_ is here! Try that once for me.
<set_> Forget it.
* set_ goes back to the corner!
<mattb0ne> zmatt: so how fast do you think your code is generating entries messages to the queue
<mattb0ne> I have not faulted due to memory being filled
<mattb0ne> or I guess I cant fail due to that
<zmatt> the original example had a delay, once you insert your uart code the rate is entirely limited by how often those measurements come on
<zmatt> you can ring due to the ringbuffer filling up
<zmatt> *can fail
<zmatt> as discussed previously
<mattb0ne> well I havent been so I am able to consume at a fast enough clip at the current delay
<zmatt> like if you just don't handle the messages in python, it'll eventually fill up
<zmatt> well again, aren't you now synchronized to the force measurements?
<zmatt> which was the original intention anyway
<mattb0ne> yes
<mattb0ne> that is what I want
<mattb0ne> on the beagle everything is working
<zmatt> and I recall those not having a particularly high rate
<mattb0ne> now when I go to plot it seems like there is a lag
<mattb0ne> so I am wondering if my gui is just slow
<zmatt> who knows... of course if you want to make a plot you should process all messages and not skip them randomly like your script was doing
<zmatt> (as in, you were doing only one print() per batch of messages)
<mattb0ne> so when I press on the force sensor i see it on the beagle side immediately
<zmatt> I think the rate was stil over 1000 measurements per second? I don't quite remember, check your datasheet
<zmatt> or check the timestamps
<mattb0ne> right I think my gui is going to be the bottle neck
<mattb0ne> not critical
<mattb0ne> at the moment
<mattb0ne> i take it sending messages over tcp 1 by 1 is not the best way to go about it
<mattb0ne> i just leave a connection open and send as soon as i see a message
<mattb0ne> i figured that would be super quick like a print statement
<zmatt> neither is "super quick"
otisolsen70 has quit [Quit: Leaving]
<zmatt> batching helps either way
<mattb0ne> how would you determine an optimal size
<mattb0ne> every 10 or 1000?
<zmatt> with tcp you may also experience buffering, depending on how the socket is configured exactly
<mattb0ne> yeah I am going to stay away from that rabbit hole for now
calculus has joined #beagle
ft has quit [Quit: leaving]
ft has joined #beagle
<mattb0ne> so the lag is about 48 seconds
<zmatt> then data is just getting buffered indefinitely somewhere
<zmatt> which is probably just a bug
<zmatt> (in your code)
<mattb0ne> doh!
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<mattb0ne> would read_until be slow
<mattb0ne> the issue is how I send
<mattb0ne> but I only write and read once
<mattb0ne> so I am not sure where the hang up is
<mattb0ne> ok it is actually hung up on the beagle
<mattb0ne> i guess the ansyncio queue is not fast
<mattb0ne> that is where I send the message before sending
<mattb0ne> maybe i can cut it out
<zmatt> this has nothing to do with performance
<mattb0ne> what do you mean
<zmatt> like, terrible performance would be 0.1 second delay
<zmatt> that would be "slow"
<mattb0ne> lol
<mattb0ne> so just bad code
<mattb0ne> lol
<mattb0ne> ok point taken
<zmatt> 43 seconds means it's being buffered indefinitely due a bug or misunderstanding
<mattb0ne> let me post what I am doing
<zmatt> and probably being flushed out by more data or something
<mattb0ne> ok i had some asyncio awaits in there that I lowered
m-atoms has joined #beagle
<mattb0ne> now it works
mattb0ne has quit [Ping timeout: 272 seconds]