Re: [Machinekit] C instantiable components and hal_pru_generic

2020-05-01 Thread mike Kennedy 
Hello All:

If it's ok that I can make a small suggestion? Please forgive me I am still
learning Machinekit and mksocfpga so this may not apply.
I have noticed that the Terasic DE10-Nano-Soc Board was on "sale" due to
Covid-19, link below. Please let me know if works for you.

http://mail.terasic.com.tw/epaper/2020/limitedtime.html

John: Would it be possible to use the DE10-Nano-SOC Board for your
project?

https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=1046

This board my help your IO problem as well as have a FPGA Fabric so you can
implement multiple Motor controllers or custom HDL code if required.

Just a thought...

Thanks,.
Mike Kennedy.

On Thu, Apr 30, 2020 at 7:14 PM John Allwine  wrote:

> I'm not convinced of that. Since the register table is fully allocated it
> would likely require swapping registers out to scratch pads and assigning
> pin numbers that are larger than a byte (this would significantly affect
> the SET_CLR_BIT and PINTABLE implementation) and at the very least adding
> twice as many memory writes. I don't fully understand the ramifications of
> making some of those changes, but it would certainly have a performance
> penalty by writing to more registers, even if it is easy to implement. I'm
> concerned with performance, so any modifications that slow down
> hal_pru_generic I'd like to avoid. I'm trying to reach high step
> frequencies with 5 different axes. I'm hoping to achieve them with
> hal_pru_generic, so I'm thinking of even adding build macros so
> hal_pru_generic could have access to PRU code that doesn't perform any
> memory writes (but rather uses only direct outputs). I'm still testing
> what's feasible, but being able to divide up that work between different
> PRUs could also be key, so I like the idea of hal_pru_generic being
> instantiable.
>
> On Thursday, April 30, 2020 at 3:28:51 PM UTC-6, Charles Steinkuehler
> wrote:
>>
>> I think it would be easier to extend the existing logic to simply write
>> to more registers, but an icomp version of hal_pru_generic could still
>> be helpful.  With four PRU cores in the BBAI, I can definitely see the
>> benefit to having more than one PRU running either to divide the work or
>> to allow the PRUs to run with different cycle times.
>>
>> On 4/29/2020 10:13 PM, John Allwine wrote:
>> > Is there documentation on how to write an instantiable HAL component in
>> C? I’ve been making modifications to hal_pru_generic to work on the
>> BeagleBone AI. hal_pru_generic is implemented in such a way that only 4
>> GPIO ports can be used. The BBB only has 4 GPIO ports, so any pin on the P8
>> and P9 headers can be used on a single instance of hal_pru_generic. The
>> BeagleBone AI has 8 GPIO ports, so without significant changes to
>> hal_pru_generic, not all pins on the P8 and P9 headers can be accessed from
>> a single instance. The BeagleBone AI does expose many more pins as direct
>> outputs, but I’m unable to instantiate more than one instance of
>> hal_pru_generic in order to take advantage of certain pin configurations.
>> Is it possible to make hal_pru_generic instantiable?
>> >
>>
>> --
>> Charles Steinkuehler
>> cha...@steinkuehler.net
>>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/50289540-1f4a-4903-912d-a9c27aed7839%40googlegroups.com
> 
> .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAFOJqr7w5WG0X0P9%2BcDZpyCm4CeiQZJZ7Lgv%2BYkjFpS69nWa_Q%40mail.gmail.com.

Re: [Machinekit] C instantiable components and hal_pru_generic

2020-05-01 Thread Charles Steinkuehler 
Hal_pru_generic was meant to be generic, not fast, which is why I put 
"generic" in the name.  :)  I had generally intended to make a "fast" 
version, but never needed to (the existing PRU logic can drive my 3D 
printer step/dir drivers faster than they can accept pulses already!).


Probably the first step for improved performance would be getting the 
HAL driver to support multiple PRUs, either using one driver, or perhaps 
by making the driver an icomp so you could run multiple instances.  This 
would let you divide up the work across the PRUs so you could run a 
faster cycle rate on each one since it's not doing all the work.


