What the heck is CircuitPython? Get that question answered along with many more during this Friday’s Hack Chat. Three engineers from Adafruit join us as [Ladyada], [Tony DiCola], and [Scott Shawcoft] lead a CircuitPython discussion at Noon PST on 1/27/17.
CircuitPython is Adafruit’s new extension on the MicroPython codebase. It adds support for SAMD21 processors in MicroPython and reworks the API for better support across platforms and better documentation. Does this still sound like jibberish? The Python programming language has been extended to microcontrollers. CircuitPython is furthering that work and this Hack Chat is the perfect opportunity to talk with the people who are doing that work. They will also be doing a giveaway of five CircuitPlayground m0 Express boards (brand new, not yet released hardware).
Don’t miss this Hack Chat! Here’s a handy web tool to help convert Friday, January 27 at noon PST to your local time.
Here’s How to Take Part:
Hack Chats are live community events that take place in the Hackaday.io Hack Chat group messaging. Visit that page (make sure you are logged in) and look for the “Join this Project Button” in the upper right. Once you are part of the project, that button will change to “Team Messaging” which takes you to the Hack Chat.
You don’t have to wait for Friday, join Hack Chat whenever you like and see what the community is currently talking about.
If everybody would fork Micropython for their own companies benefit instead of contributing to the original project, Micropython would be dead already. I watched the youtube video and missed any reason for the fork other than we want to be incompatible with (aka not to be confused with) Micropython. Also, they made it clear that Adafruit does not have the resources and has no intention of developing a “real” fork.
Bottom line: Adafruit uses Micropython but no one shall use Adafruit code with Micropython. This obviously seems to be within the scope of the licenses but I don’t have to like the taste of it. The Micropython forum already gets questions/requests about other commercially motivated forks. In the long run, you’re killing the project for personal short term benefits.
Where’s my like/upvote button?
Didn’t watch the video, but if everything’s like you said, I don’t see why I would support it in any way. I suggest we ask this question during the HackChat, what do you think?
Thanks for the warning, I already had a gut feeling about that lot, but now we have a clear example of their attitude. They are starting to remind me of another notorious and now widely hated ab.user of other people’s efforts.
hi folks,
the usual disclaimer, i was the founder of hackaday, including designing the site/logo, etc. now work with ladyada at adafruit and together we work with the team on the hackchat this friday (tony, scott). adafruit stocks and sells micropython boards directly from micropython.org, we supported the micropython kickstater and have donated to damien george (creator of micropython) and we give a royalty of micropython related merchandise to damien george (creator of micropython).
we talk/meet with damien at least once a month and work together on open-source efforts involving the micropython ecosystem that has started (micropython, circuitpython, micro:bit, pycom, adafruit and others).
all of our work is open-source and MIT licensed and we work towards keeping step with upstream providing updates, pulls and more.
you are welcome to email and talk to damien directly, we think we’ve done a good job working together with open-source so we can make sure things work with the hardware we make/share.
here are some replies and comments :)
re: pricing/shipping. we are a USA company that makes electronics in our factory in NYC, we do not have any loans, we do not have an VC, we are over 100 people that have full benefits, 401k, vacation, sick, personal time, paid time off for charity, paid family leave, commuter benefits, paid holidays (last week was mlk day, a paid day off), we provide snacks and more to everyone, there are more benefits, but that’s a good overview, we also have not had a starting hourly rate less than $16.50 for entry level folks and we promote from within, for example our CFO started in kitting.
you can see many videos of our factory in NYC, they’re on youtube and more, we do live shows every week so saying all our stuff is “crap they sourced off of Aliexpress” with a “500-1000% mark-up” is not correct.
here is a live tour we did with west point recently with ladyada:
https://www.youtube.com/watch?v=PVx7xpYnWZI
we have over 3,000 products and make many of them here, locally, some things like wires and more, yes, that will come from sources worldwide of course.
regarding “their ugly libraries written with the feet” – we do not write any open-source code with our feet, we currently have over 700+ open-source libraries on adafruit’s github account.
re: shipping costs – it _is_ correct to say shipping is not free, we have free UPS ground, trackable and reliable, in the continental USA for order $200 or more. it costs money to ship and we have the lowest rates possible with UPS and USPS, we do not ship USPS to all locations if the failure rate is so high that packages do not make it, so we often have UPS only for some locations. we have resellers such as digi-key that have more and other shipping options, check them out, along with 2,000+ other worldwide distributors.
i’ll post other replies soon about SAMD21, etc and more (lars).
Wow, that’s a nice answer, addressing most of the points! Thank you!
Thank you for you reply, these guys seem to think that they know ALL and turns out they are all bitter, for some unknown reason.
Adafruit is so corporate about everything. I find there advice not useful or encouraging. No thanks
There advice can be good. But I hate how they treat their customers. I have seen one too many customers get grilled by their employees on their public forums. Instead of taking advice they would rather argue with you and tell you how you are wrong in your way of thinking. Not to mention their high prices and high priced shipping.
Oh, come on! A 500-1000% mark-up + $10 shipping on crap they sourced off of Aliexpress? That’s just good (read: predatory) business! I have long since stopped visiting their blog and forums due to the overwhelming egos of just about all their staff, not to mention the strong political/social slant on everything they post.
Really????? Wow, just wow. Not a single thing any of you have said is accurate or true. I guess these days working all hours and creating a successful business means it’s ok for others to hate you …………
You need to take a long good hard look at yourself. You are not nice people.
Adafruit, adajuice, adapress the customers, this shop is a RIP-OFF. Greedy people!
and if they on top of top shit in the pants of good open-source projects, they deserve only one thing:
B-O-Y-C-O-T-T
Just waiting they get 30-35% tax markup on the cheap goods they buy from china, and they will disappear with their ugly libraries written with the feet !
Hey, It’s New York. Whadaya want, ya mook.
Yeah, It’s not like they have several huge manufacturing facilities and employee hundreds of US based Americans, build thousands of Made in the USA products or support 10’s of thousands of makers or or anything…that would really suck.
You don’t make “Entrepreneur of the Year” by paying attention to customers or providing break-neck dev support.
Lol had to read the paid time off for charity line twice. I think I see where the heatsink is…
Lots of carts before horses here. Angel-funded cottage industry indeed…
“… lead a CircuitPython discussion at Noon PST …”
Please consider using UTC or GMT instead.
Readership is global. If everybody would insist in publishing event times in their local time, every reader would have to memorise lots of timezone offsets. If we all use UTC or GMT, everyone only needs to know his own offset to global time…
…with best wishes from somewhere around GMT+0042…
;-)
A salute from a UTC-2 guy! Until February 19th (end of daylight saving time in Brazil), when we’ll be UTC-3.
:)
;-)
GMT+0042 is calculated from my geocoordinates. This way I’m playing with “real local time” and the next clock I’ll build will have a “real local time” mode… \o/ …I just cannot make up my mind for which kind of display to use.
…but maybe the the fun is more the thinking about it than having such a clock…
And DST sucks!
Go full one-day Sundial… :) (you know – for the kids)
http://www.thingiverse.com/thing:970654
While we’re at it, can we lobby to use a rational date format? That middle-endian ambiguous American style (1/27/17) is just nuts. ISO8601 maybe?
I’ve heard it’ll be discussed by Congress on 03.12.17, go and contact your representative! ;-)
YMD is the easiest to sort by date. Punctuation is optional but helpful, to avoid confusion with Julian dates:
2017-01-17 vs
2017.01.17 vs
20170117 vs
2017017 (Julian)
Can also be extended into time, with a Z to indicate Zulu (GMT)
2017-01-17-Z2215
YMD
YMMD
YYMMDD
YYYYMMDD
No need to confuse the issue with still more confusing formats, including that unholy perversion of “Julian” you used. ISO8601 is pretty darned clear (especially considering it’s an ISO document…). https://en.wikipedia.org/wiki/ISO_8601
Just use it. Even Randall Munroe endorses it: https://xkcd.com/1179/
BTW, it’s 12017….. :-D
https://www.youtube.com/watch?v=czgOWmtGVGs
I Like it. Year zero. Or -7473 Centigrade.
Too bad you folks can’t access Google from way on the outside.
yes my young padawans, let the hate flow throw you…….
Unlike others, I have watched their videos. They have been supporting micro python and their reason for forking it is to make changes to enhance the learning experience and tailor it to their needs. This is exactly how Open Source works, you find something you like, want to change some bits, so you fork it and make your changes. Maybe later, you can see if they can go back into the main branch.
I concur Rich, this is also my understanding of how Open Source has worked and does work!
Why don’t they contribute the SAMD21 support to the Micropython project but only to their fork?
Why can’t their IDE not be based on the original Micropython project?
Why can’t they do their renaming of APIs with a class within the scope of Micropython?
Why does ESP8266 need another API?
Why don’t they contribute board files for their boards to the Micropython project instead of forking?
If the intention of the fork is to develop outside of the main branch and then port back, why the effort to introduce a dedicated name for it to the community? Why is there the effort to start another community for Python on micro controllers?
What exactly means “tailor it to their needs”?
“They have been supporting micro python”
<- What contribution to the code would that be, beyond giving support for the products that they sell? (Maybe I missed it)
"Maybe later, you can see if they can go back into the main branch."
<- Did they mention that and I missed it or did you made this one up?
No one is required to answer any of those questions. But then, I don't have to believe that the fork was made in order to "enhance the learning experience".
In general, I agree that anyone could port features back into the Micropython branch, but those guys are already shorthanded.
I just don't see (yet) how in theory the Micropython project can have anything but disadvantages from this fork. Everything seems to be designed contrary to porting things back to the main branch.
If you use Micropython to make money, this might already be a contribution to the project in terms of spreading. You make yourself depended from the project and might contribute in terms of bug fixing and adding features (e.g. because you want to see those features in the main branch for the convenience of your own developments and sells). How does a fork designed to be incompatible with Micropython help the original project?
Hi Lars and everyone,
I’m Scott (aka tannewt) the main dev on CircuitPython. I hope to answer all of the technical questions. For questions about Adafruit Phil and Ladyada are best. Lars, I’ve taken your two posts and replied in line. Thanks for the thoughtful questions.
“If everybody would fork Micropython for their own companies benefit instead of contributing to the original project, Micropython would be dead already. I watched the youtube video and missed any reason for the fork other than we want to be incompatible with (aka not to be confused with) Micropython. Also, they made it clear that Adafruit does not have the resources and has no intention of developing a “real” fork.
Bottom line: Adafruit uses Micropython but no one shall use Adafruit code with Micropython. This obviously seems to be within the scope of the licenses but I don’t have to like the taste of it. The Micropython forum already gets questions/requests about other commercially motivated forks. In the long run, you’re killing the project for personal short term benefits.”
The decision to fork wasn’t a simple one. Every contribution to an open source project starts with “Fork” on GitHub. We started there, creating adafruit/micropython and began changing things to better match our needs.
The most obvious need is the SAMD21 port which allows MicroPython to run on Atmel’s SAMD microcontroller that is the heart of the Arduino Zero and Adafruit’s M0 boards. Another need of ours was to have a unified hardware API across the SAMD port and the ESP8266 port which runs on the Adafruit Feather Huzzah. We want to write drivers once for both ports and have them work on both. Lastly, we need a great teaching language that makes it really easy to get started and easy to move to desktop Python (aka CPython).
So, with all of these needs, we had a lot of work to do. Our approach was going to be to experiment in our fork and see where it took us. Checking in with upstream on every idea we had (unified hardware API, autoreset after save, tweaking modules shared with Python) would simply slow us down. While we implemented stuff in our fork, the upstream MicroPython devs announced pull requests would take even longer than they already were due to the backlog (https://github.com/micropython/micropython/issues/2602). So, given the speed of our development and the remaining work we decided to not pursue pull requests upstream because they would take a significant amount of time. Instead, we decided to continue working on our own fork and financially contributing to Damien’s upstream work.
This was the point where we were committed to being a longer-term fork. None of us see this as an attack on upstream MicroPython. It simply gives us the freedom to create an awesome variant of MicroPython designed around the needs of our audience. Our fork maintains the MIT license of upstream and we all would love it if upstream pulled code from our fork that they find useful. We continue to integrate upstream releases into CircuitPython both in order to get the new features of upstream (95% test coverage!) and to ensure our work can be moved back upstream in the future. This sort of relationship between forks can work really well. I saw it first hand with Cleanflight, Betaflight and iNavFlight in the drone flight controller world.
After this point of choosing to be a longer term fork we wanted to start releasing betas. However, there was a problem with naming that we wanted to sort out before the first beta. At that point we’d agreed on calling in “Adafruit MicroPython” but more often than not we’d call it “MicroPython” for short and confusion would ensue. (You mean “MicroPython MicroPython”?) Furthermore, we’d stayed with upstream’s version and tack on our version info leading to versions like v1.8.5-20161020. These versions make it less clear what we think the state of code is and what user’s should expect. So, we had a new discussion on name. Having a name without MicroPython in it ensures it doesn’t get shortened back to the original name and gives us the opportunity to reset our versions. So, we already had a fork and decided to rename it Adafruit CircuitPython. This would clarify what version of software someone was running and we’d still give credit to MicroPython as the parent project in our README and as showing us as a fork on GitHub.
I hope that clarifies how we became a fork of MicroPython and demonstrates that we still hope for a good working relationship with MicroPython. They do a lot of awesome work.
“Why don’t they contribute the SAMD21 support to the Micropython project but only to their fork?”
Pull requests take time and its not a port that upstream wants to maintain. They are focussed on STM for PyBoard and ESP8266.
“Why can’t their IDE not be based on the original Micropython project?”
Not sure what you mean. Please elaborate.
“Why can’t they do their renaming of APIs with a class within the scope of Micropython?”
We’re not simply renaming APIs. We’ve actually changed the structure of the hardware API so that the Python API and its docs are in one place that is shared between ports. This idea was brought up with MicroPython devs but they preferred to allow ports the freedom to tweak their APIs. This is a good choice when your goal is to provide in depth MCU functionality to users but our goal was to have an identical API across ports to build drivers and simple abstractions on.
“Why does ESP8266 need another API?”
To be consistent with the SAMD21 port.
“Why don’t they contribute board files for their boards to the Micropython project instead of forking?”
Not sure what you mean by board files. All but one of our boards we support run on the SAMD21 which required a completely new port.
“If the intention of the fork is to develop outside of the main branch and then port back, why the effort to introduce a dedicated name for it to the community? Why is there the effort to start another community for Python on micro controllers?”
It’s not our intention to port back but we don’t want to rule it out in the future. That is why we keep pace with upstream development. The new name helps keep clarity between versions with different goals. This is good for both forks.
We have our own support forum for MicroPython and CircuitPython on the Adafruit forums because it makes it easier to track who needs help on Adafruit products specifically. It’s the standard way for Adafruit technical support and ensures the best experience for customers. We’d love to see our customers grow into full blown MicroPython and CircuitPython contributors but that takes time.
“What exactly means “tailor it to their needs”?”
I think I laid this out well above. In short, it means supporting the SAMD21, having a unified hardware API to build drivers on and making it easy to move knowledge learned on CircuitPython to CPython.
““They have been supporting micro python”
<- What contribution to the code would that be, beyond giving support for the products that they sell? (Maybe I missed it)"
Code contribution via pull requests isn’t the only way to contribute to an open source project. Damien, the creator of MicroPython and one of two core devs, has started his own business selling PyBoards and by selling those on Adafruit and contributing a portion of sticker and patch sales we are helping pay him for his time spent on MicroPython.
We’ve also implemented a lot of good improvements to MicroPython that upstream devs are welcome to incorporate upstream. Pulling code upstream isn’t simply a matter of someone fighting to get a pull request into upstream. Upstream has to recognize features they want and reach out.
""Maybe later, you can see if they can go back into the main branch."
<- Did they mention that and I missed it or did you made this one up?"
It’s something we’re open to in the future. For now we’re moving fast while staying close to upstream by incorporating every upstream release.
"No one is required to answer any of those questions. But then, I don't have to believe that the fork was made in order to "enhance the learning experience".
In general, I agree that anyone could port features back into the Micropython branch, but those guys are already shorthanded."
Them being shorthanded also makes it harder for us to get our pull requests into upstream. By experimenting and moving fast in our own fork I hope upstream devs can prioritize between their goals and features from CircuitPython they like.
"I just don't see (yet) how in theory the Micropython project can have anything but disadvantages from this fork. Everything seems to be designed contrary to porting things back to the main branch.
If you use Micropython to make money, this might already be a contribution to the project in terms of spreading. You make yourself depended from the project and might contribute in terms of bug fixing and adding features (e.g. because you want to see those features in the main branch for the convenience of your own developments and sells). How does a fork designed to be incompatible with Micropython help the original project?”
CircuitPython isn’t designed to be incompatible with MicroPython. Thats not our goal. We’ve only broken compatibility where it’s necessary for our goals of unified API between ports and CPython. One example is our removal of time.ticks_ms() in favor of the CPython time.monotonic() function. Yes, it breaks compatibility with MicroPython but it instead is compatible with CPython. So, if someone learns to animate with time.monotonic() in CircuitPython they can use the same approach for animation in CPython.
We’ve kept machine as is in the ESP8266 port for the same reason. Machine doesn’t exist on the SAMD21 port because it’s not clear what the API should be and we have limited space. Nativeio is better defined so we use that instead.
Thanks!
~Scott
Hi Scott,
thank you for spending your time on answering and for providing insights and details. I hope that you can use some of it in a FAQ section in case others have similar questions/thoughts.
I recognize that Adafruit spends a lot of resources on Circuit python.
In my initial posts, I made it sound that Adafruit alone is to blame for the fork. Sorry, this might have been premature, I cannot judge this.
The Micropython guys are shorthanded, but you seem to have some man power. So it seems, that there was no way that you maintain SAMD21 inside the Micropython project and it wasn’t even worth a try.
Now (if our plan works out) we are going to have two APIs for ESP8266. We are going to have Micropython libraries based on time.ticks_ms() and we are going to have libraries based on time.monotonic(), aso. I wonder, if anyone will ever port things back and forward, since there is a lag of man power and common ground for working in the same project already. With every improvement you make, you go one step further away from compatibility with Micropython. After all, this is your motivation for a long term fork in the first place: Being “more different/better”. The next company might just do the same…
…I would have loved to see some other company putting significant man power into the original Micropython project (libraries for stuff they sell or some uC ports or boards)…
An FAQ is a great idea! We’ll definitely do that.
Contributing to upstream isn’t simply a question of man power. Theres a coordination cost on upstream and us around pull requests that would outweigh any gains I think. Furthermore, the difference in project goals (deep, powerful APIs (MicroPython) versus more basic but universal APIs (CircuitPython)) wouldtake time to iron out in order to work in one codebase. We chose to demonstrate the changes we’d like to see instead of discussing them beforehand.
Porting across different time implementations is doable but not a priority for us. Choosing to match CPython’s monotonic is more important. I realize that projects can drift apart and hope to limit that drift by merging in upstream changes. Some forks don’t even try to do that. Its also important to point out that the vast majority of our changes are in the port specific code and hardware API. The Python core is almost identical with MicroPython. A lot is still shared.
Thanks again for your thoughts on this. I hope you join in the chat tomorrow!
thanks lars and here is the video from the chat, enjoy!
https://www.youtube.com/watch?v=jTNVra3IENs
I love you guys for giving a single click “convert this datetime to a different timezone” link!
Adafruit is a nice site.
However their datasheets need work.
HaD is tagging articles with ‘Hack Chat’ and ‘hackchat’ but not both