On 17.02.2023 09:18, heby wrote:
[...]
> 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ć.
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ę. :-)

do góry

On 17/02/2023 10:17, JDX wrote:
> [*] 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.

do góry

On 17.02.2023 09:30, J.F wrote:
[...]
> jest ldrexd/strexd ... ktorych zdaje sie nie ma w armv7-M.
Wiem, że nie ma.

> A dwa ldrex/strex nie bedą atomic.
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ł.

do góry

On Fri, 17 Feb 2023 10:41:48 +0100, JDX wrote:
> On 17.02.2023 09:30, J.F wrote:
> [...]
>> jest ldrexd/strexd ... ktorych zdaje sie nie ma w armv7-M.
> Wiem, że nie ma.
>
>> A dwa ldrex/strex nie bedą atomic.
> 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.

do góry

On 17/02/2023 10:17, JDX wrote:
> [*] Co nie przeszkodziło ludziom wyrzeźbić na tym RP2040 (serca
> Raspberry Pi Pico) - dwurdzeniowego MCU bez instrukcji wspierających
> synchronizację. :-)

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.

do góry

heby <h...@p...onet.pl> napisał(a):
> 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.

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.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 17/02/2023 16:21, Grzegorz Niemirowski wrote:
>> 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.
> 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?

do góry

W dniu 2023-02-16 o 18:01, heby pisze:

>> Dotychczas nie zauważyliśmy problemu, którego źródłem byłoby
>> niedokończenie zapisu flasha.
>
> Zastanawia mnie wobec tego ta kombinacja z flashowaniem z RAM.

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.


> Musicie skasować cały flash (wątpię)? Ma byćszybciej? Coś innego nie
> działa?

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.

do góry

On 17/02/2023 20:20, Piotr Gałka wrote:
> Jak się chce modyfikować flash to kawałek funkcji ma być wykonywany z
> RAMu.

Możesz wskazać dokładnie ten pdf?

> to nie jest nasze
> widzimisię

Nie twierdzę nic takiego, najzwyczajniej jestem ciekaw, co nowego z
okolic kretynizmów, znowu wymyślono w uC aby utrudnić zycie programistom.

do góry

W dniu 2023-02-16 o 19:22, Marek pisze:
> On Thu, 16 Feb 2023 13:20:42 +0100, Piotr
> Gałka<p...@c...pl> wrote:
>> Tam było, że jak się coś robi z programowaniem flasha z wnętrza
>> programu to ogólnie nie ma gwarancji, że wszystko się uda. I to zdanie
>> było ogólne - czyli nawet jak ruszasz inną stronę niż jesteś to może
>> coś nie zadziałać. Nie napisali co dokładnie, ale skoro może coś się
>> nie udać to
>
> 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.
>

Z tego co brat mówi, to dotychczas w AtXmega (dawniej w Atmega)
dokładnie tak robił - programuje flash z kodu w innej stronie flasha.

Ale to na pewno nie jest tylko nasz wymysł. Brat znalazł wczoraj w necie
że jakiś gość w maju 2022 szukał dokładnie tego samego. Jacyś ludzie mu
coś tam podpowiadali, ale nie wynikało, czy już mu zadziałało, czy nie.
Wynikało za to, że jeszcze nie znalazł tej 1-ki bo podał gdzieś tam
nieparzysty adres tej funkcji, którą chce przenieść do RAM a w pliki map
był adres parzysty.
P.G.

do góry