RTV forum PL | NewsGroups PL

C++ ośla łączka

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - C++ ośla łączka

Goto page Previous  1, 2, 3, 4, 5, 6  Next

Marek
Guest

Fri Feb 17, 2023 7:45 am   



On Thu, 16 Feb 2023 19:57:58 +0100, heby <heby@poczta.onet.pl> wrote:
Quote:
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.

Nie ma wyjątków.

--
Marek

heby
Guest

Fri Feb 17, 2023 10:18 am   





J.F
Guest

Fri Feb 17, 2023 10:30 am   





JDX
Guest

Fri Feb 17, 2023 11:17 am   





heby
Guest

Fri Feb 17, 2023 11:28 am   





JDX
Guest

Fri Feb 17, 2023 11:41 am   



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


Quote:
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ł.

J.F
Guest

Fri Feb 17, 2023 3:31 pm   



On Fri, 17 Feb 2023 10:41:48 +0100, JDX wrote:
Quote:
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.

heby
Guest

Fri Feb 17, 2023 3:51 pm   





Grzegorz Niemirowski
Guest

Fri Feb 17, 2023 5:21 pm   



heby <heby@poczta.onet.pl> napisał(a):
Quote:
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/

heby
Guest

Fri Feb 17, 2023 7:56 pm   



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

Piotr Gałka
Guest

Fri Feb 17, 2023 9:20 pm   



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

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


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

heby
Guest

Fri Feb 17, 2023 9:23 pm   



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

Możesz wskazać dokładnie ten pdf?

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

Piotr Gałka
Guest

Fri Feb 17, 2023 9:30 pm   



W dniu 2023-02-16 o 19:22, Marek pisze:
Quote:
On Thu, 16 Feb 2023 13:20:42 +0100, Piotr
Gałka<piotr.galka@cutthismicromade.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.

J.F
Guest

Fri Feb 17, 2023 9:42 pm   



On Fri, 17 Feb 2023 20:30:22 +0100, Piotr Gałka wrote:
Quote:
W dniu 2023-02-16 o 19:22, Marek pisze:
On Thu, 16 Feb 2023 13:20:42 +0100, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:
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.

1-ka moze zaskoczyc :-)


tu masz pomysl z druga funkcją - ale uprzedzam, ze kompilator z
linkerem moga je inaczej rozmieszczac
https://stackoverflow.com/questions/72089507/apm32-c-copy-execute-function-in-ram

Gdzies w raporcie linkera powinna byc dlugosc kodu funkcji.
Ale to troche niewygodne tak sprawdzac za kazdą kompilacją.
No moze nie za kazdą - po grubszej zmianie.

J.

Piotr Gałka
Guest

Fri Feb 17, 2023 9:44 pm   



W dniu 2023-02-16 o 19:27, Marek pisze:
Quote:
On Thu, 16 Feb 2023 13:54:54 +0100, heby <heby@poczta.onet.pl> wrote:
Było to omawiane w tym wątku. Ogólnie, jesli ma to związek z
programowaniem flasha, to boje się zapytać, czy jakoś się
zabezpieczacie prze utratą zasilania w trakcie.

A co to za problem? Jak się przerwie programowanie z jakiekolwiek powodu
to bootloader zaprogramuje ponownie po resecie.

Moim zdaniem zbyt optymistycznie do tego podchodzisz.
Jak flash będzie nie do końca zaprogramowany (bo zniknęło napięcie w
trakcie programowania) to może w większości przypadków dobrze się
odczytywać ale czasem źle. Taki błąd może być bardzo trudny do znalezienia.
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ć. Statystykę zebraliśmy programem czytającym w koło znaną
zawartość. Miałem wtedy tylko jednokanałowy, analogowy oscyloskop, który
sobie sam zrobiłem (pasmo 5MHz) - żadnej szansy wyłapania tego momentu.
To wszystko było jeszcze THT - się okazało, że jakiś kondensator trzeba
było bliżej nóg zasilających przenieść i problem zniknął.
P.G.

Goto page Previous  1, 2, 3, 4, 5, 6  Next

elektroda NewsGroups Forum Index - Elektronika Polska - C++ ośla łączka

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map