Raspberry Pi 4

russell wrote:

I don't mind buying a Mesa daughter card except that I will have to import one as they are not available in the UK, so I would like to do some proof of concept testing first.

I do have an old buffered parallel port break out board knocking around I could use but how do I configure the hostmot2 component to tell it about the new encoders?

Is the 7I85 the most appropriate card to add 2 encoders?

Thanks
Russell

I will add some new firmware files for the 7C80 sometime this week
I will support common parallel port BOBs on the expansion port

Its not easy to add 2 encoders to most parallel port BOBs because
in the normal mode, there are only 5 inputs available

A 7I85, 7I85S or 7I89 are all possibilities for adding multiple encoders using Mesa daughtercards

For now the best kernel used is the Gene one (on his repo) I don't know what you did Gene but it's 25% faster than a classic RT kernel. Can you describe your tweaks on please ?

I'm trying to compile only RTAPI and Hal but it's not easy if someone did it or have a special makefile i would be very happy if he could share it with me.

I succefully compiled a SPI hostmot2 firmware for an XC6SLX25 with 96 I/O. Just have to try it on Linuxcnc when i will have time.....

for starters search back thru the raspbian forum to find the latest src for realtime. They supply that but do not build or otherwise support it. Its armhf which is good, It will be named linux-rpi-4.19.y.zip although the rpi might be a rename by me. And its a moving target, the last I built it on Feb 6th, the y stood for 71.

Then John Thorntons build recipe says to make bcm2711_defconfig (because he was buuilding on a pi3 I guess BUT when it discovers its actually running on a pi4b it corrects your "typo" and uses bcm_2835, which is correct. but if you do it directly, didn't work. Go figure. Then I ran it thru a make menuconfig and turned stuff off or on here and there, stuff I knew I didn't need building it special for only the pi4. No sense building for every armhf on the planet IOW.

Now I'll stop because my pi has stuff attached yours doesn't, the list is:
1; A 240G SSD, plugged into one of the usb3 (blue) ports with a StarTech usb3 to sata adapter, formatted ext4 and mounted in the /etc/fstab as /media/pi/workspace which is where all this build takes place, several times faster than using the u-sd, and many times easier on the u-sd card.

2; Another 120G SSD with 3 partitions, only on of which is important here, the 2nd partition is 10G formatted as swap and mounted as swap in the /etc/fstab as swap with a line resembling this in the fstab:

UUID=746054d4-9a33-4c79-b028-ff0000c3e40a none swap 0 0

The workspace line is:
PARTUUID=c61252a1-01 /media/pi/workspace ext4 defaults 0 1

And turn off the swapfile, instructions are in the fstab file

Now reboot the and verify you got it right. A sudo mount report should contain a line like this:
/dev/sdb1 on /media/pi/workspace type ext4 (rw,relatime,stripe=8191)
And htop which you'll probably have to install, should show around 10G of swap in the upper left panel.

Now you are ready to "make" this and that according to JT's recipe, when its all installed, you can reboot, and a uname -a ought to look more or less like this:
Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l GNU/Linux
Latentcy here is now about 16 u-s, and you are ready to build and install linuxcnc.

There is a recipe for that in the wiki.linuxcnc.org. There are some dependency's you'll need to install or if apt can't find them, remove from debian/bottom.in or whatever, its in the wiki article. 2 deps you'll need to remove, which blocks printing from classicladder and kills gmocapy, runs fine with axis.

I'll try and get the built tarball put up today, which if I do it right should unpack from / to install itself in boot, its about 1% of what the other image was to download.

I hope this helps.

Thanks Gene for this fast answer. So there is no special optimization on this kernel. I was thinking about a special patch or a OpenGL driver.

I’m still looking to compile RTAPI only with eventually Hal if someone knows how to do this...

Why would you want to tear up a working system? linuxcnc built as uspace, works quite well.

There are those who have said isolcpus= doesn't work, but I have an isolpus=3 in my boot, and htop shows zero loading on cpu 4, however the are correct, linuxcnc is shown as running on 3 cpu's so the isolation is good, but linuxcnc isn't running on the isolated cpu, humm. Might as well take that out then.

The day isn't a total loss, I learned something!
;p)

I don't think you can even see the realtime processes running on the isolated cpu. The Linuxcnc processes you can see are most likely userspace processes, not the realtime stuff.

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.