Programowanie AVRów przez ARMa z użyciem ISPProg jak rozwiązać problem z protokołem?

Thu Jul 24, 2008 9:26 pm   

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).

Thu Jul 24, 2008 9:46 pm   

"Konop" <konoppo@gazeta.pl> schrieb im Newsbeitrag
news:g6aohb$p2c$1@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

Thu Jul 24, 2008 9:58 pm   

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).

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Thu Jul 24, 2008 10:03 pm   

grg12 pisze:

środku daje procesor, żeby to przetłumaczył ..

Pozdrawiam
Konop

Thu Jul 24, 2008 10:12 pm   

Adam Dybkowski pisze:

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: http://radzio.dxp.pl/avr910.htm . 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

Thu Jul 24, 2008 10:21 pm   

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:
http://tuxgraphics.org/electronics/200705/article07052.shtml

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Fri Jul 25, 2008 12:12 am   

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.

--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

Fri Jul 25, 2008 12:57 am   

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).

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Fri Jul 25, 2008 4:35 pm   

Dzięki za oświecenie!!!! Nie przyszło mi do glowy, że AVRISP != AVRPROG
... 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

Fri Jul 25, 2008 4:42 pm   

Adam Dybkowski wrote:

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 (http://www.fischl.de/usbasp/) - 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ć :)

--
Saper/nolin11
mailto:nolin11_USUN_TO@interia.pl
gg:4476700

Fri Jul 25, 2008 9:27 pm   

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.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Sat Jul 26, 2008 12:45 am   

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