Michel Pollet

You could also try to attach gdb to the running process of simavr if it loops... and see what's going on. It's very likely the firmware is spinlooping somewhere, this...

You might be running out of stack. Try declaring half these variable 'static' and see if it helps

@gatk555 do you have a 'proper' PR or a commit for that? ie, [c8bcdc7](https://github.com/gatk555/simavr/commit/c8bcdc7463c35dd5d4b1ed307de0b249ee3acb44)?

Ahah fine :-) As you've noticed I've reactivated my tree (mostly because I got an active AVR project!) so it's a good time to get stuff merged, if you hadn't...

Well I like adding a variable to configure it, and not use rpm as well rpm is only a tiny fraction of linux/oses -- also, personally I don't *recommend* 'installing'...

I also try not to use threads when not necessary -- in this case I'm not sure why they are used, but perhaps it was to have the simavr simulation...

Ah so that's why it slowed down and became noticeable; because glut idle callback must have quite a bit more overhead...

Actually I think that's about as bad as the other solution really. here you are blocking glut, event processing and rely on synchronous behavior, while opengl is actually completely asynchronous...

Interesting, I'll have a look at that. We already had a test case for the timer16 like that, so perhaps there is a regression there..?

I think we need to start by using a AVR_IRQ_FLAG_FLOAT... And also add accessors to get/set the flags... The idea would be to do.. if () avr_irq_set_flag(irq, AVR_IRQ_FLAG_FLOAT); else avr_irq_raise(irq,...