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

Using same UNO pin with Digital & Button Machines #55

Open
Mike58501 opened this issue Mar 22, 2018 · 2 comments
Open

Using same UNO pin with Digital & Button Machines #55

Mike58501 opened this issue Mar 22, 2018 · 2 comments

Comments

@Mike58501
Copy link

Mike58501 commented Mar 22, 2018

Tinkerspy &/or other Automaton person, If the project coder is running LOW on UNO pins & also wanted to save by using one less wire to & from a relay switch leg ... is it ever permissible to use the Automaton Digital Machine & the Automaton Button Machine with the same pin (9) as two separate reactions to the same change. For example: Digital to change an Automaton State & Button to change an LCD message? Both would be using Pin 9's input_pullup declaration so the change in the UNO ground presence on the pin is what the pin (9) would be reacting to. Thanks. Just checking ... just in case there is potentially a conflict within Automaton itself. Don't want to oversimplify or over complicate ... no no ... not this American Citizen. Thanks

@matthijskooijman
Copy link

@Mike58501, did you ever just try this? From what I know of how digital and button work, I would suspect they would just both read the same pin and work fine (except that for very short pulses, I can imagine that one of them will fire but not the other, which could be problematic). A slightly more efficient version that does not poll the pin twice every time would be to use the fan machine to trigger multiple events from one digital or button, or to trigger multiple events from an onChange lambda function.

@Mike58501
Copy link
Author

Mike58501 commented Jan 10, 2019

Thanks for the thoughts about the considerations & implications for doing what I suggested. It did turn out that the more than one pin with wires branching out in parallel would just see the now showing up common ground which made it do-able for my application. Correct me if I am wrong ... but it seems like Tinkerspy's Framework would be better if it had examples that were not just pretty much limited to just one specific sequential operation which reflects more to just a "game playing" mindset IMHO vs something more worthwhile in real life.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants