Raspberry Pi 4

That may be possible, Todd, but we are being told that isolcpu's is not effective on the arms because the call to use an isolated cpu does not exist on the arm's. So the best I can do is IDK.

Skunkworks hello,
I write this to bounce some ideas off another linuxcnc user who has looked at hal_pi_gpio to control steppers.

I have a new rpi4 ( revision c03112 ) and have edited hal_pi_gpio.c to allow it to work. The present hal_pi_gpio lacks pins types of the hal_parport, and thats what I am discussing.

There are other devices that can need generalized gpio driver. I want to allow other devices in the framework.

The BBB as a base would need similar hal_bbb_gpio.
The MCP23s17 is easy and cheap addon hooked onto the pi or BBB run off SPI. I have used 2 pairs of MCP23s17 on RPI3B (not under hal/lcnc, but PiGpio ).
The Arduino and the Pi have been used as _auxilliary_ io by user wicki at erste.de/rasPiCat.

John Kasunich's wonderful parport and hal are the coolest things about linuxcnc. I find his code a bit hard to follow . I'd like to make some simpler more useable generalized gpio driver framework ,given a base address, and an array of bytes holding the features for each pin. I'd like to allow for different devices to be hung off linuxcnc, and to be linuxcnc platforms.
All these differrent devices would need driver(s). I am trying to find a scheme to specify the pins and qualities.

Within a byte, Each pin can have 8 qualities like ...
* bit# 7 6 5 4 3 2 1 0
* msb excluded dir --- out-invert resetable --- --- --- lsb RPI
* msb --- iodir --- ipol --- --- --- --- lsb MCP23S17
* msb --- dir Ain --- --- PWMout --- --- lsb BBB
* msb --- dir Ain --- --- PWMout --- --- lsb ARDUINO

An array of 32 bytes would cover Rpi and MCP23s17, and array of 64 for BBB would suffice.
The 'excluded' feature of the pi could be skipped and the use warned to not use them. .
I think the pullup and pull down features of these devices also can be skipped, just use external resistors as needed.
Empty slots will surely find use if the device list and features grow, So, Its a start.

In use, the array of bytes could be looped thru and pins created. The scheme should work for many devices. Even if seperate drivers were needed for each device, with special functions needed by the device, the overall format would be a skeleton (JMK thx again) that would reduce the pain to make a new driver.

There's 26 gpio pins on the RPi. 18 of those could be step and dir for 9 axis. There's 65 gpio on a BBB. Four MCP23s17s can add 64 gpio for the cost of 4 lines and 4 selects using SPI at rates plenty fast for user i/o. Thats a load of potential only needing some SMOP (hahahaha)

any thoughts?
tomp

Hello

I have been following this thread with interest for some time.

I'm currently playing with with optimising latency for the RT Buster for Pi4 ( and poss Pi3 as well)
From here
github.com/guysoft/RealtimePi
An RT but otherwise stock RT kernel

Using Debian <rt-tests> Cyclic
cyclictest -n -p 90 -i 1000
Duration: circa 2hrs each

I have:
wlan OFF
BT OFF
Screensaver OFF
cpu frequency locked to 1GHz ( constant, no governor)

Best I can manage is:
GUI: On , heavy usage GLX gears, browser, etc circa 90% constant load
440us
GUI: On modest to light usage usage Av 10 ~40% intermittent load
210uS
CLI Only: (no gui at all)
60uS

What manner of alchemy and magic are you guys employing to get the quoted latency figures of 16uS ?
I'm Obviously missing some some important tricks?
Do tell

Cheers
MrGreg

That gent has apparently lost interest. If you want a preemp-rt kernel for an rpi4b, get it from my page in the sig, by adding lathe-stf to the address bar, then click on the linuxcnc4pi4b directory you'll see. download rt-kernel.tgz. Install raspbian-full to a 64G card, update it, put the rt file in / and unpack it. reboot, latency is around 16 microseconds, better than good enough to run using mesa cards.

Linuxcnc-master (last 2.9.0-pre built on and running on that rpi4b is also there. e my guest. But I've a small pipe, so its not fast. But that kernel install is only 149 megs, so its pretty quick. Have fun.

Hello & Thanks

Trying your RT with linuxcnc was on my To Do list.Now near the top! I will try it out over the next day or two.

I'm currently using Picnc & Jessie 4.4.4RT Both of which are sliding into bitrot. Having said that they do work very well for my use case. The Pi4 + Mesa 7c8x solution looks a very attractive replacement if the Picnc cannot be revived and updated.
I don't think Guysoft set out to do anything more than make and publish an RT based on the Raspbian stock kernel.

I'm still in the exploration phase ATM. So trying stuff as it evolves.

Any further comments - suggestions on optimisation of the otherwise stock Buster RT would be appreciated.

Thanks for sharing and publishing you work.
I'm sure I will be back to ask more questions

Cheers
MrGreg

MrGreg wrote: Hello & Thanks

Trying your RT with linuxcnc was on my To Do list.Now near the top! I will try it out over the next day or two.

I'm currently using Picnc & Jessie 4.4.4RT Both of which are sliding into bitrot. Having said that they do work very well for my use case. The Pi4 + Mesa 7c8x solution looks a very attractive replacement if the Picnc cannot be revived and updated.
I don't think Guysoft set out to do anything more than make and publish an RT based on the Raspbian stock kernel.

I'm still in the exploration phase ATM. So trying stuff as it evolves.

Any further comments - suggestions on optimisation of the otherwise stock Buster RT would be appreciated.

Thanks for sharing and publishing you work.
I'm sure I will be back to ask more questions
=====
This kernel supports the new, about 20x faster video modes, just select it in raspi-config after the upgrade has been done. 60 fps from glxgears at full screen.

Due to missing dependencies, gscreen is not supported, but axis with pyvcp gingerbread for a gui works great.

Cheers
MrGreg