FT232BM i synchroniczny bit bang.

Sat, 11 Feb 2006 11:03:46 +0100, na pl.misc.elektronika, T.M.F. napisał(a):

Cześć

BM ma tylko zwykły bit-bang : wysyłanie z szybkością ustawianą baudratem ( FT_write) ,odczyt wejść ( sample pobierane z prędkośćią jw. FT_read) oraz niezależny jednokrotny odczyt wejść (FT_GetBitMode). Oni to nazwali trybem asynchronicznym ( chociaż nie bardzo intuicyjnie ). Nazwa tryb synchroniczny została zarezerwowana dla odczytu stanu wejść synchronicznego z ustawieniem wyjść ( czyli przy wysyłaniu FT_write bufor odbiorczy jest ładowany synchronicznie pobranymi samplami, które następnie można odczytać FT_read ) - wersje BM tego nie mają.

Tyle zrozumiałem z opisów ( 232R dopiero właśnie uruchamiam ).

Dzieki za pomoc. Pdfy umieszczaja wersje BM jako second generation i roznie to wyglada, z czesci pdfow mozna odniesc wrazenie, ze tryb synchroniczny dziala na BM. No ale wlasnie moje obserwacje tego nie potwierdzily:) Po wyslaniu tego kodu uklad go kompletnie ignoruje. Teraz juz wiem dlaczego:) Mam jeszcze takie pytanie odnosnie funkcji FT_GetStatus. Jak rozumiem ona podaje ilosc bajtow, ktore czekaja w kolejkach ukladu FT232, a nie drivera? Chodzi mi o to, ze wysylam w trybie bitbang ilestam bajtow i teraz chce zaczekac z reszta programu az te bajty pojawia sie na wyjsciu ukladu i dopiero kiedy kolejka bedzie pusta podjac dalsze akcje. I teraz robie to tak, ze cyklicznie za pomoca tej funkcji odczytuje status kolejki TX i jesli wynosi 0 to wysylam kolejna porcje. Czy robie to poprawnie, czy tez odczytuje wylacznie status bufora nadawczego drivera, a nie ukladu FT?

Sat, 11 Feb 2006 20:13:22 +0100, na pl.misc.elektronika, T.M.F. napisał(a):

IMHO dotyczy to kolejek nadawczej / odbiorczej drivera. Nie doczytałem się jaki jest ich domyślny rozmiar ( i czy można zmienić jak np. w SetupComm ), pewnie przez FT_IoCtrl - ale nie opisana. Driver sam zarządza ruchem pomiędzy buforami kostki ( które są niewielkie ) a kolejkami. Czy warto czekać na całkowite opróżnienie kolejki ? - chyba nie, ona w końcu jest właśnie po to ,żeby buforować. Raczej sprawdzać ile bajtów rzeczywiście poszło i wg tego przesuwać indeks nadawanych danych.

Tak, ale w moim zastosowaniu chodzi wlasnie o opoznienie. Chodzi o to, ze wysylam pewien ciag inicjujacy, nastepnie musze odczekac pewien czas. Myslalem, zeby zrobic to tak, ze wysylam ten ciag, poczym go powtarzam tyle razy ile mi wychodzi z przeliczenia rate i czekam az skonczy sie transmitowac. To mi zalatwia dosyc precyzyjnie opoznienie. No i kolejny problem - skoro mam tylko asynchroniczny bitbang to jak synchronizowac zapis i odczyt danych? np. nadaje ciag znakow, na to mam odpowiedz urzadzenia i chodzi teraz o synchronizacje tych faktow. Myslalem, zeby zrobic to tak:

1. nadaje ciag
2. czekam na koniec nadawiania
3. robie purge bufora Rx
4. odczytuje bufor Rx Ale gdybym mial dostep wylacznie do kolejek drivera to ten plan bierze w leb:(

Sat, 11 Feb 2006 23:10:20 +0100, na pl.misc.elektronika, T.M.F. napisał(a):

IMHO taka synchronizacja czasowa na USB i tak będzie kuleć . Kolejne polecenia aplikacji ( purge, read ) są realizowane - w najlepszym przypadku

- w kolejnych 1 ms ramkach. Dla urządzenia na zewnątrz to może być cała wieczność. Nie wiem zresztą co to ma być - może masz jakiś specjalny pomysł. Ale 232BM nie daje zbyt wielkich możliwości - praktycznie to umie nadawać ( np. ładowanie pamięci ). Do odczytu po magistrali szeregowej ( i to też tylko jako master ) potrzebny już tryb synchroniczny. Natomiast odbiornik slave na BitBangu będzie IMHO zawsze bardzo problematyczny.

Masz racje, zabralem sie do tego od zlej strony. Juz mowie o co chodzi - mam uklad

o to, ze na pokladzie jest procek do ktorego chce wgrac firmware. Moge to zrobic za pomoca uisp, ale chce to zaszyc we wlasnej aplikacji. No wiec robie ISP przez USB. No i teraz jak sie wgryzlem w to conieco to juz wiem dlaczego uisp jest taki wolny:) A co do odczytu kolejek - dostalem wlasnie info z FTDI, ze nie ma sposobu aby dowiedziec sie jaki jest stan buforow chipu FTDI, a to co zwraca FT_GetStatus to tylko stan buforow drivera.

Mon, 13 Feb 2006 12:36:12 +0100, na pl.misc.elektronika, T.M.F. napisał(a):

To może spróbuj w sposób uproszczony. Na dobrą sprawę tylko wejście w tryb programowania wymaga zwrotnej kontroli. Wtedy rzeczywiście powolutku : wysyłasz impuls SCK i sprawdzasz ( read albo getbitstatus ) co wraca na wyjściu danych kostki. Resztę komend ( fuse, ładowanie strony, zapis strony ) wysyłasz jak leci , rozdzielając tylko jakimiś rozsądnymi przerwami a z weryfikacji w ogóle rezygnujesz. Cały czas programuję atmegi bez weryfikacji - błędy zdarzają się bardzo rzadko.

Wlasnie mam problem z wejsciem w tryb programowania. Ustawiam najpierw RESET na 1, SCK=0, potem daje na >20ms RESET=), SCK=0, a nastepnie wysylam ACh,53h, ale proc cos nie chce wejsc w tryb progamowania. W zaden sposob mi nie odpowiada 53h, ciagle MISO=1. Rece juz mi opadaja bo nie wiem co jest grane.

Mon, 13 Feb 2006 20:00:10 +0100, na pl.misc.elektronika, T.M.F. napisał(a):

A nie wpychasz za szybko przypadkiem ? To ogólnie wiadome a czasem jakoś "się zapomni" o tym fabrycznym 1 MHz - mnie się zdarza :-)

Może przyda się dla porównania sprawdzona funkcja :

<>

char StartPrgMode(void) { char i,j,backbyte; uint command,mask;

command=0xac53; mask=0x8000; backbyte=0;

CLR_SCK(); CLR_MOSI();

for (i=0;i<32;i++) { CLR_RST(); // włączenie bufora 244 przy niskim SCK // reset osiąga poziom niski z niewielkim sprzętowym opóźnieniem, // które uwzględniamy łącznie z wymaganymi prze interfejs ISP 20 ms StartT1Delay(50000); while (!T1_DELAY_DONE) ; // teraz wysyłamy sekwencję zezwalającą - jeśli odpowiedź jest poprawna // wychodzimy z pętli for (j=0;j<16;j++) // komenda { if (command & mask) SET_MOSI(); else CLR_MOSI(); ISP_SCK_DELAY(); SET_SCK(); ISP_SCK_DELAY(); CLR_SCK(); mask = mask >> 1; } CLR_MOSI(); for (j=0;j<8;j++) // odczyt bajtu zwrotnego { ISP_SCK_DELAY(); SET_SCK(); ISP_SCK_DELAY(); CLR_SCK(); if (GET_MISO()) backbyte |= 0x1; if (j<7) backbyte = backbyte << 1; } for (j=0;j<8;j++) // ostatni dowolny bajt { ISP_SCK_DELAY(); SET_SCK(); ISP_SCK_DELAY(); CLR_SCK(); }

if (backbyte == 0x53) break; // OK - jest tryb programowania // nie wyszło - próbujmy ponownie SET_RST(); wdt_reset(); StartT1Delay(500); while (!T1_DELAY_DONE) ; }

if(i == 32) // brak poprawnej odpowiedzi { SET_RST(); SET_SCK(); SET_MOSI(); return 1; } else return 0; }

Nie. Mam procka przelaczonego na rezonator 12MHz. Ale wysylam w trybie

9600bodow, wiec i dla 1MHz nie byloby to za duzo. UISP tez zreszta korzysta z tej predkosci i dzialal z moim ukladem.

Niestety, to samo. Dopisalem sobie odpowiednie funkcje CLR i SET, osobno elegancko ustawiaja poszczegolne linie, ale programik i tak nie dziala (znaczy nie wykrywa odpowiedzi procka). Czytajac pdfa do 2313 zauwazylem, ze pomiedzy kolejnymi probami synchronizacji zamiast ustawiac RESET daja dodatkowy puls SCK. Co wydaje sie o tyle sensowne, ze 32 powtorzenia odpowiadaja wlasnie 32 bitom instrukcji rozpoczynajacej programowanie. Z kolei w pdf do atmega8 pisza o pulsach na RESET. Jak to w koncu jest, dawac pulsy RESET czy SCK? Drugi dzien walki mija, niestety bezowocnie:(

Ok, w koncu na twojej procedurze zadzialalo, ale po pewnych modyfikacjach. Wydaje sie, ze ATMega8 zachowuje sie tak, ze jak dostaje AC53h to na narastajacym zboczu SCK 16 bitu sampluje ostatni bit polecenia, a na opadajacym zboczu SCK tego samego bitu wystawia juz pierwszy bit z echa (w tym wypadku 0). w sumie dziwne, ale przy takim zalozeniu wszystko jest ok i otrzymuje poprawna odpowiedz 53h. Ot taka ciekawostka. Ale jesli tak jest w istocie to twoj program nie moze dzialac, przynajmniej z ATMega8:)

T.M.F. napisał(a):

A nie prościej, wygodniej i szybciej jest dorobić bootloader do procka?

Nie, bo bootloader nie zmieni np. ustawienia fusebitow, odpowiedzialnych np. za wybor zegara.

Zreszta problem rozwiazany - okazalo sie, ze ze wzgledu na kondensator

22nF na linii SCK musze wydluzyc dodatni impuls SCK. Teraz juz wszystko gra.