J.F. wrote:

> Czekaj czekaj - bo jak urzadzenia mocno osobne, to transformatorek lub
> optoizolacja by sie przydaly.

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.

> No nie. Ale czy to naprawde wada?

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.

> Tylko moment - chcesz na na jednej parze, to albo bedziesz mial kolizje,
> albo masz jakis protokol, chocby pytanie-odpowiedz.

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.

Pozdrawiam, Piotr

do góry

J.F. wrote:

> Ale tego wymagania nie pisales.

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. :-)

> Tylko ... skoro nie robia, to widac nikomu niepotrzebne :-P

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. :-)

> CAN to teraz w samochodach - nie powinno brakowac.

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?

> IMO - i tak bedziesz jakiegos procka potrzebowal ... bo nawet jak
> zdekodujesz w FPGA, to po co Ci ten sygnal?

Ź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ę.

> Tzn zebysmy sie zrozumieli - nie namawiam do wciskania do procka
> wszystkiego,
> szczegolnie jesli zadanie pasuje do FPGA, a w procku bedzie za wolno.

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.

> Tylko czy bys procka nie potrzebowal i tak ?
> Bo IMO - czesc zadan lepiej pasuje do FPGA, czesc do procka.
> Najlepiej miec oba :-)

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. :-)

Pozdrawiam, Piotr

do góry

On 26/04/2021 10:38, Piotr Wyderski wrote:
>> A jak z odpornością na przepięcia?
> Do tego są osobne elementy, które w ethernecie też musisz mieć w stopniu
> spełniającym przyjęte założenia. Może nawet takie same.

Czyli nie 3 rezystory. OK, komplikuje się.

>> Albo zasilanie z różnych faz?
> To wisi na jednej skrętce SELV, jakich różnych faz?

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.

>> Praktyka kilkudziesięciu lat LANów pokazuje że to nie jest prawda.
>> Kolizje są, ale nie "zjadają całego pasma".
> Prawdopodobieństwo kolizji gwałtownie rośnie z liczbą urządzeń na kablu.

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.

> Przecież real-time nie oznacza "natychmiast". Master odpytuje cyklicznie
> slave i demultipleksuje strumienie.

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...

> Dzięki szybkości sieci nie muszę
> przerywać transmitowanego pakietu. Pakiety są krótkie, a maksymalny czas
> rozpoczęcia udzielania odpowiedzi znany, więc od razu widać, czy coś
> zdechło. Nie ma aktywności na drucie, znaczy trup.

Heartbeat w ethernecie.

>> Pfff, a miało być 200Mbit a tu tylko reinvented token-ring z
>> prioryteteami :D Lata 80te ;)
> Nawet nie token ring w jego pełnym rozumieniu, nie ma dynamicznie
> wybieranego mastera. Jest jeden wyznaczony węzeł i odpytuje swoje
> slaves, dokłanie jak w USB. Plus szczątkowy broadcasting. Token jest
> tylko po to, by chwilowo zezwolić na dostęp do medium. Mam wrażenie, że
> to jest znacznie starszy pomysł niż lata 80. Tylko strumienie są większe
> niż wtedy bywały i się kilkadziesiąt Mbps uskłada.

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.

> Dodaj zapas na narzuty warstwy transportowej (CRC, nagłówki
> synchronizujące zegary itp.), bufor na retransmisję błędnych pakietów,
> detekcję bezczynności łącza i masz te 100-200Mbps. I to jest mała
> prędkość jak na LVDS.

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 ;)

do góry

On Mon, 26 Apr 2021 11:11:22 +0200, Piotr Wyderski wrote:
> Marek wrote:
>> Ile razy spotkałeś się z czymś takim?
>
> Kilkukrotnie w przypadku pendrive i kart pamięci, z MCU nie przypominam
> sobie. Ale to nie ma znacznia. Producent pisze np. 10 lat, to przyjmuję
> 10 lat, a nie trzymam kciuki za 100 lat.

Ciekawe, jak sobie wspolczesni producenci radza.
troche trzymaja kciuki, a troche nie?
Wszak jak padnie, to zarobek bedzie :)

> MSP430 mają 100 lat, FRAM
> Cypressa 150 lat, a MRAM milion lat (czyli się prędzej obudowa chipu
> rozpadnie niż on straci dane). Jest z czego wybierać.

Taa ... tylko oni tych 100 lat nie sprawdzili :-)

J.

do góry

On Mon, 26 Apr 2021 11:33:22 +0200, Piotr Wyderski wrote:
> J.F. wrote:
>> Czekaj czekaj - bo jak urzadzenia mocno osobne, to transformatorek lub
>> optoizolacja by sie przydaly.
>
> 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.

tylko ze LED jest jakby odporniejszy, niz te nanoskoipijne bramki
CMOS.
I jest z natury odporny na wysokie napiecie CM (miedzymasowe).

No i mimo, ze komunikacji nie ma to czasem lepiej, zeby mozliwie duzo
przetrwalo.
I np wysiadl jeden modul a nie wszystko.

>> No nie. Ale czy to naprawde wada?
>
> 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.

Kolejnego switcha dostawisz.

> Szybka sieć
> mutidrop daje duży zapas.

Zeby sie nie okazalo, ze ja pojemnosci wykanczaja.

>> Tylko moment - chcesz na na jednej parze, to albo bedziesz mial kolizje,
>> albo masz jakis protokol, chocby pytanie-odpowiedz.
>
> 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 to jak najbardziej tak.
Ale Ethernet tez to ma, a ARM moze miec go w sprzecie :-)

J.

do góry

heby wrote:

> Czyli nie 3 rezystory. OK, komplikuje się.

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:

