 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : CMM2: Is it fundamentally flawed for developers?
Page 1 of 2   |
|||||
| Author | Message | ||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi folks, I've raised this before as an addendum on another thread but don't feel I received an answer that assuages my concerns. Can someone please explain to me how the design of the CMM2 file/flash system does not fatally flaw it as a machine to develop software on? My understanding is that each time you RUN then unless it is exactly the same program as the previous run it is processed/tokenised and written to the flash on the microcontroller which has a minimum endurance of 10,000 writes … a limit I expect to hit in less than a year. Typically when developing I will make some code changes and then run the program and potentially a suite of unit tests/programs, so that could be 10+ flash writes per change. I could easily make 10 such changes (frequently many more) in an evening, twice a week, 50 weeks a year. 10 * 10 * 2 * 50 = 10,000 I'm hoping that either actual flash endurance is typically 10-100x the quoted minimum, or that I have fundamentally misunderstood something about flash endurance. If not then it looks like Waveshare modules are a "consumable" for the CMM2 and that any potential developer who bought an all-in-one unit is out of luck. Please tell me I am wrong, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3378 |
"Fundamentally flawed" is pretty strong language. Even if in your case or a very few others it's necessary to replace the waveshare or all-in-one device, $30 or $100 is nothing for a business, and if you think it's a lot for a hobby, you might look at the cost for golf, or fly fishing, or scuba diving, or going out to dinner or taking in a professional sports game. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| abraxas Regular Member  Joined: 16/06/2020 Location: CanadaPosts: 99 |
Usually flash controllers have built in flash leveling that ensures that each block is written to with the same frequency. So the longevity would be 10000 full capacity writes. Now this is with the assumption that the flash memory in the Waveshare board actually implements flash leveling. No idea if it does or not, also, how much storage are we talking about there? |
||||
| GregZone Senior Member  Joined: 22/05/2020 Location: New ZealandPosts: 114 |
Interesting observation. I wonder how the 10K min endurance of the STM internal FLASH compares to the endurance of the NAND FLASH storage in my PC? Unfortunately Samsung appear to rate their SSD endurance based on TBW (TBW: Terabytes Written). Which seems a rather vague meassure to assess. Even so, you'd hope that the average hobbiest developer would get well more than a year out of their CMM2. If anything, your observation just suggests that the Waveshare module based CMM2 PCB's might actually be the the preferred option!  At least then you are only up for a $30 replacement CPU module, when the internal FLASH goes bad. On the SMD PCB version, unless you are skilled at LQFP SMD rework, you'd need to trash the whole board and replace it.  Kinda glad I went with the Waveshare version. |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I agree, but it might prove to be an excellent way to provoke a robust defence of the design and explanation as to why given the CMM2 has plenty of RAM there is this potentially problematic write to flash element. I was also deliberately careful to append the "for developers" proviso as I realise the limitation (if it is not simply in my mind) is unlikely to prove relevant to "normal" usage. I again agree, but that doesn't mean I don't want to "know" as my usual expectation of a hardware device with no moving parts is that it doesn't wear out … I acknowledge I may simply have never used a USB key or SD card long enough to observe the phenomena. Regards, Tom Edited 2020-07-20 08:49 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| GregZone Senior Member Joined: 22/05/2020 Location: New ZealandPosts: 114 |
I don't believe this would be the case. FLASH Leveling would be an application level function of managing storage allocation. In the STM32H743 (as I imagine with any other FLASH embedded microcontroller), the FLASH is simply raw memory, mapped into the core's memory address map. I do see that the STM32H743 implements ECC protection (10 ECC bits per 256-bit FLASH word). So at the very least, as long as the CMM2 firmware is checking the non-recoverable 2 error ECC error flag (DBECCERR1/2?), then at least we'll all be alerted to the issue, instead of just having random CMM2 behaviour!  nb. Details of the STM32H743 FLASH memory operation appear to be well covered in the RM0433 Reference Manual. |
||||
| mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261 |
And usually that write limit of 10,000 is PER CELL... As stated the wear leveling routines in the chip ensure that when you perform a save, it puts it to a different cell. So as long as you don't have a fairly full card it should have plenty of locations where to perform the write. Even so, 1) back up your card regularly (to any other location) 2) cards are friggin cheap, especially since it's not like software for this thing takes up much space at all.. |
||||
| GregZone Senior Member Joined: 22/05/2020 Location: New ZealandPosts: 114 |
I think might be confusing the internal FLASH program memory endurance concern, with the SD card? I don't believe you will find any FLASH wear limiting routines in the STM32, unless the CMM2 firmware implements some FLASH program memory allocation balancing routines? (which I doubt would be the case) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Please do not take this the wrong way, but your approach to development appears somewhat idiosyncratic. No-one else has made such an issue of running one program from another something which inevitably increases flash wear and certainly not 10 different programs for each development cycle. This approach conflicts to some extent with the design concept of the CMM2. HOWEVER, if flash wear ever becomes an issue then I can easily compile a minimum of of 4 and up to 8 different binaries to use different areas of flash. This could even be included as an automatic capability in the firmware in some future release. Edited 2020-07-20 18:26 by matherp |
||||
Poppy Guru Joined: 25/07/2019 Location: GermanyPosts: 486 |
FLASH ... He´ll save everyone of us! Sorry, it just had to be!  But seriously, how long can a complex game be played before roughly any signs or wear get obvious? Hundreds, Thousands, Millions? I know this issue is about generally more stressful developing, but is any kind of just using the machine at any risk of reaching such higher grades of wearing out?  Andre ... such a GURU? | ||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi Peter, Thanks for taking the time to respond. Please don't worry about that ... this is the Internet you need a thick skin  I don't believe so. Is it possible that your development experience (and that of the majority on this forum) is outside of large scale (shrink-wrap) "software application" development using Test Driven Development and other Agile methods? Note that I'm not saying that these methods are any better, and I don't think this forum is the place to argue about them, and if anyone does want to argue can they please do it in a different thread Typically in my day job I might change a few lines of code and then run a test-suite that executes 10's of processes and I could do this 100's of times a day (So I was actually underestimating the number of times I might expect to hit the flash). A pattern that I acknowledge is only possible because computers have got so fast that using the computer to locate bugs is more efficient than applying brainpower to manually check the code multiple times. To be honest I'm wondering when I can expect to see failures on the large SSD in my development machine, but of course these do have wear levelling and error correction. I believe I have indicated in previous conversations (related to requirements for the CMM2 "operating system") that the design concept and reality may diverge because you have applied concepts that were originally intended for a 1MHz processor and 64K of memory to a 400MHz processor and 5M of memory. By providing the additional power you make the CMM2 open to larger more complicated applications the development of which may benefit from some of the more recent (and again I don't argue as to the efficacy) software development methodologies. That would be great. But why is it using the onboard flash in the first place instead of running the program from RAM ? I don't suppose a flash write counter could be built into the firmware along with a method to query it? That would allow the gathering of experimental evidence to give some indication of the potential scale of any issue. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Potentially infinitely provided you play the same game again and again as that doesn't require the microcontroller flash to be rewritten. I don't think this is an issue for most users, just some developers and I guess applications that for example process a file frequently via the collaboration of multiple programs, a not unheard of design. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Yup, we're talking about a small quanity of flash integral to the microcontroller itself. You can't replace this without replacing the microcontroller and there is no issue with "backing it up" because its contents is always recreatable from contents on the SD card. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
It has been over six years since I introduced the Micromite (with a same flash endurance) and I have lost count of the number of times that someone has worried about the life of the flash. In all that time I have not heard of anyone, repeat anyone, who has hit that limit. The bottom line is that no one can ever realistically run/edit/run 10,000 times. You may calculate such a scenario but in practice you will never come anywhere near to reaching it. I am probably the best example, in developing MMBasic I have compiled/reflashed countless times over many years using the same poor old chip and it has never faltered. It might be possible to create a silly scenario where one can exceed this level (for example, where one program RUNs another ad infinitum) but given reasonable programming you will never, ever, come near to reaching this limit. Geoff Geoff Graham - http://geoffg.net |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi Geoff, I sincerely hope you are correct, however ... That conception is the crux of my point. I don't believe this is necessarily the pattern you can expect on the CMM2 because it is open to the development of larger programs that the previous 'mites and is "advertised" as a micro-computer, not a micro-controller. Use-case 1: If the program is spread over multiple .inc files then an "edit cycle" may touch multiple files between each "run", and if you don't remember to use f6 to close the editor then my understanding is each edit will rewrite the flash. Use-case 2: Unit-testing where each "edit cycle" may involve the execution of multiple test programs. I will have to train myself to only run the minimum unit-tests for the area I am working on instead of the whole suite. Use-case 3: An application which for example processes a newly arrived file every minute by running multiple programs on it in sequence ... that could easily hit 1000's of flash writes in a day. This is not an uncommon pattern on a more traditional computer but is obviously a bad idea on the CMM2 ... but not everyone who comes to the CMM2 may necessarily realise this. Regards, Tom Edited 2020-07-20 19:28 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
I may not be "agile" but sometimes I impress even myself Try this test version OPTION RAM - programs will save and run from RAM, programs are lost with power, reset, or option change, variable storage reduced by 512Kb OPTION FLASH (default) programs will save and run from flash, all functionality as before MM.INFO(PROGRAM) gives the address where the program is stored CMM2V1.5.zip Edited 2020-07-20 21:30 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I would say in this case you are "highly responsive"  I'm not going to have opportunity to try it today, but I've got tomorrow and wednesday off from work so I'll give it a thrash then. Should I expect performance to be different ? or is the reduction in variable storage the main downside ? Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Poppy Guru Joined: 25/07/2019 Location: GermanyPosts: 486 |
Not exclusively yourself! Tom could feel challenged now! Andre ... such a GURU? | ||||
| MauroXavier Guru Joined: 06/03/2016 Location: BrazilPosts: 303 |
I will test it as soon as possible! I'm using the CMM2 since December 2019 and I guess I have transpassed easily the 10000 flashes write cycle. Let's do the math... When I'm in a high development cycle, it's normal "run, change and run again" about 200 to 300 a day (Wolf3D is far beyond that). I believe that counting on that, I developed more than 50 days with a 300 cycle for a day, resulting in about 15000 cycles, but until now I hadn't any issues with my waveshare module on the CMM2 v1.4 board. Let's see if when running my programs on RAM if we have some changes. I appreciate it if we have success on this change on the CMM2 firmware enabling this choice, even if has a little performance lost. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
I have never developed/tested code so fast as I do with the micromite. My time is valued at way more than $30/hr. If even the MX170 cost $50, or more, it would still be a no-brainer for me. |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
