**** BEGIN LOGGING AT Thu Sep 29 02:59:56 2022
Sep 29 10:33:09 <jfsimon1981> Hello zmatt
Sep 29 10:33:53 <jfsimon1981> Could you please help cmpile the uart dtsi file, i tried place it into the device tree, it seems to compile all dts files
Sep 29 10:42:20 <jfsimon1981> Ok  i found overlay-utils, seems to be going on
Sep 29 12:12:24 <jfsimon1981> zmatt
Sep 29 12:12:30 <jfsimon1981> Hi
Sep 29 12:12:50 <jfsimon1981> This works :
Sep 29 12:12:54 <jfsimon1981> (uEnv.txt)
Sep 29 12:12:57 <jfsimon1981> uboot_overlay_addr2=/lib/firmware/BB-UART2-RTSCTS-00A0.dtbo
Sep 29 12:13:04 <jfsimon1981> This doesn't
Sep 29 12:13:07 <jfsimon1981> uboot_overlay_addr1=/lib/firmware/BB-UART2-RTSCTS-00A0.dtbo
Sep 29 12:13:21 <jfsimon1981> RTS signal get low allright, never returns high.
Sep 29 12:13:31 <jfsimon1981> Just changing slot makes RTS work, strange.
Sep 29 12:20:44 <jfsimon1981> My mistake both are the same
Sep 29 16:20:44 <zmatt> jfsimon1981: yeah what I linked to is part of overlay-utils, and should be build as part of that repository (using its makefile)
Sep 29 16:23:17 <jfsimon1981> yes i could do it thank you
Sep 29 16:24:01 <jfsimon1981> although i have now strange behaviour, the RTS line will work with UART4 after boot, but using libmodbus will (with RTS NONE) brings it back to zero and it will remain there.
Sep 29 16:24:37 <jfsimon1981> Onward after lib usage, the sending through console also fails where it worked before using the library.
Sep 29 16:24:55 <jfsimon1981> So i'm investigating still.
Sep 29 16:25:06 <zmatt> is the polarity just inverted?
Sep 29 16:25:09 <zmatt> of the rts?
Sep 29 16:25:29 <zmatt> (i.e. the problem I already anticipated, warned about, and gave a solution for)
Sep 29 16:25:35 <jfsimon1981> But it's getting better, it looks like once brought to zero yes, it's inverted, doesn't move from there anywmore.
Sep 29 16:25:59 <zmatt> I mean, in rs485 mode it should move during transmit obviously
Sep 29 16:26:00 <jfsimon1981> Yes i check it all. Compile dtbo with or without the inversion makes no difference.
Sep 29 16:26:15 <jfsimon1981> yes, it does not.
Sep 29 16:26:19 <zmatt> the setting in dt doesn't do anything, I already said that
Sep 29 16:26:36 <zmatt> (it's _intended_ to work, but doesn't)
Sep 29 16:26:48 <zmatt> it needs to be configured from userspace
Sep 29 16:26:57 <jfsimon1981> The library does something to the device that locks rts to 0, i don't get it yet.
Sep 29 16:27:09 <jfsimon1981> yes right
Sep 29 16:27:15 <zmatt> if rts is not changing at all during transmit, is rs485 mode enabled at all?
Sep 29 16:27:18 <jfsimon1981> with the c file
Sep 29 16:27:24 <jfsimon1981> i did that too
Sep 29 16:27:56 <jfsimon1981> i'll check again perhaps i missed something
Sep 29 16:28:09 <zmatt> if you use my initialization code, be sure to pass true to active_low
Sep 29 16:33:35 <jfsimon1981> yes except my mistake i do it and still i have no rts. https://pastebin.com/U7VU6gcm
Sep 29 16:34:55 <jfsimon1981> The plan is dwelve into the library and find where it modifies or disables rts. That's what i'll do next.
Sep 29 16:35:43 <zmatt> ehm what, my code takes a file descriptor not a FILE* ... this shouldn't even compile
Sep 29 16:37:14 <jfsimon1981> ah
Sep 29 16:39:05 <jfsimon1981> yes i get a waring message about conversion, let me make it work
Sep 29 16:41:39 <zmatt> https://pastebin.com/iDWRgnVK
Sep 29 16:50:43 <jfsimon1981> indeed i had it not working, seems better
Sep 29 16:50:51 <jfsimon1981> i'll run the libmodbus test
Sep 29 16:51:55 <jfsimon1981> I seem to have something
Sep 29 16:52:25 <jfsimon1981> although the message don't return from the client, ie bebahiour is better
Sep 29 17:12:40 <jfsimon1981> The line behavious seem right, words are erroneous, which is similar to what i saw last week. At least the RTS timing issue seems fixed.
Sep 29 17:12:58 <jfsimon1981> I'll usea UART4, this one is working with proper rts.
Sep 29 17:17:09 <jfsimon1981> Got it the line transmits a 0a char at the end.
Sep 29 17:20:08 <jfsimon1981> The device terminates the line apparently, that messes modbus frame as i understand.
Sep 29 17:20:37 <jfsimon1981> Specific to uart4 then.
Sep 29 17:25:43 <jfsimon1981> it works i have no idea why
Sep 29 17:26:28 <jfsimon1981> At least the client responds (messages have a crc still).
Sep 29 17:28:11 <jfsimon1981> That looks somehow better though
Sep 29 17:32:18 <jfsimon1981> Just too strange, reboot and device/host now communicate allright.
Sep 29 17:32:40 <jfsimon1981> A persistent timing error fixed by reboot.
Sep 29 17:33:25 <jfsimon1981> Went from 50% success with library timer to what looks like 100% pass at the moment, all good.
Sep 29 17:45:57 <jfsimon1981> 0,8% error rate be it, i'll accept this.
Sep 29 22:28:43 <zmatt> jfsimon1981: do I remember correctly that this was with a device that sends its response way too quickly, in violation of the modbus specification?
Sep 29 22:29:25 <zmatt> if so, if fixing the device isn't an option, probably the only way to deal with that completely reliably would be by using PRU
**** ENDING LOGGING AT Fri Sep 30 02:59:57 2022