Machinekit on PocketBeagle

[mlampert]

I've installed the stretch Machinekit image from elinux.org on a PocketBeagle to play around with. As it turns out some of the installed drivers are indeed specific to the BBB, hal_bb_gpio being one of them (it insists on mapping pin 201 to 901 and then complain that it cannot be configured). After looking at the source I understand what's going on and why this is happening - however, I don't know what else needs to get specifically built for the pocketbeagle.

So the question is: What's the best way to get Machinekit running on a PocketBeagle?

Thanks a lot,

Markus

[John Morris]

On Monday, May 20, 2019 at 5:37:31 AM UTC+8, mlampert wrote:

I've installed the stretch Machinekit image from elinux.org on a PocketBeagle to play around with. As it turns out some of the installed drivers are indeed specific to the BBB, hal_bb_gpio being one of them (it insists on mapping pin 201 to 901 and then complain that it cannot be configured). After looking at the source I understand what's going on and why this is happening - however, I don't know what else needs to get specifically built for the pocketbeagle.

So the question is: What's the best way to get Machinekit running on a PocketBeagle?

I've had this running for a while on PB now.  The pin mapping issues should have been fixed for a couple of years now [1].  If the elinux.org image is too old to have this change, update Machinekit.  If you confirm that the change is in place and you're still seeing this issue, file an issue on the tracker, and mention @zultron to ensure I see it (though I would anyway).

    John

[1]: https://github.com/machinekit/machinekit/commit/b58f6e83

 

Thanks a lot,

Markus

[markus]

Am I correct that the support for the PB is a 'compile time' decision?
So if hal_bb_gpio is compiled for a BBB the driver does not support the
PB headers - right?

The MK image is from April 5 2019 - I made sure I updated to the latest
from deb.machinekit.io - the installed version is 0.1.155255826 which
has the commit sha1 355496b, which indeed seems to be HEAD of master.

If the driver is supposed to work on the PB although it was compiled
for the BBB then I'll file an issue for it.

Thanks,
Markus

[John Morris]

On Monday, May 20, 2019 at 11:07:12 AM UTC+8, mlampert wrote:

Am I correct that the support for the PB is a 'compile time' decision?

Try`board=PocketBeagle`

https://github.com/machinekit/machinekit/blob/b58f6e83/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L83

    John

[markus]

> On Monday, May 20, 2019 at 11:07:12 AM UTC+8, mlampert wrote:
> >
> > Am I correct that the support for the PB is a 'compile time'
> > decision?
>
> Try`board=PocketBeagle`
>
> https://github.com/machinekit/machinekit/blob/b58f6e83/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L83
>
> John

Where? When?
Markus

> > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmachinekit%2Fcommit%2Fb58f6e83&sa=D&sntz=1&usg=AFQjCNEOgtKEQoXpQjGVxZtzxJ5Bt8A-HQ>
> > >
> > >
> > > >
> > > > Thanks a lot,
> > > > Markus
> > > >
> > > >
> > >
> >
> >
>

[Charles Steinkuehler]

On 5/20/2019 1:22 AM, markus wrote:
>> On Monday, May 20, 2019 at 11:07:12 AM UTC+8, mlampert wrote:
>>>
>>> Am I correct that the support for the PB is a 'compile time'
>>> decision?
>>
>> Try`board=PocketBeagle`
>>
>> https://github.com/machinekit/machinekit/blob/b58f6e83/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L83
>>
>> John
>
> Where? When?

In your hal file when you load the hal_bb_gpio module, eg:

loadrt hal_bb_gpio board=PocketBeagle output_pins=...

--
Charles Steinkuehler
cha...@steinkuehler.net

[markus]

Thanks for the clarification - much appreciated.

It seems the driver is ignoring the parameter though. And I get the
same result. From linuxcnc.log:

