Peter C. Wallace wrote:
>
>
> Our older configs did this but LinuxCNC seems to want to be in charge of the
> timimg...
>
Well, it would not need to be the driver that receives the interrupt.
The interrupt
handler could be rtapi, the only real difference is that rtapi would not
be calling
for
On Thu, 18 Jul 2013, Jon Elson wrote:
> Date: Thu, 18 Jul 2013 21:47:32 -0500
> From: Jon Elson
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] architecture-specific drivers
>
> Peter C. Wallace wrote:
>> I think a good way to
Peter C. Wallace wrote:
> I think a good way to do this is simply a set of architecture specific
> wrappers around the lowest level I/O, and perhaps initialization code so the
> driver itself is not forked.
>
While in theory this could be done, it won't take advantage of the fact the
PRU is a
On 7/18/13 11:23 , Jon Elson wrote:
> I have a BeagleBone on order, and am thinking about the
> issues of converting "my" PPMC driver to work on the
> Bone. It would be pretty parallel to hal/drivers/hal_ppmc.c
> just for the non-X86 (ARM/PRU) architecture. Do we already
> have a plan on how to d
On Thu, 18 Jul 2013, Jon Elson wrote:
> Date: Thu, 18 Jul 2013 12:23:04 -0500
> From: Jon Elson
> Reply-To: EMC developers
> To: EMC developers
> Subject: [Emc-developers] architecture-specific drivers
>
> I have a BeagleBone on order, and am thinking about the
>
I have a BeagleBone on order, and am thinking about the
issues of converting "my" PPMC driver to work on the
Bone. It would be pretty parallel to hal/drivers/hal_ppmc.c
just for the non-X86 (ARM/PRU) architecture. Do we already
have a plan on how to deal with architecture-specific drivers?
Jon
