Jak efektywnie zrealizować negację wyjść układu 74154 przy użyciu inwerterów?

W dniu 2013-07-16 15:57, Pawel Lampe pisze:
No właśnie czegoś takiego chcę uniknąć. Dlatego pytałem.
No bo temat nie jest trywialny jak chcesz uprościć i boisz się pewnych
rozwiązań.
Układ 74154 jest generalnie niefajny, bo to wielkie bydlę, drogie, i w
zasadzie nic ciekawego nie oferuje. Już chyba fajniej się używa
mniejszych 138, ale one też mają aktywny stan niski.

No tak. Małe, proste pytanie i robi się ogromna dyskusja. Skrytykowałem
tych co bezpodstawnie oceniają używanie RasPi i tym samym atakują mnie,
po czym od razu lawina krytyki. W dodatku od całkiem niezwiązanych z
tematem osób.

"Ten napisał 3 linie w COBOL-u i programuje od 20 lat. Tamten wie wszystko
o jądrze i commituje do niego 100 linii dziennie."

Nie twierdzę, że nie. Na tej grupie na pewno są dużo lepsi. Może i
niektórzy z was. Nie obchodzi mnie jednak czy programujecie 20 lat czy
50. Czy używacie lamp próżniowych czy kart perforowanych.

Po prostu boli mnie takie ocenianie w ciemno ze strony tych którzy się nie
znają.

To takie polskie. Ocenić każdego. Sąsiad krzywo skosił trawnik, tamten
nie śpiewał w kościele. Kpić i oceniać. Najgorsze, że macie pewnie po
30, 40 lat.

Dziękuję tym którzy odpowiedzieli na temat.
Reszcie polecam lekturę Tischera.

jakiegoś czasu aplikację na tę platformę i mam dołączoną własną płytkę
gadającą z RasPi po serialu, I2C i I2S. A jak znasz jakiegoś eksperta,
to niech poprawi w jądrze sterownik portu szeregowego. Ja na razie piszę
inny moduł do jądra.

W dniu 16.07.2013 18:01, Grzegorz Niemirowski pisze:
jakiegoś czasu aplikację na tę platformę i mam dołączoną własną płytkę
gadającą z RasPi po serialu, I2C i I2S. A jak znasz jakiegoś eksperta,
to niech poprawi w jądrze sterownik portu szeregowego. Ja na razie piszę
inny moduł do jądra.
Możesz się podzielić informacją co konkretnie jest schrzanione?

50. Czy używacie lamp próżniowych czy kart perforowanych.

Niczego nie zrozumiałeś. Nikt Ci nie kazał używać starych technologii,

Nie twierdzę, że nie. Na tej grupie na pewno są dużo lepsi. Może i
niektórzy z was. Nie obchodzi mnie jednak czy programujecie 20 lat czy
50. Czy używacie lamp próżniowych czy kart perforowanych.
Niczego nie zrozumiałeś. Nikt Ci nie kazał używać starych technologii,

Zbych <abuse@onet.pl> napisał(a):
W dniu 16.07.2013 18:01, Grzegorz Niemirowski pisze:
jakiegoś czasu aplikację na tę platformę i mam dołączoną własną płytkę
gadającą z RasPi po serialu, I2C i I2S. A jak znasz jakiegoś eksperta,
to niech poprawi w jądrze sterownik portu szeregowego. Ja na razie piszę
inny moduł do jądra.
Możesz się podzielić informacją co konkretnie jest schrzanione?

