LinuxCNC RT blindspots (I2C and UART/Serial)

There's been a couple of things I was thinking about for a while and the more I dig in the more I wonder about why they haven't become a thing with LinuxCNC. When I have other uses for something I tend to think "will this work with LinuxCNC too?" I suppose everyone gets used to doing things a certain way and only pick up new things if they are the hot new thing (like EtherCAT). There are probably a couple of interfaces that are "just there" that should technically be fully realtime capable. I think alot of it also stems from the fact that when people were using parallel ports on desktop motherboards, Mesa popped up with PCI and Ethernet cards and that's just the way it went. Nowadays I like to use mini-PCs like Odroid H3/H4, I still use some H2's as well. These have UART and I2C ports right on the "GPIO" header, interestingly the GPIO header doesn't actually have GPIO. I use these because they're cheap, small and have 2 ethernet ports. I would still use a Mesa Ethernet card for most bigger things but I run into alot of cases where they don't have anything convenient to use in the place I want to use it. The reason (besides being readily available) that I would think about UART and I2C is that they are simple and easier to deal with for something custom.

Unless I'm missing something, both UART and I2C should be fully realtime capable. Niether is the fastest interface out there but I don't think they really have to be. The appeal for I2C is there are already a bunch of kernel drivers for specific ICs, IO expanders like MCP23017. Currently these are only used in userspace components etc., but if the interrupt output is used I think it can meet RT expectations, especially if you can run the bus at 1Mhz+. I've gotten these IO expanders to work with the kernel driver on the H-series as I needed something to register as a gpiochip for use with other kernel drivers. The LinuxCNC RT bits just don't exist yet. The thing about it is there are clockgens, ADCs, etc,  that all have kernel drivers. There obviously needs to be a hal compenent for this stuff, I'm going to play with it soon but what it seems to me is that if the HAL environment existed, you could literally breadboard a controller based on just I2C chips that have suitable kernel drivers. There's a limit of chips that can be strung in there before transaction queues start to build up but besides that, I think this could be a thing. SPI could be used in much the same vein as many I2C chips have SPI variants and generally have an associated kernel driver.

UART/Serial is also probably realtime capable as a host interface (NOT USB serial). Again Ethernet is better but AFAIK I think Intel UARTs can be run at over 3 Mbaud, that's pretty quick but I'll have to test that as I've never actually seen or heard of it being done. I wouldn't expect this to be super popular since again there are better ways to do this but the main reason I'd want to use UART is for a control panel host. Right now I'm using Arduino Connector to a custom board running a Teensy 4.1. It works, it's fine but Arduino Connector is userspace/Python. Typical use is with the USB serial port, should be usable with a UART instead but probably not gaining anything being userspace. I'd like to replace Arduino Connector with a realtime UART setup to the Teensy board. At this point I'll probably just switch to an ESP32 S3 for other reasons but I don't want to deal with anything like Ethernet. This is something else that needs HAL implimentation but I will start with some simple tests just to see what I can do with it.

I'm curious if I'm missing anything from a bus/hardware perspective. I'm not concerned with why these aren't already popular choices, I think I've already mentioned that. More concerned with what I might be missing as far as implimenting them goes. I can't find a great reason why either of these wouldn't be perfectly fine to use as RT interfaces, albeit with some limitations.

 

andypugh wrote:

This isn't an answer to your question, but have you tried hal_gpio on the Odroid?

 

Actually no, I knew of the component but I don't think it dawned on me that it used gpiod. In that case it would certainly work for something like an MCP23017 or a different I2C IO expander. The catch there is I don't know if it would technically be "realtime" unless an IRQ was attached via interrupt GPIO. I believe that specific driver will run in polling mode if an IRQ isn't attached. I could be wrong about that. This would be limited to GPIO as they have to register as gpiochips. In my head I was thinking of a component that would pretty much do exactly this but be expanded out to use other types of chips like clockgens and ADCs. Some clockgens have good command control so they could be used like a Mesa stepgen with a GPIO pin for direction. Maybe it's better just to split up the components but then it's the whole segmentation thing, I've been messing with LinuxCNC for about a decade and it didn't even dawn on me that hal_gpio used gpiod. So it'd be great to do an all-in-one component but that might get very messy making sure all the drivers are loaded etc.

andypugh post=335457 userid=723I was actually wondering the same thing about the serial port las month:

sourceforge.net/p/emc/mailman/emc-develo...arg.org/#msg59226340

Maybe a realtime modbus driver through the onboard serial port could work, for example.

If you can drive the serial port by sending bytes with outb() / inb() it might work, though you would end up having to re-invent the drivers as non-blocking code.

I've been asking about RT serial around here for over a year now, you're popped in on one or 2 of the threads. I definately would not use modbus. RS485 is (generally) half duplex and requires flow control, it's multi-drop, etc. I don't think Modbus can ever be any more realtime than USB but I could be wrong. My Idea for using UART is single host interface just like Mesa SmartSerial and just sticking to simple full duplex just as Smart Serial does.

I've been banging chatgpt from every direction on the UART thing and the result is the Intel 8250 driver is pretty much perfect as is for real time with a custom protocol. Might sound like blasphemy to someone like you who know what they're doing but I've found that if you hit the bot with enough contention you can come up with fairly solid answers in the end. Seems just plain UART with the FIFO interrupts is just fine, no hardware flow control or anything else required.

Another somewhat sticky point that I didn't bother mentioning above is because there is no real GPIO on the H-series boards I need to get creative for a hardware interrupt for the I2C chips. These don't have a GPIO controller like some other boards do. It seems the CTS (and RTS) pins can be stolen from the UART and repurposed and likely still have a usable UART just without flow control. So I actually need a kernel module to set that up. That's what actually got me back on this kick, I was messing with an vendor I2C touchscreen kernel driver. That requires the I2C bus with an INT (IRQ input) and RES (output) GPIO pins. I was able to get about halfway there hanging the IO expander off the I2C bus and binding the MCP pins as the IO it almost worked, problem was I couldn't generate a real interrupt without an single IRQ capable input pin so I gave up at the time. Once I realized I might be able to steal the CTS pin for the I2C interrupt it snowballed back into me thinking "can I get this stuff working in LinuxCNC?"

So at the moment I'm just trying to get the CTS interrupt working with the MCP23017. If that works I might just try it out with the hal_gpio component. At some point I'll see if I can get a basic RT UART comp going. Once I know it all will probably work I'll try making it useful.