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

define PIN schematics for different arduino models #69

Open
lobsteroh opened this issue Nov 17, 2016 · 3 comments
Open

define PIN schematics for different arduino models #69

lobsteroh opened this issue Nov 17, 2016 · 3 comments

Comments

@lobsteroh
Copy link
Contributor

I was wondering whether and, if so, how, JArduino handles the different pinouts for different arduino models. answers on this in past issues didn't seem conclusive. the rather rigid definition of pins in JArduino is great when it prevents us from using digital pins for analog writes, however, it also really limits our ability to use boards that have different pin characteristics. as far as i can tell only the uno is defined. the mega is the more useful board because it controls so many pins at a great price. i can change the pin definitions and recompile with maven but that will get mega working while it breaks the uno. i suspect separate pinout schematics for different models are the way to go but i dont see whether that has been tackled. any suggestions or advice on preferred design?

@brice-morin
Copy link
Contributor

One problem is that Java does not allow for extending enumerations. One possible way of doing it is to define an abstract class Platform and then have two (or more) concrete classes UNO extending Platform and MEGA extending Platform or UNO. Each concrete class can define a set of static final PIN element. We should then be able to use pins like this: UNO.PIN1 or MEGA.PIN1.

@lobsteroh
Copy link
Contributor Author

yeah, not a bad tack. could you be tempted to take a stab at the basic layout of classes? i'd be happy to add pin schematic details for individual models, if you like. teensie would be another model to include, by far the best hardware of the bunch in my hands. Alternatively, a much simpler solution would be to drop the rigid link between pin function and address, but, i guess, you would not be a friend of that.

@brice-morin
Copy link
Contributor

I am quite busy at work until end of November and cannot unfortunately commit to look into this issue in more details before early December. I suspect it is just a 20-minute refactoring, but you never know before it is done...

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