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

Piotr Gałka
Guest

Fri Feb 17, 2023 10:08 pm   





Piotr Gałka
Guest

Fri Feb 17, 2023 10:21 pm   



W dniu 2023-02-17 o 20:23, heby pisze:
Quote:
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?


Brat już wyszedł z pracy, a do poniedziałku zapomnę pytania.
Jeśli on teraz jest (99%) w PG22 to może to być tylko ten pdf:

https://www.silabs.com/documents/public/data-sheets/efm32pg22-datasheet.pdf

lub (bardziej prawdopodobne) ten:

https://www.silabs.com/documents/public/reference-manuals/efm32pg22-rm.pdf

Nie chce mi się szukać gdzie to jest bo ja tego drugiego nawet nie
przeglądałem. Brat mnie zawołał, podświetlił akapit na ekranie i chciał
usłyszeć jak ja to rozumiem.
P.G.

Piotr Gałka
Guest

Fri Feb 17, 2023 10:35 pm   



W dniu 2023-02-17 o 20:42, J.F pisze:
Quote:
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

Przesłałem mu ten link - zajrzy sobie w poniedziałek.
W tym poprzednim, który podałeś (jeśli czegoś nie pomieszałem) to brat
powiedział, że to właściwie o 51-ce, ale spodobała mu się tam metoda
uzyskania z kompilatora funkcji w assemblerze. Nie wiem czym to się
różni od tego co on normalnie stosuje, bo wiem, że zagląda jak coś się
kompiluje, ale widocznie czymś się różni.

W każdym razie na razie zdecydował, że wpisuje te parę bajtów w assemblerze.

Ja mam na głowie kilka szybkich projektów płytek. Na razie lista do
zrobienia 'na wczoraj' narasta szybciej niż się wygrzebuję z poprzednich.

Strasznie głupio projektować już kolejne płytki na nieznanym sobie
procesorze, gdy poprzednich nie mieliśmy jeszcze jak sprawdzić.
P.G.

Grzegorz Niemirowski
Guest

Fri Feb 17, 2023 11:09 pm   



heby <heby@poczta.onet.pl> napisał(a):
Quote:
Więc co oznacza?

Może być różnie, ale np. konieczność zaczynania procedury od początku. To
taki komunikat: daj mi skończyć ten update bo inaczej będziesz musiał
wszystko wyklikiwać od początku. Ewentualnie jeśli jak w Windowsie update
jest przy wyłączaniu: to zamykanie trwa dłużej niż zwykle ze względu na
aktualizację, więc wykaż się większą cierpliwością.

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

Grzegorz Niemirowski
Guest

Sat Feb 18, 2023 12:06 am   



Piotr Gałka <piotr.galka@cutthismicromade.pl> napisał(a):
Quote:
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.

Dlaczego chcecie sami kopiować tę funkcję? Czy skonfigurowanie odpowiedniej
sekcji w skrypcie linkera nie wchodzi w grę? Przykładowo funkcja do zapisu
Flash znadująca się w RAM-ie jest w bibliotekach ST:

__RAM_FUNC HAL_FLASHEx_HalfPageProgram(uint32_t Address, uint32_t* pBuffer);

Makro __RAM_FUNC zdefiniowane jest tak:

#define __RAM_FUNC HAL_StatusTypeDef __attribute__((section(".RamFunc")))

Czyli funkcja HAL_FLASHEx_HalfPageProgram jest oznaczona atrybutem
umieszczającym ją w sekcji .RamFunc. Ta z kolei w skrypcie linkera jest
umieszczana w sekcji .data:

.data :
{
. = ALIGN(4);
__data_init_start = LOADADDR(.data);
PROVIDE(__data_init_start = __data_init_start);
__data_start = .;
PROVIDE(__data_start = __data_start);

. = ALIGN(4);
*(.data .data.* .gnu.linkonce.d.* .RamFunc)

. = ALIGN(4);
__data_end = .;
PROVIDE(__data_end = __data_end);
} > ram AT > rom

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

heby
Guest

Sat Feb 18, 2023 12:58 am   



On 17/02/2023 20:44, Piotr Gałka wrote:
Quote:
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.

Jest bardzo łatwy. Przeciez nie zapomniałeś dodać sum kontrolnych a
porządne urządzenie zazwyczaj sprawdzi swoje sumy kontrolne na starcie.
Wiadomo, że nastapiło przerwanie programowania. Jedyny przypadek, kiedy
to nie zadziała to chyba programowanie tego samego wsadu ponownie.

Quote:
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? Mowa o tysiącach
źle napisanych procedur upgrade firmware pisanych przez kiepskich
programistów, a nie o przypadku jeden na miliony. Z resztą przy takiej
statystyce to może być najzwyczajniej pamięc flash z marginalnym bitem,
co wcale nie jest takie niemożliwe. Mogło go stuknąc nawet
promieniowanie jonizujące, przypadki nie są wykluczone, ale szacujemy
ryzyko i się nimi nie przejmujemy w typowych zastosowaniach.

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

I czy aby na pewno miało to związek z błedami programowania czy bardziej
z tym kondensatorem?

Z ciekawostek, to równoległe pamięci flash mogły się "gorzej"
programować, jesli impuls kasujący miał zła długość (nie pamiętam czy za
długi czy za krótki, to było wieki temu). Znalezione przypadkiem przez
kolegę który osiwiał przy jakimś systemie uC w latach 90. Tak że dam
wiarę, że coś może pójść nie tak. Tylko czy aby na pewno to problem z
firmware? Urządzenie z update firmware musi być sensownie zaprojektowane
aby zaniki zasilania nie były możliwe w połowie programowania strony i
to nie wydaje się jakoś super trudne do wymyślenia.

