**** BEGIN LOGGING AT Thu Dec 30 02:59:56 2021 Dec 30 10:48:43 Hello! Let's say I'd want to design a beaglebone expansion cape that has additional USB ports - is that possible? I guess I need something like a SPI USB Hub? Any IC recommendations? Dec 30 10:49:21 that's not really a thing, usb is way way faster than spi can handle Dec 30 10:49:59 USB 2 would be enough for me Dec 30 10:50:50 So no chance? Only the given USB ports on the beagle are available? Dec 30 10:50:56 usb 2 is 480Mbps, half the bitrate of gigabit ethernet Dec 30 10:52:33 usb 2 requires pretty careful pcb design because of its high bandwidth, running it over expansion header pins like those on the BBB would butcher its signal integrity Dec 30 10:54:03 Ok I see Dec 30 10:54:24 You think it's possible with USB1 speeds? Dec 30 10:55:40 doesn't really matter since there's no usb port pinned out on the expansion headers... the am335x has two usb ports, both are connected directly to usb connectors (one for the mini-usb-B device port, one for the usb-A host port) Dec 30 10:56:45 How do they do it? https://www.coolgear.com/product/beaglebone-black-usb-expansion-rs232-module Dec 30 10:57:17 see that usb cable attached? it plugs into the BBB's usb host port Dec 30 10:57:46 what a weird cape, never seen this before Dec 30 10:58:17 Ahh ok! Yeah thats messy Dec 30 10:59:31 looks like this is purely a usb device that does nothing with the cape headers other than to draw power Dec 30 10:59:49 Speaking of strange capes - this one claims to extend the usb ports https://nimbelink.com/products/skywire-beaglebone-black-cape/ Dec 30 11:02:01 same deal, it connects to the bbb's usb host port Dec 30 11:03:07 with a cable Dec 30 11:03:19 see https://nimbelink.com/Documentation/Development_Kits/NL-AB-BBBC/30149_NL-AB-BBBC_DataSheet.pdf page 9 Dec 30 11:04:06 Oh yes you're right Dec 30 11:04:57 Ok thanks a lot - then this is how I will do it, too Dec 30 11:27:44 Hello Dec 30 11:27:53 I am trying to do PCIe communication between Beagle board x15 (which uses Sitara processor - am572x) and layer scape board (LS1043ARDB). Dec 30 11:28:55 I configured beagle board as endpoint and layer scape board as Root complex. Can any one suggest me the driver for endpoint to be used in Root complex. Dec 30 11:49:11 Ramesh: might want to try the TI e2e forum instead Dec 30 12:10:16 Ok Dec 30 14:41:29 zmatt, looks like balena fix the null bug... https://github.com/balena-io/etcher/blob/master/CHANGELOG.md?d_id=0b9c7200-eb39-4f83-91f2-08408852be61R Dec 30 14:52:37 rcn-ee: lol, did you see the commit? https://github.com/balena-io/etcher/pull/3667/files Dec 30 14:53:15 error is typed as Error | undefined, so whoever is calling it with null as first argument is committing a type error Dec 30 14:58:54 zmatt, didn't look to far into it.. the null actually doesn't break our image.. Dec 30 15:00:56 sudoPrompt.exec()'s callback arg is typed as (error?: Error, stdout?: string | Buffer, stderr?: string | Buffer) => void Dec 30 15:01:14 so it too is claiming null is not permitted Dec 30 18:17:47 Good evening, is the default kernel of a Beagle Board -RT (preemp real time) ? Dec 30 18:18:17 no, -rt is a bad default choice Dec 30 18:18:23 but you can install an -rt kernel if you wish Dec 30 18:37:50 ok thanks Dec 30 18:39:25 trying to make an accurate delay for rts signal purpose (usleep() is not giving exactly expected delay and for this signal, it has to e within about 5us ideally). Dec 30 18:39:56 that's not going to happen to linux userspace, pru is well-suited for that sort of thing Dec 30 18:40:00 *in linux userspace Dec 30 18:41:35 ok Dec 30 18:42:21 doing a few tests in sw, and keep in mind the hw pru, thx for the tip Dec 30 18:51:45 jfsimon1981: iirc I had about 40-80us latency from gpio-triggered interrupt to userspace last time I tested an rt kernel (long time ago) Dec 30 18:54:00 i got recently 5 us period when switching 1/0 on gpio, pretty good. Issue lies in usleep(). Dec 30 19:01:33 5 us period when switching a gpio? that sounds awful Dec 30 19:01:54 no, the issue lies in trying to create accurate timing in linux userspace Dec 30 19:02:15 even if you get it working most of the time, you'll still get random delays at random moments Dec 30 19:02:42 jfsimon1981, switching i/o in real time... PRU?>... Dec 30 19:02:59 that's what I said, this is exactly the sort of thing pru is excellent for Dec 30 19:06:16 pru can get you 5 _nanosecond_ timing accuracy with a bit of effort. even with some lazy C code and no attention paid to efficiency you'll still get small-fraction-of-microsecond accuracy Dec 30 19:27:20 correct Dec 30 19:28:08 timing gets sometimes prempted, but I got one good candidate delay function, gets very accurate most of the time. Still conducting tests on it Dec 30 19:28:49 pru is programmeble timer, i have no clue yet how to make that work Dec 30 19:29:18 Yep 5 us period (4.6) is the shortest we can do with c/c++ using gpio file Dec 30 19:29:23 pru is a programmable microprocessor Dec 30 19:30:17 designed for real-time tasks, especially i/o (it has dedicated gpios wired directly into register) Dec 30 19:30:58 you can generate a 5ns pulse in software on pru Dec 30 19:31:40 yes i grab it Dec 30 19:32:02 as you say it's little bit more work but that sounds the right solution Dec 30 19:32:20 there's a bit of learning curve to get used to it I guess Dec 30 19:34:06 I've created a python library that can not only load code onto it but also directly inspect and poke the subsystem and the cores within it, which can useful both for learning and for practical purposes: https://github.com/mvduin/py-uio Dec 30 19:34:25 unfortunately there's not much documentation Dec 30 19:36:14 dealing with libmodbus half duplex and having issue with RTS timing, which needs to be precisely switching after a calculated time eg 520 us. Though there seems to be more accurate than usleep() for delay, Dec 30 19:38:18 Found busySleep() which gets better, close within 0.1% or so. Though once in a while the os gets work done and the delay get 100u or even 1ms. Dec 30 19:38:46 I'll conduct tests on beagle board with modified library. If that does'nt do the job then I'll try work with the PRU and thanks for sharing the py library. Dec 30 19:39:31 yeah, busywaiting wastes cpu time so linux will be more likely to interrupt you Dec 30 19:41:16 pruss also has a local high-speed uart in the subsystem (up to 12 Mbaud if I remember correctly) Dec 30 19:41:45 yeah Dec 30 19:44:39 i'll probably need to check the pru and make it work, cause when the modbus line goes wrong, the client device gets confused and starts replying on older messages, until by any luck it gets working back after a while. Dec 30 19:45:25 For a customer project that needs be fixed, either on BBB side or the RS 485 controller. Dec 30 19:45:45 is the bbb the master or the slave? Dec 30 19:47:13 it's the master Dec 30 19:48:49 is the kernel's rs485 functionality (kernel-controlled driver-enable via rts) also inadequate? surely it'll have better timing than doing it in userspace Dec 30 19:49:49 i see, it had the same issue Dec 30 19:50:06 both of them showed a similar delay if memorry serves well Dec 30 19:50:32 you mean uart with rts variant Dec 30 19:50:42 what exactly is this delay you say you need to do precisely anyway? I'd normally expect an 485 master to just need to disable DE fast enough after transmitting a request (to free up the line for the slave to reply) Dec 30 19:50:53 rts release Dec 30 19:50:56 and keep appropriate minimum spacing between requests Dec 30 19:51:00 so why do you need a delay? Dec 30 19:51:14 don't you want to release it asap after the serial transmission is done? Dec 30 19:51:48 it must be released as soon as transmit done, though in libmodus they calculate this delay, request uart to send data, then wait and release rts Dec 30 19:52:08 the uart would be working in the background and both should get done simultanesouly Dec 30 19:52:09 that sounds like it'll always be worse than letting the kernel handle it Dec 30 19:52:45 yep sounds like i remind uart-rts did'nt work, but need to do tests again. I did'nt get note of the time results. Dec 30 19:52:54 the kernel knows when the transmission is done and can immediately deassert rts, instead of guessing the timing Dec 30 19:53:52 it still won't be the sort of tight timing pru can get you, but it should be substantially better than anything you do in userspace Dec 30 19:54:04 i don't remember exactly, it did'nt get exact that way too, but i need to grab a bb and the scope to measure. Dec 30 19:55:39 i'll test back uart-rts on scope to make sure. Dec 30 19:57:02 make sure delay before/after send is configured to zero Dec 30 19:57:38 of course it's entirely possible the kernel driver is just shit Dec 30 19:57:55 my statement above is under the assumption the driver doesn't suck Dec 30 19:59:07 right that's what i want to tackle again, i didn't test thouroughly on that one Dec 30 20:02:00 Took a while to understand what was going on, the half duplex line had mixed signals for a short while. after poking for a few days i tackled to rts timing, but the work arounds really aren't good, i just added -100us in the delay which made it kind of work 70% of the time. Dec 30 20:02:39 uhh Dec 30 20:02:52 that just sounds like something is borked Dec 30 20:04:24 when the serial port is configured into rs485 mode, the kernel will assert rts prior to transmission (with configurable delay between asserting rts and starting transmittion) and deassert it once transmission is done (again with configurable delay, which you'll want to be set to zero) Dec 30 20:04:45 (polarity of rts signal is configurable) Dec 30 20:06:37 all userspace has to do is setup/enable the mode and then just write data, wait until transmit completes (with tcdrain() I think) and then wait for a response (if unicast) or wait for the minimum required delay until the next request Dec 30 20:07:16 as far as I know Dec 30 20:07:37 right, once the message is sent, the client device immediately sends a reponse, and the rts gets too long to release the line, thus transmis on bbb and client device for about 100us or so. This puts the wrong response bits for maybe a few bits, and then CRC complains and the message is discarded. Dec 30 20:08:06 Sot the RTS is too long to release the line by just a few us. Dec 30 20:08:13 how long does the kernel keep rts asserted after transmit? Dec 30 20:09:46 what baudrate are you using? Dec 30 20:12:35 the line is 19.2 Dec 30 20:12:37 kb Dec 30 20:13:15 sending 8 bytes expected 520us and getting little more than that Dec 30 20:14:37 how much is "a little more" ? how long the driver remaining enabled after the last byte? Dec 30 20:14:41 *how long is Dec 30 20:15:41 in the begining this was 100us Dec 30 20:17:04 that's only 2 character times... modbus requires 3.5 character times for the bus to be considered idle (i.e. end of frame) if I understand this document correctly Dec 30 20:17:23 am I saying that right, wait no Dec 30 20:17:28 uhh Dec 30 20:17:46 19.2 kbaud means 52 μs per _bit_ Dec 30 20:18:25 yep i still don't understand, the timing looks like it needs be tight. You are right I missed that. Dec 30 20:18:34 I did an arbitrary function generator, using a combination of a rt kernel, PRU, ePWM and an external DAC. It worked reasonably well. The code was a bit messy though Dec 30 20:18:40 573us per byte Dec 30 20:19:49 A while ago.. zmatt helped me a lot with that Dec 30 20:20:05 jfsimon1981: so again, if I understand the spec correctly, end of packet is signalled by >=3.5 character times of bus idle, which is 2ms Dec 30 20:20:22 Yet if I get the rts a little bit sooner, the client does not get all message and hangs. But there must be a 3.5 bit delay roughly 30us. Dec 30 20:20:34 doesn't make sense. Dec 30 20:20:39 3.5 *byte* Dec 30 20:21:07 11 bits per byte (including start, parity, and stop) Dec 30 20:21:12 52 us per bit Dec 30 20:21:30 so you're right that something is not making sense about what you're saying Dec 30 20:21:50 you should have plenty of time Dec 30 20:22:16 yep i must conduct new tests, but i take note on the stop delay which i forgot has to be present Dec 30 20:23:21 it looks the client device does'nt wait for that to happen and responds anyway, but with that in mind i'll check in detail on scope what's going on Dec 30 20:23:38 how can it respond to a packet if it doesn't know the packet has ended yet? Dec 30 20:25:48 let me check scop pix Dec 30 20:26:18 and maybe test with the simplest possible program rather than some library, e.g. just enable rs485 mode (https://pastebin.com/r1rJFUfr) and do a write(), tcdrain(), and optionally read the response Dec 30 20:27:06 check the timing of RTS relative to transmitted data, and if you have a third channel then record rxd as well Dec 30 20:32:28 https://jean-francois-simon.com/share/mat/scope-2021-11-26.zip Dec 30 20:33:56 I have no idea what I'm looking at... does this scope have only a single channel? Dec 30 20:34:19 the stop time looks like 150us thereabout Dec 30 20:34:21 this is also way too zoomed in Dec 30 20:34:30 I have no idea what the timing of anything is here Dec 30 20:35:12 the left signal is sent by bbb. Then there's a stop, and a response. The voltage on response lies about 200 mv below. Dec 30 20:35:22 where is this being measured? Dec 30 20:35:37 this looks inverted Dec 30 20:36:05 ah it might be, that's the RS485 half duplex line Dec 30 20:36:12 does your scope have only a single channel? Dec 30 20:36:19 (A-B) Dec 30 20:36:30 there are 2 channels. Dec 30 20:36:44 then capture txd and rts from the beaglebone Dec 30 20:37:21 and just send a single frame, capture it in its entirety... trigger on rts is probably useful Dec 30 20:38:14 doesn't even have to be a valid frame, all we care about first is what the rts timing relative to the data looks like Dec 30 20:42:24 on picture 7700 the rts signal went down on the first vertical bar, then client responded on second vertical bar Dec 30 20:43:10 these images are not useful to me, they show tiny snippets of the bus with unknown context/history Dec 30 20:43:15 At the time (last month), i did'nt take the pictures with rts, but i check with rts on second channel. At the moment the lab is'nt setup to work. Dec 30 20:43:29 yep Dec 30 20:44:13 i can do better in a while, i was moving home recently thus the lab is'nt yet deploed to work. Will be shortly Dec 30 20:45:14 will take a couple of days to be back into business Dec 30 20:45:31 the slave transmitting right when the master is making a request means either 1. the slave is broken, or 2. the master is doing nonsense (e.g. sending a request and then without waiting for the slave's reply send another one right as the slave is about to reply) Dec 30 20:45:53 based on your descriptions with weird delays, 2 sounds plausible enough to me Dec 30 20:46:11 hence my emphasis on doing a single isolated request as first test Dec 30 20:46:51 and really, first we want to see what the master does in isolation, i.e. what it's doing with txd and rxd Dec 30 20:47:10 if that's not okay, there's no point in looking at the interaction with the slave Dec 30 20:47:25 solve one problem at a time Dec 30 20:48:44 We can see the issue picture 7692, the master (bb) still hold the line with rts although the uart has sent the message. Between the two vertical bars stand a short period where tx on BBB and client both are on. Dec 30 20:49:52 bbb and slave you mean? Dec 30 20:49:57 I'll need more tests to get a clear understanding. Dec 30 20:50:03 Slave is a client device Dec 30 20:50:26 I don't know what you mean by that Dec 30 20:50:36 anyway, like I said I can't tell anything from this image Dec 30 20:50:40 bbb is the master Dec 30 20:51:01 since I don't know how much time has passed since the end of the last byte transmitted by the master Dec 30 20:51:03 the client probe is the client on half duplex line Dec 30 20:51:11 ??? Dec 30 20:51:31 what do you mean by "client". there's a master and a slave Dec 30 20:51:42 modbus host (bbb) query a client through modbus rtu Dec 30 20:51:53 thus rs485 line (half duplex) Dec 30 20:51:56 okay, these are modbus terms? Dec 30 20:52:18 yes i think so, little bit confusing terms somehow Dec 30 20:52:26 master-slave Dec 30 20:52:36 yes the term makes no sense to me, I'd expect a client to be a piece of software running on the host Dec 30 20:52:39 master is bbb Dec 30 20:52:45 (i.e. the master) Dec 30 20:53:22 yes, it sends a request to a node on the bus, which responds immediately Dec 30 20:53:31 yes, that's called a slave Dec 30 20:53:33 not a client Dec 30 20:53:43 right a slave Dec 30 20:54:32 i mixed up with server/client, that's used with tcp Dec 30 20:55:40 anyway, like I said, capture txd + rts on separate channels, and with a simple test rather than libmodbus preferably since your description of it sounds like it's doing weird stuff Dec 30 20:56:27 focus on verifying that the master is not holding the driver enabled _excessively_ long,... though I really doubt that given that even 1.5ms is still okay Dec 30 20:57:29 it's probably much less than that Dec 30 20:58:04 where does 1.5 ms come from ? Dec 30 20:58:14 if that's confirmed to be okay then try a _single_ request/response exchange with the slave Dec 30 20:58:29 zoom out to confirm there's no activity prior to the request of interest Dec 30 20:58:36 (or just trigger on rts) Dec 30 20:59:07 or on data rather, can't trigger on rts if you're going to examine txd + rxd (which is probably easier to read than scoping the bus itself) Dec 30 20:59:51 why did you mention 1.5 ms, where does the value come from ? Dec 30 20:59:53 3.5 character times * 11 bits/character (including start/parity/stop) * 52 us/bit Dec 30 21:00:06 right Dec 30 21:00:13 is 2 ms Dec 30 21:00:31 but you want some margin obviously Dec 30 21:02:02 also I don't think the spec was 100% clear about what they means by character time, and they suggested using 1.75ms inter-frame delay when using baudrates greater than 19.2 kbps Dec 30 21:02:16 recommended rather, not suggested Dec 30 21:02:58 thanks, i need to check in detail, indeed there was no 2ms wait as far as i checked. Dec 30 21:03:09 well there doesn't need to be one as such Dec 30 21:03:38 if you're doing a request to the slave, it's the slave who has to wait that amount to determine end of transmission of your request, at which point it can send the response Dec 30 21:03:39 ok i'll check with various configurations anyway Dec 30 21:04:05 so all that matters for the master is that it doesn't take _more_ than 2ms to disable its driver after the last byte Dec 30 21:04:31 yep it appears it waits for 150ms instead of about 2ms. I might be wrong, have to setup the bench and to additional tests. Dec 30 21:04:48 it can spend much more time than 2ms of course if its wants Dec 30 21:04:56 up to some timeout Dec 30 21:05:04 yep and 2ms does'nt need extra work, that far within the usleep() margins Dec 30 21:05:24 but it can't spend _less_ than 2ms since it can't have recognized end of transmission yet Dec 30 21:05:35 again, there's no delay here in the master Dec 30 21:05:53 however the slave appears to skip the delay, but i may be in touch with the manufacturer as well to get clarificaiton on this. Dec 30 21:05:54 the master just sends data and waits for reply Dec 30 21:06:23 I'd start by making sure you're not just sending nonsense to the slave like I explained earlier Dec 30 21:06:47 your scope pics are zoomed-in close ups so we can't tell what happened earlier Dec 30 21:06:48 thanks for this clarification, I totally missed this delay, I though 150us was good per spec. Dec 30 21:07:39 150us is 3 bit times... that's a normal allowable amount of delay between bytes and definitely not enough to mark end of frame Dec 30 21:07:42 For instance 7697 is the zoomed out slave response Dec 30 21:08:13 it's the master I'm concerned about Dec 30 21:08:28 but i can do better, once i get to dive into the matter and labo alive again Dec 30 21:08:41 again, first check the master by itself Dec 30 21:08:58 then a _single_ request/response interaction with the slave Dec 30 21:08:58 sure i don't seem to have pics on th emaster Dec 30 21:09:39 I can't stress that enough since misbehaviour from the master seems the most likely explanation to me at this point Dec 30 21:10:36 https://jean-francois-simon.com/share/mat/1920p_IMG_7651.JPG Dec 30 21:11:01 that one was taken from a full frame master/slave Dec 30 21:11:37 and how certain are you there's zero activity from the master prior to this bit you captured? Dec 30 21:12:38 (I can't tell if this is single acquisition or auto acquisition) Dec 30 21:13:26 it's a few seconds sparse requests Dec 30 21:13:37 acquisition mode Dec 30 21:13:46 the scope I mean Dec 30 21:14:09 it's been working in acquisition on this picture Dec 30 21:14:24 ??? Dec 30 21:14:56 also, this is skipping ahead again, do step 1 first Dec 30 21:15:41 this picture was taken from a single request/response between bbb and slave Dec 30 21:16:14 like, if this isn't caused by misbehaviour from the master (sending requests without waiting for the previous response) then the only other explanation is that the slave is _completely_ broken and doesn't even remotely implement modbus Dec 30 21:16:32 the bbb has sent a ~ 4ms message and received a ~ 7 ms resopnse. There is no 3.5 char wait. Dec 30 21:16:36 a single request/response wasn't step 1, it was step 2 Dec 30 21:17:21 as I mention, those are old pictures. Dec 30 21:17:37 at the moment I can't do live testing. Dec 30 21:17:43 yeah so that's not modbus since a modbus slave cannot reply until it sees the 3.5 char wait, since the packets are variable-length and the only way to know that the packet has ended (which you need to even be able to check the CRC) is by seeing the 3.5 ms idle time Dec 30 21:17:44 sorry about this Dec 30 21:17:51 then you'll have you wait until you can do live testing Dec 30 21:17:56 debugging blind is useless Dec 30 21:18:14 I'm simply outlining what I recommend you test once you do have the ability again Dec 30 21:18:57 but you got a right point. Dec 30 21:19:11 btw, implementing a proper spec-compliant modbus receiver (with correct error handling) is _definitely_ not possible in linux, that can only be done by pru Dec 30 21:19:31 well Dec 30 21:19:41 I think I had issues with the slave reponding to older messages, so it's possible there's a coincidence the request and response are close by on this picture. Dec 30 21:20:06 it requires being able to tell the size of small gaps between characters Dec 30 21:20:08 received Dec 30 21:20:33 I mean this is probably the reponse to a previous request far back in time 2ms before. That, I did'nt check. Dec 30 21:20:33 yes, that's the only thing that makes sense to me Dec 30 21:20:47 hence my stress on _single_ request/response Dec 30 21:21:08 but I observed I got responses from a different request. Dec 30 21:21:28 i check my source code again ... Dec 30 21:21:30 that makes sense if the slave was simply still busy processing your earlier request and preparing the response Dec 30 21:21:40 i.e. if your master code was just too impatient Dec 30 21:21:56 and you went ahead and sent the next request Dec 30 21:27:20 indeed, the manual calls for 10s wait timeout, which i did'nt respect Dec 30 21:27:34 there ya go Dec 30 21:27:41 patience is a virtue Dec 30 21:27:55 gosh that may be the point Dec 30 21:28:52 well spotted i'll modify the code on this. Dec 30 21:30:11 Thx for that Dec 30 21:35:58 night Dec 31 00:48:32 I made it back in once piece! Geaux BBB! **** ENDING LOGGING AT Fri Dec 31 02:59:56 2021