polled operators about aleph

In PD I'm directly calling monome_grid_key_handler from inside a liblo server thread (set to receive monome keypresses), because there's no BEES event loop and was the quickest way to get things more-or-less working (ignoring obvious thread safety issues for now)...

It seems that BEES proper is asynchronously polling midi/monome drivers for keypress/events on a 20ms timer loop... umm that means 20ms jitter between physical keypress & the device actually responding - not exactly snappy!
https://github.com/monome/aleph/blob/dev/apps/bees/src/app_timers.c#L154-L179

So any reason we shouldn't be constantly polling for fresh midi/monome data from inside main right after calling check_events, and do away with polling timers for monome & midi stimuli?
https://github.com/monome/aleph/blob/dev/avr32_lib/src/main.c#L402-L404

Obviously conscious this kind of change will further complicate the libavr32 merge a bit...

here - like this...
https://github.com/rick-monster/aleph/commit/9a81042bd4ad74026af883db03f367eee9c98428
works on my machine! didn't implement/test midi but monome serial seems to work well...

[catfact]

not exactly snappy!

no argument there. if it works to switch to busy-loop USB reads, and doesn't impact other stuff, then surely, go for it.

i would just be a little careful. ultimately all usb endpoint reads end up here:
https://github.com/monome/aleph/blob/dev/avr32_lib/asf-3.7.3/avr32/drivers/usbb/usbb_host.c#L895

i would want to make sure this is reentrant. if it's not, then you would need to be disabling interrupts on every read; that could get unpleasant.

also of course we could reduce the 20ms time. that does seem like a very high number, i assume faster polling was problematic.

i would want to make sure this is reentrant. if it's not, then you would need to be disabling interrupts on every read; that could get unpleasant.

I guess stress-testing serial with a grid plugged in would be sufficient to know whether this is 'reentrant'? (had to google that word!)

The way I see it, the function ftdi_read() was being also called before from main, but using several more layers of indirection (i.e the monome_poll_timer_callback song & dance). So (imho) this change can only exacerbate any concurrency problems...

Well it's squished down into a single, easily reversible commit at any rate!

[catfact]

the function ftdi_read() was being also called before from main

is that true? i'm pretty sure it's like:

irq_tc() -> process_timers() -> monome_poll_timer_callback() -> ftdi_read()

that is, it's being called from the timer interrupt. so it can't be interrupted.

i'm just not sure what would happen if an interrupt came along right while uhc_ep_run() was messing with the IRQ registers...

is that true?

Nope, total bs! You are correct, this is a bigger, more controversial change than I thought.

Dunno how I managed to convince myself there was an extra level of event-loop indirection there, thanks for pointing out the mistake!