Zdravím pana Tišnovského a ostatní,
obecně si myslím, že je architektura MCS51 pro práci s oblastí datové paměti větší než internich 128 nebo 256 byte dosti nešťastná. AVR nebo MSP430 je mnohem lepší volba.
Přesto někdy díky rozšířenosti architektury a zajímavých integracích s periferiemi nezbývá než ji používat.
Již zde byl zmíněný kompilátor SDCC
http://sdcc.sourceforge.net/
Příští verze 3.0 již bude alespoň o trochu blíže podpože C99 včetně inline funkcí a podařilo se mi s ní při testování zkompilovat docela složitý kód.
Mírně kuriózním odkazem je následující počin Altos. Využívá integraci MCS51 a ZigBee pro obousměrnou komunikaci s amatérsky stavěnými raketami
http://www.altusmetrum.org/AltOS/
Zajímavostí je, že jedním z hlavních vývojářů je Keith Packard. Pokud vám to jméno nic neříká, tak připomenu, že se jedná o člověka, který opustil XFree86, byl u zakládání X.org a v současné době je jedním z důležitých architektů X u Intelu.
Pěkný přehled různých mikrokontrolérových kytů, které se používají k výuce na univerzitách po celém světě připravili kolegové na Katedře měření FEL.
http://neuron.feld.cvut.cz/wiki/Analyzy/Prehled_uloh_na_skolach
Pokud někdo má čas a chuť, tak by možná stálo zatřídit mnou uvedené odkazy tady na Rootovi na MCU.cz nebo někam jinam, kam to víc přísluší.
Mate pravdu v tom, ze MCS-51 ve chvili pripojeni externi ROM a predevsim RAM uz neni tak elegantni, protoze se uz narazi na limity v instrukcni sade a vlastne i limity osmibitove architektury (adresovani pouze pres @R0, @R1 a jediny 16bitovy registr DPTR). Podobnym problemem trpi i PICy, ale ty nikdo (?) nenasazuje jako skutecny mikroprocesor, je to proste jednoduchy a levny programovatelny logicky obvod. Naproti tomu MCS-51 se (hlavne z historickych duvodu) nekdy pouziva i tam, kde se jiz prekracuje hranice snadne pouzitelnosti.
O AVR jeste bude rec, tam to maji vyresene o dost lepe a hlavne tech 32 registru hodne pomaha prekladacum cecka (co si budeme povidat, v pripade PICu a MCS-51 se zadne zazraky prekladace nedaji ocekavat).
Tohle je sice zajimave cteni, ale pohravam si s myslenkou, ze by mi v baraku ohrev TUV kolektorem a vytapeni ridil mikrokontroler. Na hw jsem celkem levej, takze sice dokazu pochopit jak pripojit LCD, ale vic by me zajimalo, jak multiplexovat porty, aby CPU mohla cist z vice senzoru a ovladat vice periferii 9v podstate pumpa, el. topeni, mozna i svetlo).
Což o to, více portů není není až tak problém, slušnější MCU mají desítky logických I/O pinů a alespoň osmiportové multiplexované A/D převodíky. Horší je, že když to budete ovládat z jednoho místa, tak se do těch drátů zapletete. Proto je potřeba vymýšlet jak ta dnes již levná MCU rozumně propojovat. Buď bezdrátově – pro budovy třeba ZigBee, nebo s dráty – CAN, RS-485. I na to je projektů hromada. Třeba http://bacnet.sourceforge.net/ nebo námi vyvinutý uLAN http://ulan.sourceforge.net/ .
Nad uLANem již kompletní aplikace řízení topení a ventilace jeden tým z naší katedry postavil. Protokol a veškeré jeho části a implementace jsou od PiKRONu a Agrosoftu pod GPL a embedded část i pod MPL. Bohužel nadstavba a aplikace pro domácí automatizaci vytvořené za peníze financované z grantových projektů mají licenci komerční nebo nevyjasněnou. Ale základ je k dispozici, včetně pár jednoduchých aplikací – stahování rolet na MCS51, nějký ten vypínač světel, melodický zvonek, meteorologickou stanici http://smoliku.cz/meteo/ a další prvky. Kromě staré MCS51 je převážná většina v současné době realizovaných aplikací na ARMech od NXP (LPC2×xx a LPC17×x). Když zbyde někdy čas a nebo peníze, tak třeba připravíme i nějaký open-source návrh HW.
Jinak dost informací o tom zatím ne až tak otevřeném projektu domovní automatizace lze nézt v diplomových pracech, které jsou a musí být veřejně dostupné a i můžete zkusit kontaktovat autory a zjistit, za jakých podmínek se lze zapojit, návrhy použít nebo nějaké komponenty získat třeba výměnou za programování
http://support.dce.felk.cvut.cz/mediawiki/images/2/2f/Dp_2009_okrouhly_milos.pdf
http://support.dce.felk.cvut.cz/mediawiki/images/1/10/Dp_2008_carek_lukas.pdf
Tady je i odkazy na práce, které byly zcela otevřené i včetně kódu, který je ve veřejných repository
http://support.dce.felk.cvut.cz/mediawiki/images/1/15/Bp_2009_stefan_jan.pdf
Stejný základ návrhu HW je použitý i v v některých zařízeních používaných a publikovaných autorem http://www.pbmaster.org
Takže není problém se do takové věci pustit. Ale znamená to hodně toho nastudovat a dát tomu kus práce. Pouze chvilkový zápal opravdu nemá cenu. To je spíš vyhozený čas, protože jsou věci, které přináší výsledky až po určité počáteční investici a bohužel dobře připravený otevřený základní build k okamžitému požití až tak dobře připravený a především zdokumentovaný není.
I2C ani 1-wire jsou stavěné na propojování čipů na jedné desce, max v jednom zařízení. Fyzická vrstva (urovní TTL a nižší) je při uvažování rozdílů v napájení a indukovaném E+M rušení pro spoje nad 1 m zcela nevhodná. Jejich galvanické oddělení první z problémů řeší, ale je třeba v případě I2C dost komplikované. I2C nemá ani žádnou ochranu dat proti chybám.
Nevím, jak je to s I2C, ale tento borec si staví věci na 1-wire, ale nevím, jakým způsobem je má propojené s řídícím počítačem. Ale řekl bych, že je má na přímo.
http://marc.merlins.org/perso/linuxha/2010-08.html#Temperature_-moisture_-humidity_-and-UV-monitoring-and-graphing-with-1wire-devices_-owfs_-and-cacti
Není snad nic jednoduššího, než si o tom něco přečíst. Literatury existuje hromada, ať už v elektronické podobě nebo v papírové – např. BEN toho vydal spoustu.
Jinak rada od člověka, který navrhuje HW, pro nějž následně píše SW – návrh HW je rozhodně složitější, než SW. Nechci tím nikoho odrazovat, spíše jen upozornit.
Pokud se do SW pocita uplne vsechno (obsluha displeje, vstupu, vystupu a k tomu nejaky komunikacni protokol), tak si myslim, ze oboji musi byt pekne tezke. Pro nas jednodussi potom nezbyva nic jineho, nez si koupit hotovou „plechovku“ (PLC) a do ni doprogramovat uz jenom samotnou „mereni a regulaci“.
Dobry den, pokud uz mate vyhlidnuta vsechna cidla a ovladaci prvky, tak z nich se da odvodit, jak vsechno zapojit. Muzete sem prosim vypsat jejich typy? Nebo aspon „schema“ co vsechno se ma ovladat, tj. kde jsou pumpy, ventily atd.
Multiplexovani portu neni az takovy problem, napriklad je mozno prepinat 16 vstupu na 4+1 pinech mikroradice (predpokladem je, ze ta cidla prenasi data seriove a relativne pomalu). Pokud se cela aplikace vleze do interni ROM mikroradice (a to by v tomto pripade mela), tak mate volnych 32 pinu ovladatelnych bit po bitu, popr. USART nebo SPI (ten implementovany v SW).
… www.microvga.com ? Mozna jednodussi na interfacovani nez LCD 2×16
Musím dát link na jeden krásný tuzemský majstrštyk.
http://www.zajic.cz/tvstupni/tvstupni.htm