>k čemu je pak budete potřebovat?<br />
ze by k tomu, aby mohl nasledne spocitat CRC celeho telegramu?<br />
<br />
>Podle mě by se dalo spokojit i s jednodušší kontrolou než CRC16<br />
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.<br />
<br />
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.<br />
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.<br />
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.<br />
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.<br />
Osobne bych se asi rozhodoval podle dostupnosti nastroju a pro SNAP je snad jen <a href="http://www.hth.com/snap/snaptest.htm">http://www.hth.com/snap/snaptest.htm</a> a <a href="http://www.hth.com/snap/snaplab.htm">http://www.hth.com/snap/snaplab.htm</a> u MODBUS ani nevim<br />
<br />
PN<br />
<br />
<br />
<br />
_____________________________________________________________<br />
> Od: "Ladislav Vaiz" <spam@nagano.cz><br />
> Komu: HW-news <hw-list@list.hw.cz><br />
> Datum: 13.06.2010 22:54<br />
> Předmět: Re: Implementace protokolu pro RS-485?<br />
><br />
<br />
Zdravim,<br />
><br />
> Na predstava.<br />
> Komunikace je asynchronni, je tedy nutne ji v MCU zpracovavat v preruseni.<br />
<br />
Ano, hlavní program by musel mít definovanou a nízkou latenci. Lépe je <br />
zpracovat přijatý paket v přerušení. Co s ním dál, závisí na vás. Buď <br />
můžete nastvit příznak a zpracovávat v hlavní smyčce. Nebo v hlavní <br />
smyčce měřit a v paměti udržovat aktuální teplotu. V přerušení pak <br />
můžete po přijetí posledního znaku zaklíčovat budič a hned vysílat. <br />
Záleží na konkrétním případě, co je vhodnější.<br />
<br />
> V preruseni se vyhodnoti zda je prijaty byte byten synchronizacnim <br />
> pokud ano, tak se zjisti zda druhy byte odpovida adrese daneho MCU, <br />
> pokud ano tak se tyto dva <br />
<br />
k čemu je pak budete potřebovat? Podle mě už k ničemu. Možná adresu, <br />
abyste po přijetí celého paketu věděl, zda odpovídat. Ale to se dá <br />
nahradit jedním příznakem.<br />
<br />
> a vsechny nasledujci prijate byty nacpou do fronty v XRAM. Nasledne se <br />
> overi zda jsou data autenticka (CRC-16), pokud ano muze dalsi funkce <br />
> felegram vyhodnotit.<br />
<br />
Podle mě by se dalo spokojit i s jednodušší kontrolou než CRC16, ale <br />
rozhodně to ničemu nevadí a pokud ji již máte napsanou, tak proč ne.<br />
<br />
> Nebo je to cele bldost a dela se to jinak?<br />
><br />
> Vysilani nevim zda resit take pres frontu v XRAM nebo felegram <br />
> seskladat primo ve vysilaci funkci treba pomoci printf?<br />
<br />
Já mám k printf v jednočipech nedůvěru, protože netuším, co se děje <br />
uvnitř. Raději posílám data binárně ve formátu nativním pro jednočip. PC <br />
si s tím už poradí, lépe se to píše a ladí.<br />
Pokud musí jednočip něco dělat během odeslání paketu, tak bych si paket <br />
připravil v RAM a odeslal v přerušení. Tady si asi vystačíte s posíláním <br />
v hlavní smyčce a čekání na příznak odeslání (TI). Firmware tak bude <br />
jednodušší.<br />
Pro poslání pár bytů si vystačíte s interní RAM.<br />
<br />
Láďa<br />
_______________________________________________<br />
HW-list mailing list - sponsored by www.HW.cz<br />
Hw-list@list.hw.cz<br />
<a href="http://list.hw.cz/mailman/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a><br />