Next would be crafting some new PRU "tasklets" that are less generic 
than what's currently implemented.  Options would be to only support PRU 
direct IO, only support one or two GPIO banks instead of 4+, possibly 
unroll some loops to avoid branch/jump (eg: make a 5 stepgen tasklet 
instead of using the stepgen tasklet 5 times).  This might also be the 
easiest solution if you think you can get the performance you need out 
of a single PRU.


The final step would be dropping most or all of the existing PRU tasklet 
framework and writing something that specifically does *JUST* what you 
need, and spread that across several PRUs, eg: Run a 2 stepgen task 
across 3 PRUs and get 6 step/dir outputs.


On 4/30/2020 6:14 PM, John Allwine wrote:

I'm not convinced of that. Since the register table is fully allocated it
would likely require swapping registers out to scratch pads and assigning
pin numbers that are larger than a byte (this would significantly affect
the SET_CLR_BIT and PINTABLE implementation) and at the very least adding
twice as many memory writes. I don't fully understand the ramifications of
making some of those changes, but it would certainly have a performance
penalty by writing to more registers, even if it is easy to implement. I'm
concerned with performance, so any modifications that slow down
hal_pru_generic I'd like to avoid. I'm trying to reach high step
frequencies with 5 different axes. I'm hoping to achieve them with
hal_pru_generic, so I'm thinking of even adding build macros so
hal_pru_generic could have access to PRU code that doesn't perform any
memory writes (but rather uses only direct outputs). I'm still testing
what's feasible, but being able to divide up that work between different
PRUs could also be key, so I like the idea of hal_pru_generic being
instantiable.

On Thursday, April 30, 2020 at 3:28:51 PM UTC-6, Charles Steinkuehler wrote:


I think it would be easier to extend the existing logic to simply write
to more registers, but an icomp version of hal_pru_generic could still
be helpful.  With four PRU cores in the BBAI, I can definitely see the
benefit to having more than one PRU running either to divide the work or
to allow the PRUs to run with different cycle times.

On 4/29/2020 10:13 PM, John Allwine wrote:

Is there documentation on how to write an instantiable HAL component in

C? I’ve been making modifications to hal_pru_generic to work on the
BeagleBone AI. hal_pru_generic is implemented in such a way that only 4
GPIO ports can be used. The BBB only has 4 GPIO ports, so any pin on the P8
and P9 headers can be used on a single instance of hal_pru_generic. The
BeagleBone AI has 8 GPIO ports, so without significant changes to
hal_pru_generic, not all pins on the P8 and P9 headers can be accessed from
a single instance. The BeagleBone AI does expose many more pins as direct
outputs, but I’m unable to instantiate more than one instance of
hal_pru_generic in order to take advantage of certain pin configurations.
Is it possible to make hal_pru_generic instantiable?




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





--
Charles Steinkuehler
char...@steinkuehler.net

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups "Machinekit" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/49ad94d8-1d0d-2477-5980-ce50eeb80378%40steinkuehler.net.

[Machinekit] problems with realtime kernel on Beaglebone AI

2020-05-01 Thread John Allwine 
I posted this on the Beaglebone forums 
 
and figured someone here may be able to help too:

I'm trying to use a real time kernel on the Beaglebone AI to get MachineKit 
running. I'm able to run MachineKit on a non-rt kernel (4.14.108-ti-r113), 
but when I update to the latest ti-rt kernel (4.14.108-ti-rt-r134), I get 
an error: 

user cannot gain I/O privileges - forgot 'sudo make setuid'?

