C++ ośla łączka

Fri Feb 17, 2023 7:45 am   

On Thu, 16 Feb 2023 19:57:58 +0100, heby <heby@poczta.onet.pl> wrote:

Nie ma wyjątków.

--
Marek

Fri Feb 17, 2023 10:18 am   

Fri Feb 17, 2023 10:30 am   

Fri Feb 17, 2023 11:17 am   

Fri Feb 17, 2023 11:28 am   

Fri Feb 17, 2023 11:41 am   

On 17.02.2023 09:30, J.F wrote:
[...]



komórki pamięci semafora chroniącego dodawanie. Ale po przemyśleniu
doszedłem do wniosku, że w tym miejscu to słaby pomysł.

Fri Feb 17, 2023 3:31 pm   

On Fri, 17 Feb 2023 10:41:48 +0100, JDX wrote:

Moze wlasnie bardzo dobry, i tak kompilator zrobil ... w podprogramie.

J.

Fri Feb 17, 2023 3:51 pm   

Fri Feb 17, 2023 5:21 pm   

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

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

Fri Feb 17, 2023 7:56 pm   

On 17/02/2023 16:21, Grzegorz Niemirowski wrote:

Więc co oznacza?

Fri Feb 17, 2023 9:20 pm   

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.

Fri Feb 17, 2023 9:23 pm   

On 17/02/2023 20:20, Piotr Gałka wrote:

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.

Fri Feb 17, 2023 9:30 pm   

W dniu 2023-02-16 o 19:22, Marek pisze:

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.

Fri Feb 17, 2023 9:42 pm   

On Fri, 17 Feb 2023 20:30:22 +0100, Piotr Gałka wrote:

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.

Fri Feb 17, 2023 9:44 pm   

W dniu 2023-02-16 o 19:27, Marek pisze:

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.