ikarso has quit [Quit: Connection closed for inactivity]
vagrantc has joined #beagle
vagrantc has quit [Quit: leaving]
lucascastro has quit [Ping timeout: 265 seconds]
thinkfat has quit [Ping timeout: 268 seconds]
thinkfat_ has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
<set_>
@zmatt: How does one add the USB client at /dev/ttyUSB0 again? I saw you describing it to someone a while back...
<set_>
It seems my AI no longer has this USB device registered at /dev/ .
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 256 seconds]
johanhenselmans_ is now known as johanhenselmans
<set_>
is this the command: modprobe usb-storage ?
<set_>
mknod ?
<zmatt>
???!?
<set_>
I used mknod.
<set_>
It worked.
<set_>
Hmm.
<zmatt>
what
<zmatt>
no?
<set_>
Oh.
<zmatt>
don't use mknod, ever
<set_>
Okay.
<zmatt>
whatever you think you accomplished, you didn't
<set_>
Why should I never use it?
<zmatt>
it has no use on current linux systems
<set_>
Oh.
<set_>
Okay.
<set_>
Fine.
<zmatt>
(that's an oversimplification, but a good enough rule for most people, and certainly you)
<set_>
Okay.
<set_>
I understand.
<zmatt>
there's no reason for a /dev/ttyUSB0 to exist on a beaglebone
<zmatt>
ai or otherwise
<set_>
Hmm. It is. I just installed the image and now it is not on it.
<set_>
I have a webcam plugged in...
<zmatt>
a webcam doesn't show up as a /dev/ttyUSB* device
<set_>
Right.
<zmatt>
only usb serial devices
<set_>
Right. Plus, I already used mknod /dev/ttyUSBn c 188 n .
<set_>
Oops.
<zmatt>
that will create _a_ device, one that will do nothing
<set_>
Right. I found that out.
<set_>
It seems trying udevadm does not do what I figured it would do either.
<set_>
Maybe a reboot will do it.
<zmatt>
dev nodes get created automatically, and if they don't then the problem is never solved by manually creating them, which is what I meant by saying mknod is useless now
<set_>
I get it. Okay. No issue.
<set_>
So, mknod is useless now.
<set_>
Okay.
<zmatt>
if a usb device isn't showing up there's either a problem with the usb port, the usb device, the cable, or a driver issue... checking kernel log may (or may not) be useful in figuring out which
<set_>
Off to check.
<zmatt>
of course that's assuming you plugged something in that would show up as an usb serial device... so far you've only mentioned a webcam, which is not one of those things
<set_>
It shows up.
<set_>
lsusb makes it show up.
<zmatt>
lsusb doesn't make anything show up, it just checks what's there
<zmatt>
if it wasn't there and then it was, then the thing that made it appear was simply waiting a bit
<set_>
I am in journalctl right now and digging. I tried dmesg | grep 25
<set_>
I got nothing of use.
<set_>
Notta.
<set_>
MAKEDEV ?
ikarso has joined #beagle
<set_>
oh.
<set_>
it should show up as /dev/video0?
<set_>
anyway...too late to illustrate. On another day!
javaJake has quit [Ping timeout: 252 seconds]
vd has quit [Quit: Client closed]
vd has joined #beagle
javaJake has joined #beagle
rob_w has joined #beagle
vd has quit [Ping timeout: 256 seconds]
<johanhenselmans>
zmatt: I had a level shifter already added on a connecting cape between beaglebone and the main PCB, so it was already there. I just wanted to test the 13487 separately, as the RS485 transceiver I had used on the previous prototype was not available any more…
CrazyEddy has quit [Ping timeout: 240 seconds]
<zmatt>
okay, have you checked that the RE pin is pulled high? (e.g. connected to VCC)
<zmatt>
or if connected to a gpio, make sure the gpio is driven high... but there's probably no reason to connect RE to a gpio
otisolsen70 has joined #beagle
CrazyEddy has joined #beagle
sicelo_ has joined #beagle
florian has joined #beagle
sicelo_ has quit [Quit: Bye!]
sicelo_ has joined #beagle
sicelo_ has joined #beagle
sicelo_ has quit [Changing host]
lucascastro has joined #beagle
Shadyman has quit [Remote host closed the connection]
sicelo_ has quit [Quit: Bye!]
<johanhenselmans>
I have tried that, via the settings in the python script, where RTS was supposed to have that function via GPIO48 (p9.15), but that did not work. I’ll setup the levelswitching etc in about half an hour, see if everything (p9.26…) is still OK.
buckket has quit [Quit: buckket]
buckket has joined #beagle
<zmatt>
johanhenselmans: well, when rs485 uses the RTS pin it's generally for direction-control, which you don't need with this transceiver since it switches direction automatically
<zmatt>
I don't really see any use for RE so I'd just connect it to VCC
<johanhenselmans>
OK, will do, See what happens.
Konsgn has joined #beagle
vd has joined #beagle
otisolsen70 has quit [Quit: Leaving]
rob_w has quit [Remote host closed the connection]
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
<Konsgn>
Weird question: is there an alternative to ext4write to override the uEnv.txt file with a backup if you have metadata_csum enabled?
xet7 has joined #beagle
<Konsgn>
I am trying to override the boot/uEnv.txt with a backup copy that boots correctly.
<Outrageous>
hmm...what type of beagle is it; are you not able to boot with a sd card and just mount the emmc and modify it that way?
<Outrageous>
Konsign: That last line was for you, forgot to put your name in front.
florian has quit [Quit: Ex-Chat]
Guest54 has joined #beagle
Guest54 has quit [Client Quit]
<Konsgn>
not really a beagle, but based on pocketbeagle, more of a if your device tree overlay fails and you are in uboot shell, how do you disable an invalid overlay callout from uEnv.txt when your ext4 partition has metadata_csum enabled
<Konsgn>
I can just pull sd, no problem, more of a I wanna find a lazy quick way of overwriting the uEnv.txt
<zmatt>
Konsgn: if you're in the uboot shell, just boot the image manually with good parameters
<Konsgn>
hmmm, alright, gunna look into that now.
<zmatt>
Konsgn: like, this is what I'd typically use, but note that this doesn't apply any overlays and doesn't use initramfs: https://pastebin.com/nt8FcL29
<zmatt>
also, this is for eMMC so for sd card you'll need to change "mmc 1:1" to "mmc 0:1" and mmcblk1p1 to mmcblk0p1
<Konsgn>
sweet! thank you!
<zmatt>
I also haven't done this on any remotely recent u-boot ;)
vd has quit [Quit: Client closed]
vd has joined #beagle
xet7 has quit [Quit: Leaving]
otisolsen70 has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 245 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
Konsgn: did it work?
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 268 seconds]
<Konsgn>
nope
<Konsgn>
fell back to pulling card
<Konsgn>
got far in the process, but i think the dtb variable got corrupted somehow
<zmatt>
like my comments said, "run findfdt" after loading /boot/uEnv.txt should fix it
<zmatt>
oh my comments didn't say that
<zmatt>
ah my comment was right I think
<Konsgn>
haha will try that shortly, I'm sure i still didn't get this right
<zmatt>
(I've only included the parts that matter in the typical boot flow used on bb.org images, not legacy stuff or things like extlinux or netboot)
<Konsgn>
hahah
<Konsgn>
this worked great, difference is when you paste in powershell-> armbian->screen-> blackmagicprobe acm port-> sitara uart0 using the right mouse button, a bunch of garbage gets sent to the command line
<Konsgn>
mattb0ne, you can try to run wireshark on computer receiving the data.
<Konsgn>
yup..
<zmatt>
I doubt wireshark would be useful here
<Konsgn>
might allow you to see if packets were dropped or never came out in first place?
<zmatt>
mattb0ne: pastebin the relevant code?
suy|m has joined #beagle
<mattb0ne>
ok
<zmatt>
Konsgn: almost certainly neither and neither
<mattb0ne>
lol
<mattb0ne>
give me 2 secs
<zmatt>
Konsgn: are you trying to use a custom overlay?
otisolsen70_ has quit [Quit: Leaving]
<Konsgn>
yup, writing one
<zmatt>
Konsgn: most common problem is a label-reference (&foo) to a non-existent label
<zmatt>
if u-boot can't resolve a reference you get that error (with no mention of which reference it was trying to resolve, and it also doesn't merely fail to apply the overlay but borks the entire DT)
mattb00ne has joined #beagle
<Konsgn>
yea hence the help bypassing uEnv.txt. mer disabling large blocks now.
<mattb00ne>
i was printing the time step from this function where I noticed the discconnect
shoragan[m] has joined #beagle
<Konsgn>
hmmm. do i have to use the name bb_spi0_pins... what if i renamed it to spi0_pins in the &spi0 pincallout as well as the %am33xx_pinmux overlay
<Konsgn>
matt... udp might be better suited no?
<zmatt>
Konsgn: if you boot without the offending overlay you can check whether it references any non-existent symbols: if you decompile the compiled dtbo with dtc -I dtb -O dts path/to/file.dtbo its external references are the names of the properties in the __fixups__ section, and all of those should exist in /proc/device-tree/symbols/
<zmatt>
I wouldn't use udp no
<Konsgn>
matt, nvnm
<Konsgn>
ahh theres 2 of you
<zmatt>
Konsgn: and you can name pinmux nodes whatever you want
<zmatt>
Konsgn: I generally give the pinmux node the name of the peripheral since the name of the node only needs to be unique within &am33xx_pinmux ... adding -pins to it or whatever is redundant since it's already a child node of the pinmux controller
<zmatt>
while the label (spi0_pins: / &spi0_pins) needs to be globally unique in the entire DT hence it needs the _pins suffix
<zmatt>
mattb0ne: I'm confused, is that first function just irrelevant?
<zmatt>
continuing on an IncompleteReadError makes no sense, your stream will be gone and you'll get the same error in an infinite loop
<zmatt>
other than that I don't see an obvious problem with this, as long as whatever data_link.transmission.emit(val); does doesn't take an excessive amount of time
<zmatt>
processing the received data in larger batches than single messages can probably help efficiency
<zmatt>
mattb0ne: what about the sender?
<zmatt>
oh I see you've sending a qt signal
<zmatt>
mattb0ne: keep in mind you're getting 1200 messages per second iirc, you're not going to want to try to update any user-interface at that rate probably
<zmatt>
also, if you're comparing with back when you still had filtering enabled, if I understand the manual correctly that will have limited the rate to 600 messages per second, so compared to that you now have double the rate. it's still not a problematic amount of data but that's contingent on not processing the data in too stupid a way ;)
<mattb0ne>
your right
<mattb0ne>
i will pastebin your sender
<mattb0ne>
i have way more since I filtering quite heavily before
<zmatt>
?
<mattb00ne>
the digitizer settings
<mattb00ne>
it was probably was slowing up my stream. I notice the slow down right when data gets recieved here so I have not done much yet
<mattb00ne>
the stream function you have works fine though
<zmatt>
how "heavy" you filter (i.e. which IIR filter is selected) does not affect the output rate, other than that having filtering enabled reduces the output rate from 1200 to 600
<mattb00ne>
i have no filter just averaging
<zmatt>
that is a filter, just a bad one
<mattb00ne>
lol
<zmatt>
"the stream function you have works fine though" ? I'm not sure what you mean
<zmatt>
and how exactly do you 'notice the slowdown' ?
<zmatt>
if you're updating the user interface on every message, i.e. 1200 times per second, then that's a pretty plausible candidate for being the _cause_ of the slowdown
<zmatt>
user interface updates should be rate-limited
mattb00ne has quit [Ping timeout: 240 seconds]
diekman_lab__ has joined #beagle
<diekman_lab__>
here is what sends the data based off your code
<diekman_lab__>
so the print line that shows the data changing is fine
<diekman_lab__>
so that is what I mean when I say the beagle bone stream is ok
<diekman_lab__>
but I cannot even do a simple printing of the bytes now for some reason
<diekman_lab__>
i did change linux environments
<diekman_lab__>
but that should not degrade anything right?
<diekman_lab__>
i know I can bog it down with gui stuff but I turned everything off and if I just do a print statement I notice the slow down and it is immediate
<diekman_lab__>
so it has to be a coding error or a environment problem
<zmatt>
oh this sender looks pretty bad
<diekman_lab__>
what do you mean
<zmatt>
what's with the delays?
<zmatt>
also, calling drain after every 27-byte message is going to make things extremely inefficient
<diekman_lab__>
well if I am not sending anything I do not want to bog down anything \
<diekman_lab__>
I have two connections one for single commands one for streams
<zmatt>
which is why you should use data_queue.get() which will block your emitter
<zmatt>
if the queue is empty
<zmatt>
except you shouldn't use queue but something designed for asyncio
<zmatt>
I'll see if I can suggest a fix for this terribleness when I'm done eating :P
<mattb0ne>
lol
Konsgn has quit [Read error: Connection reset by peer]
<zmatt>
mattb0ne: if your intention is to buffer data unboundedly, which is what you're doing right now with the queue, then you may as well do away with the queue and just call writer.write(data); directly instead of pushing onto the queue
<zmatt>
then you'll use the stream's write buffer to queue the data
<mattb0ne>
oh
<mattb0ne>
so just write as soon as i get it
<zmatt>
well, gathering messages into batches will be a lot more efficient, but that aside
<mattb0ne>
ok
<zmatt>
just calling write will be already way more efficient than putting each message into a queue, having a coroutine fetch it from that queue (with weird polling and delays), write it to the socket, and then drain() for each message
<mattb0ne>
so the documentation says I should drain after each write
<zmatt>
no it doesn't
<mattb0ne>
if I batch I would have to have some sort of buffer on the computer side
<mattb0ne>
i guess
<zmatt>
if multiple messages are available in the ringbuffer, you can send a whole bunch with one .write()
<mattb0ne>
i think the way I have it I send one data set over at a time
<mattb0ne>
ok
<mattb0ne>
will give it a shot
<mattb0ne>
will need to change my receiver to handle a batch
<mattb0ne>
make that ring buffer on the receiving side
<zmatt>
the documentation says write "should be used along with the drain() method" ... in the sense that write() doesn't block and always buffers data, so if you don't drain then the amount of data buffered can grow without bound... but right now you have a queue that can grow without bound
<zmatt>
batching on the sender side has zero impact on the receiver
buzzmarshall has joined #beagle
buzzmarshall has quit [Client Quit]
<zmatt>
now, the receiver can also benefit from using batch processing, but that's a completely independent decision
<zmatt>
on both side these are just implementation details, the wire protocol doesn't change
<mattb0ne>
well let me add batch sending side and see where I am at
<zmatt>
start with just doing the write() directly
<zmatt>
since the write buffer will in some sense already do batching for you
<mattb0ne>
and just ditch the drain
<zmatt>
yes
suy|m has quit [Write error: Connection reset by peer]
mvaittin has quit [Read error: Connection reset by peer]
shoragan[m] has quit [Read error: Connection reset by peer]
<zmatt>
btw why is recv_messages() an async def?
<mattb0ne>
not sure
<zmatt>
it shouldn't be one
<mattb0ne>
ok
shoragan[m] has joined #beagle
RossSchulman[m] has joined #beagle
jduchniewicz has joined #beagle
mvaittin has joined #beagle
suy|m has joined #beagle
<zmatt>
what does _Count_to_angle do?
<zmatt>
and why uint32(msg.position) ? isn't msg.position already an uint32 ?
diekman_lab__ has quit [Ping timeout: 260 seconds]
<zmatt>
also why use \r as separator instead of \n ? that seems like an unusual choice
shoragan[m] has quit [Quit: Client limit exceeded: 20000]
RossSchulman[m] has quit [Quit: Client limit exceeded: 20000]
mvaittin has quit [Quit: Client limit exceeded: 20000]
jduchniewicz has quit [Quit: Client limit exceeded: 20000]