thinkfat_ has quit [Ping timeout: 250 seconds]
thinkfat has joined #beagle
Guest7 has joined #beagle
Guest7 has quit [Client Quit]
buzzmarshall has quit [Quit: Konversation terminated!]
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
ft has quit [Quit: leaving]
<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.
<jfsimon1981> Although i have checked only two from US and Chinese manufacturers.
<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.
florian has joined #beagle
<zmatt> jfsimon1981: asserting and deasserting rts is still done by software, albeit by the kernel in an interrupt handler
<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)
<zmatt> sending a reply without this delay means the reply is sent before the request message has officially ended
<jfsimon1981> yes correct, it should be at interrupt level hence the interrupt priority question for sure, this can happen
<zmatt> (minimum gap required between end of request and start of reply is 2ms if the baudrate is 19200)
<jfsimon1981> i believe the library can work all right with the standard stop pause
<jfsimon1981> (500us should be the default wait time to toggle rts back in the lib itself)
<zmatt> the lib doesn't control rts, the kernel does
<zmatt> by default there's no wait time, it just deasserts rts once the transmission is complete
<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.
<zmatt> right, because the device is broken and violates the modbus specification
<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.
<jfsimon1981> Yes, i don't know how widespread this is
<zmatt> be sure to report the bug if possible
<jfsimon1981> i can for sure, at least p
<jfsimon1981> peeke the question to manufacturer, 2 of them
<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
<zmatt> (more generally, this delay is required between any two messages on the bus)
<jfsimon1981> yes i remind we discussed on this too, that's quite tricky, if hardware aren't harmonized
<jfsimon1981> Both with which i dealt responded quicker but not the same, us ones has a longer delay
<zmatt> it's just a protocol violation, a misimplementation of modbus
<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)
<zmatt> idle time is what marks the completion of a transmission
<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
<jfsimon1981> time. That's another todo item.
<jfsimon1981> I think the "state machine" in the library handles that rather than timing though i didn't check deeply how that works yet.
otisolsen70 has quit [Quit: Leaving]
mag has quit [Ping timeout: 265 seconds]
mag has joined #beagle
ft has joined #beagle
brook has joined #beagle
brook has quit [Ping timeout: 268 seconds]
brook has joined #beagle
brook_ has joined #beagle
brook has quit [Read error: Connection reset by peer]
jfsimon1981 has quit [Ping timeout: 260 seconds]
brook_ has quit [Remote host closed the connection]
brook has joined #beagle
jfsimon1981 has joined #beagle
brook has quit [Ping timeout: 265 seconds]
brook has joined #beagle
SJFriedl has joined #beagle
florian has quit [Quit: Ex-Chat]
buzzmarshall has joined #beagle
vagrantc has joined #beagle
SJFriedl has quit [Ping timeout: 244 seconds]
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 246 seconds]
Shadyman has joined #beagle
vagrantc has quit [Quit: leaving]
vagrantc has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 268 seconds]
BB-Flash has joined #beagle
behanw has joined #beagle
<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!
<BB-Flash> I found a RS232 header cable and was able to plug it into the pins and get some info! looks like it's not able to find the flash info on the microSD card.
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 252 seconds]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
javaJake has joined #beagle
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
nparafe has quit [Client Quit]
nparafe has joined #beagle
BB-Flash has quit [Quit: Client closed]
brook has quit [Remote host closed the connection]