Podczas otwierania portu pojawia się stan niski na TXD na jakieś 32
mikrosekundy, co może zostać odebrane przez drugie urządzenie jako bit
startu i transmisję bajtu. Wiele osób tego nie zauważa, bo używają
prędkości rzędu 9600 bps i logika UARTa odbiorczego, która zwykle robi
trzykrotne próbkowanie w okresie 1 bitu, i zignoruje taką szpilkę.
Dlatego nie na każdej stronie poświęconej RaspPi i portowi szeregowemu
ten problem jest wspomniany. Jednak przy prędkościach rzędu 115200 bps
ta szpilka już jest traktowana jako pełnoprawny bit startu i ludzie
piszą, że odbierają bajt 0xFF nie wiadomo skąd.
Rozwiązań jest kilka. Najprościej jechać na 9600 bps. Można też
skorzystać ze sprzętowego sterowania przepływem. Można też, o ile się
da, zrobić w urządzeniu odbiorczym ignorowanie tego bajtu.
Nie wiem na 100% gdzie leży błąd. Jest albo w peryferium PL011 układu
BCM2835, albo w sterowniku w jądrze Linuksa. Nie zauważyłem żeby ktoś
wykonywał jakąś głębszą analizę tego problemu, a googlałem sporo.
Niezależnie jednak od tego czy jest to bug w sprzęcie czy w kernelu, to
problem można rozwiązać na poziomie jądra, żeby ludzie piszący aplikacje
na Raspberry Pi nie musieli się męczyć z problemem, który jest nieznany
na innych platformach.

Podczas otwierania portu pojawia się stan niski na TXD na jakieś 32
mikrosekundy, co może zostać odebrane przez drugie urządzenie jako bit
startu i transmisję bajtu.

Jednak przy prędkościach rzędu 115200 bps
ta szpilka już jest traktowana jako pełnoprawny bit startu

Dzięki za wyjaśnienie. Zastanawiam się tylko, czy sam bym z tym walczył,
czy uznał to za zakłócenie jak każde inne i protokół komunikacji musi
być na nie odporny.

Hello Zbych,

Wednesday, July 17, 2013, 11:28:46 AM, you wrote:

[...]

Podczas otwierania portu pojawia się stan niski na TXD na jakieś 32
mikrosekundy, co może zostać odebrane przez drugie urządzenie jako bit
startu i transmisję bajtu.

[...]

Jednak przy prędkościach rzędu 115200 bps
ta szpilka już jest traktowana jako pełnoprawny bit startu

[...]

Dzięki za wyjaśnienie. Zastanawiam się tylko, czy sam bym z tym walczył,
czy uznał to za zakłócenie jak każde inne i protokół komunikacji musi
być na nie odporny.

Przy prędkości 115200bps 32us to bit startu i rozpoznane trzy bity
treści. Zakłócenia tyle nie trwają. 9600 to maksymalna prędkość, przy
której można to traktować jako zakłócenie do sprzętowego ominięcia.
przy 19200 już będzie FF a nie możesz zakładać, że każde FF to błąd.

Podczas otwierania portu pojawia się stan niski na TXD na jakieś 32
mikrosekundy, co może zostać odebrane przez drugie urządzenie jako bit
startu i transmisję bajtu.

[...]

Jednak przy prędkościach rzędu 115200 bps
ta szpilka już jest traktowana jako pełnoprawny bit startu

[...]

Dzięki za wyjaśnienie. Zastanawiam się tylko, czy sam bym z tym walczył,
czy uznał to za zakłócenie jak każde inne i protokół komunikacji musi
być na nie odporny.

Przy prędkości 115200bps 32us to bit startu i rozpoznane trzy bity
treści. Zakłócenia tyle nie trwają. 9600 to maksymalna prędkość, przy
której można to traktować jako zakłócenie do sprzętowego ominięcia.
przy 19200 już będzie FF a nie możesz zakładać, że każde FF to błąd.

Zapominasz, że porządny protokół ma sumę kontrolną i sposób
synchronizacji ramki (czy to przez timeouty, czy przez unikatowy bajt
startu, stopu). Ja bez problemu potrafię zsynchronizować transmisję
nawet jak mi wyślesz 1kB śmieci na początku.

Hello Zbych,

Wednesday, July 17, 2013, 11:41:17 AM, you wrote:

Podczas otwierania portu pojawia się stan niski na TXD na jakieś 32
mikrosekundy, co może zostać odebrane przez drugie urządzenie jako bit
startu i transmisję bajtu.

[...]

Jednak przy prędkościach rzędu 115200 bps
ta szpilka już jest traktowana jako pełnoprawny bit startu

[...]

Dzięki za wyjaśnienie. Zastanawiam się tylko, czy sam bym z tym walczył,
czy uznał to za zakłócenie jak każde inne i protokół komunikacji musi
być na nie odporny.

