Nano-X na mikroprocesoru AT91SAM9260

Na webu uCSimply vyšel článek, který popisuje zprovoznění linuxového GUI Nano-X na mikroprocesoru AT91SAM9260 a TFT displeji s grafickým řadičem SSD1963.

11.6.2013 19:27 | mares.vit | Zajímavý článek

Komentáře

[Pavel Píša]

Pokud by někoho zajímaly Microwindows drivery pro různé malé displeje na SPI, I2C nebo s paralelním rozhraním, tak se může podívat do našich repozitářů

http://sourceforge.net/p/ulan/ulan-addons/ci/master/tree/microwin/drivers/

Mnoho let již Microwindows používáme jak na Linuxu, tak na real-time exekutivě RTEMS a i na malých CPU bez OS (LPC17xx, H8S atd.). Máme i celkem zajímavé GUI postavené na popisu obrazovek a scénářů chování v XML. Je plánované jako opensource pod MPL, ale zatím nebyl dostatek energie a zdrojů na to ho někde publikovat alespoň se základní dokumentací a připravit rozumně velké příklady použití. Máme jenom kritické a velké aplikace pro naše zákazníky. Na druhou stranu dnes asi většinu do budoucna vyřeší Qt a QML. I když nároky jsou úplně někde jinde. V minimální verzi, kdy je místo XML použité vytváření widgetů v "C", se vcházíme do 32kB RAM i s celkem komplexní aplikací.

Pokud by někdo měl zájem o spolupráci v této oblasti tak se může ozvat.

[little.owl]

Pokud by někoho zajímaly Microwindows drivery pro různé malé displeje na SPI, I2C nebo s paralelním rozhraním, tak se může podívat do našich repozitářů

To je kus dobre prace.

[Bedňa]

+1

[Xii]

ten pekelnej uLan ještě neumřel?

[Pavel Píša]

Ten projekt již 20 let slouží v mnoha našich (PiKRON) zařízeních a projektech všech generací (od 8051, přes LPC21/17, Linux, Win a připravujeme i Win7 64-bit podporu) i v zařízeních v zemědělské výrobě od AGrosoft.

Knihovny z tohoto projektu jsou pak základem mnoha dalších zařízení a byly použíté i v dalších (open-source) projektech.

Co se týče komunikace, tak jsou dnes určitě lepší možnosti a uLAN je dost komplikovaný a ocení ho až ten, kdo opravdu potřebuje multimaster a objektový přístup s dlouhodobou možností rozšiřování. Pro domácí aplikace je pak potřeba bezdrát, ale to bylo mimo naše aplikace a z těch, co chtěli uLAN použít pro domácí automatizaci, tak nikdo nechtěl vlastnímu projektu věnovat reálné úsilí.

Protože jsem si vědomý toho, že tahle naše komunikace není pro většinu zajímavá, tak jsem jí ve zdejších vodách moc nezmiňoval. Ale ta grafická část by někoho zajímat mohla.

K těm Microwidows driverům, co jsme společně vyvíjeli existuje i alternativní vyšší vrastva než naše XML driven SuiTk GUI a je na tom postavené více produktů další firmy (ALVAT). Tady jsou příklady jejich GUI. Vlastní knihovna je jejich komerční produkt a na rozdíl od nás spíš o MPL neuvažovat nebudou, ale většina jimi používaných driverů je v tom uLAN repository a v případě zájmu tam lze po pročištění prototypových implementací přidat i další z firemních repozitářů.

Takže si myslím, že celkově naše snažení užitku a finalizovaných aplikací přineslo mnoho a může pro někoho dalšího, kdo nemůže použít QT a QML nebo jiné plnohodnotné GUI, mít smysl.

[little.owl]

Co se týče komunikace, tak jsou dnes určitě lepší možnosti

To urcite.

a uLAN je dost komplikovaný a ocení ho až ten, kdo opravdu potřebuje multimaster a objektový přístup s dlouhodobou možností rozšiřování.

A jakou to ma podle vas vyhodu oproti implementaci na bazi CAN bus, ModBus ci treba LIN bus? Cokoliv nad RS-4xx je pro me trochu uz krik ze zahrobi a high level protocolu pro serializaci vcetne generatoru kodu je plno.

[Pavel Píša]

