**** BEGIN LOGGING AT Wed Sep 28 02:59:57 2022
Sep 28 06:41:50 <Guest52> Hi
Sep 28 08:19:40 <Parduz> I want to create an "etcher" image from my running BBB, but googling around to find an answer, i get opposite results (some says it can be done with dd, some says the result is unusable/won't boot/hangs Etcher.
Sep 28 08:20:40 <Parduz> i've found this thread https://forum.beagleboard.org/t/creating-flasher-image-file-from-running-beaglebone/30345/5 and so i'm asking:
Sep 28 08:21:41 <Parduz> there's an utility, or a succesfull way, to make an etcher image from the flash of a BBB running Debian 10?
Sep 28 13:06:33 <Guest47> HI
Sep 28 13:09:57 <Guest47> need just several reviews from many users who test the beagle bone black in real active and continuous working and running for at least one 1 year ,what about the performance ???
Sep 28 13:12:15 <jkridner> no impact on performance I’ve noticed, but i avoid regular eMMC writes.
Sep 28 13:17:05 <Guest47> ok, thanks ,any feedback from some users make external connection with ModBus RTU devices over usb to serial converter or TCP/IP connection or using HEADER pins on the beagle itself ,I mean long time continuous running as well ???
Sep 28 13:21:03 <jkridner> Well, I deploy stuff that has run a few years continuously. maybe 500-600 days for my longest uptimes. Always run from eMMC and avoid needless writes. Been using Balena. TCP over wifi or cellular. Headers connected to sensor boards—just I2C and GPIO.
Sep 28 13:21:44 <jkridner> kinda want to search for my longest uptime now.
Sep 28 13:24:30 <Guest47> and everything was going well so far right ???
Sep 28 13:27:25 <jkridner> yeah.
Sep 28 13:28:04 <Guest47> thanks for you,.
Sep 28 15:50:23 <NishanthMenon> Parduz https://gist.github.com/StaticRocket/8934f78b3da7838ca265aa0223e62608 might be interesting.. maybe
Sep 28 15:55:07 <zmatt> make a flasher image of debian 10 ?  that's a concerning request
Sep 28 15:55:46 <zmatt> oh wait never mind, 10 is buster not stretch
Sep 28 20:11:12 <jfsimon1981> Struggling a bit with rs485 hald duplex
Sep 28 20:11:16 <jfsimon1981> (f)
Sep 28 20:12:21 <jfsimon1981> i don't quite understand the management of rs to handle the transciever DE/_RE, the line does'nt seem to be returning to high, althgouh i use uart2+rts/cts.
Sep 28 20:12:31 <jfsimon1981> I have to dig into this.
Sep 28 20:30:46 <zmatt> jfsimon1981: are you enabling rs485 mode on the tty to have the kernel automatically control the rts line as rs485 driver-enable ?
Sep 28 20:30:58 <zmatt> (cts is not used in rs485 mode)
Sep 28 20:32:10 <zmatt> (rs485 mode is very different from rts/cts based hardware handshake)
Sep 28 20:33:01 <jfsimon1981> zmatt, good evening
Sep 28 20:33:27 <jfsimon1981> I think not, when i write with the cu program the line doesn't return
Sep 28 20:33:51 <jfsimon1981> i should enable rs485 mode i probably missed it
Sep 28 20:34:20 <zmatt> well normally you wouldn't use a program like cu to control an rs485 port
Sep 28 20:34:55 <zmatt> in C it can be enabled like this: https://pastebin.com/r1rJFUfr  .. or if you're using python, py-serial also has options to enable it
Sep 28 20:36:04 <jfsimon1981> thanks let me compile it
Sep 28 20:36:10 <zmatt> in theory it can be enabled in device-tree, though that didn't seem to work yet in kernel 4.19
Sep 28 20:37:02 <jfsimon1981> ok i struggled a bit with this, i have libmodbus handle it but the timing is not perfect and get many crc
Sep 28 20:37:29 <jfsimon1981> hence i switch to kernel / driver solution
Sep 28 20:46:14 <zmatt> didn't we have a fair amount of discussion about this a while back?  or was that with someone else?
Sep 28 20:48:12 <jfsimon1981> we discussed it
Sep 28 20:48:50 <jfsimon1981> i think i enabled the cts/rts but i messed up so that the library makes use of it, through its internal timing
Sep 28 20:49:11 <jfsimon1981> that kind of works, but it's not very reliable
Sep 28 20:49:41 <jfsimon1981> i mean i don't think the underlying layer handles the rts signal, i'm trouble shooting it now
Sep 28 20:50:01 <zmatt> the rts signal should be fully managed by the kernel and not touch at all by the library
Sep 28 20:50:06 <zmatt> *touched
Sep 28 20:51:14 <zmatt> it looks like libmodbus has support for using kernel rs485 mode though
Sep 28 20:51:34 <jfsimon1981> yes that's why i did incorrectly, it seems the line never returns high when i send data through the dev. The library works but it through usleep() and writing to the pin, somehow it works.
Sep 28 20:51:46 <jfsimon1981> Indeed but i had to tweak the timing
Sep 28 20:51:56 <jfsimon1981> and it's sensitive to interrupt during frames
Sep 28 20:52:08 <zmatt> that makes no sense if it's implemented correctly
Sep 28 20:52:27 <jfsimon1981> also has to be tuned precisely to the client device, it's not good enough. Worked for prototyping.
Sep 28 20:52:40 <zmatt> all this just sounds like stuff is very broken
Sep 28 20:52:56 <zmatt> but didn't you also have the problem of a client device with broken timing?  I seem to vaguely remember that
Sep 28 20:53:21 <jfsimon1981> Yes the library has a byte length calculation, sends data to the uart, meanwhile it does a usleep() then toggles RTS.
Sep 28 20:54:22 <jfsimon1981> Yes indeed, they respond instantanesouly
Sep 28 20:54:25 <zmatt> that shouldn't happen
Sep 28 20:54:37 <zmatt> I'm looking at the code, it shouldn't get there
Sep 28 20:55:14 <zmatt> like, in here, this if-condition should be false, hence it should take the else-case: https://github.com/stephane/libmodbus/blob/master/src/modbus-rtu.c#L282-L300
Sep 28 20:55:22 <jfsimon1981> Hence i had to tweak the library to trigger rts sooner, there was a slight overhead which messed up the half duplex for few first bits.
Sep 28 20:55:32 <zmatt> so it shouldn't do any usleep at all
Sep 28 20:57:15 <zmatt> the serial mode should be MODBUS_RTU_RS485, the rts mode should be MODBUS_RTU_RTS_NONE
Sep 28 20:57:28 <jfsimon1981> ok
Sep 28 20:57:38 <jfsimon1981> i activated RTS through the lib here
Sep 28 20:57:50 <jfsimon1981> it should be none if handled by kernel you mean
Sep 28 20:57:56 <zmatt> yes
Sep 28 20:58:18 <jfsimon1981> yes that's what i messed precisely, the kernel didn't handle it and i got it throught library instead
Sep 28 20:58:22 <jfsimon1981> hence timing issues
Sep 28 20:58:53 <jfsimon1981> i correct it
Sep 28 21:00:31 <zmatt> the only possible issue I see here is that it doesn't seem to allow configuring the polarity of the rts signal.  it's possible you may need to fix that manually by using my code snippet ( https://pastebin.com/r1rJFUfr ) to configure the polarity (active-low or active-high) before using libmodbus
Sep 28 21:00:47 <zmatt> (if the signal is inverted)
Sep 28 21:00:55 <zmatt> I don't know what the default is
Sep 28 21:01:05 <jfsimon1981> i want libmodbus to have not worry about this at all
Sep 28 21:01:21 <zmatt> well libmodbus can't guess the polarity of the signal, that depends on your hardware
Sep 28 21:01:26 <jfsimon1981> once the hardware is properly setup i'll have the kernel device handle it properly
Sep 28 21:01:34 <zmatt> but it also doesn't offer an option to configure the polarity
Sep 28 21:01:39 <zmatt> it seems
Sep 28 21:02:01 <jfsimon1981> i think yes it can be configured, there's the option in set rts function.
Sep 28 21:02:21 <zmatt> that isn't used in rs485 mode
Sep 28 21:02:29 <jfsimon1981> But libmodbus won't have interface with rts if the device is handled by kernel probably
Sep 28 21:02:44 <jfsimon1981> i'll work on it
Sep 28 21:03:00 <zmatt> I'm talking about the polarity of the kernel-managed rs485 mode
Sep 28 21:03:58 <jfsimon1981> yes
Sep 28 21:04:35 <jfsimon1981> i'll check it, anyway i inverted with a simple transistors already in hw, because the transciever polarity was wrong
Sep 28 21:05:07 <zmatt> that is silly since the polarity is determined by software
Sep 28 21:06:00 <jfsimon1981> right i think i did that because of compatibility with software versions and physical modules
Sep 28 21:07:12 <jfsimon1981> i have to be a bit careful, the client can update software on other modules too hence i can change it here, it would break the other modules they run if they updated it.
Sep 28 21:08:05 <jfsimon1981> got to implement the kernel rts support, i'm on it now
Sep 28 22:55:44 <jfsimon1981> Hi, well no luck with uart2, though uart4 works, regarding rtscts
Sep 28 22:56:30 <jfsimon1981> Just need to enable BB-UART4-RTSCTS-00A0.dts, set pinmux to uart.
Sep 28 22:57:07 <jfsimon1981> (though couldn't get rts to toggle with uart2). Probably will switch to uart4 then, in hw too.
Sep 28 22:57:26 <zmatt> for some reason that overlay doesn't mux the rxd/txd pins hence needs to be combined with the BB-UART4 overlay: https://pastebin.com/PkdvgViR
Sep 28 22:57:51 <zmatt> or better, just either a custom overlay (that muxes txd, rxd, and rts) or use cape-universal
Sep 28 22:58:03 <jfsimon1981> ok
Sep 28 22:58:31 <zmatt> my overlay-utils includes an example for uart4: https://github.com/mvduin/overlay-utils/blob/master/uart4-rs485.dtsi
Sep 28 22:59:14 <jfsimon1981> thanks
Sep 28 22:59:37 <zmatt> it also shows how rs485 mode is supposed to be configurable via dt... although in practice it doesn't actually work
Sep 28 23:00:11 <jfsimon1981> Signal polarity will be ok, it's active low as need to be
Sep 28 23:00:39 <jfsimon1981> For the particular case i work on though
Sep 28 23:00:41 <zmatt> yeah, in that case comment out line 34 just in case
Sep 28 23:01:02 <zmatt> (in case you ever upgrade to a newer kernel that *does* properly support these properties)
Sep 28 23:01:14 <jfsimon1981> i see
Sep 28 23:01:59 <jfsimon1981> Working with uart4. I don't know why id didn't get though with uart2
Sep 28 23:02:21 <jfsimon1981> the rts/cts are on lcd pins, uart 4 are too
**** ENDING LOGGING AT Thu Sep 29 02:59:56 2022