Elektroda.pl
Elektroda.pl
X
Relpol przekaźniki
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

FT232R / AVR

12 Lis 2007 23:22 4833 31
  • Poziom 35  
    Witam serdecznie,

    Mam kilka układów z FT232R(L?) w obudowie SSOP28. Niektóre z nich są zasilane przez USB, inne z sieci. Wszystkie są zbudowane wg. noty katalogowej FTDI.
    Niestety układy te przy skokach napięcia w sieci bardzo często się wieszają (jedyna możliwość ponownej pracy to wyłączenie napięcia ft232R, reszta układów i komputer spokojnie pracują dalej).
    Generalnie wygląda to tak:
    Płytka z FT232R do sieci, laptop z baterii - działa
    FT232R do baterii, laptop z sieci - wiesza się
    FT232R z sieci, laptop z sieci - wiesza się.

    Testy robione na kilku różnych komputerach stacjonarnych i laptopach.

    Zwisy zależą od jakości sieci 220V. Czasem nie występują. W innych budynkach czasem wystarczy włączyć światło i układ pada. Sporo też zależy od zasilacza.
    Próbowałem filtr na 220V i nic to nie dało.

    Miał ktoś podobne objawy? Jakieś pomysły jak to eliminować?
  • Relpol przekaźniki
  • Poziom 34  
    A założył kolega koralik na zasilanko i może jakąś ceweczkę ? Te objawy to 100% źle rozwiązane zasilanie i płytka montażowa .
  • Poziom 26  
    Używam układu FT232BM. Ja mam (kolejność od złącza USB):
    -na +5V: BLM21PG221SN1, 100n, 100n, 10u/16V tantal, <stąd biorę napięcie cyfrowe USB> 470R (szeregowo), 100n <stąd biorę napięcie analogowe USB>
    -na D+ - D-: 27R (szeregowo)
    -na GND BLM21PG221SN1
    Złącze jest ekranowane, a ekran dołączony do GND. Nie mam żadnych problemów z zakłóceniami (badane w laboratoium EMC i sprawdzone "w życiu").
  • Relpol przekaźniki
  • Poziom 35  
    Dziękuje bardzo za informacje. Właśnie projektuje nową płytkę, więc za 2tyg. będę dokładnie wiedział jak to się sprawuje w rzeczywistości.
    Napisze jak te zmiany wpłynęły na niezawodność układu.
  • Poziom 29  
    Witam... Mam podobne problemy - wiem, że minęło więcej niż te 2 tygodnie i mam nadzieję, że moderator mnie nie ukarze naganą (wiem Panie moderatorze, że to oznacza już zablokowanie konta :( ) - ale czy możesz dokończyć ten bardzo istotny dla mnie temat bo niema sensu, żebym zakładał identyczny?
  • Poziom 30  
    Trzeba dobrze odseparować zasilanie FTDI. Nie jakiś byle koralik czy dławik 10u ale duży dławik(wstawiałem 1mH) i porządny kondensator tantalowy (wyłącznie na zasilaniu FTDI!)
  • Poziom 33  
    Cytat:

    Trzeba dobrze odseparować zasilanie FTDI. Nie jakiś byle koralik czy dławik 10u ale duży dławik(wstawiałem 1mH) i porządny kondensator tantalowy (wyłącznie na zasilaniu FTDI!)

    Jako że nie tak dawno ten temat był poruszany, proszę napisać jeśli kolega miał taka sytuację, że układ miał problemy z działaniem a po dodaniu dławika zniknęły.
  • Poziom 35  
    Tak, dodanie koralika i tantala pomogło, chociaż nie wyeliminowało problemu w 100%. Dodanie dławika rzędu 1mH pewnie by kompletnie wyeliminowało problem, ale dla mnie pierwsze zmiany były wystarczające.
  • Poziom 30  
    Zasilanie FTDI w moim układzie było wspólne z reszta układu (w tym 5 V z USB było podane na zasilacz impulsowy). Efekt taki jak opisywał kolega - "wypadanie" urządzenia z systemu po zmianie obciążenia zasilacza po stronie wtórnej (z.impulsowy izolowany). To dotyczy tylko układów "R". We wcześniejszych wersjach FTDI tego efektu nie obserwowałem. Teraz przetwornica ma swój układ zasilania (RLC) a FTDI swój i jakoś układ przestał mnie denerwować.
  • Poziom 29  
    ale wszystko zasilane z usb... tak ? Czy mógłbyś podać konkretny typ elementów jakie zastosowałeś oraz schemacik "poglądowy"? już próbowałem wielu "sztuczek" i wcale mi to nie pomogło :( - co prawda nie wylatuje już urządzenie z systemu ale transmisja się urywa na dobre - ciekawe czy komunikacja przez d2xx by coś zmieniła w stosunku do VCP...
  • Poziom 30  
    No pewnie, że korzystanie z VCP to jest pomyłka. Dawno używam bibliotek DLL. Układ zachowuję się bardziej stabilnie. A poza tym można po "wypadnięciu", programowo (bez wyjmowania i wkładania wtyczki USB) odtworzyć połączenie w systemie(w 90% przypadków). Istnieje też większa możliwość identyfikacji Chipu poprzez aplikację.
  • Poziom 29  
    co masz na myśli pisząc : Układ zachowuję się bardziej stabilnie ?
    U mnie zachowuje się bardzo stabilnie jeśli nie ma jakiegoś mocnego zakłócenia o którym mowa w tym temacie - czy na to zakłócenie układ (transmisja) będzie bardziej odporny ?
  • Poziom 42  
    Panowie ja stosuję już od dłuższego czasu ten przyjemny scalaczek FT232R i nigdy nie mam z nim żadnych problemów. Gdy układ ma pracować w sprzyjających warunkach to nawet koralik nie jest wymagany. Ale oczywiście gdy zakładam że będą trudniejsze warunki to daję koralik na zasilanie FT232R.

    Z tym, że ja zawsze zasilam sam scalak z USB ! I gdy ma pracować cały układ w mniej sprzyjających warunkach to stosuję w ogóle kabel USB grubszy i taki, który sam w sobie zawiera co najmniej jeden taki gruby koralik na kablu.

    Do tego jeden kondensator elektrolityczny 4,7uF przy samych nogach zasilania a równolegle z nim 100nF. Drugi kondek 100nF jak w nocie.

    Układy mają tylko wspólne masy - a sygnały RS232 śmigają na pełnych prędkościach i jeszcze nigdy nie zauważyłem, takich dziwnych efektów o jakich tu większość wypowiadających się, pisze.

    Dodano po 6 [minuty]:

    kemot55 napisał:
    No pewnie, że korzystanie z VCP to jest pomyłka. Dawno używam bibliotek DLL. Układ zachowuję się bardziej stabilnie. A poza tym można po "wypadnięciu", programowo (bez wyjmowania i wkładania wtyczki USB) odtworzyć połączenie w systemie(w 90% przypadków). Istnieje też większa możliwość identyfikacji Chipu poprzez aplikację.


    VCP pomyłka ??? sorki ale nie zgodzę się z tym ani w 1 procencie. Pomyłkowa jest twoja ocena i nie wiem z czego ona wynika. Z czego niby miałaby wynikać większa stabilność przy dostępie przez DLL ?

    Sam się narażasz na mniejszą stabilność bo twój program prędzej zawiedzie niż sprawdzone , dobre i od lat stosowane procedury do obsługi driverów VCP.

    Stosowałem zarówno jedno jak i drugie, i nigdy bym nie powiedział, że jeden sposób jest stabilniejszy od drugiego bo to w ogóle nie ma związku ze sobą.

    --------

    Najważniejsze - jeśli piszesz oprogramowanie własne do urządzenia działającego na VCP i po zerwaniu połączenia musisz wyjmować i wkładać ponownie kabel USB żeby ci to ruszyło to sorki, ale nie masz jeszcze żadnego doświadczenia w pisaniu takiego oprogramowania. Spokojnie daje się to opanować programowo bez większych wysiłków i to przy zwykłej transmisji RS232 na Virtual Com Port. Wiem co mówię bo w ten sposób muszę obsługiwać większość urządzeń. I gdyby klient miał taką kichę, że musiałby odłączać i podłączać to byłaby rzeczywiście maskara.
  • Poziom 29  
    a możesz zdradzić w jaki sposób zabezpieczyć oprogramowanie np. przed wyjęciem wtyczki z portu USB podczas trwającej transmisji ? nigdzie nie znalazłem informacji jak to zrobić a moja aplikacja korzystająca z WinApi po prostu zwisa...

    Dodano po 2 [minuty]:

    ps. Tak jak piszesz - jeśli niema problemów z zakłóceniami to żaden koralik ekranowanie, tantale etc... nie są wymagane i VCP śmiga aż miło.
  • Poziom 42  
    prokopcio napisał:
    a możesz zdradzić w jaki sposób zabezpieczyć oprogramowanie np. przed wyjęciem wtyczki z portu USB podczas trwającej transmisji ? nigdzie nie znalazłem informacji jak to zrobić a moja aplikacja korzystająca z WinApi po prostu zwisa...


    Hmmm ciężko to opisać w dwóch zdaniach tym bardziej, że do tej pory pisałem taki soft tylko przy użyciu Delphi.

    Jednak całkowicie zrezygnowałem z obsługi portów COM w postaci różnych popularnych i ogólno dostępnych komponentów, jak np znany na elektrodzie chyba wszystkim ComPort. (dzięki tym komponentom zawsze była taka obrzydliwa zwiecha)

    Napisałem własną obsługę RS232 od podstaw, no może nie od całkowitych podstaw bo jednak skorzystałem z klas "synapse" , nie są to komponenty ale w podstawowy sposób opakowane w różne klasy procedury WinAPI. Dzięki nim dopiero można albo pisać wprost kod programu albo....

    albo tworzyć własne komponenty. I tą "tajemnicą" jest obsługa komunikacji portu RS232 z użyciem wątków (Threads) .

    Tym sposobem utworzyłem sobie własny komponent o nazwie TmkComPort i w 100% pozbyłem się tych przykrych dolegliwości a dodatkowo wzbogaciłem o cały szereg interesujących mnie fiuczersów. m.in. do transmisji od razu RS485 i innych.

    Jeśli ktoś pomoże mi porządnie podszkolić się i przejść na pisanie programów w MS Visual C++ i/lub MS Visual C# - to ja z chęcią odwzajemnię się wiedzą na temat korzystania z wątków i innych ciekawych zagadnień. Zresztą mam cel aby jak najszybciej przejść z Delphi na C++ ..... tylko ta praktyczna strona nie pozwala mi na razie płynnie wystartować :(
  • Poziom 29  
    ja używam tylko delphi (WinApi) bez użycia komponentów (threards również używałem lecz zrezygnowałem) i wystarczy, że mam com otwarty to podczas wystąpienia zakłócenia lub wyjęcia wtyczki USB program "nie odpowiada", nawet nie daje mi szansy na sprawdzenie co się stało :(...

    Dodano po 3 [minuty]:

    teraz sprawdziłem - "ft prog" również podczas wystąpienia zakłócenia przestaje odpowiadać... czyżby firma ftdi również "nieumiejętnie" pisała oprogramowanie ?
  • Poziom 42  
    prokopcio napisał:
    ja używam tylko delphi (WinApi) bez użycia komponentów (threards również używałem lecz zrezygnowałem)


    Zrezygnowałeś bo ???? ...... to był twój największy błąd. Wiem, programowanie z użyciem wątków nie jest łatwe. Powiem więcej jest cholernie trudne szczególnie jak ktoś zaczyna w tym raczkować. Ale efekty tego co można później robić są porażająco przyjemne.


    prokopcio napisał:
    i wystarczy, że mam com otwarty to podczas wystąpienia zakłócenia lub wyjęcia wtyczki USB program "nie odpowiada", nawet nie daje mi szansy na sprawdzenie co się stało :(...


    Niestety wynika to z tego, że własnie nie rozumiesz co to są wątki, co to jest główny wątek programu i poboczne. Ty dobierasz się do portu COM (najprościej mówiąc) w trybie blokującym, tzn każda długotrwała operacja blokuje działanie całego programu głównego , "zamraża" ci formatkę okienka głównego. A jeśli natąpi zerwanie połączenia to nie masz prawidłowej obsługi tego mechanizmu, brak time-out'ów i to w prosty sposób prowadzi do katastrofy. Bez wątków zapomnij o poważnych zastosowaniach komunikacji szeregowej. I wcale tu nie chodzi tylko o komunikację RS232 ale chociażby TCP/IP i inne




    prokopcio napisał:
    czyżby firma ftdi również "nieumiejętnie" pisała oprogramowanie ?


    Proszę, nie opowiadaj takich herezji, to że ty nie potrafisz sobie na razie z tym poradzić to ma oznaczać, że firma ftdi nieumiejętnie pisze oprogramowanie ???? No proszę cię bardzo, nie żartuj tylko sam weź się za naukę prawidłowego oprogramowania - i nie piszę tego złośliwie. Sam kiedyś długo się wściekałem na komponenty typu ComPort że powodują takie efekty w aplikachach.

    AHA! czy myślisz, że takie zwiechy masz tylko gdy stosuszesz FTDI ? zastosuj sobie dowolną inną przejściówkę USB/RS232 nawet taką zrobioną na procku ATmega w oparciu o VUSB czy przykłady ze stronki OSAMU TAMURy, zawsze - w każdym przypadku będziesz miał takie same efekty obojętnie czego nie użyjesz, dokąd sam tego nie nauczysz się prawidłowo obsługiwać.

    Widzisz, ze mną było nieco odwrotnie, gdy okazało się , że ComPort się tak obrzydliwie zachowuje to nie siedziałem i nie płakałem nad rozlanym mlekiem oskarżając, że to wina FTDI czy np rowerzystów bo akurat hałasują za oknem. Szukałem kolejnych rozwiązań i walczyłem do upadłego aż rozwiązałem problem i teraz nigdy jak i wielu ludzi nie mam z tym żadnych kłopotów.

    Stwierdzenie, że firma FTDI, która już nawet ma ma certyfikowane swoje drivery przez microsoft, źle pisze sterowniki bo u ciebie źle działa - jest złym kierunkiem wyboru rozwiązania swojego problemu.

    ----------

    Żeby nie być gołosłownym, przenieś swoją obsługę do pobocznego nowo utworzonego wątku, naucz się w ogóle obsługiwać prawidłowo z aplikacji wątki, strować ich działaniem , przekazywać do nich parametry ale także odbierać informacje. Możesz to robić poprzez zwykłe oprogramowanie zdarzeń. Ale też doczytaj w WinApi o TimeOutach, które trzeba wziąć pod uwagę oraz o wszystkich komunikatach błędów.

    Wtedy twój wątek obsługujący port COM, jeśli nastąpi gwałtowna przerwa, będzie co najwyżej tyle czasu nieżywy co ustawiony przez ciebie Timeout dla dostępu do portu COM, po czym jeśli taki Timeout wystąpi, to wątek może albo zakończyć swoje działanie albo zgłosić to do głównego okna/wątku aplikacji, która zdecyduje czy ma dalej próbować się łączyć czy nie - w zależności od tego jaki komunikat otrzymujesz.

    Dzięki temu że to wszystko będzie działo się w wątku to twoja aplikacja główna i jej wszystkie ew okna będą w tym czasie pięknie działać, nic się nie będzie zamrażać, a ty będziesz mógł zrobić co zechcesz z wątkiem który działa tylko w tle.

    Tak ogólnie mogę to opisać. Niestety trzeba na prawdę sporo potrenować i wyszkolić się w wątkach - zamiast twierdzić, że się z nich rezygnuje bo ..... bo co? bo nie przyniosły ci spodziewanych efektów? jeśli tak to tylko i wyłącznie może oznaczać, że całkowicie źle ich używałeś niestety :(
  • Poziom 26  
    A masz połączoną masę z ekranem kabla USB?

    Miałem podobny problem z FT232 RL. Przy podłączonym obciążeniu do przekaźnika który był zasilany z USB, a następnie załączeniu układ zawieszał się praktycznie za każdym razem.

    Pomogło połączenie masy urządzenia z ekranem kabla USB (czyli z obudową gniazda USB). Ogólnie panowie z supportu FTDI mi ten pomysł podsunęli. Ogólnie pisałem do 2 panów naraz i jeden (chyba z chin lub jakiegoś kraju azjatyckiego) napisał że mam połączyć ekran z masą (co zadziałało super i bez problemów) a drugi (z UK) jakieś tam pierdoły napisał które nie nie pomogły. Odpisałem później do Pana z UK że połączyłem te masy wg tego co mi napisała inna osoba z ich supprotu, a on na to że nie powinienem tak robić że powinienem jak już to połączyć je przez kondensator 470nF (chyba - co do wartości nie jestem pewien). Że połączenie ekranu przeniesie zakłócenia na komputer co jest w sumie logiczne. Nie sprawdzałem tego rozwiązania.

    Próbowałem filtrować zasilanie dając coraz to większe kondensatory, inne dławiki i koraliki.

    Summarum od tego czasu zawsze łącze ekran z masą przy urządzeniach pracujących z USB i nie mam od tego czasu żadnych problemów.

    Pozdrawiam Jakub
  • Poziom 29  
    tak, czy z ekranem czy nie, jednak się wiesza (zapomniałem w sumie dodać ważnej informacji, że tylko na niektórych komputerach i przy dużycz zakłóceniach jak nap załączanie silników szczotkowych)....

    mirekk36 -> nie zrozumiałeś mnie... ja uważam, że ich kostki jak i support są znakomite (drivery również)... tylko o to, że czepiasz się mojej aplikacji a pomijając ją - przy wystąpieniu zakłócenia również zwisa ich oprogramowanie "FT Prog" więc pewnie nie stosują w nim rewelacyjnych wątków - tylko tyle miałem na myśli.... po tym nie działa zamykanie jej przez menadżer zadań i program ich nie zadziała jak już ktoś inny tu wspomniał jak nie wypniesz usb i na nowo nie podepniesz (sprawdzałem to dziś) - źródłem zakłóceń "testowych" jest u mnie lutownica transformatorowa przyłożona do masy układu - włączana i wyłączana. komponent ComPort zresztą już dawno wyrzuciłem do śmieci :)
  • Poziom 42  
    prokopcio --> wcale nie miałem zamaru się czepiać, jak to tak odebrałeś to sorki ;)

    A tak nawiasem mówiąc, to czy nie możesz zrobić tak? :

    1. podłączasz się kablem USB do FT232R i dajesz mu zasilanie +5V oczywiście przez koralik oraz z użyciem normalnego grubego kabla USB, który też ma jeszcze koralik w sobie (takie zgrubienie po drodze)

    2. Natomiast swój czy swoje przekaźniki zasilasz z jakiegoś zewn, źródła zasialania zamiast z USB.

    i wtedy byś zobaczył czy nie skończą się twoje problemy raz na zawsze ? ;) nawet ze strzelaniem z lutownicy transformatorowej
  • Poziom 29  
    Zawsze to jakieś pocieszenie (kiepskie), że nie tylko ja mam problem ;)... Raczej to host się wiesza w PC ponieważ z innymi komputerami ten problem się nie pojawia wcale lub pojawia się znacznie rzadziej - sprawdź jeśli możesz....

    ...
    Ja jeszcze dodam

    7. emi filtry usb
    8. podwójne emi filtry usb (przy ftdi i przy kompie)
    9. ekranowanie "full wypas".
    10. NAJDZIWNIEJSZE : OPTOIZOLACJA po stronie rs232 + izolowana przetwornica dc/dc 5V dla dalszej części.

    I nic. Jeśli komp jest nieodporny (nowoczesne komputery) - to samo urządzenie na zwykłym nieekranowanym kablu bez żadnych dławików i filtrów działa bezbłędnie w innym (starym) komputerze.....

    tyle z mojej strony.
  • Poziom 11  
    Cytat:
    ...tyle z mojej strony.


    Niestety prokopcio ma rację - bardzo dużo zależy od samego komputera – a nawet konkretnego gniazda USB do jakiego się podłączymy!?!? Np. jeśli w moim (stacjonarnym) komputerze podłącze się pod gniazdo na przednim panelu to faktycznie wystarczy kilka strzałów z lutownicy transformatorowej i układ leży. Natomiast ten sam układ podłączony do gniazda z tyłu komputera jest nie do ruszenia w żaden sposób. To samo zjawisko zauważyłem w laptopoach jakie posiadam - gniazdo gniazdku nie równe i te nie zainstalowane bezpośrednio na płycie głównej są bardziej podatne na zakłócenia. Oczywiście mimo to wszystkie „zabezpieczenia” (dobry kabel, koraliki, optoizolacja etc.) obowiązują – gdyż też swoje dają.
  • Poziom 42  
    cosimo napisał:
    Cytat:
    ...tyle z mojej strony.


    Niestety prokopcio ma rację - bardzo dużo zależy od samego komputera – a nawet konkretnego gniazda USB do jakiego się podłączymy!?!? Np. jeśli w moim (stacjonarnym) komputerze podłącze się pod gniazdo na przednim panelu to faktycznie wystarczy kilka strzałów z lutownicy transformatorowej i układ leży. Natomiast ten sam układ podłączony do gniazda z tyłu komputera jest nie do ruszenia w żaden sposób. To samo zjawisko zauważyłem w laptopoach jakie posiadam - gniazdo gniazdku nie równe i te nie zainstalowane bezpośrednio na płycie głównej są bardziej podatne na zakłócenia. Oczywiście mimo to wszystkie „zabezpieczenia” (dobry kabel, koraliki, optoizolacja etc.) obowiązują – gdyż też swoje dają.


    Panie kolego a pokusiłeś się chociaż RAZ, jeden RAZ aby sprawdzić co powoduje, że jeden strzał lutownicy i układ leży - gdy podłączony jest do przedniego gniazdka ???? To wg ciebie wina układu FT232 ????? - sorki ale nie wiesz co mówisz. Na drugi raz zajrzyj do kompa, odkręć obudowę i zobacz jakimi kablami, jak długimi są podłączone gniazda USB na panelu przednim. I dlaczego kable nie są ekranowane i bez żadnych korali ferytowych itp. Wystarczy że podłączysz taki panel na porządnym kablu i jak najkrótszym kablu i będziesz sobie mógł strzelać z lutownicy jak z karabinu maszynowego ..... co więcej na drugi raz nie będziesz już wysnuwał takich teorii - bo będziesz wiedział skąd biorą się te zakłócenia ok?
  • Poziom 29  
    mirekk36 napisał:
    cosimo napisał:
    Cytat:
    ...tyle z mojej strony.


    Niestety prokopcio ma rację - bardzo dużo zależy od samego komputera – a nawet konkretnego gniazda USB do jakiego się podłączymy!?!?............


    Panie kolego ................. To wg ciebie wina układu FT232 ????? - sorki ale nie wiesz co mówisz.............nie będziesz już wysnuwał takich teorii - ........


    Halo Halo Panie kolego :), Czy kolega cosimo, choć raz wspomniał, że to wina układu FTDI ? Przecież WYRAŹNIE napisał, że nie !!! Wina KOMPUTERA a raczej jakości połączeń gniazd do płyty głównej.... Przynajmniej ja tak to odebrałem i to potwierdzam.
  • Poziom 42  
    No to BARDZO PRZEPRASZAM jeśli ja źle zrozumiałem.
  • Poziom 10  
    Chciałbym zaprojektować układ, który po podłączeniu CC1000 lub ADF7025 (znajdujące się na osobnej płytce) mógłby służyć jako odbiornik i przesyłałby dane (w tym przypadku temperaturę z DS18B20) przez USB do PC. Zastosowałem układ FT232RL jednak nie jestem do końca pewien czy poprawnie podłączyłem go do uC Atmega8L. Całość będzie zasilana z USB z tym, że tylko FT232RL bezpośrednio czyli 5V, natomiast uC i ADF7025(lub CC1000) napięciem 3.3V ze stabilizatora.
  • Poziom 26  
    Jedyny wyraźny błąd jaki mi się w oko rzucił to, że Txd w uC masz podłączone do Txd w ft232rl (podobnie jak Rxd). One muszę być skorsowane, czyli to co procesor wysyła z TXD idzie na nóżkę odbiorczą ft232 czyli RXD.

    Przy LCD też brakuje Tobie potencjometru do sterowania kontrastem. No i uważaj z nimi bo jak go zasilasz z 3.3V to musisz kupić już konkretny taki co będzie mógł być zasilany takim napięciem (droższe i mało popularne). Jak masz 5V na płytce to lepiej właśnie nimi zasilać LCD.

    Chyba wszystko

    Pozdrawiam

    Poza tym kondensatory trochę małe przed i za stabilizatorem. Za IMO co najmniej 10uF, przed to może zostać samo 100nF (i powinno działać), ale zawsze lepiej coś tam wsadzić chociaż te 10uF.
  • Poziom 10  
    Dziękuję za odpowiedź.

    Racja, ale gafa z tymi liniami TXD i RXD. Wyświetlacz już uruchamiałem na próbę z napięciem 3.3V i działał, podobnie jak z kontrastem podpiętym do masy. Jeśli jednak później będą jakieś problemy to zmienię połączenia.

    Zastanawiam się jeszcze nad kwarcem dla uC. Jaką wartość najwygodniej użyć? Prędkość transmisji nie musi być wysoka.
  • Poziom 42  
    Siwyyx napisał:

    Zastanawiam się jeszcze nad kwarcem dla uC. Jaką wartość najwygodniej użyć? Prędkość transmisji nie musi być wysoka.


    Jeśli wystarczy ci standardowa prędkość 9600 to w ogóle nie potrzebujesz kwarca zewnętrznego no chyba że układ będzie pracował co jakiś czas w skrajnie różnych temperaturach to wtedy można pomyśleć. Jeżeli w takiej samej temperaturze to dawanie kwarcu mija się z celem.

    A jeśli jednak musisz dać kwarc bo jak mówiłem np temperatury się zmieniają skrajnie (np różnica + - 30st) to wtedy zajrzyj sobie na ostatnią stronę noty PDF dowolnego w zasadzie procka AVR w rozdziale USART. Tam masz jak byk pokazane tabele z których jasno wynikia dla jakiego taktowania - jakie są błędy transmisji.

    Spójrz sobie z ciekawości na taktowanie 8MHz i prędkość 9600 - procent błędu malutki podobnie zresztą nawet jak przy 38400. (Po co kwarc?) Jeśli procent błędu zaczyna być większy od 2% dla interesującej cię prędkości to dopiero wtedy warto myśleć o kwarcu. Z ciekawości spójrz sobie na kwarc: 11,0592MHz i procenty błędów dla dowolnej prędkości, wtedy też zrozumiesz jakie kwarce wybiera się z uwagi na RS232. Podobnie będzie np z 18,432MHz i kilkoma innymi.