**** BEGIN LOGGING AT Fri Jul 19 02:59:57 2019 Jul 19 15:09:31 m Jul 19 16:09:48 Hi all - my PC is connected to my beaglebone blue over USB. What is the method to check my blue's wifi AP name while I'm connected by USB? Jul 19 16:31:21 To put it properly I am looking for my beagle's wifi SSID Jul 19 16:43:30 it's "BeagleBone-wxyz"... run: journalctl | grep wl18 Jul 19 17:02:33 Thank you, Registered Certified Nurse - Electrical Engineer, it works! Jul 19 17:02:51 ( guess this is what rcn-ee means) Jul 19 18:14:07 Hello dear people, Jul 19 18:15:53 I am trying to gather factor favoring a beaglebone over RPI4 on beagleboard.org and i find that site to be a little dusty. What is going on? TI dropped BeagleBone as an entry platform? Jul 19 18:16:29 no Jul 19 18:16:44 also it depends on what you want to do Jul 19 18:18:50 mmoebius: BeagleBoard.org isn't controlled by TI.. Jul 19 18:20:44 @rcn-ee: I know Jul 19 18:20:51 ¯\_(ツ)_/¯ Jul 19 18:21:20 mmoebius: if you know why state it? Jul 19 18:23:01 I am a little dumbstruck on what my actual problem is; Actually everythin I neet to make use of a BB is there, however i find the beaglebone site alarmingly "somewhat stale" (sorry, lacking a better word) and no, I do not mean "add more CSS" ;-) Jul 19 18:23:53 what we don't waste money on teh website, everyone is working on useful things, kernel/default image/etc.. Jul 19 18:24:04 My research problem is how to feed video to two 1920x1080 full-hd displays,, probably via HDMI (I have not yet been told why; preparing my pitch) Jul 19 18:24:11 patches welcome, the source is on github.com/beagleboard/ Jul 19 18:24:32 the BBB has one HDMI output Jul 19 18:24:41 1080p, yeah use a pi.. Jul 19 18:25:34 there's *one* thing that those Broadcom VideoCore4 SoCs are good at is media decoding. Jul 19 18:31:09 My point usually bangs on the RPI long-term support, availability of the SoC chip if we wanted to roll our own and documentation. So far that has always scored Jul 19 18:32:15 in favor of the BB of course :-) Jul 19 18:36:12 Ok, here is my one point of pain for me: look at http://beagleboard.org/beagleboard-xm , lower right , projects -> "LVDS LCD add-on board" which lands you on http://beagleboard.org/project/LVDS+LCD/ . Dead, stale, gone. Disheartening for me in every regard. Jul 19 18:36:38 I mean like in "discouraging the entire ecosystem" Jul 19 18:45:04 re Jul 19 18:47:16 please excuse me, my connection dropped half-dead. Now using a slightly more sincere IRC client. Has anybody the messages since ~18:30 for me ? Jul 19 18:48:00 Btw, the IRC logs on https://beagleboard.org/chat (or bbb.io/chat , from the channel title) seem to end in ca. 2017 :-/ Jul 19 18:48:17 the XM is not a bone, also it's probably really hard to get hold of by noew Jul 19 18:48:19 now Jul 19 18:50:31 Oh, i got hinted on the XM by digikey, they have some 400 or them for grabs: https://www.digikey.de/product-detail/de/precision-technology-inc/BEAGLEBOARD-XM/1777-1000-ND/6834153 Jul 19 18:57:54 ok, well, just keep in mind that the SoC on that is by now about 10 years old and I don't think it will do 1080p, 720p probably Jul 19 19:17:06 that is exactly what I mean by "stale look". And that is no good advertisement. Jul 19 19:20:29 Any hints for me on supplying e.g. two displays at 1920x1080 in the BB universe? I lost a little track on developments as I have actually dug somewhat deep in the BeagleBoneBlack and that is a /working horse/ ! I cannot overstate the success I have with it. Jul 19 19:22:00 you seem to be under the assumption that beagleboard.org is a for profit like the makers of RPi. That is not the case. Jul 19 19:22:33 the XM is listed for historic reference Jul 19 19:23:02 removing information just because "it's not from yesterday" leads to loss of knowledge Jul 19 19:23:17 mmoebius: get a pi 4 it has dual displays.. Jul 19 19:26:24 or if you're building a product, buy a SoM with availability guarantees Jul 19 19:29:04 rcn-ee: you on the wrong channel ? Jul 19 19:29:30 I am trying to see if the BeagleBone ecosystem has got anything to offer that goes near dual video. May even only display static buffers. Anything. Jul 19 19:30:23 use X to extend the display to a second unit? That is the most straight forward I can think of. IE network access and add a network X display. Jul 19 19:33:13 oh … many BBBlacks , one each per screen, acting near-simultaneous by software link; with possible stand-alone failover if the software inter-link fails :) sweet. Jul 19 19:37:39 I've got a user process that talks to a device via a USB-UART. It works well, even at 500kbaud. However, every now and then it sends the first byte or two of a packet and then pauses for about 5ms before sending the rest Jul 19 19:38:37 I guess there are other ways to do it, but I wonder if I could just renice the process to be lower than whatever's doing that. Jul 19 19:38:57 tbr: Sorry for being ignorant of developments. SoM with multiple video out? Could you give me an example? Jul 19 19:39:22 any idea what it might be ? The only other thing I'm running that isn't common infrastructure stuff is mosquitto Jul 19 19:41:22 artaq: usb slot time is 1ms, at usb 2.0 Jul 19 19:42:11 artaq: could it be that your usb-host does not properly fill the USB->UART dapters buffers ? Jul 19 19:43:51 could be. but the paused packet just pushes out one or two characters (I think that might be what the write() call does to start with) then waits 5ms before more comes. And it only happens some of the time Jul 19 19:44:46 I mean, it might write() the start-of-packet, then the rest. But in most cases, it all comes ouit the other end in one go Jul 19 19:45:50 artqg: What may happen is that there were x bytes transferred in n usb Buffer round-trips, arbitrarily chopped some software to include only those "one or two" bytes. Then the USB->UART device says "buffer full" (however few bytes that may be). Unfortunately the USB->UART device is sending fast, then stalls. until USB Signallin kicks in with 1 ms per Host-Device sommunication at best, an the host knows "buffer low", "sending new buffer" Jul 19 19:45:50 5ms have easily elapsed unless that would be hand-tuned i guess. Jul 19 19:46:37 artag: What is your SoC ? The BB Black eg. has like 4 or 6 RS232 Uarts, all easily faster than 500 kBaud Jul 19 19:46:49 it's not streaming, though. the protocol is stop-and-wait, so new stuff isn't started until the previous transfer is done Jul 19 19:46:54 (i would have to look that spec up) Jul 19 19:47:50 it's the BBG wireless. But I'm using USB because I wanted to be able to drop in a faster processor board if I needed, I'm not using much that's specific to the BBG Jul 19 19:48:15 artag: it ist not streaming as smoothly as you'd hope. But RS232 is for exactly that reason synchronized on the "start bit" of every byte, creating at least 25% overhead. Jul 19 19:48:32 artag: What is your actual problem ? Jul 19 19:49:19 Not much. I can fix the problem by making sure the receiver doesn't time out if it detects start-of-packet then quiet for 5ms. Jul 19 19:49:44 But I'm curious as to what makes the processor busy for 5ms every now and then Jul 19 19:49:58 it's mostly idle (about 20% busy) Jul 19 19:52:23 artag: I took a quick look on the BBBW schematic. It has at least UART 1,2 and 4 on P9 and Uart0 on the debug Port. Anything wrong using these ? Why an USB->UART Adapter ? Jul 19 19:53:51 artag: Do you see a spike in CPU load on the 5ms interval ? How do you even monitor down to that granularity? Jul 19 19:56:05 I generally think of USB as being efficient because of the built-in buffers. Maybe the BBB has big fifos, I'm not sure. USB is also differential signalling, I'd need a lot more circuitry to get that, and as I say it would prevent me dropping in a Pi or even a PC Jul 19 19:56:25 no, I don't know if I can monitor CPU to that level Jul 19 19:57:17 definitely a bit late for me to change, too :) Jul 19 19:58:59 artag: may I quote you on "I can fix the problem by making sure the receiver doesn't time out if it detects start-of-packet then quiet for 5ms." -- that looks little a critical design to me. RS232 by itself can hang loooong time between bytes. 5ms @ 500kBaud 8N1 (assumption) is just 250 character times. With inter-process scheduling on (I assume: linux kernel) you are into several 10ms, should the other process hang on some hardware like Jul 19 19:59:00 an emmc write or something. Jul 19 20:01:12 artag: USB->UART built-in buffers? What do you assume there any where does your assumption come from? Take a look at lsusb -v | grep wMaxPacketSize to get an estimate. Jul 19 20:02:15 artag: Also, USB is very overhead intensive compared to actual uarts. You need differential signalling … where?… USB is differential, yes, but you mean the UART part, no? Jul 19 20:04:27 Obv. I could put RS485 opn the uarts, but that's a load of work. Jul 19 20:04:51 my assumption about bufffers is that the USB-UART device in the peripheral has them Jul 19 20:05:11 artag: Next: The on-SoC UARTs of the BBB interrupt more or less directly to the CPU with a rather direct path, if data is required that is a quick back-and forth from interrupt handler to driver to but the next byte on the sending line. Very very little cpu overhead Jul 19 20:05:54 artag: That is an assumption. Any foundation for your assumption? It could be wrong. Or not-right to the degree you want. Jul 19 20:06:31 Anybody knows off-head if the Sitara SoC does DMA on the UARTs ? Jul 19 20:07:27 artag: again, you did not describe your entire problem to me. You are doing RS485? RS422? Full or half-duplex? Jul 19 20:09:32 artag: b/c RS485 full-duplex at 500kBaud would kind-of require cpu intervention to get the rx/tx scheduling right and over USB that incurs several of those nasty 1ms USB round-trip interval times per cycle. Jul 19 20:10:59 I'm doing a serial protocol to an arduino-based peripheral at 500kbaud. It connects via USB, a CH340 USB-uart chip, and an atmega328. No actual RS232 or RS485 involved, but there are some motors involved on other peripherals. I'm glad to have differential signalling on the USB links Jul 19 20:12:01 But packets are only exchanged at about 5ms intervals. Then protocol is half-duplex Jul 19 20:12:44 so there IS a TTL-async connection but it's internal to the arduino Jul 19 20:13:01 and I might well swap that atmega for a 32u4 Jul 19 20:13:33 or maybe a teensy 3 Jul 19 20:16:29 artag: Do you have any sensible datasheet on CH430 beyond https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF ? Jul 19 20:17:17 no, I don't know how big the fifo is. But the pause in the data doesn't seem consistent with that refilling Jul 19 20:21:12 artag: is the protocol straight rx/tx/… ? and can you influenct the data size sent ? Jul 19 20:21:36 it might not be much of a hardware fifo - but the USB packet buffers perform a similar function, protecting the beagle cpu from the interrupt load Jul 19 20:22:04 artag: maybe there is a critical packet size? Jul 19 20:22:17 yes, I can influence it. Its a simple protocol and mainly limited by the uart rx buffers in arduino lib, which are very small Jul 19 20:24:05 no, it's the timing that's the issue. I've watched it on the logic analyser. Plenty of normal packet-reply stuff, then one packet is sent in fragments with a gap. Initially, that created a protocol error but with a longer timeout it's fine Jul 19 20:24:13 just would like to understand it Jul 19 20:24:33 it seems far more like something makes the beagle busy for 5ms Jul 19 20:28:40 artag: can you look directly at the usbserial driver? E.g. kernel probe or (my dumb way: self-compiled version with high precision time stamp) and thus log when it fills the data you intent to see into the URBs ? Jul 19 20:29:45 possibly. looking fopr a simpler explanation first :) Jul 19 20:30:51 artag: That something makes a 1 CPU multi-tasking system busy for more than 5ms is not actually unexpected. Many moons ago, the default "cycle time" (process-process) was 100Hz or 10ms in default Linux kernels. Jul 19 20:31:27 So if anything gets the CPU it can keep it for 10ms. (beside interrupts) Jul 19 20:37:10 artag: so let me guess again, after you got a Packet, your program on the BBBW must schedule a new packet? … and now what, is TX answer that one big write from the program to the device (i assume usbserial) ? Jul 19 20:39:50 mmoebius SoM System On Module like the embedded PI there are a number of vendors of such. Jul 19 20:42:49 GenTooMan: could you give me specific link to an example? Jul 19 20:45:57 mmoebius https://www.compulab.com/products/computer-on-modules/ https://www.variscite.com/products/system-on-module-som/ for example? Jul 19 20:47:12 GenTooMan:thank you very much. That gets me something to chew into. Jul 19 20:48:59 mmoebius there is a raspberry PI board that does the same kind of thing except it has 1 display :D Those are designed less to be toys and embedded into something. Jul 19 20:50:11 And I think I will of course not want that SoM to have an Sitara AM3558 SoC on it because that SoC, goot on the BBB as it may be has such a 'limited' graphics capability. :) Now my thoughts get somewhere. Jul 19 20:50:31 thank you Jul 19 20:50:42 mmoebius: no, afaicr it does a series of small writes in order to character-escape the packet contents. Could be more efficient, but certainly makes it possible that part is in the kernel buffer and they're all sent while the process gets outscheduled Jul 19 20:53:20 difficult to know if that's a good thing. after all, by doing small writes, the packet gets started. If I saved them up, nothing would be sent until it was all ready Jul 19 20:53:56 optimising that is a job for when the rest is working :) Jul 19 20:59:11 mmoebius you can still get panda boards they have dual HD HDMI output however getting software to use them is a different matter. Jul 19 21:01:24 artag: if the program makes small writes and then you wonder? If that first write comes through, places one or two bytes (who knows?) to the usbserial system, than USB does its things (we are talking several round-trips of 1ms here) and then another program gets scheduled and boom there is your "hiccup". enough explanation? Jul 19 21:02:19 artag: set the writeing program's nice level lower and set ionice, too (!) Jul 19 21:03:18 well, exactly. that's my assumption. But what I wonder, is *what* else is busy. So I can see what that's niced at Jul 19 21:04:09 in most cases, there's enough in the kernel buffers to keep USB full. But occasionally, there isnb't Jul 19 21:10:48 GenTooMan: hte panda board looks good too. I wonder what they boondoggled on the silk-screen naming the con connector "DVI-D" and the other one "HDMI". whatever. Thanks for the hint. Jul 19 21:17:25 artag: that boils down to a general question on linux scheduling then; I reach shallow waters here. Usually on linux systems every thing is a t default nice levels 0 except for a few kernel worker processes. ionicenes I would expect at 0 for everbody too. Jul 19 21:19:28 Why not just slam the gas on your process and renice it to -20 first Jul 19 21:20:08 yeah, worth a try. It's not failing at the moment so not much help :) Jul 19 21:21:26 but it's not completely general. My first stop was to ask here in case there's something the BB does that would explain it Jul 19 21:39:49 artag: still: why on earth USB between a CPU and its UART? do aouc have interference problems from the ATmega328 to the BBBW ? Jul 19 21:44:31 because when I started this (it's a small robot with sensors and motor drives as separate modules) I didn't know whether I'd need a vision system. If I did, I'd want a more powerful cpu than a BB - perhaps a multicore pi. but I'm unconvinced of the reliabilty of the pi, so I wanted to use a generic cpu and not use any special features - if I needed to use something else I could leave all the peripherals the same and just change CPU Jul 19 21:45:41 sure, I could use more efficient links. I fact, I could put the sensors (that are on this board) straight on i2c and the motors straight on pwm Jul 19 21:45:58 but then I'd be locked into the bbb Jul 19 21:46:41 admittedly I could have just left the bbb in as a hardware controller and used a separate board for vision Jul 19 21:47:14 artag: staying on TTL, running RS232 and if your ATmega328 runs on 3.3v you even get away without level vonversion Jul 19 21:48:05 yeah. but then I have 3,3v single ended signals running near 8A PWM motor drives :( Jul 19 21:48:12 artag: For long time use (at least what I used to work with) USB-Connnectors have always been victim to dirt and vibration. Jul 19 21:48:38 USB isn't great at noise immunity but it's better than that. Jul 19 21:48:56 it's not a dirty environment. Vibration .. yeah maybe Jul 19 21:49:00 glue gun :) Jul 19 21:49:33 it's a pretty low-performance robot Jul 19 21:50:44 artag: then use an opto couplers. They still work at @500kBaud. and not expensive. Jul 19 21:51:32 but then I need custom pcbs. USB uses cots boards everywhere Jul 19 21:51:38 If that PWM noise leaks along some lines you would be up for external Radio Frequency Interference anyways. Not good for CE or FCC. Jul 19 21:52:00 meh. don't care about FCC Jul 19 21:52:05 it's a one-off Jul 19 21:52:22 artag: you are lucky ;-) Jul 19 21:52:47 yeah, i've had enough of products and type-approvals Jul 19 21:52:55 do specials :) Jul 19 21:53:06 no paperwork ! Jul 19 21:53:34 approvals for the FCC aren't too bad. Now for things like MSHA and the FDA THOSE are nasty. Jul 19 21:53:55 i don't even want to think about the FDA Jul 19 21:54:01 artag: have you seen the PWM noise interrupt your RS232? Because 3 wires from BBBW to atmega saves a lot of hardware, power, software (drivers) and hiccups. Jul 19 21:54:12 no ... no you really don't. Jul 19 21:55:10 artag: Also, like just don't route your RS232 wrapped around the PWM power path? Maybe? Jul 19 21:56:39 With 3 Phase 400V frequency drives, RS422 + optical isolation was my way to go until that moved to ethernet. over fibre Jul 19 21:57:16 mmoebius: but you're missing the point of the USB. It's a one-off. No prototype development. The one I build gets shipped (maybe I build a spare). I don't run USB next to power lines but equally, I don't want to spend a week debugging a noise problem. But I have no way to estimate CPU load. Jul 19 21:57:40 This way, if I find it's too high, I drop the beaglebone and stick in a NUC Jul 19 21:57:42 easy Jul 19 21:57:57 just move some USB plugs Jul 19 21:58:52 I need a vision system .. I grab a pi with a camera and stick it on as a peripheral. Or move the main processing to it Jul 19 22:00:23 and if one is on the ttl level: differential driver = 1…4 inverters depening on fancyness. Rx = xor + rc-low-pass, done. But that is rather a last resort I'd say after some simple physical path separation, maybe a ferrite bead an rx-side-wise (on both RS232 lines) an RC-lowpass does not help Jul 19 22:00:23 sure, USB sucks for realtime systems. This robot moves slowly around an art gallery and stops a lot. It's got an MQTT (not ROS) data spine and an update rate of about 50ms Jul 19 22:02:17 artag: I see. Saved time using USB. Did the quick and obvious. Welllll… :headscratch: Jul 19 22:03:36 artag: Can you try swapping the usb->UART converter for a PL2303 or FTDI... ? Jul 19 22:03:41 now, if I wanted a 1ms cycle time I wouldn't consider it for a moment Jul 19 22:05:06 artag: The thing is the crazy overhead of USB and its inherent unreliability. That is what I hate it for since it was invented. "If that hangs just unplug and replug - customer: OK" c r a p engineering Jul 19 22:05:28 yeah, I might try an ftdi. But it's a bit moot - I can go to a teensy. Only problem is, it's far harder to watch the protocol noninvasively with a cheap LA Jul 19 22:05:37 yeah true Jul 19 22:07:11 Not to mention that at least the USB2.0 spec involved a lot of input from Microsoft in the evil "Some people do not like Microsoft, but why?"-years of like 1994-1999 Jul 19 22:08:05 artag: which is harder to watch ? Differential? Jul 19 22:08:08 for a system with scale, I'd rather use ethernet. This isn't that system. Jul 19 22:08:46 USB speeds and the extra protocol depth. I don't have a LA that can unpick 480MHz USB Jul 19 22:08:51 artag: absolutely. or CAN Jul 19 22:09:03 I don't much like CAN Jul 19 22:09:09 artag: And that is the very matter why usb stinks. Jul 19 22:09:13 packets are too small Jul 19 22:10:20 fine for data but when you have to send a file to your peripheral it sucks Jul 19 22:10:28 been there, done that Jul 19 22:10:58 8-byte frames with an 8-packet window :( Jul 19 22:12:40 interestingly, after running this protocol for half an hour without getting it to fail (I changed back to a 5ms timeout which provokes a failure) it only broke when I niced the protocol handler down :) Jul 19 22:12:59 artag: look at lsusb -v to see if the device even talks at 480 MBit. The 2.0 standard comprises low speed (irrelevant here) full speed (12 mbit iirc) and high speed 480 mbit (unlikely for those cheap connectors). And you'd need something to unknot the USB line coding. Jul 19 22:13:53 true, the usb uarts probably only go at 12M Jul 19 22:14:54 I could sniff it with wireshark but then I'd get heisenbugs Jul 19 22:15:19 prefer an external sniffer Jul 19 22:16:06 artag: maybe look into Linux Kernel high precision time debugging? Maybe something with KProbes? The Kernel sees it all: USB transfers, the serial writes. Taht should make it clear Jul 19 22:16:39 yeah. something for another day Jul 19 22:17:17 Local clock displays bed-time. Thank y'all and keep the good stuff going. Jul 19 22:17:18 but the kernel can't watch it all without slowing itself down Jul 19 22:17:26 night Jul 19 22:17:33 thanks for the chat Jul 19 22:17:37 artag: KProbes are said to be very cheap **** ENDING LOGGING AT Sat Jul 20 02:59:56 2019