https://pl.mouser.com/ProductDetail/bourns/2056-09-a
lf/?qs=fHBAHxtERQgxpJZHYzMVKA%3D%3D&countrycode=PL&c
urrencycode=PLN

Wymaga albo nie, w zależności od założonej odporności.

> Dwa urządzenia wpięte w 2 rózne fazy, komunikujace się tym "zastępnikiem
> modbusa".

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.

> Nie. Tylko z ilością nadających jednocześnie.

No ale u mnie każdy moduł ma dużo do powiedzenia i nie lubi czekać.

> Ethernet był kolizyjny w czasach kabla koncentrycznego. Czasy te,
> słusznie, minęły.

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.

> No tak, ale komu to potrzebne jak zastępnik modbusa.

Przecież nie ja go wymyśliłem. Nawet norma na to jest:

https://www.ti.com/lit/an/slla108a/slla108a.pdf

> 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 ;)

Ciepło, ciepło. ;)

Pozdrawiam, Piotr

do góry

On 26/04/2021 19:49, Piotr Wyderski wrote:
>> Dwa urządzenia wpięte w 2 rózne fazy, komunikujace się tym
>> "zastępnikiem modbusa".
> Akurat tutaj wystarcza "PoE".

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.

>> Nie. Tylko z ilością nadających jednocześnie.
> No ale u mnie każdy moduł ma dużo do powiedzenia i nie lubi czekać.

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.

>> Ethernet był kolizyjny w czasach kabla koncentrycznego. Czasy te,
>> słusznie, minęły.
> 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.

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.

>> No tak, ale komu to potrzebne jak zastępnik modbusa.
> Przecież nie ja go wymyśliłem. Nawet norma na to jest:
> https://www.ti.com/lit/an/slla108a/slla108a.pdf

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.

[1] https://en.wikipedia.org/wiki/IEEE_802.1Q

do góry

heby wrote:

> 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.

To grubsze zabezpieczenie to transil jednokierunkowy i przetwornica
obniżająca wytrzymująca 30V na wejściu. Złotówkę kosztuje taki transil?

> 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.

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.

> widzi różnicy :D. Ja zastanawiam się co nowego wymyślono proponując
> "lepsze" rozwiązanie. W czym ono lepsze?

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.

> priorytety brzmią zabawnie bo przecież QoS jest i w ethernecie

Jakie priorytety? To slave decyduje, co wysyła, a nie szyna. Half-duplex
tak klasyczny, że aż zęby bolą.

> Chyba że ktoś w sprzęcie za kilka
> tysiaków oszczędza ja scalaku za pół dolara i gniazdu z trafem za jednego.

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

Pozdrawiam, Piotr

do góry

On 26/04/2021 20:32, Piotr Wyderski wrote:
> No ale ja właśnie *nie* chcę gwiazdy, tylko magistralę.

Czyli chcesz wszelkie wady magistrali:
1) kolizyjność
2) awaryjność

Oraz zaletę:
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 ;) ?

> To ma się
> sensownie skalowac w górę bez dokładania kabelków. Wpinasz i działa,
> taka magia.

Zupełnie jak wpinanie UTP w switcha :D

>> widzi różnicy :D. Ja zastanawiam się co nowego wymyślono proponując
>> "lepsze" rozwiązanie. W czym ono lepsze?
> Umożliwia podłączenie wielu urządzeń do wspólnego kabelka

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.

> i komunikację
> szerokopasmową z wykorzystaniem zasobów FPGA za 15 złotych

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?

> oraz
> minimalnej liczby elementów zewnętrznych.

Mikroskopijny scalak + malutnie gniazdko wydaje się być całkiem spoko.
Zaryzykuej że to nawet bezpieczniejsze niż jakieś galwaniczne podpięcie.

> FPGA i tak tam miała być z
> innych powodów, więc łącze jest niemal za darmo.

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?

>> priorytety brzmią zabawnie bo przecież QoS jest i w ethernecie
> Jakie priorytety? To slave decyduje, co wysyła, a nie szyna. Half-duplex
> tak klasyczny, że aż zęby bolą.

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.

>> Chyba że ktoś w sprzęcie za kilka
>> tysiaków oszczędza ja scalaku za pół dolara i gniazdu z trafem za
>> jednego.
> 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

To brzmi jak zagadnienie dla AVR wobec tego :D Wyssałem z palca, ale ten
palec nie jedno wyssał i niekiedy całkiem dobrze.

> Poza tym temat szczegółów komunikacji podniosłeś Ty, wątek jest o cenach
> FRAM. :D

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

do góry

heby wrote:

> Na pewno to jest dobre ;) ?

Dokładnie tego chcę. :)

> 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.

Niezupełnie. Albo działa wszystko, albo nic nie działa. Stany pośrednie
nic nie wnoszą, więc to nie jest wada.

> Pewnie musze poszukać, ale nie wykluczam że znajdzie się wypasiony
> procesor z iface ethernetu za 15zł.

Szukaj, i ja się czegoś dowiem. :)

> Natomiast co to za FPGA za 15zł? I w szczególności - czy podskoczy cpu
> za tyle samo w zastosowaniach komunikacyjnych?

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. :)

> Mikroskopijny scalak + malutnie gniazdko wydaje się być całkiem spoko.
> Zaryzykuej że to nawet bezpieczniejsze niż jakieś galwaniczne podpięcie.

A zasilanie skąd się weźmie bez galwanicznego podpięcia?

> 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?

Err... ^C^V w VHDL?

> To brzmi jak zagadnienie dla AVR wobec tego :D

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.

> Ale takie poboczne wątki bywają bardzo sympatyczne.

Niewątpliwie. :)

> 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

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.

Pozdrawiam, Piotr

do góry