Transformatorek i optoizolacja zabezpieczają moduł, a nie cały system. Jak Ci ESD/EMP rozwali LEDa w transoptorze, to sobie z modułem nie pogadasz, pomimo, że technicznie przeżył. Więc trzeba zabezpieczyć tego LEDa -- no ale jak go już zabezpieczyłeś, to własciwie po co Ci on? "Bezpieczny" sygnał możesz wpuścić od razu do modułu.
Nie skaluje się. Nie dorzucisz sobie nowych modułów do istniejącej sieci, wolnych kabelków masz tylko ileś i więcej nie będzie. Szybka sieć mutidrop daje duży zapas. Kanałów w masterze też masz tylko jeden lub małe kilka, a nie dla każdego modułu po jednym.
No, dokładnie. Przy czym nie musi to być na jednej parze, dostępna jest cała skrętka minus żyły zasilania. Ale już dawno zauważono, że protokoły zawierające zegar w strumieniu danych są niepodatne na rozsynchronizowanie pomiędzy kilkoma liniami, bo... nie ma kilku linii. SATA, USB, HDMI i inne współczesne protokoły się na tym opierają. To czemu i ja nie mam z tej wiedzy skorzystać, zwłaszcza, że FPGA ma to wbudowane w sprzęt? A skoro tak, to jedna para mi wystarczy. To nie wynika z wymagań -- po prostu wystarczy i w efekcie będzie prościej.
Pisałem, że potrzebuję pamięci o długim retention time. Czy ta pamięć potrafi przy okazji wykonywać jakieś instrukcje i pogadać jako master przez I2C, to nieistotne. :-)
Robią, tylko po pierwsze mało kto potrafi, a po drugie oni nawet szczególnie tego nie podnoszą. Jak popatrzysz na reklamę, to MSP430FR to bardzo energooszczędny procesor z bardzo szybką i dużą pamięcią nieulotną. Że ona jeszcze jest trwała, to detal. No i jest tani. :-)
Ale jest obłędnie wolny i ma krótkie ramki z długim nagłówkiem, który jeszcze bardziej ogranicza pasmo. To jest antyczny protokół multimaster z wywłaszczaniem priorytetowym. Ma kilka zalet, ale dużej ilości informacji za jego pomocą nie przepchniesz. I nie tylko mi to przeszkadza, pojawiają się na rynku transceivery M-LVDS i B-LVDS do zastosowań automotive. Skoro nawet I2C doczekało się wersji I3C, to czemu akurat CAN miałby się oprzeć upływowi czasu?
Źródło dokładnego (do kilkudziesięciu mikrosekund) czasu wewnątrz budynku, gdzie GPS nie sięga, wzorzec częstotliwości itp. niszowe zastosowania. Nie mam na myśli radiobudzika. Ale fakt, mnie chodzi o zabawę.
Procek sam w sobie nawet nie jest za wolny, tylko się gubi przy większym poziomie równoległości. I wielu rzeczy nie potrafi, np. ma 8-bitowe SPI, a ja potrzebuję odebrać 64 bity, bo gadam z mikrofonem I2S. Owszem, mogę się pomęczyć, ale po co, skoro w VHDL sobie napiszę dokładnie takie peryferia, jakie mi są potrzebne? Zegarów też bym nie porównywał, FPGA taktowana 1MHz może zawstydzić procek pędzący na 100MHz, a kosztuje podobnie.
No tak, są zadania zdecydowanie lepiej pasujące do procka. Więc sie tego procka wrzuca w FPGA. :-) Chyba każdy producent ma kilka modeli soft cores, te najmniejsze zużywają jakieś 200 LUTów. I tak to właśnie miało pierwotnie wyglądać -- szybkie rzeczy o regularnej strukturze w VHDL, dziwne z wieloma warunkowymi ścieżkami przepływu sterowania, jak np. I2C, w C na procesorku. Emulowanym. Chociaż jakieś *małe* chińskie GoWiny chwalą się ARM core na pokładzie. :-)
Dwa urządzenia wpięte w 2 rózne fazy, komunikujace się tym "zastępnikiem modbusa". W przypadku modbusa dwie fazy po dwóch stronach kabla to codzienność, w moich wynalazkach modbudowych zawsze była separacja optyczna bo inaczej były setki V różnicy. Wspomniałeś że tonastępca modbusa. Nie widzę tego.
Nie. Tylko z ilością nadających jednocześnie. I radykalnie maleje, jesli sieć jest poprawnie zaprojektowana (switche i połaczenia między nimi). Wręcz do zera, nawet najtańszy switch 100Mbit ma możliwosc przełączenia wielokrotności tej prędkosci.
Ethernet był kolizyjny w czasach kabla koncentrycznego. Czasy te, słusznie, minęły.
No ale w LAN jest podobnie, hardware w uC demultipleksuje strumienie/ramki ethernet po MAC adresie. Jeden drut to rule them all. W ethernecie brakuje tylko priorytetów, ale przecież są switche. jeśli masz urządzenie walace 3Mbity strumeinia i *jednocześnie* chcesz mieć mikrosekudowe reakcje na tym samym kablu, to coś jest ogólnie zastanawiające tej koncepcji...
Heartbeat w ethernecie.
Ale w latach 80 w powszechnym użyciu były sieci z redukcją kolizji. Zazwyczaj jakieś wariacje tokenring (Apple) i różne wynalazki których nazw nie pomnę (rodzimy Junet?). Na koniec okazało się że nie ma sensu ich "redukować". Kolizje są ok. I nie wypełniają 100% pasma, jeśli sieć jest na switchach.
No tak, ale komu to potrzebne jak zastępnik modbusa.
Ja rozumiem, na jakiejś pojedynczej płytce, czy urządzeniu, ale w automatyce, tam gdzie do tej pory był modbus? Nie widzę tego. A nawet na tej płytce łatwije będzie pociągnąc PCIe, którego coraz wiecej, zamiast innych wynalazków.
Przepraszam że tak krytykuje, ale staram się wyobrazić sobie zastosowanie i nie rozumiem gdzie są jakieś zalety:
1) chcesz szybko: ethernet jest szybki i tani
2) chcesz mieć realtime: to lepiej nie mieszaj tego z general purpose
3) chcesz mieć natychmiast: pociągnij drut
4) chcesz FPGA: prawdopodobnie masz za duży budżet
Na razie to wygląda jak magistrala z możliwością strumieniowania porno + szybka reakcja na przycisk odpalający rakiety. Coś w sam raz do silosów ;)
Trzy rezystory wystarczają do pogadania sobie na krótkim dystansie, gdzie nie ma ESD/EMP. Jak się pojawia takie ryzyko, to trzeba zabezpieczać niezależnie od protokołu. Nie piszę Ci przecież, że ethernet wymaga odgromnika plazmowego:
formatting link
Wymaga albo nie, w zależności od założonej odporności.
Akurat tutaj wystarcza "PoE". Ale LVDS przy zastosowaniu kodowania o zerowej składowej stałej, choćby antycznego Manchestera, się daje izolować kondensatorami. Maxim ma fajną notkę na ten temat.
No ale u mnie każdy moduł ma dużo do powiedzenia i nie lubi czekać.
Czasy minęły, ale świetna koncepcja została. FastEthernet dalej tak potrafi, przynajmniej w teorii. W praktyce to ciekawe, czy w ogóle testują PHY pod taki przypadek.
Przecież nie ja go wymyśliłem. Nawet norma na to jest:
Czyli wystarczy grubsze zakłócenie które cośtam wyindukuje. Czyli i tak kończy się to na grubych zabezpieczeniach przed wystraszonym FPGA, który pierdnie dymkiem na widok kilku V.
Obawiam się że to jest sprzeczne. Chyba że "kazdy moduł" ma do powiedzenia jednoczesnie 3Mbit, to najtańszy ethernet ogarnie jakieś 30 takich a ten o pół dolara droższy, 300. Innymi słowy, zjada na śniadanie, nawet bez jakiegoś QoS i magicznych priorytetów.
Zwróć uwagę, że jeśli masz typową topologię gwiazdy i każdy jest podłaczony własnym drutem do switcha, i switch jest typu store&forward (każdy współczesny) to ilość kolizji zalezy tylko od wypełnienia pasma na konkretnej dziurce. Czyli w Twoim wypadku może w ogóle nie być ani jednej kolizji, nawet jeśli jesteś blisko wydajnosci max. Kolizje *NIE* istnieją w praktyce duperelowatych transmisji po 3Mbit.
Ależ nie twierdze że sam to wymyśliłeś, ale zastepnik modbusa to obecnie jest konwerter modbus<->LAN i działa bardzo kiepsko, ale automatyk nie widzi różnicy :D. Ja zastanawiam się co nowego wymyślono proponując "lepsze" rozwiązanie. W czym ono lepsze? I tak trzeba lepić dodatkowe zabezpieczenia, wydajność taka jak ethernet 30 lat temu, priorytety brzmią zabawnie bo przecież QoS jest i w ethernecie [1] i nikogo to nie dziwi, a obie magistrale muszą czekać aż poprzedni pakiet się skończy,
1Gbit w ogóle redukuje problem responsywności do absurdalnie niskiego poziomu. 0 zalet wobec ethernetu ;) Chyba że ktoś w sprzęcie za kilka tysiaków oszczędza ja scalaku za pół dolara i gniazdu z trafem za jednego.
"Wymyśliliśmy nowy tokenring z ficzerami can aby możliwe było odpalenie bittorenta, na jednym kablu z detektorem neutrin.". Ok, może i są takie zastosowania. Ale mi się zawsze wydawało że druty są tanie. Szczeglnie jak się je kładzie nowe. I do bittorenta osobne i do eventów osobne.
To grubsze zabezpieczenie to transil jednokierunkowy i przetwornica obniżająca wytrzymująca 30V na wejściu. Złotówkę kosztuje taki transil?
No ale ja właśnie *nie* chcę gwiazdy, tylko magistralę. To ma się sensownie skalowac w górę bez dokładania kabelków. Wpinasz i działa, taka magia.
Umożliwia podłączenie wielu urządzeń do wspólnego kabelka i komunikację szerokopasmową z wykorzystaniem zasobów FPGA za 15 złotych oraz minimalnej liczby elementów zewnętrznych. FPGA i tak tam miała być z innych powodów, więc łącze jest niemal za darmo.
Jakie priorytety? To slave decyduje, co wysyła, a nie szyna. Half-duplex tak klasyczny, że aż zęby bolą.
Jakich tysiaków? Zdrowo poniżej stówy przy kilkuset sztukach. Zobaczyłeś FPGA i wkręciłeś sobie jakiegoś Virtexa-7, a rozmawiamy o płytce średnicy 45mm z jakimś Lattice z kilkoma tysiącami LUT. :D
Poza tym temat szczegółów komunikacji podniosłeś Ty, wątek jest o cenach FRAM. :D
1) jeden kabel latajacy od tokarki do frezarki, po drodze omiatając kamerę czyli oszczędzone czypiesiąt w miedzi.
Na pewno to jest dobre ;) ?
Zupełnie jak wpinanie UTP w switcha :D
Po co? Jak to jakieś I2C to pojmuje, ale jak to automatyka to pierszeństwo, myslę w swojej ignorancji, ma niezawodność. Pojedyncza magistrala jest biegunowo odległa od niezawodności.
Pewnie musze poszukać, ale nie wykluczam że znajdzie się wypasiony procesor z iface ethernetu za 15zł.
Natomiast co to za FPGA za 15zł? I w szczególności - czy podskoczy cpu za tyle samo w zastosowaniach komunikacyjnych?
Mikroskopijny scalak + malutnie gniazdko wydaje się być całkiem spoko. Zaryzykuej że to nawet bezpieczniejsze niż jakieś galwaniczne podpięcie.
Zgadza się, ale ... nagle musisz to "łacze za darmo" implementować w piętnastu innych urządzeniach. To jest ciągle za darmo w takiej sytuacji?
No o to mi chodzi, jest jakiś arbitraż na magistrali. Jedni rozwiązują go jak tokenring, inni jak ethernet. Chwilowo ethernet wygrywa, a dzięki absurdalnie niskim latency wszelakie pozostałe ficzery są bez znaczenia: ethernet gigabitowy dostarczy w warunkach kolizyjnych ramkę szybciej niż FPGA zdąży przełaczyć przerzutnik czekając na swoją kolej.
To brzmi jak zagadnienie dla AVR wobec tego :D Wyssałem z palca, ale ten palec nie jedno wyssał i niekiedy całkiem dobrze.
Ale takie poboczne wątki bywają bardzo sympatyczne.
Na przykład wychodzi w nich:
1) po co komu popsuta magistrala
2) po co komu FPGA za 15zł w zastosowaniu gdzie pewnie zje je na śniadanie CPU.
Swoją drogą pochwal się co to za FPGA za 15zł co nie wygląda jak przemalowany CPLD :D. Bo obawiam się czy po impelemntacji proto tej magistrali styknie mocy bramkowej na miganie diodą :D
Niezupełnie. Albo działa wszystko, albo nic nie działa. Stany pośrednie nic nie wnoszą, więc to nie jest wada.
Szukaj, i ja się czegoś dowiem. :)
Póki co na stole są trzy opcje. LCMXO2-1200HC-4SG32C (18 złotych), ICE40UP5K-SG48I (19.84), a jak się zdarzy cud, to LCMXO2-640HC-4SG48C (14.85). Zwłaszcza chciałbym zobaczyć CPU konkurujące z tym ICE. :)
A zasilanie skąd się weźmie bez galwanicznego podpięcia?
Err... ^C^V w VHDL?
No jak AVRek łyknie strumień danych kilkadziesiąt Mbit/s, a potem go zdecymuje i odfiltruje, to czemu nie. Może nawet 8051 da radę, najlepiej ten z Bytomia.
Niewątpliwie. :)
Bez żartów, nawet kodek 10b8b zajmuje ~160LUT. A różnicowego Manchestera można napisać w stanie pomroczności niemal bez zużycia zasobów. 1200HC wspiera gearbox 1:8, pozostałe 1:2. Na tym pierwszym sam blok IO daje potężny oversampling przy zegarze w tempie spacerowym, na pozostałych trzeba pomyśleć, ale też bez przesady.
Zapytaj elektryków samochodowych ile czasu zajmuje im znalezienie "prawie działajcej" magistrali can. Na przykład w czwartki po 16 przestają działać lewe kierunkowskazy, ale kiedy są właczone wycieraczki.
Pojedyncza maistrala nie jest w dwóch stanach. Może mieć taki śliczny stan nieustalony z gatunku "kabel zrobił się zielony, o tutaj, manie majster".
Wszystko zależy od zastosowań. Nie wiem co tam liczysz. Ale jeśli się komunikujesz, to jednak stawiam, że przetwarzasz *coś* szeregowo, a FPGA za małe aby implementować cpu w środku, więc będzie straszliwa orka albo bardzo trywialne zagadnienie z gatunku forward.
Z gniazdka 2m dalej. Wtedy to już bez znaczenia.
A jak zabranie zasobów?
Ogólnie ^C^V w przypadku HDL czasami sie nie sprawdza tak jak się wydaje. Niech Ci zabraknie 1 LUTa i dupa.
Ten z Bytomia na pewno da radę, ale skoro przetwarzasz taką ilość danych to chyba ta magistrala nie jest dla Ciebie. Sam twierdziłeś że to łyka tylko 3MBity per node.
No ale styknie na to miganie diodą czy nie ;)? Jesli ten FPGA nic nie robi tylko przepycha dane dalej to ok. Myślałem że on coś poważniejszego robi, a to tylko takie międzymordzie wychodzi na to.
Ten łazik ma to zaimplementowane, znaczy się, dali mu wincyj HDD żeby wysyłać mu upgrade software. Logiczne zatem, że hardware musi być lekko przygotowane na takie okazje, co nie opłaca się w produkcji seryjnej na Earth :) Generalnie nikomu nie zależy na tym, żeby łazikowi zwiększyć procka bo dane w końcu kiedyś spłyną. Lepiej jakby działał bezawaryjnie dłużej bo wincyj odwiedzi a to już jest zaimplementowane doświadczeniem. Sądzę zatem, że łazik nie pretenduje tutaj do funkcji "postarzania" technologicznego :)
Nie bez powodu wspomniałem żartobliwie o 8051 w tym wątku, w kontekście LAN.
Naście lat temu znajomy podskoczył do mnie, spanikowany, bo mu się niemieckie urządzenie popsuło co steruje jakas maszyną.
Pomysłałem: niemieckie, musi być dobre, pewnie też da się łatwo naprawić.
Otwarłem, a tam:
1) płytka sterująca na jakimś starym klonie 8051, jednostronna, z mostkami z drutu i ślicznym epromem (nawet nie eepromem). Roboty tyle że sterowała kilkoma triakami (bodaj) i czytała jakies krańcówki. Ot, typowy dzisiejszy projekcik w Arduino na 30 minut.
2) do niej wpięta płytka robiąca rs485, oryginalne gniazdko DB9 RS232 zastapione goldpinami i tam osadzona, zasilanie na pająka, aczkolwiek bez wątpienia zgodnego z niemieckimi normami, sądząc po średnicy przewodów. Oni na pewno mają na to jakąś normę. Nowsza, dwustronna.
3) Ale do niej, zamiast kostki w dziurze obudowy, dopięty fabryczny konwerter MODBUS<->LAN jakiejś innej firmy, we własnej obudowie, fikuśnie zamocowany tak, że przez obudowę widać tylko dziurkę ethernetu. W tamtych czasach takie konwertery kosztowały chyba więcej niż to urzadzenie było naprawdę warte, razy 10.
4) Obudowa z zaślepionymi oryginalnymi dziurami na RS232 i piny modbusa, coby nie było widać korzeni w średniowieczu, tego cudu techniki.
5) strasznie skomplikowana blacha łącząca to wszystko do kupy śrubami, coby nie latało jak w grzechotce.
Siadłem nad tym i zapłakałem. Automatyka przemysłowa w pigułce.
Niemieckie. Drogie, w zasadzie za drogie. Sądząc po ilości workaroundów musiały im ze dwa pokolenia inżynierów umrzeć i zapomnieli powiedzieć gdzie mają schematy i kod źródłowy.
A popsute to co zawsze: elektrolit spuchł. Jednak solidna niemiecka robota, po wymianie wstało i robiło co powinno.
Ogólnie problem magistrali (i technologii) w przemyśle wydaje mi się być czysto biologiczny i tylko tak można go rozwiazać, jak rozwiązuje go natura od lat. Dlatego tak ważne jest usunięcie 8051 z dydaktyki i ustawowy zakaz na początek. Żeby przerwać łańcuch zła ;) A jak sie nie da, bo przeszło do konspiracji, to rozpalonym żelazem, nie brać jeńców.
Choć prawdę mówiąc, nie ma znaczenia co nowego wymyślimy. Jestem przekonany że przy budowie windy kosmicznej czy nawet kolonizacji gwiazd, będą pracowały urządzenia na modbus z lagiem 20 sekund na odczyt, wyswietlaczem 7-seg LED, dwoma przyciskami ze skomplikowanym menu, dodatkowym wyjściem impulsowym jak by ktoś miał stoper, najlepiej z komunikacją na 2400 bodów @ 12V, bo tak jest bezpiecznie i pewniej, na całe 20 m, ale bez ECC, bo to fanaberia i koniecznie bez znormalizowanych wtyczek przez złą UE czy Uni Marsjańskiej, bo to ogranicza wolność druciarstwa i patriotyzm lokalnych producentów w wymyślaniu kwadratowych kół.
Nawet do tej najmniejszej wejdzie soft CPU i zostanie jeszcze połowa zasobów, co jest swoją drogą zadziwiające. I tak miało być początkowo, tylko potem okazało się, że procesor z pamięcią jest znacznie tańszy niż sama pamięć, więc nie będzie soft core. Zepchnie się MCU z FPGA jakimś SPI, rzeczy ciekawe zrobi w FPGA, pierdoły w MCU i będzie elegancko. To uwalnia też dużo zasobów w FPGA do zastosowań czysto komunikacyjnych
-- 1200 da radę z palcem w nosie, 640 potencjalnie też. Problem z 640 to nie za mało bramek, tylko brak wielofazowego PLL, więc potrafi obsługiwać piny IO tylko z podwójną częstotliwością zegara. 1200 z ośmiokrotną, co się bardzo przydaje przy odbiorze szybkiego strumienia.
Przecież to jest stosunkowo małe, znacznie mniejsze niż soft CPU. Wiele klocków jest gotowych, m.in. SERDES z oversamplingiem. Jest wytrawiony na krzemie przy pinach w dolnym banku, więc jego użycie to koszt zero -- pin i tak by musiał jakiś być. FPGA musi tylko zadecydować, czy widzi 0, czy 1 i wysłać do dekodera a potem do FIFO. Nadawanie to jest w ogóle banał, bo to nadajnik formuje impulsy i nie musi zgadywać, czy widzi 0,
1, czy jakś glitch na drucie. To on mówi, co jest na drucie. Mam wrażenie, że dla Ciebie FPGA to zbiór LUTów i RAMów, a tam jest jeszcze masa innych ciekawych bloczków.
Może mi też zabraknąc jednego bitu w MCU. Nie wymyślaj sztucznych problemów.
Ale te 3Mbps to jest wynik przetwarzania, które możesz nazwać kompresją. Wejściowe strumienie są znacznie większe, tylko one w ogóle nie opuszczają płytki, więc ich z punktu widzenia świata nie ma. I teraz trzeba ten wynik szybko wysłać w świat.
Robi całkiem złożone DSP. A że ze względu na duże możliwości LUTów, m.in. zdolność do pracy jako dwuportowa pamięć rozproszona, efektywne zapotrzebowanie na zasoby jest stosunkowo małe. Układ jest tak szybki, że umożliwia powtórne użycie tego samego bloku do obróbki wielu różnych źródeł danych. Wiele innych rzeczy da się z kolei rozwiązać sekwencerem: ładuję blok danych do RAM i potem odtwarzam go w pętli jak sampel. LUTów idzie tyle, co na licznik adresu tego RAM. Cała sekwencja zdarzeń jest przeliczona na zewnątrz w pytongu i podana FPGA do wierzenia. Większość moich układów sprowadza się do takiego czy inego zbioru sekwencerów i w efekcie są bardzo zwarte. Przykro mi, jeśli Cię zawiodłem.
Ale z którego roku ta konstrukcja? Nie da się ukryć, że istnieje pewne zjawisko betonowania pewnych rozwiązań konstrukcyjnych wcześniej sprawdzonych. Mie można oczekiwać, że konstrukcja z 1992 będzie na ethernecie.
Sterowanie sterowane przez Ethernet? I jeszcze przez jakis nadrzedny program LAN-Modbus?
To jaka byla wtedy alternatywa? Dac malego peceta i posadzic tam np Linuxa?
Bo dzis ... Arduino moze i fajne, ale tak natywnie Ethernetu nie posiada. Dolozyc modul mozna, ale tak po prawdzie ... skladanka niemal godna tej, co opisujesz.
W zasadzie tak, ale o w zamian? Arduino czy ARM ?
Ale czesto mniej nie trzeba, bo temperature sie mierzy powoli :-)
Naprawiałem ją koło 2005 roku, przypuszczam że z 2001 bo takie były daty produkcji na scalakach z okolicy 8051. Nie znam właściciela ani historii tego cuda, dostałem pudełko, oddałem pudełko i tyle mojej wiedzy.
Nikt nie oczekuje. Rzecz w czym innym: owszem, "nowoczesne" rozwiązania, takie jak ethernet wnikają w automatykę. Ale ponieważ to protezy na modbusa itp to w efekcie nie dają nic nowego. Dalej jest to samo dziadostwo, tylko na innym kablu. Nic dziwnego że automatyk na widok ethernetu krzywi się straszliwie. Z jego perspektywy w środku jest właśnie taki konwerter i wystawiony gówniany modbus na porcie tcp dodając tylko zbędną warstwę komplikacji, grubsze kable, jakies switche itd itp.
Mam falownik PV z wifi. Mam pompę z wifi. Zgadnij, co w obu wypadkach robi za to wifi. Podpowiadam: konwerter na modbusa.
I nie, że oba urządzenia projektowano za Łokietka. Nie. To konstrukcje mające kilka lat.
Nie da się tego uzasadnić logicznie. Tym bardziej że jestem zmuszony pauzować strumień po TCP aby poprawnie rozpoznawało ramki, czyli wbrew koncepcji TCP. Widać, że projektował to automatyk a nie informatyk i działa przypadkiem.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.