Jetson Nano as LinuxCNC driver

Mine just arrived. I'm trying to learn how to run Tensorflow models on it, but I'm not averse to getting another one and would be happy to alpha/beta test as needed.

Probably want to check if preempt_rt works with it out of the box - it might need some massaging, but Nvidia should be amenable as it is advertised as a robotics platform...

Also need to see in there's an RTC with hardware timing interrupts, and look at the memory mapping for the GPIO (need direct access to the registers in C for best speed).

This doesn't sound correct - it comes on a 260-pin sodimm-type package, and some of those pins are dedicated to power and ground (figure a number between 1/32 and 1/8 of those pins, so between 8 and 32 would be a pretty reasonable estimate).

The dev-kit board has a RaspberryPi-like 40-pin header, and many of those 260 pins from the Nano module go to HDMI and DisplayPort connectors each using 20-pins, and then Ethernet, M.2 PCI-e...

That accounts for about 160 pins or so, but some of this is admittedly a WAG , the datasheet for the Nano module itself is not public yet. We'll know more in June when the production module is scheduled to be released.

Here was the slide for The Jetson module itself:



Someone took a picture of the DevKit carrier board without the module installed:


You can see the RPi-like header on the left - a UART in the lower right corner, a MIPI camera connector, M.2 e-Key connector (where you'd put WiFi). This shouldn't be a bit issue - there looks to be about 20 or so GPIO pins available on the header (some are claimed by SPI or I2C busses, of which there are multiples). Using very simple low-level logic, you can expand out to many more IO. As an example, you can use a 3-to-8 address decoder to multiplex 16 pins to 8x 16-bit registers. With 8-bit D-type latches , you can do both level-shifting and handle the storage(outputs)+blocking(inputs) of the expanded bits.

With a low level C-driver that has direct access to the memory registers for GPIO (GPIO DMA), you can update all IO bits at once, 16-bits at a time - should be able to hit megahertz speeds for 128-bits at the "bus" - way beyond what LinuxCNC would need. With careful design you can make all of the Outputs update at one time, and simultaneously latch in the Inputs, at roughly 1/16th the Nano's GPIO pin update rate. Using an external clock that runs a counter, you can throw an interrupt to run the low-level parallel bus data driver rather than non-deterministic timing inside the ARM.

You'd still have I2C, SPI, USB, PCIe, and network interfaces available for other uses using this method too. Point is, there's probably a way to get there as long as we can get the core functionality working - the real-time kernel patch, the Nvidia driver playing nice with it, and checking that the system jitter is in spec.

Mine shipped from Sparkfun last week and should be here tomorrow. I'm thinking of going the above route if I can get LinuxCNC to play nice with the Jetson Nano - except I'll probably use a pair of TI DS92LV18 Ser/Des and some standard SFP 1GBe transceiver modules to optically isolate the controller from the power switching drivers. Running the ser/des isolator at 50MHz and clocking in the data from the Nano at 6.25MHz - that gives about a 160nS GPIO refresh rate. Again, assuming it all works

So I got some initial feedback from the support thread on the Nvidia developer forum - they are going to look into the preempt_rt patch, still no details on the GPIO DMA as of yet.

Cross-linking the Nvidia Developer Support Thread here, to track the issue easier . Any others of you who have the Nano Devkit and want to see this, probably not a bad idea to chime in on that thread.

My Jetson Nano devkit arrived, but I'm waiting for an external USB3.0 SSD so I don't run into SD card write wear issues as a primary partition - before I really start beating on it with dev effort. I didn't see anything obvious in the developer notes or code examples for handling GPIO with DMA... it's gotta be in there somewhere as a modern ARM processor.

By some miracle, Nvidia seems to have gotten PREEMPT_RT to work with the latest DevKit in early December (see above cross-linked Nvidia Developer support thread in my last post). I personally was not holding my breath, and I have yet to verify myself, but this could bode well for those of us who want to do real-time Linux control of hardware and want a decent embedded GPU for graphics.

I have a RaspberryPi 4/4GB that I already started doing my build with, but I'll see how easy it is to port over the current effort with the MESA RPi 7C81 baseboard I bought from them back in October. I do have to say I'm interested in the impact on control latency between an SPI operated control system and a PCIe operated control system - I had expected to buy and play with a MESA 6I24-25 as well (which can be run from the Nano's M.2 E-type slot with an adapter).

Hi tim292stro,
Have you had any success migrating your rpi4 project onto jetson nano ? I have patched the nano kernel with rt-preempt but I cant' find any linuxcnc software to run on it.
thx