Stepper rework as variable

[bmcage]

This PR is to convert the stepper construction to using the variable blocks.

Reasoning:

1. I want to reuse the stepper mechanism for other components. However, the current method in stepper is for stepper only, so this PR creates a general mechanism that needs to be reused for other components
2. The core part is a version of field_variable, that only shows variables of a specific component type. This can be stepper now, but in the future also ledstrip, IR_Sensor, ... .
3. In making the construct general, I converted it to the stepper name being a variable like the other variables present. This has the benefit that where previously it looked like a variable but wasn't, it now looks like it, and is it also. So rename is now working, which is a big benefit.
4. What is contained in the variable? A component is connected to an Arduino via pins, so the variable is the pin to which the component is connected. This will/might be useful for other components like a LED strip, but for stepper it means it is an array of two pins (as stepper connects to two pins). I don't see a use for this at the moment, but it also is not a problem, it is not because a variable exists that one has to use the variable. If array methods are added like in the mdxly fork, then one could query the first or second pin, and send specific commands to those pins as needed. It being a variable means it shows up in the variable blocks, which was the aim, as this allows to do things like digitalwrite, ... via variables (in my branch).
5. The aim is now to add extra components.

[carlosperate]

Oh, this is really interesting! I've been meaning to refactor the current stepper implementation for ages, it was a "temporary workaround" for a workshop that ended up in the codebase far longer than anticipated.

It's a bit late to have a proper look now, but i'll check it out as soon as I can. Quick question based purely on the general description, would this result in the stepper variable name to appear in the variable block dropdown?

(I'll have a look at all the pending stuff as well as soon as I get a chance, apologies for the delay)

[bmcage]

Yes, I choose to have it appears in the variable block dropdown. Removing it there would mean more changes in core. As it contains a value (the pins the stepper is connected to), it can be a variable. For stepper it is array of two pins, which we cannot do much with, but for other components (button, ledstrip, ...) it is the pinnumber. I don't see a big need to work with these variables, but it is something I can think some interesting applications for.

[carlosperate]

Looks like this might be required, even if it compiles due to the closure parsing ordering.

[bmcage]

I saw other block files which depend on not mentioned requires which are present due to closure parsing, so commented it out. Originally I tried to have this present in blocks/arduino/ which is not possible due to dependencies, then this require is needed

[carlosperate]

As you can see with the new FieldNumber, it's good practice to explicitly indicate the dependency, if it works here I would leave it in.

[bmcage]

It gives error in build version:

FATAL ERROR
required "Blockly.FieldVariable" namespace never provided
blocks/procedures.js at line 30:
goog.require('Blockly.FieldVariable');
^

For some reason the compiler gives wrong js file where the error happens ...

[carlosperate]

Thanks for the submission, looks quite good, I've added a few minor comments.

I've been thinking about this and I quite like the idea of having a mechanism to store global "lists of things" that can be displayed on dropdowns, however I'm not quite sure they should be variables. In a lot of cases we are basically creating class instances, and while they are stored in variables, these are not variables that could be used in any other blockly "variable context" (variable blocks can be connected essentially everywhere). So I think we should separate this completely from the variable class, while mirroring the functionality and allowing to create different isolated categories.

[bmcage]

Well, the fact that they are variables fits with my overarching idea of assigning pins to variables, then using the variables to do writes/reads. So I need these variables to be able to do this, they should not be something special, but behave like the variables that have values of pins, so I can use them.

My overall plan for how I want to have children work with our projects is like this:

1. put a hub component on the board: eg an UNO, which will be a block where parts can be added:
   Hub component UNO. Attach to digital pin <dropdown_pin_numbers>:
   The nice thing here is that I will set Arduino.Board.selected automatically like that, no longer settings section needed then. What is also nice for the children is that as you give a manual of a project with how to build with breadboard, you can give these HUB block parts as a way to visualize it in blockly.
2. Then one can attach to hub components actual components: LED, LEDSTRIP, SERVO, ... which all use the scheme in this PR to obtain a variable value. Attaching it to the hub sets the pin value. A component would also have a block like SERVO now, where you set the pin in the block itself.
3. So, next one can use the variable to do things, or use the pin numbers. Using the variable in the dropdown of eg digitalwrite requires that it has something special to appear there, like in the Variable pins #70 At the moment my branch has actual variable digitalwrite versions, so I use this.
4. So, a somewhat roundabout way to use the variables. It is not really needed to do this (eg in ardublockly GUI you could not expose components that assign to a hub, and only use components that set variable and pin in the block. All will work like that.
5. Main takeaway is, if the assigned names are not variables with pin number in it, you can only use predefined blocks like eg a new simple block for young children: set LED <LEDNAME_VARIABLE> ON/OFF. If LEDNAME_VARIABLE is a real variable, you can also use the digitalwrite function (in my branch with extended digitalwrite that allows a variable to determine the pin, in the future hopefully standard digitalwrite with this variable in the dropdown list). As you might want to make a runlight over 4 LED, changing the variable for digitalwrite is what you want to be able to do, as that allows for compact, simple code, so variables used in this way must be settable, and by extension hence also the variables set in the component blocks.

[carlosperate]

If we mantain this idea of "instances of things" separated from variables, you could still assign a "thing instance" to a variable and use it as you are describing, no?

[bmcage]

Yes. Extra block needed on the canvas to describe it though. Although it are different things, variables already are different things now too (number, decimal, string ...).
I'm not convinced these variables to be separate from the other variables brings something extra to the table.

[bmcage]

Ok, tackled most issues, inheritance can indeed be simplified. Not a js coder though, so I hope I follow the correct paradigm ...
I'll do these changes in my branch where I use this construct more extensively for further testing.

[bmcage]

To have an idea how this looks when having many constructs that use this, see example:
http://ingegno.be/Manuals/Blockly4Arduino/blockly4Arduino/index_en.html?url=examples/MD_Caroussel_Muziek.xml

So, if you add a variable there, then the dropdown of the variable has all those names. Is that a problem or cumbersome? If you work with variables you typically set it once, and then use copy/paste to have other copies, so the fact that the dropdown contains more is not really a problem.

If we have a way to identify which variables are pins, then all those should be present in the dropdownbox of a digitalwrite or read.

[carlosperate]

Thanks a lot for all your contributions @bmcage . I'll finally have some time to look into this properly, for now I've merged into master and started playing with it locally, I'll let you know how it goes as I might think about creating this "instances of things" system based on the same concept as blockly variables.

[carlosperate]

As I mentioned in the earlier discussions, I finally had some time to add some kind of "instance" implementation that can be used to create custom dropdowns.This also maintains it separated from variables, as otherwise these could end up being used in all kinds of "invalid" block configurations.

It's not finished, and needs some work to fix a couple of minor issues, but the bulk is in there: c757d75

You can see that blocks can now do a new Blockly.FieldInstance() and based on the input arguments everything else should be taken care of.

@bmcage I was wondering what was the reason to add a global array for the stepper pins in this PR.
Using the stepper config block creates a global int MyStepper[2] = {1, 2};, which is really not used for anything else?

[bmcage]

The stepper is special in attaching to two pins. For components that attach to one pin, this global is an integer and can be easily used in blocks.
For the Stepper this is not directly possible. One could create functions though that work on the pins of a stepper, and then passing a stepper means the function can use the MyStepper global to access these pins, knowing that global exist.

So it is a design choice to always create a global with the pins of a component. If it was an LCD, it would be a longer array. In reality, a component hopefully has a library with one init function, and one can pass the pins once, and forget about them, making this global unneeded for actual use as the functions are then library functions.
PS: almost in holiday mode, so slow posting ...