May 20 00:07:37 pocketbeagle msgd:0: startup pid=1376 flavor=rt-preempt rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 version=v0.1~-----~355496b
May 20 00:07:37 pocketbeagle msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=gcc intrinsics libwebsockets=2.0.3
May 20 00:07:37 pocketbeagle msgd:0: configured: sha=355496b
May 20 00:07:37 pocketbeagle msgd:0: built: Mar 14 2019 10:47:55 sha=355496b
May 20 00:07:37 pocketbeagle msgd:0: register_stuff: actual hostname as announced by avahi='pocketbeagle.local'
May 20 00:07:37 pocketbeagle msgd:0: zeroconf: registering: 'Log service on pocketbeagle.local pid 1376'
May 20 00:07:38 pocketbeagle msgd:0: zeroconf: registered 'Log service on pocketbeagle.local pid 1376' _machinekit._tcp 49152 TXT "uuid=4e7e123c-1726-4351-bdfc-eba93047fb35" "instance=f2ce6258-7acd-11e9-aea4-606405e00475" "service=log" "dsn=tcp://pocketbeagle.local:49152"
May 20 00:07:39 pocketbeagle rtapi:0: 1:rtapi_app:1381:user hal_bb_gpio: ERROR: invalid pin number '901'. Valid pins are 101-136 and 201-236.
May 20 00:07:39 pocketbeagle rtapi:0: rtapi_app_main(hal_bb_gpio): -1 Operation not permitted
May 20 00:07:39 pocketbeagle rtapi:0: 1:rtapi_app:1381:user rtapi_app_main(hal_bb_gpio): -1 Operation not permitted
May 20 00:07:45 pocketbeagle rtapi:0: unload: '' not loaded
May 20 00:07:45 pocketbeagle rtapi:0: unload: '' not loaded
May 20 00:07:45 pocketbeagle rtapi:0: unload: 'motmod' not loaded
May 20 00:07:45 pocketbeagle msgd:0: rtapi_app exit detected - scheduled shutdown
May 20 00:07:47 pocketbeagle msgd:0: msgd shutting down
May 20 00:07:47 pocketbeagle msgd:0: zeroconf: unregistering 'Log service on pocketbeagle.local pid 1376'
May 20 00:07:47 pocketbeagle msgd:0: log buffer hwm: 0% (0 msgs, 0 bytes out of 524288)
May 20 00:07:47 pocketbeagle msgd:0: normal shutdown - global segment detached

Thanks again,
Markus

[Charles Steinkuehler]

On 5/20/2019 3:36 PM, markus wrote:
> Thanks for the clarification - much appreciated.
>
> It seems the driver is ignoring the parameter though. And I get the
> same result. From linuxcnc.log:

Look closer, it's not the same result.

> May 20 00:07:37 pocketbeagle msgd:0: startup pid=1376 flavor=rt-preempt rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 version=v0.1~-----~355496b
> May 20 00:07:37 pocketbeagle msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=gcc intrinsics libwebsockets=2.0.3
> May 20 00:07:37 pocketbeagle msgd:0: configured: sha=355496b
> May 20 00:07:37 pocketbeagle msgd:0: built: Mar 14 2019 10:47:55 sha=355496b
> May 20 00:07:37 pocketbeagle msgd:0: register_stuff: actual hostname as announced by avahi='pocketbeagle.local'
> May 20 00:07:37 pocketbeagle msgd:0: zeroconf: registering: 'Log service on pocketbeagle.local pid 1376'
> May 20 00:07:38 pocketbeagle msgd:0: zeroconf: registered 'Log service on pocketbeagle.local pid 1376' _machinekit._tcp 49152 TXT "uuid=4e7e123c-1726-4351-bdfc-eba93047fb35" "instance=f2ce6258-7acd-11e9-aea4-606405e00475" "service=log" "dsn=tcp://pocketbeagle.local:49152"
> May 20 00:07:39 pocketbeagle rtapi:0: 1:rtapi_app:1381:user hal_bb_gpio: ERROR: invalid pin number '901'. Valid pins are 101-136 and 201-236.

The P8/P9 headers do not exist on the PocketBone. Try using legal pin
numbers: 101-136 and 201-236

--
Charles Steinkuehler
cha...@steinkuehler.net

[markus]

That actually is the problem - the driver takes the p1 and p2 pins and
uses them as p8 and p9 pins, this is the excerpt from the hal file that
I used:

# load low-level drivers
loadrt hal_bb_gpio board=PocketBeagle input_pins=201,202,203,204 output_pins=217,227,228,229,230,231,232
loadrt [PRUCONF](DRIVER) prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN) [PRUCONF](CONFIG)

Same thing happens if I do it manually with halrun - and it complains
about the first pin in the command line, so if I remove 201 it
complains about 902 not being valid.

[Charles Steinkuehler]

Hmm...looking at the code it appears the output pins have a
conditional for the pin numbering fixup:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L365-L370

...that's missing for the input pins:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L272-L275

Combined with the legacy use of 1xx and 2xx for the BeagleBone pin
numbers (which is why the fixup exists in the first place) it looks
like that's breaking you pin numbering scheme.

Can you try with just output pins and see if that works?

--
Charles Steinkuehler
cha...@steinkuehler.net

[markus]

Yay - that does work, it is required to specify the board though:

markus@pocketbeagle:~/machinekit/configs/infinity$ halrun
msgd:0 stopped
rtapi:0 stopped
rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288
rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0
halcmd: loadrt hal_bb_gpio output_pins=201
<stdin>:1: insmod failed, returned -1:

rtapi_app_main(hal_bb_gpio): -1 Operation not permitted

halcmd: loadrt hal_bb_gpio board=PocketBeagle output_pins=201
halcmd:




On Mon, 20 May 2019 16:24:59 -0500

[markus]

I created an issue, hope I got the description right:
https://github.com/machinekit/machinekit/issues/1481

[John Morris]

On Tuesday, May 21, 2019 at 6:30:32 AM UTC+8, mlampert wrote:

I created an issue, hope I got the description right:
https://github.com/machinekit/machinekit/issues/1481

Thanks, Markus and Charles.  I put in a PR:

    https://github.com/machinekit/machinekit/pull/1482

Sorry I didn't test the original patch more rigorously.  Seems my super-simple Goldibox HAL config didn't use any GPIO inputs!

    John

[markus]

wow - that was quick. I'll have to setup my box for compiling mk,
haven't done that yet.

For the record, if nobody noticed for two years I would call it a
feature request, not a bug ;)

Thanks a lot - I'll confirm once I manage to build it.
Markus

> > > Charles Steinkuehler <cha...@steinkuehler.net <javascript:>>

> > > wrote:
> > > > Hmm...looking at the code it appears the output pins have a
> > > > conditional for the pin numbering fixup:
> > > >
> > > >
> > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L365-L370
> > > >
> > > > ...that's missing for the input pins:
> > > >
> > > >
> > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L272-L275
> > > >
> > > > Combined with the legacy use of 1xx and 2xx for the BeagleBone
> > > > pin numbers (which is why the fixup exists in the first place)
> > > > it looks like that's breaking you pin numbering scheme.
> > > >
> > > > Can you try with just output pins and see if that works?
> > > >
> > > >
> > > > On 5/20/2019 4:06 PM, markus wrote:
> > > > > That actually is the problem - the driver takes the p1 and p2
> > > > > pins and uses them as p8 and p9 pins, this is the excerpt
> > > > > from the hal file that I used:
> > > > >
> > > > > # load low-level drivers
> > > > > loadrt hal_bb_gpio board=PocketBeagle
> > > > > input_pins=201,202,203,204
> > > > > output_pins=217,227,228,229,230,231,232 loadrt
> > > > > [PRUCONF](DRIVER) prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN)
> > > > > [PRUCONF](CONFIG)
> > > > >
> > > > > Same thing happens if I do it manually with halrun - and it
> > > > > complains about the first pin in the command line, so if I
> > > > > remove 201 it complains about 902 not being valid.
> > > > >
> > > > >
> > > > > On Mon, 20 May 2019 15:55:37 -0500

> > > > > Charles Steinkuehler <cha...@steinkuehler.net <javascript:>>

[Daren Schwenke]

Thank you for the work here.  I'm about to venture down this rabbit hole myself and this is useful stuff.

[markus]

confirmed - fix works like a charm.
And thanks for the new package, didn't have to setup a build env after
all - not yet anyway.

Have fun,
Markus