-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sterility Not Working As Expected #100
Comments
@jbobrow So if you alone-long-long-press a blink with sterile built-in game then it would reload the built-in game to be that active game and then go to sleep (it would do this regardless of whether the active game is sterile or not). Good? |
Should just go to sleep.
|
Then how would you get a sterile that has a different game loaded back to the built-in one? |
No need for a Blank to return to its demo sketch. The two ways that you can get back to that state are the following:
The goal is for Blanks to play a supporting role unless a developer has updated them to be something else. |
So "sterility" is a property of a physical tile that makes it so that tile never sends a game as a result of a button press? If so, then I think the workflow to make a sterile tile would be to program it normally and then do an extra step to neuter it. This would probably be something like running an AVRdude command. Does that sound right? |
Sterility should not be a permanent aspect of the hardware. It should be a property of the application that it has stored in local memory. This sterility should be recognized while running an application downloaded from another Blink so that it remains sterile. Sterility is only overwritten if the FW is flashed via ISP. |
Putting this one on ice while we user test. There are in fact 2 different features that could be arrived at from this description.
For the time being, we'll keep one model consistent across Blinks. |
Closing until we can work out how to do this well. |
REPORTED BY @jbobrow:
Looks like I didn’t think to thoroughly test the way sterility was implemented, as I just thought to test how it is working in a number of different scenarios and realized there are some very likely problematic ones.
The desired behavior is that the Blink that is sterile can never transmit its code to another Blink (unless it is of course flashed w/ a developer publish tool). Consider the Blank running "sterile blank sketch” in the following scenario of how the Blinks currently behave, but not the desired behavior:
I have a 6-pack of Blanks, I break them out to play, they animate, look pretty and can be put to sleep. The don’t really do anything else, but they are ready to accept another game to play. I pull our ZenFlow and load it up. It transmits to all of my Blanks and then all of my Blanks are playing ZenFlow. At this point, I pick up one of my Blanks and I hold it down for 3 seconds while alone. This Blanks is running ZenFlow, since it recently learned ZenFlow, and so the Blank enters program mode. This Blank is now ready to teach other Blinks the code it knows, so I attach it and it loads onto all other Blinks and Blanks alike. This code that was shared is the “sterile blank sketch.” At this point I have a lot of Blinks and Blanks that don’t have the ability to enter program mode, so I am stuck. I have to take out a battery to return or find another Blink to program with and get out of this situation.
The desired behavior is the following: A blank that is running ZenFlow when held for 3 seconds should not enter Program mode. It should simply bypass that and go to sleep. Alternatively, if that is not possible, it should enter program mode and immediately cancel it, so there is no chance of propagation of the sterile code. Under no circumstance should someone be able to seed a sterile sketch to other Blinks.
The text was updated successfully, but these errors were encountered: