Hello Dariusz,

Wednesday, July 17, 2013, 9:22:44 AM, you wrote:

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

[...]

Dostał na talerzu gotowca:
http://iqjar.com/jar/wp-content/uploads/2013/04/LED_
Cube_Circuit_V4.jpg
do którego dokłada jeden rejestr (zamiast 7 jak w oryginale), 8
rezystorów i resztę diod. Rejestry są w TME po niewiele ponad 1PLN.
Układ jest banalnie prosty. Czego chcieć więcej?

Ale to kolejna łajza, która przyłazi tu pojęczeć, jak jej źle zamiast
przyjąć do wiadomości, że robi coś nie tak.

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

Pawel Lampe <s...@s...com> napisał(a):
> 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.

Skąd wiesz kto jak jest związany?

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

Bo zacząłeś kreować się na jedynego co ma jakieś pojęcie.

> 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,
zasugerowano Ci jedynie, że nie wszystko co najnowsze jest adekwatne.

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

Więc dlaczego sam oceniasz ludzi, których nie znasz?

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

Nie mam słów. Twoje zachowanie jest właśnie takie, jakie zarzucasz innym.

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

Gościu, zrozum, że nikt Cię tu personalnie nie atakuje. Odsyłasz do
Tischnera, a nie potrafisz czytać ze zrozumieniem odpowiedzi, których Ci
udzielono. Zachwyciłeś się Raspberry Pi i stwierdziłeś, że skoro ma duże
możliwości, to powinno się tej platformy używać wszędzie. Gdy na grupie
powiedzano Ci, że może czasem lepiej użyć czegoś innego, to zaszufladkowałeś
dyskutantów jako oderwanych od rzeczywistości frustratów, który nie potrafią
docenić tego super wspaniałego komputerka i dlatego Cię atakują. Nie
potrafisz pojąć, że jeśli ktoś krytykuje Twój pomysł, to a) dlatego, że chce
Ci pomóc b) nie ocenia _Ciebie_. Jak możesz polecać Tischnera, skoro nawet
nie potrafisz oddzielić płaszczyzny merytorycznej od personalnej? Nie
będziesz mieć łatwo w życiu, jeśli w każdej wypowiedzi będziesz się
doszukiwał ataku na siebie.

Przyszedłeś na grupę z ciekawym tematem do dyskusji, ale zamiast się na nim
skupić zacząłeś jakieś osobiste wycieczki. Dziwisz się potem, że dyskusja
zrobiła się nieprzyjemna.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 5 days, 1 hours, 7 minutes and 53 seconds

do góry

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?

do góry

Zbych <a...@o...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.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 5 days, 1 hours, 32 minutes and 29 seconds

do góry

W dniu 2013-07-17 10:40, Grzegorz Niemirowski pisze:

>> 50. Czy używacie lamp próżniowych czy kart perforowanych.
>
> Niczego nie zrozumiałeś. Nikt Ci nie kazał używać starych technologii,

Sam chciał używać 74154. Gdzieś w piwnicy chyba jeszcze mam pozytywkę
zrobioną na nim, jeśli dobrze liczę, jakieś 34 lata temu :)
--
Pozdrawiam
Andrzej
www.symbiostock.info

do góry

Hello Grzegorz,

Wednesday, July 17, 2013, 10:40:10 AM, you wrote:

[...]

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

Rejestr przesuwający z wyjściem mocy zrealizowanym na MOSFETach ciężko
nazwać technologią starszą od 74154.

[...]

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

W dniu 17.07.2013 11:01, Grzegorz Niemirowski pisze:
> Zbych <a...@o...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.

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.

do góry

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.


--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

W dniu 17.07.2013 11:35, RoMan Mandziejewicz pisze:
> 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.

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.

do góry

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.


--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry