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

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.

do góry

Użytkownik "RoMan Mandziejewicz" napisał w
Hello Zbych,
>>>> 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.

do góry

J.F <j...@p...onet.pl> napisał(a):
> 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.

Tak, chodzi o otwieranie. I jeśli jest aplikacja, która otwiera port i go
trzyma, to problem nie jest duży, może wystarczyć po prostu ignorowanie
pierwszego bajtu. Ale w przypadku skryptu będzie gorzej. Komenda
echo a> /dev/ttyAMA0
powoduje taki efekt:
http://www.raspberrypi.org/phpBB3/download/file.php?
id=4066&sid=55bc978e7b5cc30569372ac93a0e0662

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

do góry

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.

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

do góry

W dniu 17.07.2013 12:35, RoMan Mandziejewicz pisze:
> 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ę?

Błąd jest czy tego chcesz, czy nie. Można go próbować ominąć w
sterowniku portu, albo we własnym sofcie. Być może to feler sprzętowy i
nie da się go naprawić wcale. I co dalej? Wyrzucisz RPi, czy spróbujesz
ominąć?

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

Te, na które masz wpływ to owszem, a co zrobić z tymi które pojawiają
się same? Wdeptywać, czy jednak nauczyć się omijać?

do góry

On 2013-07-16 14:26, Pawel Lampe wrote:
> Mam 16 diód które wymagają stanu wysokiego do działania. Układem ma
> sterować mikrokontroler, ale chcę oszczędzić na jego wyjściach i użyć 4
> zamiast 16.

Po drugiej stronie wstaw drugi uC jako ser->par. Wyjdzie taniej i
szybciej niż rękodzieło na ttl/cmos chyba że wymagasz absurdalnych
prędkości. Attiny2313 na dwóch (zamiast 4) drutach sterujących w sam raz.

do góry

Hello Sebastian,

Wednesday, July 17, 2013, 1:08:22 PM, you wrote:

> On 2013-07-16 14:26, Pawel Lampe wrote:
>> Mam 16 diód które wymagają stanu wysokiego do działania. Układem ma
>> sterować mikrokontroler, ale chcę oszczędzić na jego wyjściach i użyć 4
>> zamiast 16.
> Po drugiej stronie wstaw drugi uC jako ser->par. Wyjdzie taniej i
> szybciej niż rękodzieło na ttl/cmos chyba że wymagasz absurdalnych
> prędkości. Attiny2313 na dwóch (zamiast 4) drutach sterujących w sam raz.

Ale nadal pozostaje problem driverów dla LEDów - na 3 rejestrach z
wyjściami mocy masz 3 linie i też sprawę załatwia. Na dokładkę
rozwiązanie jest skalowalne.

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

do góry

On 2013-07-17 13:15, RoMan Mandziejewicz wrote:
>> Po drugiej stronie wstaw drugi uC jako ser->par. Wyjdzie taniej i
>> szybciej niż rękodzieło na ttl/cmos chyba że wymagasz absurdalnych
>> prędkości. Attiny2313 na dwóch (zamiast 4) drutach sterujących w sam raz.
> Ale nadal pozostaje problem driverów dla LEDów - na 3 rejestrach z
> wyjściami mocy masz 3 linie i też sprawę załatwia.

Nie wiem na ile dobrze rozumiem problem, ale 74154 pozwalałby zaswiecić
tylko *jedną* diodę na raz. Czyli przeciążenie wyjścia AtMegi jest jak
najbardziej okay. Zalezy jeszcze co to za diody ...

> Na dokładkę
> rozwiązanie jest skalowalne.

Zupełnie jak uC :)

Można tez wstawic kilka ekspanderów I2C, w koncu chyba Pi wystawia
magistralę I2C i kernel pozwala na komunikację bez znajomości dupereli.

do góry

Użytkownik "Sebastian Biały" napisał
>> Ale nadal pozostaje problem driverów dla LEDów - na 3 rejestrach z
>> wyjściami mocy masz 3 linie i też sprawę załatwia.

>Nie wiem na ile dobrze rozumiem problem, ale 74154 pozwalałby
>zaswiecić tylko *jedną* diodę na raz.

Pradem do ~24mA, i to tylko przy zerze.
Na diode w sam raz, do multipleksingu troche za malo.

J.

do góry

Hello Sebastian,

Wednesday, July 17, 2013, 1:41:15 PM, you wrote:

>>> Po drugiej stronie wstaw drugi uC jako ser->par. Wyjdzie taniej i
>>> szybciej niż rękodzieło na ttl/cmos chyba że wymagasz absurdalnych
>>> prędkości. Attiny2313 na dwóch (zamiast 4) drutach sterujących w sam raz.
>> Ale nadal pozostaje problem driverów dla LEDów - na 3 rejestrach z
>> wyjściami mocy masz 3 linie i też sprawę załatwia.
> Nie wiem na ile dobrze rozumiem problem, ale 74154 pozwalałby zaswiecić
> tylko *jedną* diodę na raz. Czyli przeciążenie wyjścia AtMegi jest jak
> najbardziej okay. Zalezy jeszcze co to za diody ...

Ale pełne multipleksowanie jest ryzykowne i niepotrzebne. Zdecydowanie
lepiej jest zapalać dowolną ilość diod na jednym poziomie z
multipleksowaniem poziomów tylko. Przy pełnym multipleksowaniu masz
średni prąd diody max. 1/64 szczytowego. A jak multipleksowanie przez
pomyłkę się zatrzyma, to masz przewalone - dioda płonie.

Przy rejestrach wypychasz poziom i może świecić w nieskończoność, jak
przez przypadek odpalisz wszystko na raz, to i tak prąd jest
ograniczony rezystorami kolumn do bezpiecznej wartości. No i
multipleksujesz tylko 4 zestawy danych warstw a nie 64 pojedyncze bity.

>> Na dokładkę rozwiązanie jest skalowalne.
> Zupełnie jak uC :)
> Można tez wstawic kilka ekspanderów I2C, w koncu chyba Pi wystawia
> magistralę I2C i kernel pozwala na komunikację bez znajomości dupereli.

Ale ekspandery maja słabą wydajność prądową - być może wystarczyłyby
przy multipleksowaniu tylko warstw ale niekoniecznie. Mi tam rejestry
z wyjściami mocy bardzo się spodobały :)

A najbardziej banalna prostota rozwiązania.

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

do góry