ModBus na RS-485 je prasárna, která nikdy pořádně o multi-masteru neuvažovala. CAN je pěkný a na procesorech, které mají řadič, rozumný. Nakonec pro Linux jsme se, co se týče CANu, něco napracovali. Např. OrtCAN - LinCAN a i když dnes je standardem SocketCAN, tak i tomu jsme pomáhali jak z nadšení, tak i v placených projektech. CAN je velice pěkný na malá zařízení, ale má tvrdá omezení, např. při 1 MBps je max vzdálenost mezi nody okolo 30 metrů. Další zásadní vada je, že potřebuje tahat vždy tři dráty, bez země vede recesivní stav k zarušení. RS-485 s dobrým zakončením a rozvážením chodí na stovky metrů a jen po dvou drátech. Další problém CANu je max payload 8 byte. Z pohledu real-time je to dobré, ale pro SDO data to znamená, že komunikace nemůže být bezstavová => buď jen jeden master na daný SDO server nebo různé oprasy jako více SDO s NMT komplikovaným procesem navázání přístupu. Pro jednoduché zařízení je to pak celkem děsivé.

Dnes je určitě správná cesta Ethernet, ale ten má jiné nároky na počet i kvalitu vodičů a topologie hvězdy s centrálním switchem je také pro větší prostory neštěstí. Řeší se to různými daisy-chain řešeními, ale tam jde zase dolů odolnost k poruše na jednotce (ETHERcat, ProfiNet atd.). CAN teď přichází s rozšířením Flexible Datarate a 64 bytů payload. To některé problémy (vy)řeší, až většina MCU bude rozšíření podporovat (tak 10 let výhled).

Pro malé věci a v případě bez MCU pak není RS-485 špatnou volbou. Problém je protokol. Z těch, co myslí na multimaster, jako standard připadá v úvahu Profibus. Ale to je horká půda. Nakonec k open-source v této oblasti jsem také měl zájem přispět, ale výsledek byly ústně doručované tvrdé výhrůžky a aktivity právníků Profibus organizace, když taková věc vnikla. Teď je ve stavu zobie/dalšího komerčního projektu pod jejich kontrolou. A ono doba zotavení po ztrátě tokenu je také docela děsivá.

Z dalších projektů nad RS-485 je většina buď čistý master-slave nebo nepromyšlené ad-hoc řešení. Dobrý je asi BacNet MS/TP. Ale s tím zkušenosti nemám.

Na druhou stranu jsou i lidé, co roztahají po celém domě One-Wire a chodí jim to. Ale z firmy jsme nějak zvyklí, že průmyslová řešení musí být galvanicky oddělená, i veškeré převodky USB FTDI nebo CDC na TTL si děláme s oddělením a na zařízeních je to u nás pravidlo. A vedení na vzdálenost delší než 60 cm vždy diferenční. Vždy jsme to i u robotických věcí a dalších zařízení doporučovali a tam, kde diferenční interface nebyl třetími stranami dodaný/akceptovaný - např. IRC/ILC na některých robotech, tak v reálném nasazení vždy nakonec problémy byly a pomáhali jsme to (často komplikovaně) řešit předěláním na RS-485/422.

Takže i do budoucna mají RS-485 budiče/vedení smysl. Na kratší vzdálenosti (metry) možná půjde začít používat linky na bázi PCI-express/SATA/DVI, to je kódování 8 na 10. Ale tam zatím nejsme a jak by měl vypadat protokol také nevím. Ono vlastní PCIe moc na RT řízení někdy díky značným latencím nevychází.

[Pavel Píša]

Pro malé věci a v případě bez MCU podpory CANu

[little.owl]

LIN?

[little.owl]

ModBus na RS-485 je prasárna,

S tim bych souhlasil, treba na Modbus/TCP nemam vzpominky prilis dobre.

CAN je velice pěkný na malá zařízení, ale má tvrdá omezení, např. při 1 MBps je max vzdálenost mezi nody okolo 30 metrů.

Coz v plno pripadech staci, ostatne jako LIN na uCPU chcipacich.

CAN teď přichází s rozšířením Flexible Datarate a 64 bytů payload.

Ano.

To některé problémy (vy)řeší, až většina MCU bude rozšíření podporovat (tak 10 let výhled).

Uz ted to mame ve specu pristi generace ECU, vcetne zajistene vyroby CPU (Freescale); ale asi to bude pase.

Dnes je určitě správná cesta Ethernet,

Ano.

ale ten má jiné nároky na počet i kvalitu vodičů a topologie hvězdy s centrálním switchem je také pro větší prostory neštěstí. Řeší se to různými daisy-chain řešeními, ale tam jde zase dolů odolnost k poruše na jednotce (ETHERcat, ProfiNet atd.)

Uz dva roky jedem na AVB. Ruseni neni problem ani u startujiciho auta, diky technologiim jako Broadreach, k dispozici jsou i routery/switche, vcetne precizni synchronizace, timestampovani packetu po cele trase.

A vedení na vzdálenost delší než 60 cm vždy diferenční.

LVDS

Takže i do budoucna mají RS-485 budiče/vedení smysl. Na kratší vzdálenosti (metry) možná půjde začít používat linky na bázi PCI-express/SATA/DVI, to je kódování 8 na 10. Ale tam zatím nejsme a jak by měl vypadat protokol také nevím. Ono vlastní PCIe moc na RT řízení někdy díky značným latencím nevychází

Porad mi prijde ze zacinate nekde uprostred. Prvni je specifikace pozadavku a pak se hleda reseni, ktere je naplni.

A stale jsem nepochopil vyhody uLAN .

[Pavel Píša]

Jen se snažím popsat můj pohled na problémy různých komunikací. Jasné je, že pro reálný/konkrétní projekt je potřeba dát dohromady specifikaci, nebo požadavky přímo vyplývají z oblasti použití. Pak má smysl vybrat vhodné řešení. A to je to, co ve většině projektů děláme.

Co se týče uLANu tak se hodí tam, kde je potřeba zapojit MCU jen s UARTem a nebo kde je RS-485 vhodná volba. To je omezení na dva vodiče, požadavky na rozumnou odolnost a oddělení, pro nízké rychlosti možnost použití libovolných vodičů, i zvonkový drát, žádné požadavky na topologii, díky multidrop sběrnici na fyzické úrovni žádné problémy s výpadkem centrálního prvku atd.

uLAN má v současné době smysl jen tam, kde stačí z dnešního pohledu směšné rychlosti. Např. u HPLC nás zajímají desítku (sice hodně přesných) vzorků za sekundu a ještě mohou jít v paketech jednou za sekundu. Na druhou stranu potřebujeme občas vzájemné řízení, posílání signálů, mezi přístroji, takže se hodí multi-master. Například propojením dvou pum se po nakonfigurování chovají z lokální klávesnice i pro nadřazené PC jako jedna s možností řídit složení čerpaného média včetně možnosti naposílání programu gradientu v čase na master pumpu.

Výhoda to může být i pro levnou/poloamatérskou domácí automatizaci. Tím, že se data posílají jen tehdy, kdy to je potřeba (dojde k změně, k stisknutí tlačítka atd.) tak nejsou reakční doby nijak dlouhé (hodně pod 1s), což při single master/slaves řešeních často bývá i při rychlejší komunikaci a hodně jednotkách problém.

Díky distribuovanému algoritmu arbitrace není pro multi-master potřeba udržovat tabulku sousedů. Bez objektové vrstvy, ale multi-master, nám to chodilo i na 8051 s 256 byte RAM. Pro případ, kdy lze servisní data kumulovat do delších paketů (u nás typicky dotaz na stav tak 20 položek v zařízení nebo jejich nastavení) vychází podíl doby arbitrace ku datům lépe než na CANu. V RTLWS článku popsaný systém skládání a konfigurace procesních dat do kanálů a broadcast packetů to rozšiřuje i na předávání většího množství procesních dat. Přitom poměr délky vodičů ku komunikační rychlosti vlastních dat vychází 10-krát lépe než na CANu. To sice pro 19200 není zajímavé, ale při 1 MBps by to dalo 300 metrů. V podstatě stejné chování jako FD-CAN, ale navržené před 23 lety. S tím, že u nás nebyla preference priorita, ale jakžtakž spravedlivé rozdělení přístupu k médiu mezi více jednotek při plném vytížení sběrnice. I tak proti FD-CANu má naše řešení zásadní výhodu, že vlastní data jsou vysílaná v push-pull režimu, to znamená, že není jiná dynamika přechodů mezi 0->1 a 1->0 a linka při vlastním datovém přenosu může být impedančně symetrická. Ovšem o tom by mělo smysl uvažovat jen v případě implementace uLANu v FPGA nebo na čipu pro vysoké rychlosti. Zásadní nevýhoda jsou zbytečné start a stop bity UARTu, jenže bitstuffing nebo jiné lepší kódování vyžaduje specializovaný HW. Ještě ztrácíme jeden bit na rozlišení adresních/řídicích bytů. Opět, formát vyladěný dohromady s HW by vyšel o hodně lépe. Na druhou stranu exponenciální štěpení/nárůst formátů rámců ve FD-CANu není nic až tak hezkého.

