About "Moving" question

Pokitto Programming
61

Yes, they are up, down left right in that order.
AX,AY,BX,BY are manually controlled cursors, independent of signal (in this case)
Y-axis (364 mV) is not relevant. I shifted the signals so that I can see them at the same time.

1 Like
62

@79859899 , @Pharap , @spinal

Please try to reproduce button glitch with this:

Pokitto_Game_Lost_LPC11U68.bin (53.0 KB)

1 Like
63

Seems OK to me.

64

I think we might just have a winner this time.

1 Like
65

Does using an interrupt for reading pins take up any CPU time?

66

Yes.
The time to write the data into the array and the time taken to make a context switch,
which depending on the processor may require saving and restoring a number of variables.
Some processors have a set of registers reserved for interrupts so they don’t have to do a save/restore, and if the Pokitto’s MCU is one of those then the time will be fairly negligable.

I don’t know which the Pokitto does though.
(Hopefully @jonne will know and I won’t have to dig out and decipher the spec.)

67

Ive tested many times, perfect for me.
How did you repair this problem ?
Please tell me, I want to learn more.:joy:

3 Likes
68

Yes, we expect typical in-depth explanation of how to implement perfect interrupt handling :wink:

69

Later today. It was very simple. I just read the level of the pin inside the interrupt.

InterruptIn is just the same as DigitalIn, except it has an interrupt handler attached. So you can simply read the level (high / low) when interrupt fires.

Nothing else.

Edit: advantages vs. constant checking (i.e. polling):

  1. does not use cpu resources constantly
  2. not FPS dependent

Edit2: but @spinal method is also useful if you want to save interrupts for something else (external hardware) so its good also

2 Likes
70

You won’t believe what a problem I’ve had with the new button code.

I was totally puzzled by the fact that buttons were “repeating” by themselves.

And I was trying and trying.

Then I realized. The legacy Gamebuino button handler does not take into account, that the button press loop can now reach button hold time 0xFF in a matter of milliseconds. BUT: 0xFF happens also to be the button released value. So holding a key made the counter go 01,2,3,4,…0xFF…0,1,2,3,4…0xFF !! Argh! Half a day WASTED!

Now if it reaches 0xFF by increment, it goes to 2 and prevents the “auto-rapid-fire” feature.

Thats what you get for too fast code!

Changed:

void Buttons::update() {
    #if POK_USE_CONSOLE
    if (console.conscounter) return;
    #endif // POK_USE_CONSOLE
    #ifndef POK_SIM
        /** HARDWARE CODE **/
    for (uint8_t thisButton = 0; thisButton < NUM_BTN; thisButton++) {
        if (Pokitto::heldStates[thisButton]) { //if button pressed
            states[thisButton]++; //increase button hold time
        } else {
            if (states[thisButton] == 0)//button idle
                continue;
            if (states[thisButton] == 0xFF)//if previously released
                states[thisButton] = 0; //set to idle
            else
                states[thisButton] = 0xFF; //button just released
        }
        }

To:

void Buttons::update() {
     #if POK_USE_CONSOLE
     if (console.conscounter) return;
     #endif // POK_USE_CONSOLE
     #ifndef POK_SIM
         /** HARDWARE CODE **/
     for (uint8_t thisButton = 0; thisButton < NUM_BTN; thisButton++) {
         if (Pokitto::heldStates[thisButton]) { //if button pressed
             states[thisButton]++; //increase button hold time ...AAAARGH!!!
             if (states[thisButton]==0xFF) states[thisButton]=2; // PREVENT WRAPAROUND!!!!
         } else {
             if (states[thisButton] == 0)//button idle
                 continue;
             if (states[thisButton] == 0xFF)//if previously released
                 states[thisButton] = 0; //set to idle
             else
                 states[thisButton] = 0xFF; //button just released
         }
         }
4 Likes
71

The reason why I am working on this is because a new release of library with a fine-tuned volume control (much, much better) is imminent

3 Likes