The Fundamental nature of a Blink, or Perhaps the very first question I should have asked

1

I am going to list a few assumptions below. Please let me know where I am with them. After that, a few questions.

Coming back up here to add this. I just finished typing point 12. It becomes apparent to me now, that this OP has all the hallmarks of a “Meeko” post. Non sequiturs abound, and I am mostly on track, coherent and sane throughout the undertaking. This is not intentional, but it is indeed how I am. If I do much editing or revising from this, I lose what I am after, either in content or in questions.

This is the best I can do. You have been warned.

  1. There is a collected and connected assemblage of Blinks. They are all on, all doing their own thing, from their last session.

  2. An unconnected blink is turned on, and put into “Teach” mode. It connects to the assemblage, and successfully starts the blue path, and then the green path.

2.The point of this teaching, is to give each and every blink an exact copy, in full, of the program being taught. [[ 2A. I assume, obviously, that each blink maintains it’s own game, and a BIOS of some sort to be able to persist / survive into other games and sessions. All of this to say, rightly so, blinks can’t use ALL of their memory when being taught new games. ]]

3.The green path transitions, and the game starts.

  1. From this point on the entire and exclusive thing that each blink is doing, is going down the lines of code, more or less " in line ", stopping only to entertain loops and nested loops that it finds itself member to.

EDIT : And then, once finally reaching the end, the entire main block of programing, everything outside of Setup, is itself one huge loop. That each blink is doomed to repeat the outer most loop, at a minimum, indefinitely.

  1. The point remains, that blinks, on the whole, despite needing a lot of them, maintain doing their own thing. Only, in stark contrast to point 0. above, this time, “their thing” is EXACTLY what the teaching blink from 1 has taught them. No more, no less. [Save for maintaining the information it needs from 2A.] Each blink is doing their own thing, just like every other blink. The. Exact. Identical. Things.

  2. Until a blink is made aware of this [[And I am not entire sure how they would be told, per se]] notion that they are unique snowflakes, just like every other blink, … they aren’t made aware of this.

  3. I mean, for all I know, while we can see two blinks connected to each other, until that fact is coded into the blinks, … the blinks themselves will never know they are connected.

  4. Blinks have to be told. They need their clothes put out before them for the day, next to their lunch box.

  5. Then they have been instructed to put on clothes and take their lunch, and go to school.

  6. All of this to say that Blinks [If I am getting my terminology correct] ultimately are “pushed” everything. Either from square one at being taught the game, or when another [[Edit " when another neighboring blink " ]] blink gets the notion that, what it has, or what it generates, is pushable.

  7. This constant and consistent concept of “Push” [[Again, I could be off my terms here, but I am going out of my way to provide enough context, I hope.]] over Pull, is THE DEFINING challenge that blinks development has. Everyone comes into Blinks development assuming that they can push and pull things.

  8. To use another example, new blinks programers have the assumption that they can turn both Right and Left, … and in reality, they can only turn Right, or turn Right three times. [[At 90 degree Angles, so that Right 3 Times finally ““looks”” like a left hand turn]]

  9. This Left Versus Right 3 Times situation is a habit that dies hard, and probably, ultimately, still lives on and manifests itself in each and every Blink developer. There is no cure, only ways to maintain it.

  10. Related to 12 and 13, is the fact that, given 2A, blinks have a limited ability to do things, and a limited capacity to do those things. Similar in situation to 12, taking the same appearance, but a different flavor of “”" being creative “”" . [[No judgment intended here]]

  11. And deep down. Deep, all the way down, we know that these constraints are the exact thing that gives Blinks it’s character, and “draw” of attraction. And we love them for that. … In our best moments.

A. At Statement 1 : When exactly does the Void Setup { } block start and finish ?
A.I. Does Setup have to end with a user manipulating or detaching a blink?

B. Is there anyway at all, short of physically force stopping the program [essentially] by long pressing a blink back into teach mode, to reenter the setup block during the main program, and from that entry into setup, continue into main ““from the top”” ? [[This answer to this one actually pertains to my current program.]]

C. I guess I am asking about subroutines. Are Subroutines even possible? Or is the traditional [[I guess I am referring to BASIC here]] subroutine closer to wanting to “turn left” ala 12 above? That I can only assume by a loop set out in advance, can anything approaching a subroutine even exist / and be executed.

D. Related to C and tied into an immediate issue my current game idea crashed into, … is it wise to create variables and loops for everything ?

