On 22/02/2023 13:02, Piotr Gałka wrote:
>>> Kiedyś w naszym emulatorze EPROMów mieliśmy taki błąd, że średnio
>>> statystycznie raz na 3 miliony odczytów jakiś jeden bit potrafił mu
>>> się przekłamać.
>> I jesteś pewny, że to statystycznie istotny przypadek?
> W przypadku emulatora EPROMów jak najbardziej - raz na 3s program idzie
> w maliny (51-ka z kwarcem 12MHz).

To wina w końcu emulatora czy epromu? Bo się pogubuiłem do czego to
dygresja.

> A czy ja twierdziłem, że to miało jakikolwiek związek z błędami
> programowania. To było na temat, że jak odczyt pamięci prawie zawsze
> jest OK, a czasem błędny to może być problem (a tak się chyba może
> zachować flash, gdy programowanie zostało przerwane wyłączeniem zasilania).

Ale na to jest CRC. Trochę z tym problemem "źle działajacych flash bo
przerwali programowanie w połowie" przesadzamy. ja rozumiem, że mogło
się coś zaprogramować marginalnie źle, ale to znaczy, że zapewne za
szybko zanikło zasilanie, zanim flash zakończył co miał zakończyć.

>> Urządzenie z update firmware musi być sensownie zaprojektowane aby
>> zaniki zasilania nie były możliwe w połowie programowania strony
> Mam wrażenie, że w tym miejscu już zapomniałeś, że cała dotychczasowa
> Twoja wypowiedź kwestionuje moje stwierdzenie uznające za zbyt
> optymistyczne podejście "A co to za problem? Jak się przerwie
> programowanie z jakiekolwiek powodu to bootloader....".

a) stosujac CRC zapewniasz sobie ochornę przed przerwanym w połowie
programowaniem. Rola programisty.
b) stosujac zasilanie flasha na ułamek sekundy dłużej niż cpu (z
solidnym wykrywaniem zaniku) zapewniasz sobie że to co się zdążyło
zaprogramować powinno być poprawne. Rola hardwareowca.

Jakei jeszcze problemy można mieć ze zwykłym update firmware, poza
zwykłym pechem promieniowania kosmicznego?