Pru interface separation

[hzeller]

Very nice, only some little confusion converting the old int-returning-C interface into a boolean-returning-C++ interface.

[hzeller]

Looks good!

[bigguiness]

All,

I may have just noticed a bug in:

unsigned UioPrussInterface::WaitEvent() { const unsigned num_events = prussdrv_pru_wait_event(PRU_EVTOUT0); prussdrv_pru_clear_event(PRU_EVTOUT0, PRU_ARM_INTERRUPT); return num_events; }

prussdrv_pru_clear_event() is defined as:

int prussdrv_pru_clear_event(unsigned int host_interrupt, unsigned int sysevent);

WaitEvent() is passing the values backwards.

Maybe this is part of the race I am seeing.

Hartley

From: Henner Zeller [mailto:notifications@github.com] Sent: Thursday, July 28, 2016 2:15 PM To: hzeller/beagleg Subject: Re: [hzeller/beagleg] Pru interface separation (#15)

Merged #15https://github.com/hzeller/beagleg/pull/15.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/hzeller/beagleg/pull/15#event-738457757, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABkqIde0YB-XuQjRXCxkXwweBzuVaXK-ks5qaRvPgaJpZM4JXexE.

[bigguiness]

Something broke with this commit.

I get this when I start machine-control:

machine-control: pru-motion-queue.cc:145: PRUMotionQueue::PRUMotionQueue(HardwareMapping, PruHardwareInterface): Assertion `init_result == 0' failed.

Rolling back to this commit works:

commit 6b5057b4c5627705e4266f251e5b4945f10677e0 Author: H Hartley Sweeten hsweeten@visionengravers.com Date: Tue Jul 26 14:08:37 2016 -0700

Improve planner for threshold angle acceleration.

I just started looking into the failure.

Hartley

From: Henner Zeller [mailto:notifications@github.com] Sent: Thursday, July 28, 2016 2:15 PM To: hzeller/beagleg Subject: Re: [hzeller/beagleg] Pru interface separation (#15)

Merged #15https://github.com/hzeller/beagleg/pull/15.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/hzeller/beagleg/pull/15#event-738457757, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABkqIde0YB-XuQjRXCxkXwweBzuVaXK-ks5qaRvPgaJpZM4JXexE.

[hzeller]

So the finding with the prussdrv_pru_clear_event() is interesting @bigguiness : the documentation indeed says first the interrupt, then the event.

But then all of their example code does the reverse: https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_memAccessPRUDataRam/PRU_memAccessPRUDataRam.c#L148

Need to look at the implementation what the prussdrv_pru_clear_event() actually is doing...

[hzeller]

So there were two problems in this patch 1) there was some reverse logic going on essentially making the system immediately assert() fail. Fixed in https://github.com/hzeller/beagleg/commit/8ecd1621579a08cf98225847d07febb0a35c0f3c

2) The waiting for event was hanging, because it internally was reading from a wrong file-descriptor. instead of PRU_EVTOUT_0, the constant PRU_EVTOUT0 was used (which apparently is a thing internally in the PRU headers, with a different value). Fixed in https://github.com/hzeller/beagleg/commit/57d5ac13bb25ef5183ce241053fa5cd9624970dd

However, the PRU_EVTOUT_0 was used previously, so other hangs we might've seen must be some other reason.