07:43 <jfsimon1981> zmatt, good morning, yes it turns out two types of devices i checked and interface to do not wait. It is my opinion this part of the standard is not applied in most recent devices.

07:44 <jfsimon1981> Although i have checked only two from US and Chinese manufacturers.

07:45 <jfsimon1981> The uart if properly handled at hardware level, which i trust since it has IRQs, should not be handled by the processor and it should be buffered. If so there shouldn't be much issues.

09:06 <zmatt> jfsimon1981: asserting and deasserting rts is still done by software, albeit by the kernel in an interrupt handler

09:08 <zmatt> jfsimon1981: and the delay before responding is an absolutely required part of the modbus protocol, in fact the way the end of a message is indicated is through a transmit idle period (which can, necessarily, only be detected by waiting)

09:08 <zmatt> sending a reply without this delay means the reply is sent before the request message has officially ended

09:13 <jfsimon1981> yes correct, it should be at interrupt level hence the interrupt priority question for sure, this can happen

09:13 <zmatt> (minimum gap required between end of request and start of reply is 2ms if the baudrate is 19200)

09:14 <jfsimon1981> i believe the library can work all right with the standard stop pause

09:15 <jfsimon1981> (500us should be the default wait time to toggle rts back in the lib itself)

09:15 <zmatt> the lib doesn't control rts, the kernel does

09:15 <zmatt> by default there's no wait time, it just deasserts rts once the transmission is complete

09:17 <jfsimon1981> What happened is that it kept RTS active too long, hence devices talked on a busy line, and that did'nt work both because drivers interfere, and receive is disabled, hence RTS really needs to get off at the instant transmission finished. I saw they again yesterday on the scope, all happens right at the edge of a frame.

09:17 <zmatt> right, because the device is broken and violates the modbus specification

09:17 <jfsimon1981> Yes now it does, before, i still handled throught the library although it needed fine tune per device type. That could be possible only during developemnt.

09:18 <jfsimon1981> Yes, i don't know how widespread this is

09:18 <zmatt> be sure to report the bug if possible

09:18 <jfsimon1981> i can for sure, at least p

09:18 <jfsimon1981> peeke the question to manufacturer, 2 of them

09:21 <zmatt> for baudrates up to 19200 the line must be idle for at least 38.5 bit-times (e.g. 2ms @ 19200, 4ms @ 9600), for higher baudrates the line must be idle for 1.75ms before sending a reply

09:22 <zmatt> (more generally, this delay is required between any two messages on the bus)

09:23 <jfsimon1981> yes i remind we discussed on this too, that's quite tricky, if hardware aren't harmonized

09:24 <jfsimon1981> Both with which i dealt responded quicker but not the same, us ones has a longer delay

09:24 <zmatt> it's just a protocol violation, a misimplementation of modbus

09:25 <zmatt> it also implies deeper problems in how their code works, since on modbus rtu this minimum idle time is the _only_ way to determine the end of a message (and obviously you need to detect the end of a message before sending a reply)

09:26 <zmatt> idle time is what marks the completion of a transmission

09:27 <jfsimon1981> I'm not finished yet, i had to "reboot" the library, since sometimes, the client/host messages get back wrong, that can put the modbus library into a state when it never recovers. Hence at the moment, for each frame, i fully initialyze it. It's more complicated but reliably works. If i get time for it, i'd like to integrate a reinit where this gets messed at library level, so it does'nt neet to be instanciated every

09:27 <jfsimon1981> time. That's another todo item.

09:28 <jfsimon1981> I think the "state machine" in the library handles that rather than timing though i didn't check deeply how that works yet.

20:49 <BB-Flash> I have a BBBW at a remote location where only the Power LED lights up on application of power, nothing else happens. No USR LEDs flashing etc. I usually run it off of a microSD card and tried with and without. If you have any suggestions for troubleshooting, please let me know. Thanks!

21:07 <BB-Flash> I found a RS232 header cable and was able to plug it into the pins and get some info! https://pastebin.com/Y7Whay6g looks like it's not able to find the flash info on the microSD card.