Elektroda.pl
Elektroda.pl
X
IGE-XAOIGE-XAO
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

LChucki 09 Lut 2020 21:24 3348 60
  • #31
    khoam
    Specjalista - ESP32, ESP8266
    Wiesz co, skoro jest to promocja płytki AVT to sobie poczekam, aż będzie dostępna u nich. Jeżeli cena płytki nie będzie wyższa niż za Uno, to rozważę napisanie biblioteki dla Arduino. Oczywiście w 100% niekomercyjnie.
  • IGE-XAOIGE-XAO
  • #32
    LChucki
    Poziom 31  
    khoam napisał:
    Wiesz co, skoro jest to promocja płytki AVT to sobie poczekam, aż będzie dostępna u nich. Jeżeli cena płytki nie będzie wyższa niż za Uno, to rozważę napisanie biblioteki dla Arduino. Oczywiście w 100% niekomercyjnie.

    1) Czy będzie czy nie to zależy od klientów.
    2) Zanim pojawi się artykuł monie min kilka miesięcy, obstawiam 6. PCB najszybciej za jakieś 2 miesiące po publikacji, chyba, że tłumy będą zainteresowane ta PCB ale szczerze wątpię.
    3) Nie wiem ile czasu będziesz pisał bibliotekę ale jeśli za free to w wolnych chwilach więc pewnie miesiąc :-)
  • #33
    trol.six
    Poziom 31  
    LChucki napisał:
    Podstawowa obsługa (jak mostków UART) jest banalna. Pod domyślny adres 0x44 (0x22) wysyłamy daną.

    Czyli ten sprzęt ma dwa adresy, czy jak? Tzn czy jest możliwość podłączenia kilku przy różnych adresach do jednej linii?
    .
  • IGE-XAOIGE-XAO
  • #34
    LChucki
    Poziom 31  
    trol.six napisał:
    Czyli ten sprzęt ma dwa adresy, czy jak?

    Ma 3 adresy.
    - Unikalny, który nadajesz FT_PRO-em lub zapisując po I2C w pamięci MTP.
    - Broadcast.
    - 0xF9 (0x7C)

    trol.six napisał:

    Tzn czy jest możliwość podłączenia kilku przy różnych adresach do jednej linii?

    Możesz podłączyć kilka FT201 nadając im unikalne adresy. Dane po USB przesyłasz używając unikalnego adresu. Inne funkcje używając broadcast + unikalny a identyfikator, który możesz nadać FT_PROG-iem albo po I2C przez adres 0xF9 + unikalny.
  • #35
    JarekC
    Poziom 28  
    khoam napisał:
    Czy jesteś autorem projektu pcb do tej płytki? Czy samą płytkę można gdzieś nabyć?


    Jeżeli jesteś zainteresowany konwerterem ale bez izolacji to możesz ode mnie dostać gratis płytkę i obudowę do tego projektu (ostatni wpis w wątku)
    https://www.elektroda.pl/rtvforum/viewtopic.php?t=3620901&highlight=

    Takie małe 3 w 1:
    Konwerter USB-I2C
    Konwerter USB-UART
    Konwerter USB-GPIO

    Dostępne są biblioteki DLL, program terminala a także biblioteka dla Pythona.
    Przymierzalem się do opublikowania tego projekciku na Elektrodzie ale ciągle brakuje mi czasu.

    Pozdrawiam
    JarekC
  • #36
    LChucki
    Poziom 31  
    MCP2221 - cena taka sama jak FT201, zaleta 3 w jednym, wady:
    - FIFO 64 bajty.
    - I2C 400kHz
    - Brak EEPROM
    Dużą zaletą może być to, że dostępna jest wersja w DIP.

    Dodano po 1 [minuty]:

    Nie pamiętam ale chyba w MCP2221 nie można zmieniać stanu GPIO z poziomu uC?
    @JarekC dobrze znasz ten układ, napisz o nim coś więcej.
  • #37
    khoam
    Specjalista - ESP32, ESP8266
    JarekC napisał:
    Jeżeli jesteś zainteresowany konwerterem ale bez izolacji to możesz ode mnie dostać gratis płytkę i obudowę do tego projektu (ostatni wpis w wątku)
    https://www.elektroda.pl/rtvforum/viewtopic.php?t=3620901&highlight=

    Super. Zgłoszę się na PW. Wygląda obiecująco. Dziękuję.

    LChucki napisał:
    - FIFO 64 bajty.
    - I2C 400kHz
    - Brak EEPROM

    Dla płytek Arduino z atmega328p w zupełności akceptowalne. To ma przede wszystkim służyć jako alternatywny monitor szeregowy. Co najważniejsze jest biblioteka do MCP2221 z otwartym kodem źródłowym w C.

    Ten EEPROM w tym wypadku byłby lekko nadmiarowy.
  • #38
    JarekC
    Poziom 28  
    W MCP2221(A) GPIO są dostępne od strony USB.
    Są o tyle ciekawe że mogą spełniać różna rolę:
    - być zwykłym cyfrowym portem I/0
    - automatyczne sygnalizować stan TXD/RXD
    - automatycznie sygnalizować stan Transmisji I2C
    - być wyjściem 5-bitowego DAC
    - być wejściem 10-bitowago ADC

    Wszystkie informacje znajdziesz w karcie katalogowej.

    W moim przypadku prędkość do 400kHz w zupełności wystarcza.
  • #39
    LChucki
    Poziom 31  
    JarekC napisał:
    W MCP2221(A) GPIO są dostępne od strony USB.

    Z not wnioskuję, że od strony uC nie można zrobić nic poza samą transmisją po USB. Nie mylę się?

    JarekC napisał:
    Wszystkie informacje znajdziesz w karcie katalogowej.

    Wiem ale po przejrzeniu noty nie zawsze wszystko jest jasne. Widzę możliwość konfigurowania VID, PID ale deskryptora już nie. Nie ma rejestru deskryptora. Jak w systemie "przedstawia" się MCP2221?
    Widzę, że jest tylko tryb master! Nie przeszkadza to:
    khoam napisał:
    To ma przede wszystkim służyć jako alternatywny monitor szeregowy.

    FT201 jest slave. Bez problemu do AVR podłączysz inne slave, bo AVR przeważnie jest masterem*. Jeśli MCP jest masterem, to nie podłączysz slave do AVR a co gorsza, jak na dłużej użytkownik zawiesi przerwania to stracisz dane przesyłane po USB. No chyba, ze da sie na MCP wymusić tryb slave.

    JarekC napisał:
    W moim przypadku prędkość do 400kHz w zupełności wystarcza.

    Tobie wystarcza bo pewnie używasz AVR. Zauważ, że dla @tmf 3,4Mb/s jest za mało.

    khoam napisał:
    Ten EEPROM w tym wypadku byłby lekko nadmiarowy.

    Niekoniecznie. Pokazałem przykład licznika resetów uC, niezależny od EEPROM w uC. AVR ma fuse EESAVE, z którego często kożystałem ale gdy wymienisz uC żaden EESAVE nie pomoże. Kluczowe informacje można trzymać nie tylko w EEPROM uC ale także właśnie w FTDI i dodatkowo w DS2431 albo DataFlash, które maja swój unikalny numer seryjny. Naturalnie to o czym pisze to raczej nie dla amatorów Arduinowców choć (niestety**) jakieś tam rozwiązania na Arduino pojawiają się w postaci projektów komercyjnych, może nie komercyjnych ale płatnych a każdy chce zabezpieczyć swój produkt przed kopiowaniem. Nowe AVR mają unikalne ID, stare nie ale i tak im więcej zabezpieczeń tym lepiej.

    Jeszcze taka sygnaturka jaka daję w swoich produktach:
    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    Tekst ten jawnie nie musi występować w kodzie programu, mozna go zaszyfrować kluczem o długości samego tekstu. Tekst jest widoczny w oknie FT_PROG (w tym przypadku specjalnie dałem go w obszarze pierwszych 256 bajtów) ale można go umieść tam, gdzie FT_PROG go nie pokaże. Sygnaturę można odczytać na komputerze przez D2XX lub przez uC. Całkiem dobry sposób na zabezpieczenie swoich praw. MCP2221 czy mostki z UART nie dają takiej możliwości.
    Licznik czasu pracy pozwala ograniczać czasowo licencję. Często występuje sytuacją, gdzie zlecający opóźnia zapłatę za ostatni etap prac. Niech więc sobie produkuje urządzenie w milionach, zobaczymy co będzie z reklamacjami za rok :-) Nawet jak w końcu wpadnie na to jak działa zabezpieczenie to musi wymienić we wszystkich urządzeniach FT201, po pewnym czasie ponownie.


    * - muszę poczytac o komunikacji I2C MCP bo jak na razie nie wszystko jest dla mnie jasne.
    ** - urządzenia nie przyszły prostego testu zwarcia lub przerwany/braku rezystora podciągającego na I2C/1-Wire. Urządzenie po prostu zawiesiło się. Żeby chociaż był włączony watchdog. Ja za taki produkt bym nie zapłacił bo nie spełniałby podstawowych założeń.

    Dodano po 23 [minuty]:

    JarekC popraw mnie jeśli się mylę. I2C w MCP nie można użyć w roli mostka USB-uC bo tylko od strony HOST-a można cokolwiek zrobić na magistrali. Jak uC chce coś wysłać po USB musi czekać aż HOST odczyta dane z uC. Wnioskuję, że gdy uruchomię terminal na komputerze, to uC nie będzie mógł z nim wymieniać informacji? Jeśli jest jak piszę, to nici z wykorzystania MCP z Arduino :-(
    khoam czytałeś notę MCP?
  • #40
    tmf
    Moderator Mikrokontrolery Projektowanie
    LChucki napisał:
    Tobie wystarcza bo pewnie używasz AVR. Zauważ, że dla @tmf 3,4Mb/s jest za mało.

    Jesteś mistrzem w odwracaniu kota ogonem. Wskaż, gdzie tak napisałem, albo nazwę cię kłamcą.
    LChucki napisał:
    Pokazałem przykład licznika resetów uC, niezależny od EEPROM w uC. AVR ma fuse EESAVE, z którego często kożystałem ale gdy wymienisz uC żaden EESAVE nie pomoże.

    Kolejny chybiony argument. Gdy wymienię FT20x to też stracę taki licznik. Z praktyki - nagminnie robię w EEPROM liczniki POR i WDR, szczególnie ten drugi jest interesujący. Nigdy nie miałem potrzeby umieszczać ich poza MCU, bo i po co? Jeszcze rozumiem na ARM, gdzie zazwyczaj nie ma EEPROM, wykorzystanie takiej pamięci przy okazji użycia chipu takową pamięc posiadającego, może być kuszące. Ale jeśli mam EEPROM w procku to po co?
    LChucki napisał:
    Jeśli MCP jest masterem, to nie podłączysz slave do AVR a co gorsza, jak na dłużej użytkownik zawiesi przerwania to stracisz dane przesyłane po USB.

    A niby dlaczego nie podłączę? Obsługa multimaster jest podstawową funkcjonalnością I2C. \Co do tych przerwań już pisałem - jak programista do kitu, to powinien sprzedawać ziemniaki.
    LChucki napisał:
    Nowe AVR mają unikalne ID, stare nie ale i tak im więcej zabezpieczeń tym lepiej.

    Do tego są specjalne układy. Takie zabezpieczenie o jakim piszesz może być, ale trzeba mieć świadomość, że byle "hacker" je złamie w parę minut.
    LChucki napisał:
    Tekst ten jawnie nie musi występować w kodzie programu, mozna go zaszyfrować kluczem o długości samego tekstu. Tekst jest widoczny w oknie FT_PROG (w tym przypadku specjalnie dałem go w obszarze pierwszych 256 bajtów) ale można go umieść tam, gdzie FT_PROG go nie pokaże. Sygnaturę można odczytać na komputerze przez D2XX lub przez uC. Całkiem dobry sposób na zabezpieczenie swoich praw.

    Na utrudnienie sposób dobry, na zabezpieczenie - żaden. Sklonujesz chip i po zabezpieczeniu.
    Jak pisałem - układ jest jakąś opcją, jeśli ktoś lubi I2C. Jest wybór, jest dobrze. Tylko po co do tego dorabiać jakieś naciągane argumenty? Nie lepiej po prostu przedstawić rzetelnie jak jest?
  • #41
    LChucki
    Poziom 31  
    tmf napisał:
    Wskaż, gdzie tak napisałem,

    Pisałeś, że 400kHz to mało mimo iż zaznaczałem, że FT201 pracuje do 3,4MHz. Ten argument nie trafiał, więc zakładam, że 3,4MHz to mało.

    tmf napisał:
    Gdy wymienię FT20x to też stracę taki licznik.

    Czy licznik ma być tylko w FT201? Jak masz w FT201 i uC to oba musisz wymienić aby stracić licznik.

    tmf napisał:
    A niby dlaczego nie podłączę? Obsługa multimaster jest podstawową funkcjonalnością I2C.

    O ile obsłuży to przeciętny arduinowiec w co szerze wątpię.

    tmf napisał:
    Co do tych przerwań już pisałem - jak programista do kitu, to powinien sprzedawać ziemniaki.

    Co ma zrobić przeciętny arduinowiec w przypadku WS2812? Sam napisze biblioteki?

    tmf napisał:
    Do tego są specjalne układy.

    Są ale każdy wie do czego taki układ służy natomiast w przypadku mostka zabezpieczenie jest niewidoczne do czasu aż zadziała a wymiana uC nic nie zmieni.

    tmf napisał:
    Takie zabezpieczenie o jakim piszesz może być, ale trzeba mieć świadomość, że byle "hacker" je złamie w parę minut.

    Pare minut? Z chęcią bym się z Tobą założył że kilka minut nie wystarczy ale już kiedyś chciałeś założyć się, jak się zorientowałeś, że przegrasz to zacząłeś zmieniać warunki więc nie ma sensu zakładać się. Kolejny raz rozśmieszyłeś dość szerokie grono osób na forum.

    tmf napisał:
    Na utrudnienie sposób dobry, na zabezpieczenie - żaden.

    Jeśli o zabezpieczeniu nie wie jest bardzo skuteczne. Jak się dowiesz może być za późno.

    tmf napisał:
    układ jest jakąś opcją, jeśli ktoś lubi I2C.

    Częściej używam FT22x z SPI ale nie dlatego, że nie lubię I2C. Wrecz przeciwnie, magistrala jest bardzo dobrze przemyślana.

    Dodano po 14 [minuty]:

    @tmf, masz alergię nie na FT201 a na mnie, bo mimo niezaprzeczalnych zalet FT201 widzisz tylko jego wadę i to urojoną, mimo że inni uczestnicy dyskusji widzą zalety wykorzystania I2C. Puki co przegrywasz 3:1.
    A może nie widzisz zalet tak jak nie widziałeś a raczej nie chciałeś widzieć, izolacji galwanicznej?

    Przemyśl na spokojnie wszystkie za i przeciw.
    - Postaw się w roli profesjonalisty a nie amatora który nie ma potrzeby modyfikować deskryptora a jak ma to zrobić to lubi bawić się w podwójne programowanie przy niedużych seriach urządzeń.
    - Postaw się w roli amatora, którego chce wydy...ć zlecający, który gdyby potrafił łamać zabezpieczenia to i z napisaniem programu by sobie poradził.
    - Postaw się w roli konstruktora, który zna tylko AVR, nie polutuje TQFP100 przez co jest ograniczony do 2 UART, potrzebuje ich a musi się komunikować przez USB, niestety AVR z USB go przerasta a SC16IS7xx to dodatkowy koszt, którego uniknie gdy skorzysta z FT201.
    - Jak zrealizujesz zdalny upgrade prze Internet (urządzenie do pracy wykorzystuje ETH) u miliona klientów gdy trzeba zmienić ustawienia FTDI?. Każdego będziesz prosił o udostępnienie pulpitu, instalował mu FT-PROG..... Jak obalisz ten argument?
    Argumenty można mnożyć i mnożyć a Ty masz tylko jeden @LChucki bo o I2C Ci nie chodzi no chyba, że jesteś totalnym amatorem i mostek z UART spełnia wszystkie Twoje wymagania. Może to jak z Trabantem i Mecedesem? Dopóki nie jechałeś Mercedesem trabant wystarczał do wszystkiego i nic lepsze nie potrzeba?
    Jak używał AVR to też wydawało mi się, że wystarcza do wszystkiego, dopóki nie trafiłem na projekty, które przerosły AVR jak np zaemulować ZXspectrum na AVRmega.


    PS
    Dlaczego nie atakujesz mnie w temacie Budżetowy licznik częstotliwości 0,1Hz - 42MHz (1.6GHz) i czasu 24ns - 10s. Bo z Xmega nie masz co startować? Właśnie w tym projekcie będzie użyty dokładnie ten sam moduł, który opisuje w tym temacie. Wylejesz tam falę krytyki, jakie to złe rozwiązanie, że UART byłby lepszy? Ze jestem kiepskim programistom, bo nie potrafię użyć UART?
  • #42
    khoam
    Specjalista - ESP32, ESP8266
    LChucki napisał:
    I2C w MCP nie można użyć w roli mostka USB-uC bo tylko od strony HOST-a można cokolwiek zrobić na magistrali. Jak uC chce coś wysłać po USB musi czekać aż HOST odczyta dane z uC.

    Chyba masz rację. Trochę wczoraj zbyt entuzjastycznie podszedłem do tego pomysłu, ale było już późno ;) Natomiast ten MCP2221 byłby fajnym układem do sterowania działaniem programu Arduino z peceta lub jakiegokolwiek USB hosta.
  • #43
    JarekC
    Poziom 28  
    Tak MCP2221A jest zawsze Masterem. Moduł który opisywałem był zastosowany do sterowania konwerterem audio.
    Aplikacja mogła zmieniać konfigurację i odczytywać aktualny stan urządzenia, resetować układ itd.

    Piszesz o 3.4MHz a izolacja ograniczyła to już do 1MHz.
    FT jest Slavem więc o zegarze decyduje Master, pokaż jakieś rozwiązanie z Arduino pracujące z tak wysokim zegarem I2C.
    Przy I2C należy zwracać uwagę na pojemność linii, przy 3.4MHz jest to maksymalnie 100pF, a długość linie nie może przekraczać 0.5m.
    Podłączenie konwertera luźnymi przewodami do układu który może być zbudowany na pająka i praca dużymi prędkościami to proszenie się o problemy.

    Druga sprawa czy ADUM1251 jest poprawnie podpięty?
    ADUM1251 ma dla SCL transmisję tylko w jedna stronę od SCL1(pin3) do SCL2(Pin6).

    FT201 pracuje jako Slave więc do niego powinien być podłączony sygnał SCL2 a według twojego schematu podłączone jest SCL1, czy się mylę?

    Przyznam że argumenty dotyczące Arduino i zastąpienia UARTa przez I2C zupełnie do mnie nie trafiają ale nie wykorzystuję Arduino więc nie będę drążył tego tematu.
    Wiele przytoczonych zarzutów dotyczących AVR nie dotyczy nowych serii AVR0 i AVR1 które są znacznie lepiej wyposażone i tańsze od starych.
  • #44
    LChucki
    Poziom 31  
    khoam napisał:
    LChucki napisał:
    I2C w MCP nie można użyć w roli mostka USB-uC bo tylko od strony HOST-a można cokolwiek zrobić na magistrali. Jak uC chce coś wysłać po USB musi czekać aż HOST odczyta dane z uC.

    Chyba masz rację. Trochę wczoraj zbyt entuzjastycznie podszedłem do tego pomysłu, ale było już późno ;) Natomiast ten MCP2221 byłby fajnym układem do sterowania działaniem programu Arduino z peceta lub jakiegokolwiek USB hosta.

    Długo szukałem rozwiązania problemu mostków USB. Gdy tym się zająłem był jakiś MCP z I2C ale właśnie tylko tryb jak MCP2221. CH3xx też są z I2C/SPI ale też coś mi w nich nie pasowało. To co spełniało większość moich wymagań to właśnie Ft20x i FT22x.
    Cóż, chcesz pisać dla Arduino, izolacja nie jest potrzebna, pozostaje kupić https://www.tme.eu/pl/katalog/?search=umft201&s_field=1000011&s_order=desc
    Mam trochę PCB do FT201 i FT220/221 bez izolacji. Same scalaki mam, ale FT201XD niewiele na szczęście są w TME.
    Mam też po sztuce UMFT201XA-01 i UM201XB.

    Dodano po 1 [minuty]:

    JarekC napisał:
    ADUM1251 ma dla SCL transmisję tylko w jedna stronę od SCL1(pin3) do SCL2(Pin6).

    Gdzie to wyczytałeś?
    Jeśli to co napisałeś jest prawdą, to jakim cudem u mnie działa?

    Dodano po 1 [minuty]:

    JarekC napisał:
    Przyznam że argumenty dotyczące Arduino i zastąpienia UARTa przez I2C zupełnie do mnie nie trafiają ale nie wykorzystuję Arduino więc nie będę drążył tego tematu.

    Jak też nie ale cała masa "programistów" tak.

    JarekC napisał:
    Wiele przytoczonych zarzutów dotyczących AVR nie dotyczy nowych serii AVR0 i AVR1 które są znacznie lepiej wyposażone i tańsze od starych.

    I tak nie przegonią ARM. Jak poużywasz ARM do AVR nie będziesz chciał wracać.

    Dodano po 1 [minuty]:

    JarekC napisał:
    Piszesz o 3.4MHz a izolacja ograniczyła to już do 1MHz.

    jak izolacja nie jest niezbędna to problemu nie ma.

    JarekC napisał:
    pokaż jakieś rozwiązanie z Arduino pracujące z tak wysokim zegarem I2C.

    Patrzysz tylko przez pryzmat AVR ale sa i inne uC gdzie 3,5MHz to nie problem nawet w roli slave.
  • #45
    khoam
    Specjalista - ESP32, ESP8266
    JarekC napisał:
    Przyznam że argumenty dotyczące Arduino i zastąpienia UARTa przez I2C zupełnie do mnie nie trafiają ale nie wykorzystuję Arduino więc nie będę drążył tego tematu.

    Do emulacji UART z użyciem I2C, to sens IMHO jest niewielki. W tym przypadku chodziło mi jedynie o uzyskanie portu dla monitora w Arduino IDE i "zwolnienie" jedynego UART w Uno czy Nano. Wielu użytkowników Arduino nie rozumie, że jak korzysta z monitora portu szeregowego w Uno (prawie każdy początkujący), to nie może jednocześnie podłączać np. ESP8266 do RX/TX, bo to ten sam port. Wyprowadzenia RX/TX w Uno/Nano na złącze grzebieniowe sugeruje, że są to wolne piny do swobodnego wykorzystania - to taki "chłyt" marketingowy :)
  • #46
    LChucki
    Poziom 31  
    khoam napisał:
    Wyprowadzenia RX/TX w Uno/Nano na złącze grzebieniowe sugeruje, że są to wolne piny do swobodnego wykorzystania - to taki "chłyt" marketingowy :)

    W Wemos D1 jest taki chwyt i jeszcze inne zbublowane piny :-)
    I2C też jest wyprowadzone dwa razy wiec tu też Arduino nie jest w porządku. To co dobre w tym bałaganie to fakt, że UNO często jest rozbudowywane przez i2C. W sumie głupota. bo wystarczy użyć Mega, wyjdzie taniej i lepiej ale arduinowcy nie radzą sobie z przeniesieniem kodu z UNO na Mega.
  • #47
    JarekC
    Poziom 28  
    LChucki napisał:
    JarekC napisał:
    ADUM1251 ma dla SCL transmisję tylko w jedna stronę od SCL1(pin3) do SCL2(Pin6).


    Gdzie to wyczytałeś?
    Jeśli to co napisałeś jest prawdą, to jakim cudem u mnie działa?


    W karcie katalogowej układu:
    The ADuM1250 provides two bidirectional channels, supporting a complete isolated I2C interface.
    The ADuM1251 provides one bidirectional channel and one unidirectional channel for applications where a bidirectional clock is not required.


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

    Trochę to dziwne że stosujesz układ i nie wiesz jak on działa?
    Nie wiem jak to testowałeś więc trudno mi oceniać czy naprawę działa.

    JarekC
  • #48
    Slawek K.
    Poziom 32  
    @LChucki

    A co jest tam do przeniesienia ? Kod z UNO na Mega bedzie działał bez przeróbek, odwrotnie wiadomo, że już niekoniecznie, zatem słaby argument.
    Ale widzę, że kolega dobrze obeznany z arduino z jednej strony, ale jakby się trochę wstydził, z drugiej ;)
    I podziwiam czas i nerwy kokegi poświęcone na tą krucjatę, nie tylko na tym forum. Ile szybciej powstałyby te setki projektów, o których kolega się chwali gdzie to tylko możliwe, gdyby nie te zacięte i emocjonalne dysputy odnośnie arduino i avr ;)

    Pozdr
  • #49
    LChucki
    Poziom 31  
    Na schemacie jest ADuM1251 a na PCB, mam 1250. Nie wiem jak na schemat trafił 1251 ale poprawię to.

    Slawek K. napisał:
    A co jest tam do przeniesienia ? Kod z UNO na Mega bedzie działał bez przeróbek

    Pewny jesteś? Tak w 100% będzie działać? Dasz sobie rękę uciąć? A może zakład ale nie jak z @teemef, że jak widzi , że przegrał to zmienia zasady.

    Co do reszty wypowiedzi to niezwiązana z tematem.
  • #50
    Slawek K.
    Poziom 32  
    LChucki napisał:
    Na schemacie jest ADuM1251 a na PCB, mam 1250. Nie wiem jak na schemat trafił 1251 ale poprawię to.

    Slawek K. napisał:
    A co jest tam do przeniesienia ? Kod z UNO na Mega bedzie działał bez przeróbek

    Pewny jesteś? Tak w 100% będzie działać? Dasz sobie rękę uciąć? A może zakład ale nie jak z @teemef, że jak widzi , że przegrał to zmienia zasady.

    Co do reszty wypowiedzi to niezwiązana z tematem.

    Tak, jestem pewien, 95% kodu napisanego w C++ na arduino, będzie działać, mowa o Arduino UNO -> Arduino Mega.

    Pozdr
  • #51
    JarekC
    Poziom 28  
    LChucki napisał:
    Na schemacie jest ADuM1251 a na PCB, mam 1250. Nie wiem jak na schemat trafił 1251 ale poprawię to.

    A ja na zajęciu zmontowanego PCB wiedzę ADUM1251, kolega trochę pląta się w zeznaniach.
  • #52
    khoam
    Specjalista - ESP32, ESP8266
    LChucki napisał:
    Tak w 100% będzie działać?

    Będzie, dzięki bibliotekom Arduino, które są tak napisane, aby tego rodzaju sytuacje uwzględnić :)

    LChucki napisał:
    ale arduinowcy nie radzą sobie z przeniesieniem kodu z UNO na Mega.

    LChucki napisał:
    ale cała masa "programistów" tak

    LChucki napisał:
    O ile obsłuży to przeciętny arduinowiec w co szerze wątpię.

    LChucki napisał:
    to o czym pisze to raczej nie dla amatorów Arduinowców

    i podsumowanie:
    LChucki napisał:
    Kto jest chętny już może pisać na Arduino.


    Drogi Kolego, naprawdę jest coraz mnie osób na tym Forum, których interesują Twoje opinie na temat programistów Arduino i w ogóle programistów, poza tym nie są one związane z tematem. Opinie te są łatwe do przewidzenia i mają zawsze charakter pejoratywny. Dziwie się trochę, że swoim pretensjonalnymi wypowiedziami zniechęciłeś potencjalnie najbardziej zainteresowaną grupę nabywców na przedstawiony konwerter, czyli użytkowników Arduino. Ale to jest tylko IMHO.
  • #53
    LChucki
    Poziom 31  
    Slawek K. napisał:
    Tak, jestem pewien, 95% kodu

    Więc nie 100%

    Co do ADUm na oscylogramie widać wyraźnie, że działa. Poziom niski na SDA jest inny gdy nadaje master a inny gdy odpowiada slave.

    Dodano po 6 [minuty]:

    Zagadka z płytką jest taka, że na PCB mam 1250 a na foto 1251.
  • #54
    khoam
    Specjalista - ESP32, ESP8266
    LChucki napisał:
    Więc nie 100%

    W opisie bibliotek Arduino jest obowiązkowy plik library.json (dla PlatformIO) oraz library.properties (dla Arduino IDE), w którym zawarta jest informacja, na jakie platformy sprzętowe przeznaczona jest dana biblioteka Arduino. Dla przykładu, dla biblioteki TimerOne jest to odpowiedni fragment:
    Kod: json
    Zaloguj się, aby zobaczyć kod

    Informacja ta pozwala na identyfikację platformy sprzętowej, dla której przeznaczona jest dana biblioteka. W tym wypadku atmelavr oznacza kompatybilności z płytkami wymienionymi pod tym linkiem:
    https://docs.platformio.org/en/latest/platforms/atmelavr.html#boards
  • #55
    JarekC
    Poziom 28  
    Nie wiem może działa, niemniej takie podłączenie Adum1251 jest błędne i tyle. Po prostu odwrócić scalaka i już.
  • #56
    LChucki
    Poziom 31  
    JarekC napisał:
    Nie wiem może działa,

    Działa, bo jest ADuM1250.
    JarekC napisał:

    niemniej takie podłączenie Adum1251 jest błędne i tyle. Po prostu odwrócić scalaka i już.

    Jak byłby odwrócony to bym nie odczytał symbolu. Dziś pewnie nić już się nie dowiem ale chyba wiem co się wydarzyło.
  • #57
    JarekC
    Poziom 28  
    LChucki napisał:
    Zagadka z płytką jest taka, że na PCB mam 1250 a na foto 1251.

    To wrzuć nowe foto.
  • #58
    LChucki
    Poziom 31  
    JarekC napisał:
    LChucki napisał:
    Zagadka z płytką jest taka, że na PCB mam 1250 a na foto 1251.

    To wrzuć nowe foto.

    Izolowany galwanicznie kowerter USB-I2C (głównie AVR, Arduino ale i dla ARM)
    Zacząłem nierówną walkę z Arduino. W ograniczonym zakresie działa podstawowa funkcjonalność:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Ograniczeniem jest max długość nadawanego ciągu bajtów. Arduino typowo ogranicza bufory I2C do 32 bajtów :-( Bez modyfikacji biblioteki nie da się zwiększyć bufora nadawczego nie zmieniając wielkości odbiorczego. Gdy zwiększę nadawczy do 512 bajtów, odbiorczy też i połowa RAM w UNO znika.
    Standardowe biblioteki można sobie odpuścić, bo nie da się wygenertować ponownego startu jest więc jeszcze gorzej niż w HAL STM32, gdzie można ale tylko z tym samym adresem po ponownym starcie.
    Nie ma więc sensu drążyć tematu standardowych bibliotek. Dalsze przykłady będą operować na rejestrach i będą dotyczyć AVRmega/tiny.
    Napisanie uniwersalnych bibliotek to dużo roboty, Trzeba napisać osobno na każdą rodzinę uC, a jak już pisałem, ja w tym biznesu nie mam. Jest społeczność to ktoś napisze. Szlaki już są przetarte.


    Znacznie lepiej będzie z FT22x co paradoksalnie wynika z gorszych bibliotek SPI. Nie używaj buforów tylko on-line wysyłają/odbierają dane z SPI. Nie ma problemu z ponownym startem itp. Niestety, SPI to aż 5 drutów, o jeden mniej niż dla alfanumerycznego LCD w jednokierunkowym trybie 4-bit. Mam nadzieję, że żaden "geniusz" nie wpadnie na to, aby użyć PCF8474 jak w LCD :-) Mimo wady w postaci dużej liczby GPIO SPI ma dwie zalety:
    - Duża prędkość komunikacji.
    - Zapis/odczyt stanu linii modemowych.
    Dzięki drugiej zalecie uniknie się latającego jak wariat wskaźnika myszy i klikania gdzie popadnie gdy uC wysyła nade po USB którego VCOM nie jest otwarty. Pewnie z tego powodu sterowniki mają opcje VCOM albo DD2X. Nie ma VCOM, nie ma problemu z myszą.
  • #59
    khoam
    Specjalista - ESP32, ESP8266
    LChucki napisał:
    Ograniczeniem jest max długość nadawanego ciągu bajtów. Arduino typowo ogranicza bufory I2C do 32 bajtów :-( Bez modyfikacji biblioteki nie da się zwiększyć bufora nadawczego nie zmieniając wielkości odbiorczego.

    W pliku Wire.h jest:
    Kod: c
    Zaloguj się, aby zobaczyć kod
    W pliku Wire.cpp jest:
    Kod: c
    Zaloguj się, aby zobaczyć kod
    W pliku twi.h jest:
    Kod: c
    Zaloguj się, aby zobaczyć kod
    W pliku twi.c jest:
    Kod: c
    Zaloguj się, aby zobaczyć kod
    To teraz to wszystko policz i napisz nam, jaki jest rozmiar tego bufora w wypadku Arduino HAL dla AVR :)
    https://github.com/arduino/ArduinoCore-avr/tree/master/libraries/Wire/src
    https://github.com/arduino/ArduinoCore-avr/tree/master/libraries/Wire/src/utility

    Dodano po 16 [minuty]:

    LChucki napisał:
    Standardowe biblioteki można sobie odpuścić, bo nie da się wygenertować ponownego startu jest więc jeszcze gorzej niż w HAL STM32, gdzie można ale tylko z tym samym adresem po ponownym starcie.

    Jest nawet lepiej niż w wypadku STM32, dla wersji HAL AVR jest funkcja tw_init().
  • #60
    Freddie Chopin
    Specjalista - Mikrokontrolery
    JarekC napisał:
    Piszesz o 3.4MHz a izolacja ograniczyła to już do 1MHz.
    FT jest Slavem więc o zegarze decyduje Master, pokaż jakieś rozwiązanie z Arduino pracujące z tak wysokim zegarem I2C.
    Przy I2C należy zwracać uwagę na pojemność linii, przy 3.4MHz jest to maksymalnie 100pF, a długość linie nie może przekraczać 0.5m.

    To nie problem. Pierwsze wcielenie LChucki, czyli R-MIK, na forum zostanie zapamiętane głównie z tego, że równie zaciekle broniło swojego super projektu, który naginał wszelkie możliwe prawa fizyki i pozwalał używać I2C z prędkością 10 Mbit/s na odległość 1200 m.
    https://www.elektroda.pl/rtvforum/topic3334112.html
    Po tym zbłaźnieniu się R-MIK wkrótce zniknął, a potem każdy jego nowy klon był coraz bardziej złośliwy i pojawiał się na forum tylko po to, żeby potrollować.