<whitequark>
shouldn't that be a priority queue in silicon?
<whitequark>
also, 581 cycles per interrupt sounds pretty bad
<cr1901_modern>
On lm32 there's a 32-bit IRQ line. I don't think it has a concept of priority.
<cr1901_modern>
But additionally, for reasons pertaining to how MiSoC handles interrupts, I had to tie two interrupt sources to a single IRQ line
<cr1901_modern>
The interrupts are arriving at 55,000Hz (calculated). I don't actually know how fast its servicing them, other than its passing an imprecise "light up the LEDs once a counter has reached 32000" test.
<whitequark>
you could use a timer...
<cr1901_modern>
Or a performance counter, now that I think about it lol
<cr1901_modern>
In any case, I ran a simulation... 3470ns from trigger to pending clear, or 111 cycles (when everything's in cache).
<whitequark>
that sounds better
_rht has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
larsc: Thanks :) (although all I did was take a bunch of existing code and string it together lol). Application is audio processing (with more flexibility than putting a filter directly on FPGA)
<cr1901_modern>
For better or worse, a CPU is a fairly efficient use of silicon space for its flexibility
<GitHub138>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/vDL2l
<GitHub138>
smoltcp/master 3e78039 whitequark: Add the log crate to dev-dependencies.
<travis-ci>
m-labs/smoltcp#68 (master - 3e78039 : whitequark): The build is still failing.
<GitHub>
[artiq] whitequark closed issue #625: improve error message when a connection is attempted and startup kernel is still running https://github.com/m-labs/artiq/issues/625