Jakou struturu mcu zvolit

[Kolbaba71]

Už několik let se zabývám konstrukcí silné led svítilny jenž bude mít nastavitelný kužel a vodní chlazení. Při její konstrukci jsem narazil na problém ohledně struktury mcu, jelikož mě vychází, že jich budu potřebovat minimálně 8ks. Svítilna má 6 pohyblivých (a jeden pevný) bloků s led, jenž jsou uchyceny na otočné desce. V každém bloku bude řada čidel a snímačů. Jelikož chci omezit počet vodičů vedoucí z každého bloku na minimum. Proto bych chtěl do každého pohyblivého bloku dát mcu, jenž všechny naměřené údaje shromáždí a pošle přes sériovou linku do mcu (v otočné desce), co tyto data ze 6ks mcu shromáždí + přidá data naměřená v posledním 7. bloku, jenž je pevný a pošle vše do centrálního mcu, jenž bude v těle svítilny. Ten bude mít na starosti řízení asi 120ks DC/DC měničů, tak 20ks H-můstků, dotykový barevný grafický displej s rozlišením asi 800x600 (především text a jednoduchá grafika/symboly, grafy), RGB matrix (2ks předběžně 24x80 bodů), jenž bude na obou bocích svítilny - proto 2x. Zobrazovat může kritické stavy svítilny či nějaké animace. Právě ten matrix ve mě vyvolává otázku, zda nebude pro něj potřeba extra procesor.Na mcu, co budou u led bloků sbírat data, bude stačit nejspíš libovolný mcu. Trochu silnější asi bude potřeba ten co ty data bude shromažďovat a posílat centrálnímu mcu. Sběrnici bych chtěl RS485 a psát to budu zkoušet v “C”.

Potřeboval bych poradit, jaký mcu použít na sběr dat z 6 pomocných mcu + vlastní měření a hlavně jaký použít mcu na centrální řízení. A zda stačí jeden, nebo bude muset být dva (řízení + rgb matrix) či dokonce tři (řízení + rgb matrix + grafický displej) Stavbou se budu nejspíš zabývat ještě pár dalších let, takže nepotřebuji něco hodně rychle teď, ale spíš poradit co vybrat, abych nešlápnul vedle, což by mohlo mít v konstrukci svítilny fatální následky.

Jelikož jsem nepřišel na to, jak se sem dávají obrázky, tak obrázek, jak by mohla svítilna vypadat, je tady: https://photos.app.goo.gl/xhsAZp4B5FMJgiWE9
P.S. Je to jen mechanický ideový nápad. Tvary se postupně mění podle toho, co kam dávám, aby se to tam vešlo. Volím opačný, než obvyklý způsob - nemám najitou vhodnou krabici, do které se to budu snažit nacpat, ale udělám kostru, jenž obalím komponenty a tím vznikne vnější tvar. Mechanicky se nic měnit nebude - pořád počítám s otočnými moduly (vyjma jednoho) a otočnou deskou.

Hodně orientační soupis toho, co se bude ovládat/měřit.

1. Otočný modul (vše krát 7)
   1.1. 1x mcu
   1.2. 3x termistor
   1.3. 18x mikrospínač
   1.4. 9x reflexní čidlo
   1.5 1x čidlo vlhkosti
   1.6. 19x výkonová led

2. Otočná deska
   2.1 1x mcu
   2.2. 6x H-můstek
   2.3. 1x Čidlo vlhkosti
   2.4. 6x Snímač natočení
   2.5. 3x modelářský servo

3. Tělo
   3.1. Mcu (hlavni + pro displej + matrix)
   3.2. 2x Aku
   3.3. cca 120x DC/DC měnič (bude se nastavovat (jednorázově) přes RS485 a zpátky posílat naměřené hodnoty - nastavený proud a napětí a aktuální proud a napětí (tak 1x za sekundu, pokud mu nepřijde změna nastavení) )
   3.4. 6x H-můstek
   3.5. 30x mikrospínač
   3.6. 1x Dotykový displej 7"
   3.7. Led Matrix RGB (cca 2x 24x80 bodů)
   3.8. 6x modelářské servo
   3.9. 12x termistor
   3.10. Měření napětí/proudu aku
   3.11. 1x Čidlo natočení

[Martin]

1. najprv treba odpovedať na otázku, aký rýchly reakčný čas potrebuješ. Koľko údajov potrebuješ z pohyblivej časti poslať/prijať a ako rýchlo, respektíve akú odozvu systému očakávaš?

Predpokladajme, že potrebuješ zapísať a načítať 16B údajov. Predpokladajme, že každá správa bude mať nejaký úvod vrátane adresy modulu a nejaký záver vrátane CRC. Nech je to teda spolu nejakých 32B.

Ak by si komunikoval rýchlosťou 19200Bd 8E2, potom jedna správa zaberie čas:

11(b) * (1/19200) * 32 * 2 = 36,6ms. Bude treba počítať s nejakým časom na spracovanie v Slave a nejaký čas na spracovanie v Mastrovi. Tak nech je to spolu cca 40ms.

40ms. 6 je 240ms.

Bude Ti stačiť cca 1/4 sekundy na zber a nastavenie parametrov?

Ak áno, potom Ti bude stačiť nejaký bežný MCU s dvoma UART-ami.
Ako potrebuješ riadiť tých 120ks DC/DC meničov a s akou odozvou?

Podľa popisu by som asi ako na hlavný MCU siahol po riešení a´la RP.

Inak veľmi málo relevantných infomrmácií si poskytol pre zodpovedanie Tvojich otázok. Podľa toho aj budú vyzerať odpovede. V princípe, viac menej nikoho nebude zaujímať na čo to chceš, ale všetkých odpovedi chtivých budú zaujímať presne tie parametre ako požadované ovládanie (bárs čoho) a očakávané reakčné časy. O riadení motorov nehovoriac.

To bude 20 efektových motorov riadiť jeden procesor, alebo bude mať každý svoj MCU a ten si bude na základe pokynov riadiť to čo má? To isté platí aj pre tie DC/DC meniče. Predpokladám, že to chceš pre riadenie svetelného toku. Ak áno, má zmysel používať riadenie DC/DC meničov? nebolo by lepšie riadiť osvetlenie cez PWM?

Samozrejme, hneď na začiatku netreba zabúdať na EMC. Lebo sa nebudeš stihať diviť, čo všetko bude mať vplyv na “samovoľné” resetovanie MCU vplyvom nesprávneho zapojenia napájania, či návrhu DPS.

[Kolbaba71]

Problém vidím v tom, že na kritické události budu potřebovat rychlou reakci, tak 1/100 sekundy, ale na jiné nebude problém s reakční dobou 1/4 sekundy. Bohužel se může jednat o stejný mcu, kde bude stačit “pomalá” komunikace, ale v případě problému naopak “rychlá”, což by možná šlo vyřešit extra pinem - viz níže***. Ohledně kritické události je např. možnost nárazu modulu s výkonovými led. Pokud senzor zjistí blízkost překážky, stačí reakční doba 1/10 sekundy, ale v případě detekce fyzického nárazu budu potřebovat okamžitou reakci odhadem 1/100 sekundy. V tom okamžiku se musí objevit na displeji varování a současně (pokud to bude možné) se pokusí modul automaticky uhnout. Třeba teplotu nosné desky led stačí hlídat jednou za 1/2 sekundy. Pokud se přiblíží kritické hodnotě přes 80C, tak bych ji chtěl hlídat častěji, aby v případě neustále stoupající teploty systém včas upozornil a reagoval. Nastavení 120 DC/DC driverů stačí v řádu 1/4 sekundy. Počítám s tím, že se vyšle všem potřebným nové parametry a následně se pošle generální kód “přepni na nové hodnoty”, aby se jas neměnil postupně, ale téměř naráz. DC/DC drivery mají vestavěnou ochranu a tak v případě nějakého fatálního problému odpojí napájení, takže v tomto směru není potřeba nějaká extra rychlá reakce. PWM na řízení světelného toku použít nechci, jelikož DC/DC měnič, co navrhnul kamarád umí nastavit lineárně jak napětí, tak i proud a je to příjemnější pro oči, tak i šetrnější k ledkám. Další mcu pro řízení motorů být může, ale nemusí. Přestavení polohy motorů z jedné do druhé krajní polohy potrvá odhadem 2-3 sekundy a proto by asi bylo lepší je řídit extra mcu, aby měl hlavní mcu volno. Každý blok se může nastavit individuálně a to na libovolný úhel. Proto se právě ptám, jak to nejlépe udělat, aby se z toho nestal šílený kombajn, ale naopak aby vše fungovalo a člověk nezadal něco na displeji a pak několik vteřin čekal, až se něco bude dít. RGB matrix je pouze doplňková funkce a pokud animace naběhne o něco později, tak se nic nestane. I když pokud bude zapnutá volba, že bude zobrazovat naměřené hodnoty, tak zvláště u těch kritických by bylo vhodné, aby byly zobrazeny co nejdříve. Další hodnota, co u které je potřeba rychlá reakce je měření celkové odebíraného proudu. Budu tam mít i tavnou pojistku, ale tu považuju za krajní opatření, jelikož počítám s max odběrem kolem 300A, takže uvažuji o pojistce tak 500A, pokud je něco takového reálné použít kvůli přechodovému odporu a nebo bude lepší se spolehnout pouze na elektronickou pojistku. Modelářská serva, měření vlhkosti, průtoku a teploty vody, nepovažuju za kritické a tak stačí měření/nastavení i 1x za sekundu, stejně tak jako u čidel natočení. U čidel natočení v okamžiku natáčení bloků výkonových led či otočné desky očekávám samozřejmě výrazně rychlejší odezvu, aby mcu při dosažení nastavené polohy zbytečně “nepřejel”. Bylo by asi vhodným řešením, kdyby toto rovnou kontroloval stejný pomocný mcu, co by řídil H-můstek. Otázkou zůstává, zda všech 8 h-můstků řídit jedním mcu či mít pro každý mcu zvlášť. Pokud budu mít něco zobrazeného na displeji a tu hodnotu začnu měnit, bylo by vhodné, aby se ta hodnota měnila okamžitě a ne za 1/4 sekundy.

