Currently there is no support for CircuitPython for Tufty. I can find a CP-fork with Tufty support, but this fork is now 800+ commits behind main.
I followed the open issue on that, but there has not been any progress for a long time. Do you think it is possible to create a pull-request for mainline CP? This would mean that the CP uf2 is built automatically and allows more people to play with it and maybe this will help with fixing the open issues.
BTW: Adafruit also has some board in the main-tree which are by no means stable or feature complete.
I’m thinking you’re going to have to ask this request of Adafruit. I don’t think Pimoroni has much control over what happens Circuit Python wise.
Just curious what you want to do, Circuit Python wise on your Tufty? I have one and have had a lot of fun with it. Micro Python here though.
No. Board specific code in CP is maintained by the manufactures. The fork I am referring to is from Pimoroni.
CP has many, many libs which you can just install using “circup”. As simple as with pip. With MP, I have to hunt all over the internet to find libs, and many of them don’t “just work”. And even if they work, they have to be manually installed and maintained.
An example: I would use a cheap ESP-01S as a wifi coprocessor for the tufty. With CP, this is a matter of a addding a few lines of code. circup would then detect the missing libs and update everything. Same with sensors and so on.
MP does have a number of advantages compared to CP, but I decide on a per project basis what to use. And often I do prototyping using CP and then switch to C++.
Yes, I have read this issue. But it does not help anybody if you keep your current work in a fork which is now almost 900 commits behind mainline. As far as I can see we are talking about five tufty-specific files, so it should be no problem pushing these to mainline. It would give hackers a chance to play with it and maybe solve the problem. But nobody wants to work on a fork that is so old…
Chris has updated the fork to be inline with mainline, so it should be easier to build now. He’s reluctant to raise it as a PR though until the issue is resolved.
The display-driver is not perfect yet and produces artifacts, but I have tested the release with various programs and it works sufficiently fine (for me at least).
Note that this release is not in any way official, so don’t expect support. But feedback is welcome.
The state of the code hasn’t changed since last October. I could create a current 8.2.x tufty-version if this helps. Artifacts are still there, but similar artifacts are also visible with MicroPython. So I think this is a hardware problem (firmware of display controller), rather then a CircuitPython issue. The workaround is to keep away from plain-white (or nearly plain-white) colors.
To make it official, Pimoroni must provide an USB_ID and create a pull-request for circuitpython.org (download site). I could create the pull request for CircuitPython code.
This is the bouncing-ball example. It works perfect with a pure white ball on black background. But as soon as you flip the colors, this fails. The workaround is to keep away from pure white. Note that I have other working programs that do use a pure white background, but not for the whole display.
Buttons, light-sensor and so on are accessible using the board-module, but you have to create the relevant objects (e.g. DigitalInOut) yourself.