logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Atmega128 - Bascom - jak sprawdzić zajętość pamięci flash z poziomu programu?

sundayman 21 Wrz 2015 17:21 1101 17
  • #1 15010624
    sundayman
    Poziom 26  
    Czy jest jakaś możliwość określenia z wnętrza programu - jaka jest zajętość flasha ?
    Tzn. na jakim adresie miejscu kończy się program ?

    Może jest jakiś wskażnik w Bascomie ?
  • #2 15010952
    Konto nie istnieje
    Poziom 1  
  • #3 15011380
    Konto nie istnieje
    Konto nie istnieje  
  • #4 15011778
    sundayman
    Poziom 26  
    Pięknie - ale nie doczytałeś ; chodzi o odczyt z WNĘTRZA programu.
    Czyli w czasie działania programu potrzebna mi ta informacja.

    Oczywiście - można na wpisać "na stałe", jednak przy dowolnej modyfikacji trzeba będzie zmieniać. Nie o to mi zatem chodzi.
    Rzecz w tym, żeby pisząc program nie trzeba było co chwila ręcznie sprawdzać jaki dana wersja ma rozmiar, wpisywać to ręcznie itp. tylko żeby odbywało się automatycznie.

    Ideałem byłoby, gdyby kompilator umieszczał gdzieś w kodzie tą wartość - może tak jest ?
  • #5 15018061
    Marico
    Poziom 20  
    Tak z ciekawości, po co ta informacja?
    Nie kojarzę bezpośredniej instrukcji Bascoma na to, ale możesz użyć CPEEK zwracajacej bajt pod danym adfresem flash. Uzyj ją w pętli zaczynając od najwyższego możliwego adresu aż do napotkania wartości różnej od 0xff.Adres pod którym będzie ta różna wartość od 0xff wstaw do wzoru: usedmem=totalmem-adres. Dostaniesz orientacyjną wartość użycia flash.
  • #6 15018103
    deksta84
    Poziom 24  
    Optymalizacja kodu wynikowego i Bascom? Nie rozumiem zasady działania Twojego programu. Czy ten kod sam się nadpisuje, zmieniając zajętość?
  • #7 15018105
    Marico
    Poziom 20  
    deksta84 napisał:
    Optymalizacja kodu wynikowego i Bascom?


    Dobre :-). A tak przy okazji Bascom to w ogóle kompilator czy raczej coś na kształt konsolidatora gotowych (napisanych w asm) instrukcji Bascoma,, do których są przekazywane tylko parametry?
  • #8 15021382
    sundayman
    Poziom 26  
    Chodzi o coś w rodzaju "sumy kontrolnej". Czyli - program na swoim początku robi sumę kontrolną zawartości pamięci programu i sprawdza czy jest taka jak należy. Oczywiście, ta suma jest różna po każdej zmianie programu.

    Teoretycznie, wystarczałoby robienie tej sumy kontrolnej na całej pamięci programu po prostu. Sprawa się jednak komplikuje, ponieważ - jeżeli "nowa" wersja programu jest krótsza od "starej", to w pamięci flash pozostają "śmieci", które fałszują poprawną sumę kontrolną.
    Jeżeli wersja nowsza jest większa niż stara - problem nie występuje oczywiście.

    A śmieci pozostają, ponieważ program jest ładowany przez bootloader, zatem pamięć programu nie jest kasowana podczas każdorazowego zapisu. I właśnie dlatego należałoby sprawdzać "prawdziwą" część zajętą przez aktualną wersję programu...

    Rzecz jasna - można pominąć cały problem, wyłączając sobie w programie na czas pisania to sprawdzanie. Chciałbym jednak, żeby nie było potrzeby dokonywania takiego zabiegu.

    Zauważyłem, że na końcu programu znajduje się string "bootloader" - zatem zrobiłem przeszukiwanie "od końca" flasha do tego stringu. Wydaje sie to działać poprawnie, no ale to bardziej po omacku działanie...
  • #9 15021639
    Marico
    Poziom 20  
    W takim razie po co te sumy kontrolne? Być może probujesz dorobić skomplikowane narzędzie do funkcjonalności, która w obliczu pewnych okolicznosci (których jeszcze nie znasz lub nie przewidziałeś) okaże się jednak niepraktyczna?
  • #10 15021728
    BlueDraco
    Specjalista - Mikrokontrolery
    żadne śmieci nie zostaną, bo Flash musi być skasowany przed zapisem nowej zawartości, a kasuje się sektorami, a nie po bajcie.
  • #11 15021781
    Marico
    Poziom 20  
    BlueDraco napisał:
    żadne śmieci nie zostaną, bo Flash musi być skasowany przed zapisem nowej zawartości, a kasuje się sektorami, a nie po bajcie.


    To zależy jakie są różnice w wielkości kodu, jeśli starszy był większy o jeden blok, to ten jego blok zostanie nietknięty.
  • #12 15021835
    tmf
    VIP Zasłużony dla elektroda
    Trochę OT, ale jest to kolejny przykład na dzielną walkę Bascomowców z problemami nieistniejącymi w normalnych językach. W każdym języku opartym o etap linkowania nie ma problemu aby dowiedzieć się, gdzie kończą się poszczególne elementy programu.
    Co do rozwiazania - oczywiście nie wiem jak to obejść w Bascomie, ale pomysł typu liczyć CRC z całego FLASHa nie jest taki prosty. Bo w tym FLASH trzeba umieścić CRC, który to CRC zmieni zawartość FLASH i tak w kółko. Czyli co najmniej jest wymagana możliwość umieszczenia CRC we FLASH w znanej lokacji i jej pominięcie przy liczeniu CRC, tudzież liczenie jej na końcu/początku, dzięki właściwości CRC, że CRC z CRC daje 0 lub -1 w zależności od konkretnej implementacji.
  • #13 15022418
    sundayman
    Poziom 26  
    Marico ma rację - jednak zostają śmieci, oczywiście zgodnie z tym co napisał...

    Cytat:
    w tym FLASH trzeba umieścić CRC, który to CRC zmieni zawartość FLASH


    To jest akurat stosunkowo proste - wartość CRC jest zapisana jako string, poprzedzony odpowiednim prefixem. Wystarczy go odszukać w pamięci i pominąć podczas liczenia CRC.

    Faktem jest natomiast, że jest to wyciąganie Bascoma za uszy, no ale taki jest ten przypadek i na razie nie bardzo można to zmienić.
    Znaczy jest w planie całkiem nowa wersja, którą już w C trzeba zrobić, no ale - to trzeba zrobić, a czas nie jest z gumy. A program zajmuje całą ATMEGĘ 128...


    Cytat:
    po co te sumy kontrolne? Być może probujesz dorobić skomplikowane narzędzie do funkcjonalności, która w obliczu pewnych okolicznosci (których jeszcze nie znasz lub nie przewidziałeś) okaże się jednak niepraktyczna?


    Bez przesady, narzędzie jest dość proste. Pominąwszy wspomniany kłopot podczas zmian programu , kiedy nowsza wersja jest mniejsza niż stara, to sprawdza się to - bo przecież dla czego miałoby się nie sprawdzać.

    W normalnej praktyce nie ma to znaczenia, bo programowany jest czysty MCU i żadnych śmieci tam być nie może. A gdyby się pojawiły - to byłby to znak, że coś jest nie tak, i błąd CRC będzie całkiem pożądany.

    Natomiast dlaczego w ogóle coś takiego ? Ano dlatego, że procesor działa w warunkach niekorzystnych EMC , i musi być możliwe zabezpieczony przed niespodziankami właśnie.

    To CRC to tylko jeden z elementów, oprócz tego stosuję np. przechowywanie zmultiplikowanych danych, co pozwala na wyłapanie i ew. korekcję błędów.

    Do tego dochodzi okresowe inicjowanie zmiennych, parametrów portów, czy nawet okresowe restartowanie ( czasem można się z tym z spotkać np. w systemach alarmowych ).

    Nie pamiętam teraz dokładnie tytułów, ale jest nieco literatury traktującej o specyfice programowania dla trudnych środowisk EMC, i są tam również takie wskazówki.

    I rzeczywiście jest to pomocne i konieczne. Kiedyś też mi się wydawało, że zmiana zawartości flasha jest nieprawdopodobna. A jednak - to się zdarza.
    Mimo podejmowania wszelkich możliwych zabezpieczeń, ekranowania itp.

    Fakt, że aplikacja BASCOMowa jest w takim miejscu jest lekkim nieporozumieniem, ale cóż - błąd młodości :)
  • #14 15022805
    Marico
    Poziom 20  
    A co Ci da weryfikacja flash gdy w trudnych warunkach emc/promieniowania przestawiają się bity w RAM i to runtime?
  • #15 15023351
    sundayman
    Poziom 26  
    Bez przesady, promieniowania nie ma :)
    Chodzi o zakłócenia np. od pioruna czy linii zasilania itp.

    Miałem raz przypadek, że pobliski piorun (w odległości 100-200m) spowodował przestawienie jednego dosłownie rejestru w AVR. Dokładnie odpiął rezystory podciągające akurat na porcie, na którym były przyciski sterujące.

    Szczęśliwie, wejście w menu było zabezpieczone hasłem, więc nic się nie stało - natomiast było wiele prób nieskutecznego podania hasła :)
    Dziwnie to wyglądało - jak gdyby ktoś próbował się włamać do urządzenia.

    Oczywiście, nie da się zabezpieczyć na 100%, ale chodzi o to , żeby zminimalizować ryzyko jak się da.
  • #16 15023457
    Konto nie istnieje
    Konto nie istnieje  
  • #17 15023496
    tmf
    VIP Zasłużony dla elektroda
    @niveasoft Przykład na co? Wrzucienie CRC do kodu z C? Nie ma problemu, Oczywiście to nie robota dla kompilatora, ale dla narzędzi z toolchaina. Jak to zrobić jest w I wydaniu mojej książki "Język C dla....", częściowo w darmowych przykładach do pobrania z Helionu, sam tekst rozdziału może jest za darmo na google books. Dzięki obecności makefile można sobie proces budowania aplikacji dowolnie zautomatyzować, samo umieszczenie CRC w kodzie wynikowym wymaga użycia programu, który to CRC wyliczy, a następnie dopisze do wynikowego hexa - prościej byłoby z plikiem elf, ale z jakichś magicznych powodów ludzie ich nie używają i wolą się babrać z plikami, w których osobno jest FLASH, osobno EEPROM, a wartości fusebitów są przekazywane ustnie :)
    Czyli potrzebujemy narzędzie o nazwie srec, konkretnie srec_cat, które wyliczy CRC i umieści je w kodzie wynikowym.
  • #18 15023529
    Konto nie istnieje
    Konto nie istnieje  
REKLAMA