Why? Real hardware is dirt cheap.
Extensive testing purposes. It is rater a PITA for every single change to compile, upload, execute...
Actually, before any update it is recommended to wait few minutes in order to follow recommendation to retain even nearly 10 000 Erase/Write cycles in programming memory...
My development style must be different. Uploading was never the factor. With simulator you will spend a lot of time trying to create input stimulus.
And if you are debugging something that does not depend on inputs - debug it on PC first.
Recommended where? Actual flash endurance is way-way higher and there is absolutely no requirement to have any delays between writes.
No need for stimulus, what so ever. Anyway, good simulator will allow to prepare test cases...
With what software on linux? Atmel studio7 is available only for windows (probably will fail even to run through wine on linux), except I may en up with GCC AVR debugger Anyway, I do not need debugging, only speed testings.
IIRC, this was recommended in any 8-bit PICs datasheet
Have you ever tried to repeatedly flash an AVR? That is actually not bad idea to establish safety boundaries.
But it some cases it just makes the workflow much quicker
No need for stimulus, what so ever. Anyway, good simulator will allow to prepare test cases...
But it some cases it just makes the workflow much quickerExcept for the part where you try to figure out why your massive code base does not work on a real hardware.
There is a need if your program takes any inputs. I rally don't understand how it is possible to test anything using a fixed set of inputs.
I would actually need to see this for myself to believe. This makes no sense at all. Flash does not remember how long ago it was written.
Guys in Norway did unofficial tests long time - under a normal power supply and at room temperature it was more than 100 000. The write was performed from inside the device, since it would take forever to do that over the debugger.
Do you remember what rewriting frequency was?
And that is supposed for 100 000 E/W MCU? The ATmega 328p have specified only 10 000 E/W cycles endurance.
I doubt 328p would live much...
It's mostly the 'analog' part that goes wrong.
Proteus can simulating these things very well actually, but is not free
Why? There is no evidence that flash endurance is stretched in any way in those devices.
I can't comment that deeper, a I do not know exact hardware based self-programming process exactly.
However, with standard flashing with a programmer, you have to provide 13V, which is way too much than 5V,
Anyway, that may be total rubbish I wrote, as I already wrote, as I really don't know exactly how flashing process work under hood, a well as self-programming.
However, with standard flashing with a programmer, you have to provide 13V
It's mostly the 'analog' part that goes wrong.
Proteus can simulating these things very well actually, but is not freeIn the past I decided to never use Proteus for MCU simulation. Wasting hours finding why you get some weird issue just to find it is some sort of bug in MCU simulation, and it worked perfectly on real MCU to start with. Happened several times on different projects. This happened to the point where issue was not even related to peripherals. Last time it was doing calculations wrong, then I decided enough is enough.
Anyway, that may be total rubbish I wrote, as I already wrote, as I really don't know exactly how flashing process work under hood, a well as self-programming.Yes you don't. Programming is done with voltage generated by internal converter and is much higher than 5V.
All AVRs have internal charge-pump for that, and temperature does not increase that much. I mean maybe really old PICs were that bad, but definitely nothing designed in the last 10 years suffers from such problems.
as well repeating the same already previous poster explain - well done!
Hard to understand those posts were typed simultaneously?