<jfsimon1981>
RTS signal get low allright, never returns high.
<jfsimon1981>
Just changing slot makes RTS work, strange.
<jfsimon1981>
My mistake both are the same
set_ has quit [Remote host closed the connection]
brook has quit [Ping timeout: 246 seconds]
brook has joined #beagle
set_ has joined #beagle
tbr has joined #beagle
buckket has quit [Quit: buckket]
buckket has joined #beagle
otisolsen70 has joined #beagle
rob_w has quit [Remote host closed the connection]
brook_ has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has quit [Remote host closed the connection]
brook has joined #beagle
otisolsen70 has quit [Quit: Leaving]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 268 seconds]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
<zmatt>
jfsimon1981: yeah what I linked to is part of overlay-utils, and should be build as part of that repository (using its makefile)
<jfsimon1981>
yes i could do it thank you
<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.
<jfsimon1981>
Onward after lib usage, the sending through console also fails where it worked before using the library.
<jfsimon1981>
So i'm investigating still.
<zmatt>
is the polarity just inverted?
<zmatt>
of the rts?
<zmatt>
(i.e. the problem I already anticipated, warned about, and gave a solution for)
<jfsimon1981>
But it's getting better, it looks like once brought to zero yes, it's inverted, doesn't move from there anywmore.
<zmatt>
I mean, in rs485 mode it should move during transmit obviously
<jfsimon1981>
Yes i check it all. Compile dtbo with or without the inversion makes no difference.
<jfsimon1981>
yes, it does not.
<zmatt>
the setting in dt doesn't do anything, I already said that
<zmatt>
(it's _intended_ to work, but doesn't)
<zmatt>
it needs to be configured from userspace
<jfsimon1981>
The library does something to the device that locks rts to 0, i don't get it yet.
<jfsimon1981>
yes right
<zmatt>
if rts is not changing at all during transmit, is rs485 mode enabled at all?
<jfsimon1981>
with the c file
<jfsimon1981>
i did that too
<jfsimon1981>
i'll check again perhaps i missed something
<zmatt>
if you use my initialization code, be sure to pass true to active_low
<jfsimon1981>
indeed i had it not working, seems better
<jfsimon1981>
i'll run the libmodbus test
<jfsimon1981>
I seem to have something
<jfsimon1981>
although the message don't return from the client, ie bebahiour is better
SJFriedl has quit [Ping timeout: 244 seconds]
<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.
<jfsimon1981>
I'll usea UART4, this one is working with proper rts.
<jfsimon1981>
Got it the line transmits a 0a char at the end.
brook has quit [Remote host closed the connection]
<jfsimon1981>
The device terminates the line apparently, that messes modbus frame as i understand.
<jfsimon1981>
Specific to uart4 then.
brook has joined #beagle
<jfsimon1981>
it works i have no idea why
<jfsimon1981>
At least the client responds (messages have a crc still).
<jfsimon1981>
That looks somehow better though
florian has quit [Quit: Ex-Chat]
<jfsimon1981>
Just too strange, reboot and device/host now communicate allright.
<jfsimon1981>
A persistent timing error fixed by reboot.
<jfsimon1981>
Went from 50% success with library timer to what looks like 100% pass at the moment, all good.
<jfsimon1981>
0,8% error rate be it, i'll accept this.
ft has joined #beagle
otisolsen70 has joined #beagle
alan_o has joined #beagle
PhotoJim has quit [Ping timeout: 244 seconds]
PhotoJim has joined #beagle
argonautx has joined #beagle
argonautx has quit [Client Quit]
otisolsen70 has quit [Quit: Leaving]
<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?
<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