Przy prędkości 115200bps 32us to bit startu i rozpoznane trzy bity
treści. Zakłócenia tyle nie trwają. 9600 to maksymalna prędkość, przy
której można to traktować jako zakłócenie do sprzętowego ominięcia.
przy 19200 już będzie FF a nie możesz zakładać, że każde FF to błąd.

Zapominasz, że porządny protokół ma sumę kontrolną i sposób
synchronizacji ramki (czy to przez timeouty, czy przez unikatowy bajt
startu, stopu). Ja bez problemu potrafię zsynchronizować transmisję
nawet jak mi wyślesz 1kB śmieci na początku.

Zapominasz, że jeśli start każdej ramki jest obciążony błędem, to
będziesz transmitował w nieskończoność z błędami. To jest błąd
systematyczny a nie przypadkowe zakłócenie.

Owszem, można wykonać partaninę polegająca na świadomym założeniu, że
każda ramka zaczyna się błędem ale to jest manana a nie solidna
robota. Błąd należy po prostu wyeliminować raz na zawsze a nie omijać
jak śmierdzące psie gówno na chodniku.

Podczas otwierania portu pojawia się stan niski na TXD na jakieś
32
mikrosekundy, co może zostać odebrane przez drugie urządzenie
jako bit
startu i transmisję bajtu.
Zapominasz, że porządny protokół ma sumę kontrolną i sposób
synchronizacji ramki (czy to przez timeouty, czy przez unikatowy
bajt
startu, stopu). Ja bez problemu potrafię zsynchronizować transmisję
nawet jak mi wyślesz 1kB śmieci na początku.

Zapominasz, że jeśli start każdej ramki jest obciążony błędem, to
będziesz transmitował w nieskończoność z błędami. To jest błąd
systematyczny a nie przypadkowe zakłócenie.
Owszem, można wykonać partaninę polegająca na świadomym założeniu, że
każda ramka zaczyna się błędem ale to jest manana a nie solidna
robota. Błąd należy po prostu wyeliminować raz na zawsze a nie omijać
jak śmierdzące psie gówno na chodniku.

Ale kolega napisal "przy otwieraniu portu". Czyli raz, a potem czysto.
To jest manana a nie solidna robota, jesli protokol nieodporny na chwilowe
bledy.
Z drugiej strony ... inny kolega zachwalal linuxa na tym ?
Skrypt jakis napisze, bedzie wypluwal cos na port co sekunde, i juz nad
zamykaniem nie zapanuje.
J.

Zapominasz, że jeśli start każdej ramki jest obciążony błędem, to
będziesz transmitował w nieskończoność z błędami. To jest błąd
systematyczny a nie przypadkowe zakłócenie.
Mowa była o błędzie w momencie otwarcia portu. Chyba nie otwierasz i nie
zamykasz portu przy każdej ramce?

Owszem, można wykonać partaninę polegająca na świadomym założeniu, że
każda ramka zaczyna się błędem ale to jest manana a nie solidna
robota. Błąd należy po prostu wyeliminować raz na zawsze a nie omijać
jak śmierdzące psie gówno na chodniku.
Ja bym powiedział, że omijanie psich gówien to cenna umiejętność i to
niezależnie czy są generowane przypadkowo, czy deterministycznie.

Hello Zbych,

Wednesday, July 17, 2013, 12:04:33 PM, you wrote:

[...]

Zapominasz, że jeśli start każdej ramki jest obciążony błędem, to
będziesz transmitował w nieskończoność z błędami. To jest błąd
systematyczny a nie przypadkowe zakłócenie.
Mowa była o błędzie w momencie otwarcia portu. Chyba nie otwierasz i nie
zamykasz portu przy każdej ramce?

A ktoś mi zabrania? Mam godzinami trzymać otwarty port tylko dlatego,
że ktoś spieprzył jego obsługę?

Owszem, można wykonać partaninę polegająca na świadomym założeniu, że
każda ramka zaczyna się błędem ale to jest manana a nie solidna
robota. Błąd należy po prostu wyeliminować raz na zawsze a nie omijać
jak śmierdzące psie gówno na chodniku.
Ja bym powiedział, że omijanie psich gówien to cenna umiejętność i to
niezależnie czy są generowane przypadkowo, czy deterministycznie.

A ja uważam, że psie gówna należy po prostu sprzątać a nie zmuszać
innych do ich omijania.