Idea : PIN Configuration Block

[VonSzarvas]

Block which expands with all 32 pins, and allows each one to be given a "constant name" and default pin state, which gets set immediately after main()

This is currently achieved by dragging across 32 of the "constant" blocks. Then using up to 32 "make PIN" blocks to set the default states. Takes a heap of time!

Especially for custom boards, but maybe all board types could be useful to some extent...

[MatzElectronics]

Like this?

[VonSzarvas]

That works! Cool!
Does that already exist somewhere ?

[MatzElectronics]

No, mocked it up with the block factory...

[VonSzarvas]

About the name field... having to tick a box then type seems like work....

could that tick box "autotick" when you type in the name box ?
or do away with the tick... if the box is empty it's "unticked" already :)

[MatzElectronics]

Yeah...I wasn't sure what the best way to handle that one would be - but probably just reading a blank field as "don't create a name for this" would be best.

[PropGit]

Input, high, and low are mutually-exclusive. Is there a way to make them radio buttons, or perhaps they should be combined into a single drop-down field with the three choices.

[PropGit]

Will this block always show all 32 I/O pins, or will it be user-expandable and able to specify non-contiguous pins (in order, but not contiguous)... ie:
0, 1, 2, 3, 8, 9, 15, 30, 31 (for example)

[PropGit]

One thing to think about: people may misinterpret this to mean it's setting the pins for the chip, regardless of additional cog activity, but each cog needs to set pins the way it intends to use them; the collective determines the overall result.

Ideally, once someone places a block to run a function in a new cog, it'd be awesome if we could determine whether or not they've configured I/O pins in that function and show a warning on the function that it needs I/O configuration specified to work properly in a new cog.

[VonSzarvas]

Will this block always show all 32 I/O pins, or will it be user-expandable and able to specify non-contiguous pins (in order, but not contiguous)... ie:
0, 1, 2, 3, 8, 9, 15, 30, 31 (for example)

I'd vote to keep it simple. All visible when editing, then collapse to only those pins used when in "normal" blockly view. With the option to shrink/grow like all the other blocks.

[VonSzarvas]

One thing to think about: people may misinterpret this to mean it's setting the pins for the chip, regardless of additional cog activity, but each cog needs to set pins the way it intends to use them; the collective determines the overall result.

Ideally, once someone places a block to run a function in a new cog, it'd be awesome if we could determine whether or not they've configured I/O pins in that function and show a warning on the function that it needs I/O configuration specified to work properly in a new cog.

Well, the pin-setup-block could be a "per cog" deal. Although the CONstants will work in all cogs... hmm.

Maybe this pin-setup shouldn't include the default pin state then.
Just allow a simple way to set pin name constants for each IO. They will be accessible for all cogs, and it's up to the user to insert make-pin blocks in each cog that wants.

Even that will be a significant time saver, and also provide a nice neat list of pin definitions at the start of the code. Another bonus to this simplification, is that you don't need to think about function warnings and conflicts.

So.... this is just a multi-line constant block really. With a title hopefully !

constant group block [title]
+ add line
name and value

[VonSzarvas]

BTW... one reason a constant group block like this would still be a significant improvement over the single constants, is that you can't drop multiple undefined constants onto the page without the warning triangle appearing, and things grinding to a halt. So you need to drag, edit, drag, edit, drag, edit. Takes forever !

Plus having a collapsible group of constants, perhaps with a nice comment-title, would be very tidy.

[PropGit]

Well, the pin-setup-block could be a "per cog" deal. Although the CONstants will work in all cogs... hmm.

Maybe this pin-setup shouldn't include the default pin state then.

whoops... I didn't actually even think about that! I was thinking they'd have to use this block in each function (of course) but not that the constant names would be duplicated (or separated).

The easy thing to do is change this request into a constant group block (as you suggested) instead of a setup pins block, but please consider this as a possibility and think about if it will make thing better, or be too complicated.

Three group blocks:

• constants block
• name pins block
• setup pins block

The name pins block can be used to create a bunch of friendly names for pins (which applies to whole application) and is limited to 1 such block per project. The setup pins block can use names from the name pins block (or pin numbers themselves) to set default (initial) states of pins for application and/or cog-function; 1 such block per cog.