Implementace protokolu pro RS-485?

[Pavel Novotny]

>k čemu je pak budete potřebovat?
ze by k tomu, aby mohl nasledne spocitat CRC celeho telegramu?

>Podle mě by se dalo spokojit i s jednodušší kontrolou než CRC16
jj , ale tazatel pise, ze ma Cygnal procesory, to je dnes Silab a rada jejich procesoru ma hw jednotku pro vypocet CRC16, 32 takze osobne take na techto MCU pouzivam CRC16 prednostne.

Souhlasim i s printf, pokud mate frontu je logickou volbou nasypat data do fronty, pak nahodit TI a frontu vysypat na port, pokud mate sbernici master slave tak MCU vysila jen jako odpoved na dotaz tak by nemel hrozit prijem noveho paketu pri zapisu paketu pro vysilani.
SNAP obcas take pouzivam, ma sve kouzlo, je jednoduchy a pokud si clovek vybere jen to co potrebuje da se takove rozhrani napsat za hodku, dve.
Na druhou stranu, protokol se nikam nesune, nemyslim ani tak nove verze, ale to, ze nikdo neaktualizuje, nastroje, knihovny pro PC a i vzorove implementace jsou jen v nejakem basicu, ci co to je.
Alternativou muze byt MODBUS, ale jelikoz nevim o vzorove implementaci pro x52 tak zde nevidim jednoznacny duvod proc pouzit jeden nebo druhy protokol, krome toho , ze MODBUS je defakto prumyslovy standard.
Osobne bych se asi rozhodoval podle dostupnosti nastroju a pro SNAP je snad jen http://www.hth.com/snap/snaptest.htm a http://www.hth.com/snap/snaplab.htm u MODBUS ani nevim

PN
 
 

_____________________________________________________________
> Od: "Ladislav Vaiz" 
> Komu: HW-news 
> Datum: 13.06.2010 22:54
> Předmět: Re: Implementace protokolu pro RS-485?
>

Zdravim,
>
> Na predstava.
> Komunikace je asynchronni, je tedy nutne ji v MCU zpracovavat v preruseni.

Ano, hlavní program by musel mít definovanou a nízkou latenci. Lépe je 
zpracovat přijatý paket v přerušení. Co s ním dál, závisí na vás. Buď 
můžete nastvit příznak a zpracovávat v hlavní smyčce. Nebo v hlavní 
smyčce měřit a v paměti udržovat aktuální teplotu. V přerušení pak 
můžete po přijetí posledního znaku zaklíčovat budič a hned vysílat. 
Záleží na konkrétním případě, co je vhodnější.

> V preruseni se vyhodnoti zda je prijaty byte byten synchronizacnim 
> pokud ano, tak se zjisti zda druhy byte odpovida adrese daneho MCU, 
> pokud ano tak se tyto dva 

k čemu je pak budete potřebovat? Podle mě už k ničemu. Možná adresu, 
abyste po přijetí celého paketu věděl, zda odpovídat. Ale to se dá 
nahradit jedním příznakem.

> a vsechny nasledujci prijate byty nacpou do fronty v XRAM. Nasledne se 
> overi zda jsou data autenticka (CRC-16), pokud ano muze dalsi funkce 
> felegram vyhodnotit.

Podle mě by se dalo spokojit i s jednodušší kontrolou než CRC16, ale 
rozhodně to ničemu nevadí a pokud ji již máte napsanou, tak proč ne.

> Nebo je to cele bldost a dela se to jinak?
>
> Vysilani nevim zda resit take pres frontu v XRAM nebo felegram 
> seskladat primo ve vysilaci funkci treba pomoci printf?

Já mám k printf v jednočipech nedůvěru, protože netuším, co se děje 
uvnitř. Raději posílám data binárně ve formátu nativním pro jednočip. PC 
si s tím už poradí, lépe se to píše a ladí.
Pokud musí jednočip něco dělat během odeslání paketu, tak bych si paket 
připravil v RAM a odeslal v přerušení. Tady si asi vystačíte s posíláním 
v hlavní smyčce a čekání na příznak odeslání (TI). Firmware tak bude 
jednodušší.
Pro poslání pár bytů si vystačíte s interní RAM.

Láďa
_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20100614/71fa4b76/attachment.htm>