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

Idea: Universal Badge Platform #217

Open
renzenicolai opened this issue Jan 11, 2018 · 1 comment
Open

Idea: Universal Badge Platform #217

renzenicolai opened this issue Jan 11, 2018 · 1 comment

Comments

@renzenicolai
Copy link
Member

There are multiple badges that run Micropython like the Tilda Mk. Pi and the SHA2017 badge. Since Micropython seems to work well enough to have the potential to be used in many more camp badges I propose that we define an API which would allow apps to work on all current and future Micropython based badges.

Another thing is the appstore. I think we've got that working great using Woezel. Backporting woezel to the Tilda Mk. Pi badge seems like a great way to improve that badge.

Also API calls to interact with for example LEDs, speakers, buzzers and buttons could be defined in such a way that an app would not have to be changed to work on different hardware.

Last thing: maybe it's an idea to create a sort-of descriptor so that an app (and the appstore) knows if certain hw features are available?

@basvs
Copy link
Contributor

basvs commented Jan 11, 2018

A conference badge is a special thing. They are not designed to be the same as any older conference badge, but are designed to show the possibilities of recent hardware technology and at the same time offer a simple and interesting platform for developers.

I don't think you should hide all the fancy features behind a thick API layer. It should be possible to use the badge to its full extent.

But on the other hand, when designing a new badge, I think it should be preferred that one uses the same function-names where possible. (you should not enforce it..)

There is imho however a place where API standardization should be, and that's in the micropython libraries. (e.g. your Easy*.py classes). Application-developers can then choose between being compatible with multiple badges and being compatible with only one or two badges.

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