00:03 <zmatt> jfsimon1981: presumably they infer the frame has ended based on the higher protocol layer, but that is not how the protocol is specified. the serial protocol layer considers a packet to consist of one address byte, a variable-size payload, and two crc bytes. it considers the payload to be opaque hence has no way to determine the end of a frame other than by recognizing the 3.5-char idle time

00:04 <zmatt> jfsimon1981: so, the device you have is broken, what they implemented is not modbus

00:47 <mewt> Went ahead and grabbed a second BBB to replace dead NIC, will try and troubleshoot more at a later date I guess

00:48 <mewt> I still want to try the near/far loopback modes on the NIC though, maybe later tonight even

01:13 <zmatt> jfsimon1981: anyway, if this thing was sold to you as a modbus device you can perhaps complain loudly to the manufacturer to try to get them to fix it. alternatively, if you want to make it work with extremely tight bus turnaround, your options are either using pru or perhaps use an rs485 transceiver with automatic driver-enable

03:36 <set_> The build is back on! Workin' and workin' to get this daughter card, the Cape, up and out!

03:37 <set_> First, w/out mcu and then...dun, dun, dun, dun. W/ mcu!

07:42 <jfsimon1981> zmatt, yes now that i got it almost working like this, i'll probably polish the solution though. It involved modifying the library. This device works well with other monitorings, i'll see what manufacturer said about it.

09:38 <jfsimon1981> zmat, right, indeed it must not be the modbus spec, it was said to me the device was plugged into a box and properly read.

09:39 <jfsimon1981> zmat, That explains why I had so much trouble making libmodbus work, indeed the default lib. has a parameter for rts which is quite long, that is coherent with the 3.5 char silent.

09:56 <jfsimon1981> I can confirm, the device responds immediately after the request.50 microseconds or less

09:56 <jfsimon1981> That's on boot, single modbus request, first request+response, no possible frame error.

10:31 <set_> Yes!

10:32 <set_> Give it to 'em, jfsimon1981. Shoe that modbus up!

10:32 <set_> For instance...

10:37 <set_> How you say, lemme learneth moreth!

10:38 <set_> Sorry. Off to dabble.

10:39 <zmatt> jfsimon1981: 50 microseconds measured from where exactly? I do hope from the end of the last stop bit and not from the last rising edge (which is at the latest between the parity bit and the stop bit)

10:40 <zmatt> though either way that's insanely short, that's barely a bit-time

10:41 <zmatt> jfsimon1981: I'm honestly surprised this would work with other modbus masters, given how seriously it violates the spec

11:05 <jfsimon1981> i understand they respond as soon as the frame is received in full as you said.

11:06 <jfsimon1981> That and possible the rs485 needs a ground ref although it should not, are - apparently - what cost me 4 weeks delay ! 2 weeks to just understand why the lib modbus did'nt work and 2 to found a way around.

11:06 <jfsimon1981> But not I'm going to implement an accurate delay in the lib, so this workaround can work reliably.

11:07 <zmatt> what do you mean? it sounds like you want to eliminate any delay

11:07 <jfsimon1981> The kernel on BB has "Preempt" flag on. That can be leveraged i hope to make some part deterministic.

11:07 <zmatt> it will probably be worse than letting the kernel handle rts

11:07 <jfsimon1981> I mean RTS needs to be very precise and not wander off by few us as it does not, sometime causing overlap.

11:08 <zmatt> that requires pru or a hardware solution (rs485 transceiver with auto-driver-enable)

11:09 <jfsimon1981> Ye sif kernel can leverage the preempt, otherwise I think it's possible to make a specific usleep() that's not interrupted, though i might be wrong, on bbb thx to preempt (or at least better that the standard library function). i don't know yet

11:09 <zmatt> if using kernel control of rts is not stable enough (using a non-RT kernel may actually be more reliable than an RT kernel for that)

11:09 <jfsimon1981> as you mentionned PRU could be leveraged although i'm verty late on this project now ...

11:10 <zmatt> why are you still talking about usleep? I don't get what you're doing

11:10 <zmatt> and no, you will get interrupted regardless

11:10 <zmatt> since the kernel needs to service the uart interrupts

11:10 <zmatt> which is why allowing the kernel to manage the rts should always be better than doing it in userspace

11:12 <jfsimon1981> libmodbus uses it, and the frames somethime collide due to the way the library implements rts.

11:12 <jfsimon1981> I remind the same happened with letting kernel do.

