Move38 / Blinks-SDK

Development for Blinks starts here. This codebase includes everything you need to get up and running in the Arduino IDE with Blinks.

Home Page:http://forum.move38.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

blinkStatep.cpp: didValueOnFaceChange method: Uninitialized static member

kenj1 opened this issue · comments

In blinkStatep.cpp, the prevState static array is never initialized properly.

byte didValueOnFaceChange( byte face ) {

    static byte prevState[FACE_COUNT];
    
    byte curState = getLastValueReceivedOnFace(face);
    
    if ( curState == prevState[face] ) {
        return false;
    }
    prevState[face] = curState;
    
    return true; 
    
}    

I understand this will default to zero. Since only the lower 6 bits are usable for a Blink (0-63), maybe setting the initial value to 0xFF (i.e. purposely setting the upper 2 bits) will always cause the initial value (even if 0) to be considered a changed value.

Ah yes, this is a nice catch. Don't want to be missing those first face value changes from a neighbor attaching.

The last value received on a face is currently documented as being 0 at power up, so this behavior is expected (that is, receiving a 0 immediately after a battery change should not register as a change).

Don't want to be missing those first face value changes from a neighbor attaching.

Attaching after what? Battery change? New game loaded? Sleep? Face expiring? Blink momentarily removed?

Is any value received after one of these events a change - even if the value happens to be the same as the value last received on that face? I think I can make a case that a 0x01 transmitted by Mortals is different than a 0x01 transmitted by Bomb Brigade, although with current semantics that would not trigger a change notice.

I prefer using local game state to see if things change since different games (and even game programmers!) will likely have different answers to this question, but if we are going to support a function like this in the API then we should pick and document one of these options.

Which one should it be?

If there is going to be more semantics on this, should there be even more state? Is it worth the complexity of having a correct and locked in view with a flag for currentValueOnFaceHasBeenRecieved()?

This would mean that last value received and has changed would only be valid if a value had been retrieved at all. Still leaves open when this should reset though...

@bigjosh you bring up good points. No changes necessary at the moment. Simply document that all Blinks initialize to 0 on all faces, a change in value received must initially be different than 0. Since didValueOnFaceChange is not a tool for determining placement, the implementation follows what the naming suggests. Closing this issue.