global-constants.md

Good Idea? Bad Idea?

The Arduino programming environment is bootstrapped with many preprocessor definition contant values, specifically created to make the programming experience more accessible to non-programmers. Some specific examples include:

• Analog Pins:
  • A0: 14
  • A1: 15
• Modes:
  • INPUT: 0
  • OUTPUT: 1
• Values:
  • HIGH: 1
  • LOW: 0

...And many more.

Should Johnny-Five expose similar global constants?

Please post thoughts in the comments. I'd like to flesh out the lists below before making a decision.

Pros

• Easily memorized by users
• Increased accessibility for those familiar with Arduino IDE programming
• Potentially reduce user code errors (?)

Cons

• Global scope pollution

+1 for namespacing.

@WebReflection, when using Firmata from a client (J5 in this case) you do not know which board you are dealing with until you query it. At least with the way Firmata currently works (I know because I am the maintainer of the Firmata library). Obviously you could assign values to A0, A1, etc once the query returns and you have the mapping. This is Firmata-specific. You would not have this issue when using J5 with board-specific plugins.

One way to get around this (when using Firmata and J5) would be to add an option to declare the board (or architecture) used when creating a new instance of five.Board. That would also eliminate the need for the configuration query and analog mapping requests and would ultimately allow for a much faster startup time upon connecting to the board. If the board type is not specified, then fall back on the configuration query and analog mapping request.

Regarding analog pins, when using Firmata, you won't know the mapping until the configuration query and analog mapping response has returned so I'm not sure how you could use a constant since the mapping of analog pins to digital pins differs per board.

@soundanalogous thanks for this reminder.

Probably expose on the board and receive from the IO implementation. You could make them getters on board that proxy through to the IO class or attach during bootstrapping.

You could make them getters on board that proxy through to the IO class or attach during bootstrapping.

exactly my thoughts here too

A namespace wouldn't solve anything in this scenario anyway, would be just delegating the problem to j5. instead of just global

GLOBAL ALL THE THINGS

Given that J5 can support multiple different boards concurrently (I think), it's probably not a good idea for constants like A0 through An to be global. Different boards will have a different number of analog inputs. Exposing them on the board as suggested by @phated is a better way to go.

Lots of the constants in the header files linked to above are very specific to a particular microcontroller. Most of the constants are probably not needed and if they are, exposing them on the board is also the better way to go.