Pico2 (RP2350 no wifi)
Update. Using headphones mp3’s play fine, definitely stereo and equal volume on both sides.
Play tone 1,2000,5000:pause 5000 a click in right earpiece.
Play tone 2000,1,5000:pause 5000 a tone in left earpiece.
48Khz Test mp3… female voice centre then left then right. WORKS FINE BOTH FROM SPEAKERS AND HEADPHONES. Work that one out lol…
Have you tried
OPTION DISK SAVE "B:yourfilename"
I tried that and it works just as I need. I’m still learning so thanks for pointing it out!
There’s a small change in version 06.00.03 that affects the CHAIN command. The change involves Commands.c and can be seen here:
UKTailwind/PicoMiteAllVersions
I just synced the PicoCalc repo, but won’t be doing a build right away (maybe later this weekend).
I’m not going to try to chase after Peter’s updates with new builds like I did for 6.00.02. This latest change didn’t even get a different version number for the offiical release, so I’m not even sure how I should handle that. I’m assuming the official version just deleted the first release with that name and replaced it with this one. I wonder how many times that will happen?
But I will try to keep the PicoCalc fork synced in case others want to try to live on the bleeding edge and want to build the latest. 
In the earlier releases I actually did release a .bin file for the PICO builds. When there was only one SD_Boot bootloader, they might have worked with it. But I’m not sure if they had the flash locations changed properly to match, since that info changed a few times. Then things got complicated when the bootloader changed, and now there’s an even better bootloader in the works that doesn’t need to use .bin files at all but can load .uf2 files directly. Sounds like it is already working for the PICO, but the PICO2 support is still a work in progress.
I haven’t been using the PICO module in my PicoCalc and have been using a PICO2W. So I don’t really have a way to test the PICO builds, and with the fragile nature of the screen, I’d rather not swap out modules constantly, even though I taped down my replacement screen to lessen the chance it would break.
Once the new bootloader is available and working for both PICO and PICO2, there won’t be a need to use separate .bin files at all. So I was planning to just wait it out and not even bother with the old .bin method that will eventually be going away.
Looking at the code there appears to be a cutoff for the left channel of 10Hz. This seems to be something to do with rounding the duration to a complete number of waveforms. Why not use PLAY VOLUME to shut off one or other channels or just use 10 instead of 1?
if(PlayDuration != 0xffffffffffffffff && f_left >=10.0){
hw=((float)PWM_FREQ/(float)f_left); //number of interrupts per cycle
duration = duration * (float)PWM_FREQ; // number of interrupts for the requested waveform
// This should now be an exact multiple of the number per waveform
PlayDuration=(((uint64_t)(duration/hw))*hw);
}
Interesting, I’ll have a play…
UPDATE
Still bust, can’t see how this isn’t a software problem and I’ve noticed it in all builds.
Irrespective of ‘play volume’ the right channel just clicks if the tone on the left side is somewhere less than 100 !?.
Though it probably didn’t need to be confirmed, I just tested with:
play tone 10,2000,5000:pause 5000
play tone 2000,10,5000:pause 5000
and it works as expected for both right and left, using the speaker, and also using the headphones.
I also found it difficult to tell which speaker is being used on the actual device this way, but that’s just a question of how poor the sound quality is on the device speakers. Stereo sound should sound better on the speakers than mono, but trying to tell which single speaker is active is a bit tricky, for me at least.
@DigitalDreams, if this is something that may need be fixed, I’d recommend posting it as a bug/question on TheBackShed. Peter probably has a reason for the way it is (like picouser’s suggestion about rounding to the complete number of waveforms), and since this is how it’s done on all PicoMite builds, I don’t want to change it for the PicoCalc build since it isn’t a specific quirk of the PicoCalc hardware and is instead a “design decision” (or bug?) for PicoMite.
Doubt that, my left and right channels don’t behave the same !. I work around it by keeping the left at or above 100 and now using volume 0 too. Maybe it’s a weird issue with my Pico2 as yours works fine, will try another when the case is next open…
When I tried your code, I got the same results, with only a “click” on the right, whether it was via headphones or speaker.
It was only when I used 10 instead of 1 that both the left and the right worked fine, and I experienced no clicks. Since the tone sounded identical to me, and since @picouser pointed out the relevant code that ignores values below 10, that seemed like a good workaround beyond getting the source changed in the main release. PicoMite just doesn’t support values below 10 on the left, for whatever reason. That was why I suggested asking about it on TheBackShed, since it might reveal the reason, though I wouldn’t be surprised if Peter just ignored the question as well, based on my experience there.
I also felt the bootloader situation was complicated at this point so it’s nice to see someone with much more experience using the PicoCalc say that.
Thanks for responding!
It’s why I’m putting effort into streamlining it - it really needs to be a “just works” thing that doesn’t require constant jumping through moving hoops to use.
I seem to have a unique problem. When I switch on, PicoMite boots up Ok. However the first Basic program I run causes an error “invalid address” message which momentarily appears and disappears (twice), and I get the switch on click, then just the “>” prompt. I can then quite happily run anything after that, it’s just the first program.
I can even switch on and type in any command, “files”, “chdir”, “list”, “edit”, “print 5+5” and it works fine. But if I then run the program in flash, or load a program, then run it, BANG! it crashes again. Then it is happy from then on.
This all began a week ago after I undated the keyboard firmware and upgraded to PicoMite V6.00.02". Today I just upgraded to V6.00.03 hoping it would go away, but it didn’t.
Any ideas?
Reflash the keyboard ?. Also did you nuke the Pico core flash before installing the firmware ?. I always have issues getting ‘autorun on, autorun 1’ to work after flashing a core, takes a few jabs before springing into action on boot (fine every time after that).
https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html#resetting-flash-memory
So I used that flash_nuke.uf2 and then reloaded the PicoMite and it still fails.
I’ll try redoing the keyboard tomorrow and see how I go.
Thanks for the advice.
Well I did the keyboard firmware update again today, updating with “PicoCalc_BIOS_v1.2.bin” and using STM32CubeProgrammer in Win11. The update worked smoothly, but the problem still exists sadly.
Very strange !, maybe a core issue. Do you have any others to try ?. I’d reccomend a Pico2 for more memory and higher possible overclock etc… Be VERY carefull swapping modules, hopefully screen taped down but beware circuit board moving and stressing the display cable plus dont put pressure on board as can crack display below. I use a rubber plier handle gently akternating both sides - and have modded the case screws so centre two stay in and keep board in place.
In the early days some reported issues with bad solder joints on the stm32 (keyboard controller) yet would expect different symptoms to yours…
@adcockm Would it be possible to get a build with v2.2.0 of the Pico SDK?
