AVRy - ISP Prog i jego protokół... Ja

Hej!!

Tak sobie grzebię ostatnio z ARMami i AVRami, gdyż potrzebuję za pomocą ARMa programować AVRa ;)... I postanowiłem, że w przejściowej wersji zrobię sobie programator podłączany do kompa. Widziałem mnóstwo opisów do standardowego ISPProg'a obsługiwanego przez AVR Studio, więc zacząłem działać :)... protokół niby prosty, ale jednak coś nie halo :/... AVRProg mojego układu nie wykrywa, chociaż zaimplementowałem chyba wszystkie możliwe komendy!! Zacząłem sprawdzać różne ustawienia portu COM (choć powinno być 115200 8n1 podobno). Nic :/... Więc połączyłem ze sobą 2 COMy i zobaczyłem, co tam AVRStudio wysyła na moją płytkę... i oto dostałem takie coś:

1B 01 00 01 0E 01 14 1B 02 00 01 0E 01 17 30 20 30 20 30 20 30 20 .... (potem powtarza się w kółko 30 20 kilkadziesiąt razy).

Problem jest taki, że ŻADEN z tych kodów nie należy do listy instrukcji!! Domyślnie aplikacja powinna odpowiadać na niego znakiem '?'!! Moj program tak robi, ale to nic nie daje :/...

Podejrzenie padło na jednak inne ustawienie prędkości, ale proszę, znalazłem Device Monitoring Studio, odpaliłem, i w raportach widać wyraźnie, że AVRStudio ustawia takie parametry:

. 000002: Create Request (DOWN), 24.07.2008 17:37:19.718 +8.359 Process 0xcd8 (AVRStudio.exe) attempted to open the device 000003: Create Request (UP), 24.07.2008 17:37:19.718 +0.0 Process 0xcd8 (AVRStudio.exe) create request status: 0x00000000

(...)

000022: I/O Request (DOWN), 24.07.2008 17:37:19.718 +0.0 IOCTL_SERIAL_SET_BAUD_RATE: Set baud rate Baud Rate=115200

000023: I/O Request (UP), 24.07.2008 17:37:19.718 +0.0 IOCTL_SERIAL_SET_BAUD_RATE: Set baud rate

(...)

000028: I/O Request (DOWN), 24.07.2008 17:37:19.718 +0.0 IOCTL_SERIAL_SET_LINE_CONTROL: Set line control WordLength=8 StopBits=1 stop bit Parity=No parity

Niestety, nie mam teraz pod ręką działającego programatora, żeby zobaczyć, jak one ze sobą gadają i co sobie nawzajem wysyłają. Ale może ktoś da radę mi pomóc? To chyba popularnie używany protokół przy używaniu np. bootloader'a w AVRach :)...

Dodatkowo przesyłam listę instrukcji z jakiegoś programatora wykorzystującego ten protokół (szerokość wiersza > 70 znaków!!)

Pozdrawiam Konop

;* Commands | Host writes | Host reads ;* | ID (hex ) | data | data |

;* | Enter programming mode | 'P'(0x50) | | | 13d ;* | Report autoincrement address | 'a'(0x61) | | | 'Y' ;* | Set address | 'A'(0x41) | ah al | | 13d ;* | Write program memory, low byte | 'c'(0x63) | dd | | 13d ;* | Write program memory, high byte | 'C'(0x43) | dd | | 13d ;* | Issue Page Write | 'm'(0x6d) | | | 13d ;* | Read program memory | 'R'(0x52) | | dd(dd)| ;* | Write data memory | 'D'(0x44) | dd | |

13d ;* | Read data memory | 'd'(0x64) | | dd | ;* | Chip erase | 'e'(0x65) | | | 13d ;* | Write lock bits | 'l'(0x6c) | dd | | 13d ;* | Leave programming mode | 'L'(0x4c) | | | 13d ;* | Select device type | 'T'(0x54) | dd | | 13d ;* | Read signature bytes | 's'(0x73) | | 3*dd | ;* | Return supported device codes | 't'(0x74) | | n*dd | 00d ;* | Return software identifier | 'S'(0x53) | | s[7] | ;* | Return sofware version | 'V'(0x56) | | dd dd | ;* | Return hardware version | 'v'(0x76) | | dd dd | ;* | Return programmer type | 'p'(0x70) | | dd | ;* | Set LED | 'x'(0x78) | dd | | 13d ;* | Clear LED | 'y'(0x79) | dd | | 13d ;* | Universial command | ':'(0x3a) | 3*dd | dd | 13d ;* | New universal command | '.'(0x2E) | 4*dd | dd | 13d

;* | New Commands since Version 3.3 | | | | ;* | Exit (AVR109, Bootloader) | 'E'(0x45) | | |

13d ;* | Return Chip ID (Terminalmode only)| 'i'(0x69) | | s[n] |

;* | New Commands since Version 3.5 | | | | ;* | Implemented Atmel Bootloader commands (Atmel Appl. Note 109) |

;* | Report Block write Mode | 'b'(0x62) | |'Y'2*nn| 13d ;* | Block Write | 'B'(0x42) |2*nn'M'| n*dd | 13d ;* | Block Read | 'g'(0x67) |2*nn'M'| n*dd | 13d

;* | Commands to test (fully implemented since V3.8, Unverified) |

;* | Return Lockbits | 'r'(0x72) | | dd | 13d ;* | Return High Fusebits | 'N'(0x4E) | | dd | 13d ;* | Return extendet Fusebits | 'Q'(0x51) | | dd | 13d ;* | Write fuse bits (reserved) | 'f'(0x66) | dd | | 13d ;* | Read fuse and lock bits (reserved)| 'F'(0x46) | | dd |

Dodatkowo na samym początku jest czekanie na znak 1B (albo na znak rozny od 1B).

Reply to
Konop
Loading thread data ...

"Konop" snipped-for-privacy@gazeta.pl schrieb im Newsbeitrag news:g6aohb$p2c$ snipped-for-privacy@inews.gazeta.pl...

Masz na mysli programowanie szeregowe 3-wire? Ale to chyba leci po SPI - synchronicznie (z dedykowana linia zegarowa) - aplikacja "recznie" steruje liniami COMa (albo - jak w programatorze AVRISP, portu rownoleglego) i standardowe timingi COM nie mają zastosowania? GRG

Reply to
grg12

Konop pisze:

Ale po co tak sobie utrudniać życie?

Podłącz AVRa do portu drukarkowego (np. kabelkiem STK200/300) i steruj ze swojego programu na pececie bezpośrednio pinami portu LPT. Jak dojdziesz do pełni szczęścia, będzie łatwo przenieść cały soft na ARMa, zmieniając tylko sterowanie poszczególnymi liniami idącymi do AVRa.

Protokół programowania szeregowego (ISP) jest opisany w PDFie każdego AVRa. Na początek możesz wyciągnąć podstawowe sprawy z kodu źródłowego darmowych programatorów takich jak avrdude czy PonyProg (ja jak zaczynałem dawno temu ISP Programmer'a nie miałem tak łatwo i musiałem krok po kroku analizować PDFa).

Ja w firmie z ARMa programuję ATmegi 128 i 2561 ale po JTAG'u - niby podobnie jak przez ISP bo też szeregowo ale dużo więcej zamieszanych komend się wydaje AVRowi. To też jest w jakimś PDFie Atmela opisane (nie w PDFach samych procesorów).

Reply to
Adam Dybkowski

grg12 pisze:

Tak, to leci po SPI, a z kompa wychodzi po COMie ;).. i po to się w środku daje procesor, żeby to przetłumaczył ;)..

Pozdrawiam Konop

Reply to
Konop

Adam Dybkowski pisze:

No aż tak na piechotę się bawić nie chcę, w końcu to prawie standardowa magistrali SPI, więc nie zamierzam sterować liniami MISO, MOSI i SCK "ręcznie" :) Dlatego też lepsze wydają mi się komendy w tylu 'e' - Chip Erase, 'R' - Read Porgram Memory itp ;)... poza tym, to ma być taka "inwestycja na przyszłość" - chodzi o budowanie w przyszłości układów z BootLoader'em (a tu zawsze lepiej zastosować COMa albo nawet COMa na USB). Pomijając fakt, że przez RSa programowanie idzie jak burza, a przez LPT - jak żółw (przynajmniej w Windzie).... Dlatego chcę rozgryźć ten protokół, co (teoretycznie) nie powinno być trudne ;).. Przykładowe rozwiązanie znajduje się tu:

formatting link
. Jak chcesz - znajdź sobie w kodzie etykietę waitcmd: - łatwo się połapać, że dalej następuje wybór algorytmu działania w zależności od odebranego znaku... coś jak switch case w C :)...

Pozdrawiam Konop

Reply to
Konop

Konop pisze:

Ale to tylko na początek gdy będziesz miał program na pececie. Docelowo programowanie przecież będzie wykonywał ARM. W moim zastosowaniu ARM programuje AVRa jak burza (najpierw cały plik jest przesyłany przez USB z peceta XModemem do RAMu ARMa a potem samo programowanie przez JTAG ARM->AVR idzie momentalnie).

Jeżeli chcesz się podpiąć pod AVR Studio (albo je udawać), poczytaj o protokole STK500v2, jest do tego PDF i dokładny opis (AVR068.pdf i AVR069.pdf). Gotowy soft na AVRa gadający z AVR Studio tym protokołem (programator AVRów na USB) istnieje np. w postaci projektu avrusb500v2:

formatting link

Reply to
Adam Dybkowski

Lepiej zrob tak jak ci radzi Adam i podepnij to przez LPT zonglujac liniami recznie. Gadanie z AVRem wymaga na poczatku odpowiedniej synchronizaji, zeby go wprowadzic w tryb programowania szeregowego. Potem juz idzie latwiej. Ja zrobilem cos takiego, ze programuje AVRa po USB wykorzystujac manglowanie liniami FTDI232R, na mojej stronie znajdziesz gotowy kod w C++. Wlasnie rozpoczecie programowania i zmuszenie procka do wejscia w odpowiedni tryby to cala sztuka, potem z gorki. Stad nie licz, ze przeniesiony program z jakiegos innego wiekszego tak po prostu ci zadziala.

Reply to
T.M.F.

T.M.F. pisze:

Jeżeli chodzi o FTDI to jeszcze fajniejszym pomysłem jest użycie układu FT2232. Może on pracować jako [de]serializer i robić za konwerter USB-SPI. Sprawdzone doświadczalnie. API jest dobrze opisane w PDFach (trzeba użyć bibliotekę D2XX a dokładnie MPSSE).

Reply to
Adam Dybkowski

Dzięki za oświecenie!!!! Nie przyszło mi do glowy, że AVRISP != AVRPROG :P... I wchodziłem nie w tą opcję, co trzeba ;)... no to jak widać z protokołem STK500 już się zapoznałem ;P... te rozkazy o dziwnych kodach to właśnie to ;)... znalazłem opcję AVR Prog i komunikacja zadziałała ;)... problem jest z zapisem ;)... ale czytam proca dobrze :)... popracuję nad tym :)... W tym urządzeniu, które teraz robię, nie będę korzystać z pomocy AVR Studio, chcę po prostu poznać algorytm programowania ;).. Ale tak na przyszłość - czemu polecasz STK500 bardziej niż tego AVR Proga ?? :)... Jakiś czas temu gdy szukałem tych informacji o programatorze, to właśnie stwierdziłem, że niewiele jest klonów STK500 (a jak są - działają na zaszyfrowanym sofcie od Atmela). Ten linkt który mi przysłałeś, to wówczas był jedyny klon działający na tym protokole :)... reszta chodziła na AVRProgu ;)... Coś w tym musi być?? :)...

Pozdrawiam Konop

Reply to
Konop

Może trochę w złym miejscu odpowiadam ale takie mnie naszły myśli więc coś podpowiem :)... Zobacz w źródła usbasp

formatting link
- tam jest moduł (isp.c/isp.h) który gada z avr przez ISP więc wystarczyło by tylko trochę go przerobić. A jak jesteś zainteresowany implementacją proto. avr910 to wpisz w google "avr910.c" i dostaniesz źródła od avrdude'a gdzie też możesz podejrzeć :)

Reply to
saper/nolin11

Konop pisze:

Ale pomyśl już przed narobieniem się nad rozwiązaniem docelowym, które Cię czeka - czyli o ile dobrze zrozumiałem chcesz ARMem zaprogramować AVRa. A wtedy zrozumienie algorytmu programowania ISP, JTAG albo równoległego Cię nie ominie bo pinami ARMa będziesz (pewnie przez jakiś bufor) musiał zaprogramować AVRa. Bez żadnych "pomocników" dołączanych zwykle do peceta (a'la STK500). W praktyce wystarczy między AVRem a ARMem pociągnąć interfejs SPI (bez chipselectu) i dodatkowo sterować resetem AVRa.

Reply to
Adam Dybkowski

Właśnie z tego względu buduję AVR Proga!! :)... Popatrz - jest to programator prosty (tak się przynajmniej wydaje - odbiera jeden znak po RSie i wysyla cos po SPI), dostępne są przykładowe rozwiązania (także od Atmela, więc raczej dobre) i daje mi w ten sposób szerokie możliwości :).. najpierw, napiszę sobie AVR Proga, korzysyając z pomocy "gotowców", jak to zadziała, będę mieć 100% pewności, że komunikacja z AVRem działa poprawnie, że znam wszystkie komendy potrzebne do zaprogramowania AVRa itp ;).. Następnie przyjrzę się uważnie komendom wysyłanym przez program po RSie i poznam algorytm programowania :)... . Do tego mogę wykorzystać albo "podsłuchiwacze" RSa, albo ARMowi kazać logować wszystko, co dostaje po RSie (w przypadku mojej procedury obsługi UARTa będzie to kwestia zmiany wielkości bufora ;P)... i tyle :)... a czemu AVR Prog?? :).. bo tak ;)... jakoś tak wybór padł na niego, można to uzasdnić tym, że ma "przyjazne" komendy - w postaci znaków ASCII z zakresu liter, czyli miło i łatwo się to analizuje ;)... np R jest od czytania, e to erase, D i d odnoszą się do pamięci EEPROM (DATA ;)) itp :)... poza tym

- planowalem napisac programator właśnie wykorzystujący ten protokół, więc będę mieć gotowy kod tylko do przeniesienia na AVRa ;)..

Pozdrawiam Konop

Reply to
Konop

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.