Powolność programatora STK500v2

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

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

Użytkownik Adam Dybkowski napisał:

Właśnie mam wręcz przeciwnie i to mnie dziwi. Popierdułka sklecona na szybko z programowym USB (usbasp na ATmega8) popindala jak mały samochodzik, a klon z FT232 tak się ślimaczy ale tylko przy programowaniu eepromu. Programatorek to AVR PROG z firmy SIBIT. Teraz patrzę, że jest nowy firmware. Spróbuję zaaplikować i zobaczymy :-)

Pozdrawiam Grzegorz

A sprawdzales czy to kazy bajt dlugo, czy czeka 39s, i dopiero zaczyna programowac ? Ewentualnie odwrotnie - programuje w sekunde, a potem czeka.

Moze byc jakis problem z emulacja przerwan ..

J.

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

Pozdrawiam Grzegorz

W dniu 2010-03-02 10:03, Grzegorz Kurczyk pisze:

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

Użytkownik Adam Dybkowski napisał:

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.

Pozdrawiam Grzegorz

W dniu 2010-03-02 23:49, Grzegorz Kurczyk pisze:

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.

W dniu 04.03.2010 00:44, Adam Dybkowski pisze:

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 !!! Poszperałem na góglu, ale znalazłem tylko ludzi mających podobny problem (choć ta zwłoka nie była aż tak duża). Pierwszy raz robię obsługę RS-a pod linuxem i trochę mnie to zmartwiło. Znają Koledzy może jakiś parametr (coś w stylu timeouta), który zmniejszałby tę zwłokę? Dziwne to trochę, bo o ile rozumiem zwłokę w wysyłaniu w przypadku gdy FIFO nie jest jeszcze zapełnione (choć nadajnik powinien rozpocząć nadawanie z chwilą pojawienia się pierwszego bajtu w buforze), to w przypadku wymuszenia nadawania trochę to bez sensu.

Pozdrawiam Grzegorz