**** BEGIN LOGGING AT Thu May 07 02:59:57 2020
May 07 07:37:30 <Mari72> Hi, I am new with BBB, I have a question : I would like to control a analog Valve, via USB - Rs232
May 07 07:38:30 <Mari72> What I should to du to configure the BBB USB, that it can control this Valve
May 07 07:40:19 <Mari72> The cable is USB in BBB side and the Rs232 in the Valve side
May 07 07:42:15 <Mari72> Can anyone help me?
May 07 07:45:31 <rob_w> Mari72: well if you plugged a usb2rs232 converter , you should recieve your /dev/ttyUSB0 such
May 07 07:48:17 <Mari72> Yes
May 07 07:48:56 <rob_w> well then now your talking to your"valve" and you can write to this dev your valve protocol
May 07 07:49:49 <Mari72> @rob_w : should I configure the Rs232 protocol?
May 07 07:50:56 <Mari72> Without configuration?, can I just Wright my Rs232 protocol?
May 07 07:52:02 <rob_w> well if you baudrate etc match , yes
May 07 07:52:30 <rob_w> of course you need to setup your rs232 so the valve reads you .. baudrate, stopbits etc
May 07 07:54:29 <Mari72> Should I setup the Rs232 outside my protocol?
May 07 07:55:10 <rob_w> u dowhat suits u best
May 07 07:55:38 <rob_w> either use librarys to setup and open the rs232 or you use stty cmdline
May 07 07:56:09 <rob_w> u can now simple google examples on how to drive a rs232
May 07 07:56:35 <Mari72> Perfect
May 07 07:57:59 <Mari72> It's mean, when it pulled with the USB, I should just setup the Rs232 than just writing my protocol
May 07 07:58:17 <Mari72> Right?
May 07 07:58:55 <rob_w> yeah i guess
May 07 07:59:20 <rob_w> what is it that ur unsure ?
May 07 07:59:55 <rob_w> i got a rs232 via your adapter, if that is plugged and your "valve" aka client is running , then you might talk to it
May 07 08:00:20 <rob_w> after plugging your adapter and recieving your /dev/* it is generic and not bbb specific anymore
May 07 08:03:01 <Mari72> Are the not specific configuration, while I use USB for re232
May 07 08:03:27 <rob_w> dunno what u mean?
May 07 08:03:42 <Mari72> I use USB not the Pins
May 07 08:04:12 <rob_w> your bbb obviouly knows the adapter and load the driver and creates your /dev/* .. then u can start using it
May 07 08:04:17 <Mari72> For this Punkt there isn't a specific configuration for USB?
May 07 08:05:02 <rob_w> its a matter of the usb adapter and the bbb kernel to know about it and load it ..which seeems fine
May 07 08:07:09 <Mari72> Ok perfect thanks, I will try now to setup the Rs232 in cmd than it should send th data to the valve
May 07 09:31:49 <thinkfat_> zmatt: did you ever try aes67 AoIP on the BBB?
May 07 09:35:27 <thinkfat_> zmatt: a friend of mine tried to run a Raspi 3B+ as a PTPv2 grandmaster, that didn't work out well.
May 07 09:38:30 <zmatt> lol
May 07 09:38:44 <zmatt> we do use PTP and have it working pretty decently (with hardware timestamping)
May 07 09:38:59 <thinkfat_> yeah, that seem to be key
May 07 09:39:13 <thinkfat_> the raspi 3b+ has ethernet over usb and no timestamping in hardware...
May 07 09:39:20 <zmatt> lol
May 07 09:41:06 <zmatt> some effort was involved though, the kernel api is weird and the driver needed some fixes
May 07 09:41:29 <thinkfat_> but the hardware does support it, right?
May 07 09:41:47 <zmatt> yes
May 07 09:43:43 <zmatt> it can timestamp PTP packets (both layer 2 and over UDPv4) with high accuracy
May 07 09:44:41 <zmatt> lemme see if I pushed all stuff I did in the cpts driver to our github repo
May 07 09:45:45 <zmatt> I do see that patches 8, 9, 12, and 14-17 are all related to cpts and timestamping: https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.14/patches/local
May 07 09:45:52 <zmatt> it's been a while
May 07 09:47:23 <zmatt> and there's still more bugs in the cpts driver that I know I want to fix but haven't had time yet
May 07 09:47:41 <zmatt> and I should also try to see if some fixes can be cleaned up and upstreamed
May 07 09:47:46 <zmatt> but again, haven't really had time
May 07 09:48:01 <zmatt> oh great, and I have uncommitted changes /o\
May 07 10:14:23 <thinkfat_> Mouser just delivered another BBB, the stacking cape connectors and a few other bits, looks like I can now complete my GPSDO cape
May 07 10:14:46 <thinkfat_> and I immediately found a bug on the PCB ;) It's not good to repurpose one of the eMMC pins as a GPIO ;)
May 07 10:15:02 <zmatt> lol
May 07 10:16:19 <thinkfat_> not a real problem. nothing that cannot be fixed with an X-acto knife and a bit of thin copper wire.
May 07 10:16:35 <zmatt> thinkfat_: maybe print out the P9 and P8 tabs of my pins spreadsheet (https://goo.gl/Jkcg0w), they neatly fit on 1 page each (e.g. both sides of one sheet) and includes helpful cautions ;)
May 07 10:17:22 <thinkfat_> I did, I did! I just botched the schematics. The P8 GPIOs are shifted up one row and I didn't spot it.
May 07 10:19:27 <zmatt> :D
May 07 10:32:08 <malavpatel0112[m> Hello, i want enable all UART in beagle bone AI, please suggest me steps.
May 07 10:33:31 <malavpatel0112[m> please any one help me
May 07 11:36:23 <thinkfat_> hmmm, why isn't the driver for the ad5963r dac automatically loaded?
May 07 11:52:02 <zmatt> either because DT has no device with the appropriate declaration, or if it's an out-of-tree module then maybe you forgot to run depmod after installing it
May 07 11:52:47 <zmatt> (also, if initramfs is used, update that after installing a module and/or running depmod.  or just don't use initramfs)
May 07 11:53:22 <zmatt> I get zero results (apart from nonsense) for that part number btw, so I'm guessing it contains a typo?
May 07 11:58:15 <thinkfat_> yes
May 07 11:58:19 <thinkfat_> ad5693r
May 07 11:58:29 <thinkfat_> two numbers mixed up
May 07 11:59:56 <thinkfat_> if I load the module (which is in-tree) manually, the driver probes.. so I guess the devicetree is OK
May 07 12:00:12 <thinkfat_> and there's a line i2c:ad5693r in modules.alias...
May 07 12:00:42 <zmatt> oh, i2c, I remember there being a headache with that
May 07 12:01:16 <zmatt> you have  compatible = "adi,ad5593r";   ?
May 07 12:01:28 <zmatt> ehh sorry
May 07 12:01:29 <zmatt> wait what
May 07 12:01:36 <zmatt> oh I'm looking at the wrong driver
May 07 12:01:58 <thinkfat_> I have compatible = "ad5693r"
May 07 12:02:04 <zmatt> ad5696-i2c.c doesn't declare any of_device_id
May 07 12:03:22 <zmatt> that's not a proper compatible-string
May 07 12:03:34 <zmatt> you're currently using a hacky compat/fallback mechanism
May 07 12:04:46 <zmatt> https://i2c.wiki.kernel.org/index.php/OF_Modalias
May 07 12:06:38 <zmatt> see ad5593r.c for an example of a similar driver which does declare an of_device_id
May 07 12:07:25 <zmatt> it should be compatible = "adi,ad5693r";  but the driver will need a declaration for it
May 07 12:07:44 <thinkfat_> so that's why the lm75 driver is properly loaded for the mcp980x temperature sensor I have, but not the adc...
May 07 12:08:18 <thinkfat_> yep, so the driver seems broken...
May 07 12:08:36 <zmatt> thinkfat_: what "modalias" does your device report in sysfs?  I wonder if they've fixed it nowadays
May 07 12:09:45 <zmatt> yeah it's using of: modaliases, not i2c:
May 07 12:10:24 <zmatt> for i in /sys/bus/i2c/devices/*/modalias; do echo "$i: - $(cat $i)"; done
May 07 12:10:47 <zmatt> ehh, the ": " and " - " is redundant, pick one separator of choice :P
May 07 12:11:36 <zmatt> on kernel 4.19.94-ti-r42 I get of: modaliases only
May 07 12:11:45 <thinkfat_> https://pastebin.com/0Vb8CEFG
May 07 12:12:07 <zmatt> so that means the i2c_device_id declarations in the driver are not used for loading the driver
May 07 12:12:18 <zmatt> of_device_id declarations are required
May 07 12:12:27 <thinkfat_> so, broken driver
May 07 12:12:46 <zmatt> but I guess the old mechanism is still used as fallback to probe drivers
May 07 12:13:01 <zmatt> yeah, or at least driver that hasn't been updated yet
May 07 12:13:11 <zmatt> it should be a trivial fix
May 07 12:13:15 <zmatt> it's just some identifiers
May 07 12:13:49 <thinkfat_> yep, but it's even easier for me to add the driver to /etc/modules ;)
May 07 12:14:22 <zmatt> :P
May 07 12:14:59 <zmatt> at least fix your compatible to have the "adi," prefix... I'm pretty sure that shouldn't interfere with the fallback mechanism, but then at least your DT declaration is correct even if the driver isn't yet
May 07 12:15:35 <thinkfat_> yep, already done
May 07 12:15:58 <thinkfat_> hm, no driver for the tdc7200
May 07 12:16:57 <thinkfat_> I guess that means "spidev"
May 07 12:20:22 <zmatt> yay, spidev
May 07 12:20:39 <zmatt> would be nice if there were an async version of it
May 07 12:21:02 <zmatt> or rather, if it supported async transfers
May 07 12:27:40 <thinkfat_> yeah, I wonder anyway. I need to start a measurement, then wait for an interrupt, then read the result
May 07 12:27:56 <zmatt> basic enough
May 07 12:28:03 <thinkfat_> I guess that means I need a method to wait for interrupts on a gpio in userspace
May 07 12:28:05 <thinkfat_> uio?
May 07 12:28:24 <zmatt> you could use uio but you can also just use the sysfs gpio interface
May 07 12:28:31 <thinkfat_> hm, yes.
May 07 12:28:36 <thinkfat_> latency is not an issue
May 07 12:28:41 <zmatt> if you configure the 'edge' attribute you'll get an (E)POLLPRI on the value file descriptor
May 07 12:28:50 <zmatt> I don't know which is faster, if either
May 07 12:29:37 <zmatt> I've seen 40-80 us latency last time I tested but that was aaaaaaages ago
May 07 12:30:05 <zmatt> (and I think using uio but I honestly don't really remember)
May 07 12:30:48 <zmatt> should you have an interest in the uio route for some reason, this is how you set one up: https://github.com/mvduin/py-uio/blob/master/dts/gpio-irq.dtsi
May 07 12:30:53 <thinkfat_> microseconds range is totally fine, as long as I can select()
May 07 12:31:16 <zmatt> wow that's oldschool :)
May 07 12:31:46 <zmatt> but yeah, it should show up in exceptfds when using select()
May 07 12:31:54 <zmatt> (when using sysfs that is)
May 07 12:32:03 <zmatt> when using uio the file descriptor simply becomes readable
May 07 12:32:35 <thinkfat_> I don't want do use multithreading for no good reason
May 07 12:32:51 <zmatt> yeah I mean using the old select() instead of a more modern replacement
May 07 12:33:11 <thinkfat_> and the program I'm porting runs on a cortex-m0+ with no rtos, so I don't see the point
May 07 12:33:19 <thinkfat_> well, yes, poll() then, whatever
May 07 12:34:14 <zmatt> I personally usually use sd-event these days for my event loops (or my own C++ wrapper thereof), since libsystemd is generally available and it allows different kinds of events to be received (e.g. timers on CLOCK_REALTIME and CLOCK_MONOTONIC, fd events, signals, child processes)
May 07 12:35:04 <zmatt> it's not perfect but mostly adequate
May 07 13:33:41 <thinkfat_> zmatt: is pinctrl-* mandatory for uio?
May 07 13:34:32 <zmatt> thinkfat_: pinctrl applies uniformly to all devices that use pins
May 07 13:35:23 <zmatt> uio specifically doesn't know or care
May 07 13:42:23 <thinkfat_> ok
May 07 13:42:28 <thinkfat_> the bindings have changed a bit
May 07 13:42:33 <zmatt> ?
May 07 13:42:39 <thinkfat_> compatible = "linux,uio-pdrv-genirq";
May 07 13:42:54 <zmatt> oh they finally added an actual compatible-string to the driver?
May 07 13:43:16 <zmatt> nope
May 07 13:43:28 <zmatt> still needs to be specified via module parameter
May 07 13:43:44 <zmatt> at least in 4.19
May 07 13:44:08 <zmatt> for which I use https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf
May 07 13:45:11 <thinkfat_> hm, the patch I found was from 2017, I assumed it was merged meanwhile...
May 07 13:45:15 <zmatt> and it's still like that in current mainline: https://elixir.bootlin.com/linux/v5.6.11/source/drivers/uio/uio_pdrv_genirq.c#L264
May 07 13:45:19 <zmatt> patch?
May 07 13:45:24 <zmatt> no patch is needed
May 07 13:45:29 <zmatt> this is a mainline driver
May 07 13:45:41 <thinkfat_> https://lore.kernel.org/patchwork/patch/833109/
May 07 13:45:51 <thinkfat_> the patch that introduced the binding documentation
May 07 13:46:00 <thinkfat_> I sort of assumed the driver would follow that...
May 07 13:46:09 <thinkfat_> but it's not been merged, apparently
May 07 13:46:47 <zmatt> all of its properties are generic DT properties anyhow
May 07 13:51:34 <zmatt> just define zero or more mmio regions with "reg", an optional interrupt, and the usual pinctrl properties (for state "default") if it has any associated pins
May 07 13:53:26 <zmatt> compatible-string set to whatever you set the of_id property of the module to (I'd suggest plain "uio"), and I personally add a custom "symlink" property to create a symlink in /dev/ (rcn also uses that same udev rule in current images)
May 07 13:54:45 <thinkfat_> well yes
May 07 13:54:50 <thinkfat_> did that, no workee
May 07 13:55:05 <thinkfat_> I see the module gets loaded, but nothing in /dev/uio and nothing in /sys/class/uio either
May 07 13:56:40 <thinkfat_> https://pastebin.com/70b8YbbT
May 07 13:57:16 <zmatt> you have the modprobe.d rule to set its of_id ?
May 07 13:58:12 <thinkfat_> yes
May 07 13:58:25 <zmatt> updated initramfs, if you're using initramfs ?
May 07 14:00:22 <thinkfat_> momentchen...
May 07 14:02:13 <zmatt> (easy fix: don't use initramfs.  every beaglebone image in quite a few years has worked just fine without it, and boots faster and no need to ever rebuild it)
May 07 14:02:18 <thinkfat_> got it
May 07 14:02:22 <thinkfat_> put the rule in the wrong place
May 07 14:02:25 <zmatt> ah
May 07 14:03:36 <thinkfat_> perfect
May 07 14:03:54 <thinkfat_> I have my /dev/uio/tdc7200-irq file, that should do it
May 07 14:04:14 <zmatt> so you're opting for uio over sysfs? :)
May 07 14:07:05 <thinkfat_> yes.
May 07 14:07:35 <thinkfat_> less hassle with hardware changes with symbolic names
May 07 14:11:25 <zmatt> oh I use symbolic names for gpios
May 07 14:11:51 <zmatt> e.g. https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi  with appropriate udev rule that creates symlinks
May 07 14:13:39 <zmatt> which would yield as result: https://pastebin.com/YKW7Wcqu
May 07 14:15:27 <zmatt> very useful since gpios often end up moving around in pcb revisions
May 07 14:27:11 <thinkfat_> indeed
May 07 14:30:09 <thinkfat_> I wrote a small eventloop framework in 2009 that used select() in the mainloop. I guess I'll dust it off and rewrite it to use poll, that's probably good enough for what I need
May 07 14:31:15 <zmatt> yeah I had a similar thing around epoll but I now avoid it for anything new and usually ended up having to rewrite existing things once I ran into its limitations
May 07 14:31:42 <zmatt> no use in reinventing the wheel
May 07 14:32:17 <thinkfat_> yeah, I anyway don't get why somebody would bother with systemd....
May 07 14:32:20 <thinkfat_> :-)
May 07 14:33:35 <zmatt> because it's actually really useful?
May 07 14:33:56 <thinkfat_> I suppose... otherwise it'd have died by now
May 07 14:34:11 <zmatt> it also does a great job at minimizing startup time
May 07 14:35:09 <zmatt> systemd-networkd has also been a clear improvement over everything I've previously used
May 07 14:36:08 <zmatt> and if your system uses systemd anyway, there's little reason to not use libsystem in services
May 07 14:36:20 <zmatt> we use sd-bus too for dbus communication
May 07 14:37:01 <zmatt> (which has replaced random ad-hoc ways for our services to communicate)
May 07 17:05:10 <kremlin> m
May 07 20:32:38 <claude65> Hello! I was trying to find the operating temperatures for the BBBW but I could not find any official documetnation other than that of the octavo processor. can perhaps someone shed some light or point me to the right direction
**** ENDING LOGGING AT Thu May 07 22:58:43 2020

**** BEGIN LOGGING AT Thu May 07 23:00:15 2020
May 08 01:37:32 <KenUnix> (y)  Idle minds are the devils workshop D:
May 08 01:46:55 <set_> Hey Honkie!
May 08 01:47:07 <set_> KenUnix in da 'hizzy!
May 08 01:48:34 <KenUnix> See the new BBB SRM. Came out yesterday.
May 08 01:48:54 <set_> What?
May 08 01:48:56 <set_> Serious?
May 08 01:49:02 <set_> What version?
May 08 01:49:49 <KenUnix> Yes, go grab your copy here (top item)   https://github.com/beagleboard/beaglebone-black
May 08 01:50:10 <KenUnix> Yesterday version
May 08 01:52:33 <set_> Nice...but what version. They have the rev. c already.
May 08 01:53:01 <set_> Oh. I got it. It is an updated version of the Rev. C version.
May 08 01:53:13 <KenUnix> This is C2
May 08 01:55:05 <set_> Aw.
May 08 01:55:07 <set_> Okay.
May 08 01:55:42 <set_> I am trying to use Adafruit_PCA9685 w/ smbus2 right now. it is beating me b/c I cannot find the replica of get_i2c_device in smbus2.
May 08 01:55:58 <set_> brb
May 08 01:58:08 <KenUnix> Well, you got me
May 08 01:58:36 <KenUnix> Can you download the SRM from Git?
May 08 02:01:22 <set_> Oh.
May 08 02:01:23 <set_> No.
May 08 02:01:55 <set_> I am trying to exchange items in the old source from this fellow Tony to work w/ smbus2 for the ServoCape.
May 08 02:01:56 <KenUnix> I'll try and find the original link
May 08 02:02:20 <KenUnix> exchange items?
May 08 02:03:36 <set_> Yes.
May 08 02:03:43 <KenUnix> Rememberr I was complaining about  sleep  not working in ubuntu? Well I wrotemy own in 'c' and it runs on ubuntu, debian and BBB
May 08 02:04:12 <KenUnix> Want a copy?
May 08 02:04:18 <set_> I am developing something right now from what was already done that no longer works on the BBBW for the ServoCape.
May 08 02:04:37 <set_> KenUnix: I got your email earlier.
May 08 02:04:49 <KenUnix> Enjoy it?
May 08 02:04:57 <set_> Nope. I have not tried it just yet.
May 08 02:05:17 <set_> Was it for file searching?
May 08 02:05:56 <KenUnix> Before I go looking for the SRM i'll push a copy of sleep to pastebinit. Some need 'c' things.
May 08 02:06:15 <zmatt> KenUnix: https://github.com/beagleboard/beaglebone-black/raw/master/BBB_SRM.pdf
May 08 02:11:29 <KenUnix> Thanks is it the C2 version ?
May 08 02:12:15 <zmatt> set_: there's no equivalent to get_i2c_device, you don't create an object for an i2c device, you create one for the bus and pass the device address as separate argument to the various calls
May 08 02:12:58 <KenUnix> set See above link from zmatt to download C2 version of SRM
May 08 02:14:11 <KenUnix> zmatt, Remember my slep headaches with ununto 20.04?  I wrote my own simplifid version in 'c'.
May 08 02:14:20 <KenUnix> It at :https://pastebin.com/xWF1retp
May 08 02:14:40 <KenUnix> zmatt, Remember my sleep headaches with ununto 20.04?  I wrote my own simplifid version in 'c'.
May 08 02:14:46 <zmatt> KenUnix: did the patched libc not fix the problem?
May 08 02:14:54 <KenUnix> no
May 08 02:15:56 <zmatt> KenUnix: you did install it with "sudo apt install libc6=2.31-0ubuntu8+lp1871129~1" ?
May 08 02:19:32 <KenUnix> Here's what it did: The following packages will be REMOVED:  libc6-devThe following packages will be DOWNGRADED:  libc6
May 08 02:19:48 <KenUnix> sleep still broke
May 08 02:20:00 <zmatt> KenUnix: weird
May 08 02:20:14 <zmatt> since that package had been specifically made to fix the problem
May 08 02:20:24 <KenUnix> Did you look at my silly sleep.c
May 08 02:20:33 <zmatt> yes it's terrible
May 08 02:20:42 <KenUnix> Thank you
May 08 02:21:13 <zmatt> just use sleep() or usleep()
May 08 02:21:18 <KenUnix> Should I dare to ask why?
May 08 02:21:27 <zmatt> because you're causing 100% cpu load
May 08 02:21:35 <zmatt> as opposed to sleep which causes 0% cpu load
May 08 02:22:10 <zmatt> it also doesn't support fractional-second sleep
May 08 02:22:38 <KenUnix> Well sleep is broke. How do I avoid 100% cpu load? I don't need fractions
May 08 02:23:10 <KenUnix> Look I knocked this out this afternoon
May 08 02:23:28 <zmatt> use sleep() or usleep()  (the C functions)
May 08 02:24:15 <KenUnix> If usleep worked in the first place I wouldn't ne here
May 08 02:24:27 <zmatt> usleep is broken too?
May 08 02:24:42 <KenUnix> Let me try it, hold
May 08 02:24:56 <zmatt> that would probably break soo many applications
May 08 02:25:01 <zmatt> it sounds highly unlikely
May 08 02:25:08 <zmatt> WSL would be completely broken if that were the case
May 08 02:26:58 <zmatt> though I guess it's possible if libc now converts usleep() into the broken call
May 08 02:27:37 <zmatt> but then you should really try to downgrade libc to an older version, since it means sleeping is broken in so many programs
May 08 02:29:30 <set_> I almost got it. Down to one error.
May 08 02:35:08 <KenUnix> zmatt, OK I set the usleep timer to 10,000 much less load
May 08 02:35:32 <zmatt> KenUnix: just usleep( tsec * 1000000 );
May 08 02:35:37 <zmatt> instead of using time() and looping
May 08 02:36:33 <KenUnix> ok wait
May 08 02:44:10 <KenUnix> OK zmatt. Thanks. Here is what I ended up with   https://pastebin.com/3pdL0c4r
May 08 02:45:30 <zmatt> KenUnix: does plain sleep() not work btw?  sleep( tsec );
May 08 02:48:02 <KenUnix> Yea that works too.
May 08 02:52:08 <GenTooMan> so no panic needed?
May 08 02:53:04 <zmatt> it's really dumb though, this means nanosleep() works in WSL but clock_nanosleep() doesn't work for CLOCK_REALTIME (even though it apparently works for CLOCK_MONOTONIC)
May 08 02:53:38 <zmatt> hmm wait though, what clock does nanosleep() use anyway?
May 08 02:54:42 <zmatt> and why did glibc switch to using clock_nanosleep(CLOCK_REALTIME, ...) ... hmm
May 08 02:56:01 <set_> Hey. False alarm. I more errors that are going to take much more work.
May 08 02:56:03 <set_> Boo!
May 08 02:56:05 <set_> and..
May 08 02:56:07 <set_> yea boy!
May 08 02:56:33 <GenTooMan> they probably deprecated usleep and call internally nanonsleep this is because of POSIX.1-2001 declaring it obsolete and POSIX.1-2008 removing it from the specification.
May 08 02:56:53 <zmatt> GenTooMan: nanosleep() is fine
**** ENDING LOGGING AT Fri May 08 02:59:59 2020