E. I mean, I know the answer to D is " No. " I get that. Honestly, I do. It would eat up memory like no tomorrow to do so. Apparently, triply so if you want to blinks to read the colors off of neighboring blinks.

F. Therefore, is the challenge of finding the balance between D. and E. met with A LOT of edits? Should I buy the huge pink rubber eraser ““For BIG Mistakes”” ?

G. Or is this just the nature of programing in general, to not only improvise, but to improvise expediently?

H. [And hopefully, you get the legit sense, that I am twigging into this, for the very first time, as I type] … That all of programing, regardless of language, perforce, requires constant learning. Constant revision.

I. And, Deep down, deep, all the way down, we know that these exact things, are what give us our character, and our draw of attraction to programing. And we love ourselves for that… in our best moments.

2

Correct a Blink has a copy of the BlinkBIOS, its own game and the game currently active (which might be its own game or some other game).

As soon as a Blink receives new code or is reset in some other way (say, batteries removed and reinserted) it will call setup() once. Then it will start calling loop() over and over again. Before and after the loop() call, it does its own housekeeping (receiving face values and datagrams, checking button state, sending face values and datagrams, “rendering” leds and more).

Not sure I understand what you mean here but, as I mentioned above, loop() will be called over and over, yes.

In general terms, yes. But because Blinks react to external input (button presses, datagrams, face values), they might actually be running different parts of the same code available to all Blinks thus, effectively, doing different things. Blinks can also react to internal events (timers, for example).

I suspect I addressed this above. Blinks can react to external input which what would make them do their own thing based on that input.

Blinks know they are connected even if you do not do anything. This is part of the code that runs before and after loop() is called. This code is always there. Obviously knowing they are connected is just part of the puzzle. You still need to use that information for it to be relevant.

They have to be told what to do, yes. But They do not need to be told that they are connected (how would you even tell it it is connected to other Blinks otherwise? :slight_smile: ).

I guess this is a valid way to put it, although it might not be the most complete one.

I have the feeling you are overcomplicating things. There are only 2 possible external inputs to Blinks:

1 - Button presses. This is pretty straight forward. You can check if a button was clicked and how many times and then act upon it ("do X if the button has been double-clicked).
2 - IR data (datagrams and face values). This obviously gives you the actual data (“do X if the value on face 2 is 42”) but is also used to figure out if a Blink is connected to other Blinks or not (“send X to every connected Blink”).

Well… If one Blink is pushing something, a connected Blink would have to be pulling it. In this sense, it does both.

Well, turning a Blink is a physical thing and can not even be directly detected by it (but it can be detected if it is connected to at least one other Blink). In that sense, turn left means exactly that, turn left. You could also turn right as you suggested but that is a weird way to do this (again, considering it is a physical event). :slight_smile:

I am sorry, but I think I do not understand what you mean.

Well, yes, Blinks have limitations. They can not do laundry for example. :slight_smile: I am not trying to be snarky. This is just a reference to the fact that limitations are everywhere. Blinks can do everything they were designed to do. Sure, they could do more, but then you are talking about something else entirely (i.e. not Blinks).

I think character is not relevant here. Blinks, as every other piece of technology, is a group of trade-offs obtained form a bag of features. Again, for what they do, they are pretty good.

setup() is called once. it starts when it is called and ends when it returns.

Not sure I understand the question. There are no requirements for anything in setup() except for obvious things. For one thing, it can not have an infinite loop inside it as it has to return.

setup() is just a function. There is nothing magical about it except for the fact that it is automatically called for you once. You can simply call it anywhere you want. But why would you want to do that? Setup is supposed to be used for one-off things.

In C, what you call subroutines are functions. setup() is a function, loop() is a function and everything you call in the Blinks SDK are functions. And yes, you can also write your own functions and call them.

Well, you should create variables and loops whenever a variable or loop is needed. Nothing more and nothing less.

It is not “no” and I think you are at the very least mixing concepts here. Yes, variables use memory. But if you need a variable, then you need a variable. The same applies to loops or anything else really.

To be clear, you can always optimize programs and remove. variables loops to reduce memory pressure or improve performance but you should NEVER start with that. First write your program and make it work. Then optimize.

To be blunt, at this point you seem to be a long way from being able to write even a simple Blink program so I suggest, again, you start at the very basics.

3 Likes
3

I simply wanted to clarify or reiterate here, that the code outside of loop() is only executed if called within loop (or nested within). i.e. global variable definitions simply execute once.