Porównanie prędkości programowania flash i EEPROM w emulatorze STK500v2 z Allegro

Od jakiegoś czasu używam programatorka z USB zakupionego na allegro.
Emuluje on STK500v2. Flash AVR-ka programuje się błyskawicznie, ale
eeprom koszmarnie wolno. Przykładowo 20kB flasha - 6,2s a jedyne 418
bajtów eepromu ponad 40 sekund !!!. Czy to "urok" wszystkich STK500 czy
tylko tego jednego ? Sklecone na szybko usbasp programuje bez porównania
szybciej.

W dniu 2010-02-28 22:39, Grzegorz Kurczyk pisze:

Od jakiegoś czasu używam programatorka z USB zakupionego na allegro.
Emuluje on STK500v2. Flash AVR-ka programuje się błyskawicznie, ale
eeprom koszmarnie wolno. Przykładowo 20kB flasha - 6,2s a jedyne 418
bajtów eepromu ponad 40 sekund !!!. Czy to "urok" wszystkich STK500 czy
tylko tego jednego ? Sklecone na szybko usbasp programuje bez porównania
szybciej.

Powinno być znacznie szybciej. Poszukaj w archiwum grupy, w zeszłym roku
był wątek o wydajności programowania AVRów różnymi programatorami.
Wyszło na to, że im nowszy wynalazek Atmela tym szybszy - wygrały wtedy
chyba AVR One oraz ISP mkII.

Sprawdź przy okazji, co masz w środku programatora. Jeżeli popierdułkę w
rodzaju USB obsługiwanego programowo przez AVRa (z prędkością LowSpeed
czyli 1,5Mbps) to nic dziwnego. Ja mam klona gadającego jak STK500v2 ale
na pokładzie jest układ FT232 i śmiga na 12Mbps. Ale to i tak wolno w
miarę działa (w stosunku do wydajności programowania ograniczanej przez
sam programowany AVRek) ze względu na algorytm STK500v2, zakładający
m.in. komunikację z pecetem na 115200 bps przez "wirtualny" COM oraz
mały bufor programowania (częste małe paczki danych i potwierdzenia do
przesyłania z/do peceta).

Emuluje on STK500v2. Flash AVR-ka programuje się błyskawicznie, ale
eeprom koszmarnie wolno. Przykładowo 20kB flasha - 6,2s a jedyne 418
bajtów eepromu ponad 40 sekund !!!.

Jeśli chodzi o programowanie EEPROM z poziomu nowszych AVR Studio
to niestety tak będzie. Trochę szybciej (tak gdzieś z 50%) będzie z
poziomu AVR DUDE.
Po prostu Atmel w swoim środowisku stosuje z zapasem zalecane
odstępy czasowe (Twd_eeprom) między kolejnymi bajtami podczas zapisu
do pamięci EEPROM.
To że USBASP zakaszania podczas zapisu do eeprom-u wynika tylko z
niefrasobliwości
twórców oprogramowania obsługującego ten standard.

Autopoprawka.
Odpowiadam sam sobie
Problem dotyczy systemu Linux. Pod WinXP jest ok. Podejrzewam kwestię
konfiguracji /dev/ttyUSB0

Miło wiedzieć. Też mam ten USBowy programator firmy SIBIT i żadnych
problemów (pod WinXP). Czy nowy firmware coś zmienia szczególnego?

Niestety pod Linuxem nadal to samo. Coś musi być z obsługą FTDI pod
linuxem. Nie wgrywałem żadnych specjalnych sterowników. Linux
(Ubuntu9.10) sam wykrył programator jako /dev/ttyUSB0 i tak ustawiłem
avrdude. Ruszyło od pierwszego kopa, ale właśnie z taką niespodzianką.
Coś mi się wydaje, że problem jest związany z buforowaniem w FTDI.
Podczas programowania eepromu lecą krótkie paczki (programowanie bajt po
bajcie). Przy programowaniu flascha lecą całe strony i bufor FTDI szybko
się zapełnia i dane szybko pojawiają się po stronie RS-a.

W sterowniku dla Windows jest okienko ustawień zaawansowanych, gdzie
można m.in. zmniejszyć czas oczekiwania przed wysłaniem danych (gdy
bufor nie jest zapełniony, standardowo 16ms a minimalnie 1ms). Może masz
gdzieś też upchnięte podobne ustawienia w Linuxie, albo można jest
ustawić niestandardowym ioctl'em? Wtedy nie problem dodać to nawet w
źródłach avrdude.

Choroba, pod Linuxem w og le jako dziwnie dzia a obs uga port w
szeregowych. Nawet na RS-ie czysto sprz towym (normalny COM1 wbudowany w
p yt ) ma taki dziwny efekt przy wysy aniu kr tkich paczek po kilka
bajt w. Przyk adowo kawa ek kodu w C.

int handle = 0;
handle = open("/dev/ttyS0", O_RDWR);
for(int i = 1000; i; i--) {
        write(handle, "abcd", 4);
        tcdrain(handle); // czeka na opr nienie bufora nadajnika}

close(handle);

daje mi taki efekt, e wysy ane s paczki po cztery bajty, a mi dzy nimi
jest 20ms przerwy !!!

Uzywasz kernela 2.4? W 2.6 "tick" jest 10x krotszy (10ms->1ms). Nie
znam implementacji tcdrain ale prawdopodobnie nie czeka ona na
zakonczenie transmisji w petli, a oddaje CPU schedulerowi.

Zamiast tcdrain sprobuj uzyc (nie sprawdzalem w praktyce):

do {
ioctl(handle, TIOCSERGETLSR,&lsr);
} while (lsr& TIOCSER_TEMT);

Wygląda niby dobrze, ale na oscyloskopie widzę niekiedy taką sytuację,
że RTS przeszło na moment w stan aktywny (ok 20..30us), a nie poszedł
żaden bajt. Po południu sprawdzę czy ta "ramka" jest gubiona czy
faktycznie wychodzi z następnym aktywnym RTS.

Jajko z serii 2.6.

Potrzebne mi to jest m.inn. do wysyłania danych przez bufor RS485
sterowany sygnałem RTS.

W efekcie końcowym wyszło coś takiego:
[...]
Wygląda niby dobrze, ale na oscyloskopie widzę niekiedy taką sytuację,
że RTS przeszło na moment w stan aktywny (ok 20..30us), a nie poszedł
żaden bajt. Po południu sprawdzę czy ta "ramka" jest gubiona czy
faktycznie wychodzi z następnym aktywnym RTS.