*** Jeden z nápadů, jak obejít klasickou komunikaci po sériové lince je ten, že by každý mcu vyjma hlavního měl extra pin, po kterém by se v případě vážného problému přihlásil o slovo a díky tomu by dostal absolutní přednost přes ostatními mcu a hlavní mcu by se věnoval především jemu a zbylým dle volného času.

Abych nemusel všechny možné parametry nastavovat extra, chci využívat uživatelské profily, jímž nastavím jedinou volbou individuální svit všech led a polohu jak bloků led, tak i otočné desky. Samozřejmě tyto nastavení se neprovedou slepě, ale budou se kontrolovat i krajní meze.

Snad jsem alespoň některé moje myšlenkové pochody dostatečně vyjasnil, ale nemám problém v tom pokračovat, pokud je stále něco nejasné.

[Kolbaba71]

U RGB matrixu uvažuju minálně o 15FPS, lépe 25FPS.

[Panda38]

U RGB matrix nebude problém s výkonem procesoru. Tady v ukázce animuji sice jen 320 LED, procesor ATmega8 s posuvnými registry, ale byla tam velká výkonová rezerva: Osvětlení vánočního stromku s 320 LED (320 LED Xmas Tree Lights) - YouTube . Problém je spíš v tom, že mezi procesorem a LED musí být velký tok dat, protože se musí řídit multiplexem, včetně řízení jasu LED (šířkovou modulací). Takový tok dat by velmi zatěžoval ostatní komunikaci. Proto by měl být na každou RGB matrix samostatný procesor, který bude od hlavního procesoru dostávat jen povely, ale ne podrobné řízení obrazových dat. Nejspíš by stačila nějaká ATmega 20 MHz, ale musí se počítat aby měla dostatek RAM pro buffer dat - tj. 24x80=2 KB hlavní frame buffer, a možná ještě dalších 2 KB pro druhý přepínaný frame buffer.

Pro hlavní displej by sice teoreticky bylo dobré aby procesor měl dostatek RAM pro obrazové frame buffery - tj. minimálně 1 buffer v RGB tedy 800x600x3=1.5 MB, což už může být obtížné splnit. Obcházím to tak (STM32), že obraz renderuji po pásech, a pak stačí i méně RAM, možná by to mohl zvládnout i Raspberry Pico s 256 KB RAM. Obsah displeje je definován stromovou strukturou okenních prvků (text, obrázek atd). Po změně obsahu displeje se aktualizuje modifikovaná oblast displeje (RECT rozsah). Při renderování se projíždí pásy obrazu (stačí jen modifikovaná část podle Y souřadnice), projedou se všechny okenní prvky (v pořadí od kořenového, tím se zajistí překryvy) a nechají se vyrenderovat, s tím že se jim řekne rozsah Y v obrazovém bufferu. Pak se každý pás pošle do paměti LCD. Je to docela rychlé a nepostřehnutelné že to běhá po pásech. Jen se musí počítat s tím, že se prvky renderují až ve chvíli zobrazení (včetně grafů, dá se to obsloužit), není dost RAM na přípravu obrazových dat předem. Ovládací jednotka by měla být samostatná (samostatný MCU), měla by obsluhovat RGB displej a matici tlačítek. Z ní by chodily jen povely do hlavní řídicí jednotky, která bude dělat hlavní rozhodování. Hlavní jednotka by se neměla zatěžovat obsluhou displeje a tlačítek, aby to nezpomalovalo její odezvy.

Celkově bych řekl, že tam bude příliš velký komunikační tok, který sběrnici přetíží a nebude stíhat. Na rychlé odezvy by mělo být těch sběrnic buď víc nebo spíš rychlá zařízení obsluhovat samostatnými linkami. A přenášet jen minimum dat - což znamená spíš samostatná MCU pro inteligentní periferie, aby se přenášelo toho co nejmíň. Problém je i dostatek pinů a interface procesoru, i proto je dobré vše rozdělit spíš na samostatné moduly s MCU.