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

Czysto sprzętowy programator ISP AVR (bez współpracy z PC)

AVATAR_PL 07 Lis 2007 18:23 3295 28
  • #1 07 Lis 2007 18:23
    AVATAR_PL
    Poziom 14  

    Witam!
    Ostatnio chodzi mi po głowie wykonanie sprzętowego programatora ISP procesorów AVR. Mam na myśli urządzenie do którego można załadować same wsady np. w formacie bin i bez użycia komputera zaprogramować procesor.
    Czy ktoś z was spotkał się z podobnym projektem?, może są gotowe komercyjne rozwiązania?

    Dzięki za odpowiedzi :)

    0 28
  • #2 07 Lis 2007 20:13
    JOLLY
    Poziom 15  

    Może głupie pytanie, ale skąd brać wsady w takim razie? Jakieś karty pamięci?

    0
  • #3 07 Lis 2007 20:19
    AVATAR_PL
    Poziom 14  

    Piszesz program na PC, kompilujesz a wynik kompilacji (np: plik .BIN) kopiujesz do programatora sprzętowego, może być to karta SD, dysk twardy, jakiś FLASH itp.
    Generalnie w 90% przypadków takie coś nie jest nikomu potrzebne, dopóki nie musi zaprogramować 20 procesorów 15 metrów nad ziemią, stojąc na drabinie :) :). - To tylko taki przykład :)

    0
  • #5 07 Lis 2007 21:03
    DJ_KLIMA
    Poziom 12  

    Uhm... z chęcią sie podepnę pod temat jak coś wymyślicie, w moim przypadku opcja jest następująca; 1400m pod ziemia, wilgotność 75%, zapylenie (krzemionka) + olej 30 - 50% zależy gdzie! Komputery wytrzymują średnio po 200 - 250 roboczogodzin wiadomo, że programowanie trwa parę sekund, dodam iż pancerne panasoniki szlak trafia po około 300 roboczogodzinach :), wcześniej programowałem uC i z wgranymi wariantami do roboty :) ale obecnie prototypy maszyn są tak zbudowane, iż musiał bym programować po 100 atmeg 128 w SMD aby usprawnić pewne funkcje... Myślałem nad takim programatorem i kartą SD z wyświetlaczem 2 segmentowym, z wybieraniem sobie binarek do wgrania, cyk i już. Dajcie znać jak coś wymyślicie !

    0
  • #7 07 Lis 2007 21:39
    AVATAR_PL
    Poziom 14  

    @Platon - Bardzo ciekawy pomysł, ale potrzebuje czegoś znacznie prostszego :)
    @jacur - Niestety nie o to chodzi.

    0
  • #8 07 Lis 2007 23:51
    ktrot
    Poziom 19  

    Niekoniecznie potrzebne są ekstremalne warunki aby takie urządzenie się przydało. Moze to być np upgrade na odległość. Wysyłamy plik bin internetem do klienta. Klient wgrywa ten plik do czarnej skrzynki, wpina programator do urządzenia, naciska guzik i ma zrobiony upgrade (ewentualnie wymianę procesora). Nie musi podjeżdżać z pecetem do urządzenia i uczyć się programu do programowania. Nie zrealizowałem tego ale mam w głowie ideę takiego urządzenia.

    Najprostszy sposób to uC o pamięci flash takiej samej lub większej od uC, który zamierzamy programować, do tego jakieś diody sygnalizujące stan i przyciski. Programator przepisuje zawartość swojej pamięci flash do uC, który zamierzamy programować. Jeżeli uC w programatorze i uC docelowym mają takie same pamięci flash to brakujący kawałek (bo część flash zajmuje programik przepisywania) umieszczamy w pamięci eeprom.

    Oczywiście można sobie łatwo wyobrazić wygodniejsze urządzenie: uC (tym razem dowolny) + zewnętrzna pamięć flash (może być sd) lub uC+interface USB wpółpracujące z dowolnym pendrivem.

    0
  • #9 08 Lis 2007 08:45
    Ch.M.
    Poziom 27  

    --> Platon
    Bardzo fajny pomysł, szkoda ze nie mam palma... pod symbianem chodzą podobne programy, może znajdę wersję na Motkę A1000, przyjemnie byłoby pobawić się palmofonem podłączonym z prockiem :)
    Jakby była możliwość zainstalowania kompilatora na palmie to by był "full wypas"
    Pomysł na prawdę dobry i warty uwagi, szczególnie ze palmy nie sa strasznie drogie (używane)
    Pozdrawiam

    0
  • #10 08 Lis 2007 17:54
    PiotrPitucha
    Poziom 33  

    Cześć
    Jeśli w procesorze będzie bootloader to nie powinno być problemów zarówno z ładowaniem z PDA posiadającego RS232, jak i z drugiego procesora z większą pamięcią i to praktycznie bez specjalnych programów.
    Piotr

    0
  • #11 09 Lis 2007 01:02
    Platon
    Spec od komputerów

    AVATAR_PL - czegos prostszego? W jakim sensie prostszego? Gdzie znajdziesz mniejsze urzadzenie niz palmtop, i tansze niz 40zł?

    0
  • #12 09 Lis 2007 01:32
    kamyczek
    Poziom 34  

    Sprzętowy programator do układów które obsługują operacje spm ciekawe po jakiego to robić jak można sobie moduł rs 485, BT, czy inne łącze np na CC1000 zrobić i zaprogramować atmela zdalnie ..

    0
  • #13 09 Lis 2007 14:12
    Nawigator
    Poziom 33  

    Z bootloaderem przez dowolny interfejs sprawa jest oczywista, ale musi on być przewidziany w programie i zajmuje trochę miejsca, musi być przetestowany itd. Jak jest układ z procesorem full a tak zazwyczaj bywa to sprzętowy isp by się przydał.
    Do małej serii produkcyjnej też. Keyfob Kanda (link jacur) do tego służy. Program jest najpierw ładowany z komputera do programatora przy pomocy specjalnego programu a potem już tylko podłączyć do procesora, niebieski przycisk i gotowe. Potrzebującym zawodowo firma powinna kupić taki programator, 116 funciaków to w końcu nie majątek.
    Pzdr. N.

    0
  • #14 09 Lis 2007 18:43
    BoskiDialer
    Poziom 34  

    Jeśli to ma być układ typu "wepnij i wgraj", to wystarczy jeden mikrokontroler wpinany przez interfejs isp do układu docelowego, protokół programowania avr'ów jest opisany praktycznie w każdej dokumentacji avr'ów, sam mam projekt, w którym jeden procek programuje drugi bez pomocy komputera - ściśle soft jest wysyłany przez podczerwień z telefonu (tylko upgrade zintegrowany z weryfikacją) albo z komputera (pełna obsługa) - procek to odbiera i wrzuca do podłączonego układu. Jeśli układ miał by być prosty, to jeden uC na zegarze RC, jeden przycisk, złącze idc10 i jedno miejsce na zworę (co by można było zaprogramować procek - wgrać soft z dołączonym plikiem docelowym). Podłączasz, naciskasz przycisk i procek wysyła wszystko do układu docelowego. Jedynym wymaganiem było by, aby procek w programatorze był większy (pojemniejszy) od ilości softu wgrywanego o co najmniej 3KB. Piszesz soft, który po wykryciu naciśnięcia przycisku łączy się z układem docelowym, programuje go częścią swojej pamięci flash, weryfikuje (jeśli niepowodzenie to od nowa) i kończy pracę. Jeśli warunki są tak ekstremalne, że istnieje ryzyko uszkodzenia się przycisku, to można dać tylko diodę, układ co jakiś czas sprawdzał by czy układ docelowy jest podłączony (jeśli tak, to zapala diodę), programuje, gasi diodę i zawiesza się (aby więcej nie programować).

    0
  • #15 12 Lis 2007 18:33
    William Bonawentura
    Poziom 31  

    AVATAR_PL napisał:
    @Platon - Bardzo ciekawy pomysł, ale potrzebuje czegoś znacznie prostszego :)


    Zacznijmy może od tego, że w kopalni potrzebujesz sprzętu z atestem bezpieczeństwa np. z "Barbary". Czyli montowanie czegoś samodzielnie i potem atestowanie jest mało celowe - lepiej wykorzystać np. palmtopa przemysłowego w hermetycznej obudowie.

    0
  • #16 12 Lis 2007 18:58
    marek_Łódź
    Poziom 36  

    William Bonawentura napisał:
    AVATAR_PL napisał:
    @Platon - Bardzo ciekawy pomysł, ale potrzebuje czegoś znacznie prostszego :)


    Zacznijmy może od tego, że w kopalni potrzebujesz sprzętu z atestem bezpieczeństwa np. z "Barbary". Czyli montowanie czegoś samodzielnie i potem atestowanie jest mało celowe - lepiej wykorzystać np. palmtopa przemysłowego w hermetycznej obudowie.


    Przecież On nie pisał o żadnej kopalni (chyba, że między wierszami ;) )
    DJ_KLIMA pisał o podziemiach, ale na kopalnię węgla mi to nie wygląda, prędzej miedzi albo złota ;) , a tam są inne przepisy ;-)

    ps Palmtop nawet z atestem nie rozwiąże sytuacji, bo potrzebny jest jeszcze ISP z atestem.

    0
  • #18 13 Lis 2007 09:02
    Jdsoul
    Poziom 23  

    Cześć!!!
    Koncepcja super. Pytanie zasadnicze do czego układ ma służyć i czego mamy wymagać od urządzenia w którym będzie zmieniany soft ???

    Jeśli rzeczywiście ma być to tylko SPI to rozwiązanie z prockiem i pamięcią SD jest słuszne i właściwie cenne.

    Ma pewne wady
    1. Jak to podłączyć do "dużego" PC, żeby nie programować programatora.
    2. Problem może się już pojawić jak w przenośnym programatorku będziesz chciał mieć kilka bin. np. kilka różnych wersji softu lub soft do kilku urządzeń. Niestety w tym momencie pojawi się kwestia albo implementacji tablicy FAT w układzie, jakiegoś wyświetlacza, jakiego mniej lub bardziej rozbudowanego układu klawiatury , czy nawigacji menu no i w końcu temat zasilania układu.

    Co do wymagań programowanego urządzenia. to musi się pojawić jakiś zewnętrznie dostępny interfejs i jakakolwiek formuła ratowania urządzenia.
    Wiecie czasem podczas programowania szeregowego może się coś nie powieść, lub w skrajnym przypadku możemy pomylić pliki , wersje itd itd.
    I urzadzenie zimne , a klient nad głową wisi :)

    Podsumowując PDA będzie miał wszystko, system plików, możliwość nawigacji po aplikacji. Powienien jednak mieć zapewnione komfortowe warunki zasilania i buckup, do tego separację interfejsu programowego.


    Wydaję mi się że najlepsze byłoby .... stworzenie programatora .... współpracującego z PDA lub inną "gotową" platformą sprzętową, na tyle przenośnego na ile to możliwe i wymiana danych pomiędzy "dużym" Pc i PDA. , a potem aplikacja na PDA i współpraca z programatorkiem :)

    Dodano po 8 [minuty]:

    Można by też pomyśleć o odwróceniu sprawy :) :)

    Rzeczywiście dodać łącze radiowe BT lub WIFI do urzadzenia końcowego platformy i programować w sesji telnet, ftp lub nawet samodzielnie.

    Przykład takiego samokonfigurujacego się środowiska to RUNES.

    http://www.sics.se/contiki/projects/contiki-and-the-runes-middleware.html

    Problemem staję się tylko koszt urządzeń końcowych.
    Ale powyższy system został wykorzystany do monitorowania podziemych tuneli drogowych i podobno świetnie działa więc może w tym kierunku byłoby słuszniej i docelowo taniej ???

    Koszt to już nie bootloader, ale cały sieciowy system operacyjny !!!!

    0
  • #19 14 Lis 2007 08:01
    Bazi13
    Poziom 10  

    Coś komplikujecie "As simple as better" :
    - Bateria, procek z SPI i EEPROM lub osobny EEPROM, wyświetlacz lcd lub LED, i pare "guzików" :-)

    Bardzo fajny pomysł. Do przedyskutowania zostaje fakt jak chcesz ładwoać te BINy do urządzenia? Jak wypuszcać to w zasadzie nie problem tylko troche pracy, wyświetlacz na wypadek jakbyś chciał wiecej Tych Binów miec ale to też trzeba wziąść na uwage pojemnośc pamięci

    0
  • #20 14 Lis 2007 09:14
    Jdsoul
    Poziom 23  

    No i jeszcze coś pokombinować

    Np. , jak długi jest każdy BIN, od którego momentu zacząć przepisywać i w którym momencie skończyć :) i czy aby rzeczywiście jest jeszcze wolne miejsce w "kluczu" i czy aby optymalnie pamięć EEPROM została wykorzystana, a później jakoś inteligentnie rozwiązać kwestię usunięcia z "klucza" zbędnych binów itd. itd. albo oznaczając plik jako nieaktywny albo od nowa zapisując "image" plików, hardware w EEPROM.

    No i chyba sprawa kluczowa SPI to poprostu piny procesora, raczej słabo zabepieczone i mające wpływ na całość urządzonka, więc gniazdo powinno być dobrze uszczelnione lub zbuforowane, a to kolejny układ :(

    Wbrew pozorom przy 1 lub 2 binach , 0 problemu później już zaczynają się schody.

    Wiesz tego typu zagadnienie , długi czas działa np. w synchornizacji ustawień radiostacji lub zabezpieczeniach urządzeń i raczej nie przenosi się tym Firmware tylko same Dane i config.

    Dodano po 22 [minuty]:

    Tak czy inaczej korzyść z "kieszonkowego" programatora pojawi się dopiero przy kilku urządzeniach programowanych o podobnym firmware lub rozwiązanych w "podobny" sposób uwzględniających funkcjonalność programowania kluczem.

    Oczywiście zarządzanie "sprzętowym" programatorem warto załatwić z poziomu PC - I tu w sumie trochę inwencji nie zaszkodzi, może jakaś dodatkowa baza danych do veryfikacji i .

    Co zaś do sposobu ładowania do "programatora" to RS-232, i2c lub USB.

    Mogłoby wyglądać jak coś takiego :)

    http://www.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/USBToolStick.htm

    0
  • #21 14 Lis 2007 16:07
    AMD_Athlon
    Poziom 12  

    A moze telefon komorkowy. Mam Siemensa M65 (pancerny telefon z norma szczelnosci IP54 :D). Mozna do niego dokupic akcesorium "Bike-o-Meter" - przystawke sprzetowa przeksztalcajaca telefon w licznik rowerowy. Jako prawdziwy polak postanowilem te przystawke zlozeyc, a nie kupic (niestety nie znalazlem schematu). Wracajac do tematu musi byc mozliwosc dostepu javy do UART-a. Dolaczamy do tego translator UART <-> ISP na jakims AVR i mamy ze 3 MB pamieci klawiature i kolorowy ;) wyswietlacz. Jedyny problem to zdobycie polecen obslugi UART-a do Siemensa (inne telefony chyba nie maja takich mozliwosci), nie jest to przeciez standardowy zestaw polecen Javy.

    Przepraszam za brak polskich znakow - Gentoo nie lubic polskie znaki ;)

    0
  • #23 15 Lis 2007 11:21
    Jdsoul
    Poziom 23  

    No jest ale z tego co widać na załączonych opisach, to właściwie taka mała protezka, bo:

    - decyzję o przenoszonym pliku musisz podjąć w momencie programowania klucza, określić mu wszystkie parametry programowanego docelowo urządzenia i załadować bin. hex do przenośki;

    Na miejscu podłączasz standardową wstążkę i naciskasz przycisk :) :), więc docelowe urządzenie powinno mieć wyprowadzony standardowy SPI.
    czyli itd.

    0
  • #24 08 Mar 2008 10:39
    asembler
    Poziom 32  

    I co dalej z tym projektem? Właśnie też mam taki problem "na drabinie"

    0
  • #25 08 Mar 2008 11:03
    kamyczek
    Poziom 34  

    Na drabinie ;) Swietnie ale w dobie procesorów z botloaderem można sobie zastosować dowolną metodę programowania I2c, spi, uart, usb, ir, bluetoth , itp wszystko zalezy od programisty ,który napisze sam loader...

    0
  • #26 08 Mar 2008 11:14
    asembler
    Poziom 32  

    Pytałem autora postu czy skonstruował juz programator który monza stosowac w nieludzikich warunkach np na drabinie.

    0
  • #27 08 Mar 2008 16:32
    AVATAR_PL
    Poziom 14  

    @kamyczek - widzę, że nie rozumiesz idei takiego programatora, ten powyższy bootloader też trzeba jakoś zaprogramować.
    @asembler - niestety z powodu chronicznego braku czasu nie mogę się do tego zabrać :(

    0
  • #28 08 Mar 2008 20:24
    asembler
    Poziom 32  

    No własnie ten czas. Ja sie tez zabieram do tego tematu już jakiegoś czasu. Chce zrobic z wyświetlaczem LCD oczywiscie zasilanie bateryjne tak zeby można było wizualnie sprawdzic poprawnosc programowania (później może nawet możliwośc wprowadzania małych poprawek do kodu)
    Teraz musze biegać wyjmując z urzadzenia procek i programując na IBM.

    0
  • #29 08 Mar 2008 21:46
    tplewa
    Poziom 38  

    Obecnie wiekszosc programatorow do AVR jest po niekad sprzetowa :)
    Pomijajac oczywiscie proste klony STK200.

    Mozna zmodyfikowac soft np. z usbasp ( http://www.fischl.de/usbasp/ )

    Dorobic mu obsluge kart MMC/SD (FAT lub jakis swoj prosty sytem plikow).
    Oraz dodac osobna liste rozkazow w protokole komunikacji (odczyt/zapis MMC - programowanie))- tak aby tez pracowal jako zwykly programator.

    W sumie temat fajny :) i realizacja niezbyt trudna :)

    0
  Szukaj w 5mln produktów