I tested it with the brownian motion code you posted ealier, and realized it was outputting some timing information to serial. With the old ILI9488P display setting the range of values was about 168 - 181. (Lower numbers are better.) With the new ST7796SP display setting, the range of values was about 75 - 87. So it’s more than twice as fast using this new display type!
Turns out I didn’t need the numbers anyway, becasue the movement of the circles was obviously a lot faster.
I’m not sure there is a way to ensure it isn’t confusing?
I could just go back and rename the current release to RC27. But then people who watch TheBackShed and want the newest up to the minute releases will complain that the final release isn’t available or wonder what RC27 means since it has no matching release there.
Seems like adding “final” to it kind of implies stability/trust that isn’t really there. That’s something I’d consider doing one the actual, final, PicoCalc release for V6.00.02.
I figured it made more sense to match the naming convention of the main release so people knew what it was based on. But that doesn’t mean the PicoCalc portion of it is bug free or as good as it can be. This latest display update is a good example. This is something I’d want to put out there right now, but it also means multiple releases after V6.00.02.
The versioning on TheBackShed doesn’t seem to be tied to much of an actual release process anyway. V6.00.02 just happens to be when it finally stopped, so documentation could be updated, etc. New features were added into practically every RC leading up to that release, and that’s not usually what happens when something is preparing for release and is restricted to just minor changes and bug fixes so there’s ample time to test. The most recent display code and I2C fixes couldn’t have even been publicly tested at all by any users until after the release.
So it seems like the only thing the release version means on TheBackShed is that it matches the documentation (hopefully). I would expect most users would expect a major release to be more stable than other prior releases, but unfortunately I’m not sure that’s a safe assumption here. Also, given the interest in up to the minute bleeding edge releases, maybe that’s more the norm for this. And since the PicoCalc version is built on the shifting sands of the main version, the same issues apply.
And I have to wonder what will happen if Peter releases V6.00.03RC1 in a few days… (Kinda hoping he takes a break for a good long while though!) Should the PicoCalc version ignore those updates completely and focus on improving the quality of V6.00.02 on the PicoCalc, or do we go back to chasing the dragon again? Personally, I’d like to get things working better on the PicoCalc rather than pick up new experimental/undocumented features. While some progress has been made, we’ve never had a proper version for the PicoCalc that works as well as it could.
I’m really not sure what to call future releases though.
Dude, I wish I had some good advice for you other than a Vicodin prescription and a bottle of gin. Personally I don’t think there is anything wrong with using V6.00.02A or B or C to denote a revised “Stable” release. All it means is something important came up that needed to be done. No matter what you do people are going to get confused and complain, so just do what you think is best.
If you really want to annoy people, go with the Ubuntu versioning system and call V6.00.02, 25.06 and then give it a nick name just to add to the chaos.
As for chasing the dragons tail, do what you are comfortable with, this is a hobby, not a job. If that means we only get a Weekly or even Monthly “Testing” releases, then so be it. No ones life depends on getting up to the minute bleeding edge updates.
Yes here lies the problem maybe adding (my RC27) to the end might have helped… Thanks for the update anyway, yet your next one is more looked forward to.
Probably only refers to the built in controller not LCD physical dimensions and connector. I’d be interested in an upgrade for sure though, especially if touch too . If Clockwork offered an upgrade that’d be ideal…
When OPTION SERIAL is in the firmware itself, trying to disable it causes a soft reset the way it’s supposed to but the OPTION SERIAL in the firmware is still in effect. As long as it’s there, I can’t use COM2 for the serial console. The other versions of PicoMite allow you to disable it so you can use either COM1 or COM2 for the serial console. You can type in
OPTION SERIAL CONSOLE GP4,GP5,B
but the firmware won’t allow a change. Since the generic versions of PicoMite allow disabling it, I’d like to be able to do so as well. I’m not asking you to change it for everyone, I can compile my own version that does it.
I found out that if you only comment out the following line
Then trying to switch to COM2 GP4,GP5 won’t work. The pins stay at GP0 and GP1.
In order to disable it properly, I had to comment out these two lines as well:
No hardware change required. I’m just using the new ST7796SP display definition in PicoMite on the PicoCalc. I didn’t even realize it was compatible until picouser suggested it.
Pretty sure there have been other discussions on the forum about what display type the PicoCalc might actually have, and it seems like no one really knew for sure. Sounds like some kind of murky generic display of which there are lots of variations.
Something else I realized is that my naming convention is kind of bad in general. I probably should have included “PicoCalc” in the filename somewhere, because chances are some owners might have other PictoMite capable devices. So it’s good this discussion came up.
Maybe this is an opportunity to improve it, and also clarify how things line up to the main release:
PicoMite_PICORP2350_V6.00.02_PicoCalc_RC1.uf2
PicoMite_PICO_V6.00.02_PicoCalc_RC1.uf2
WebMite_WEBRP2350_V6.00.02_PicoCalc_RC1.uf2
And then for the last of the series:
xxxx_xxxxx_V6.00.02_PicoCalc_Final.uf2
The name is already ridiculously long, so I guess it doesn’t hurt much to make it longer.
Then post V6.00.02 I can see about shortening it. The PICORP2350,PICO,WEBRP2350 stuff was just taken from the makefile platform definitions, but that could be reduced to just 2040 for Pico and 2350 for Pico2. Not sure much else could be dropped though, as it’s all kind of necessary information to know what the file is. It would be simpler if Peter drops support in future for the Pico (2040) as it seems like was being discussed, even if that would throw a wrench into what ships with the PicoCalc (which always seemed like a strange choice anyway since the cost difference between the Pico and Pico 2 is minimal and the Pico2 is a seemingly better chip!)
I’ve kinda felt like the hardcoding in FileIO.c is a bit of a mess anyway, though it was an easy way to set things up for the official PicoCalc build. It seems like the correct way to do it would be to base things around the OPTION PLATFORM "PicoCalc" command.
I’ll need to see if this can work, but it might be possible to just rip out all the hardcoded stuff in FileIO.c and only leave the strcpy((char *)Option.platform,"PicoCalc");. Everything else could be defined in MM_Misc.c (as it is now, though it’s not currently necessary) and based on that platform value. The other critical thing is that there would need to be a way to query the existing Option.platform value stored in flash at that point when it gets set in FileIO.c. If the flash doesn’t have a value stored for it, then it should be set to “PicoCalc”, but if it already has a different value, then it should be left alone. Otherwise, any change you make would get reset on the next boot when the device forced itself to be a “PicoCalc” again.
Assuming that check can be made, then it would be possible to do something like OPTION PLATFORM "PicoCalcCustom" (or whatever new name you wanted to give it) from the console. After restart, it should no longer overwrite the options values with the hardcoded PicoCalc values, and any changes you make should remain. Nuking the flash and starting from the original PicoCalc version would mean you’d have the working defaults, but could still change them. But of course some weird user defined options could mean that stuff would break. If that happened a clean reflash could still set things right because it would start up as the “PicoCalc” platform again, with all those working defaults.
All of this is just a theory, but I think it might work. And it would also probably be a better way to “patch” the PicoMite code to support the unique PicoCalc requirements. I’ll look into this.
It would be good if some folks wanted to try out some display focused MMBasic programs with it to see how well the display works, and how it compares to the old version. From what I could tell it seemed to be working fine, and things were noticably faster. Might be a good time to experiment with porting over some existing animations and games over from existing PicoMite projects.
No other changes in this release aside from the display driver. (Literally it was just changing the display driver to use in a couple of places). But I figured since the rest of the release was stable it would be a good way to test this, before I go messing around in other areas to deal with some things.
Hmm. I wonder if the speed increase only happens with the use of FRAMEBUFFER and/or SPRITE?
This sample ran much faster with the new driver:
But maybe it’s the exception instead of the rule!
I’ve been playing around with adapting some of the demos here, and they seem ok, but they don’t feel nearly as fast. I haven’t tried them with the previous release yet to see how they compare.
Thanks for the great work. My programmes are running well. The first thing I do is use the Internet to set the CPU’s RTC at startup. My programmes run smoothly and without errors.
. If Clockwork offered an upgrade that’d be ideal…
