First, I love the Presto, it’s such a sleek design! I haven’t bought one yet, waiting for the final version.
One thing I am missing though is a way to mount a backplate. I think you should include a way to add screws to the backplate. Maybe a system like M2 slots use can work? So you have a little metal cylinder on the backplate that stands off a bit, that you can screw screws in?
Great little display, just a few suggestions for the production version.
Make the usb socket vertical (a lead sticking out the side spoils the looks and a stiff cable makes it a bit unstable).
Separate the two buttons a little.
You missed one IO pin (it must be lonely and unloved), maybe give it a button or led to look after.
Add a socket that connects to Vbus, Vbat and Gnd to make connecting a battery charger easier. (something for any device with a battery connector maybe)
I have one on order.
Looks good for development, but if I want to use it for some permanent use, such as a clock, or status display or home control console, it is going to need some kind of rear cover. This could be as simple as a piece of flat plastic or PCB like material on spacers.
Thinking ahead, I would really like a way to mount a daughter card that would be a custom application specific PCB, AND a rear cover or cover plate.
Unless I missed something, GPIO0 (pin 77 on the cpu) only appears to go to a test pad.
Maybe use it for the backlight_en or user_sw and bring out an analogue pin for Tonygo2.
For all the chargers I have seen on Pimoroni, the chargers appear drive the load AND charge the battery (ok if the load is small and cannot handle 5V), bringing out Vbus and Vbat would allow a charger to just charge the battery.
I’ve had my PRESTO for two weeks now and have used it a great deal. The only thing I miss is a spare IO pin. I find the buzzer the least attractive element and would like a link or cuttable trace to a solder pad so that I could make a choice between using the buzzer or an IO pin. There appears to be space for this in that corner of the board.
I don’t get it, Tony?!
I am thinking of the following scenario ever since you wrote about the on-board beeber…
There are 2 Qu/St connectors at the back and by a Qu/St to DuPont adapter you get the two pins out for tinkering with the physical port GPIOs.
Just don’t use them for I2C, but define them as regular GPIO ports and you can make use of whatever you want…also connecting your buzzer of choice…
I prioritise i2c over the very quiet buzzer. I already hang a qw/st pad and some sensors of the i2c port and do not want to give them up. I just would like at least one user available GPIO pin to use as I want. More useful than a too quiet buzzer.
…at least this request is which I fully support, as well.
I would even request more than just one GPIO pin, say up to 6 user defined pins, broken out on the rear as female socket bar + plus ofc Ground & Voltage pins 3,3 and 5 Volts (for various applications). Same as on the Pico Explorers’s front…just on the Presto’s back…
Hello, I’ve been trying out Presto and all the examples for a few days. It’s great what it can do.
I was able to translate the word clock into German, but now I’m stuck on the time zone. Adding the difference works, but it’s not optimal.
Unfortunately, I’m not a programmer and everything I’ve found so far about the time zone doesn’t work.
Does anyone have a tip on how I can tell Presto the right time zone?
…so what do you want instead? Unless you tell any device the deviation from standard time (GMT, UTC, etc.), the device would not know where you are…except you are giving some meaningful geo meta data to elaborate further on automatically…
So the point is, the device needs to know where it is (or YOU are) located. Then it can adjust the time according to the given timezone, which usually derives from the geo-coordinates… This can be either manually adjusted or automatically retrieved by some more information given, such as your location.
Apart from a moving object, this is in principle done by a timezone adjustment within the code.
However, if you need to be flexible, because - say - you are always moving between continents, you could derive the geolocation by the device’s IP address retrieved from the local network provider you are connected to. Then you could auto-adjust the geolocation and have the proper timezone adjustment calculated automatically…and -boom- time is set right…
I for one, believe this is too much over-engineering… ;)