11:12 <zmatt> sounds like it just sucks

11:12 <jfsimon1981> don't know

11:12 <jfsimon1981> have to make a few tests

11:13 <jfsimon1981> had the probe been implementing this a little better ... anyway.

11:13 <zmatt> honestly, if you really have only one bit-time of turnaround time, I seriously doubt you'll ever get this working properly in linux

11:13 <zmatt> (and from your description it still isn't clear to me whether you even have that much or whether that 50 us is the stop bit)

11:13 <jfsimon1981> i have hope

11:14 <jfsimon1981> can be a little tough but possible i guess

11:14 <zmatt> I sincerely doubt that

11:14 <jfsimon1981> joker is the pru at th emoment

11:14 <zmatt> not reliably

11:15 <zmatt> if you want an easy fix without having to learn to deal with pru, use the hardware solutionI mentioned

11:15 <zmatt> or find a modbus device that isn't broken

11:15 <zmatt> or get the manufacturer to fix their broken device

11:17 <jfsimon1981> client device

11:17 <zmatt> server (slave) device you mean? I thought the bbb was the client (master)

11:17 <jfsimon1981> very specific, we can do nothing about this, it has modbus but also a chemical something converter

11:17 <jfsimon1981> client = customer

11:17 <zmatt> ohhh

11:18 <zmatt> that makes more sense

11:18 <jfsimon1981> the customer probe (which is a slave)

11:19 <zmatt> so have them fix it... can't be that hard to at least insert that 3.5 bit-time delay (which still wouldn't make it behave according to the modbus spec, but would at least make it not insane to deal with)

11:19 <zmatt> before sending a response

11:19 <jfsimon1981> is something very small that i have to read from however this takes me, but the master has more jobs to do hence a linux bb is more a less required. Doing logs, usb writes, little bit passed the edge of what microcontroller alone could do.

11:20 <jfsimon1981> sure, the problem I think this device is implemented in many other oems products so making them to change it, might be possible,

11:20 <jfsimon1981> i asked them about this issue, no response yet

11:20 <zmatt> ughhh

11:20 <zmatt> so they made a hot mess and then made it your problem

11:21 <jfsimon1981> honestly i doubt i get too much support, so i'll work around

11:22 <jfsimon1981> yep i assume many other people have figures out and got it work anyway, or maybe did'nt see the issue because the specific way they implemented, more hardware solution without embedded os.

11:22 <zmatt> still sounds odd to me, normally you'd still have some turnaround time

11:23 <jfsimon1981> cant' request my customer to pay for this troubles ...

11:23 <jfsimon1981> i'll explain to the customer, he's comprehensive at the moment

11:25 <jfsimon1981> i'll post some pix so you can see what'shappening

11:40 <set_> Me too? Can I see?

12:16 <jfsimon1981> Here's the link

12:16 <jfsimon1981> http://jean-francois-simon.com/share/modbus/2022-01-04_Tests.zip

12:17 <jfsimon1981> i'd be interested to have your point of view on those frames ...

12:18 <jfsimon1981> Hardware layer RS-485, protocol Modbus-RTU, 19200 baud, 1 start bit, 1 stop bit, no parity bit.

13:55 <jfsimon1981> behaves worse with the busy timer, tough issue.

13:55 <jfsimon1981> (busy timer is more accurate but keeps cpu busy).

16:24 <jfsimon1981> zmat, kind of working on uart with rts support, seems to be better that the modified lib in user space. Thanks for this hint, I ruled this out a few weeks ago but i certainly had another issue back then. It's running seems about right.

16:25 <jfsimon1981> Will leave it running the com test for a few hours. A few time out and crc errors reports, might acceptable.

19:09 <set_> I made it back after cleaning up sticks! Here is my sign?

19:09 <set_> Oops. Wrong room.

19:09 <set_> BBB!

19:10 <set_> Things are working out for the AI so far. I erased everything on my SD Card and now I am rebuilding so slowly! Wish me luck?

19:10 <set_> tflite and opencv w/ python at the helm!

19:41 <hnv> wow... ´[´ is actually an executable. Cool.

21:49 <nerdboy> okay, what's the latest 2GB flasher image for bbb?

21:49 <nerdboy> am i supposed to use something like this? https://rcn-ee.com/rootfs/bb.org/testing/2022-01-01/bullseye-minimal/am335x-debian-11.2-minimal-armhf-2022-01-01-2gb.img.xz