prenos 16 bitovych dat po seriovej linke

[balu@home]

ide o meranie napatia a prudu na vysokom potenciali, ktore musi byt 
galvanicky oddelene.
Na meranie prudu katody a zeravenia su pouzite jednoduche DCCT senzory 
od LEM-u, napatie klasicke odporove delice. Snima to 16 kanalovy AD 
prevodnik AD7490, ktory je zaveseny na CPLD XC2C256. Planoval som pouzit 
low cost vlaknove vysielace a prijimace HFBRxxxx, vlakno do 20m, 
pravdepodobne to velkoprierezove plastove bude stacit na tuto vzdialenost.
Nechcem to moc komplikovat, jednak nemam vela casu na vyvoj ale hlavne 
to musi byt vysoko spolahlive. AD prevodnik bude neustale vysielat data 
a prijimac len vyhodnoti ci su pakety kompletne, inak ich zahodi.
Natiahnut tam dve vlakna namiesto jedneho bude v porovnani s tymito 
vsetkymi sofistikovanymi metodami asi jednoduchsie. Do CPLD sa to 
nezmesti a male FPGA tam davat nechcem lebo to nema pevne napalenu 
konfiguraciu. Ak sa z nejakeho dovodu zacne resetovat pocas prevadzky 
bude to celkom neprijemne. CPLD je predsa len robustnejsie. Ak sa 
spravne naprogramuje tak pripadna chyba sa sama vycisti po prebehnuti 
jedneho kompletneho cyklu, takze vypadne max. jeden ramec.
Jedno vlakno bude prenasat hodiny a druhe CS signal s datami. CS na 
padajucej hrane hodin a data na nabeznej.
Toto by malo byt pomerne odolne a da sa tam zabalit lubovolny pocet 
bitov do jedneho paketu.
Dakujem vsetkym za nazory, je to zaujimave citanie a material na 
rozmyslanie. Pojdem ale nakoniec cestou 'keep it simple' :-)
b.




On Dec/23/2011 15:39, Jan Waclawek wrote:

>
> Ak ta optika (o ktorej tiez nic nevieme) vie prenasat 8- alebo 12-bitovy UART, tak s breakom v trvani 9/13 bitov zrejme tiez nebude mat problemy. Naviac Dano spomenul aj prenos data/clock osobitnymi vlaknami, kde uz vobec nie je zarucene ze sa vyskytuju obe polarity dostatocne hojne, takze zrejme ta uvazovana optika s tym problem nema.
>
> Nie je samozrejme nemozne siahnut po hotovom rieseni, ale mal som pocit, ze Dano spominal na vysielacej strane nejake jednoduche CPLD. U zlozitejsich protokolov moze byt tiez problematicke zabezpecit synchronicitu/konstantnu efektivnu prenosovu rychlost. U Ethernetu apod. to vobec nevadi, rata sa s tym, ale Danovej aplikacii to moze vadit.
>
> wek