Vlákno názorů k článku Hardware inteligentního internetového termostatu od Yenya - Já bych AVR až tak nezatracoval. Na rozdíl...
-
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ý podporovatelYenyo, č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.
-
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.
ČLÁNKY DO MAILU