Skip to content
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

Block request: run as setup #1661

Open
MatzElectronics opened this issue Apr 15, 2019 · 3 comments
Open

Block request: run as setup #1661

MatzElectronics opened this issue Apr 15, 2019 · 3 comments
Assignees
Labels
Block Request Experimental Alpha quality features not quite ready for public testing In Demo

Comments

@MatzElectronics
Copy link
Collaborator

@VonSzarvas pointed out an unfortunate side effect of having init block code always generate at the top of the main() function. He described it as so:

Sometimes I like to run little sensors direct from the FLiP pins. I've seen you enjoying that shortcut in the past also :)
So we need to set the appropriate IO's for sensor VIN and GND to high and low BEFORE calling SPI init.
But... The blockly code pushes the init block to the start of main(), so if you had used "make PIN blocks" and a pause, before the init, they get called only after the init :)
The three blocks I used are in the attached blockly picture, but set to disabled so a little grey looking. When swapping to code view, those three blocks are pushed after the "Air Quality init" command...Is there a way to use "make PIN" blocks /etc... , and force them to stick at top of main?
Maybe some sort of container block for setup instructions (like how the "do" block works, that other init commands cannot jump ahead of?

@MatzElectronics MatzElectronics self-assigned this Apr 15, 2019
@MatzElectronics MatzElectronics added In Demo Requires Verification Experimental Alpha quality features not quite ready for public testing labels Apr 17, 2019
@PropGit
Copy link
Contributor

PropGit commented Apr 17, 2019

Good point. It seems this behavior may also affect other cogs too. For example, wouldn't "pushing the init block to the start of main()" mean that pin direction initializations intended to be executed in the context of another cog be done in the wrong context (ie: the wrong cog)?

@MatzElectronics
Copy link
Collaborator Author

MatzElectronics commented Apr 17, 2019 via email

@Steph-Parallax
Copy link
Collaborator

Interesting conversation! For clarification, are we talking about init blocks for specific devices, protocols, or both?

@MatzElectronics , you have an "In Demo" and "Requires verification" tags up above. Is there a new block or block change in Demo, and if so, where?

@PropGit You bring up a good point. Presently, if these init blocks are always pushed to the top and run in the main core, and can't be used in a function launching in another core, that needs to be documented throughout the Reference as we do with some of them already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Block Request Experimental Alpha quality features not quite ready for public testing In Demo
Projects
None yet
Development

No branches or pull requests

3 participants