@Tonygo2 Mine shipped International Tracked, so about a week.
It should have anything needed to play with Pimoroni breakouts, all the QWIC stuff already backed in.
I’ve been trying a write a simple program but only get errors.
I can create .png icon, put code from the examples into a _init_.py file, load then onto the TUFTY drive. TI can run them from the menu but always crash.
The programs on the TUFTY are all very clever but far too long and complicated to easily see what is going on.
A very different environment from normal MicroPython with Thonny.
One wonders what would happen if you flash it with Pimoroni’s rp2350 uf2?
Assuming you can go back to the shipped as / with setup?
We really need a link to the Github page for this.
I’ve been fine tuning with my go to program on my Tufty 2040, thinking it will be an easy port to the Tufty 2350. It looks like I’ll be doing some head banging. That’s not a complaint per say, it’s not like I haven’t done it before. It’s hurry up and wait time for me though. With a little luck I’ll have mine by the end of next week.
It probably would not run, since it does not support the hardware (large flash, display and so on). From what I see in the docs linked above, “badgeware” is more an OS with integrated application-starter. This will work if you follow the rules, i.e. use the provided APIs.
Now I am not sure if this “badgeware”-stuff is all Python and you can just dump it and replace it with your own code or not. In the latter case, the firmware would have to support at least the hardware including updated versions of pico-graphics and/or vector-graphics.
I was just thinking out loud as they say. I do believe the Tufty 2040 shipped with a menu system. Which I have nuked / removed. Currently Thonny shows,
MicroPython v1.25.0, tufty2040 v1.25.0 on 2025-05-12; Pimoroni Tufty 2040 with RP2040
And I see I have the tufty2040-v1.25.0-pimoroni-micropython.uf2 saved to my PC. I should have had a look before I posted, as I was thinking I had flashed it with the generic Pimoroni RP2040 uf2.
Hopefully some links show up to the Tufty2350 recovery image etc.
Pretty much the thing that’ are 100% necessary in a Badgeware are the folder, icon and _init_.py as you’ve surmised. Inside _init_.py the one thing that’s necessary is the update() method, this will loop endlessly until you press the home button to go back to the menu. If you’re launching the app through thonny it will whine and whinge at you as there are things that get set up by the menu system that don’t get set up when you run the app directly.
This page of the docs is up to date, as are the ones regarding badge modes and the differences between badges, we’re going through and rewriting one by one.
We’re really not pushing Thonny as a way to edit and iterate code as it has several disagreements with the way the filesystem has been organised to prevent data corruption. It’s possible to do, but it’s very much preferred to put the badge into disk mode and go from there.
Since I use CircuitPython a lot, I am used to editing on my PC and then rsyncing everything to the disk of the Pico. But Thonny also supports direkt editing on the disk of the Pico, so if anyone is used to Thonny, they can keep it (as long as you use the disk-mode).
@BillyTPilgrim: while the menu-system seems nice, it does not fit every use case. Will there be a firmware-level interface (i.e. from your MicroPython fork) for the hardware without the menu-system? This would really be necessary unless you want all your users to port their programs to what you described above.
The only thing needed for an absolutely minimal setup is a main.py. The only thing you need in there is
from badgeware import run
and then you can start your own code with run(name_of_method). For example,
from badgeware import run
def hello():
screen.pen = color.white
screen.text("Hello!", 0, 0)
run(hello)
That’ll get you all of the fancy API stuff we’ve put in there for drawing etcetera, but without the menu and app ecosystem.
Code is on Github now, which gives some interesting insights:
- Badger uses SSD1680
- Tufty uses ST7789 with parallel interface (pio instead of spi)
- both support picovector
- both use POWMAN for “deep-sleep”
Still no schematic though. The last item will be something to investigate, since my experiments with POWMAN show that the the RP2350 can be driven down to something like 150µA, but this all depends on the electronics. E.g. I measured for the Pico2-Plus 260µA. Compare this to 37.5µA from the Inky-Frame…
What about old code, i.e. something that was running on a Tufty2040. Will it work, or does it have to be rewritten? Or code written for a Pico and a display-pack?
Thank you for that insight. I’ve got the Hello! on the TUFTY screen.
I’ve been saving directly to TUFTY from Thonny and then running via the Menu. This works for me.
What do you recommend as the editor if we do not use Thonny?
Whatever feels comfortable and natural to work in, to be honest. Personally, I’ve been using mostly VS Code to work on the apps, but I know a lot of people swear by text editors with syntax highlighting such as Sublime Text.
My head hurts, and I haven’t even got mine yet. :P
Initial thoughts after a day with a TUFTY2350
This is a wonderful piece of kit. Build quality is fantastic and the built-in software works wonderfully. The Alpha Centauri game is terrific – and I do not normally play games! I am impressed with what it can do.
I’ve played the games, explored the buttons and connected the sensors. Now I want to program it myself. I do not expect to be able to run before I can walk. I will need guidance with all these sprites and layers. I am happy to learn about them in the future, once the documentation is available, hopefully at a similar level to that provided by PicoGraphics. (I hope for and expect a better experience and support than I received after buying a 32BLIT – mine is one of those gathering dust and unused after initial playing sessions.)
The supplied apps are all far too complicated for many coders, whose top-level skills are graphics, buttons, sensors and WiFi applications on a PRESTO using MicroPython, to read through and understand enough to start building their own apps.
I realise that commercial interests force manufactures to push the hardware sales out the door before documentation is ready – they need to recoup the enormous funds spent on development, components and manufacturing. I remember bringing up the point that good documentation is an essential part of the deal hardware suppliers have with their customers at the first Raspberry Jam in Cambridge well over a decade ago – that was an exciting time!
What would be helpful while we wait for access to the full documentation.
What is needed is a VERY SIMPLE app – TESTING - that we can add to the menu and then modify and build on. (A bit like BLINK when you first met an Arduino UNO or a Pi Pico.)
My suggested specification – Which I am going to work towards now that I’ve got a working starting point with Billy T Pilgrim’s help – Thank you.
Setup section
Import any essential items like modules
Load a couple of these nice new fonts – does anything need to go in assets?
Set up any essential components like the screen and buttons
Define a few colours – RED, GREEN, BLUE, WHITE, BLACK.
Set up a counting variable – count.
Clear the screen to BLACK and display TESTING in RED on the screen for 2 seconds.
In the def update() loop
Clear the screen to BLUE.
Display the value of count in large YELLOW text near the centre of the screen and a smaller white version top-right.
Draw a GREEN rectangle near the bottom on the screen which expands to the right if the COUNT is positive – basic horizontal bar graph.
Reads the UP (+10) and DOWN (-10) buttons to control the value of count and the bar – cannot go negative or above 100.
Read the B button to terminate the program and return to the menu.
This should be a pretty simple app to write if you have used TUFTY to write its current apps and would provide new users, at PRESTO coding level, with an understandable starting point for their own journey of discovery with their new device.
As a starting point I will explain how I made a new T icon using GIMP – basic but it works!
Copy the icon from the Tennis app and paste in a safe place
Run the free to download GIMP program and open the icon.png file
View – Zoom 800%
Edit – Fill with BG colour WHITE
Select Pencil Tool
On the right select single pixel pencil type
Click on current foreground colour (BLACK) and change to RED – OK
Draw a Large ‘T’ in the centre of the icon
File – Export – iconT.png to a suitable safe place
Unclick all the crosses
Export it
Feedback from TUFTY2350 owners would be appreciated.
1 Like
Thanks for the review! Especially glad you like 30 minutes To Alpha Centauri, that’s one of mine :)
We’re working on throrough documentation as a priority. In the interim some simpler code examples on Tufty might include something like the Badge app - it’s mainly drawing things to the screen and doing some transformations to flip the card. I’ve also tried to thoroughly comment my code to explain at least what does what.
Regarding what you need in assets - fonts are stored in their own rom on the badge’s filesystem, so you don’t need them anywhere in your app. You can access them with
screen.font = rom_font.name_of_font
The assets folder is primarily for images, whether that’s standalone images or sprite sheets. You can see both in the examples. These should be PNGs - preferably converted to indexed colour to save memory and space, although that’s not compulsory. Hope that helps.
1 Like
For basic drawing controls, your most useful resource right now will be https://badgewa.re/docs/api/types/image.md and https://badgewa.re/docs/api/types/shape.md - they are both up to date with the final version of the API. Although these methods apply to all images, it’s worth noting that the screen itself is also an image, so you can apply them directly to the screen as is shown in the examples on that page.
1 Like
Thank you, These links are really helpful. I’m feeling much more confident I can now make some progress.
I found it impossible to display text in the init() section - no screen.update() instruction - so had to work around for a title screen.
Here is my first working code - pathetic really and took ages - but it does work.
from badgeware import run
import time
nope_font = rom_font.nope
compass_font = rom_font.compass
global value
value = 0
def update():
global value
if value == 0:
screen.pen = color.green
screen.clear()
screen.pen = color.yellow
screen.font = nope_font
screen.text("Tony's First App ",10,30)
screen.text("Value is: " + str(value),10,50)
value = 1
elif value == 1:
screen.text("Tony's First App ",10,30)
time.sleep(3)
value = 2
else:
screen.pen = color.navy
screen.clear()
screen.pen = color.white
screen.font = nope_font
screen.text("This is nope", 10, 10)
screen.pen = color.red
screen.font = compass_font
screen.text("This is compass", 10, 30)
screen.font = nope_font
screen.pen = color.green
screen.text("Value is: " + str(value),10,50)
Mmm, the thing with init() is that it goes straight into update(), which will of course redraw the screen every time it runs. So even if you were to draw something in init(), it would only appear for a single frame before being replaced by whatever was drawn in update().
A good way to do a title screen is using a state as you have there, but rather than sleep you can use io.ticks() to get the number of milliseconds since the badge was powered on. So in your startup code there, you could define, say,
title_screen = True
start_time = io.ticks
and then in update(),
global title_screen
if title_screen:
(stuff to draw your title screen)
if io.ticks - start_time >= 3000:
title_screen = False
else:
(stuff for your main program)
sleep() pauses all execution for the duration specified. That will freeze the program on a title screen, but what if you want to do something on that title screen, like animate something, or get button presses? It’s not ideal. In this example, it’s running around update() over and over and over again, each time checking whether it’s been three seconds since you started the program. As soon as it has, turn off the title_screen flag so the program will go into the next bit.
If you’ve just got two states for your program to be in, you can use a boolean as I have there, or if you’ve got more than two then you can use an integer as you did originally. You’ll see quite a few of our examples use a title screen state, a gameplay state and a game over state, which loop around from one to the next.
Incidentally, if it’s working code, it’s not pathetic. Could it be improved? Sure, but so can everything, it’s about getting something that works and then refining it. Gotta start somewhere, right?