In that case we need polling. Or level interrupt triggering (i am using edge trigger)
If level triggering is an option then it might be worth a try.
Button presses would be fast interrupts to serve so if there’s any delay then it would come from the context switching overhead.
(I had to look them up to double check the difference. This is the oddest analogy that I’ve ever seen, and yet it makes sense.)
I’ll have a look to see if marking heldStates as volatile makes a difference.
It’s possible that compiler optimisations could be responsible for the data being written out of order.
Otherwise it’s likely to be a case of interrupts being reordered or dropped again.
Falling back to polling isn’t too bad in the grand scheme of things.
Like I say, we can always try to find a way to let the end user decide as part of the API revamp.
Really though I don’t think that many games are going to be running on a low framerate, and if there are ways around the polling issue, e.g. by polling more frequently.
I think with polling the occasional fps drops can cause problems. Say you have a full screen explosion when the player ship explodes. Say that the frame where the explosion is drawn takes 500 ms. Then the player quickly presses A button to restart the game, but that can be lost. Another example is writing to SD. If there is one function call which writes a lot of data to SD, key presses can be lost during that.
I do not say that you cannot handle that . As long as the code is open source you can divide it to smaller parts and read keys in-between. That just makes games more complicated to code than an interrupt-based approach.
That’s why I think the best approach would be to be able to choose if possible.
I think it would be difficult to do with the current API, but it might be doable.
(I’ll try to remember to look into it when I have a moment.)
For now I think the interrupt based approach (in either incarnation) is causing tangible problems, and while I don’t doubt that polling can cause problems, those problems haven’t been demonstrated yet.
I think the best way to decide which should be the default (if only for now) is to look at which games each method causes issues with and to decide if there are ways to fix those issues, and if not then pick the solution that causes the least issues for most games.
I’ll be sticking with my method, it hasn’t failed me since the GBA days.
5 Likes
Its around 80 ms. There is hardly any noise. Debouncing is not the problem.
1 Like
That’s should’t be a problem for any kind of interrupt, neither software or hardware.
Yes, it should not. I am thinking maybe I am not treating the interrupt idea correctly. I may have to first detect rising edge, disable rising edge trigger, enable falling edge, trigger on fall, then disable falling edge, then enable rising etc.
In other words, a state machine.
That is how I got my quadratures working 100% in the past
That’s sound odd. Interrupt on mbed, should simply be a matter of attach a function to rising or falling of an input. Adding a state machine have non sense to me. That’s would be “insane”.
I am not sure yet where the problem is coming from. Maybe its that NVIC is overworked or something. I will know more in a moment
1 Like
… but… maybe I am disabling interrupts somewhere and that is interfering with edge detection…
NOPE
1 Like
that deserve your attention, maybe also any kind software interference caused by using interrupt in audio/video generation?
No. I am not disabling interrupts anywhere, apart from flash loader mechanism
Its a deal! This is getting interesting. I will install the labview software on my PC so I can capture the scope output. Be quacking to you later today!
1 Like
Beware I’ve saw some real “spaghetti code” made with that.
I don’t understand why the interrupts are not all caught. The interrupt handles is very short, its over in microseconds. No triggers should be missed under any circumstances.
Sure, I could just poll my way around the problem, but part of this project is also about me increasing my level of understanding. So I am not letting this pass. When something doesn’t work, its a personal insult. I get upset. Very upset.
4 Likes
Dear @HomineLudens , aka rubber duck
Two things are evident from the scope:
- its not a bouncing issue (ie 0-3v glitching)
- I should focus on level triggering interrupts. Surely they should be easier to detect, looking at how much the level dominates the edge events vs time
And a third of the two things
- Maybe, just maybe, I am misunderstanding the way the chip behaves when interrupts are nested, i.e. if an interrupt occurs while we are in an interrupt handler. edit because, the smallest concurrent “edge events” I was able to find were 2.02ms, in other words 500Hz. A processor running at 48 Mhz can operate 96000 cycles of instructions in that time. Detecting another interrupt should be no problem what so ever.
2 Likes
Dear duck.
I have found out that falling edge register flag is set by PinInterrupt detection and by default, the mbed library InterruptIn initializes InterruptIn pins to edge mode (0).
Perhaps the falling edge registers should be cleared before we begin detecting button presses?
I am more and more convinced this is about me reading the interrupts in the wrong way.
1 Like
A couple of questions:
- Are 1,2,3,4 each different pins you have measured?
- What are AX, AY, BX, BY? A range you have selected? Of which pin are the AY and BY: 1,2,3, or 4?
- Why is AY 364 mV? Should it be either 0 or 3.3V, or at least near them?
1 Like