Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Czy można "częściowo" zaprogramować/przeprogramowa

robin_pl 12 Aug 2009 15:56 1742 22
  • #1
    robin_pl
    Level 12  
    witam

    ostatnio zainteresowałem się rodziną Arduino i pochodnymi

    próbowałem szukać odpowiedzi w necie - ale nie bardzo wiem jakich słów kluczowych użyć a przez to otrzymane wyniki są mizerne :(

    co do "częściowości" programowania/przeprogramowania w/w układów - czy można zmienić kawałek kodu albo dodać/dograć nowy kod - najlepiej "w locie" ?
    - dodawanie kodu - coś na wzór Windowsowych bibliotek DLL/OCX
    - zmiana "w locie" - samomodyfikowalny kod

    czy może JEDYNĄ możliwością zmiany kodu jest tylko i wyłącznie CAŁKOWITE przeprogramowanie układu - JTAG'iem, ISP, bootloaderem ?

    dzięki za ew. odpowiedzi

    ps. czemu ciągle jak edytuję temat postu - wcina mi "ć ?" ?
    w podglądzie przed wysłaniem jest poprawnie ...
    Do you have a problem with Arduino? Ask question. Visit our forum Arduino.
  • #2
    maniek1818
    Level 22  
    Quote:
    próbowałem szukać odpowiedzi w necie - ale nie bardzo wiem jakich słów kluczowych użyć a przez to otrzymane wyniki są mizerne

    A jaki siedzi tam uC :?: ATmega8, więc przez ISP wrzucasz wsad, ale jaki w tym problem? To są przecież tylko kilka sekund.
  • #3
    robin_pl
    Level 12  
    maniek1818 wrote:
    Quote:
    próbowałem szukać odpowiedzi w necie - ale nie bardzo wiem jakich słów kluczowych użyć a przez to otrzymane wyniki są mizerne

    A jaki siedzi tam uC :?: ATmega8, więc przez ISP wrzucasz wsad, ale jaki w tym problem? To są przecież tylko kilka sekund.


    w Arduino siedzą ATmega168 a w najnowszych ATmega328 - jest jeszcze Arduino MEGA z ATmega1280 ;)

    tylko, że ja nie chcę przeprogramowywać "całego" uC - a tylko zmienić/dodać mu kod "w locie" ;)
  • Helpful post
    #4
    tmf
    Moderator of Microcontroller designs
    Tak, oba procesory mozesz "czesciowo" przeprogramowac. Zarowno poprzez ISP, jak i calkowicie programowo. Z tym, ze kod programu odpowiedzialny za zmiany FLASH musi znajdowac sie w specjalnym obszarze pamieci FLASH - bootloaderze. Jego adres i wielkosc ustawia sie fusebitami. Wlasciwie w tym obszarze musi byc tylko instrukcja SPM.
    Z drugiej strony po co ci to? Skad bedziesz pobieral kod programu? Wez pod uwage, ze ilosc zapisow do FLASH jest ograniczona wiec ciagle manglowanie kodem wczytywanym dynamicznie np. z zewnetrznej pamieci jest raczej nierealne.
  • #5
    robin_pl
    Level 12  
    tmf wrote:
    Tak, oba procesory mozesz "czesciowo" przeprogramowac. Zarowno poprzez ISP, jak i calkowicie programowo. Z tym, ze kod programu odpowiedzialny za zmiany FLASH musi znajdowac sie w specjalnym obszarze pamieci FLASH - bootloaderze. Jego adres i wielkosc ustawia sie fusebitami. Wlasciwie w tym obszarze musi byc tylko instrukcja SPM.


    to już coś :) a mógłbyś podać więcej szczegółów ?
    w ostateczności mogą być tylko słowa kluczowe ;) dalej sam już pomęcze wujka Google ;)
    no ale jakbyś podał jakieś linki to byłbym bardzo wdzięczny :)

    tmf wrote:
    Z drugiej strony po co ci to? Skad bedziesz pobieral kod programu? Wez pod uwage, ze ilosc zapisow do FLASH jest ograniczona wiec ciagle manglowanie kodem wczytywanym dynamicznie np. z zewnetrznej pamieci jest raczej nierealne.


    a to na razie tajemnica ;)
  • #6
    mirekk36
    Level 42  
    tmf wrote:
    Wez pod uwage, ze ilosc zapisow do FLASH jest ograniczona wiec ciagle manglowanie kodem wczytywanym dynamicznie
    np. z zewnetrznej pamieci jest raczej nierealne.


    chyba się coś koledze pomyliło i to o sporą wartość.... jeśli chodzi o takie ograniczenie to można brać pod uwagę pamięć EEPROM w procku - no ale jej się tak nie programuje często

    tymczasem doczytaj o możliwej dopuszczalnej maksymalnej ilość zapisów do pamięci FLASH procka - jak doczytasz i przeliczysz to na "manglowanie" jak napisałeś nawet kilka razy dziennie to wyjdzie ci parę ładnych lat - tak więc bez przesady

    po to są bootloadery i złącze ISP żeby testować układ do bólu ;)
  • #7
    tmf
    Moderator of Microcontroller designs
    Obawiam sie, ze nic mi sie nie pomylilo. Ilosc zapisow do FLASH wynosi wg dokumentacji 10000, czyli jest 10x mniejsza od ilosci zapisow do EEPROM. Czy jest to duzo czy nie to juz zalezy od aplikacji. Nietrudno sobie wyobrazic aplikacje, ktora laduje wielokrotnie "DLLki" do FLASH, nawet kilka tys. razy dziennie. Co wykonczy procesor.

    Do robin_pl: zobacz w dokumentacji sekcje memory programming, tam masz co i jak. I w AVR instruction set instrukcje SPM.
  • #8
    mirekk36
    Level 42  
    tmf --->

    tak ilość zapisów do Flash to ok 10tys ;) i wystarczy to nawet dla zawziętego amatora w przeprogramowywaniu procka na kilka lat ;) aby uruchomić prototyp

    ale - sorry kolego tmf - tym razem to już walnąłeś głupotę z kosmosu - z tym:
    tmf wrote:
    Nietrudno sobie wyobrazic aplikacje, ktora laduje wielokrotnie "DLLki" do FLASH, nawet kilka tys. razy dziennie. Co wykonczy procesor.


    ciekawe jaką ty masz wyobraźnię, że sobie wyobrażasz ładowanie jakichś DLL'ek w tego typu procesorach do pamięci FLASH (ty wiesz chociaż o czym ty w ogóle mówisz?) ..... pomylenie z poplątaniem ..... jak nie masz zielonego pojęcia (jak widać) o programowaniu mikroprocków i wszystko przyrównujesz do pracy pod Windows - to już twój wielki problem.... jeśli mieszasz pojęcia pamięci RAM w komputerach PC z pamięcią FLASH w mikroprocesorach to też twój problem - ale nie wygaduj tutaj takich kompletnych bzdur - próbując nieudolnie poradzić coś początkującemu.

    Poczytaj coś n/t pisania programów dla procków, spróbuj chociaż raz sam napisać taki program dla dowolnego procka - a wtedy sam zrozumiesz jakie bzdury tutaj wypisujesz

    .... dla informacji - czytając o max ilości cykli zapisu/kasowania pamięci Flash w procku - trzeba mieć na uwadze - najczęściej - przeprogramowywanie całego wsadu procesora (całej lub części pamięci z całym kodem wynikowym.) Tak więc takiej ilości operacji nikt nie jest w stanie nawet zrobić zbyt dużo - chyba że na upartego - dla wytestowania możliwości opisanych w PDF'ie ;)



    ------------------------------------------------

    robin_pl wrote:

    czy może JEDYNĄ możliwością zmiany kodu jest tylko i wyłącznie CAŁKOWITE przeprogramowanie układu - JTAG'iem, ISP, bootloaderem ?


    tak - to w zasadzie jest jedyna możliwość - Flash to nie pamięć RAM jak w PC w tym przypadku i tu nikt nie stosuje takich technik

    tak więc koledzy

    zapomnijcie raz na zawsze ładowaniu dynamicznym czegoś do FLASH'a w mikrokontolerach - tego się po prostu nie robi z założenia - a nie dlatego aby zaoszczędzić na cyklach zapisu do pamięci
  • #9
    Freddie Chopin
    MCUs specialist
    Zauważ, że tam pisze o MINIMALNEJ wartości. Nie trudno wyobrazić sobie procesor w którym ilośc zapisów mogłaby wynieść 100k albo i 1M. Pozatym... tak serio... System obsługi dynamicznego ładowania kodu, kod który byłby w stanie to wykonać, kod który byłby w stanie to wykorzystać... to nie jest za darmo, a mówimy tutaj o ATmedze, która ma kilkanaście kB FLASHa. Czy ktoś przemyslał już jaki jest koszt zastosowania takich mechanizmów? Przecież żeby czegoś takiego używać trzeba mieć system operacyjny... Już prościej napisać interpreter jakiegoś pseudokodu i owy kod ładować do RAM.

    4\/3!!
  • #10
    tmf
    Moderator of Microcontroller designs
    mirekk36:
    Zanim komus zarzucisz brak wiedzy warto przeczytac caly temat i to o co pytal zalazyciel watku. Nigdzie nie pisalem, ze pisanie programu w stylu windowsowych dllek ma sens, to zalozyciel watku pytal o taka mozliwosc. Podobnie jak o mozliwosc pisania samomodyfikujacego sie kodu.
    Moja odpowiedz byla wyczerpujaca i zgodna z prawda. To, ze masz klopot ze zrozumieniem tekstu to wylacznie twoj problem.
  • #11
    mirekk36
    Level 42  
    tmf wrote:
    Obawiam sie, ze nic mi sie nie pomylilo. Ilosc zapisow do FLASH wynosi wg dokumentacji 10000, czyli jest 10x mniejsza od ilosci zapisow do EEPROM. Czy jest to duzo czy nie to juz zalezy od aplikacji.


    a kto napisał, że to zależy od aplikacji ? - co ma piernik do wiatraka?
  • #12
    robin_pl
    Level 12  
    mirekk36 wrote:
    tmf --->
    ale - sorry kolego tmf - tym razem to już walnąłeś głupotę z kosmosu - z tym:
    tmf wrote:
    Nietrudno sobie wyobrazic aplikacje, ktora laduje wielokrotnie "DLLki" do FLASH, nawet kilka tys. razy dziennie. Co wykonczy procesor.


    ciekawe jaką ty masz wyobraźnię, że sobie wyobrażasz ładowanie jakichś DLL'ek w tego typu procesorach do pamięci FLASH (ty wiesz chociaż o czym ty w ogóle mówisz?) ..... pomylenie z poplątaniem ..... jak nie masz zielonego pojęcia (jak widać) o programowaniu mikroprocków i wszystko przyrównujesz do pracy pod Windows - to już twój wielki problem.... jeśli mieszasz pojęcia pamięci RAM w komputerach PC z pamięcią FLASH w mikroprocesorach to też twój problem - ale nie wygaduj tutaj takich kompletnych bzdur - próbując nieudolnie poradzić coś początkującemu.


    ale spokojnie ;)
    z tymi DLL'kami to był mój pomysł ;) ja zasugerowałem, że o cel w tym stylu mi chodzi ;) ale nie miałem na myśli wymianę kodu programu kilka(naście/dziesiąt/set) razy dziennie ;) a tylko okazyjne dogrywanie nowego kodu
  • #13
    mirekk36
    Level 42  
    robin_pl wrote:

    ale spokojnie ;)
    z tymi DLL'kami to był mój pomysł ;) ja zasugerowałem, że o cel w tym stylu mi chodzi ;) ale nie miałem na myśli wymianę kodu programu kilka(naście/dziesiąt/set) razy dziennie ;) a tylko okazyjne dogrywanie nowego kodu


    ok - spokojnie ;) ... ale już napisałem ci, że czegoś takiego w ogóle nie zrobisz na procku - mowa o jakiejś dynamicznej podmianie kodu nawet kilka razy dziennie - zapomnij - nie tak podchodzi się do programowania procków
  • #14
    tmf
    Moderator of Microcontroller designs
    mirekk36 wrote:
    tmf wrote:
    Obawiam sie, ze nic mi sie nie pomylilo. Ilosc zapisow do FLASH wynosi wg dokumentacji 10000, czyli jest 10x mniejsza od ilosci zapisow do EEPROM. Czy jest to duzo czy nie to juz zalezy od aplikacji.


    a kto napisał, że to zależy od aplikacji ? - co ma piernik do wiatraka?


    Hmm, trudno jest mi oprzec sie wrazeniu, ze czytajac tekst nie starasz sie go zrozumiec. To ma piernik do wiatraka, ze 10tys. zapisow to moze byc calkiem sporo (okazyjna wymiana firmaware za pomoca bootloadera) lub nic (przechowywanie jakis czesto updatowanych zmiennych, czy dynamiczne ladowanego fragmentu kodu/samomodyfikacja programu).

    Ale wracajac do meritum - piszez, ze autor moze zapomniec o dynamicznej podmianie kodu. Niby dlaczego? Dopoki w okresie zycia budowanego urzadzenia ilosc tych podmian nie przekroczy mozliwosci zapisu FLASHa to nie ma najmniejszego problemu. Czy ma to sens to inna sprawa. Chociaz moge sobie wyobrazic sytuacje, gdzie ktos uzyl procka np. z 8kB FLASH i dodatkowo ma zewnetrzna pamiec EEPROM. I nagle w zbudowanym ukladzie okazuje sie, ze fajnie by bylo dodac pare funkcji, ktore jednak juz sie nie mieszcza. I co? Mamy sytuacje, gdzie nie ma wolnego FLASH, za to jest wolny EEPROM. Wiec jakies rzadko uzywane funkcje mozna tam wyrzucic i tylko ladowac je do FLASH jak beda okazyjnie potrzebne (np. jakas rozbudowana diagnostyka ukladu). Oczywiscie lepiej byloby od poczatku wsadzic procek z zapasem, ale zycie pokazuje, ze nie zawsze wszystko da sie przewidziec.
  • #15
    mirekk36
    Level 42  
    tmf wrote:
    (okazyjna wymiana firmaware za pomoca bootloadera) lub nic (przechowywanie jakis czesto updatowanych zmiennych, czy dynamiczne ladowanego fragmentu kodu/samomodyfikacja programu).

    Ale wracajac do meritum - piszez, ze autor moze zapomniec o dynamicznej podmianie kodu. Niby dlaczego? Dopoki w okresie zycia budowanego urzadzenia ilosc tych podmian nie przekroczy mozliwosci zapisu FLASHa to nie ma najmniejszego problemu. Czy ma to sens to inna sprawa. Chociaz moge sobie wyobrazic sytuacje, gdzie ktos uzyl procka np. z 8kB FLASH i dodatkowo ma zewnetrzna pamiec EEPROM. I nagle w zbudowanym ukladzie okazuje sie, ze fajnie by bylo dodac pare funkcji, ktore jednak juz sie nie mieszcza. I co? Mamy sytuacje, gdzie nie ma wolnego FLASH, za to jest wolny EEPROM. Wiec jakies rzadko uzywane funkcje mozna tam wyrzucic i tylko ladowac je do FLASH jak beda okazyjnie potrzebne (np. jakas rozbudowana diagnostyka ukladu). Oczywiscie lepiej byloby od poczatku wsadzic procek z zapasem, ale zycie pokazuje, ze nie zawsze wszystko da sie przewidziec.


    wiesz - jakby się ktoś zaparł - żeby to zrobić - to by zrobił - tyle, że zrobiłby to czystej krwi amator - młody gniewny człowiek, który na siłę chce udowodnić swoje chore teorie - piszę chore nie dlatego że nie możliwe - ale totalnie niepraktyczne, nieprofesjonalne, nieeleganckie i w większości wypadków można je określić jako bzdurne....

    .... widać, że jeszcze nigdy sam nie dotknąłeś chociaż tematyki napisania własnego bootloadera - a szkoda, może przeszłyby ci takie dziwne teorie ... bo od bootloadera, do przeprogramowywania pamięci Flash z eepromu to już w ogóle - okresliłbym gorzej niż chory pomysł - jeśli chodzi oczywiście o praktyczną stronę takiego rozwiązania, bezpieczeństwo działania programu itp .... tak może mógłbyś zastosować wtedy program z tak wykorzystywanymi procedurami wczytywanymi w locie do FLASH'a do sterowania misiem pluszowym, który miga oczkami itp ... sorry za sarkazm, ale gwarantuję ci że nawet pisząc takie oprogramowanie dla misia pluszowego - w końcu puknąłbyś się w głowę i poszedł po rozum do głowy - i zrobił to jak się należy czyli zwiększył procka i ilośc pamięci flash - zamiast załadować do eeproma wymiennie kilka krótkich bzdurnych funkcyjek ....

    poza tym - jeśli komuś zabrakło miejsca - to nie będzie się bawił w dokładanie funkcyjek z eeproma - bo sam kod tego mechanizmu zeżarłby bardzo miejsca .... no chyba, że ktoś hyhyhyhy na etapie planowania już napisałby taką obsługę marnując drogocenne miejsce i przewidując że będzie ładował co jakiś bliżej nie określony czas durne funkcyjki z eeproma! ... ten pomysł jest urojony .... bo zamiast planować że jak zabraknie miejsca to będę ładował funkcje z eeproma - lepiej wziąć procek z większą pamięcią - jeśli z tym się nie zgodzisz - no to sorry - ale nawet nie ma o czym dalej z tobą dyskutować

    .... jak ktoś robi coś na procku - to podstawa dobrze to zaplanować łącznie z przewidzeniem fazy rozwojowej poprzez zastosowanie nieco większej pamięci FLASH niż potrzeba. Tego typu - BABOLE - o jakich piszesz, że znowu możesz sobie wyobrazić, że ktoś wpadł na pomysł dodatkowych funkcji i zaczyna kombinować z eepromem .... to jest BABOL a nie projektowanie - i większość tego typu BABOLI projektanci eliminują w fazie testowej urządzenia oraz w dobrym planowaniu.

    Jeśli ktoś ma małe doświadczenie, nie potrafi planować, dobierać procka itp itp itp itd - to będzie może i stawał przed takimi dylematami jak opisujesz, ale też nikomu - zaznaczam - poważnemu nie opłacałoby się MARNOWAĆ czasu na takie próby zabawkowego przeprogramowywania FLASH'a

    reasumując - nie po to ATMEL dał możliwość przeprogramowywania pamięci FLASH "w locie" - żeby korzystać z tak karkołomnych pomysłów i zastosowań ..... jest kilka powodów kiedy może się taki mechanizm przydać - ale w większości przypadków wystarcza bootloader i przeprogramowanie procka

    .... więc nie brnij dalej kolego w te ślepe uliczki - na siłę udowadniając swoje teorie - bo to stanie się wkrótce śmieszne - poza tym nie zarzucam ci braku wiedzy - widać tylko, że nie grzeszysz jeszcze praktyką
  • #16
    Mat_91
    Level 25  
    tmf wrote:
    Mamy sytuacje, gdzie nie ma wolnego FLASH, za to jest wolny EEPROM. Wiec jakies rzadko uzywane funkcje mozna tam wyrzucic i tylko ladowac je do FLASH


    Funkcje przechowywać w EEPROM? To w ogóle tak można? I co z predkościa odczytu takiej funkcji z EEPROM'u? I chyba chciałeś do ładować do ram- nie do flash.

    To już dużo rozsądniejszym rozwiązaniem jest to co zapronował Freddie Chopin, interpreter jakiegoś jeżyka (np.: BASIC). Wgrywasz go raz do flasha a cały kod programu odczytujesz chociażby z karty pamięci czy szeregowych (bądź równoległych) pamięci zewnetrznych, kod ładować do ramu i stamtąd go wykonywać.
  • #17
    Nawigator
    Level 33  
    W AVR-ach nie ma możliwości wykonywania kodu z RAM-u, można tam tylko przechowywać zmienne z tego co się orientuję, ale mogę się mylić a nie chcę się narazić kol. mirekk36...

    N.
  • #18
    mirekk36
    Level 42  
    Nawigator ---> jakie narazić ? ;)

    pewnie, że z RAMu nie można wykonywać kodu - racja

    natomiast kolega Mat_91 - może pomyślał o prockach AVR z serii '51, które z kolei mają możliwość wykonywania kodu wprost z pamięci RAM ..... i w takiej konfiguracji to można by było sobie ew wyobrazić - działanie dynaminie ładowanych jakichkolwiek funkcji np z karty pamięci a nawet eepromu ;) ---- tyle że znowu autor wspomniał o Arduino - a te robione są w oparciu o zwykłe AVR typu ATmega o innej strukturze rozkładu pamięci
  • #19
    tmf
    Moderator of Microcontroller designs
    mirekk36 wrote:

    wiesz - jakby się ktoś zaparł - żeby to zrobić - to by zrobił - tyle, że zrobiłby to czystej krwi amator - młody gniewny człowiek, który na siłę chce udowodnić swoje chore teorie - piszę chore nie dlatego że nie możliwe - ale totalnie niepraktyczne, nieprofesjonalne, nieeleganckie i w większości wypadków można je określić jako bzdurne....


    Znowu nie starasz sie rozumiec tego co czytasz. Nikt tu nie pytal o praktyczny aspekt, tylko czy sie da. Czy jest to niepraktyczne? Zapewne tak, ale zapewne sa tez sytuacje w ktorych jest to jakies rozwiazanie.

    mirekk36 wrote:
    .... widać, że jeszcze nigdy sam nie dotknąłeś chociaż tematyki napisania własnego bootloadera - a szkoda, może przeszłyby ci takie dziwne teorie ... bo od bootloadera, do przeprogramowywania pamięci Flash z eepromu to już w ogóle - okresliłbym gorzej niż chory pomysł - jeśli chodzi oczywiście o praktyczną stronę takiego rozwiązania, bezpieczeństwo działania programu itp ....


    Wyobraz sobie, ze napisalem wlasny bootloader. A w jaki sposob ma to wplywac na bezpieczenstwo programu to juz zupelnie sobie nie wyobrazam. Bo nawiet nie wiem o jakim bezpieczenstwie piszesz.

    mirekk36 wrote:
    tak może mógłbyś zastosować wtedy program z tak wykorzystywanymi procedurami wczytywanymi w locie do FLASH'a do sterowania misiem pluszowym, który miga oczkami itp ... sorry za sarkazm, ale gwarantuję ci że nawet pisząc takie oprogramowanie dla misia pluszowego - w końcu puknąłbyś się w głowę i poszedł po rozum do głowy - i zrobił to jak się należy czyli zwiększył procka i ilośc pamięci flash - zamiast załadować do eeproma wymiennie kilka krótkich bzdurnych funkcyjek ....


    A jakbym mial juz w Chinach zamowione 100tys. takich misiow to tez bym nie skorzystal z takiego rozwiazania, bo to nieeleganckie?

    mirekk36 wrote:
    poza tym - jeśli komuś zabrakło miejsca - to nie będzie się bawił w dokładanie funkcyjek z eeproma - bo sam kod tego mechanizmu zeżarłby bardzo miejsca .... no chyba, że ktoś hyhyhyhy na etapie planowania już napisałby taką obsługę marnując drogocenne miejsce i przewidując że będzie ładował co jakiś bliżej nie określony czas durne funkcyjki z eeproma!


    Duzo miejsca powiadasz? Takie ladowanie zajmie kilkanascie instrukcji w assemblerze, a wywolanie takich funkcji mozna zorganizowac w postaci jump table, calosc zajmie jakies 50 bajtow albo i mniej.
    W praktyce podobny mechanizm wykorzystalem wlasnie do podmiany bootloadera przy jego updatowaniu. A w wiekszym projekcie do downloadowania kodu bootloadera z zewnetrznej pamieci I2C w przypadku bledu CRC FLASH. Wtedy urzadzenie samo pobiera sobie sprawny fragment kodu i oczekuje na uploadowanie calego firmware przez siec.

    Nawigator: nie myslisz sie, AVR potrafi wykonywac kod wylacznie z wewnetrznej pamieci FLASH.
  • #20
    Mat_91
    Level 25  
    Hmm przepraszam za błąd, nie siedze w AVR dla tego myślałem ze mają taka możliwość.

    Aczkolwiek biorąc pod uwagę inne rodziny uC jest to jak najbardziej możliwe. A że na razie są to tylko rozważania teoretycznie to nic nie stoi na zmianie koncepcji i zmianie uC (lub płytki rozwojowej z uC innej rodzinny) :]

    Pozdrawiam!
  • #21
    mirekk36
    Level 42  
    tmf wrote:
    W praktyce podobny mechanizm wykorzystalem wlasnie do podmiany bootloadera przy jego updatowaniu. A w wiekszym projekcie do downloadowania kodu bootloadera z zewnetrznej pamieci I2C w przypadku bledu CRC FLASH. Wtedy urzadzenie samo pobiera sobie sprawny fragment kodu i oczekuje na uploadowanie calego firmware przez siec.


    ... tak - to są przypadki kiedy warto użyć takich mechanizmów - ale nie opowiadaj o funkcjach programu dynamicznie ładowanych co jakiś czas z eepromu w procku i o setkach tysięcy misiów w chinach ...
  • #22
    Nawigator
    Level 33  
    AVR jest to Miś na miarę naszych możliwości...

    N.
  • #23
    robin_pl
    Level 12  
    tmf wrote:
    mirekk36 wrote:
    poza tym - jeśli komuś zabrakło miejsca - to nie będzie się bawił w dokładanie funkcyjek z eeproma - bo sam kod tego mechanizmu zeżarłby bardzo miejsca .... no chyba, że ktoś hyhyhyhy na etapie planowania już napisałby taką obsługę marnując drogocenne miejsce i przewidując że będzie ładował co jakiś bliżej nie określony czas durne funkcyjki z eeproma!


    Duzo miejsca powiadasz? Takie ladowanie zajmie kilkanascie instrukcji w assemblerze, a wywolanie takich funkcji mozna zorganizowac w postaci jump table, calosc zajmie jakies 50 bajtow albo i mniej.
    W praktyce podobny mechanizm wykorzystalem wlasnie do podmiany bootloadera przy jego updatowaniu. A w wiekszym projekcie do downloadowania kodu bootloadera z zewnetrznej pamieci I2C w przypadku bledu CRC FLASH. Wtedy urzadzenie samo pobiera sobie sprawny fragment kodu i oczekuje na uploadowanie calego firmware przez siec.


    dokładnie o coś takiego mi chodziło :)

    jest sobie urządzenie, które ma 5 głównych opcji w menu - a pozostałe opcje pojawią się po dograniu kolejnych procedur odpowiedzialnych za konfigurację nowopodpiętych urządzeń

    te procedury mogły by być dogrywane np. z kości SD wkładanej do wbudowanego w kontroler gniazda SD a dostarczane razem z urządzeniem