Jakub Vrána napsal AI plugin sql-gemini pro nástroj pro správu databáze v jednom PHP souboru Adminer. Plugin dovoluje sestavovat SQL dotazy pomocí AI, konkrétně pomocí Google Gemini.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána nová verze 0.4.15 (𝕏) svobodného operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows. Přehled novinek i s náhledy v oznámení o vydání.
Byl představen rpi-image-gen, tj. oficiální nástroj pro vytváření vlastních softwarových obrazů pro zařízení Raspberry Pi.
Byla vydána nová major verze 8.0, aktuálně 8.0.1, softwaru pro správu elektronických knih Calibre (Wikipedie). Přehled novinek v poznámkách k vydání. Vypíchnuta je lepší podpora Kobo KEPUB formátu nebo integrovaný lokálně běžící engine Piper pro převod textu na řeč používaný pro čtení nahlas (již od verze 7.18).
Společnost OpenAI rozšířila své API o nové audio modely. Nový model pro převod textu na řeč (text-to-speech model) lze bez přihlašování vyzkoušet na stránce OpenAI.fm.
Příspěvek Bezpečnost paměti pro webové fonty na blogu Chrome pro vývojáře rozebírá, proč se pro zpracování webových fontů v Chrome místo FreeType nově používá v Rustu napsaná Skrifa z Fontations.
V pátek 21. a v sobotu 22. března proběhnou Arduino Days 2025, tj. každoroční „narozeninová oslava“ platformy Arduino. Na programu je řada zajímavých přednášek. Sledovat je bude možné na YouTube. Zúčastnit se lze i lokálních akcí. V sobotu v Praze na Matfyzu.
Komunitná konferencia Bratislava OpenCamp, ktorá sa uskutoční už o tri týždne 5. 4. 2025 na FIIT STU pozná svoj program – návštevníkom ponúkne 3 paralelné behy prednášok a workshopov na rôzne témy týkajúce sa otvoreného softvéru či otvorených technológií.
Časopis MagPi od nakladatelství Raspberry Pi se s číslem 151 přejmenoval na Raspberry Pi Official Magazine. I pod novým názvem zůstává nadále ve formátu pdf zdarma ke čtení.
Tiskni
Sdílej:
Návody pro Zephir, NuttX a další existují.A stojí za nemnoho. Zkuste na webu hledat nuttx tutorial. Najde vám to nějaká osm let stará videa (naprosto nevhodný formát pro tento druh obsahu) a odkazy na quickstart v dokumentaci NuttX. V dokumentaci najdete, jak to stáhnout, jak nainstalovat závislosti a... nic. Návod pro cmake nefunguje (vyžaduje instalaci dodatečného balíku, po nainstalování toho balíku stejná chyba.) Dobrá, zkusíme make, to prošlo. Dál to chce docela dost procházení toho webu, kde najdete nenápadný odkaz Guides, kde po dlouhém scrollování najdete "Custom Apps How-to". Tím se prokoušete, uděláte program, přeložíte, spustíte, dostanete NSH. Jak spustit přímo ten program bez shellu, těžko říct. Každopádně po absolvování quickstart nejste ani o kousek blíž k tomu to prakticky použít. Se Zephyrem to bylo lepší, tam jsem svedl čtyřhodinový boj ve snaze vyhnout se jejich SDK (obsahuje asi tak všechen software v celém vesmíru, přičemž to, co potřebuju, už mám stažené z archivů své distribuce), ale nakonec se nějak povedlo dopracovat k tomu, že jsem spustil program a ten něco dělal. Hledání zephyr tutorial pak najde docela pěkný úvod do problematiky - nic rozsáhlého, ale aspoň to obsahuje základní koncepty. Upřímně řečeno se mi filozoficky NuttX líbí víc - nenutí mě stahovat hromadu software kdovíodkud. Což mi naznačuje, že to není žádná rychlokvaška slepená z čehokoliv, jen aby to fungovalo. Ale v tuhle chvíli ten projekt považuju za software pro vyvolené, kteří už ví, jak se s tím pracuje. A nebo je to někdo naučí. (Možná námět pro seminární práci? Žádný převratný výsledek, ale schopnost učit je taky přijatelná dovednost, kterou si student může odnést.)
git clone https://gitlab.com/pikron/projects/imxrt-devel.git
cd imxrt-devel
git submodule update --init
cd nuttx
make
je to nad již starší verzí NuttXu, ale asi stačí jen update submodulu. A máte firmware pro náš https://gitlab.com/pikron/projects/imxrt-devel/-/wikis/teensy_bb. Podobně to nyní připravuji pro SaMoCon.
Úplně stejně a velkým reuse i našich zdrojových modulů a aplikací zkompilujete risc-v-esp32/ice-v-pmsm. Zde je ale v prerekvizitách instalace YosysHQ pro build designu PMSM periferií do FPGA. Ten Yosys s GHDL pluginen je zatím trochu magie. Ale třeba to bude za nedlouho celé v distribucích. Když v tom projektu dáte jen "make sw" tak stačí mít jen ESP tooly a příslušný GCC RISC-V kompilátor.
Export NuttX buildu pak lze požít i pro grafický návrh řídících aplikací v pysimCoder.
Ale jinak gratuluji k té nejtěžší části, která se liší podle HW. Na druhou stranu hodně platforem má celkem dobrou startovací NuttX dokumentaci.
A trochu s rozmyslem napsaná aplikace Vám již poběží všude, kde se potřebné periferie podaří nakonfigurovat. Pokdu něco málo nebo speciálního chybí, tak si drivery dopíšeme, je je možné mít i ve vlastním projektu a registrovat, ale v zásadě na všem se dokážeme dohodnout, že to jde do mainline. Ale NuttX ne jen že umí registraci driverů zalinkovaných do image s aplikací, ale při povolení i jejich runtime dynamické nahrávání třeba přes síť.
Připadá Vám to již takto zajímavější a je tam opravdu ten vstup tak těžký?
Když Vám pro danou desku přirpavím ten to level make, tak začnete okamžitě, na každé to Arduino kompatible to také někdo musel připravit. takže když si komunita vybere nějaké vstupní platformy, za mě třeba ESP32C6 nebo nějaký STM či SAM či to Teensy 4.1 kde mohou snadno přejít přes Arduino na NuttX, tak to vidím jako snadné...
Jinak těší mě, že se od toho zarytého tvrzení některých,že nemám obtěžovat, dostáváme k tomu, že se zkouší, kde pro začátečníka jsou s mojí nabídkou problémy.
Na které platformě jste NuttX zkusil Vy?
Připadá Vám to již takto zajímavější a je tam opravdu ten vstup tak těžký?Zajímavé to je, ale co se obtížnosti vstupu týče... popsal jste spoustu zajímavého software člověku, který zatím z dokumentace nevyčetl, co napsat za #include, aby aplikace to jádro vůbec mohla použít. Vstupní bariéra je prostě někde jinde, než na jaké úrovni se v této debatě pohybujeme
Na které platformě jste NuttX zkusil Vy?Risc-V Qemu. Pro NuttX ani nemám podporovaný hardware.
AVR byl to anachronizmus již před 15, 20 lety, vidím ty problémy v kompilátorech a obcházení špatného návrhu.Hm, nejdříve pro úplnost, kdyby sem někdo zabloudil z Google. (Doufám, že mě paměť moc neklame.) Problémy v kompilátorech jsou dle předchozích diskuzí zejména to, že přístup do programové paměti je potřeba mít uvozený do funkce, která provede příslušné instrukce. A je také nutné používat klíčová slova při práci s ukazateli na programovou paměť. Tj. není možné používat pointery "jen tak". No a teď se podíváme do zdrojových kódu NuttX jako nováček a jako jedna z prvních věcí na nás v deklaraci funkce vykoukne "FAR". Skoro to vypadá, jako by na tom NuttX nebyl o moc lépe...
se střední a vyšší vrstvou řízení Trasgasu, RegioJet motoráků atd. přešli na GNU/Linux.Co prosím? Linux, pokud vím, nemá žádné certifikace ohledně bezpečnosti nebo jako RTOS, takže s tím, že by byl součástí řízení vlaku, to se mi moc nezdá. Pokud tedy nemáte na mysli nějaké displaye apod., to pak jo - v roli levného GUI ho takhle najdete i jinde.
.. a pomáhám jim řešit problémy v těch skvělých ARduino knihovnách. Je škoda, že je někdo nepřesvědčil dříve, že Arduino není dobrá volba...Zeptal jste se jich proc si vybrali zeovna Arduino? Proste smula, dira na trhu, kterou vyhral nekdo jiny nez by jste si asi pral. Chapu Vas povzdech, ale tak to proste chodi. Zase, lepsi 3 skupiny studentu, nez zadna..
tools/configure.sh teensy-4.x:pikron-bb
Zrovna u libm je docela pravděpodobné, že pro danou konfiguraci, kterou jste zvolil, je vybraná externí, více optimalizovaná libm, která musí být dodaná s toolchainem. Tedy volba
Math library from toolchain (LIBM_TOOLCHAIN)Zkuste v "Library Routines" -> "Standard C Library Options" přepnout na
Math library from NuttX (LIBM)Jinak jestli je to tento problém, tak bych ho nehodnotil jako větší chybu, je to opravdu zájem dodat pro desítky platforem řešení, které lze nakonfigurovat i pro profesionální práci. Ale určitě je vítaný patch do dokumentace, kde bude popsané, že tento problém lze jednoduše řešit výše uvedenou volbou. Pro získání maximálního výkonu je pak potřeba zjistit, jaké je přesné doporučení pro danou platformu a který řetězec se má použít. To je často u platforem uvedené. To je konkrétně pro náš starší pokus teensy_bb. Moc nevyšel, SPIFI Flash i při velké cache je nakonec pro RT nad 1 kHz brzdou. Jinak na pomalejší věci je to sestava výkonná, další chyba je ale od autora Teensy špatný návrh napájení a reference ADC, takže na FOC řízení PMSM to nakonec je také nepoužitelně zašuměné. Ale s interní Flash na SAMv7 máme výsledky pěkné, s častováním před dedikovaný timer si troufáme v běžném POSIX tasku na 5 kHz a zdá se, že je to i při floodu z pingu a další zátěži pro již větší PMSM control aplikaci generovanou z pysimCoderu OK. Pro další testování přidal pan Pressl (autor HW a sestavení SW) do mainline NuttXu cyclictest s možností testování i proti dedikovaným timerům. Histogramy vychází slušně, i při zátěži task start jitter je pod 50 usec. Zajímá mě, jak to vychází na alternativách, máte představu? Testoval to někdo na Arduinu s pingem, Telenetem, nějakým logováním dat z RT procesu nad 100 Hz přes TCP nebo nějakou jinou pokročilejší komunikací třeba na Arduino, Zephyru atd... Pokud testujete aktuální mainline z GITu, tak je možné, že je tam něco je pokažené, pak určitě má smysl reportovat do projektu, ať se to dá dohromady. Ono opravdu na rozdíl od projektů, které jsou různé forky vždy pro konkrétní platformu jako je STMduino, ESPduino atd... je udržení podpory pro všechny desky níročné. Zase pak máte pro všechny stejné prostředí a nevyvíjí se vše desetkrát. Zároveň je možné testovat na Linuxu (když se dodrží základní POSIX subset) a pak jen překompilovat na NuttX. Jinak vůbec nemám zkušenost s buildem pod Windows mimo WSL a nemíním tomu čas věnovat. Zpět k příkladu buildu na Teensy-4.1, v mainline jsem teď narazil na nějaký problém, budu ho řešit. Ale vždy lze vzít release
git clone https://github.com/apache/incubator-nuttx-apps.git apps
git clone https://github.com/apache/incubator-nuttx.git nuttx
( cd apps && git checkout -b release-12_6 origin/releases/12.6 )
( cd nuttx && git checkout -b release-12_6 origin/releases/12.6 )
Konkrétně pro to teensy jsme teď updatoval náš projekt s návrhem desky
a základní podpory pro NuttX i jeho export pro náš build větších aplikací
mimo zdrojáky NuttXu, kdy se vše konfiguruje pro daný target automaticky.
Můžete zkusit
git clone https://gitlab.com/pikron/projects/imxrt-devel.git
cd imxrt-devel/nuttx
git submodule update --init
make
Vše by se mělo pak sestavit automaticky i s nějakými našimi věcmi navíc
pro ty externí buildy. nttx-export pak lze použít i přímo pro návrhy řídicích
systémů přes pysimCoder.
Jinak ano, NuttX má mnoho potíží, podle mé, již starší analýzy, je jeho scheduler je vhodný jen pro menší projekty do tak jednotek, možná desítky naráz probuzených tasků. Stějně tak škálovatelnost čekání mnoha tasků na muttex nebude žádná sláva, ale nabízí POSIXový priority inherintace. NuttX sice SMP podporuje, ale sám bych si ho takto použít netroufl. Naopak třeba RTEMS má plánovače někde úplně jinde, již před 10 lety běhal na 24 jádrových PowerPC, jenže mu chybí podpora platforem a periferií, tu má dobrou pro těch několik letových systémů, ale ty jsou zase mimo možnosti běžných nadšenců. Zephy je pěkný popisem hardware přes device-tree, což sice pro začátečníky je také komplexní, ale smysl to má. Plánovač má podle mě tak někde mezi, nelíbí se mi zatahování celých HALů od výrobců čipů, bude tam obrovská duplikace a nekonzistence podpory a stylu programování mezi různými rodinami.
Přiďte se podívat na InstallFest, Michal Lenc tam bude povídat, jak připravují i přes NuttX mainline podporu updatování a vzdálené správy firmware
Aktualizace embedded systémů pomocí NuttX bootloaderu v Elektroline.cz.
Sám jsem letos přednášku nepřipravoval (lze čerpat z minulých), ale když se stavíte na mých workshopech, které jsou spíše míněné jako setkání a společné pokusničení, a třeba si přinesete i svůj hardware a počítač s GNU/Linuxem nebo alespoň s Ubuntu ve WSL, tak s Vámi zkusím NuttX na Vaší platformě zprovoznit. Případné chyby, které jsou často závislé na konkrétní instalaci a nastavení když tak nahlásíme do mainline. Rád se podívám a třeba navrhnu proměření i na jiných embedded systémech RTOS i bez RTOS. Ideální je to s lidmi, co do nich přímo přispívají, aby měli přehled, případně bechmarky dostali i do jejich do mainline.
Jinak bát se nemusíte, pokud si potřebujete jen dokázat, že učit se něčemu novému nemá cenu, tak si určitě toto stanovisko dokážete i na základu toho, co se nám nebude dařit, dokážete potvrdit a žít s nějakým řešením od těch, co si vás chtějí zavřít do nějakého ekosystému bez dobré možnosti spolupráce s druhými a portace aplikací mimo, dlouho spokojeně, ale pozor, často to pak zruší, jako ARM Mbed, Microsoft ActiveX, Explorer ekosystém... Ale bát se také nemusíte, za Skype Vám nabídnou Teamsy (tedy práci open source komunity přes KHTML, Safari , Chrome až opět do uzavřeného prohlížeče od MS) kde si pro naplánování schůzky na čas koupíte uživatelskou licenci Exchange. Stejně je to většinou s Arduino ekosystémem, třeba na Teensy je zamknutý na updateru přes USB, takže si vlastní destičku nepostavíte, nebo si k ní musíte kupovat "licenční" čip. S tím, že jeho účel je zjednodušit nahrávání, ale zcela blokuje HW debuggování (SVD/JTAG). Sám jsem do imxRT šel přes Teensy jen proto, že si vybrali lidi držící se a propagující Arduino na katedře, kteří neumí vystoupit jinam a chtěl jsem jim ukázat alternativu. Ale nepomohlo, teď se plácají v CAN FD na Teensy na Arduinu a tak se jim snažím alespoň trochu pomoci s tím. Je to hrůza bez shellu, debugování a kód slepenec do několika "profesionálních" dodavatelů atd...
hello
na jiné jméno, třeba mytest
, a veškeré výskyty "hello" změníte v tom novém adresáři na "mytest" nebo "MYTEST", to je zachovat velikost. Jedná se o sobory (CMakeLists.txt, Kconfig, Make.defs, Makefile, hello_main.c), hello_main.c
bych ještě přejemnoval na mytest_main.c
. Nemělo by být potřeba nic registrovat, v konfiguraci se Vám objeví Vaše aplikace, povolíte jí a při konfiguraci se stratem na NSH by měla být ke spuštění z příkazové řádky. Pokud chcete později minimální sestavu, nastavíte si main jen na tu Vší aplikaci INIT_ENTRYPOINT="mytest_main"
.
Verzovat pak můžete ten vlastní form main a nebo později aplikaci vytáhnou do nějakého repozitáře mimo použít mechanismus `EXTERNALDIR`. Sám to takto neprovozuji, používám make export
a pak celý NuttX beru jako knihovnu zdroj nastavení kompilátoru pro ty větší aplikace mimo. Ale má to také své problémy, třeba na RISC-V se určité informace neexportují správě. Mám na to issue. Mám to zanalyzované, ale řešení je pozměnovat to u všech desek a tak to zatím obcházím...