Názory k článku Hardware inteligentního internetového termostatu
-
Ray (neregistrovaný)
Zdar a silu, nesledoval jsem cely serial, tak pokud uz to nekdo psal, tak se omlouvam (: Pokud by si toto nekdo chtel postavit v realnem prostredi, bylo by prinejmensim vhodne chranit si datovej pin 1wire transilem, ci jeste lepejinak. Samotnej transil stoji nekolik kc... Obecne jsou single terminated a jeste k tomu open colector sbernice dost nechutne nachylne na ruseni... Cim vyssi odpor k VCC tim horsi... A s tim souvisi prave ochrana pred ESD a jinou haveti, zejmena z blesku, ktery muze svihnout klidne nejakou tu stovku metru daleko a presto naindukvoane napeti muze spolehlive znicit pripojeny cidla. Nekdy staci i dostatecne silnej VF zdroj v akuratni vzdalenosti/smeru... 1wire se da spolehlive polozit i soubehem se silovinou a EMI radiacnim spotrebicem, pripadne zapinanim peknyho audio zesiku s 10ti kilovym toroidem (: Jak kde, jsou mista, kde se to nestane za 10 let a mista, kde to bude kazdou druhou bourku. Stejne tak, jako bezne odchazi ETH traficka... Pokud by to melo byt nekde resene robusne, urcite by stalo za uvahu dat ke kazdemu cidlu radic nebo miniaturni MCU a honit to po nejake prumyslove sbernici, treba 485petce. Je to sice 1-2 cm2 tistacku a 2 tolarky navic, nicmene, z dlouhodobejsiho hlediska by se to rozhodne vyplatilo :) Kdo zazil, co udela blesk, co svihne o par baraku vedle jen vzduchem, vi o cem mluvim. Tahat 1wire po destikach metru po baraku muze fungovat bezproblemove, pravda. Problem je jen v tom, ze muze :) Aneb nevedomost je sladka :) (mysleno ve smyslu praktickych dopadu)
R.
-
Petr StehlíkZlatý podporovatelRayi, v minulém díle o stavbě sítě čidel jsem napsal "na oba konce sběrnice dejte transil".
Je pravda, že jsem v tomto díle neuveřejnil fotografii plošného spoje ze spodní strany, kde jsou ty transily vidět, a zároveň jsem je nepopsal do textu. Takže máte pravdu, a já tam ty transily mám.
A samozřejmě je tam všem čtenářům doporučuji dát také.
-
Peter (neregistrovaný)
Pokial chcete komunikaciu na 1-wire poriadne domrsit, transil je nejlepsie riesenie. Ma velmi velku kapacitu prechodu a pokial zbernicu budite z nejakeho mizernejsieho zdroja (pin procesoru a pod.), radikalne sa skrati pouzitelna kabla, osciloskop ten zazrak ukaze ... Pre ochranu pred prepetim treba pouzit poriadny skruteny dvojvodicovy kabel (minimum volnej plochy pre indukovanie rusivych napeti z vonkajsich mag. poli) s chakteristickou impedanciou 110...120 Ohm, elektrostaticke polia linku neohrozuju. Kvalita kabla sa pozna jednoducho, na konce kabla sa pripoji ukoncovaci rezistor o hodnote charakteristickej impedancie kabla Z=sqrt(L/C) a pripoji sa na osciloskop, podla urovne bordelu na obrazovke sa da usudit na jeho vhodnost.
Pokial trvate na pouziti transilu, treba ho od linky oddelit rychlou impulznou diodou (schottky) s malou kapacitou (transil voci zemi, katoda diody spojena s katodou transilu). -
Petr StehlíkZlatý podporovatel
A zachová se ještě funkčnost toho transilu? Nebo se jako první "pokazí" dioda a tím odpojený transil přestane chránit?
-
peter (neregistrovaný)
Spickovy impulzny prud aj pomerne mizernych spinacich / rychlych diod IFSM (jednorazovka a dost) je pomerne znacny - jednotky az desiatky Amp (pri schottky menej), takze dioda toho znesie relativne dost - pre rusivy prud je zapojena v priepustnom smere. Transil svojou velkou kapacitou pre rusivy impulz funguje ako kondenzator s paralelne pripojenou (mizernou) zenerkou. V kazdom pripade, ak by sa na 1-wire objavil rusivy impulz s dobou trvania pod 1usec, ktory by odpalil takuto spinaciu diodu, uz budu davno mrtve vsetky senzory na linke (Ucc max = 6V). Ako som napisal, najlepsou ochranou je zabranit vzniku indukovanych rusivych napeti (kable, topologia, zemnenie, tienenie...), hlusenie transilmi, antiparalelnymi diodami a pod. je uz druhy level.
-
Ray (neregistrovaný)
Transil a velkou kapacitu ? Jak se to vezme.... Naprosto obycejnej transil se pohybuje pod 1nf, obvykle nekde na urovni par stovek pf (alespon ty co bezne pozuivam, nejlevnejsi co se daj koupit). A to se nebavim o lepsich typech. Na frekvence na sbernici 1wire, pri pullupu 1.5K se da lehce spocitat maximalni kapacita vedeni, aby to bezelo. Dokonce je ve specifikacich 1nf ohledne sbernice. Krom toho, existuje cela rada dalsich moznosti, lepcich, kdyz je na 1 draty X cidel, kde by to pak uz mohlo pusobit problem. Namatkou tyristory (SIDACy), ktery maj kapacitu nekde mezi 20-50pF, verze pro rychle sbernice jeste min...
R.
-
Yenya (neregistrovaný)
Jak je tohle vážné, pokud jde o instalaci uvnitř budovy? Jak velký náboj je potřeba tím transilem typicky odvést?
Jakože třeba ATtiny má na pinech ochrannou diodu směrem k Vcc, takže při přivedení napětí většího než Vcc na pin se otevře a nějaké malé desítky mA odvede tam. Pokud neřeším blesk (uvnitř železobetonového skeletu to myslím fakt nemá cenu), tak by naindukovaný náboj který by bylo třeba odvést neměl být nijak velký, i kdybych měl souběh se silovým vedením nebo se vedle spínal nějaký motor nebo jiná cívka.
Jak to je?
-
Petr M (neregistrovaný)
Uvnitř budovy? To je irelevantní. Na ochranu proti blesku platí ČSN EN 62305. Ta dělí budovu do zón.
LPZ (Lightning Protection Zone) 0 je venku. LPZ0a je imo dosah hromosvodu, LPZ0b v ochranným prostoru hromosvodu.
LPZ1 je uvnitř budovy, obecně.
LPZ2 jsou speciální prostory uvnitř (rack, serverovna, laboratoř,...)
LPZ3 by byl rack uvnitř serverovny v LPZ3, pokud dává smysl ho dodatečně chránit
A takhle se definují další a další vnořený zóny uvnitř budovby, kde to má smysl. Ochrana se instaluje na hranici zóny. Při vedení LPZ0-LPZ1 musí být podle ČSN EN 33 2000-4-41 vždy.Další věc je rušení, kde je několik pastí. Vydalo by to na celou knížku, ale obecně je potřeba vědět, jak a od čeho se rušení do systému dostává a řešit to klasicky, nebo udělat EMC zkoušky podle norem. 1-wire čidlo nevyhoví, takže odrušovat individuálně...
Splnění ČSN EN 33 2000-5 pro požadavky na kabel (průřez, izolační odpor, zkušební napětí) a jeho vedení (uchycení, mechanická ochrana, souběhy) jsou snad základ a samozřejmost...
-
Petr M (neregistrovaný)
Ještě k diodám v AtTiny. Tyhle diody má každý CMOS. Viz moje poznámka k JTAGSEL u AT91SAM9260 a AT91SAM9261. Pokud je v datasheetu "Vdd+0,5V", víc se tam nepouští.
Proud závisí na ploše PN přechodu, protože je tam limitace počtem paralelně cestujících majoritních nosičů. Při hustotě integrace na procáku bych nad pár uA neriskoval. Procák funguje na principu stlačenýho dýmu. Jak dým uteče, je po něm.
Pozor, klasická dioda je pomalá, rychlý jevy jako výboje nedá a prorazí se hradla u vstupních MOSFETů. A pokud už tam něco vletí, musí se to vhodně "protopit" - třeba lapnout do kondíku a propálit na LEDce napájení. Pokud by to byly jenom CMOSy za step-up měničem nebo nábojovou pumpou, sesmažíš je.
-
Yenya (neregistrovaný)
No a otázka je, jestli tam vůbec může něco "rychle vletět". Samozřejmě věci typu připojování nového vedení při instalaci nepočítám. Jde o to, jestli ty transily jsou potřeba u vedení v rámci jedné místnosti uvnitř ŽB skeletu, když jde o vedení délky malých desítek m mezi piny MCU a nějakým vzdáleným čidlem.
Může reálně třeba sepnutí motoru výtahu poblíž signálového vedení naindukovat v tom vedení něco, co by ta dioda neodvedla?
-
Petr StehlíkZlatý podporovatel
trokare, dobrá poznámka - přesně z toho důvodu mám v termostatu Arduino v objímce a v šuplíku další čtyři kusy :-)
Jinak jsem nechtěl nikoho vyděsit - i proto tu není schéma, ale jen lidský popis, kterou nožku spojit s kterou další nožkou. Ten základ je velmi jednoduchý, a navíc jsou na internetu haldy návodů právě díky tomu, že je to na Arduinu. Nebát se a nekrást!
-
Petr M (neregistrovaný)
Dobře. Kontrolní otázka.
10. ledna odjedu na dva týdny hory. 12. ledna přijde kalamita, která strhne vedení VN k trafostanici. Při zapnutí tradfa po opravě vznikne přechodový jev, který sejme Arduino. Otázka zní: Stihnu vyndat ze šupléku Arduino dřív, než zamrznou a popraskají radiátory, když průměrná teplota venku bude -10°C?
Arduino vem čert, to je pár korun. Pět radiátorů po 2500, rozmočený koberce a zničená plovoučka jsou přece taky levnější, než pořádně ochránit jednu sběrnici... A případný "odskok" z 200km vzdálené destinace se taky dá zvládnout zadarmo a za pět minut.
A o platnosti Murphyho zákonů tady snad nikdo nepochybuje.
-
Petr StehlíkZlatý podporovatel
Petře M, jste opravdu dobrý v něčem, co by někteří útlocitní mohli nazvat rýpáním, ale chybí vám konkrétní návrhy řešení. Jen v tomto maličkém podvláknu jste nejméně čtyřikrát zdůraznil, že transil nestačí. Jak jsem vás včera vyzýval k publikační činnosti, tak ta by právě měla obsahovat spíš konkrétní řešení než kontrolní otázky.
Zkuste proto prosím přesně popsat návrh ochrany na hranici zón u 1-Wire sběrnice. Čtenáři to uvítají. A já zatím nebudu jezdit na hory, dokud se to nevyřeší lépe než transilem (který navíc, podle jiného zkušeného čtenáře, ničí kapacitní poměry na sběrnici, takže bych ho měl stejně předělat či zahodit).
-
Petr M (neregistrovaný)
Velice hezký je třeba to řešení, co máte na venkovním čidle. Kdybych to takhle udělal na baráku, kde je střecha 10m vysoko a v místě křížení je okap spojený s hromosvodem, na baráku čtyři svody, stane se při úderu 100kA blesku zhruba tohle:
- Proud se rozdělí do čtyř svodů. Předpokládejme, že rovnoměrně. Do každýho vletí 25kA.
- Předpokládejme svody s impedancí 10Ohm/m. Od připojení okapu k zemi 10m, takže impedance svodu 100mOhm. Na svodu v místě připojení okapu je 2,5kV, na stejným potenciálu je svod okapu.
- Deklarovaný provozní napětí UTP je 350V, pro blesk to není problém. Vletí do obou žil současně, transil nemá co řešit.
- Termostat se dostane na napětí 2,5kV proti zemi. Prorazí se zdroj (asi to nejede z baterek) a po průrazu klesne odpor sběrnice proti zemi třeba na 10 ohmů.
- Touto cestou se vydá 1% proudu toho svodu, tzn, 250A (proudový dělič). Transil v termostatu se pokusí spojit žíly, aby těch 125A nešlo do GPIO pinu. Při tomto prvním a posledním hrdinským činu se odpaří i s chráněnám procesorem.
- Prakticky okamžitě se odpaří měď v těch UTP s tím, že začne hořet izolace a zapálí třeba nábytek, záclony,...
- Pokud by někdo v té době držel kabel od sběrnice v ruce, tak se blesk vykašle na prorážení zdroje. Zkrátí si to skrz izolaci kabelu a dobrovolníka třeba do armatury betonové podlahy. Pokud bude jeho impedance po průrazu řekněme 5kOhmů proti zemi, U^2/Z = 1,25kW. Upeče se zevnitř. Naštěstí nestihne moc trpět, je to hodně rychlý.Konkrétní návrh ochran hodně závisí na místních podmínkách a na instalaci. Je tam potřeba si zodpovědět hodně otázek a v diskusi (no, vlastně ani v článku) by na to nebyl prostor.
Můžu vás ale odkázat na stránky o ochtaně před bleskem. http://www.kniska.eu/ Vymyslel je soudní znalec v oboru ochrany před bleskem a přepětím. Dá se tam najít i SW pro aanlýzu rizik, vysvětlení jak blesky chytata a jak zemnit,.. Myslím, že tamní informace budou relevantnější a komplexnější, než bych mohl napssat sem.
Ty stránky by si měl ve vlastním zájmu přečíst každý, kdo nějak manipuluje s kabeláží z venku dovnitř. Hlavně ti idioti, co omotají UTP kolem svodu hromosvodu, dají AP na jímač, mají anténní stožáry vyšší než hromosvod a dělají podobný zvěrstva, by je měli mít povinný a po jejich prostudování test, v případě neúspěchu zakončený kopancem do rozkroku.
-
Petr StehlíkZlatý podporovatel
Trvám na tom, abyste začal publikovat! Budeme tomu říkat technická beletrie, něco jako scifi, ale bez fi. Máte nesporný talent, dalo by se říct básnické střevo.
Na domě mám jen jeden svod, takže kA nemusíme dělit čtyřmi.
Mám díky vám už docela jasnou představu, jak 1-Wire sběrnici před bleskem ochránit správně, ale už to do příštího článku o SW asi nebudu dávat. Třeba někdy příště.
-
Hany (neregistrovaný)
Zdravím,
díky za zajímavé články. Jestli bude na rootu více věcí na podobné téma, určitě to uvítá hodně lidí.
Ochrana busu je zásadní a rád bych znal jednoduché a správné řešení. Nebuďte prosím jako zde hodně mluvící ale málo sdělující zamindrákovaný inženýr a nastiňte jak byste 1-Wire bus chránil?
Napadla mě jednoduchá tranzistorová ochrana, viz: http://pandatron.cz/?797&jednoduche_prepetove_ochrany
-
karel (neregistrovaný)
No ja ani ne,
opravdu by se to hodilo nekam napsat, mam taktez nekolik cidel na strechu a docela se bojim, po precteni diskuze, zas na druhou stranu, mam na strese kolektory a tam je teplomer a drat vede podel trubek primo az do ridici jednotky a je to tak od certifikovane firmi tak nevim.klidne pod navaod jak to udelat spravne napsat na vlastni nebezpeci protoze nic na 100% nefunguje
net je plnej navodu na arduino i picko ktere pri delsim zapojeni akorat dotycne upecou, tak kdyby se nekomu chtelo tento trend zvratit nejsem proti.
-
Petr M (neregistrovaný)
Jenomže ono to není tak jednoduchý. Existuje hned několik věcí, na který si je potřeba u kabelu dávat pozor:
1) Nadproudy a zkraty
2) Zemní smyčky
3) Unikající proud
4) Potenciálový rozdíl mezi žílama
5) Elektrický pole
6) Kapacitní vazba
7) Indukční vazba
8) Vyrovnání potenciálu
9) ESD
10) Přechodový jevyA každý se řeší jinak, navíc se liší i podmínky. Navíc vyřešení jednoho bodu zhorší odolnost jinde, něco z rtoho někde nemusí vůbec vadit (ESD u 230V), jinde to samý může být smrtelný...
Transil v tomhle případě pomůže na 4 (omezeně), 9 a 10 (částečně), zbytek neřeší.
-
Yenya (neregistrovaný)
Tak nevím, nepletou se vám někde Ohmy a miliOhmy?
Izolace dnešních UTP by hořet neměla, většina kabelů se dělá jako bezhalogenové samozhášivé. Maximálně někam skápne plast o teplotě nějakých 300 °C, což asi ani nic nezapálí. Myslím že zhruba od této části dál je ten text už v oblasti sci-fi.
Nebo možná i dřív - Wikipedia si myslí, že typický blesk má 30 kA, 15 C náboje a 500 MJ energie. Trvá řádově desítky mikrosekund (maximální fáze) a doznívá stovky mikrosekund už o řádově nižších proudech. Na druhou stranu odpor lidského těla při výboji je údajně jen 500 Ohmů, ne těch 5k.
Odpaří-li se měď, kudy půjde těch 250 A do toho člověka?
======
A teď já:Podíval jsem se do dokumentace, jak máme dělaný hromosvod na baráku: je to AlMgSi o průměru 8 mm. Dohledal jsem, že měrný odpor AlMgSi je 29 nOhm.m:
http://elektrika.cz/data/clanky/wkkpmuh040907
10 m takového vodiče bude mít odpor 5.8 mOhm, jestli dobře počítám. My teda takových vodičů kolem domu máme patnáct, ale počítejme ty čtyři. 7.5 kA na tomto vodiči udělá 43.5 V, což sice může leccos spálit nadproudem, ale výbojem to moc daleko nepřeskočí. Navíc pokud by se toho drátu na druhém konci držel člověk, tak nebude tvrdě připojený k potenciálu země. No ale i kdyby byl uzemněný natvrdo a dostalo se do něho 1 % výboje, tedy 75 A na 43.5 V po dobu řekněme 100 mikrosekund, je to energie 0.33 J. Smrtelná dávka elektrického šoku je podle tohoto odhadována na cca 4 kJ (ale nepochybně bude záviset i na napětí a proudu, nejen na energii):
https://books.google.com/books?isbn=052187811X
Co jsem přehlédl?
-
Petr M (neregistrovaný)
Samozhášivý neznamená nehořlavý... A už jsem viděl UTP kabel, jak pěkně zapálil dřevo.
Měď se odpaří při nárůstu teploty. Teplota naroste v důsledku toho, že napřed proteče proud. Takže průchod proudu se roztavením nevylučuje, naopak. Průchod proudu je podmínkou toho tavení.
A přehlídnutí bylo ohledně toho, že se jedná o přechodový jev. Nedá se počítat jenom s činným odporem, ale beton se chová jako vodič (polarizační jevy), v drátech nastane skin efekt a uplatní se i jejich indukčnost. Ještě nějaký dotaz?
-
Yenya (neregistrovaný)
No dobře: skin efekt; impedance; přechodový jev. Člověk se furt něco učí. Jedeme dál:
Budeme věřit, že ten můj hromosvod má tu vaši impedanci 100 mOhm. Jaké frekvenci to asi odpovídá?
http://chemandy.com/calculators/round-wire-impedance-calculator.htm
Když tam dosadím 10000 mm, hliník a 8 mm průměr dostávám Z=100 mOhm u frekvence 600 kHz. Což si vykládám tak, že ten přechodový jev lze aproximovat sinusovkou o této frekvenci. Tedy náběh do maximálního napětí trvá řádově jednu čtvrtvlnu této frekvence, a náběh do maximálního proudu (a odpovídající pokles napětí) druhou čtvrtvlnu. V tu dobu už se ale napětí nemění, takže takže drát se během té druhé čtvrtvlny přiblíží zpět svému stejnosměrnému odporu. Můj odhad tedy je, že na konci první čtvrtvlny bude v místě toho senzoru napětí těch vašich 2.5 kV (asi méně - vy počítáte s 25 kA, já se 7.5 kA), a na konci druhé čtvrtvlny bude těch mých 43.5 V. Řekněme tedy, že vaše napětí bude působit v průměru po dobu jedné čtvrtvlny, nějakých 0.4 mikrosekund.
Je otázka, jestli během této doby si stihne blesk prorazit všechny vzduchové a jiné izolované mezery (přes izolaci UTP, přes kůži člověka, přes tu betonovou podlahu), a jestli způsobí nějakou škodu. Nejdřív ta rychlost: Podle tohoto videa blesk vyrobí ionizovaný kanál až k zemi za nějakou čtvrtsekundu:
https://www.youtube.com/watch?v=CfYiFSTkBWk
Pokud pro jednoduchost předpokládám, že mraky jsou ve výšce 250 m, je to rychlost 1 km/s, tedy 0.4 mm za těch 0.4 mikrosekundy. To je podle mě na proražení izloace UTP kabelu a ještě jednotlivého vodiče málo (drze předpokládám, že rychlost průrazu bude stejná jako ve vzduchu).
A teď ta škoda: Pokud by člověk už měl proraženou kůži a dostal těch 2.5 kV do těla o odporu 500 Ohmů, procházel by jím proud 5 A a výkon 12.5 kW. Po dobu 0.4 mikrosekundy, ovšem. Čili do člověka by se uložila energie 0.005 J. Proud by sice na tu dobu překročil fibrilační hranici 120 mA, ale pochybuju, že by reálně k nějaké fibrilaci došlo. A ke škodě na nervové soustavě téměř jistě ne.
Navíc pokud přechodový jev na hromosvodu samotném, tak přechodové jevy na sousedních izolovaných objektech budou taky, a možná ještě ve větší míře.
Co jsem zanedbal tentokrát?
A ještě jedna věc: já tady píšu proto, abych se o tom něco dozvěděl. Takže bych chtěl požádat, abyste případně svá tvrzení poněkud víc rozepsal. Je nakonec možné, že to nejde počítat ani tak jak to mám já, ani tak jak to máte vy. Například tam nikde nefiguruje těch 100 MV napětí mezi mrakem a zemí.
-
Petr M (neregistrovaný)
No pochopitelně může. Armování betonu je sice Faradayova klec, ale pomůže spíš s elektrostatickým výbojem, pokud je pro něho kratší cesta z povrchu do armatury, než do vnitřního prostoru. A tam je ještě podmínka dobře provařené a uzemněné konstrukce.
Na magnetický pole velké intenzity moc nepoumůže, je to přece jenom feromagnetikum. Pohltí sice nějakou energii při magnetování, ale zůstanou oblasti s nějakým remanentním magnetismem, takže tam bych ochraně před magnetickým polem moc nevěřil.
Navíc armování má oka třeba 10cm. A rádiový frekvence vlnovou délku od km po mm. Něco zadrží, u něčeho se koná difrakce a něco bez problémů projde... Třeba z mobilu se dá volat i v paneláku, že? A do toho železobetonovýho kvádru nevedou z venku žádný kabely, že?
Navíc se tím neeliminují zdroje rušení vevnitř té konstrukce.
A co se zdrojů rušení týká, tam je několik mechanismů vzniku rušení. Každý se chová jinak a každý se eliminuje jinak. Diody v procesoru nestačí, pokud se neomezí proud tak, aby to s rezervou pokrylo worst case. Ale to pak zvedne impedanci a vyžaduje přizpůsobení impedance vedení. To pak rozhodí úrovně signálů... Je to duchařina a hodně tvrdě zaplacený know how.
I ten transil už považuju jenom za symbolickou hromničku. Nezachrání prakticky nic, pokud člověk neví kdy, proč, kam a jaký typ nasadit..
-
hofikhof (neregistrovaný)
Dobrý den,
Před nedávnem jsem si pořídil microserver od HP, kde mám Windows server 2012 s virtualizací. Na Windows používám program LogTemp pro 1wire zaznaménávání celkem 12 čidel v domě pomocí redukce z RS232 (několik odporů, diod... jednoduchý a funkční bez problémů).
Dále na viurtuálu je linux server pro 2 kamery a linux server pro DLNA úložiště.
Nastala otázka spotřeby... server má cca 50W. Napadlo mě to řešit pomocí Raspberry, k čemuž by šlo asi připojit čidla, nainstalovat DLNA a nějaké samba úložiště s externím diskem (mám 2x 1.5TB RAID1).
Je nějak tato kombinace schůdná i výkonově pro Raspberry, nebo raději Ardinuo?
Prosím o pomoc. Opravdu se v těchto mini zařízeních nevyznám. Všude je spousty návodů, postupů, ale srovnání nic moc pro mé potřeby...Moc děkuji a přeji hezký den.
-
Petr StehlíkZlatý podporovatel
Raspberry Pi je pro DS18B20 "kanón na vrabce". Naopak nebude vůbec dobrý pro RAID kvůli absenci diskového rozhraní a slabé síti.
Osobně bych to řešil novým serverem (klidně ARM, anebo ty nové Buldozery od AMD) se spotřebou do 10 W. Určitě nenapájet přes ATX zdroj, tím se dá taky hodně ušetřit.
Sám mám doma Atom, který bere kolem 15 W, a výhledově ho chci nahradit něčím ještě menším, ale rozhodně s on-board SATA a gigabitovou síťovkou, což Raspberry Pi nesplňuje ani jedno.
-
hm (neregistrovaný)
Článek je rozhodně podnětný a díky za něj, ale měl bych poznámku k topologii sítě čidel.
Topologii LINE nelze s čidly vytvořit. Předpokládám, že autor měl na mysli sběrnici, kde ale odbočky k jednotlivým čidlům jsou tak dlouhé, jak dlouhé jsou nožičky integrovaných obvodů. Pokud bychom chtěli vytvořit topologii LINE, musela by mít všechna čidla (kromě krajních) dvě 1-wire rozhraní a veškerý provoz, který se jich netýká, přeposílat z jednoho rozhraní na druhé. S 1-wire mám sice zkušenost pouze s jedním čidlem na sběrnici, ale topologii LINE podle mě vytvořit nelze, vždy to bude BUS, podobně jako se běžně používá RS485 nebo CAN. Není to, samozřejmě, zásadní, ale je to matoucí zejména pro ty, kteří by chtěli pochopit jednotlivé topologie.
-
Petr StehlíkZlatý podporovatel
Ano, je to přesně tak - mám nožičky čidel napájené přímo na drátech sběrnice, takže odbočky jsou prakticky nulové délky, což mi připomínalo spíš Line než Bus. Nechtěl jsem čtenáře ještě jednou zmást, omlouvám se.
-
Lukáš Doktor (neregistrovaný)
Zdravím, bylo by fajn, pokud by jste mohl doplnit schéma. Neměl by být problém udělat ho ve Fritzingu či Eaglu. Nutné to není, schéma jste popsal a navíc lidé nejspíš použijí vlasní modifikace. Ale myslím, že by se to hodilo, ideálně i se zdrojákem, aby to nemusel kreslit každý od nuly.
S Pozdravem, Lukáš
-
Petr StehlíkZlatý podporovatel
Fritzing je nepřehledný zmatek a Eagle jako nefree soft nepodporuji. Mohl bych to nakreslit v KiCadu, ale pokud čtenáři vypustí ten převodník CD4050, domníval jsem se, že schéma je téměř zbytečné, protože se jen propojuje CS na CS, D/C na D/C, MOSI na MOSI, MISO na MISO atd.
-
Yenya (neregistrovaný)
Já bych AVR až tak nezatracoval. Na rozdíl od "velkých" ARMů s Linuxem to má výhodu, že celé MCU je fakt do posledního taktu a do posledního registru dokumentované. Další výhoda je, že procesor jde uspat do režimu, kdy má odběr pod 1 mikroampér. Takže třeba u kontroleru LED světel na kolo jsem nemusel řešit žádný vysokoproudý vypínač, ale prostě jsem uvedl všechny věci do klidu a pak uspal MCU. Takhle v tom můžou zůstat baterky třeba rok a vydrží to.
Tuhle výhodu ovšem mají jen "holé" AVR, ne Arduino, kde na desce je spousta
obtížně vypnutelných věcí - předimenzovaný regulátor napětí, FTDI čip, LEDky, atd.Ještě tak kdyby se dělala "univerzální" deska typu Arduino, která by měla regulátor napájitelný z 24V a MAX485 místo USB/FTDI.
No ale pokud už by člověk chtěl komunikovat přes IP, tak AVR už nestačí. Co za desku s ARMem byste použili? Beagleboard?
-Yenya, http://www.fi.muni.cz/~kas/blog/
-
Petr StehlíkZlatý podporovatel
Yenyo, četl jste ten článek? Vždyť tam komunikuji přes IP, a AVR na to stačí.
A mnou použité Arduino na sobě má jen jednu LEDku, která se dá vyloupnout páječkou (někteří to dokonce dělají šroubovákem :-). Takže obě výtky mi přijdou dosti liché.Jinak vřele souhlasím s tím, že AVR je dobře zdokumentované a v tom termostatu mi nedělá nic jiného, než co mu řeknu - a to mě uklidňuje.
-
Petr M (neregistrovaný)
Jako člověk, který se 10 let živí vývojem na jednočipech prakticky všech výrobců sa pěti letech technické podpory pro distributora, který měl Atmel v sortimentu, musím konstatovat, že AVR ve srovnání s ARM není dobře dokumentovaný.
Ale je pozitivní, že čipy od Atmelu (bez ohledu na to, jestli 8051, AVR nebo ARM) obsahují spoustu překvapení a člověk se s nima nenudí... Jenom to nepotěší, pokud potřebuje zaplatit hypotéku a místo vypisování faktury řeší, proč se nedaří zápis do EEPROM, proč po připojení emulátoru shoří procesor, proč to ten externí watchdog nedokáže zresetovat, proč z A/D převodníku lezou hausnumera... :(
-
Yenya (neregistrovaný)
Tak jasně, YMMV. To co jsem psal je moje osobní zkušenost - pokud jsem někdy potřeboval něco najít v datasheetu, tak to tam bylo, a procesor se přesně podle toho choval. A v zásadě se choval docela rozumně i tam, kde zapojení bylo s datasheetem v mírném rozporu (ADC na signálu s vysokofrekvenční složkou bez předřazeného low-pass filtru). Ale je pravda, že emulátor nepoužívám, a watchdog jen interní.
-
Petr M (neregistrovaný)
Není. Ani náhodou. Chybí tam docela podstatný informace
- ATXMEGA, D-čková řada, neuvedena tolerance interní bandgap reference. Naplánuj výrobu několika tisíc kusů týdně, když nevíš, s jakýma tolerancema počítat na produkčním testeru. A i u dalších parametrů platí, že uvedení nominální hodnoty nestačí.
- Zařízení se zálohováním baterkou CR2032, v době zálohy se probudí jednou za 2s, změčí hodnotu, uloží do RAM. V datasheetu 2,8uA, realita 67uA, měřeno na pěti kusech. Proud nakonec závisel na nastavení fuses, ale v dokumentaci (ani v datasheetu, ai v erratě) ani slovo. Týden práce na projektu kvůli jejich lemplovině.
- AT91SAM9260, pin JTAGSEL. Ten přepíná mezi laděním jádra a boundary scanem. Podle datasheetu s interním pull-downem, přepíná se tvrdým připojením na VddIO (+3,3V). V reálu byla vnitřní clampovací dioda na VddCore... Následek? Po přepnutí se odpařila část čipu...
- Opět ATXMEGA, první řady. Zrušili EEPROM, zavedli NVM Controller, který má v sobě FLASH, FLASH využitelnou jako EEPROM, bootloader FLASH, Lock-bity, fuses, signaturu,... Deklarovali to tak, že z pohledu SW není změna proti EEPROM. Faktycky, mazání po blocích a pokud byl jakýkoliv přístup k NVM během zápisu (včetně čtení instrukcí), zápis zfailoval. Teď už to aspoň zadokumentovali.Mám pokračovat?
-
Petr M (neregistrovaný)
Tam většinou býbají problémy v analogobé části.
Nestabilita a nedefinovaná přesnost interních oscilátorů, lítá brownout, časování watchdogu nic moc. Brownout má tak velký odběr, že se při napájení z baterek vyplatí ho vypnout a připojit externího brouka.
U prvních řad občas nefungoval RESET pin nebo oscilátory.
U periferek namátkově třeba... ATMEGA329, LCD řadič při pádu napájení nechá jeden COM aktivní a při pomalým poklesu napájení nechá na připojených segmentech DC klidně na několik sekund (riziko zničení skla).
-
Yenya (neregistrovaný)
No, četl. Ale to přece není komunikace přes IP z toho AVR samotného - ten IP stack tam dělá procesor na tom ethernetovém shieldu, ne? Každopádně to není na úrovni, že bych si na AVR dělal HTTP server nebo si implementoval svoje výmysly typu SNMP trapy, MODBUS/TCP, BACnet nebo nějaký jiný podobný protokol aplikační vrstvy.
-Yenya
-
Som silne toho nazoru, ze sietove servery, potazmo TCP na zariadenie takehoto druhu proste nepatri. Budto je tam IP preto, ze som lenivy a chcem pouzit na pristup TCP a potom bude implementacia vzhladom k obmedzeniam bud nachylna na vsetky DoS utoky voci HTTP serverom publikovane za celu jeho existenciu, alebo bude extremne bloated. Alternativne mozem so zariadenim komunikovat cez nejaky custom protokol nad UDP a tam uz nevidim vobec ziaden benefit proti pouzitiu napr. RS485.
O tom, ze na real-time regulacnych zariadeniach by ad-hoc sa chovajuce veci v podstate nemaju co hladat sa nejdem rozpisovat. Jedna vec je ak barak vymrzne pre vypadok prudu, druha ak sa veci pokaslu skrz zacyklenie v kode HTTP servera, ktoremu sa trebars velmi nebude pacit request z nejakeho malfunctioning zariadenia v sieti.
-
Yenya (neregistrovaný)
Obecně máte pravdu, ono dost záleží, co to je za zařízení. Třeba je to někde kde máte strukturku, máte switche, ale tahat někam zvlášť RS485 se nevyplatí. Třeba to nemusí být pro zařízení které něco reguluje a má tvrdé požadavky na spolehlivost. Důvodů může být spousta.
Já jsem ten dotaz pokládal hlavně proto, že mám několik nápadů na drobné bastlení, které jsou ale pro malé MCU nepříjemné v tom, že pro dané místo a daný účel by rozumná komunikace byla nad TCP/IP (nějaké SNMP nebo tak něco). Určitě se nechci hádat o tom, že řízení topení v baráku je rozumné dělat na AVR se softwarově implementovaným IP stackem.
-
Petr M (neregistrovaný)
O nutnosti TCP/IP u termostatu taky dost pochybuju.
Pokud jde o domácí automatizaci tak osobně bych viděl priority takto:
1) Bezpečnost, protože zdraví a život jsou k nezaplacení, těžko se vraci a nemocenská po úraze nebo odškodný příbuzným je dražší, než neregulovaný topení..
2) Spolehlivost, protože co je po systému, který je autodestruktivní (třeba zapálením hořáku kondenzáku při vypnutým čerpadle)
3) Komfort, protže bez něho by nebyl potřeba regulovaný HVAC systém a celý by to ztratilo smysl.
4) Úspory, protože to je důvod pořízení automatizace.
5) Ergonomie, aby i každý uživatel,který z toho má rozum, dokázal nastavit komfortní teplotu, vlhkost,...Nějaký logování venkovní teploty, komunikace po TCP/IP, vestavěný budík, integrovaný rádio, vodotrysk na horním krytu atd. jsou už jenom jako bonus. A dá se řešit někde připojeným black boxem, který sleduje traffic na sběrnici a v případě potřeby předá termostatu v hostovským pokoji vzkaz, že se blíží návštěva. Tam stačí krabka třeba se starým AT91SAM7X256 + KSZ8801 + SN65HVD1050 + 25Cxx + TSP51040. Dá se to odpojovat/připojovat i za běhu bez ovlivnění systému (jediná chyba je, že to ještě nemám zbastlený, furt na to není čas)...
-
SB (neregistrovaný)
Čip W5100 umožňuje pracovat pouze(?) s TCP/IPv4, pro implementaci nižších vrstev je na hovno. Čip ENC28J60 by měl zvládat surové ethernetové rámce, proto v něm jde implementovat např. IPv6.
-
Trident (neregistrovaný)
Are you sure?
http://forum.arduino.cc/index.php?topic=74547.0 -
Petr M (neregistrovaný)
Malý ARMy nestačí a nejspu plně pod kontrolou? Dělá je každý...
Třeba Freescale: http://cz.farnell.com/freescale-semiconductor/mkl05z32vlc4/mcu-32bit-cortex-m0-48mhz-lqfp/dp/2253371
Nebo preferuješ STM? http://cz.farnell.com/stmicroelectronics/stm32f030c6t6/mcu-32bit-cortex-m0-48mhz-lqfp/dp/2393632
A co takový NXP (dřív Philips Semiconductors)? http://cz.farnell.com/nxp/lpc1113fbd48-302-1/mcu-32bit-cortex-m0-50mhz-lqfp/dp/2072186
Ale pochalpil se i Cypress, na čidla ideál: http://cz.farnell.com/cypress-semiconductor/cy8c4013sxi-400/mcu-32bit-cortex-m0-16mhz-soic/dp/2428329
No a sapmozřejmě je tady i něco od prznitelů křemíku: http://cz.farnell.com/atmel/atsamd20g14a-au/mcu-32bit-cortex-m0-48mhz-tqfp/dp/2363633A samozřejmě si něco s ARM jádrem můžete postavit i doma. Na FPGA ProAsic od Actelu je standardně příprava pro snadný zadrátování ARM7TDMI. Stačí koupit kit s vhodným broukem, Libero IDE a jede se... Zdrojáky jádra opravdu k AVR nedostanete :D
Pravda, Linux na ARMu za 2€ v kusovce moc neběží, ale AVRko proti němu nemá šanci... (vybíral jsem rozumný, doma pájitelný pouzdra. DFN, QFN a BGA jsou o něco levnější). A pro brouky ode všech výrobců stačí jeden programátor, jeden kompilátor a jedno IDE (pokud to není SAM-ICE).
-
Yenya (neregistrovaný)
Díky za přehled.
Já jsem před časem uvažoval (a dodnes uvažuju), že bych někdy zkusil pro změnu postavit nějaký projekt na ARMu. Myslím že jsem se dokonce díval na ten shora uvedený freescale (nebo nějaký podobný). Nakonec to ale skončilo na tom, že proti AVR to nepřináší v podstatě nic navíc(*). Podstatný rozdíl je až u něčeho, na čem by běžel Linux, ale to už asi není pájitelné v domácích podmínkách.
(*) ano, tyhle ARMy jsou o něco rychlejší a třeba ten STM má výrazně rychlejší ADC, což bych tehdy i využil, na druhou stranu mají výrazně větší spotřebu (přes 10 mA versus malé jednotky mA), mají obvykle o dost menší povolený rozsah napětí, atd. Některé AVR mají dokonce 2.7-5 V, což mimo jiné znamená že to přímo jde připojit na jeden lithiový článek bez dalších součástek.
No a pak je otázka, jak se to vlastně programuje - pro AVR je avr-gcc, které má k sobě avr-libc, a jsou tam definice registrů pro všechny možné modely, v podstatě je ten kód dobře přenositelný. A v datasheetu jsou ty registry přesně popsány jak se který I/O modul ovládá. Zkusil jsem kliknout na první dva ty odkazy na Farnell, a tamní datasheet tohle vůbec neobsahuje. Navíc pro Arduino existuje obrovská spousta kódu, ze kterého jde často dost jednoduše odmyslet ten Arduino balast nad tím, a vyextrahovat z toho vše potřebné pro programování přímo na úrovni AVR a jazyka C.
Pro projekty typu "potřebuju 5-10 pinů a nějaké vestavěné moduly typu PWM, UART nebo ADC, a ať to potřebuje co nejméně součástek okolo" je docela jedno jestli použiju ATtiny, ATmegu nebo tyhle malé ARMy. Spíš je důležitá dokumentace, dostupnost kódu, atd.
No ale teda stejně bych to někdy zkusil - kde najdu nějaké HOWTO, jak vybrat vhodný procesor a jak programovat ARM MCU pod Linuxem?
Ještě jsem se teda kdysi zkoušel dívat na PIC, a tam mi ta podpora co se týče infrastruktury (kompilátor, atd.) přišla daleko horší, než u AVR. Ale co jsem se díval, tak třeba v pračce i v ledničce jsme měli PIC, takže asi nějaký důvod pro použití této konkrétní architektury ti výrobci mají.
-
Petr M (neregistrovaný)
Na programování používám ARM GCC, GDB + FT2232D. Pod Eclipse.
Výhoda, no, závisí to na aplikaci. ARM je výhodný, pokud
- Potřebuju spouštět kód z RAMky, třeba nějaký produkční test nebo loader. U AVR to nejde (Harvard má oddělenou paměť dat a programu).
- Potřebuju někde používat konstanty z FLASH. Třeba u textovýho displeje. U ARMu to jde nativně, U AVR musím buďto mít dvě verze zobrazovací funkce, nebo mirrorovat aktuální text v RAMce, nebo mirrorovat celý CONST segment v malé RAMce, nebo mít u funkcí další parametr pro rozlišení zdrojovýho segmentu.
- Potřebuju pracovat s A/D nebo D/A převodníkem. Pokud bude 10b ADC, už na AVR potřebuju dvě slova v datové paměti. Násobení 16x16b dá 32b, u AVR tak můžu zpracovávat vzorky z až 16b ADC přímo (násobení 16b hodnotou, sčítání,...) a nezaliskám si tím čtvrtinu registrů jádra.
- Větší propustnost sběrnice - hodí se při ryhlejší komunikaci, třeba pokud bych s tím chtěl dělat něco jako "logický analyzátor", rychle lifrovat data do SPI FLASH atd.Pro AVR mluví jenom to, že
- je to v Arduinu pro lamy
- kdysi to bylo výrazně levnější proti jiným platformám
- dá se koupit v kusovce i v GME (i když několikanásobně předražený)
- je na to spatlaných hodně amatérských knihoven (kvalitu nehodnotím)
- PIC má katastrofální podporu
- MSP430 je u nás celkem neznámá platforma
- Renesas se moc neorientuje na bastlíře
- STM8 se blbě shánělo
- Freescale nijak neřeší podporu
- PSoC je pro většinu lidí nepředstavitelná technologie
- 8051 je nepoužitelnýProti AVR je
- Atmel Studio, založený na M$ Visual Studu, jenom puštění na Dell Lattitude E6430 s Win7 zabere tři minuty, absolutně nepřehledný a nestabilní
- Mám tady JTAG ICE Mk II a samo od sebe se to odpojuje a připokjuje k USB, prostě super drivery
- Nástroje od Atmelu se dají použít jenom s procákama od Atmelu, platí i pro ARM (zmiňovaný klon JLinku SAM-ICE, softwarově zamknutý jenom pro Atmel)
- Nestandardní ladění a programování (SPI, PDI, zprzněný "JTAG",...) -
Petr StehlíkZlatý podporovatel
Pro mě velmi hodnotný komentář, díky. Bylo by fajn, Petře M, kdybyste své hluboké znalosti a zkušenosti stran norem, HW interagujícího s AC a hlavně tohoto přehledu o mikrokontrolérech dokázal publikovat v nějaké ucelené formě. Tady v těch komentářích se to těžko hledá a časem poztrácí.
-
Petr StehlíkZlatý podporovatel
Není nezbytné publikovat na Rootu, přestože jsem přesvědčen, že by to redakce neodmítla. I tento můj seriál je zde na popud šéfredaktora, který by rád Root více "rozkročil" i směrem k HW, tak jako ostatně kdysi býval.
Můžete ale mít i svůj blog, na kterém si budete psát co a kdy budete chtít a my to budeme sledovat se zatajeným dechem. Anebo je v Česku mnoho technicky/HW orientovaných webzinů, které by po dobrém autorovi doslova skočily...
-
Yenya (neregistrovaný)
"- je na to spatlaných hodně amatérských knihoven (kvalitu nehodnotím)"
Checht. Pokud byste opravdu nehodnotil, nepoužijete ty hodnotící přívlastky "spatlaných" a "amatérských" :-) OK, váš názor na AVR je z vašich příspěvků vidět, ale věta o knihovnách je něco podobného, co jsme slýchali tak před dvaceti lety: "Linux je amatérský, opravdový UNIX je jedině Solaris".
Pro mě je například "spatlaná" a "amatérská" knihovna, ze které si můžu vyčíst co potřebuju, upravit pro svůj konkrétní typ MCU a použít, daleko přínosnější než žádná knihovna.
========
Ok, díky za sumarizaci pro a proti. Některé argumenty jsou pro mě relevantní, některé nikoliv (Atmel Studio, JTAG ICE). Co je třeba pro mě podstatné je, že breakout desku s ATmegou (Arduino Nano) můžu koupit hotovou za 6 dolarů i s USB rozhraním a stabilizátorem napětí, píchnout do nepájivého pole a začít prototypovat. A pokud k tomu nepotřebuju připojovat nic dalšího a naopak potřebuju USB, tak to můžu rovnou i použít jak to je. A kdyžtak programátor seženu za 4 dolary.
Existuje nějaký ARM ekvivalent třeba k ATtiny25/45/85? Pouzdro SOIC-8, 5 GPIO pinů, dva PWM kanály (případně i symetrické), ADC, komparátor, ...
Jakože značná část vašich argumentů pro ARM se dá shrnout jako "ARM bývá výkonnější". No ale já mám hodně aplikací, kdy výkon CPU není limitujícím faktorem, a na ty AVR stačí, a naopak je výhodou jejich dostupnost včetně toho, že často nějaký podobný problém na AVR už někdo přede mnou řešil, a jde se inspirovat jeho řešením, případně i vyhnout se problémům, na které narazil.
-
Petr M (neregistrovaný)
Pozor, ARM nebývá výkonnější, to je trochu omyl. ARM je tak výkonný, jak si ho nastavím. Klidně poběží i na 1kHz, když na věc přijde. A nastavím ho tak, jak zrovna potřebuju. Jestli rychlý, nebo úsporný. Klidně i za běhu.
A jako správný CMOS, Icc=A * Bf, kde A je klidová spotřeba (v datasheetu jako Stand-by), B je koeficient opět z datasheetu (např. 100uA/MHz). Dá se s tím hodně čarovat.
Klidovou spotřebou se klidně dostanu na úroveň uspané MSP430. Ale díky specifické instrukční sadě (pěkně to je popsáno i tady na rootu - http://www.root.cz/clanky/instrukcni-sada-mikroprocesoru-arm/#ic=serial-box&icc=text-title) můžu minimalizovat počet instrukcí. Když se má probudit ze spánku, vzít hodnotu z ADC a číslicově zpracovat, dostanu se na řádově míň instrukcí a tím i strojových cyklů. Když je vzorkování řekněme po 10ms, zpracování na 8b CPU sebere 8ms, nevymyslím nic. Jenom to probudit na plný výkon. U ARMu to jde třeba za 0.2ms až 4ms. A nemusím se probouzet na maximální frekvenci. Můžu stáhnout PLL, nastavit si optimální hodiny pro periferky, abych do nich nemusel rvát 32MHz a pak použít předdělič 64,... Dá se tam tak mnohem líp vytunit spotřeba.
Tohle jsou na první pohled neviditelný detaily.
Praxe: deska s ARM7TDMI@48MHz, USB device na čipu, audio korek, 8MB SPI FLASH pro data, pár operáků, 3x indikační LED, MAX232, na plný výkon i se ztrátama na zdroji to bralo průměrně 5V/12mA. Při odpojeným USB to spadlo na 8mA, stačilo přepnout PLL na čipu...
-
Yenya (neregistrovaný)
Teď nerozumím - většina z toho popisovaného jde přece dělat i s AVR. Ostatně jde o problém, který se třeba u velkých CPU řeší taky - jestli je lepší zpomalit CPU nebo naopak zrychlit co to dá a pak uspat (race-to-idle).
Každopádně z těch CPU co jste posílal vychází provozní proudy o dost víc než u některých AVR. Třeba samotné procesorové jádro ATtiny861A bere 0.7 mA při 1 MHz na 5V. K tomu 0.3 mA pro ADC a největší zásek měly hodiny PLL, které jsem používal pro PWM výstupy step-up a step-down regulátorů: 3.5 mA na 32 MHz, 6 mA na 64 mHz. Nakonec jsem použil tu nižší frekvenci a PLL vypínal i mezi jednotlivými bliknutími LEDky. Zkusil jsem to pak i měřit a skutečně se to chovalo zhruba takto. A mají tohle všechno v datasheetu uvedené, žádný problém jsem v tomto neobjevil.
Jak říkám - pokud potřebuju 32-bitovou aritmetiku nebo výrazně rychlejší jádro, asi bude ARM lepší volba. Taky - podle toho co píšete - pokud potřebuju vysmahnout tisícikusovou sérii a jít od toho. Pokud ale potřebuju ubastlit kusovku s pokud možno nízkými náklady na vývoj i následné použití, je fakt mnohdy levnější a pohodlnější zarazit Nano do nepájivého pole, vyzkoušet, podle toho navrhnout desku nebo jen shield, a je hotovo.
-
Petr M (neregistrovaný)
A ještě k těm knihovnám - pokud knihovna, původně psaná v C pro AVR GCC přímo neobsluhuje HW procesoru a nejde zkompilovat v ARM GCC, tak je něco hodně špatně (mezi židlí a klávesnicí u autora)... A všichni se tady přece baví o tom, že ty "hotový knihovny jsou použít jenom na AVR"
putchar() se přece používá stejně, ať je přesměrovaný do HD64380A, FT800 nebo na UART... Aplikaci je to jedno, ta jenom zavolá funkci. Low level funkcionalita se přiohne bez ohledu na kód ve vyšších vrstvách. Stejně tak se dají od HW abstrahovat celý fyzický rozhraní stylem I2C_WriteByte(char Adr, char Byte) a modul nemusí hrabat přímo na železo.
-
Yenya (neregistrovaný)
Na toto je jednoduchá odpověď: říká se tomu "layer bloat". Proč by putchar() muselo s sebou tahat celou mašinerii stdio, když ve finále na té konkrétní aplikaci v tom konkrétním procesoru půjde výstup jen do USART, jen do EEPROM, jen někam konkrétně. Pak má cenu do toho pomocí maker a podmíněné kompilace nacpat všechny varianty které jsem dosud potřeboval (včetně HW-specifických záležitostí), a zkompiluje se jen ta jedna. Takovou věc pak samozřejmě jinde nepoužijete, pokud nedopíšete tu svoji HW-specifickou část pro konkrétní ARM.
To že něco je napsáno na míru konkrétnímu HW bez příslušné abstrakce, ještě nemusí nutně znamenat, že je to bastl.
Ostatně řekl bych, že tyto knihovny vznikají často tak, že autor potřebuje řešit konkrétní problém, a možná jeho část vykopíruje do podoby knihovny, když už to teda napsal. Já osobně s tím problém nemám - toho kódu není moc, a tyto "knihovny" většinou používám jako startovací bod který dále upravuju, nebo i jen jako inspiraci, abych nemusel z datasheetu zkoumat, jak přesně se ten který HW inicializuje a používá.
-
Petr M (neregistrovaný)
Ony ty knihovny často vznikají tak, že autor má třeba jednu periferku na I2C, tak to prostě narve do jednoho modulu a přímo šmrdlá s registrama periferky. Tam je to pak peklo při změně platformy, při přidání dalšího brouka na sběrnici, při nutnosti použít softwarovou periferku na GPIO,... Při tom napsat to pořádně dá míň práce, než to takhle lepit.
Na originál knihovnách u procesoru je často taky vidět, co za experty mají ve vývojovým oddělení... Třeba originál HW drivery pro nějakou SH4A, to je lahůdka... :D
-
Zrovna integrovaný ethernet PHY je trochu problém, ale najít se dá - např:
http://cz.farnell.com/texas-instruments/tm4c1294ncpdti3/mcu-32bit-cortex-m4f-120mhz-tqfp/dp/2444603
-
Petr M (neregistrovaný)
Proč? MAC s MII rozhraním je u ARMu celkem běžná periferka, PHY v LQFP48 je od 35Kč/kus při jednotkovým odběru... Trafu, krystalu a bižuterce okolo se nevyhneš tak jako tak.
A výhoda je, že máš doma jeden typ brouka a bez LAN máš bonus 20 GPIO ;)http://cz.farnell.com/micrel-semiconductor/ksz8081mlxca-tr/ic-trx-phy-10-100-48lqfp/dp/2345480
-
Petr StehlíkZlatý podporovatel
Pročetl jsem zběžně prvních pár stránek specifikace a nepřipadalo mi to jako obecně použitelný mikrokontrolér s ethernetem a GPIO k tomu. ADC, PWM, SPI, I2C, ... nic z to jsem tam jaksi nezahlédl. Myslel jste to určitě jako dobrou volbu nahrazující řekněme Arduino a W5100?
-
Petr M (neregistrovaný)
To je samotná fyzická vrstva 100BaseTx. K procesoru se připojuje standardním rozhraním MII k periferii, označené jako MAC. Předpokládám volbu vhodnýho procáku s touto periferkou, pro mrzáčka s 2kiB RAM by integrování MAC moc nedávalo smysl.
Je to standardní způsob realizace LAN. On totiž dovoluje
- Zvolit si médium (tohle je pro 100BaseTx, existují PHY pro 100BaseFx apod.)
- Připojit místo toho switch a najednou jsou třeba čtyři porty (oblíbený třeba v routerech)
- Při nevyužívání LAN jek dispozici cca 20GPIO.Samo rozhraní MII znamená Media Independent Interface. Skládá se vlastně ze dvou rozhraní, managementu (signály MDC a MDIO, obdoba I2C) a vlastního rozhraní pro data. V tom jsou 25MHz hodiny, čtyři bity pro Rx, čtyři pro Tx a nějaký signály pro řízení (Data Valid, Collision,...)
Toto rozhraní má i svoje varianty - třeba RMII (Reduced MII), kde je takt 50MHz a jenom dva datový vodiče pro každý směr, GMII (Gigabit MII) s tatem 125MHz a osmi drátama pro každý směr, RGMII,...Použitelný procesory jsou třeba zmíněný AT91SAM7X (šuplíkový zásoby), http://cz.farnell.com/nxp/lpc4330fbd144-551/mcu-32bit-cortex-m4-204mhz-lqfp/dp/2094316 apod.
-
Petr StehlíkZlatý podporovatel
Pak ale nechápu tu hlášku, že "máš doma jeden typ brouka a případně 20 GPIO navíc". To bylo myšleno na ten Cortex M4, ke kterému mohu/nemusím připojit přes MII ten druhý čip? Protože já to původně pochopil tak, že "jeden typ brouka" je ten převodník MII-ethernet, a to mi nedávalo smysl.
-
Jiri Pittner (neregistrovaný)
Dobry den,
prad casem jsem resil podobne zarizeni - pouzivam take ATmegu, ale vzdalena cidla konunikuji bezdratove na 433 MHz, display mam jen textovy s ovladanim rotacnim koderem, na mereni teploty jsem z historickych duvodu pouzil SMT160 s PWM vystupem. Schema v Kicadu a zdrojaky jsou na http://www.pittnerovi.com/jiri/hobby/electronics/thermostat/, treba by se to nekomu mohlo hodit.
Zdravi,
J.P. -
libcha (neregistrovaný)
Zaujalo mě, že autor vyvinul nemalé úsilí na konstrukci ovladače, napodobujícího obývákové ovladače běžně prodávané s kotli.
Když už je takový geek (všechna čest!), očekával bych, že uživatelské I/O bude řešit nějakým serverem (samozřejmě tak aby při ztrátě serveru přestalo fungovat jen uživatelské rozhraní, ne automatická regulace kotle) a aplikací pro PC/mobily, aby mohla kotel ovládat i rodina ;)
Výhodu by to mělo kromě ušetření podstatné části elektrobastlení i v tom, že by krabička snímající teploty a řídící kotel mohla být někde schovaná, klidně i vně baráku, aby dovnitř netahala blesky :)
-
Petr StehlíkZlatý podporovatel
Server je přece součástí a kotel rodina ovládá i přes web. Nerozumím přesně, co vám chybí :)
Jinak ta krabička je prostě taková zvyklost, člověk nemusí vytahovat elektroniku pokaždé, když chce vědět jak je - prostě jen zvedne hlavu a mrkne. Je to především praktické. Něco jako trvale na zdi přitlučený tablet :)
-
Potřeboval bych trochu "nakopnout" ohledně sběrnic. Je to sice trochu mimo mísu, ale mohlo by se to někomu hodit.
Stručně: Mám udělané moduly, které komunikují přes CAN sběrnici (ATmega8, řadič, budič). Mám je pod vypínači a používám je k ovládání světel (rolet, magnetické spínače, pohyb čidla..). Na modulech je vstup pro 1-wire čidla, které pak ovládají topení. Ale SW je z mého hlediska celkem robusní. Chtěl jsem původně postavit vše na 1-wire sběrnici, kde by se jednoduše posílala adresa modulu s teplotou, spínačem... Ale jsou tam pro mě dvě omezení: 1. 1-wire součástky s IO nejsou úplně dobře dostupné (+cena) 2. Latence na sběrnici jsou u spínačů dost velké (myslím tím více modulů se spínači, kdy je musí obsloužit master). Doba k sepnutí světla se tak prodlužuje. U teplotních čidel je to jedno.
To hlavní: Jakou sběrnici použít (i modifikaci), aby byla jednoduchá, dostupná pro amatéry, levná (cca 100Kč/modul), pokud možno robusní pro domácí automatizaci? A budu si vymýšlet - ideálně stejné vodiče pro napájení i signály (dvouvodičová).
-
Petr StehlíkZlatý podporovatel
Zůstal jsem u 1-wire. Součástky jsem si postavil (jak jinak než na Arduinu). Kde u spínačů vzniká latence a proč?
-
Petr M (neregistrovaný)
Latence vznkají proto, že je tam polling masteru na hodně jednotek a malá přenosovka. Vypínač musí třeba 1.5s čekat, než se ho master zeptá, co je novýho. 99% trafficu je při tom o ničem. Jenom "Stalo se něco?" "Nic."
Tam jsou jenom dvě možnosti, CSMA/CD nebo extra lajna pro každý čidlo (ale tolik UARTů aby rval do středně velkýho FPGA, běžnej procák jich má max. 5.)
-
Petr M (neregistrovaný)
Co takhle Energy Bus? Ten by nevyhovoval?
- Dva dráty pro napájení a data
- (proudový) zdroj s LM317 dodává v klidu 24V/50mA
- Z tohohle zdroje se krmí zařízení na sběrnici. Pokud to nestačí, přihodí se další zdroje.
- Těch 24V je log.1. Kdokoliv na sběrnici může poslat 0 tím, že sepne tranzistor. V sérii s ním je zenerka, takže napětí spadne na 12V. Max.takhle zkratovaný proud je 100mA.
- Příjem pomocí hyterezního koparátoru (ale šlo by použít i odporový dělič a 4093)
- Krmeno z UARTu
- Standardní rychlost 2400Bd, pokud tam budu jenom tvoje výtvory, můžeš to trochu "nakopnout"
- Volně dostupná specifikace.
- XOR mezi RxD a TxD zavedený do interruptu dovolí detekci kolize na úrovni bitů.Jestli je to za kilo nevím, ale extra drahý součástky tam nebyly. U pasivního zařízení je to operák, pár odporů a kondíků, dvě diody, stabilík na napájení, zenerka a jeden tranzistor.
-
Petr M (neregistrovaný)
Ohledně odolnosti - nemyslím, že indukovat (24-12V)*100mA = 1,2W rozdílu mezi jedničkou a nulou do kroucené dvojlinky je v domácím prostředí tak easu, aby to pětkrát denně padlo. Navíc používají CRC, kolize se detekuje na prvním bytu, kterým se vysílající představuje. Hardware se zdá být neprůstřelný, slabina může být SW...
Pod minulým dílem jsem dával odkazy na specifikaci.
-
HW vypadá jednoduše, protokol je složitější (ale je to multimaster). Ta bajtová arbitráž mi sice nesedí, ale asi to funguje (předělal bych to na bitovou). Snad budu mít čas to vyzkoušet. Mám dilema. Ty moje moduly jsou už celkem odladěné, tak se v nich nechci moc šťourat, ale koncepce už je stará 10 let. Nu, použil bych to někde jinde. Nenašel jsem ale nikde zdrojáky, ani jakou to má licenci. Taky se divím, že to nasadil jen Vaillant.
Taky jsem nepochopil napájení. Maximum je 100mA nebo tam těch zdrojů může být víc? -
Petr M (neregistrovaný)
Není to multimaster, je to styl "kdo chce,vysílá".
Při návrhu šlo o jednoduchost, proto se řeší byty. Proto je tam v prvním bytu adresa vysílajícího a ne cíle a je to i důvod toho CRC.
Licence, no, co jsem pochopil, tak je to bastlířský německý projekt.
A napájení - mám třeba 20 pasivních modulů se spotřebou po 35mA. Takže potřebuju 700mA + něco na komunikaci a rezervu. 750/50=15 napájecích modulů a celkový příkon dimenzovaný na 18W. Modul napájení jde samozřejmě řešit i jinak...
-
Nikita Bretschneider (neregistrovaný)
Dvě poznámky. Pokud má kotel i oběhové čerpadlo (tj není to samotížka), je vhodné nechat ho zapnuté ještě chvíli po vypnutí kotle. Horké topné medium se vyplaví z kotle do radiátorů a chladne tam namísto toho, aby bezúčelně chladlo v kotli. Takže ty relé na 230V to chce spíš dvě. U normálního termostatu typu "rego" jsem to řešila časovým relé na din lištu, což se jinak používá na časování osvětlení schodišť a podobné věci.
Druhá poznámka. Chladič se nesmí lepit chrchlometem! (tavné lepidlo) Teplem ten lep povolí a chladič potom klouže. Osobně se mi osvědčila tenká vrstva lukoprenu. Přestup tepla asi jako přes silikonovou podložku pod tranzistor (takže žádná sláva), ale drží to na místě a nehne se to.
ČLÁNKY DO MAILU
