Elektroda.pl
Elektroda.pl
X
Relpol przekaźniki nadzorczeRelpol przekaźniki nadzorcze
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Programator AVR USBASP - Linux i programowanie 10 urządzeń jednocześnie

02 Maj 2013 18:18 3420 19
  • Poziom 36  
    Witam.

    Pod kontrolą RaspberryPi pracuje 10 urządzeń (w sieci RS485). Wszystkie zainstalowane są w szafie na szynach TH35, Raspberry Pi również. Urządzanie mają wyprowadzone złącza ISP. Chciałbym mieć możliwość zdalnego programowania firmware.

    Najprostsze rozwiązanie jakie przychodzi mi do głowy to zakup 10 sztuk programatora AVR USBASP wpięte do HUB-a USB i programowanie odpalane po zalogowaniu się po SSH na konsolę Raspberry Pi. Oczywiście po kolei, bo nie sądzę, by programowanie udało się uruchomić na 10 programatorach jednocześnie.

    A może są jakieś inne sprawdzone rozwiązania / pomysły masowego programowania wielu urządzeń po ISP ?
  • Relpol przekaźniki nadzorczeRelpol przekaźniki nadzorcze
  • Poziom 40  
    A czemu po ISP a nie bootloader?
  • Moderator na urlopie...
    Do takiego programowania już bardziej JTAG pasuje i połączenie układów w łańcuszek, albo, jak powiedział przedmówca, odpowiedni bootloader i wykorzystanie samego RS485 do programowania.
    Względnie, jeśli musiałoby być ISP, to taniej niż N programatorów, wyjdzie wybudowanie odpowiedniego multipleksera sygnału ISP, albo dodanie przed każdym wejściem bufora, który "podłączał" by dany układ do programatora po podaniu odpowiedniego stanu na linię "CS" - i potem do tego jeden układ, który sterowałby takim multiplekserem, a sam byłby kontrolowany choćby przez FT232.
  • Poziom 36  
    excray napisał:
    A czemu po ISP a nie bootloader?

    Szkoda pamięci. Użyta AMEGA32, i pamięć wykorzystana prawie w 100%.

    Dodano po 3 [minuty]:

    piotrva napisał:
    Względnie, jeśli musiałoby być ISP, to taniej niż N programatorów, wyjdzie wybudowanie odpowiedniego multipleksera sygnału ISP, albo dodanie przed każdym wejściem bufora, który "podłączał" by dany układ do programatora po podaniu odpowiedniego stanu na linię "CS" - i potem do tego jeden układ, który sterowałby takim multiplekserem, a sam byłby kontrolowany choćby przez FT232.

    To dobra droga. Chyba w tę stronę pójdę.
  • Moderator Mikrokontrolery Projektowanie
    Jeśli pamięć zajęta tylko w prawie 100% to może te kilkaset bajtów na bootloader da się wygospodarować, zawsze można też zoptymalizować progam. Z pewnością jest to prostsze niż zabawa z ISP.
    A propos ISP - właściwie nic nie trzeba multipleksować - wystarczy sterować np. linią SCK - układ, który nie dostaje SCK nie wejdzie w tryb ISP, za to RESET utrzyma go w stanie nie kolidującym z programowaniem innego układu. Tylko ciężko widzę te odległości, obciążenie i pojemności połączeń. Trzebaby jakiś bufor wstawić, a sygnał MISO z każdego AVR zapewne też przyjdzie buforować. Także patrz punkt pierwszy -bootloader :)
    Jeśli naprawdę się aplikacji nie da zoptymalizować (a 32 kB aplikację prawie zawsze się da), to jeśli ta ATMega jest w DIP to prościej będzie zrobić do niej minimoduł np. z ATMega64 i wymienić w ten sposób procki.
  • Relpol przekaźniki nadzorczeRelpol przekaźniki nadzorcze
  • Poziom 36  
    tmf napisał:
    Jeśli pamięć zajęta tylko w prawie 100% to może te kilkaset bajtów na bootloader da się wygospodarować, zawsze można też zoptymalizować progam. Z pewnością jest to prostsze niż zabawa z ISP.

    Słyszałem, że bootloader jest bardzo pamięciożerny, stąd też nie wchodziłem głębiej w temat. Programowanie po ISP zapewni mi jednak większą kontrolę zdalną - jak coś mi padnie podczas programowania po ISP - proces mogę powtórzyć. Jeśli padnie bootloader to zdalnie już nic nie zrobię...

    tmf napisał:
    A propos ISP - właściwie nic nie trzeba multipleksować - wystarczy sterować np. linią SCK - układ, który nie dostaje SCK nie wejdzie w tryb ISP, za to RESET utrzyma go w stanie nie kolidującym z programowaniem innego układu. Tylko ciężko widzę te odległości, obciążenie i pojemności połączeń. Trzebaby jakiś bufor wstawić, a sygnał MISO z każdego AVR zapewne też przyjdzie buforować.

    Bufor dwukierunkowy by się przydał, kto wie, czy kluczowanie (a może zastosowanie miniaturowych przekaźników z cewką na 5V w obudowie DIP (jak układ scalony) nie będzie najpewniejszym rozwiązaniem.
  • Moderator na urlopie...
    Przekaźniki to moim zdaniem nienajlepszy pomysł... Coś co generuje pole magnetyczne blisko procesora i na liniach programowania - obawiałbym się fajnych nieoczekiwanych przygód. Jeśli już to bufor.
    A co do bootloadera - na prawdę trzeba się postarać, żeby takowy uszkodzić (o ile wszystko jest dobrze przemyślane), a można zrobić fajny bootloader w bardzo malutkim rozmiarze kodu - kwestia wprawy lub znalezienia fajnego gotowca ;)
  • Moderator Mikrokontrolery Projektowanie
    MES Mariusz napisał:
    tmf napisał:
    Jeśli pamięć zajęta tylko w prawie 100% to może te kilkaset bajtów na bootloader da się wygospodarować, zawsze można też zoptymalizować progam. Z pewnością jest to prostsze niż zabawa z ISP.

    Słyszałem, że bootloader jest bardzo pamięciożerny, stąd też nie wchodziłem głębiej w temat. Programowanie po ISP zapewni mi jednak większą kontrolę zdalną - jak coś mi padnie podczas programowania po ISP - proces mogę powtórzyć. Jeśli padnie bootloader to zdalnie już nic nie zrobię...

    tmf napisał:
    A propos ISP - właściwie nic nie trzeba multipleksować - wystarczy sterować np. linią SCK - układ, który nie dostaje SCK nie wejdzie w tryb ISP, za to RESET utrzyma go w stanie nie kolidującym z programowaniem innego układu. Tylko ciężko widzę te odległości, obciążenie i pojemności połączeń. Trzebaby jakiś bufor wstawić, a sygnał MISO z każdego AVR zapewne też przyjdzie buforować.

    Bufor dwukierunkowy by się przydał, kto wie, czy kluczowanie (a może zastosowanie miniaturowych przekaźników z cewką na 5V w obudowie DIP (jak układ scalony) nie będzie najpewniejszym rozwiązaniem.


    Bootloader może zająć nawet kilkadziesiąt bajtów. Wszystko zależy jak skomplikowany jest protokół wymiany danych pomiędzy urządzeniami. Dla porównania - Atmelowy bootloader obsługujący RS232 i szyfrowanie 128 bitowe AES ma 2-3kB. Bez szyfrowania miałby poniżej 1 kB. Jeśli coś się zepsuje przy programowaniu przez bootloader to programowanie zawsze można powtórzyć. Przy odpowiednio ustawionych fusebitach nie ma możliwości skasowania bootloadera, więc jego uszkodzenie jest równoznaczne z uszkodzeniem mikrokontrolera.
    Co do ISP - żadnych dwukierunkowych buforów nie potrzeba. To jest zwykłe SPI, więc kierunek przesyłu danych na każdej linii jest z góry znany. A pomysł z przekaźnikami - im szybciej o nim zapomnisz tym lepiej. W ogóle im szybciej zapomnisz o pomyśle z ISP tym lepiej:)
  • Poziom 22  
    A te 10 bootloaderów, to jak się fizycznie podłącza do 1 portu Rpi?
  • Moderator Mikrokontrolery Projektowanie
    Jado_one napisał:
    A te 10 bootloaderów, to jak się fizycznie podłącza do 1 portu Rpi?


    Przecież te 10 procków już jest połączonych jedną magistralą RS485.
  • Poziom 36  
    tmf napisał:
    Przecież te 10 procków już jest połączonych jedną magistralą RS485.


    Zgadza się. Co do bootloadera trochę się go boję ze względu na brak czasu wydaje mi się, że szybciej bym to ogarnął poprzez realizację rozdzielacza ISP (chyba, żeby komuś zlecić przygotowanie bootloadera...?).

    Materiały niby w sieci są:
    http://ep.com.pl/files/3561.pdf
    http://www.mcselec.com/index.php?option=com_content&task=view&id=159
    http://avrhelp.mcselec.com/index.html?mcsbootloader.htm
    http://www.forbot.pl/forum/topics20/programow...loadery-pierwsze-kroki-rs232-i-usb-vt3700.htm
    https://www.elektroda.pl/rtvforum/topic1809610.html
  • Poziom 22  
    tmf napisał:

    Przecież te 10 procków już jest połączonych jedną magistralą RS485.

    No dobrze, a jak wprowadzic je w stan programowania (reset), wszystkie da się jednocześnie zaprogramować?, czy trzeba każdy po kolei? Jeśli po kolei, muszą chyba dojść jeszcze jakieś linie sterujące, wybierające, resetujące, itp....?
    No chyba, że da się to zrobić czysto programowo - po adresie wewnętrznym procka - niestety ja zasadniczo przeskoczyłem AVR'y, więc nie jestem w temacie - ale zainteresowało mnie to z technicznego punktu widzenia :-)
  • Moderator Mikrokontrolery Projektowanie
    Jado_one napisał:
    tmf napisał:

    Przecież te 10 procków już jest połączonych jedną magistralą RS485.

    No dobrze, a jak wprowadzic je w stan programowania (reset), wszystkie da się jednocześnie zaprogramować?, czy trzeba każdy po kolei? Jeśli po kolei, muszą chyba dojść jeszcze jakieś linie sterujące, wybierające, resetujące, itp....?
    No chyba, że da się to zrobić czysto programowo - po adresie wewnętrznym procka - niestety ja zasadniczo przeskoczyłem AVR'y, więc nie jestem w temacie - ale zainteresowało mnie to z technicznego punktu widzenia :-)


    To się robi całkowicie programowo. Wykorzystując bootloader nie wprowadza się procka jakiś nowy stan, po prostu realizuje się funkcję zapisu strony pamięci FLASH nową wartością. Czyli na rs485 wysyła się polecenie do konkretnego urządzenia typu odpal bootloader, po czym wysyła się kolejne polecenia z danymi zawierającymi kod programu. Można oczywiście zaprogramować wszystkie jednocześnie, jest tylko mały problem - dobrze by było aby procesor odbierający dane je kontrolował i w razie błędu mógł wysłać żądanie retransmisji błednej ramki.

    Dodano po 3 [minuty]:

    MES Mariusz napisał:
    tmf napisał:
    Przecież te 10 procków już jest połączonych jedną magistralą RS485.


    Zgadza się. Co do bootloadera trochę się go boję ze względu na brak czasu wydaje mi się, że szybciej bym to ogarnął poprzez realizację rozdzielacza ISP (chyba, żeby komuś zlecić przygotowanie bootloadera...?).


    Bootloader to naprawdęnic skomplikowanego, niepotrzebnie się obawiasz. Atmel też wydał parę własnych bootloaderów i noty do nich. Jak wygląda transmisja po RS485? Masz jakieś ramki, to jest transmisja master-slave, czy multimaster? Jeśli to proste master-slave, odpowiednik RS232, to cały bootloader zmieści się w <1kB.
  • Poziom 22  
    tmf napisał:
    [
    To się robi całkowicie programowo. Wykorzystując bootloader nie wprowadza się procka jakiś nowy stan, po prostu realizuje się funkcję zapisu strony pamięci FLASH nową wartością. Czyli na rs485 wysyła się polecenie do konkretnego urządzenia typu odpal bootloader, po czym wysyła się kolejne polecenia z danymi zawierającymi kod programu.

    Ach tak....w takim razie zmyliła mnie nazwa bootloader - myślałem, że do jego uaktywnienia
    wymagany jest reset mikrokontrolera, który podczas startu sprawdza sobie stan jakiegoś pinu i w zależności od tego stanu uruchamia albo program ładujący, albo użytkownika - jak to jest np. w ARM'ach.
    Ale czy w takim razie, skoro wywołanie bootloadera ma - jak rozumiem - być jednym z rozkazów wysyłanych do mikrokontrolera przez RS485, to czy w przypadku niedokończonego/nieudanego zapisu (i w związku z tym, padzie programu użytkownika) nie spowoduje to "zamilknięcia" mikrokontrolera?
  • Moderator na urlopie...
    Bootloader może być uaktywniony w dowolny sposób, niekoniecznie podczas startu i resetu procesora, chociaż jest to często stosowana praktyka (czasem np. po starcie procesor czeka parę sekund na komunikat po UART itp.). Równie dobrze może być to komenda wysłana przez RS485.
    Co do problemu wgrania błędnego programu lub błędu komunikacji - od czego są sumy kontrolne i tego typu zabezpieczenia. Wiadomo - ryzyko zawsze istnieje, ale wykonując odpowiednio kontrolę przesłanego wsadu można zrobić tak, aby w przypadku awarii procesor wogóle nie zaczynał wykonywania wadliwego programu, ale pozostawał w trybie bootloadera.
  • Poziom 36  
    tmf napisał:
    Bootloader to naprawdęnic skomplikowanego, niepotrzebnie się obawiasz. Atmel też wydał parę własnych bootloaderów i noty do nich. Jak wygląda transmisja po RS485? Masz jakieś ramki, to jest transmisja master-slave, czy multimaster? Jeśli to proste master-slave, odpowiednik RS232, to cały bootloader zmieści się w <1kB.

    Transmisja master-slave na MAX485, 4800 b/s, urządzenia są slavea-mi, oczekują nanapływające dane:

    Code:
    Odbierz:
    

    Disable Urxc
     Kod_znaku = Udr
     Tekst = Chr(kod_znaku)
     Enter = 1
     If Kod_znaku <> 13 Then Enter = 0
     If Enter = 0 Then
      Zdanie = Zdanie + Tekst                                   ' jesli wcisnieto inny klawisz niz enter dopisz znak do zdania
      Znakdodruku = 1
     End If
     Enable Urxc
    Return


    Zbierane są kolejno napływające bajty (znaki). Po napłynięciu entera tworzone jest zdanie, które dalej jest interpretowane, wykonywane operacje na sprzęcie i ewentualnie generowana odpowiedź. Komunikacja przypomina konsolę dos albo linux. Kiedy finalnie ukończę firmware, można będzie pomyśleć o bootloaderze. Zobaczymy ile zostanie pamięci.
  • Moderator Mikrokontrolery Projektowanie
  • Moderator na urlopie...
    Uuuu, tu pomoże tylko kolega Manekinen - wirtuoz Bascoma i optymalizacji w tym języku.
    Osobiście polecam przesiadkę na C ;)
  • Poziom 36  
    piotrva napisał:
    Uuuu, tu pomoże tylko kolega Manekinen - wirtuoz Bascoma i optymalizacji w tym języku.
    Osobiście polecam przesiadkę na C ;)

    Chętnie. Niestety jako ojciec dwójki chłopaków i pracujący mąż pracującej żony dzisiaj jestem zmuszony korzystać wyłącznie z tego co zdążyłem poznać (to, że teraz siedzę nad kodem to igranie ze śmiercią ;-), ryzykowanie gniewu żony ;-). Może w następnym życiu uda mi się przesiąść na C... ;-) Dziś to już albo zlecić pewne rzeczy osobie trzeciej, albo z nich zrezygnować, albo zrobić coś na okrętkę. Projekt (po publikacji w EP) planuję jako open source, być może lepsi ode mnie napiszą ten soft lepiej i w C.
  • Poziom 22  
    Niezły argument w dyskusji na temat "Dlaczego wybierać C" - bo pewnych rzeczy nie da się zrobić w Bascomie ;-)