You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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?
The text was updated successfully, but these errors were encountered:
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)?
Without testing, it's hard to know for sure, but yeah, its possible. One
option it to have any init block detect if it's inside a function and
generate code online as opposed to at setup.
On Wed, Apr 17, 2019, 8:00 AM Parallax Git Administrator < ***@***.***> wrote:
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)?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#1661 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AS0quIGQ7D-bt24oA0YmICz-Yt87t7ZKks5vhzcNgaJpZM4cvMkL>
.
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.
@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:
The text was updated successfully, but these errors were encountered: