Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

robin_pl 12 Sie 2009 15:56 1520 22
  • #1 12 Sie 2009 15:56
    robin_pl
    Poziom 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 ...

  • #2 12 Sie 2009 16:29
    maniek1818
    Poziom 22  

    Cytat:
    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 12 Sie 2009 17:08
    robin_pl
    Poziom 12  

    maniek1818 napisał:
    Cytat:
    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" ;)

  • Pomocny post
    #4 12 Sie 2009 22:56
    tmf
    Moderator Mikrokontrolery Projektowanie

    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 13 Sie 2009 01:02
    robin_pl
    Poziom 12  

    tmf napisał:
    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 napisał:
    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 13 Sie 2009 07:55
    mirekk36
    Poziom 42  

    tmf napisał:
    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 13 Sie 2009 09:05
    tmf
    Moderator Mikrokontrolery Projektowanie

    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 13 Sie 2009 09:56
    mirekk36
    Poziom 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 napisał:
    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 napisał:

    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 13 Sie 2009 10:04
    Freddie Chopin
    Specjalista - Mikrokontrolery

    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 13 Sie 2009 10:56
    tmf
    Moderator Mikrokontrolery Projektowanie

    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 13 Sie 2009 11:02
    mirekk36
    Poziom 42  

    tmf napisał:
    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 13 Sie 2009 11:42
    robin_pl
    Poziom 12  

    mirekk36 napisał:
    tmf --->
    ale - sorry kolego tmf - tym razem to już walnąłeś głupotę z kosmosu - z tym:
    tmf napisał:
    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 13 Sie 2009 12:31
    mirekk36
    Poziom 42  

    robin_pl napisał:

    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 13 Sie 2009 13:02
    tmf
    Moderator Mikrokontrolery Projektowanie

    mirekk36 napisał:
    tmf napisał:
    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 13 Sie 2009 14:06
    mirekk36
    Poziom 42  

    tmf napisał:
    (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 13 Sie 2009 14:11
    Mat_91
    Poziom 25  

    tmf napisał:
    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 13 Sie 2009 14:19
    Nawigator
    Poziom 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 13 Sie 2009 14:46
    mirekk36
    Poziom 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 13 Sie 2009 14:48
    tmf
    Moderator Mikrokontrolery Projektowanie

    mirekk36 napisał:

    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 napisał:
    .... 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 napisał:
    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 napisał:
    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 13 Sie 2009 14:54
    Mat_91
    Poziom 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 13 Sie 2009 15:07
    mirekk36
    Poziom 42  

    tmf napisał:
    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 13 Sie 2009 15:34
    Nawigator
    Poziom 33  

    AVR jest to Miś na miarę naszych możliwości...

    N.

  • #23 13 Sie 2009 17:13
    robin_pl
    Poziom 12  

    tmf napisał:
    mirekk36 napisał:
    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

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME