eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaC++ ośla łączkaRe: C++ ośla łączka
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.213.192.88.68!
    not-for-mail
    From: Piotr Gałka <p...@c...pl>
    Newsgroups: pl.misc.elektronika
    Subject: Re: C++ ośla łączka
    Date: Wed, 22 Feb 2023 13:45:57 +0100
    Organization: news.chmurka.net
    Message-ID: <tt52q2$47n$1$PiotrGalka@news.chmurka.net>
    References: <trelrs$g0p$1$Janusz@news.chmurka.net>
    <trgbkf$st9$1$PiotrGalka@news.chmurka.net>
    <63dbd22e$0$9601$65785112@news.neostrada.pl>
    <ts6rps$roo$1$PiotrGalka@news.chmurka.net>
    <63e9f424$0$19625$65785112@news.neostrada.pl>
    <tsg6eb$96a$1$PiotrGalka@news.chmurka.net> <tsgv8m$2kn8s$1@dont-email.me>
    <tsiqth$55n$1$PiotrGalka@news.chmurka.net> <tsj9if$2v62r$1@dont-email.me>
    <tsl72n$lpl$1$PiotrGalka@news.chmurka.net> <tsl934$38gns$2@dont-email.me>
    <a...@n...neostrada.pl>
    <tsole7$tii$1$PiotrGalka@news.chmurka.net> <tsp0q3$3ocgr$1@dont-email.me>
    <tt507n$2s4$1$PiotrGalka@news.chmurka.net> <tt5132$1gkap$1@dont-email.me>
    NNTP-Posting-Host: 213.192.88.68
    Mime-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed
    Content-Transfer-Encoding: 8bit
    Injection-Date: Wed, 22 Feb 2023 12:45:54 +0000 (UTC)
    Injection-Info: news.chmurka.net; posting-account="PiotrGalka";
    posting-host="213.192.88.68"; logging-data="4343";
    mail-complaints-to="abuse-news.(at).chmurka.net"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.8.0
    In-Reply-To: <tt5132$1gkap$1@dont-email.me>
    Content-Language: en-US, pl
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:778526
    [ ukryj nagłówki ]

    W dniu 2023-02-22 o 13:16, heby pisze:
    > 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.

    Jak EPROM jest zastąpiony emulatorem to EPROMu jako takiego nie ma - nie
    może być jego wina.

    >
    >> 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ć.

    Od samego początku o tym jest rozmowa.
    Ktoś napisał (nie chce mi się sprawdzać kto), że można się nie
    przejmować tym, że programowanie zostanie nagle przerwane.
    A ja po prostu uważam, że jak rozpocznie się programowanie strony flasha
    to należy zapewnić zasilanie aż do jego dokończenia bo uważam, że po
    takim nie dokończonym programowaniu może powstać sytuacja w której crc
    czasem pokaże że jest ok, mimo, że nie zawsze odczyt daje te same dane.

    >
    >>> 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.

    Może źle zrozumiałem wypowiedź "A co to za problem..." jako sugerującą,
    że zapewnienie zasilania flasha na czas programowania nie jest niezbędne.
    P.G.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: