Domaci automatizace

[Marek Pavlu]

Zdravim,



// -----Original Message-----
// From: hw-list-bounces@hw.cz [mailto:hw-list-bounces@hw.cz] On Behalf Of
// Pavel Novotny
// Sent: Wednesday, May 11, 2005 10:44 AM
// To: 'HW-news'
// Subject: RE: Domaci automatizace
// 
// 
// >Tim, ze vyradite rodinu PIC, ale i AVR, eZ8 a dalsi se vystavujete
// znacnemu
// nebezpeci, ze mnoho lidi od toho da ruce pryc:((((.
// >Naopak by se melo postupovat naproasto opacne.
// 
// Kohokoliv vyrazovat nebylo mim umyslem, otevrenost standartu musi byt
// zaklad, ale stejne tak je treba zacit s nejakym konktetnim hw a zmeho
// pohledu se jako nejvhodnejsi jevi rodina x51 pro svou rozsirenost a
// nenavazanost na jednoho vyrobce. Jeste uvazuji o AVR, ale to je v
// soucasne
// fazi relativne nedulezite.
[M.P.] 

Nutnost zacit s konkretnim HW ja nezpochybnuji, ale aby to bylo skutecne
otevrene, tak musite zohlednit i dalsi rodiny procesoru. Pokud ted zacnete
rovnou palit od boku kod bez toho, ze budete akceptovat nejaklou definici
univerzalniho procesoru, kterou dokazi splnit vsechny vybrane procesory
akorat nektere o neco vybavenejsi nez jine, tak se dostanete do faze, kdy
treba jiz nebude mozne prenest projekt na dalsi typ.

Mne jde jen o to, aby se kod v kazdem procesoru z ruznych rodin rozdelil na
ciste sitovou cast s univerzalnim rozhranim a kod vlastní inteligence prvku
pak bylo možno s minimem uprav prenest na jiny procesor...


// Jak se zda nejsou vetsi namitky proti fyzicke vrstve komunikacniho kanalu
// a
// to RS485. Popravde tezko vymyslime neco lepsiho co by bylo  stejne snadno
// a
// levne realizovatelne. Padl zde navrh na rozdelovani site na subsite,
// jiste
// to je jedna z moznosti, ale z meho pohledu se tim vyrazdne zeslozituje a
// zneprehlednuje cela struktura a nevidim nic co by to jednoznacne
// vyvazovalo.
[M.P.] 

Tohle je sporne, když zacinal DOS, tak si nikdo nedovedl predstavit
programy, ktere by na beznem PC potrebovaly vic nez necele mega pameti. A
ejhle, dneas tu mame mamuty, co spolknou z fyzicke [pameti par set mega a
ještě část beha ve swapu na disku:).

Takze ja bych sel cestou, kdy umoznim dostatecny rozsah adresovani a nezavru
si dvirka do budoucna. TO plati i o moznosti doplnit v pripade potreby bloky
subsiti. Taky musite uvazovat, ze 256 cidel rozmistenych na velmi dlouhe
kabelazi nutne povede ke snizeni rychlosti uz jen z duvodu delky kabelaze.
 

// Pri pouziti vhodneho budice RS-485 lze na jednu sbernici umistit 256 nodu
// a
// to by melo byt vice nez dost i pro Karlstejn vcetne rizeni hladomorny :-
// ).
[M.P.] 

Muj nazor je vyse:).


// 
// Domnivam se, ze hlavni otazkou nyni je nalezeni dalsi vrstvy komunikace a
// to
// je komunikacni protokol. Lze zacit stavet na zelene louce, ale  osobne
// bych
// sahl po necem hotovem k cemu existuje dokumentace a nejake hotove sw
// nastroje (analyzatory protokolu, knihovny pro PC nerku-li MCU ). Svou
// prvni
// automatizaci jsem stavel na orezanem S.N.A.P protokolu
// http://www.hth.com/snap/ , ale nejak se prestal vyvijet.
// 
[M.P.] Tohle neznam, ale prave vychazet z nejakeho definovaneho protokolu
vede k nutnosti orezavat pozadavky, ale i puvodni protokol nebo ho proste
predelavat postupne k obrazu svemu:).