Vyšší vrstvy řeší plnou introspekci slovníků zařízení a přitom ve vlastních datech jsou objekty specifikované jen identifikátorem o délce 16-bitů. Další metadata (2 nebo 4 byte) jsou pak potřeba až při přístupu do polí. Na druhou stranu na straně vyššího řízení/software s možností přístupu do slovníků se za to platí nutností budovat si přesný model položek v zařízení a v případě chyby v kódování nebo neznalosti položky v odpovědi to znamená dost komplikace. V případě monitoru, analyzátoru si lze paket podržet a zařízení se na význam kódů vyptat, jednotlivě i dávkách a díky bezstavovému protokolu není problém se ptát z více nódů naráz. Přitom koncept konfigurovatelných kanálů a metadat umožňuje pro specifikaci složitých propojení i mezi zařízeními, která sama skládat požadavky na přístup do objektových slovníků neumí. Implementace na straně zařízení je pak celkem nenáročná. uLAN lze bez problémů provozovat i na MCU s 8k RAM a při optimalizaci současného plného C kódu by se šlo i s objektovou komunikací dostat na 2.5 kB RAM (to jsme na 8051 v ASM mívali vyřešené). To jsou požadavky, které standardní komunikace nad Ethernetem nepřipouští. Asi by mohlo být zajímavé něco jako uLAN řešit nad RAW packety - možná Ethernet PowerLINK.

Obecně tedy neprohlašuji, že je uLAN nějaká velká sláva. Hlavní důvod pro nás je, že nám to roky chodí. Problémem je spíš že jsme nedefinovali odpovědi při detekci chyby v objektových datech (teď se to řeší tak, že se pro každou SDO frontu pro zařízení na straně mastera hlídá timeout) a další chyba je slabá ochrana dat proti chybám (1 byte XOR sum + 1). Ztráta nebo chyba v unicast packetu ale může být na linkové vrstvě opravená díky možnosti přímého ACKu. Dál chybí implementace pro propojování více sítí, i když trochu promyšlené to mám.

Co se týče LINu, tak to je další a řekl bych ještě více diletantsky navržený bastlík nad UARTem. O tom, že vůbec při prvním návrhu nemysleli, svědčí chránění dat proti chybám zvlášť od identifikátoru/hlavičky. Nová verze specifikace to již záplatuje. Možná by mohl někoho zajímat náš projekt na LIN přes TTY/termios vrstvu v Linuxu. Pro mastera a monitoring by to mělo fungovat na široké škále HW/UARTů, testované na PC a MPC5200. Projekt je k dispozici zde.

Jinak si rád poslechnu kdo, co používá (ideálně s odkazy na otevřený kód) a rád se něčemu přiučím. Teď se zrovna kolem návrhu ECU jednotky včetně FlexRay také pohybuji, i když to není oblast, kde bych, kromě diplomky na CNG motory v autobusech z 90-tých let, měl až tak moc zkušeností.

[little.owl]

To je omezení na dva vodiče, požadavky na rozumnou odolnost a oddělení, pro nízké rychlosti možnost použití libovolných vodičů, i zvonkový drát

To mi prijde vyhodne pro situace, kdyz mate polozenou starou kabelaz, jinak bych veci jako zvonkovy drat neresil. Rozumna odolnost ma byt co?

Tím, že se data posílají jen tehdy, kdy to je potřeba (dojde k změně, k stisknutí tlačítka atd.)

Zadny "alive" signal?

Přitom poměr délky vodičů ku komunikační rychlosti vlastních dat vychází 10-krát lépe než na CANu. To sice pro 19200 není zajímavé, ale při 1 MBps by to dalo 300 metrů.

To mi prijde jako nejzajimavejsi cast; zatim mi ale stale neni zrejme pro tomu tak je a dnes jiz to lepsi nebude ...

jakžtakž spravedlivé rozdělení přístupu k médiu mezi více jednotek při plném vytížení sběrnice.

Pro urcite scenare ano, treba sber dat z vice ekvivalentnich senzoru; ale u kontrolni/ridici komunikace bych preferoval priority based bus arbitration.

I tak proti FD-CANu má naše řešení zásadní výhodu, že vlastní data jsou vysílaná v push-pull režimu,

Jak resite arbitraz na sbernici?

