Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP

szulat 16 Sie 2012 02:42 39648 48
  • Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP

    ATxmegi to łakomy kąsek dla kogoś, kto już poznał "stare" AVRki - zwiększona szybkość (32MHz!), o wiele więcej peryferiów (5 UARTów! 16 kanałów PWM!), modularna budowa i można używać tych samych dobrze znanych narzędzi. Ale potem czytamy o interfejsie programowania i... co?! Gdzie jest ISP?! Przecież nie będę kupować nowego programatora tylko po to, żeby pobawić się ich procesorkiem!

    Na szczęście zaimplementowanie nowego protokołu programowania w USBASP okazało się łatwiejsze, niż się spodziewałem. Z początku wydawało mi się, że będzie to prawie niemożliwe, bo PDI wymaga ciągłego sygnału zegarowego i rozłącza się, gdy częstotliwość spadnie poniżej 10 kHz. Tego typu wymogi czasowe są problemem dla V-USB (implementacja USB używana w USBASP), jako że cała transmisja USB jest obsługiwana softwarowo i nie może w tym czasie robić niczego innego (podobnie jak niektórzy goście co to nie są w stanie równocześnie chodzić i myśleć).

    Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP

    (na obrazku powyżej - przerwy w sygnale zegarowym wywołane przerwaniami V-USB)

    Ale testy wykazały, że przerwanie przy obsłudze prostego transferu typu control zabiera tylko 40-50us i jest to wystarczająco mało, że nie przerywa połączenia PDI obsługiwanego softwarowo. Wysyłanie większej liczby danych na raz zakłóca zegar, ale można to obejść przez odpowiednią organizację pracy programatora, czyli zbieranie danych i użycie ich w momencie, gdy nie spodziewamy się dalszego ciągu transmisji.

    Moja implementacja przełącza się na generację zegara timerem na czas transmisji USB (podczas których przerwania grożą dłuższymi przestojami zegara), chociaż nie jest to absolutnie konieczne, bo można również rozłączać PDI i łączyć ponownie po transferze (ale uznałem, że PDI może bardziej lubić ciągły zegar ;-))

    Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP

    (na obrazku - po lewej zegar softwarowy, po prawej już z timera)

    Połączenie fizyczne

    Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP

    Normalny USBASP jest na 5V, a PDI ATxmegi pracuje na 3,3V, najprostszym sposobem obniżenia napięcia jest oczywiście dioda Zenera.

    Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP

    Jak widać, SCK steruje PDI DATA, a MOSI to PDI CLK. R1 i R2 wydają się niepotrzebne, ale takie jest zalecane połączenie wg Atmela przy normalnych programatorach PDI. Chodzi o to, że linia DATA jest dwukierunkowa i warstwa fizyczna połączenia powinna umieć wykrywać kolizje. Moja implementacja akurat tego nie robi, chociaż mogłaby, używając linii MISO (może ktoś to kiedyś dorobi). Kolejna dziwna rzecz to połączenie RESET wyglądająca jak masa - bo to właśnie jest masa odłączana w razie potrzeby. Gdyby była podłączona cały czas, to buskeeper w PDI widzi połączenie do masy (przez diodę!) i nie trzyma poziomu wysokiego, więc na czas odbierania danych ta "niby masa" jest odłączana.
    Jeżeli masz USBASP pracujący na 3,3V, to te wszystkie sztuczki są niepotrzebne i wystarczy podłączyć tak jak normalne PDI:

    Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP


    Zasilanie
    Jeżeli chcemy zasilać programowany układ z programatora, to do 5-voltowego USBASPa trzeba też dodać jakiś stabilizator 3,3V, ale nie jest to element tego projektu.


    Oprogramowanie:
    Oczywiście, żeby to wszystko działało potrzebne są jeszcze dwa kawałki softu:
    1. Firmware USBASP z obsługą PDI:
    Źródła do ściągnięcia stąd:
    http://www.fischl.de/usbasp/usbasp.2011-05-28.tar.gz
    oraz patch usbasp-pdi-usbaspfirmware-20120816.txt (załącznik)

    Odpakować, dorzucić patch, skompilować:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    ...i zainstalować w programatorze.

    Uwaga: ATmega48 nie jest obsługiwana, bo dodatkowy kod nie mieści się już w pamięci. Ja testowałem tylko na ATmega8 (więc pewnie ATmega88 też zadziała).


    2. AVRDUDE z obsługą USBASP z PDI:
    Potrzebujesz źródeł w wersji r1092 i patcha usbasp-pdi-avrdude2091-20120816.txt (w załączniku)

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Efekt końcowy - klasyczne miganie diodą
    Programator ATxmega za złotówkę, czyli obsługa PDI w USBASP

    Co teraz?
    Programator działa z moją ATxmegą16A4 i z moim Linuksem na kompie, ale byłoby miło dowiedzieć się, czy działałoby też u kogoś innego (zwłaszcza, że połączenie PDI zależy od przerwań obsługujących USB). Więc... zapraszam do ściągania i testowania (i może naprawiania), a jeżeli wszystko pójdzie dobrze, to pewnie można będzie to dołączyć do oficjalnych wydań USBASP i AVRDUDE.

    Podsumowanie
    - Dodając prosty interfejs do USBASP możesz programować ATXmegi;
    - Jeżeli już masz USBASP, to interfejs zrobisz w parę minut prawie za darmo (ale jeżeli musisz dopiero kupić USBASP, to i tak będzie to najtańszy sposób na zaprogramowanie xmegi);
    - Zupgradowany USBASP może w dalszym ciągu służyć do programowania starszych AVRek (po odłączeniu interfejsu);
    - Ale jest też haczyk: żeby zainstalować nową wersję firmware w programatorze musisz mieć drugi programator.

    Dla zwiększenia ilości potencjalnych testerów jest też wersja angielska tego opisu, jeżeli jesteście na jakichś forach zagranicznych, gdzie ludzie byliby zainteresowani, to tu jest link:
    http://szulat.blogspot.com/2012/08/atxmega-programmer-for-050.html

    Aktualizacja:
    Dodałem skompilowany wsad dla atmegi8 (załącznik usbasp_pdi_atmega8_20120816.txt - txt, bo rozszerzenie hex jest zakazane).


    Fajne!
  • #2 16 Sie 2012 10:07
    maniek1818
    Poziom 22  

    Gdyby jeszcze jakimś cudem zaimplementować w nim interfejs TPI (do programowania najmniejszych ATMEL'ków) to byłby pełen sukces :P

  • #3 16 Sie 2012 10:59
    piotrva
    Moderator Mikrokontrolery

    Nie wiem Koledzy dlaczego to uważacie za taką sztuczkę, ale o ile dobrze pamiętam to:
    1. Jeden z naszych elektrodowiczów współpracował z autorem USBAsp nad implementacją nowych interfejsów programowania
    2. Wspólnie napisali firmware, który obsługiwał TPI
    ---
    Moim skromnym zdaniem i tak lepszym rozwiązaniem jest sprzętowy USB w programatorze AVR ISP MKII

  • #4 16 Sie 2012 11:30
    mjc
    Poziom 14  

    A ja się przyczepię płytki: Link czy dobrze mi się wydaje, że jest to... tektura ?!

  • #5 16 Sie 2012 11:32
    szulat
    Poziom 23  

    Nie wiem kto go napisał ale TPI już było w tych źródłach USBASP które zmieniałem. Nie sprawdzałem czy działa bo nie mam żadnego atmela z TPI :P (więc też fajnie gdyby ktoś sprawdził czy moja reorganizacja kodu tego nie zepsuła, ja nie sprawdzę)

    piotrva napisał:
    Moim skromnym zdaniem i tak lepszym rozwiązaniem jest sprzętowy USB w programatorze AVR ISP MKII

    Na pewno pod wieloma względami jest lepszy ale z mojego subiektywnego punktu widzenia AVRISP MKII jest o wieeeele gorszy od USBASP, a to dlatego że USBASP posiadam a AVRISP MKII musiałbym dopiero kupić :D i jeżeli zabawa skończy się na zaprogramowaniu jednego czy dwóch procesorków to wydawanie takiej kasy wydało mi się pomysłem zupełnie absurdalnym.

    m4tc10k napisał:
    A ja się przyczepię płytki: Link czy dobrze mi się wydaje, że jest to... tektura ?!

    Zgadłeś :) Przed budową prototypu zakładałem że raczej się nie uda więc po co robić bardziej trwałą płytkę...

  • #6 16 Sie 2012 14:01
    maniek1818
    Poziom 22  

    szulat napisał:
    Nie wiem kto go napisał ale TPI już było w tych źródłach USBASP które zmieniałem.

    Ech, Mea Culpa...
    na stronie autora już od roku wisi aktualizacja ze wsparciem dla TPI.
    Jak należy przekompilować avrdude (w windows) z tym path'em :?:

  • #7 16 Sie 2012 17:26
    simpson777
    Poziom 10  

    Cytat:
    Potrzebujesz źródeł w wersji r1092 . . .


    Moje pytanie,gdzie to znaleźć?? Tak i jak prze kompilować.

    Cytat:
    1. Firmware USBASP z obsługą PDI:
    Źródła do ściągnięcia stąd:
    http://www.fischl.de/usbasp/usbasp.2011-05-28.tar.gz
    oraz patch usbasp-pdi-usbaspfirmware-20120816.txt (załącznik)

    Odpakować, dorzucić patch, skompilować:

    Kod Bash - [rozwiń]
    tar xvzf usbasp.2011-05-28.tar.gz
    cd usbasp.2011-05-28/firmware
    patch <full/path/of/usbasp-pdi-usbaspfirmware-20120816.diff
    make main.hex



    ...i zainstalować w programatorze


    A tu może dało by rade jakby .hex'a dodał do załącznika. Ponieważ jestem Bascom'owcem i mam problemy z C.

  • #8 16 Sie 2012 18:34
    szulat
    Poziom 23  

    maniek1818 napisał:
    szulat napisał:
    Nie wiem kto go napisał ale TPI już było w tych źródłach USBASP które zmieniałem.

    Ech, Mea Culpa...
    na stronie autora już od roku wisi aktualizacja ze wsparciem dla TPI.

    No i już wiem kto napisał - BoskiDialer - co widać w tym wątku:
    http://www.elektroda.pl/rtvforum/topic1861848.html

    maniek1818 napisał:
    Jak należy przekompilować avrdude (w windows) z tym path'em :?:

    W windowsie nie wiem jakich narzędzi się używa, być może cygwin, najlepiej gdyby ten wątek odwiedził ktoś kto już to kompilował i nam pomógł.

    simpson777 napisał:
    Cytat:
    Potrzebujesz źródeł w wersji r1092 . . .

    Moje pytanie,gdzie to znaleźć?? Tak i jak prze kompilować.

    Te polecenia linuksowe właśnie ściągają odpowiednią wersję (używając svn) i kompilują tak że nie trzeba w nic wnikać "samo się robi" i być może nawet w na windowsie jest tak samo jeżeli się ma cygwina - nie wiem.

    simpson777 napisał:

    Cytat:
    1. Firmware USBASP z obsługą PDI:
    Źródła do ściągnięcia stąd:

    A tu może dało by rade jakby .hex'a dodał do załącznika. Ponieważ jestem Bascom'owcem i mam problemy z C.

    W sumie masz rację, taka kompilacja jest uniwersalna i przydatna dla wszystkich niezależnie od systemu więc w pierwszym poście dodałem nowy załącznik z gotowym wsadem: usbasp_pdi_atmega8_20120816.txt

  • #9 18 Sie 2012 15:31
    simpson777
    Poziom 10  

    Jest ktoś co, jest w stanie prze kompilować AVRDUDE pod Windows??

  • #10 19 Sie 2012 01:57
    phoszek
    Poziom 15  

    simpson777 napisał:
    Jest ktoś co, jest w stanie prze kompilować AVRDUDE pod Windows??


    W załączniku dodałem skompilowaną wersję avrdude. Nie testowałem go, bo nie miałem pod ręką żadnej ATxmegi, więc jak możecie to sprawdźcie czy działa. :P

  • #12 20 Sie 2012 12:37
    szulat
    Poziom 23  

    Dziękuję za kompilację na win i za poinformowanie hackaday :)

  • #13 30 Sie 2012 23:11
    simpson777
    Poziom 10  

    phoszek pobrałem twój plik i nie wiem czy tak powinno być ale w liście procesorów nie ma żadnego z xmegi. Używam Burn-O-Mat v2

  • #14 30 Sie 2012 23:39
    phoszek
    Poziom 15  

    Niestety zmartwię Cię, ale jesteś zmuszony używać avrdude z poziomu linii poleceń, bo Burn-O-Mat nie wspiera mikrokontrolerów ATxmega. W pierwszym poście tego tematu masz przykład użycia:

    Cytat:
    avrdude -C avrdude.conf -c usbasp -p x16a4 -U flash:w:../../../xmega/xmegatest.hex -E noreset

    Listę obsługiwanych uC możesz wyświetlić wpisując samo:
    Code:
    avrdude -C avrdude.conf -c usbasp

  • #15 11 Lis 2012 01:47
    Frenzel
    Poziom 12  

    Chodzi wam wersja avrdude po win podana przez "phoszek" ? bo mi niestety nie ;/

  • #16 27 Lis 2012 15:49
    jacynka84
    Poziom 26  

    Czy ten prog sprawia jakieś problemy przy odpalaniu xmeg?
    Czy mogę prosić o najnowszy hex pod AVR Studio dla tego proga, czy to ten od phoszek?

  • #17 21 Sty 2013 21:19
    Zajc3w
    Poziom 13  

    Wsad nie działa na buforowanych USBASP-ach. Brakuje sygnału sterującego buforem.
    Nie działa z xmega 128a4 - sygnature czyta jako 0x86f1e0
    a to wywala przy odzczycie:

    Code:

    AVRdude -s -c usbasp -p x128a4 -F -U "application:r:D:\AVR_Projekty\balancer\FIRMWARE\BALANCER\Debug\BALANCER.hex:i"

    avrdude.exe: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.01s

    avrdude.exe: Device signature = 0x86f1e0
    avrdude.exe: Expected signature for ATxmega128A4 is 1E 97 46
    avrdude.exe: NOTE: Programmer supports page erase for Xmega devices.
                 Each page will be erased before programming it, but no chip erase is performed.
                 To disable page erases, specify the -D option; for a chip-erase, use the -e option.
    avrdude.exe: reading application memory:

    Reading | avrdude.exe: paged_load failed
    ##

  • #18 20 Lut 2013 00:18
    Arek1990
    Poziom 9  

    Mam mały problem z obsługą PDI, mianowicie za każdym razem mam inna sygnaturę urządzenia, a po próbie dołożenia 100nF na zasilanie dostaje tylko
    avrdude: initialization failed, rc=-1
    Jakieś propozycje?

  • #19 21 Lut 2013 01:58
    szulat
    Poziom 23  

    działanie tej "przystawki" PDI może zależeć od różnych nieprzewidywalnych okoliczności, np. od tego co w jakim czasie się dzieje na szynie USB (bo atmega obsługuje to programowo) i od tego czy xmega polubi zastosowany interfejs zamieniający 5v na 3,3v.

    skoro dodanie kondensatora zmienia wynik to sugeruje że coś jest nie tak na poziomie "elektrycznym"!

    czyli może warto przyjrzeć się czy na pewno wszystko połączone zgodnie ze schematem (dla normalnego usbasp wersja 5v z 2 diodami i 4 rezystorami) i czy procesor ma dobre zasilanie 3,3v? (u mnie jak widać na zdjęciu akurat kondensator był, a nawet dwa, 100n i parę uF, chociaż to pewnie najmniej ważne)

    poza tym to tylko usbasp i najmniej problemów miewa przy bezpośrednim połeczeniu do komputera (a nie przez hub lub długi przedłużacz)

    od czasu publikacji ujawniło się tylko (lub aż :D) kilka osób, które zbudowały interfejs u siebie i testowały go na modelach xmegi innych niż mój, mniej więcej w połowie przypadków skończyło się to sukcesem a w połowie porażką - i przy tak małym zainteresowaniu pewnie nigdy nie dowiemy się czy przyczyna była po stronie programu/projektu czy jego konstrukcji przez kogośtam, bo wiadomo że typowy użytkownik nie będzie chciał albo umiał bawić się w debugowanie procesu programowania na oscyloskopie żeby znaleźć przyczynę.

    najlepsze są proste porównania: używam tego samego układu i jeden procesor działa a drugi nie - wniosek: problem po stronie układu lub programu.
    albo: używam tego samego układu na dwóch kompach, na jednym działa na drugim nie - wniosek: oczywisty.
    niestety jeżeli komuś nie działa nic bo ma tylko jeden przypadek do testowania to niewiele można poradzić...

    ostatnio odkrytą ciekawostką był fakt że u jednego użytkownika ten sam układ nie działa w linuksie 64bit a na 32bit działa. jeszcze nie sprawdziłem tego u siebie, może u mnie też tak będzie i uda się coś naprawić.

  • #20 21 Lut 2013 16:19
    pryanick
    Poziom 9  

    Hi fellows!
    Hope Your all ok here!
    I've got a question: is there a firmware hex-file for USBASP (atmega8) for ATXMEGAxxx burning? Please, upload it here, I upgrade my USBASP...
    May be I need some extra files to upgrade AVRDUDE?
    I use AVRDUDE 3.2 with windows interface.
    I appreciate it!!!
    Thanks!
    /Serg

  • #21 21 Lut 2013 21:43
    lg2000
    Poziom 12  

    pryanick napisał:
    Hi fellows!
    Hope Your all ok here!
    I've got a question: is there a firmware hex-file for USBASP (atmega8) for ATXMEGAxxx burning? Please, upload it here, I upgrade my USBASP...
    May be I need some extra files to upgrade AVRDUDE?
    I use AVRDUDE 3.2 with windows interface.
    I appreciate it!!!
    Thanks!
    /Serg
    Firmware is in usbasp_pdi_atmega8_20120816.txt file. You must change extension for .hex

  • #22 22 Lut 2013 17:40
    pryanick
    Poziom 9  

    lg2000, thanks for replay!
    The only thing I have to do is change extension and update my USBASP Mega8 firmware with new hex file.
    No need to make changes in AVRDUDE or somewhere else?

  • #23 22 Lut 2013 19:22
    percol
    Poziom 11  

    Cześć,
    U mnie działa na Xmega16d4 bez żadnych problemów, za to na Xmega64a1 nie mogę zaflashować kontrolera. Z terminala idzie zmienić tylko fusy, eeprom i flash odpada (usersig, boot, app, apptable itp). Z linii komend da się zaprogramować eeprom ale już flash nie - nie wiedzieć czemu. Rzucam informację zwrotną od avrdude:

    Cytat:
    avrdude -p x64a1 -c usbasp -E noreset -U flash:w:test.hex

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.02s

    avrdude: Device signature = 0x1e964e
    avrdude: NOTE: Programmer supports page erase for Xmega devices.
    Each page will be erased before programming it, but no chip erase is performed.
    To disable page erases, specify the -D option; for a chip-erase, use the -e option.
    avrdude: reading input file "test.hex"
    avrdude: input file test.hex auto detected as Intel Hex
    avrdude: writing flash (604 bytes):

    Writing | ################################################## | 100% 0.46s

    avrdude: 604 bytes of flash written
    avrdude: verifying flash memory against test.hex:
    avrdude: load data flash data from input file test.hex:
    avrdude: input file test.hex auto detected as Intel Hex
    avrdude: input file test.hex contains 604 bytes
    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 0.54s

    avrdude: verifying ...
    avrdude: verification error, first mismatch at byte 0x0000
    0xff != 0x0c
    avrdude: verification error; content mismatch

    avrdude done. Thank you.


    Ten test.hex to jakiś durny program w stylu:
    main(){ while(1); }
    Zresztą ambitniejszy też nie wchodził (niecałe 4kB żywej wagi). EEPROM idzie (testowałem rozmiary 2kB i 512B), chip erase działa (bo czyści zapisany eeprom), ale fleshu nie chce zaprogramować (czy 3,8kB czy te cytowane 600B, po prostu nic), niech by nawet błędnie!
    Wszystko kompilowane w Winavr20101001 a hex wrzucany pod SuSe 12.2 z pełnymi poprawkami. Avrdude z załącznika jak i reszta softu (w tym firmware). Ale przecież to nie w tym rzecz, moim zdaniem jest coś nie tak z firmware, może trzeba dać niewielką zwłokę po zapisaniu każdej strony albo większą pauzę po chip erase? Nie wiem.

    Od razu uprzedzę, że siedziałem nad tym cały dzień i podobne problemy zdarzały się gdy napięcie zasilające układ było za niskie lub niestabilne - u mnie to odpada, zasilam i stabilizuję z porządnego zasilacza. Przy okazji sprawdzałem czy nie fluktuuje podczas programowania - nie, jest stabilne z dokładnością do pojedynczych mV. Próbowałem nawet z podjazdem na zasilaniu do 3,65V (kontroler znosi i działa ale nadal nie flashuje - zwraca ten sam błąd). Wpisy w avrdude.conf i firmware (tzn. xmega_pdi.h) też są poprawne, głębiej się nie zapuszczałem.
    Acha, z opcją -e też próbowałem (chip erase) ale avrdude dalej pada na tym samym (chip erase nie powinno tu mieć znaczenia). Zawartość flasha to cały czas 0xFF = dziewicza, niezła zagwozdka... ;-(

    Co do projektu proponuję dodać stabilizator do usbasp, tak by można było ustawić zasilanie pod kątem programowanego układu (wtedy obowiązuje prostszy wariant "przejściówki"). U siebie dałem stabilizator regulowany LDO na 3V z opcją "w górę" (potencjometr precyzyjny), dzięki czemu programator można użyć do układów 3...5V, a nawet odblokować uC gdyby przez pomyłkę ustawiono BOD level zbyt wysoko zaś zasilanie kontrolera było zbyt niskie (jak mi się to na początku przydarzyło;) ).

    Pozdrawiam


    =========================================================

    Dodano po 21 [minuty]:

    pryanick napisał:
    lg2000, thanks for replay!
    The only thing I have to do is change extension and update my USBASP Mega8 firmware with new hex file.
    No need to make changes in AVRDUDE or somewhere else?


    If google translate cannot produce understandable output for You then You have to do these steps:

    1. Take sources of the USBASP available here: http://www.fischl.de/usbasp/usbasp.2011-05-28.tar.gz
    and download install patch "usbasp-pdi-usbaspfirmware-20120816.txt" - available above in the first post (You have to change extension *.txt to *.diff)
    And then do:
    Cytat:

    tar xvzf usbasp.2011-05-28.tar.gz
    cd usbasp.2011-05-28/firmware
    patch <full/path/of/usbasp-pdi-usbaspfirmware-20120816.diff
    make main.hex


    When main.hex is ready then flash Your USBASP programmer and use just compiled main.hex file.

    2. Now prepare modified avrdude, follow this way:

    Get r1092 version of avrdude and the patch "usbasp-pdi-avrdude2091-20120816.txt" (do not forget change extension from *.txt to *.diff). To obtain avrdude r1092 use svn like this:
    Cytat:


    then do exactly:

    Cytat:

    cd trunk/avrdude
    patch <full/path/of/usbasp-pdi-avrdude2091-20120816.diff
    ./bootstrap
    ./configure
    make


    If there will be no compilation errors just install it (invoke: "make install") and enjoy.

    Good luck!


    Aaaaargh, I missed You use MS Windows environment! Damn what I described here is correct for Linux users but, I hope, compiling (f.e. free Watcom compiler) proper (patched) version of avrdude (r1092) should let You be a happy user of USBASP with PDI support... ;-)
    If it is possible do not forget download Your MS-Windows version here.

    Another tip: maybe Cygwin will be better choice for You if You will have too many problems compiling avrdude in Microsoft environment...

  • #24 24 Lut 2013 21:28
    lg2000
    Poziom 12  

    pryanick napisał:
    lg2000, thanks for replay!
    The only thing I have to do is change extension and update my USBASP Mega8 firmware with new hex file.
    No need to make changes in AVRDUDE or somewhere else?
    You still need to patch avrdude r1092 version with usbasp-pdi-avrdude2091-20120816.txt patch. User phoszek attached compiled version avrdude Link without any warranty.

  • #25 25 Lut 2013 06:59
    percol
    Poziom 11  

    Cytat:
    User phoszek attached compiled version avrdude Link without any warranty.


    This version doesn't work properly with my Win7 system (tested with drivers based on both libusb ver. 0.1 and 1.1). If I remember well, avrdude doesn't see the programmer at all or cannot communicate with a device (tested on Xmega16d4 and 64A1). In Linux system any problems disappear. :-)

  • #26 25 Lut 2013 19:03
    lg2000
    Poziom 12  

    percol napisał:
    This version doesn't work properly with my Win7 system (tested with drivers based on both libusb ver. 0.1 and 1.1). If I remember well, avrdude doesn't see the programmer at all or cannot communicate with a device (tested on Xmega16d4 and 64A1). In Linux system any problems disappear. :-)
    If your win7 is 64bit you should read this .

  • #27 26 Lut 2013 20:14
    pryanick
    Poziom 9  

    I tried today compiled version avrdude with USBASP prommer with this schematic
    http://obrazki.elektroda.pl/2407137700_1345075790.png
    and no luck.
    I use windows version program, its not a command line interface. I replaced two files avrdude.conf and avrdude.exe but nothing - i can not choose any ATxmega, the list of supported AVR's still the same.
    So I supposed to make it in command line mode?
    I use winxp32bit sp3.

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