J.F
Guest

Sat Feb 18, 2023 10:11 am   



On Fri, 17 Feb 2023 16:21:13 +0100, Grzegorz Niemirowski wrote:
Quote:
heby <heby@poczta.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.

Nie radze próbować.
Zaden system plików nie lubi, jak mu wyłączyc nagle zasilanie,
SSD nie lubi potrójnie,
a i taka czesciowa aktualizacja może byc zgubna.

J.

JDX
Guest

Sun Feb 19, 2023 1:14 pm   





Marek
Guest

Sun Feb 19, 2023 1:29 pm   



On Fri, 17 Feb 2023 20:44:12 +0100, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:
Quote:
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.

Co to znaczy "nie do końca"? Z flash jest jak z ciążą, nie można być
w niej trochę. Jeśli crc całości (po wygraniu) się zgadza to nie
przewiduje się by to jeszcze poprawiać. Jeśli zostało przerwane to
flashuje się ponownie, ale to chyba oczywista oczywistość.

--
Marek

Zbych
Guest

Mon Feb 20, 2023 2:51 pm   



On 17.02.2023 20:42, J.F wrote:

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

Nie ma takiej potrzeby, wystarczy że wsadzisz funkcję do swojej własnej
sekcji (a ta sekcja może wylądować wewnątrz np. data), dodasz etykiety
na początku i końcu sekcji w skrypcie linkera.
Potem takie etykiety mogą być widoczne w kodzie C jako dowolna zmienna
extern, której adres można pobrać i z różnicy wyliczyć długość.

Grzegorz Niemirowski
Guest

Mon Feb 20, 2023 2:57 pm   



Zbych <zbych@somewhere.com> napisał(a):
Quote:
Nie ma takiej potrzeby, wystarczy że wsadzisz funkcję do swojej własnej
sekcji (a ta sekcja może wylądować wewnątrz np. data), dodasz etykiety na
początku i końcu sekcji w skrypcie linkera.
Potem takie etykiety mogą być widoczne w kodzie C jako dowolna zmienna
extern, której adres można pobrać i z różnicy wyliczyć długość.

Pozwolę sobie podlinkować przykład:
https://stackoverflow.com/questions/72089507/apm32-c-copy-execute-function-in-ram

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

Zbych
Guest

Mon Feb 20, 2023 3:05 pm   



On 20.02.2023 13:57, Grzegorz Niemirowski wrote:
Quote:
Zbych <zbych@somewhere.com> napisał(a):
Nie ma takiej potrzeby, wystarczy że wsadzisz funkcję do swojej
własnej sekcji (a ta sekcja może wylądować wewnątrz np. data), dodasz
etykiety na początku i końcu sekcji w skrypcie linkera.
Potem takie etykiety mogą być widoczne w kodzie C jako dowolna zmienna
extern, której adres można pobrać i z różnicy wyliczyć długość.

Pozwolę sobie podlinkować przykład:
https://stackoverflow.com/questions/72089507/apm32-c-copy-execute-function-in-ram

Nie podoba mi się w tym przykładzie poleganie na kolejności umieszczania
funkcji w pamięci (flash_function i flash_function_end).
Zdecydowanie lepiej wygląda to:
https://stackoverflow.com/questions/4156585/how-to-get-the-length-of-a-function-in-bytes

Piotr Gałka
Guest

Wed Feb 22, 2023 12:44 pm   



W dniu 2023-02-17 o 23:06, Grzegorz Niemirowski pisze:
Quote:
Piotr Gałka <piotr.galka@cutthismicromade.pl> napisał(a):
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.

Dlaczego chcecie sami kopiować tę funkcję? Czy skonfigurowanie
odpowiedniej sekcji w skrypcie linkera nie wchodzi w grę? Przykładowo
funkcja do zapisu Flash znadująca się w RAM-ie jest w bibliotekach ST:

W którejś wiadomości już pisałem, że mam takie, może nie całkiem
racjonalne podejrzenie, że wpisana do RAMu wartość po 20 latach może
ulec jakiemuś zakłóceniu i nie wróci sama do stanu prawidłowego a dana z
flasha jak kiedyś przy jednym odczycie zostanie zakłócona to można
liczyć, że przy kolejnym już się odczyta prawidłowo.
P.G.

Piotr Gałka
Guest

Wed Feb 22, 2023 2:02 pm   



W dniu 2023-02-17 o 23:58, heby pisze:
Quote:
On 17/02/2023 20:44, Piotr Gałka wrote:
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.

Jest bardzo łatwy. Przeciez nie zapomniałeś dodać sum kontrolnych a
porządne urządzenie zazwyczaj sprawdzi swoje sumy kontrolne na starcie.
Wiadomo, że nastapiło przerwanie programowania. Jedyny przypadek, kiedy
to nie zadziała to chyba programowanie tego samego wsadu ponownie.

Myślałem o tym jak pisałem, ale już nie chciało mi się rozwijać
szczegółów. W ramach praw Murphy'ego przyjmuję, że takie zniknięcie
napięcia zdarzy się wtedy, kiedy wywoła najwięcej problemów.
Jak to się zdarzy przy zapisywaniu ostatniej strony programu to wtedy
może być tak, że przy weryfikacji odczyta się dobrze więc program
zostanie uruchomiony, a potem czasem dobrze a czasem źle powodując
jakieś trudne do przewidzenia zachowania.

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

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

I czy aby na pewno miało to związek z błedami programowania czy bardziej
z tym kondensatorem?

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

Quote:
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....".
P.G.

heby
Guest

Wed Feb 22, 2023 2:16 pm   



On 22/02/2023 13:02, Piotr Gałka wrote:
Quote:
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.

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

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

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