Give it a look, it’s fiendishly clever and offloads repetitive I/0 related tasks to eight whirling dervishes which will chew throu’ input data and churn out results to python or DMA across the USB to a host.You slow them up to do USB…
And people have written SVGA Drivers with it.
and there’s a second core….
In fact there are four but you choose between Arm Cortex M33 world and RISCV5 cores, which make it’s appeal very wide and supports you in the Qualcomm swallowing of Arduino.
I would have to say I’ve never used a Teensy.
Just wait for the A4 core over the current A2. The AtoD in PIO has issues.
This project started with an Arduino Pro Micro… but it needed a separate interface. It works great with the pressure sensor, but not with the membrane. Poor control, and condensation ends up inside the sensor.
Then I switched to the optical sensor with a reflective membrane.
With the Teensy, it works great; with the Pico, it has poor sensitivity and a nasty “tongue” effect. The problem is definitely in the firmware, because the mechanics are the same and work great.
Looks great, I like the engraving of BC-1. What happened between 2/25 and 3/1 - did you find and fix the firmware or accept the ‘poor sensitivity and nasty “tongue” effect’ or ?
I’ve improved the sketch using AI, but it still doesn’t work as well as the Teensy. Since I hate having boards with soldered wires on my desk, I’ve finished printing the case, but I’m not at all happy with the result so far.
I’m testing different pullup resistors (which made a difference in the Teensy), but I eliminated the trimmer, which would have been more convenient, but 2 cm of wire was enough to make it uncontrollable.
If anyone wants to take a look…
I used the “reverse printing” technique with my 3D printer. But it’s not a BC-1, but a BC-L (Breath Controller - Lanfranco).
That is indeed a point. If he had written the code himself, he might have some idea of its efficiency, but he points out a couple of times that he has no idea what the Pico version’s code is like.
“Vibe Code Rot” doesn’t only bring security issues, it also can definitely give you serious degradation of performance, as it only gives you the equivalent of an unsubtle junior dev with incredible confidence. So that’s also a possibility, for sure, but given the application here, I believe that it’s probably down to the much higher resolution he’s getting from the Teensy.
I went googling for a comparison between Teensy4 (I have several kicking around here, it’s not oshw but it’s a beautiful device) and Pico, and well, I found this, I don’t think anyone present is involved in the drama so dropping a link. Mr Torrone over at a famous Brooklyn electronics shop seems to be trying to alienate the entire world from his wife’s livelihood…
@jtode as I’ve always said, I’m a music lover and know practically nothing about programming. The little I’ve done with my head was dedicated to radio when I was practicing. So any advice, criticism, or help is gold to me. For two reasons: because my device can work better, and because if someone kindly sends me an improved sketch, as a good radio amateur, I don’t just upload it and use it, I also look at it first and always try to learn something new. I’ve pasted the sketch below, and if you’d like to take a look (For your curiosity and my pleasure), I’d be happy to. This is a device for personal use (I tried to sell the one with the Teensy, but I see that these items aren’t attracting interest, so I deleted the ad).
How much were you looking for for the Teensy one? I was planning to build one myself actually, and I’m about to sell a car and do our taxes, so I might be able to swing it.
edit: I’d have to see both sketches, the Teensy and the Pico, and I do wonder if those extra PIO features could help the Pico perform better, so a complete refactor could well be of benefit as well, if it reduces the price of the thing significantly.
I’m not a Teensy-or-die guy by any stretch, I’ve kinda decided I wanna use RISC-V as much as possible from here on out actually, and Pico has that option, so who knows.
There are a few small optimizations that can be applied but the biggest gain in throughput would be to process display and usb less frequently, e.g. on every 10th cycle, (offset so not processing in same cycle) and of course there is the 5ms delay in every loop.
@jtode, I’ve only made one controller with the Teensy, so I’m holding on to it… but if you want to improve the sketch, I can print the case for you, even though as a radio amateur, I’ve always believed in collaboration without any vested interests (Ham Spirit).
@riban (master of the Ham Spirit), thank you, but your observations sound like any other @wyleu comment to me… you’ll understand my discomfort.
No need to print for me, and also, as it happens I have 4.1s on hand, not 4.0, so I’ll have to modify your layout somewhat. But if you have your STL files, or even better would SCAD files, not sure what you used to design it, I would gratefully take those as a place to start.
I’m currently in the design stages of my next homebrew Zynthian, and I plan to wrangle all the IO through the 4.1, probably including a 1-2 octave keyboard as well; this would make an excellent addition. :>
Hi, I use Fusion360. Give me time to extract the STLs and I’ll send them to you without any problems. I’d also send you the .f3z file, but it contains a lot of objects (I have the free version of Fusion 360, so I put multiple objects in the same project to save space, which is limited).
