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

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

MES Mariusz 02 Maj 2013 18:18 3678 19
REKLAMA
  • #1 12263440
    MES Mariusz
    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 ?
  • REKLAMA
  • #2 12263451
    excray
    Poziom 41  
    A czemu po ISP a nie bootloader?
  • REKLAMA
  • #3 12263553
    piotrva
    VIP Zasłużony dla elektroda
    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.
  • #4 12263792
    MES Mariusz
    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ę.
  • #5 12263870
    tmf
    VIP Zasłużony dla elektroda
    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.
  • #6 12264110
    MES Mariusz
    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.
  • #7 12265077
    piotrva
    VIP Zasłużony dla elektroda
    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 ;)
  • #8 12265303
    tmf
    VIP Zasłużony dla elektroda
    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:)
  • #9 12265657
    Jado_one
    Poziom 22  
    A te 10 bootloaderów, to jak się fizycznie podłącza do 1 portu Rpi?
  • REKLAMA
  • #10 12265865
    tmf
    VIP Zasłużony dla elektroda
    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.
  • #11 12266467
    MES Mariusz
    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
  • REKLAMA
  • #12 12266617
    Jado_one
    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 :-)
  • #13 12266642
    tmf
    VIP Zasłużony dla elektroda
    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.
  • #14 12267344
    Jado_one
    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?
  • #15 12267432
    piotrva
    VIP Zasłużony dla elektroda
    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.
  • #16 12267493
    MES Mariusz
    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:

    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.
  • #18 12268472
    piotrva
    VIP Zasłużony dla elektroda
    Uuuu, tu pomoże tylko kolega Manekinen - wirtuoz Bascoma i optymalizacji w tym języku.
    Osobiście polecam przesiadkę na C ;)
  • #19 12268547
    MES Mariusz
    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.
  • #20 12268792
    Jado_one
    Poziom 22  
    Niezły argument w dyskusji na temat "Dlaczego wybierać C" - bo pewnych rzeczy nie da się zrobić w Bascomie ;-)
REKLAMA