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

Programmer to go dla AVR (Programowanie AVR bez PCta)

Anderian 30 Gru 2009 15:44 3850 21
REKLAMA
  • #1 7458769
    Anderian
    Poziom 18  
    Czy ktoś z kolegów spotkał się z projektem stacjonarnego programatora do AVRów ?
    Chodzi o programowanie układów bez użycia PCta, tylko układ z AVRem na pokładzie i wgranym na stałe programem, który następnie wgrywany do urządzeń.
  • REKLAMA
  • REKLAMA
  • #3 7459204
    Anderian
    Poziom 18  
    bootloadery znam.

    muszę zaprogramować większą ilość urządzeń i znacznie szybciej będzie poprzez sam programator bez użycia PC
  • #4 7459325
    mirekk36
    Poziom 42  
    Niedawno dosłownie kilka tyg temu był dokładniuśko taki sam post z takim samym pytaniem i tam też ktoś się zaparł że nie chce bootloadera ;) .... więc proponuję zapoznać się z tamtym tematem i życzę powodzenia

    czasem warto zmienić założenia niż walczyć z wiatrakami ;) nie oznacza to że nie jest to niemożliwe - to tylko kwestia czasu i kasy - a zwykle każdy rzuca się na takie rozwiązanie bo liczy że uda się to zrobić w przysłowiowe 2 dni robocze i za przysłowiową złotówkę

    po czym - po 2-4 miesiącach - okazuje się, że jednak bootloader to wspaniałe rozwiązanie! - tyle że już nie napisze o tym w swoim temacie na elektrodzie ;)
  • #5 7459476
    tmf
    VIP Zasłużony dla elektroda
    Nie zawsze bootloader jest taki wspanialy, a nawet jesli jest to i tak pozostaje kwestia skad pobierac dane - a tu czasami lepiej jest miec prosty uklad, niz calego PC. Tego typu projekty sa, na AVRFreaks jest gosc, ktory robil cos takiego i chyba nawet sprzedaje. Zrobienie tego samemu jest raczej banalne - napisanie kodu programujacego po ISP to kilkadziesiat linii, interpreter HEX to tez kilkadziesiat linii, w razie czego moge podrzucic wlasne kody w C++.
    P.S. mnie np. prosciej bylo zrobic programowanie po ISP dla ukladu, ktory z PC laczyl sie za pomoca chipa FTDI niz dodawac bootloader. Po ISP mam kontrole nad wszystkim - nie tylko zawartoscia pamieci, ale takze fusebitami, w razie czego moge nawet w trybie bit-bang generowac zegar dla procesora. W tej sytuacji bootloader nic by mi nie dal, poza koniecznosci napisania kodu na mikrokontroler - na PC pisze sie latwiej, a przynajmniej latwiej debuguje.
    P.S. Bootloader tez jakos w chipie musi sie znalezc, co czasami podwaza sens jego stosowania. No i zawsze moze sie uszkodzic.
  • #6 7459922
    asembler
    Poziom 32  
    Autor postu ma racje ze nie chce bootloadera Jest prosty sposob programowania a raczej klonowania AVR z tym ze mam jedno pytanie jaki dlugi program w tej atmedze kopiowanej bedzie? Ale co do szybkosci programowania wiekszej ilosci procesorow to raczej to nie przyspieszy, gdyz czas programowania jest zalezny od czasu zapisu do flash-a
  • #7 7460135
    BoskiDialer
    Poziom 34  
    Dokumentacja każdego AVR'a zawiera dokładny opis protokołu aby zaprogramować przez ISP/SPI jak i równolegle (pewnie ISP/SPI jest tutaj ciekawszym rozwiązaniem). Wystarczy otworzyć dokumentację na "Memory Programming -> Serial Downloading". Po zapoznaniu można zacząć pisać program na jakiegoś innego avr'a, który komunikował by się z układem docelowym i próbował się z nim połączyć. Po połączeniu sprawdzić czy nie jest już zaprogramowany, jeśli nie to zacząć wpisywać dane pobierając je np z własnej pamięci flash.
    W skrócie: z procesora programującego potrzebne będą 4 przewody: jeden do sterowania resetem, trzy do SPI. Po wystawieniu stanu niskiego na reset trzeba wymienić 4 bajty (0xAC 0x53 i dwa dowolne), przy trzecim wymienianym bajcie układ zwróci 0x53 co będzie oznaczać tyle, że pomiędzy MOSI a MISO jest opóźnienie 8 bitowe - czyli połączenie jest sprawne. Przy okazji procesor wejdzie w tryb programowania i można mu zacząć wysyłać następne polecenia (każde ma 4 bajty). Więcej nie ma co się rozpisywać, wszystko jest w dokumentacji.
    Kiedyś stworzyłem programator komunikujący się przez podczerwień, który mógł pracować w dwóch trybach: pierwszy w połączeniu z komputerem widoczny jako port COM, po napisaniu własnej łatki do avrdude mogłem programować dowolny avr; drugi tryb odbierał plik wysyłany przez obex (np wysyłając plik przez podczerwień w telefonie) i wgrywał go w locie na jeden z kilku typów avr'ów (ograniczenie spowodowane posiadaniem małej tablicy kojarzącej sygnaturę z rozmiarem pamięci flash i rozmiarem strony, która jest potrzebna do poprawnego zaprogramowania układu).
  • REKLAMA
  • #9 7462225
    Nawigator
    Poziom 33  
    No ładny ale za 89 dolarów i w Chinach.
    Kilka dni była o takim programatorze mowa:
    https://www.elektroda.pl/rtvforum/topic1513361.html
    ale autor zamknął temat bez podania rozwiązania.
    Mam pytanie jak koledzy widzą wpis gotowego hex do flasha programatora? W całości z bajtami wierszy czy jakos inaczej?

    N.
  • #10 7462537
    BoskiDialer
    Poziom 34  
    Szybciej było by napisać na komputer mały program konwertujący plik hex (lub bin) na coś pośrednio bardziej strawnego do tego zastosowania: do pliku .c (lub np. .inc i dołączyć #include'm) z wypełnioną tablicą w pamięci programu. Dołączyć taką tablicę do projektu i bezpośrednio z niej programować. Posiadanie pliku w postaci hex w pamięci flash jest złym pomysłem:
    - na każdy bajt pamięci programowanej przypadają dwa znaki - strata miejsca
    - dodatkowo zbędne adresy
    - potrzeba interpretowania pliku w locie, kiedy i tak po wgraniu do pamięci flash nie ma takiej potrzeby.
    Rozwiązanie z plikiem z tablicą ma natomiast wiele zalet:
    - do napisanego programu można napisać regułę do makefile
    - plik po skompilowaniu będzie praktycznie czystymi danymi binarnymi i nie będzie potrzebna ekstra duża pamięć flash.
  • #11 7462749
    tmf
    VIP Zasłużony dla elektroda
    Zwykle tego typu programatory maja karte SD, na ktora na PC wgrywa sie potrzebne wsady, wiec miejsce nie jest tu krytyczne. Natomiast HEX ma jedna olbrzymia zalete - jesli program nie zajmuje spojnego bloku pamieci, tylko jest np. na poczatku i na koncu (typowo aplikacja + bootloader) z wieka dziura pomiedzy to oszczedzamy duzo czasu na programowanie i przy okazji sporo miejsca na niepotrzebne bajty.
    Co do programatora to widzialem inny - zapodaj tam temat to pewnie czlowiek sie odezwie.
  • #12 7462826
    BoskiDialer
    Poziom 34  
    No to przekształcić na inny pośredni format, nadal unikając hex'a: w ciąg bajtów dający się podzielić na bloki. 2 bajty długość linijki, 4 bajty adres pod jakim ma wylądować pierwszy bajt a dalej ciąg bajtów o długości wyliczanej z długości linijki (ewentualnie na końcu suma kontrolna). Z pliku hex wyciągać kolejne linie, scalać je w jedną dłuższą aby uniknąć nadmiarowych informacji i wrzucić do tablicy. Jeśli pojawia się luka na więcej niż 6 bajtów, to zakończyć jedną linijkę i zacząć następną - uzyska się coś postaci pliku binarnego z niewielką narzutą na nagłówki, które to umożliwią skompresowanie pustych bloków. Jeśli część przetwarzania pliku hex można przenieść na etap kompilowania lub trochę wcześniej, to warto to zrobić, gdyż nie trzeba będzie w procesorze umieszczać tego kodu czyli zyska się na pamięci flash oraz same dane nie będą zajmować dużo miejsca. Każdy format pośredni będzie dobry, tylko nie hex który ma dużą nadmiarowość ze względu na użycie znaków ASCII.

    Używając karty SD traci moc argumentacja na rozmiar pliku, jednak dalej interpretacja danych wstępnie przetworzonych będzie łatwiejsza. Wadą będzie wtedy natomiast konieczność przetworzenia hex'a przed wgraniem na kartę.
  • #13 7462896
    tmf
    VIP Zasłużony dla elektroda
    Interpretacja HEXa jest tak banalna (jak pisalem zajelo mi to kilkadziesiat linii kodu), ze nie oplaca sie w przypadku karty SD wprowadzac posrednich formatow. A nawet jesli jej nie ma to i tak, zeby to mialo sens jakis DataFLASH bedzie, wiec IMHO jakiekolwiek przetwarzanie traci sens. Tak naprawde zastanowilbym sie wrecz nad wykorzystaniem plikow elf - zeby miec info o fusebitach.
  • #14 7462978
    asembler
    Poziom 32  
    O czym rozmowa jezeli zapisujemy do flasha w postaci bin to po co sie babrac w hex i tracic dwa razy wiecej pamieci. Co w przypadku ja zrobisz programator na samym procesoraze atmega8? Ja dodaje do głownego programu programujacego avr zbior bin i po kłopocie.
  • #15 7462996
    tmf
    VIP Zasłużony dla elektroda
    Po to, ze w pewnych sytuacjach wcale nie tracisz pamieci - jesli masz 1kB programu i na koncu 300 bajtow BL to bin ma dla ATMegi8 8kB, a HEX malo. I to jest dosyc typowe. Z drugiej strony nikt nie trzyma wsadow w programatorze w pamieci FLASH kontrolera programatora. Jest to bez sensu bo: a) ilosc zmian wsadu ze wzgledu na trwalosc FLASH jest ograniczona, b) ATMega8 nie moglaby programowac procesorow wiekszych niz pwenie jakies male ATTiny, bo nie byloby miejsca na wsad, c) zmiana wsadu bylaby upierdliwa, d) w praktyce nie moznaby trzymac kilku roznych wsadow, co mocno ogranicza funkcjonalnosc. Dlatego taki programator to zwykle maly procesorek + karta SD. Co zapewnia wygode i miejsce.
  • #16 7463099
    BoskiDialer
    Poziom 34  
    Jeśli to ma być do zaprogramowania większej ilości urządzeń każdy takim samym oprogramowaniem, to tracą znaczenie:
    - argument a/ - ograniczenie trwałości to 10000 cykli zapis/kasowanie, a wątpię żeby trzeba było zmieniać wgrywany program przed każdym pojedynczym programowaniem (założenie o programowaniu bez PC'ta) oraz wątpię żeby oprogramowanie na docelowe urządzenia zmieniało się tak często, żeby trzeba było wszystkie urządzenia przeprogramować np 1000 razy.
    - argument c/ Nie koniecznie. Jeśli taki programator mógł by się komunikować w dowolny sposób z komputerem, to mógł by odebrać nowy firmware i samemu zapisać go do własnej pamięci flash. Podłączenie kabla było by to tak samo upierdliwe jak przekładanie karty pamięci pomiędzy urządzeniem a czytnikiem (może trochę bardziej gdyby trzeba było podłączyć jeszcze kabel zasilający).
    - argument d/ a po co trzymać kilka różnych wsadów? gdyby miało być kilka różnych wsadów, to pojawia się konieczność wyboru wsadu czyli pojawia się dodatkowo kilka przycisków i albo wyświetlacz albo diody.
    jedyny znaczący jest argument b/. W takim przypadku trzeba dać zewnętrzną pamięć, jednak SD komplikowało by sam program, potrzebne by było wsparcie systemu plików etc - łatwiej było by wziąć zewnętrzną pamięć flash lub eeprom i przeprogramować ją mając podłączony kabel do urządzenia - unika się stosowania systemu plików, dane mogą być zapisane w formacie dogodnym do programowania, komunikacja może być stosunkowo prosta.
  • #17 7463156
    asembler
    Poziom 32  
    zakładajac ze autor chce robi jakies urzadzenie seryjnie w tys sztuk to bedzie sie staral wybrac jak najtanszy procesor. Najbardziej popularnym i wygodnym malo nózek jest wlasnie atmega8 i wybierajac atmege 168 na programator caly wsad sie miesci do flasha. Ja rozmiem ayora postu gdyz sam musze zmieniac oprogramowanie i to raczej w warunkach w ktorych branie ze sobą PC raczej jest utrudnione. Moj programator jest skonstruowany tak ze wykrywa włozenie go do ganiazda ukladu i samoczynnie zmienia oprogramowanie niejednokrotnie sie przydalo na wysokosciach gdzie moglem tylko jedna reka operowac. Robilem cos takiego na bootloaderze ale nie zdal egzaminu a po rozbudowie programu został usuniety na stałe.
  • #18 7463207
    tmf
    VIP Zasłużony dla elektroda
    Ja zakladam, ze nie chodzi tu o urzadzenie seryjnie programujace procesory w tysiacach sztuk - tu jednak jakas platforma oparta na PC i jakims dziwacznym (w sensie mozliwosci jednoczesnego programowania wielu procesorow) programatorze by się przydala. Trzymanie wsadu na karcie SD ma pare zalet - brak koniecznosci robienia interface do PC, brak koniecznosci symulowania mass storage po USB (inaczej trzebaby pisac dedykowana aplikacje na PC, czyli miec ja ze soba na wypadek gdyby trzeba bylo zmienic wsad). Obsluga SD z FAT tylko do odczytu jest banalna - analogicznie mnie to zajelo 341 linii kodu. Trzymanie kilku roznych wsadow jest atrakcyjne, bo przeciez urzadzenie moze miec wiecej niz jeden procesor, albo mozemy w terenie miec kilka roznych urzadzen. W kazdym razie z tego co pisza osoby wykorzytujace tego typu rozwiazania to wlasnie korzystaja z SD i wielu wsadow + prosty LCD do wyboru wsadu i pokazujace komunikaty diagnostyczne. Oczywiscie dla jakis specyficznych rozwiazan sprawe mozna bardzo uproscic.
  • #19 7463454
    asembler
    Poziom 32  
    Mnie si ewydaje ze to urzadzenie ma tylko sens w przypadku małych projektów a 99% to własnie małe projekty, a jak mam zapisywac na karte SD to juz wole do netbooka podlaczyc.
  • #20 7468320
    Nawigator
    Poziom 33  
    -> BoskiDialer :
    " tylko nie hex który ma dużą nadmiarowość ze względu na użycie znaków ASCII "
    wydaje mi się że hex zawiera kod maszynowy czyli dwubajtowe słowa rozkazów a nie ASCII.

    N.
  • REKLAMA
  • #21 7475758
    BoskiDialer
    Poziom 34  
    Nawigator: Pisząc hex mam na myśli popularny format pliku "intel hex", gdzie na każdy właściwy bajt przypadają dwa znaki. Nadmiarowość polega tutaj na tym, że większość plików hex po przekształceniu na format binarny będzie zajmować co najwyżej około 38% tego co odpowiedni plik hex. Po rozkodowaniu może i będzie z tego kod maszynowy, jednak mi chodzi o to, że przy ograniczeniach na pamięć nie ma sensu trzymać bezpośrednio pliku hex tylko właśnie rozkodowane do danych binarnych.
REKLAMA