Niezliczona ilośc błędów popełnianych przez programistów w takim kodzie każe mi dmuchać na zimne. Taki kod powinien podlegać weryfikacji formalnej a z drugiej strony "zbrickowanie" urządzeń to rzecz tak powszechna, że zastanawiam się kto w ogóle pisze te bootloadery, flashery itd itp. bo wyglądają jak prace zaliczeniowe kiepskich studentów.
Zastanawia mnie wobec tego ta kombinacja z flashowaniem z RAM.
Musicie skasować cały flash (wątpię)? Ma byćszybciej? Coś innego nie działa?
heby snipped-for-privacy@poczta.onet.pl> napisał(a):
I w sumie jako rozwiązanie podają std::atomic. Ciekawe czy atomic z C też może być.
Chodziło o to, że jak jest scheduler to zwykle też masz pod ręką semafory, kolejki itd.
Miałem właśnie na myśli MCU.
Ale cały czas mi chodzi o ten problem cache. Wiem dobrze, że volatile nie rozwiązuje zacytowanych wyżej problemów.
Zgadza się. Niemniej dlatego wspomniałem, że problem dotyczy MCU.
OK, tutaj zgoda.
Dzięki.
Ciekawe. Nie wiem jak w arm ale w mips setki tysięcy razy programowałem flash z kodu będącym w innej stronie niż strona programująca i nigdy nie miałem z tym problemu.
A co to za problem? Jak się przerwie programowanie z jakiekolwiek powodu to bootloader zaprogramuje ponownie po resecie. Jeśli urządzenie wymaga idiotycznego "nie wyłączaj urządzenia podczas aktualizacji" to nadaje się do kosza a "twórcom" należą się baty.
A co broni użyć C++, szczególnie na nowej arch? Nawet na AVR to zmiana 2 literek na dwa + w nazwie kompilatora i strata bodaj 4 bajtów na dodatkową sekcję, którą można łatwo usunąć, jak ktoś sępi. Więc na arch, gdzie atomic ma implementację, to powinno kosztować asymptotyczne zero.
Ich istnienie jest rozdzielne. Do tego stopnia, że trafiłem kiedyś na urządzenie o nazwie "Tiger" zawierajace "TigerBASIC", taki panel do kontroli automatyki, z wyświetlaczem graficznym. Gdzie rozdział poświęcony miltithread miał opis 1 funkcji tworzącej wątek i kończył się na "należy zwrócić uwagę na dostępie do zmiennych w innych wątkach". I wsio na temat synchronizacji.
A ja wskazuje, że granica między dużym systemem i uC/MCU zaciera się coraz szybciej. Mam przed sobą pdf dwurdzeniowego ARM za normalne $. Do migania diodą nadaje się tak samo jak AVR. Może nawet konsumuje mniej energii, nie zdzwiłbym się.
volatile źle rozwiązuje równiez "ten problem z cache" w sensie optymalizacji. Bo zabrania *zawsze* optymalizacji danej zmiennej,a nie tylko w miejscu, gdzie jest błędem logicznym.
MCU za chwile będą takie jak duże systemy. Duże systemy idą w szerokość (ilośc rdzeni) to samo czeka uC. Prawdę mówiąc bardzo mi szkoda, że Parallax Propeller nie dał rady stać się popularnym, to był bardzo interesujacy CPU do aplikacji real-time.
Czyli sporej częsci urządzeń wyświetlajacych ten komunikat. Ja bym zaczął od Windowsa. Co prawda to nie flash, ale w sumie co za różnica.
On 16.02.2023 13:20, Piotr Gałka wrote: [...]
Sugeruję jednak zapoznanie się ze skryptami linkera – zakładam, że używacie GNU toolchaina. W sieci jest mnóstwo przykładów jak odczytać adres początku danej sekcji, jej końca, jej długość i jak wyeksportować te dane do linkowanego programu.
Hint: Można sobie zdefiniować sekcję i umieścić w niej tylko jedną funkcję.
To podstawy:
A gdzie ma implementację? Bo na np. ARMv6-M (Cortex-M0 itp.) czy starą, ale nadal żywą ARMv4T (np. ARM7TDMI) nie ma – kompilator woła funkcje zewnętrzne
Na ARMv7-M jest lepiej, ale IMO nie idealnie:
Nie ma wyjątków.
Tak, bo to biedaarchitekura. To jest to miejsce, gdzie stosujesz sztuczki specyficzne dla danej arch. Tak samo jak na AVR i 8051 nie da się bez tego żyć.
Rzecz w tym, aby tych sztuczek nie traktować jako normy ogólnej.
Ale przybywa rdzeni, wiec samo volatile to raczej nie jest zastępnik.
jest ldrexd/strexd ... ktorych zdaje sie nie ma w armv7-M.
A dwa ldrex/strex nie bedą atomic.
J.
On 17.02.2023 09:18, heby wrote: [...]
Fakt, w tym kontekście ARMv6-M to biedaarchitektura [*], ale stara ARMv4T już nie – ma sprzętowe wsparcie dla synchronizacji w postaci instrukcji SWP, więc dla niej ten mój przykładowy kod mógłby wyglądać tak samo ładnie jak dla ARMv7-A. Gdyby było wsparcie ze strony kompilatora.
[*] Co nie przeszkodziło ludziom wyrzeźbić na tym RP2040 (serca Raspberry Pi Pico) – dwurdzeniowego MCU bez instrukcji wspierających synchronizację. :-) To trochę tak jak z tą szybką 51, z Bytomia zdaje się. :-)
Spokojnie czekać, RISC-V to zaora.
On 17.02.2023 09:30, J.F wrote: [...]
Wiem, że nie ma.
Nie będą, ale myślałem nad zrobieniem za pomocą LDREXB/STREXB i jednej komórki pamięci semafora chroniącego dodawanie. Ale po przemyśleniu doszedłem do wniosku, że w tym miejscu to słaby pomysł.
Moze wlasnie bardzo dobry, i tak kompilator zrobil ... w podprogramie.
J.
Czekaj, czekaj... Tam nie było jakiś spinlocków sprzętowych? Mam, ale jeszcze nie programowałem, więc niewiele wiem praktycznie, ale jakiś ochłap tam dali.
heby snipped-for-privacy@poczta.onet.pl> napisał(a):
Bo tak właściwie to ten komunikat wcale nie musi oznaczać, że coś wybuchnie jak wyłączysz nagle zasilanie. Windows nie psuje się od tego.
Więc co oznacza?
W dniu 2023-02-16 o 18:01, heby pisze:
Dotychczas stosowaliśmy procesory w których program działający z jednej strony flasha mógł bez przeszkód modyfikować inną stronę. A teraz musimy (bo tamte na razie zniknęły) przenieść się szybko na inne no i najpierw znaleźliśmy coś, co jest dostępne (EFM32PG22 i PG23) i kupiliśmy jakiś tam zapas, potem zaprojektowaliśmy urządzenia i w czasie gdy one 'się produkują' brat przygotowuje się do ich oprogramowani a ja projektuję już następne.
No i w czasie tego przygotowywania się natknął się na info, że: Jak się chce modyfikować flash to kawałek funkcji ma być wykonywany z RAMu. To co ma być w RAMie kompiluje się bratu do 10 czy 12 bajtów. Na zapas przekopiowywał do RAMu 40 bajtów, ale chciał to zrobić dokładnie, bo kto wie, czy kiedyś jakaś kolejna wersja kompilatora czegoś tam nie wrzuci i zrobi się ponad 40 bajtów. On jest na etapie, że kiedyś wszystko pisał wyłącznie w asm, a obecnie stara się wszystko napisać w C - że niby bardziej przenośne. Ale nie udało mu się znaleźć metody policzenia tego "sizeof(funkcja)" więc mówił mi dziś, że ten kawałek zostawi w asm aby nie mogło być żadnych niespodzianek.
Wydaje mi się, że już to wystarczająco wyjaśniałem, że to nie jest nasze widzimisię tylko w reference manualu napisali, że jak będziesz flashował z flasha to nie dają gwarancji, że coś się nie posypie. Z tym, że nie jest jasne co i jak często.
Gdzie indziej piszą, że jak programujesz flasha to wstrzymuje się dostęp do flasha. I tak było zawsze. Uruchamiasz programowanie z programu z flasha, potem masz pętlę czekającą na flagę, że już się zrobiło. Po uruchomieniu programowania twój program staje (bo nie ma dostępu do flasha). Jak się zaprogramuje to program idzie dalej i już przy pierwszym wykonaniu pętli sprawdzającej ma flagę, że się zrobiło. No i z tego fragmentu wynika, że tak to powinno zadziałać, ale gdzie indziej napisali, że jest ryzyko, że coś się nie uda i sam rozkaz programowania i pętla czekająca mają być w RAM. Tego się pewnie nie da sprawdzić, bo może jak zrobisz to z flasha to milion razy zadziała a za milion pierwszym coś się posypie. Skoro piszą, że tak trzeba to widocznie jest jakiś powód.
No i wyłącznie z tego powodu ta kombinacja z flashowaniem z RAM. P.G.
Możesz wskazać dokładnie ten pdf?
Nie twierdzę nic takiego, najzwyczajniej jestem ciekaw, co nowego z okolic kretynizmów, znowu wymyślono w uC aby utrudnić zycie programistom.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required