In dmesg, I see this:
[  811.654246] warning: process `rtapi:0' used the deprecated sysctl system 
call with 8.1.2.

Robert Nelson offered to tweak the rt kernel config to support that call. 
Is that what needs to happen?

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com.

Re: [Machinekit] problems with realtime kernel on Beaglebone AI

2020-05-01 Thread John Allwine 
This seems to be the source of the problem:
https://github.com/machinekit/machinekit-hal/blob/9fca994e08e3f8384498e78ea8e8baa1c899e4db/src/rtapi/rtapi_app.cc#L1457

The system call iopl seems to be returning an error:
http://man7.org/linux/man-pages/man2/iopl.2.html

On Fri, May 1, 2020 at 2:49 PM John Allwine  wrote:

> I posted this on the Beaglebone forums
> 
> and figured someone here may be able to help too:
>
> I'm trying to use a real time kernel on the Beaglebone AI to get
> MachineKit running. I'm able to run MachineKit on a non-rt kernel
> (4.14.108-ti-r113), but when I update to the latest ti-rt kernel
> (4.14.108-ti-rt-r134), I get an error:
>
> user cannot gain I/O privileges - forgot 'sudo make setuid'?
>
> In dmesg, I see this:
> [  811.654246] warning: process `rtapi:0' used the deprecated sysctl
> system call with 8.1.2.
>
> Robert Nelson offered to tweak the rt kernel config to support that call.
> Is that what needs to happen?
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/1iYGU9VfvPM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com
> 
> .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAPEK9qbEdq5hL4p5yNsWa6DSTthhed-vM7CBdSBX%3DFPHMZ0BBg%40mail.gmail.com.

Re: [Machinekit] problems with realtime kernel on Beaglebone AI

2020-05-01 Thread cern via Machinekit 
Hi,
May 1, 2020, 23:36 by j...@pocketnc.com:

> This seems to be the source of the problem: > 
> https://github.com/machinekit/machinekit-hal/blob/9fca994e08e3f8384498e78ea8e8baa1c899e4db/src/rtapi/rtapi_app.cc#L1457
>
You are not the only one bitten. There is/was discussion in Machinekit Matrix 
room, history: 
https://view.matrix.org/room/!CLLXbpAoUbAfHmWDXt:matrix.org/?anchor=$158837589690473CEniQ:matrix.org&offset=0

Personally, I consider it premature and think that the program should cross 
that bridge when it comes at it and not when everything it sees is flat land. 
So I would remove it.

Cern.

>
> The system call iopl seems to be returning an error:
> http://man7.org/linux/man-pages/man2/iopl.2.html
>
> On Fri, May 1, 2020 at 2:49 PM John Allwine <> j...@pocketnc.com> > wrote:
>
>> I posted this on the >> Beaglebone forums 
>> >> 
>>  and figured someone here may be able to help too:
>>
>> I'm trying to use a real time kernel on the Beaglebone AI to get MachineKit 
>> running. I'm able to run MachineKit on a non-rt kernel (4.14.108-ti-r113), 
>> but when I update to the latest ti-rt kernel (4.14.108-ti-rt-r134), I get an 
>> error: 
>>
>> user cannot gain I/O privileges - forgot 'sudo make setuid'?
>>
>> In dmesg, I see this:
>> [  811.654246] warning: process `rtapi:0' used the deprecated sysctl system 
>> call with 8.1.2.
>>
>> Robert Nelson offered to tweak the rt kernel config to support that call. Is 
>> that what needs to happen?
>>
>>
>>
>> --
>>  website: >> http://www.machinekit.io>>  blog: >> 
>> http://blog.machinekit.io>>  github: >> https://github.com/machinekit
>>  --- 
>>  You received this message because you are subscribed to a topic in the 
>> Google Groups "Machinekit" group.
>>  To unsubscribe from this topic, visit >> 
>> https://groups.google.com/d/topic/machinekit/1iYGU9VfvPM/unsubscribe>> .
>>  To unsubscribe from this group and all its topics, send an email to >> 
>> machinekit+unsubscr...@googlegroups.com>> .
>>  To view this discussion on the web visit >> 
>> https://groups.google.com/d/msgid/machinekit/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com
>>  
>> >>
>>  .
>>
>
>
>
> --
>  website: > http://www.machinekit.io>  blog: > http://blog.machinekit.io>  
> github: > https://github.com/machinekit
>  --- 
>  You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
>  To unsubscribe from this group and stop receiving emails from it, send an 
> email to > machinekit+unsubscr...@googlegroups.com> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/CAPEK9qbEdq5hL4p5yNsWa6DSTthhed-vM7CBdSBX%3DFPHMZ0BBg%40mail.gmail.com
>  
> >
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M6Ht6hJ--3-2%40tuta.io.