04:34 <sensille> zyp: how do you mean? cpu time in the communcation functions?

08:22 <zyp> sensille, yes

08:23 <sensille> no idea, can't be much. just building/parsing a smallish udp packet

08:23 <sensille> one per millisecond

08:26 <zyp> I looked at both litehm2, litex-cnc and colorcnc (I think it was called), but neither was entirely what I wanted, so I started my own approach based on a custom ethercat-like protocol where a single packet passes through a chain of devices that rewrites it

08:28 <zyp> because part of what I want to do is distribute IO across multiple boards: https://bin.jvnv.net/file/sOo86.mp4

08:29 <sensille> my approach was to built on the 20+ years maturity of the existing code, host+fpga side

08:31 <zyp> yeah, I get that, it just doesn't suit what I want to do well :)

08:32 <zyp> but I'm curious how the communication performance I'm getting compares to other ethernet-based devices

08:32 <sensille> i found ethercat quite appealing, but was repelled by the patents on it

08:32 <zyp> indeed, that's why I'm not attempting to implement actual ethercat

08:32 <sensille> but nice work if you can already pass packets through both ports

08:35 <zyp> my main goal is to make something to drive this thing: https://bin.jvnv.net/file/2pVce.jpg

08:35 <zyp> by making a custom fpga-based controller card that hooks up to the original power electronics

08:39 <zyp> so I'm making custom hardware, which means I want the flexibility to handle arbitrary ADCs and similar in gateware, so the hm2 approach seems a little constraining

08:40 <zyp> wheras colorcnc/litex-cnc is apparently based on etherbone, which seems like it'll be a performance bottleneck if you've got many signals

09:38 <_florent_> zyp: interesting project! Feel free to share advance/progress here, I'm also interested by this :)

09:39 <_florent_> zyp: Etherbone is indeed probably not the best for your application, it's mostly intended for MMAP.

09:40 <zyp> I've designed it so the devices contains metadata about what signals it got, which types they have and at what offset in the data frame they're located, so I can simply just declare a few signals like this: https://paste.jvnv.net/view/Gy09s and have them show up in linuxcnc: https://bin.jvnv.net/file/WYbrd.png

09:40 <tpb> Title: JVnV Pastebin – View paste – Untitled (at paste.jvnv.net)

09:41 <_florent_> zyp: If you want similar latency than Ethercat, you'll indeed have to have a non-standard MAC.

09:42 <_florent_> zyp: Another possibility if you want to reuse LiteEth could be to have a custom protocol over UDP, ex here with just raw streaming:

09:42 <zyp> yeah, right now I'm using the standard mac, with a custom L3 handler, so each device adds latency corresponding to the preamble and L2 header, plus CDC

09:42 <_florent_> https://twitter.com/enjoy_digital/status/1486381439469957120

09:42 <zyp> so probably on the order of a hundred ns per device

09:43 <zyp> but that drowns in the host side latency, linuxcnc says my data exchange function takes 40-50 us to execute

15:37 <cr1901> _florent_: Did you get a chance to confirm the bug? If not, should I open an issue anyway?

15:38 <cr1901> bisecting could potentially, be difficult, but I'll try

15:39 <sensille> zyp: do you write your own linuxcnc drivers, or intend to do so?

15:43 <zyp> sensille, yes, I did

15:44 <sensille> from scratch or by starting from the existing mess?

15:44 <zyp> I was looking at a few existing drivers for inspiration, but wrote it from scratch

15:44 <sensille> that is quite the feat :)

15:46 <zyp> I think I took a fairly unconventional approach: https://paste.jvnv.net/view/xgWVd :)

15:46 <tpb> Title: JVnV Pastebin – View paste – Untitled (at paste.jvnv.net)

17:29 <sensille> still trying to port to colorlight ... etherbone just works, but the cpu doesn't seem to run

17:49 <_florent_> cr1901: sorry, haven't had time yet, you can open an issue

18:50 <zyp> sensille, what type of uart are you using for the bios console? have you checked it's not just waiting for uart flow control?

18:51 <zyp> a regular hardware uart will output bytes regardless of whether anybody are listening or not, but e.g. the crossover uart will block until it's polled

19:39 <cr1901> _florent_: Ack, will do when I get the chance

20:32 <_florent_> sensille: with the crossover uart, you can use this to avoid it being blocked at startup: https://github.com/360nosc0pe/scope/blob/main/sds1104xe.py#L134

21:05 <sensille> nice. i don't use a bios, though. just a short loop that is supposed to blink the led. i guess i need to learn to simulate with litex. for some miracle that wasn't necessary yet