// 
// 1. Existuje nejaky "hotovy" protokol vhodny pro tuto aplikaci ?
// 2. Jak by melo vypadat komunikacni schema Master-Slave, Multimaster ? Dle
// meho nazoru by u tohoto typu aplikace kde je pozadovana rock-solid
// stabilita
// a blbuvzdornost mel byt pouzit model Master- Slave, kde nadrizene
// zarizeni
// ridici celou automatizaci postupne oslovuje jednotlive slave zarizeni. Je
// to
// jednoduche, nekolizni, kdyz je nejhur staci vypnout mastra a sit se
// rozpadne
// na jednotlive izolovane ostrovy, ktere toho moc neumi, ale v dome se
// sviti,
// topi a chova se jako bezny dum bez inteligence. Pripoustim ma to radu
// nevyhod, priklad modul svetel se bez mastra nedozvi od meteo modulu zda
// uz
// je tma
[M.P.] 

No ale prece kdyz mate jedno centrum inteligence, které je master a dotazuje
se kazdeho zatrizeni na stav, tak jak muzete docilit toho, aby pri jeho
vypadku zustaly zive svetla a dalsi?

To mi nedava smysl, prece kdyz vypinac musi sve pozadavky shromazdovat,
dokud si o nej master nerekne, tak to bude delat donekonecna. Jedine, ze by
ho to po chvili prestalo bavit a oslovil jednotku rizeni svetla sam. Ale to
uz je nutne multimaster:))).


// 3. Jak resit sw pro hlavni ridici jednotku, nerkuli zda je vhodnejsi
// compilovany nebo interpretovany jazyk je v teto fazi mene dulezite, ale
// jak
// uz jsem psal i jako priznivec C/C++ C# nemohu nevidet znacne vyhody
// interpretovanych jazyku v techto modularnich aplikacich.
[M.P.] 

Ja tam jaksi zadne vyhody nevidim. Když udelam kod v C/C++, tak si muzu
vymyslet deset testovacich programku, které dany kod proveri. To same se o
interpretrech vetsinou rict neda a nebo to nejde tak zlehka:(.

// 
// 
// Hlavni otazkou je zda lze najit nejaky vhodny, jednoduchy a otevreny
// komunikacni protokol ?
[M.P.] 

Proc hledat, kdyz tu je plno lidi, co urcite v ruznych zarizenich
implementovaly protokoly vlastniho navrhu. Chce to jen dostatecne usili a
trebas vyjit z nejake zakladni myslenky, která se v nejakem existujicim
protokolu vyskytuje:).


// 
// 
// 
// P.S. Myslenka na upgrade fw pres komunikacni sbernici je lakava, ale
// priznam
// se , ze z toho mam tak trochu strach a nedovedu si to zcela predstavit.
// 
// 
[M.P.] 

Pro mne je nejen lakava, ale povazuji ji za zakladni kamen a pozadavek na
komunikacni protokol. Staci splnit jen par zakaldnich podminek.
1.Protokol resi zabezpeceni dat
2.Modul je sam o sobe vybaven univerzalni knihovnou pro sitovou komunikaci a
vypalovani dat
3.Modul bez uzivatelskeho softu musi umet vypalit kod(a to i pri chybe
vypalovani dat) s tim, ze na pametove misto s ulozenou knihovnou se nesaha.
4.Kazdy modul musi behem sve cinnosti v prenasenem protokolu ocekavat
pozadavek na ukonceni cinnosti vypalovani dat, coz je vlastne obsazeno v
bode druhem.

A musí to fungovat:)))


S pozdravem,
		Marek pavlu
---
avast! Antivirus: Odchozi zprava cista.
Virova databaze (VPS): 0519-1, 10/05/2005
Testovano: 12.5.2005 0:58:28
avast! (c) copyright 2000-2003 ALWIL Software.
http://www.avast.com