Vyšší vrstvy řeší plnou introspekci slovníků zařízení a přitom ve vlastních datech jsou objekty specifikované jen identifikátorem o délce 16-bitů. Další metadata (2 nebo 4 byte) jsou pak potřeba až při přístupu do polí.

Mate tedy nejaky generator kodu?

To jsou požadavky, které standardní komunikace nad Ethernetem nepřipouští.

HW pozadavky jsou o neco vyssi.

Asi by mohlo být zajímavé něco jako uLAN řešit nad RAW packety - možná Ethernet PowerLINK.

Zigbee?

Obecně tedy neprohlašuji, že je uLAN nějaká velká sláva. Hlavní důvod pro nás je, že nám to roky chodí.

Coz je hlavni duvod, proc cela rada jinych prisernych protokolu roky strasi, pokud se dostatecne rozsiri.

Co se týče LINu, tak to je další a řekl bych ještě více diletantsky navržený bastlík nad UARTem. O tom, že vůbec při prvním návrhu nemysleli, svědčí chránění dat proti chybám zvlášť od identifikátoru/hlavičky. Nová verze specifikace to již záplatuje.

Tak horke to neni, pokud si pamatuji enhanced checksum se pouzival mnohem drive nez se stal soucasti LIN2.0 standardu, automobilky si vykladaji tyto standardy celkem volne.

Jinak si rád poslechnu kdo, co používá (ideálně s odkazy na otevřený kód) a rád se něčemu přiučím.

Otevreny kod od nas? Realne ted jedem hlavne na CAN, LVDS, AVB, vse ostatni je pase. Trend je jasny, kabelu zacina byt neuprosne mnoho a med je draha => Ethernet, pres twisted pair.

[Bystroushaak]

Protože jsem si vědomý toho, že tahle naše komunikace není pro většinu zajímavá, tak jsem jí ve zdejších vodách moc nezmiňoval.

Já si tedy rozhodně radši počtu o zajímavých technických projektech, než ty debilní výžblechty v blozích, které tu v poslední době předvádí miriam a spol. Dokonce si troufám tvrdit, že nejsem sám.

[Bedňa]

+1000

[macek]

Pekne, i prechozi clanky na ucsimply.

Mel by jste nekde z diskutujich tip na rozumne drahy displej (aspon 320x200) pripojitelny k raspberry? Chtel bych si to povesit na dvere od kancelare a informovat lidi tak lidi. (nechci 2x 16 znaku apod zobrazovace postavene na HD44780).

Macik

[ruza99]

Líbí se mi jak se od nano-x řeší komunikace. Ale obě to jsou zajímavá témata, jen bych takhle rozsáhlou diskuzi o rozhraních čekal jinde. Některé příspěvky jsou poněkud nepřesné. Špatně by vzpomínal na ModBus/TCP s ohledem na RS485 asi každý, podle mého platí, že ModBus/TCP je ETH varianta modbusu. Pro RS485 platí varianta ModBus/RTU. Dále vyzdvihovat RS485 s dosahem nad CAN mi taky nepřijde příliš relevantní. Rozdíl by v tom asi příliš být neměl, obě sběrnice používají jako fyzické médium diferenciální pár vodičů s úrovněmi 0V a 5V (alt. 0V;3.3V). Co se týče terminace jsou si dost podobné. Je pravda, že algoritmus zajištění CANu je na přenosové médium citlivější než RS485, protože RSka nemá na HW úrovni žádný a všechno je jen o SW implementaci. Myslím, že 1Mbps přenášet přes tyhle sběrnice na řádově 100m vzdálenosti je nesmysl. Vždy bude potíž s rušením. Kdo chce takovou vzdálenost s takovou rychlostí by měl uvažovat o jiném řešení, např. optice. Zásadní nevýhodou CANu je velká režie, která se nedá ovlivnit. Na RS485 máte ruce volné a záleží na Vás co si vyberete, zda vyšší propustnost na úkor spolehlivosti nebo naopak. CAN je na straně spolehlivosti. Dříve jsme v práci implementovali hodně galvanicky oddělených RS485 a pokud se to udělá dobře, tak výsledky jsou supr, ale samozřejmě je to prostě RSka, neumí nic víc než přetahat 8/9 bitové znaky.ModBus je primitivní protokol a je třeba ho tak i brát. Spojení RS485 a ModBus je rozšířené, ale překonané. Kdo chce víc, ať implementuje složitá řešení ve formě průmyslového ETH, nebo si zaplatí za licence