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.