Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)

LChucki 07 Feb 2020 09:32 5964 60
Altium Designer Computer Controls
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    Wydawać się może, że na temat konwerterów USB napisano już wszystko i nic nowego się nie pojawi. Nic bardziej mylnego.
    Najczęściej stosowane są konwertery USB-UART. Mają one szereg wad odczuwalny zwłaszcza przy współpracy z AVR a co za tym idzie większością Arduino. Wykorzystanie UART stwarza problemy, bo:
    - AVR mają mało UART. Jest to szczególnie odczuwalne w przypadku ArduinoUNO. Niektóre AVR mają 2 UART, nieliczne mega 4 ale to już obudowy 100pin.
    - Generator AVRmega/tiny musi być stabilizowany rezonatorem kwarcowym. Wbudowany RC ma zbyt małą stabilność aby wykorzystać go z UART.
    - Wbudowane FIFO nie spełnia swojej roli. Mostki mają FIFO ale co z tego jak znaki, które przyszły z USB są wysyłane do UART czy uC tego chce czy nie *(wyjaśnienie na końcu). Ten problem najbardziej odczuwalny jest w Arduino z AVRmega/tiny, w którym podczas komunikacji z WS2812 czy 1-Wire najczęściej zawieszane są przerwania.
    - Kontrola przepływu wymaga dodatkowych GPIO uC.
    - Nie można stwierdzić czy USB HOST jest przyłączony czy nie.
    - Konfigurację mostka czyli VID, PID, desktyptor, funkcje GPIO (np przyłączonych LED), itd można przeprowadzić (o ile można bo w np CP2101 nie) tylko z poziomu komputera odpowiednią aplikacją, dla FTDI FT_PROG. Nie można tego zrobić z poziomu uC.

    Wszystkie wyżej wymienione problemy rozwiązuje mostek USB-I2C udostępniając dodatkowo ok 1kB EEPROM. Wszystko to za sprawą układu FT201. Układ ten pracuje po magistrali I2C. Dzięki temu nie tracimy drogocennego dla AVR UART a uC nie musi mieć stabilnego generatora. I2C umożliwia zarówno transmisję danych jak i konfigurację układu, odczyt statusu czy obsługę EEPROM. Do pamięci konfiguracji (MTP) i EEPROM ma dostęp zarówno uC jak i HOST za pośrednictwem bibliotek D2XX. Dzięki temu, programując uC nie trzeba dodatkowo konfigurować mostka, może to zrobić uC. Opcja bardzo wygodna przy seryjnej produkcji. Cena układu FT201 jest porównywalna z ceną FT232RL.

    W czasach gdy zajmowałem się AVR-ami, FT201 i podobny do niego FT22x (USB-SPI) stał się moim ulubionym mostkiem USB. Teraz wrócił do łask mino, że używam ARM STM32, w których USB to niejako standard. FT201 przydaje się wszędzie tam gdzie potrzebuje galwanicznie izolowanego interfejsu USB. Do izolacji USB można użyć np układu ADuM1460 ale FT201 jest tańszy.

    O budowie urządzenia niewiele można napisać (schemat w załączniku, plik "FT201_rev2001.pdf") poza tym, że dodałem izolator galwaniczny na liniach I2C. O takiej izolacji często zapominają producenci sprzętu pomiarowego takiego jak oscyloskopy, generatory itp. Izolację zapewnia ADuM1251
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    Szeroki zakres napięć zasilających powoduje, że poza izolacją galwaniczną układ może pełnić także funkcję konwertera poziomów. Oznaczenia SCL i SDA na układzie są umowne bo oba bloki konwertera zbudowane są w ten sam sposób. FT201 akceptuje na I2C napięcie 5V dlatego układ został zasilony z USB, dzięki czemu nie obciąża stabilizatora w FT201. Na oscylogramie widać wysyłanie danych do FT201:
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    W załączniku, poza schematem konwertera (UWAGA! Na PCB opis linii SCL i SDA jest zamieniony), umieściłem notę aplikacyjną układu oraz dokument opisujący sposób konfiguracji konwertera, pamięci MTP i inne materiały.


    Układ testowałem z płytką NUCLEO L412:
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    Podstawowa obsługa (jak mostków UART) jest banalna. Pod domyślny adres 0x44 (0x22) wysyłamy daną. Jeśli otrzymamy ACK to ok, jak nie to znaczy, że FIFO jest zapchane. Odczyt równie banalny. Adresujemy slave 0x44 (0x22) do odczytu, jeśli jest ACK to znaczy, że jest co najmniej jeden znak w FIFO, jeśli nie to nie ma nic. Prosty program odsyła odebrane znaki oraz co 2 sekundy napis "Ramka" i jej nr kolejny:
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    Program w załączniku (plik "F20x_FT22x_NucleoF411RB-P 20200208 105437.zip").
    Na STM32 nie testowałem bardziej zaawansowanych funkcji układu, bo zrobiłem to już wcześniej dla AVR (załącznik, plik "FT201.c"). Tam można zobaczyć jak odczytywać/zapisywać pamięć MTP, wolny obszar EEPROM, czytać status układu, liczbę znaków do odebrania itd.

    Na koniec warto wspomnieć o układach FT220 i 221. Oba komunikują się z uC po SPI. Pierwszy z nich, 500kb/s od strony USB, posiada SPI 1/2/4-bit. Drugi, 1Mb/s, SPI 1/2/4/8 bit.


    * - Nie znam sposobu aby zatrzymać wysyłanie danych z FTDI. Zmiana stanu linii CTS czy DTR powoduje tylko zmianę stanu tych wirtualnych linii dostępnych w Hoście przez API. Nawet jak HOST przestanie wysyłać dane, to i tak co już wcześniej wysłano będzie musiało zostać wytransmitowane przez UART układu FTDI. Bardziej obrazowo, stan linii CTS i DTR nie ma wypłwu na wysyłanie danych z FTDI. Jeśli więc przerwania w uC zostaną zawieszone na zbyt długo, FIFO w uC przepełni się, znaki zostaną utracone.
    Jeśli przezornie, zmienimy stan linii CTS/DTR (aplikacja musi na to reagować!) i poczekamy na opróżnienie FIFO FTDI, to wszystko będzie dobrze z tym, że potrzebujemy do tego dodatkowej linii GPIO w uC. W przypadku FT201 do wszystkiego wystarczają linie I2C.
    Attachments:

    Cool? Ranking DIY
    Do you have a problem with Arduino? Ask question. Visit our forum Arduino.
    About Author
    LChucki
    Level 31  
    Offline 
    Kod z delay to nie kod, to DEMO!
    Możliwości sprzętowe uC trzeba wykorzystywać a nie "machać" GPIO.

    Moje publiczne projekty/współ-projekty od 1991 roku: http://er-mik.prv.pl/projekty_avt.php http://er-mik.prv.pl/projekty_edw.php

    e-mail: es2(malpa)ep.com.pl
    LChucki wrote 1940 posts with rating 362, helped 102 times. Live in city Warszawa. Been with us since 2018 year.
  • Altium Designer Computer Controls
  • #2
    CosteC
    Level 37  
    Doceniam ideę mostka USB<->I2C ale argumentacja mnie totalnie zabiła. "UART stwarza problemy".. chyba gdy nie umie się zarządzać przerwaniami, bo poprawnie działające systemy z UARTami chodzącymi dobrze powyżej 115.2 kbps są dosyć często spotykane, miniaturowe FIFO w UART jest potrzebne tylko do wyjęcia bajtu w przerwaniu i przeładowaniu do bufora cyklicznego w RAMie... To, że biblioteki często tego nie robią albo robią to źle to nie wina uC tylko programisty.

    Jak chodzi o projekcik - ładny, brakuje mi tylko zabezpieczeń, chociażby przed odwrotnym podłączeniem zasilania co się zdarza w warunkach "bojowych"
  • #3
    LChucki
    Level 31  
    CosteC wrote:
    ale argumentacja mnie totalnie zabiła.

    Chyba nie znasz dobrze AVR. Ciężko zrealizować na nim transmisję do WS2812 i jednocześnie odbierać dane z UART. Da się, bo zrobiłem, ale bez ASM raczej nie. Problemem jest to, że AVR nie mają wielopoziomowego systemu przerwań. Można to sztucznie stworzyć przez deklarowanie przerwania INTERRUPT lub ISR( ISR_NOBLOCK)*. Niestety, nie ma to zastosowania dla przerwań odbiorczych UART, bo dopóki nie odczyta się rejestru danych, znacznik przerwania nie jest skasowany. Co się wtedy stanie? Jak chcesz analizuj sprawę dalej albo uwierz na słowo, przerwanie UART będzie stwarzało problemy tak samo jak od poziomu niskiego na wejściu INT.
    Zapoznaj się też z dalszą argumentacją, mało UART w AVR, wymagany kwarc.
    Wybrałeś jedną przypadłość, pewnie projekty realizujesz na ARM, jak ja. W tytule tematu, napisałem: głównie AVR, Arduino! Tam już "kolorowo" nie jest. Arduinowskie biblioteki zawieszają przerwania jak popadnie! Softwarowa realizacja interfejsów to norma! To rodzi masę problemów.

    CosteC wrote:
    Jak chodzi o projekcik - ładny, brakuje mi tylko zabezpieczeń

    Tu już jest problem. W miarę skutecznie to polimer + dioda Zenera mocy. Trochę to na PCB miejsca zajmuje a jak widać moduł jest nieduży. Zakładając, ze daję zabezpieczenie na zasilaniu, co z liniami I2C? Odwrotna polaryzacja zasilania oznaczam, że gdy master wystawi "L", to .... No właśnie, klejne schody.
    A co jak ktoś poda 230V :-)
    Z jednej strony ADuM125x tani nie jest, z drugiej skuteczne zabezpieczenie jest problemem. Jak ktoś obawia się błędów to może dać jakąś diodę od bodtomlayer, która zabezpieczy przynajmniej od odwrócenia biegunowości zasilania. Jak chce skuteczniej, to rezystory kilkadziesiąt ochm na liniach I2C.


    * - pisałem z pamięci, mogą byc literówki.
  • #4
    CosteC
    Level 37  
    Nie dyskutuję z potrzebą kwarcu albo innego stabilnego źródła zegara bo jest i jest pochodną transmisji asynchronicznej, zabawy w kalibrację i kompensację temperaturową uważam za przerost formy nad treścią i rozwiązanie nieprodukcyjne. Można dać rezonator cermiczny, tańszy będzie i działa dostatecznie dobrze.

    Mało UARTów w AVR... Co tu do dyskusji.. w 8051 było jeszcze mniej. Przesiądź się na XMEGA? Byłem nimi kiedyś zachwycony a teraz nie mają większego sensu od kiedy 32 bitowe procesory staniały.

    Na dzień dzisiejszy AVR jest architekturą starą i koniec... ma wady, da je się obejść do pewnego stopnia.

    Sprawdzałeś rozwiązanie polimier + dioda zenera w praktyce?
  • #5
    LChucki
    Level 31  
    CosteC wrote:
    Nie dyskutuję z potrzebą kwarcu albo innego stabilnego źródła zegara bo jest i jest pochodną transmisji asynchronicznej,

    Każdy STM32 obsłuży UART używając wewnętrznego generatora RC. Wiele STM32 nawet do USB nie potrzebuje kwarcu.


    CosteC wrote:
    Mało UARTów w AVR... Co tu do dyskusji.. w 8051 było jeszcze mniej.

    Mniej? Raczej więcej! Każdy uC 8051 miał UART czego nie można powiedzieć o AVR (tiny10, 13, 24, 45, 85 i wiele innych).


    CosteC wrote:
    Na dzień dzisiejszy AVR jest architekturą starą i koniec

    Ale niektóry się nimi zachwycają w dzisiejszych czasach. To samo z Arduino (przeważnie AVR). Stworzyłem kilka projektów pod Arduino:
    https://forum.elportal.pl/viewtopic.php?f=62&t=15010
    https://forum.elportal.pl/viewtopic.php?f=62&t=14998
    https://forum.elportal.pl/viewtopic.php?f=62&t=15000
    bo są na to klienci.
    Nie ma szansy kogoś, co ledwo sobie daje radę z AVR przekonać do ARM. Otoczy AVR-ka dziesiątkami innych układów czy uC o mocy kilkadziesiąt razy większej niż AVR i będzie cieszył się sukcesem. Jest jeszcze druga natura człowieka, czyli przyzwyczajenie. Jakoś nie udało mi się przejść z Altery na Xilinx. Pozostałem przy Alterze, a raczej tfu, Intelu.

    CosteC wrote:
    Sprawdzałeś rozwiązanie polimier + dioda zenera w praktyce?

    Tak. Wiele razy, np. tu: https://www.elektroda.pl/rtvforum/topic3552750.html
  • Altium Designer Computer Controls
  • #6
    Marek_Skalski
    VIP Meritorious for electroda.pl  
    LChucki wrote:
    Większość STM32 nawet do USB nie potrzebuje kwarcu.

    Byłbym ostrożny z takim stwierdzeniem. Raczej niektóre STM32 nie wymagają kwarcu do prawidłowej pracy w trybie USB Device FS. To są układy z rodziny L0 i L5, oraz przestarzałe już dziś L1 i F0. Synchronizują się do sygnału Start of Frame z Hosta.
    W pozostałych (F1, F2, F3, F4, F7, G0, G4, H7, MP1), czyli w większości, kwarc jest potrzebny. Nie musi to być 8, 12 czy 16 MHz. Wystarczy 32768 Hz, do którego synchronizuje się reszta systemu, ale nadal kwarc jest wymagany.
    Proszę nie wprowadzać w błąd. Ktoś może uwierzyć, że w STM32 wszystko samo działa.
  • #7
    CosteC
    Level 37  
    @LChucki Widzę, że lubisz czepiać się szczegółów a nie lubisz odpowiadać na pytania.

    Pytałem czy sprawdzałeś jak działa dioda zenera + bezpiecznik polimerowy. Odsyłasz mnie do schematu z zasilaniem z USB i zabezpieczeniem po stabilizatorze. Jak dla mnie "sprawdzić" znaczy policzyć jak to działa na najgorszych możliwych komponentach a potem podłączyć zasilanie odwrotnie na kilku sztukach. Schemat zniesie wszystko. Zwłaszcza, że na schemacie nawet nie ma informacji ile wynosi VCC. U2 opisałeś jako "SPX1117" a nie "SPX1117M3-3.3"

    Piszesz o zegarze USB taktowanym w STM32 z wewnętrznego zegara. To nie działa co do zasady. USB wymaga stabilności 0.25% (dla trybu full speed). Dla STM32F103xB (rozdział 5.3.7: Internal clock source characteristics), Generator HSI w 25°C ma tolerancje -1.1% to +1.8%. Grubo za słaby. Działa to dokładnie jak UART w AVR: "czasami". @Marek_Skalski wymienia to bardziej szczegółowo.

    A już czepianie się, że w rodzinie tak licznej jak AVRy są wersje bez UARTu... no są, i co z tego, rodzina jest liczna i od 8 nóżkowych do ponad 100 o ile pamiętam.
    Argument, że ARMy są tak samo słabe jak AVRy bo mają 1 UART w Kinetis KL03? Przecież to bez sensu...
    W ogóle tinyAVR i MegaAVR są już mocno różne, z Xmega, AVR32, FPSLIC będącymi zupełnie innymi klasami procesorów z ostro innymi rdzeniami. Po co to porównywać? Procesor jak procesor. AVRy zdobyły rynek dobrymi narzędziami i dlatego do dzisiaj mają powodzenie. Ale są rozwiązania tańsze, są rozwiązania mocniejsze. Taka rzeczywistość rynkowa.

    Wracając do WS2812. Przy 16 MHz jest 20 cykli zegara na bit wysyłany do WS2812. To rzeczywiście wymaga bardzo starannego kodu obsługi przerwań i procesor prawie nic nie może robić gdy ma obsługiwać długi łańcuch WS2812. Teraz pytanie czy to dowodzi słabości AVRów czy złego dopasowania procesora do aplikacji.

    Na koniec argumentacja typu "ludzie to lubią" to już poniżej krytyki. Fiata 125p też lubią co nie czyni z niego auta nowoczesnego ani dobrego. "Kultowe" tak.
  • #8
    LChucki
    Level 31  
    CosteC wrote:
    Na koniec argumentacja typu "ludzie to lubią" to już poniżej krytyki. Fiata 125p też lubią co nie czyni z niego auta nowoczesnego ani dobrego.

    Z jakiegoś powodu najpopularniejsze Arduino to UNO. W przeciwieństwie do PRL teraz jest wybór ale z jakiegoś powodu widzę potwory w postaci 2 x UNO zamiast MEGA.
    Z czego to wynika?
    Trzeba zapoznać się z projektami. Okazuje się, że "programista" nie potrafił na jednym uC napisać obsługi enkodera, wyświetlacza alfanumerycznego i sterowania silnikiem. Dlaczego nie potrafi? Bo używa delay, silnikiem krokowym nie steruje z PWM ale używając delay i machanie pinem. Problem zostaje rozwiązany przez użycie kilku uC, niczym Windows, jak chce się realizować dobrze kilka zadań potrzeba kilku komputerów.

    Marek_Skalski wrote:
    Byłbym ostrożny z takim stwierdzeniem.

    Zmieniłem na "wiele STM32". pisałem o późnej porze i już słowa mi się myliły.

    CosteC wrote:
    Wracając do WS2812. Przy 16 MHz jest 20 cykli zegara na bit wysyłany do WS2812. To rzeczywiście wymaga bardzo starannego kodu obsługi przerwań i procesor prawie nic nie może robić gdy ma obsługiwać długi łańcuch WS2812.

    99,99% softu obsługującego WS2812 macha pinem przy wyłączonych przerwaniach mimo iż można użyć UART lub SPI i obsłużyć je na przerwaniach ale faktycznie, CPU jest obciążony 80-90%.
  • #9
    CosteC
    Level 37  
    No to wniosek jest taki że problemy wynikają w 99.99% przypadków z niekompetencji programistów a architektura procesorów ma drugorzędne znaczenie.

    P.S. muszę się zastanowić jak WS2812 przy pomocy UARTu SPI czy innego peryferium... Może się da to elegancko zrobić.
  • #10
    tmf
    Moderator of Microcontroller designs  
    Quote:
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)

    Tytuł jest mylący - układ nie ma optoizolacji. Po obu stronach połączone są masy, dodatkowo Vcc przez rezystory podciągające na I2C. W efekcie nie wiadomo czemu ten ADM służy.
    LChucki wrote:
    - AVR mają mało UART. Jest to szczególnie odczuwalne w przypadku ArduinoUNO. Niektóre AVR mają 2 UART, nieliczne mega 4 ale to już obudowy 100pin.

    A w czym pomoże zamiana UART na I2C? Przecież I2C nie mają więcej. W dodatku o ile softwarowy UART jakoś działa, to softwarowe I2C niekoniecznie. Dla AVR dysponujących tylko USI, w ogóle nic to nie poprawi.
    Poza tym podana przez ciebie informacja nie jest prawdziwa - np. ATMega4809 ma aż 4 UARTy w obudowie 48-pinowej, a to tylko przykład.
    Quote:
    - Generator AVR musi być stabilizowany rezonatorem kwarcowym. Wbudowany RC ma zbyt małą stabilność aby wykorzystać go z UART.

    Tyle, że nowsze AVR mają generatory umożliwiające poprawną pracę po UART na wewnętrznym generatorze. Odnosisz sie do procków sprzed wielu lat.
    Quote:
    - Wbudowane FIFO nie spełnia swojej roli. Mostki mają FIFO ale co z tego jak znaki, które przyszły z USB są wysyłane do UART czy uC tego chce czy nie.

    To nie wina UART, tylko protokołu, który stworzył użytkownik. Jak na I2C nie zapewnisz odpowiedniej obsługi to efekt będzie taki sam. Wystarczy po przesłaniu paczki danych odczekać na wysłanie Ack z kontrolera/hosta.
    Quote:
    Ten problem najbardziej odczuwalny jest w Arduino z AVRmega/tiny, w którym podczas komunikacji z WS2812 czy 1-Wire zawieszane są przerwania.

    Jeśli ktoś źle napisał program to ma problem. To nie dotyczy tylko Arduino, z ATMega/Tiny. 1-wire się implementuje na UART, a nie na pinach IO. WS2812 w nowych ATMega można zaimplementować sprzętowo przy pomocy LUT, we wszystkich się to robi na SPI/UART. Znowu - jeśli programista nie potrafi programować, to lepiej niech sobie znajdzie inną pracę.
    Quote:
    - Kontrola przepływu wymaga dodatkowych GPIO uC.

    Jaka kontrola przepływu? Przecież można ja zawrzeć w protokole. Po co więc ten dodatkowy pin?
    Quote:
    - Nie można stwierdzić czy USB HOST jest przyłączony czy nie.

    Jak nie można? Przecież jeśli nie odpowiada to jest wyłączony... Można tez w FT wykorzystać dodatkowe piny informujące o stanie jeśli ktoś tego potrzebuje.
    Quote:
    - Konfigurację mostka (VID, PID, funkcje LED, itd) można przeprowadzić (o ile można bo w np CP2101 nie) tylko z poziomu komputera odpowiednią aplikacją. Nie można tego zrobić z poziomu uC.

    Nie widzę na czym miałaby polegać ta wada, bo PID/VID jest przypisany urządzeniu i nie wiem w jakim celu urządzenie miałoby go zmieniać.
    Quote:
    RM STM32, w których USB to niejako standard

    A skąd bierzesz VID/PID?
    Quote:
    O budowie urządzenia niewiele można napisać (schemat w załączniku, plik "FT201_rev2001.pdf") poza tym, że dodałem izolator galwaniczny na liniach I2C. O takiej izolacji często zapominają producenci sprzętu pomiarowego takiego jak oscyloskopy, generatory itp. Izolację zapewnia ADuM1251

    Przecież nie masz izolacji skoro masy podłączonego urządzenia, mostka i komputera są połączone...
    Quote:
    Chyba nie znasz dobrze AVR. Ciężko zrealizować na nim transmisję do WS2812 i jednocześnie odbierać dane z UART. Da się, bo zrobiłem, ale bez ASM raczej nie.

    Raczej nie jest to żadnym problemem o ile się to robi właściwie - czyli sprzętowo. Pomijam LUT w nowych ATMegach, ale wykorzystanie UART do transmisji do WS też rozwiązuje sprawę.
    Quote:
    Problemem jest to, że AVR nie mają wielopoziomowego systemu przerwań.

    Od wielu lat nie jest to prawdą. Pomijając XMEGA, to np. nowe ATMega mają 2-poziomowy system przerwań. Co zresztą do implementacji obsługi WSów nie jest potrzebne.
    Quote:
    Zapoznaj się też z dalszą argumentacją, mało UART w AVR, wymagany kwarc.

    Jak już pisałem nie masz aktualnej wiedzy na ten temat.
    Quote:
    Arduinowskie biblioteki zawieszają przerwania jak popadnie! Softwarowa realizacja interfejsów to norma!

    Jakiś problem, żeby napisać własne? Obsługa WS2812 to raptem kilkanaście linii kodu.
    Podsumowując - fajnie, ze zaprezentowałeś układ, może komuś się przyda info, że taki scalak jest. Tylko po co ta cała reszta nie na temat?

    Dodano po 3 [minuty]:

    CosteC wrote:
    P.S. muszę się zastanowić jak WS2812 przy pomocy UARTu SPI czy innego peryferium... Może się da to elegancko zrobić.

    Zobacz tu:
    http://mikrokontrolery.blogspot.com/2011/03/Diody-WS2812B-sterowanie-XMega.html
    W drugiej części jest o wykorzystaniu sprzętu, w kolejnych więcej na ten temat.
    A tu:
    https://www.elektroda.pl/rtvforum/topic3411874.html
    masz moje DIY, co prawda z XMEGA, ale da się to wprost przenieść na nowe ATMega, a nawet lepiej, bo mając LUT można to prościej zaimplementować.
  • #11
    LChucki
    Level 31  
    tmf wrote:
    Tytuł jest mylący - układ nie ma optoizolacji. Po obu stronach połączone są masy, dodatkowo Vcc przez rezystory podciągające na I2C. W efekcie nie wiadomo czemu ten ADM służy.

    GND i GND_I to nie to samo podobnie jak Vcc i +5V.

    tmf wrote:
    A w czym pomoże zamiana UART na I2C? Przecież I2C nie mają więcej

    Możesz przez UART skonfigurować VID, PID, deskryptor, funkcje LED, dostac się do EEPROM w FTDI?

    tmf wrote:
    W dodatku o ile softwarowy UART jakoś działa, to softwarowe I2C niekoniecznie.

    Raczej na odwrót.

    tmf wrote:
    To nie wina UART, tylko protokołu, który stworzył użytkownik

    Zmuś mają tylko TX i RX aby znaki z FTDI nie przychodziły do uC aby ich nie stracić.

    tmf wrote:
    Jaka kontrola przepływu? Przecież można ja zawrzeć w protokole. Po co więc ten dodatkowy pin?

    CTRS, RTS, DSR, DTR ale i tu jest pułapka.

    tmf wrote:
    Jak nie można? Przecież jeśli nie odpowiada to jest wyłączony... Można tez w FT wykorzystać dodatkowe piny informujące o stanie jeśli ktoś tego potrzebuje.

    Jeśli można to i tak trzeba stracić kolejny GPIO w uC. Używając FT201 wszystko robi się przez I2C.

    tmf wrote:
    Przecież nie masz izolacji skoro masy podłączonego urządzenia, mostka i komputera są połączone...

    Wktaż mi to połączenie na schemacie.

    tmf wrote:

    Nie widzę na czym miałaby polegać ta wada, bo PID/VID jest przypisany urządzeniu i nie wiem w jakim celu urządzenie miałoby go zmieniać.

    VID, PID może nie koniecznie ale deskryptor?
    Funkcje GPIO w FTDI?
    Nigdy tego nie zmieniasz?

    tmf wrote:
    Jakiś problem, żeby napisać własne? Obsługa WS2812 to raptem kilkanaście linii kodu.

    Pokaż te kilkanaście linii kodu.

    tmf wrote:
    Od wielu lat nie jest to prawdą. Pomijając XMEGA, to np. nowe ATMega mają 2-poziomowy system przerwań.

    Nadal najpopularniejsze Arduino to UNO i Mega a jakie sa tam AVR każdy wie.
    Zresztą porównaj liczbę projektów ze starymi i nowymi AVR. Przepaść, nowe AVR to jakieś promile.
    Co do Xmega to szkoda się wypowiadać, cena ARM, możliwości AVR z nico lepszymi peryferiami.
    Ile projektów na Xmega w stosunku do timy/mega jest? tez jakieś promile.

    Dodano po 4 [minuty]:

    Pokaż mi połączenie mas i zasilania na PCB
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM) Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    ja ich nie widzę.
  • #12
    tmf
    Moderator of Microcontroller designs  
    LChucki wrote:
    GND i GND_I to nie to samo podobnie jak Vcc i +5V.

    Ok, masz rację. To popraw schemat i wyprowadź te napięcia na listwę od strony MCU. Bo tak można przez nieuwagę je zostawić niepodłączone.
    LChucki wrote:
    Możesz przez UART skonfigurować VID, PID, deskryptor, funkcje LED, dostac się do EEPROM w FTDI?

    Ale po co? Nigdy w żadnym projekcie nie potrzebowałem takiej możliwości i trudno mi sobie wyobrazić sensowny powód dla którego miałbym to zmieniać w gotowym układzie.
    LChucki wrote:
    Zmuś mają tylko TX i RX aby znaki z FTDI nie przychodziły do uC aby ich nie stracić.

    Przecież skoro przychodzą pomimo przepełnienia FIFO i prowadzi to do błędów to jest to ewidentna wina programisty. Jeśli po I2C będę wysyłał znaki ignorując stan magistrali to też nic z tego nie wyjdzie...
    LChucki wrote:
    CTRS, RTS, DSR, DTR ale i tu jest pułapka.

    Nie pisałem o pełnym interfejsie. Kontrolę można zawrzeć w samym protokole i nie potrzeba więcej niż 2 pinów. Mało tego, w przeciwieństwie do I2C można nawet połączyć FT z MCU przy pomocy jednego pinu - patrz np. interfejs debugWire. Więc można powiedzieć,stosując twoją argumentację, że UART jest lepszy niż I2C bo potrzebuje tylko jednego pinu.
    LChucki wrote:
    Jeśli można to i tak trzeba stracić kolejny GPIO w uC. Używając FT201 wszystko robi się przez I2C.

    Jeśli komuś jest niezbędna informacja o stanie podłączenia FT-USB. To wszystko można zawrzeć w protokole MCU-PC bez konieczności angażowania hardware.
    LChucki wrote:
    VID, PID może nie koniecznie ale deskryptor?
    Funkcje GPIO w FTDI?
    Nigdy tego nie zmieniasz?

    Nie. Po co miałbym zmieniać deskryptor USB w urządzeniu? Tym bardziej, że w większości FT niewiele tam się da zmienić - nazwę, maksymalny prąd i parę innych parametrów związanych z hardware. Podobnie GPIO - żeby z nich korzystać musi być wsparcie hardwarowe, w gotowym urządzeniu schemat połączeń się nie zmienia, nie za bardzo istnieje potrzeba rekonfiguracji tych pinów. Podaj jakiś przykład.
    LChucki wrote:
    Pokaż te kilkanaście linii kodu.

    Podałem w poprzednim poście linki do moich arytkułów o WS, w których jest pokazany kod.
    Faktem jest, że z tymi kilkunastoma liniami kodu mocno przesadziłem... faktycznie jest ich dziewięć, a więc kilka.
    LChucki wrote:
    Nadal najpopularniejsze Arduino to UNO i Mega a jakie sa tam AVR każdy wie.
    Zresztą porównaj liczbę projektów ze starymi i nowymi AVR. Przepaść, nowe AVR to jakieś promile.

    A jaki to ma znaczenie? Trzeba było napisać, że AVRy wprowadzone na rynek ponad 20 lat temu mają jednopoziomowy system przerwań, a w AVR wprowadzonych na rynek zaledwie kilka lat temu system przerwań jest 2- lub 3-poziomowy i to byłaby prawda.
    Idąc za twoim argumentem, podałbym przykład '51 dla porównania i to tego z lat 80-tych, bo przecież ilościowo ciągle biją na głowę AVRy.
  • #13
    LChucki
    Level 31  
    tmf wrote:

    LChucki wrote:
    GND i GND_I to nie to samo podobnie jak Vcc i +5V.

    Ok, masz rację. To popraw schemat i wyprowadź te napięcia na listwę od strony MCU. Bo tak można przez nieuwagę je zostawić niepodłączone.

    Cztery linie złącza J4 przyłączone są do ADuM1251, co tu poprawiać? Co jest nieczytelne? Co można pominąć przy podłączaniu?


    tmf wrote:

    LChucki wrote:
    Możesz przez UART skonfigurować VID, PID, deskryptor, funkcje LED, dostac się do EEPROM w FTDI?

    Ale po co? Nigdy w żadnym projekcie nie potrzebowałem takiej możliwości i trudno mi sobie wyobrazić sensowny powód dla którego miałbym to zmieniać w gotowym układzie.

    Nigdy nie używałeś FT_PROG?
    Nigdy nie zmieniałeś funkcji GPIO w FTDI, np sygalizacji TX, RX itp LEDami?
    Nigdy nie zmieniłeś deskryptora aby po nim w aplikacji znaleźć układ?


    tmf wrote:

    LChucki wrote:
    Zmuś mają tylko TX i RX aby znaki z FTDI nie przychodziły do uC aby ich nie stracić.

    Przecież skoro przychodzą pomimo przepełnienia FIFO i prowadzi to do błędów to jest to ewidentna wina programisty. Jeśli po I2C będę wysyłał znaki ignorując stan magistrali to też nic z tego nie wyjdzie...

    Napisze inaczej. Na jak długo w AVR możesz zawiesić przerwania przesyłając po UART z prędkością 460300?
    Używając FT201 bez problemu możesz zawiesić na obliczony czas * 256.
    Widać różnicę?


    tmf wrote:

    LChucki wrote:
    CTRS, RTS, DSR, DTR ale i tu jest pułapka.

    Nie pisałem o pełnym interfejsie. Kontrolę można zawrzeć w samym protokole i nie potrzeba więcej niż 2 pinów.

    To się nazywa soft handshaking czy tam soft flow control ale wymaga dodatkowych nakładów pracy przy pisaniu programu. Softwarowe rozwiązanie ma też wady, np przesyłanie tylko kodów ASCII. Transmisja BIN tez jest możliwa ale spada przepływność, no chyba, ze szczęśliwie dwa znaki używane do flow control nie występują w plikach BIN.


    tmf wrote:

    Mało tego, w przeciwieństwie do I2C można nawet połączyć FT z MCU przy pomocy jednego pinu - patrz np. interfejs debugWire.

    O czym piszesz? Jaki debugWire?
    Microchip udostępnił protokół?
    Jeśli nawet, to zatrzymujesz CPU?
    napisz jak to działa bo jeszcze nie widziałem aby ktokolwiek podłączał peryferia przez debugWire no i pokaż mi FTDI, który w ten sposób przesyła dane.


    tmf wrote:

    LChucki wrote:
    Jeśli można to i tak trzeba stracić kolejny GPIO w uC. Używając FT201 wszystko robi się przez I2C.

    Jeśli komuś jest niezbędna informacja o stanie podłączenia FT-USB. To wszystko można zawrzeć w protokole MCU-PC bez konieczności angażowania hardware.

    Dodatkowy nakład pracy, zmniejszenie przepływności danych.


    tmf wrote:

    LChucki wrote:
    VID, PID może nie koniecznie ale deskryptor?
    Funkcje GPIO w FTDI?
    Nigdy tego nie zmieniasz?

    Nie. Po co miałbym zmieniać deskryptor USB w urządzeniu?

    Po to aby znaleźć urządzenie po deskryptorze. Tak działają niektóre interfejsy DMX i masa innych urządzeń wykonywanych zarówno przez amatorów jak i produkowanych seryjnie np glukometry.
    Jak masz 20 urządzeń z FTDI to skąd wiesz, które jest które? Odpytujesz wszystkie o czekasz na określony ciąg? A co jak urządzenie nie twojej produkcji zareaguje na zapytanie i wykona akcję?
    Nie prościej, szybciej, bezpieczniej wylistować wszystkie urządzenia USB i przez deskryptor (przyjazna nazwa) skomunikować się z wybranym urządzeniem?


    tmf wrote:

    Tym bardziej, że w większości FT niewiele tam się da zmienić - nazwę, maksymalny prąd i parę innych parametrów związanych z hardware. Podobnie GPIO - żeby z nich korzystać musi być wsparcie hardwarowe, w gotowym urządzeniu schemat połączeń się nie zmienia, nie za bardzo istnieje potrzeba rekonfiguracji tych pinów. Podaj jakiś przykład.

    Osobne LED TX i RX. Domyślnie FTDI ma np RX+TX.


    tmf wrote:

    LChucki wrote:
    Pokaż te kilkanaście linii kodu.

    Podałem w poprzednim poście linki do moich arytkułów o WS, w których jest pokazany kod.
    Faktem jest, że z tymi kilkunastoma liniami kodu mocno przesadziłem... faktycznie jest ich dziewięć, a więc kilka.

    I zadziała to na Tiny/mega bez wstawki ASM?
    Pewnie zadziała ale CPU obciążone na 98%.

    Dodano po 18 [minuty]:

    Nie napisałem o EEPROM. Dostajemy w tej samej cenie co FT232RL ok 1kB EEPROM. Powiadasz, mam w AVR. Ale jak wymienisz na PCB uC (np uszkodzenie) to zawartość eeprom tracisz, prawda? Można więc w FTDI trzymać kopie EEPROM uC albo klucze licencji, licznik czasu pracy, jakieś zabezpieczenia. Mało które STM32 mają EEPROM a emulowanie nie zawsze jest takie oczywiste gdy strona to 16kB. Używając FTDI, bo inaczej tanio nie zrobisz izolacji galwanicznej masz 1k EEPROM o ile użyjesz FT20x/FT22x mostka z UART.
    EEPROM jest dostępny dla hosta przez biblioteki D2XX ale pewnie nie używałeś dlatego nie wiesz co można nimi robić. W urządzeniach, które projektowałem w deskryptorze był zawarty unikalny identyfikator. HOST nie dość, że w prosty sposób znajduje urządzenie to dodatkowo, gdy jest kilka tego samego rodzaju (np GPIO) to wie, który jest który. Wystarczy że raz host przypisze ID urządzenia i nie ważne, do którego portu USB zostanie podłączone, host wie, które jest które. W przypadku VCOM, wiadomo jak to jest z numeracją czyli nic nie wiadomo, zwykła loteria.


    Wydaje mi się, że nie robiłeś urządzenia komercyjnego z FTDI. Ja zrobiłem nie jedno i gdy używałem FT230 to trzeba było używać FT_PROG. Zmieniany był właśnie deskryptor, bo po nim szukano urządzenia, tym bardziej, że było kilka z FTDI oraz funkcje GPIO. Dzięki wykorzystaniu FT20x/FT22x cena uruchomienia urządzenia spadła, bo wystarczy wgrać program do uC a on skonfiguruje FTDI. W przypadku mostków z UART trzeba programować uC i FTDI - podwójna robota.
  • #14
    tmf
    Moderator of Microcontroller designs  
    LChucki wrote:
    tmf napisał:

    LChucki napisał:
    Możesz przez UART skonfigurować VID, PID, deskryptor, funkcje LED, dostac się do EEPROM w FTDI?


    Ale po co? Nigdy w żadnym projekcie nie potrzebowałem takiej możliwości i trudno mi sobie wyobrazić sensowny powód dla którego miałbym to zmieniać w gotowym układzie.


    Nigdy nie używałeś FT_PROG?
    Nigdy nie zmieniałeś funkcji GPIO w FTDI, np sygalizacji TX, RX itp LEDami?
    Nigdy nie zmieniłeś deskryptora aby po nim w aplikacji znaleźć układ?

    Oczywiście, właśnie FT_PROG używałem, więc po co niby MCU miałby go zastępować? To jest jednorazowa operacja.
    LChucki wrote:
    tmf napisał:

    LChucki napisał:
    Zmuś mają tylko TX i RX aby znaki z FTDI nie przychodziły do uC aby ich nie stracić.


    Przecież skoro przychodzą pomimo przepełnienia FIFO i prowadzi to do błędów to jest to ewidentna wina programisty. Jeśli po I2C będę wysyłał znaki ignorując stan magistrali to też nic z tego nie wyjdzie...


    Napisze inaczej. Na jak długo w AVR możesz zawiesić przerwania przesyłając po UART z prędkością 460300?
    Używając FT201 bez problemu możesz zawiesić na obliczony czas * 256.
    Widać różnicę?

    A jakie to ma zanczenie? Naprawde nie wiesz jak taki protokół wygląda? Bo próbujesz udowodnić, że magistrale takie jak np. RS485 nie mają prawa działać, bo skąd master wie, że slave może przyjąć dane?
    LChucki wrote:
    tmf napisał:

    LChucki napisał:
    CTRS, RTS, DSR, DTR ale i tu jest pułapka.


    Nie pisałem o pełnym interfejsie. Kontrolę można zawrzeć w samym protokole i nie potrzeba więcej niż 2 pinów.


    To się nazywa soft handshaking czy tam soft flow control ale wymaga dodatkowych nakładów pracy przy pisaniu programu. Softwarowe rozwiązanie ma też wady, np przesyłanie tylko kodów ASCII. Transmisja BIN tez jest możliwa ale spada przepływność, no chyba, ze szczęśliwie dwa znaki używane do flow control nie występują w plikach BIN.

    O czym ty piszesz? Master wysyła dane, slave potwierdza, master wysyła dane, slave potwierdza. Parę linii kodu to faktycznie gigantyczny nakład pracy. To czy dane są w postaci tekstowej, czy binarnej jest bez znaczenia. Przepływność nie spada, bo UART jest full-duplex, w przeciwieństwie do I2C, więc potwierdzenia można przesyłać niezależnie od odbioru danych.
    LChucki wrote:
    tmf napisał:

    Mało tego, w przeciwieństwie do I2C można nawet połączyć FT z MCU przy pomocy jednego pinu - patrz np. interfejs debugWire.


    O czym piszesz? Jaki debugWire?
    Microchip udostępnił protokół?
    Jeśli nawet, to zatrzymujesz CPU?
    napisz jak to działa bo jeszcze nie widziałem aby ktokolwiek podłączał peryferia przez debugWire no i pokaż mi FTDI, który w ten sposób przesyła dane.

    Rozmiem, że na siłę starasz się coś udowodnić, jednak, z szacunku dla samego siebie, nie rób przy tym z siebie osobę nieporadną, o wiedzy mniejszej niż początkujący. Naprawdę nie wiesz jak przesłać dane po jednym przewodzie przy pomocy UART, w trybie half-duplex? debugWire jest przykładem realizacji tego i owszem, jeśli ktoś potrzebuje to i strona hardwarowa i softwarowa jest opisana w notach Atmela. Jedyne czego nie ma, to pokazania pełnej implementacji wyższych warstw protokołu. debugWire jest tylko przykładem, że się da i jest to wykorzystywane.
    Nie widzę po co miałoby to wstrzymywać MCU.
    LChucki wrote:
    tmf napisał:

    LChucki napisał:
    Pokaż te kilkanaście linii kodu.


    Podałem w poprzednim poście linki do moich arytkułów o WS, w których jest pokazany kod.
    Faktem jest, że z tymi kilkunastoma liniami kodu mocno przesadziłem... faktycznie jest ich dziewięć, a więc kilka.


    I zadziała to na Tiny/mega bez wstawki ASM?
    Pewnie zadziała ale CPU obciążone na 98%.

    Zaglądałeś w kod? Wie wierzę, że te 9 linii cię przerosło. Asemblera tam nie ma, bez obaw.

    Dodano po 9 [minuty]:

    LChucki wrote:
    Nie napisałem o EEPROM. Dostajemy w tej samej cenie co FT232RL ok 1kB EEPROM. Powiadasz, mam w AVR. Ale jak wymienisz na PCB uC (np uszkodzenie) to zawartość eeprom tracisz, prawda? Można więc w FTDI trzymać kopie EEPROM uC albo klucze licencji, licznik czasu pracy, jakieś zabezpieczenia.

    Tak, a jak padnie FTDI to stracę te dane, podobnie jak w przypadku ich trzymania w MCU. Już widzę, jak ktoś się bawi w synchronizację danych pomiędzy FTDI i MCU, tym bardziej osoba, dla której parę linii kodu to problem.
    LChucki wrote:
    EEPROM jest dostępny dla hosta przez biblioteki D2XX ale pewnie nie używałeś dlatego nie wiesz co można nimi robić.

    Tak, jesteś pierwszą osobą na świecie, która odkryła, że biblioteka D2XX daje większe możliwości :)
    LChucki wrote:
    Mało które STM32 mają EEPROM a emulowanie nie zawsze jest takie oczywiste gdy strona to 16kB.

    Straszne, to twoje ukochane STMy mają wady? Byc nie może.
    LChucki wrote:
    Zmieniany był właśnie deskryptor, bo po nim szukano urządzenia, tym bardziej, że było kilka z DTFI oraz funkcje GPIO.

    Wiesz, ale identyfikacja urządzenia po samej nazwie to raczej amatorstwo. Jak sobie wrzucę dwa FTDI o takiej samej nazwie, to co twój program zrobi?
    LChucki wrote:
    ak masz 20 urządzeń z FTDI to skąd wiesz, które jest które? Odpytujesz wszystkie o czekasz na określony ciąg? A co jak urządzenie nie twojej produkcji zareaguje na zapytanie i wykona akcję?

    Jak być może nie wiesz, idea USB jest taka, żeby urządzenia identyfikować po VID/PID, dzięki czemu OS może załadować odpowiedni sterownik.
    LChucki wrote:
    A co jak urządzenie nie twojej produkcji zareaguje na zapytanie i wykona akcję?

    To znaczy, że oprogramował je jakiś niepełnosprawny intelektualnie programista. Korzystając ze wspólnego VID/PID udostępnianego przez FTDI, trzeba zadbać o to, aby takie sytuacje nie miały miejsca. Dlatego właśnie potrzebna jest dodatkowa identyfikacja na poziomie protokołu. Jeśli oprogramowanie jest tak napisane, że przypadkowe dane mogą wpłynąć na jego działanie to niezbyt dobrze to świadczy o programiście.
  • #15
    LChucki
    Level 31  
    tmf wrote:
    Oczywiście, właśnie FT_PROG używałem, więc po co niby MCU miałby go zastępować?

    Bo jak programujesz 1000 szt to robisz to kilka razy szybciej.
    Praca z FT_PROG:
    - zaprogramuj uC.
    - scan w FT_PROG
    - wskaż układ FTDI jeśli jest ich kilka
    - zaprogramuj FTDI - zakładam, że mam już wczytany plik w XML
    - wywołaj enumerację, sprawdź czy wszystko ok.

    Bez FT prog:
    - zaprogramuj uC.
    - wywołaj enumerację, sprawdź czy wszystko ok.

    Widzisz różnicę?


    tmf wrote:
    A jakie to ma zanczenie? Naprawde nie wiesz jak taki protokół wygląda?

    Twierdzisz, że możesz na dłużej zawiesić przerwania w przypadku komunikacji przez UART niż przez I2C?
    Przy 460800 AVR może zawiesić przerwania na ok 42us w przeciwnym wypadku znaki przepadną. Arduino potrafi zawiesić przerwania na nawet kilkadziesiąt ms! W przypadku FT20x nie mam limitu 42us. Minimum to 10ms zakładając przepływność 460800.
    To duże uproszczenie. Dokładniej może być tak:
    - Przypuśćmy, że po USB co 1ms wysyłane jest 10 znaków. Mostek z UART odbiera te znaki i zapisuje do FIFO, po czym wysyła po UART. uC ma akurat zawieszone przerwania 8 znaków przepada. Wystarczyło zwiesić przerwania na 210us. Napiszesz kontrola przepływu ale aplikacja nie jest moja i nie mogę zatrzymać wysyłania danych.
    - Ta sam sytuacja, zawiesiłem przerwania na 50ms (ok 240 razy dłużej niż w poprzednim przypadku!). Znaki trafiają do FIFO w FTDI ale uC nie odpytuje go bo coś tam robi. W 50 ms w FIFO znajdzie się 500 znaków. Bez problemu te 500 znaków można odczytać z FIFO FTDI.
    tmf wrote:
    Naprawdę nie wiesz jak przesłać dane po jednym przewodzie przy pomocy UART

    Pokaż mi mostek USB, który ma dwukierunkowa transmisję po jednym drucie!

    tmf wrote:
    W FTDI wystarczy połączyć RX z Tx i analogicznie po stronie MCU

    I to jest full duplex?
    Ponadto nadal zużywasz 2 wyprowadzenia uC w przypadku AVRmega/tiny (nie wiem jak Xmega, bo STM32 może takie zapętlenie zrobić wewnątrz uC).


    W I2C nie ma z tym problemu, zauważ, że np 100 bajtów UART z prędkością 9600 przesyła się ok 100ms. Te same 100 bajtów po I2C 400kHz prześlę przez ok 2,3ms! Nie ma więc problemu aby wysłać 100 bajtów po I2C w 2,3ms i odebrać 100 w kolejne 2,3ms, razem 4,6ms. Jak prędkość jest większa niż 9600, to FT201 działa do 3,4MHz, no ale AVR nie da rady. Wtedy trzeba sięgnąć po FT22x, SPI do 25MHz, AVRtimy/mega realnie wyciągnie ok 5M ale to pozwoli bez problemu w krótkim czasie przesyłać dane z max prędkością USB FTDI 1Mb/s w obie strony.
  • #16
    Marek_Skalski
    VIP Meritorious for electroda.pl  
    LChucki wrote:
    Bo jak programujesz 1000 szt

    Jak ktoś planuje produkcję niewielkich serii, to na pewno nie takich urządzeń, gdzie VID i PID jest ogólnej puli. Do takich celów kupuje się VID i PID w usb.org. Chyba, że ktoś lubi ryzyko i wypuszcza na rynek urządzenie, które nie jest zgodne z USB i świadomie łamie prawo, ale podobno takie rzeczy to tylko w Chinach.

    LChucki wrote:
    I to jest full duplex?

    Całkiem niedawno mieliśmy tutaj dyskusję na temat full-duplex, half-duplex. Kolega coś przegapił?

    LChucki wrote:
    zauważ, że np 100 bajtów UART z prędkością 9600 przesyła się ok 100ms. Te same 100 bajtów po I2C 400kHz prześlę przez ok 2,3ms!

    A jakby zamienić i przesyłać dane po I2C z prędkością 9600, a po UART z prędkością 400000, to UART będzie szybszy. Oba protokoły przesyłają dane szeregowo, bit za bitem. W dodatku UART może przesyłać dane w obie strony niezależnie, a I2C ma tylko jedną linię danych i jeżeli trwa transfer z Mastera do Slave'a, to w drugą stronę nie można nic przesłać. Proszę nam wytłumaczyć, jaka logika przyświeca temu porównaniu? Chętnie dowiem się czegoś nowego.
  • #17
    Patrick_30
    Level 10  
    Czy FT201 można użyć jako sniffer i2c? Chodzi mi o to by na żywo zobaczyć co się dzieje na magistrali.
  • #18
    tmf
    Moderator of Microcontroller designs  
    LChucki wrote:
    Bo jak programujesz 1000 szt to robisz to kilka razy szybciej.

    Jeśli programuję takie ilości to zamawiam preprogramowane elementy, lub programuję EEPROM przed wlutowaniem. Przecież gdyby to miał robić MCU to musiałbym mieć program, który po pierwszym uruchomieniu jest zbędny. Zresztą i tak zostaje mi programowanie 1000 MCU.
    LChucki wrote:
    tmf napisał:
    A jakie to ma zanczenie? Naprawde nie wiesz jak taki protokół wygląda?
    Po pierwsze zakładasz szybkości transmisji normalnie nieużywane. W większości zastosowań używa się 9600-19200 bps. Jeśli ktoś potrzebuje przesyłać duże ilości danych to o wiele szybciej jest wybrać procesor z USB i sobie to od początku właściwie oprogramować. Zresztą nawet jakby to co się stanie? Od tego są wyższe warstwy OSI, żeby sobie poradzić.
    LChucki wrote:
    - Przypuśćmy, że po USB co 1ms wysyłane jest 10 znaków. Mostek z UART odbiera te znaki i zapisuje do FIFO, po czym wysyła po UART. uC ma akurat zawieszone przerwania 8 znaków przepada. Wystarczyło zwiesić przerwania na 210us. Napiszesz kontrola przepływu ale aplikacja nie jest moja i nie mogę zatrzymać wysyłania danych.




    Twierdzisz, że możesz na dłużej zawiesić przerwania w przypadku komunikacji przez UART niż przez I2C?
    Przy 460800 AVR może zawiesić przerwania na ok 42us w przeciwnym wypadku znaki przepadną. Arduino potrafi zawiesić przerwania na nawet kilkadziesiąt ms! W przypadku FT20x nie mam limitu 42us. Minimum to 10ms zakładając przepływność 460800.

    Aplikacja nie jest twoja, ale urządzenie jest twoje? Trochę to wydumane, niesądzisz? Ale nawet jakby, to w czym problem? Kto ci każe zawieszać przerwania? Jeśli tak napisałeś program, to do kogo masz pretensje?
    LChucki wrote:
    - Ta sam sytuacja, zawiesiłem przerwania na 50ms (ok 240 razy dłużej niż w poprzednim przypadku!). Znaki trafiają do FIFO w FTDI ale uC nie odpytuje go bo coś tam robi. W 50 ms w FIFO znajdzie się 500 znaków. Bez problemu te 500 znaków można odczytać z FIFO FTDI.

    Źle napisałeś program, co ma być dowodem na jakąś tezę?
    LChucki wrote:
    tmf napisał:
    Naprawdę nie wiesz jak przesłać dane po jednym przewodzie przy pomocy UART


    Pokaż mi mostek USB, który ma dwukierunkowa transmisję po jednym drucie!

    Każdy? Przecież to nie jest funkcja mostka. Tx musi być OD, jeśli nie ma bezpośrednio możliwości to potrzebny jest tranzystor, łączysz z Rx i załatwione.
    LChucki wrote:
    tmf napisał:
    W FTDI wystarczy połączyć RX z Tx i analogicznie po stronie MCU


    I to jest full duplex?
    Ponadto nadal zużywasz 2 wyprowadzenia uC w przypadku AVRmega/tiny (nie wiem jak Xmega, bo STM32 może takie zapętlenie zrobić wewnątrz uC).

    Potrafisz przeczytać dłuższy tekst, czy każde <CR><LF> resetuje ci bufor?:) Przecież napisałem, że w takim przypadku jest half-duplex, czyli dokładnie tak samo jak na I2C. Co do zapętlenia - tak, nowe ATMega, ATTiny, XMEGA e5 robią to wewnętrznie. Nazywa się to tryb 1-wire i polega właśnie na wewnętrznym połączeniu Tx i Rx.
    LChucki wrote:
    W I2C nie ma z tym problemu, zauważ, że np 100 bajtów UART z prędkością 9600 przesyła się ok 100ms. Te same 100 bajtów po I2C 400kHz prześlę przez ok 2,3ms!

    Po pierwsze to niczego nie dowodzi, bo szybkości transmisji sobie mogę zmieniać. Poza tym w I2C owszem, przy założonych przez ciebie parametrach, te 100 bajtów prześlę szybciej, tylko to nie będzie użytecznych 100 bajtów. Po pierwsze mam narzut protokołu - start, adres, dane, stop, a więc realna szybkość przesyłu danych jest znacznie niższa niż w przypadku UART, gdzie narzut może być tak mały jak 20%. Po drugie, mogę sobie zrobić UART o wiele szybszy, co w przypadku I2C niekoniecznie jest możliwe, wiele MCU nie obsługuje taktowania I2C powyżej 400 kHz.
    Poza tym MCU musi FT221 odpytywać, zeby sprawdzić czy nie nadeszły jakieś dane, odpada więc automatyczne wybudzanie.
  • #19
    LChucki
    Level 31  
    Patrick_30 wrote:
    Czy FT201 można użyć jako sniffer i2c? Chodzi mi o to by na żywo zobaczyć co się dzieje na magistrali.

    Nie.


    tmf wrote:
    Poza tym MCU musi FT221 odpytywać, zeby sprawdzić czy nie nadeszły jakieś dane, odpada więc automatyczne wybudzanie.

    Nie zapoznałeś się z nota FT201 i piszesz nieprawdę.
    Może zanim zaczniesz dyskutować przeczytaj jak działa FT201 bo nic o nim nie wiesz, twierdzisz, że UART 9600 przesle danej szybciej niż I2C 400kHz. Dajesz złe przykłady
    Quote:

    start, adres, dane, stop,

    co jest ewidentna bzdurą, bo można:
    start, adres, dane * 512, stop,
    i narzut nie jest 20% jak piszesz ale poniżej 0,3%.

    tmf wrote:
    Po drugie, mogę sobie zrobić UART o wiele szybszy, co w przypadku I2C niekoniecznie jest możliwe, wiele MCU nie obsługuje taktowania I2C powyżej 400 kHz.

    To trzeba wybierać uC, który może taktować szybciej a jak już koniecznie zapierasz się przy AVRmega/tiny to, o czym już pisałem, możesz użyć FT22x z SPI.


    Zapoznaj się z AN FT201, bo bez wiedzy tam zawartej dalsza dyskusja jest bezsensowna. Nie wiesz, że można odczytać liczbę bajtów w FIFO i zamiast odczytywać po bajcie, ciągle adresując slave i generując start i stop, odczytać na raz cały bufor. Z nadawaniem to samo i nawet nie zadałeś sobie trudu obejrzenia oscylogramu, który załączyłem, bo byś widział, że generowany jest start, adres a po nim wiele danych.
  • #20
    tmf
    Moderator of Microcontroller designs  
    LChucki wrote:
    tmf napisał:
    Poza tym MCU musi FT221 odpytywać, zeby sprawdzić czy nie nadeszły jakieś dane, odpada więc automatyczne wybudzanie.

    Nie zapoznałeś się z nota FT201 i piszesz nieprawdę.

    Może jednak ty się najpierw zapoznaj. Z noty, str. 15 "The FT201X device shall only be able to operate as a slave" - niby więc jak FT20x miałby poinformować MCU, że są nowe dane? Tylko przez jego piny CBUS, odpowiednio przeprogramowane, ale przecież miało być połączenie z MCU tylko przez 2 piny. Więc jak?
    LChucki wrote:
    Może zanim zaczniesz dyskutować przeczytaj jak działa FT201 bo nic o nim nie wiesz, twierdzisz, że UART 9600 przesle danej szybciej niż I2C 400kHz. Dajesz złe przykłady

    Cytat:

    start, adres, dane, stop,


    co jest ewidentna bzdurą, bo można:
    start, adres, dane * 512, stop,
    i narzut nie jest 20% jak piszesz ale poniżej 0,3%.

    Też sobie mogę jakieś nierealistyczne przykłady podać. Układ wymaga, aby przy każdym odczycie przechodzić sekwencję start+adres, sprawdzenie ACK i ew. odczytanie bajtu danych (ponad 50% narzut protokołu), lub alternatywnie odczytanie liczby bajtów w buforze + bufora w trybie burst, narzut w zależności od ilości bajtów do odczytania to od 100% do >13% jeśli odczytujemy cały bufor. Nie wiem jak ci wyszło 0,3%, skoro przesłanie 1 bajta danych na I2C wymaga czasu co najmniej 9 bitów, a więc masz narzut co najmniej 12,5%. Ciągle też pozostaje problem tego, że I2C jest half-duplex, a UART full-duplex, w efekcie w sprzyjających warunkach mogę transmitować 2x więcej danych, przy takim samym taktowaniu.
    LChucki wrote:
    tmf napisał:
    Po drugie, mogę sobie zrobić UART o wiele szybszy, co w przypadku I2C niekoniecznie jest możliwe, wiele MCU nie obsługuje taktowania I2C powyżej 400 kHz.


    To trzeba wybierać uC, który może taktować szybciej a jak już koniecznie zapierasz się przy AVRmega/tiny to, o czym już pisałem, możesz użyć FT22x z SPI.

    Tak, równie dobrze mogę sobie wybrać procesor dla którego nie będę potrzebował powyższego układu, więc argument z czapy.
    LChucki wrote:
    apoznaj się z AN FT201, bo bez wiedzy tam zawartej dalsza dyskusja jest bezsensowna. Nie wiesz, że można odczytać liczbę bajtów w FIFO i zamiast odczytywać po bajcie, ciągle adresując slave i generując start i stop, odczytać na raz cały bufor. Z nadawaniem to samo i nawet nie zadałeś sobie trudu obejrzenia oscylogramu, który załączyłem, bo byś widział, że generowany jest start, adres a po nim wiele danych.

    Czyli standardowa funkcjonalność slave I2C. I co z tego, skoro przy odczycie sekwencyjnym nie wiesz, kiedy przestać o ile wcześniej nie odczytałeś z układu liczby bajtów w FIFO. A to z kolei powoduje przy krótkich pakietach duże narzuty. W dodatku musisz cyklicznie odpytywać układ, bo nie masz info, że coś czeka na odebranie, o ile nie wykorzystasz dodatkowych pinów. W efekcie argument o rzekomej wyższości takiego połączenia z MCU w stosunku do UART jest co najmniej wątpliwy.
  • #21
    Janusz_kk
    Level 36  
    LChucki wrote:
    Ta sam sytuacja, zawiesiłem przerwania na 50ms (ok 240 razy dłużej niż w poprzednim przypadku!).

    W swoim programie zawieszasz przerwania na 50ms!!! po co? co takiego ważnego procek musi zrobić żeby tyle blokować przerwania.
  • #22
    LChucki
    Level 31  
    tmf wrote:
    Może jednak ty się najpierw zapoznaj. Z noty, str. 15 "The FT201X device shall only be able to operate as a slave" - niby więc jak FT20x miałby poinformować MCU, że są nowe dane? Tylko przez jego piny CBUS, odpowiednio przeprogramowane, ale przecież miało być połączenie z MCU tylko przez 2 piny. Więc jak?

    Wynajdujesz jakieś problemy, typu uśpic się nie da, to pisze jakie jest rozwiązanie. Wtedy wynajdujesz kolejny problem i tak zabawa może trwac wieki. Zaraz napiszesz, ze potrzebne dwa dodatkowe rezystory do podciągania I2C a gdy używasz uart to są niepotrzebne.
    Dalszego sensu takiej dyskusji nie widzę, bo na siłe chcesz udowodnić, ze UART jest lepszy.
    Jak będę chciał to udowodnię, że Z-80 jest lepszy od ARM. Z pewnością znajdę jakiś argument, np skalowalność.
    Problem dodatkowej linii można rozwiązać banalnie konwerterami I2C-OneWire.
    Co teraz wymyślisz?

    tmf wrote:
    Też sobie mogę jakieś nierealistyczne przykłady podać. Układ wymaga, aby przy każdym odczycie przechodzić sekwencję start+adres, sprawdzenie ACK i ew. odczytanie bajtu danych (ponad 50% narzut protokołu),

    Niech ten narzut będzie i 100%. Co z tego skoro szybciej wykonam operacje?
    Standardowo UART w AVR nie przekracza 115200. Bez problemu I2C na AVR zadziała 400kb/s a i 800 nie jest problemem. Mimo więc narzutu I2C będzie szybsze. Wiem, ze zaraz coś wynajdziesz np:
    tmf wrote:
    w efekcie w sprzyjających warunkach mogę transmitować 2x więcej danych, przy takim samym taktowaniu.

    Napisz mi kiedy AVRem ma ciągłą transmisję w obie strony bez przerwy z duża prędkością. Czy nie jest raczej tak, ze wysyłasz niewielkie ilości danych stosunkowo rzadko?
    Znów wynajdujesz jakiś problem, z którym się spotka 0,01% użytkowników Arduino czy AVR. Do ciągłego przesyłania szybko dużej ilości nie używa się AVRmega/tiny lecz ARM z DMA.. Jeśli ktoś robi to na AVR to źle dobrał sprzęt do zadania.

    Z ogromnym narzutem wysyłasz dane przez ETH, jakieś 150% ale używasz. Dlaczego nie użyjesz RS485? Bo RS485 masz do 10Mb/s, EHT bez problemu 100. Zakładając narzut 150% a może być i 500 lub więcej jak pakiet jest krótki to i tak ETH jest szybszy o 50% od RS485.
    Odczep się więc tych narzutów, bo chyba nie czytasz tego co napisałem, że jak I2C nie wystarcza to użyjesz SPI


    tmf wrote:
    Czyli standardowa funkcjonalność slave I2C. I co z tego, skoro przy odczycie sekwencyjnym nie wiesz, kiedy przestać o ile wcześniej nie odczytałeś z układu liczby bajtów w FIFO. A to z kolei powoduje przy krótkich pakietach duże narzuty.

    Dobry programista wie jakiej długości pakietów się spodziewa. Coś podobnego już pisałeś wiele razy dobry programista, bład programisty, więc i ja użyłem tego argumentu.

    Janusz_kk wrote:
    W swoim programie zawieszasz przerwania na 50ms!!! po co? co takiego ważnego procek musi zrobić żeby tyle blokować przerwania.

    Ja nie ale Arduino tak. Co prawda 50ms nie spotkałem ale 30 tak.
  • #23
    tmf
    Moderator of Microcontroller designs  
    Jako, że żadne merytoryczny argumenty nie padły, nie ma się do czego ustosunkowywać. Po prostu kolejny raz kolega troluje. Myślę, że dla społeczności elektrody nie jest to zaskoczeniem.
  • #24
    LChucki
    Level 31  
    Dopóki będziesz używać mostka USB w banalny sposób, to czy użyjesz taniuśkiego CP2101, w którym nic zmienić się nie da, czy wypasionego FTDI najczęściej nie bedzie to miało znaczenia.Jeśli potrzebujesz coś więcej, to bez zaawansowanego mostka, a te sa z I2C/SPI, nic nie zrobisz.

    Wystarczy jeden argument aby był sens stosowania FT201: I2C nie wymaga stabilizacji kwarcem w najpopularniejszych AVR.
    Jak ten argument obalisz? Źle dobrany sprzęt do zadania?

    Tych argumentów jest więcej, jak możliwość zawieszania przerwań na długi czas. Jak to obalisz? Użycie ArduinoUNO/MEGA to zły dobór sprzętu do zadania? W takim razie 99% konstrukcji na Arduino to zły dobór sprzętu.

    Gratisowy 1kB EEPROM. Jak to obalisz w przypadku uC, który eeprom nie ma? Zły dobór sprzętu? A może właśnie konstruktor świadomie może wybrać FT201 + uC, zamiast FT230 + uC + EEPROM?

    Modyfikowanie MTP. Nie ma problemu aby w Twoim produkcie zmienić MTP i uC nic o tm nie wie. Pewnie wiesz, a może nie, że jak MTP zostanie uszkodzona to FTDI przyjmie standardowa konfigurację i Twoją konfiguracje diabli wzięli a uC nic o tym nie wie. Gdy użyjesz FT201, nawet jak ktoś zmieni MTP czy zostanie uswzkodzona, to wiem o tym i mogę wpisać ponownie swoją konfigurację. W moich konstrukcjach akurat modyfikacja MTP jest kluczowym zagadnieniem.
    Jak obalisz ten argument?


    Mogę wymieniać dalej, każdy argument obalisz. Każdy z osobna. Ja tez każdy argument aby stosować UART obaliłem. Też z osobna. Spójrz teraz na to całościowo, na typowe zastosowania, typowe prędkości, wielkości pakietów itp. Jakie wnioski? Moje takie, że w co najmniej 90% przypadków FT201 jest lepszym rozwiązaniem niż FT230 i jemu podobne z UART.

    Dodano po 3 [minuty]:

    Dyskusja przypomina podobne o wyższości świąt ..... czyli:
    - Co lepsze AVR czy ARM?
    - Lepszy STM32, LPC czy PIC32?
    - Pisać w C czy C++?
    itd.

    Wiesz, że te dyskusje nigdy się nie kończą a ta należałoby już zakończyć. Argumentów za i przeciw jest dużo, każdy wybierze co mu pasuje a wybór dałem ja, bo konstrukcji z FT201 się raczej nie spotyka. Na tym forum była chyba tylko jedna, moja https://www.elektroda.pl/rtvforum/topic3382190.html.
  • #25
    khoam
    Level 41  
    LChucki wrote:
    AVR mają mało UART. Jest to szczególnie odczuwalne w przypadku Arduino UNO.

    Nie da się ukryć, że jest to problem w wypadku Uno czy Nano, w większości przypadków stosowane są "plomby" w postaci SoftwareSerial, które mają dość ograniczone zastosowanie. Czy związku z tym, że Kolega wyraźnie podkreślił znaczną przydatności tego konwertera dla "arduinowców", to czy zamierza Kolega udostępnić bibliotekę np. o nazwie WireToSerial, która mogłaby być użyta podobnie, jak standardowa klasa Serial i jednocześnie nie kolidowała z klasą Wire, która z kolei standardowo wykorzystywana jest do obsługi I2C? Przydałaby się również wtedy obsługa serialEvent() dla takiej nowej kasy.

    Bez takiego wsparcia programowego dość trudno mi sobie wyobrazić szerokie zastosowanie takiego konwertera tym bardziej, że większość "arduinowców" jest przyzwyczajona do tego, że do znakomitej większości używanych przez nich modułów/rozszerzeń dostępne są odpowiednie biblioteki z otwartym kodem źródłowym. Nie znalazłem w necie jakichkolwiek bibliotek na bazie Arduino HAL ze wsparciem dla FT201.

    LChucki wrote:
    W takim razie 99% konstrukcji na Arduino to zły dobór sprzętu.

    Raczej, w 90% przypadków to zły dobór programistów ;)
  • #26
    LChucki
    Level 31  
    khoam wrote:
    Czy związku z tym, że Kolega wyraźnie podkreślił znaczną przydatności tego konwertera dla "arduinowców", to czy zamierza Kolega udostępnić bibliotekę np. o nazwie WireToSerial, która mogłaby być użyta podobnie, jak standardowa klasa Serial i jednocześnie nie kolidowała z klasą Wire, która z kolei standardowo wykorzystywana jest do obsługi I2C? Przydałaby się również wtedy obsługa serialEvent() dla takiej nowej kasy.

    Nas razie mam kod dla AVR, jest w załączniku. Dla STM32 nie wszystkie funkcje mam, bo nie zawsze można użyć standardowych funkcji HAL, np:
    START
    ADR_WR = 0
    DANA_WR
    START_RD = 0x44
    DANA_RD
    STOP
    dlatego pisze na rejestrach i odezwał się problem blokady magistrali przez slave. Na szczęście rozwiązanie tego problemu już miałem, trzeba było tylko lekko zmodyfikować.
    Na Arduino funkcje powstaną jak skończę z STM32 bo mam jedną płytkę z FT201 a nie mam ochoty co chwila przekładać kabelków.

    khoam wrote:
    e do znakomitej większości używanych przez nich modułów/rozszerzeń dostępne są odpowiednie biblioteki z otwartym kodem źródłowym.

    Nie jestem pewny czy nie spotkałem bibliotek dla FT201 ale mogłem pomylić z DS2482.
  • #27
    khoam
    Level 41  
    LChucki wrote:
    Na Arduino funkcje powstaną jak skończę z STM32

    Jako pewnego rodzaju szablon dla nowej klasy z powodzeniem można wykorzystać kod klasy SoftwareSerial, trzeba jedynie pamiętać, że obiekt Wire może być inicjowany i konfigurowany przez różne peryferia wykorzystujące I2C. Jestem ciekawy, czy w ten sposób udałoby się uruchomić monitor portu szeregowego, zamiast na standardowym Serial - oznaczałoby to zwolnienie jedynego UART w Uno czy Nano dla własnych celów (sam kod mógłby być ładowany dalej przez Serial, ale to nie miałoby większego znaczenia po uruchomieniu programu) przy zachowaniu funkcjonalności tego monitora.
  • #28
    LChucki
    Level 31  
    Pomysł fajny ale ja nie sprzedaję ani Arduino ani modułów z FT201. Nie używam Arduino, czasem jakąś bibliotekę napiszę do sprzętu, który do Arduino robię dlatego nie mam interesu w tym aby zrobić to o czym piszesz.
    Będą kody, znajdzie się chętny to napisze. ja zrobię tylko proste funkcje:
    - Wyślij bajt/bajty na USB.
    - Odczytaj bajt/bajty z USB.
    - FlushFT201.
    - Odczytaj status FT201.
    - Odczytaj ID.
    - Od liczbę znaków w FIFO.
    - Czytaj bajt z EEPROM.
    - Zapisz bajt do EEPROM.
    - Czytaj MTP.
    - Zapisz MTP.
    - Licz CRC MTP.

    Podobnie będzie dla FT220 i FT221 (SPI) z tym, że dojdą:
    - Czytaj stan linii DTR, DSR.
    - Ustaw stan linii RTS, CTS, CDC, RI.

    Kto jest chętny już może pisać na Arduino. W załączniku jest kod dla AVR.
  • #29
    khoam
    Level 41  
    Czy jesteś autorem projektu pcb do tej płytki? Czy samą płytkę można gdzieś nabyć?
  • #30
    LChucki
    Level 31  
    Jestem autorem, będą w AVT. W TME, Farnel można kupić (można było) zestawy devkity (tanio nie jest) z FT201, FT220, FT221 ale bez izolacji galwanicznej. Do zabawy wystarczą.

    Prawie skończyłem funkcje dla STM32. Praktyczne zastosowanie - licznik resetów:
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    Tylko 8-bit ale to demo.
Reply Cool? Ranking DIY | New topic
Notify about new articles
Popular Topics