Na střeše budovy Red Hatu v Brně-Medlánkách stojí krabička za pár tisíc, která dokáže to, co před dvěma lety zvládla jen profesionální infrastruktura: spolehlivě doručit zprávu přes půl republiky bez jediného mobilního operátora. Jmenuje se techpark.meshcore.cz a je to jeden z uzlů, na kterých teď stojí česká MeshCore síť.

V minulém článku jsme si vysvětlili, proč MeshCore existuje. Tohle je díl o tom, jak se do něj reálně připojit, co koupit, čeho se v české komunitě vyvarovat a proč není dobrý nápad nechávat na síti běžet vlastního pingovacího bota.

Co se za poslední čtyři měsíce změnilo

Když jsme o MeshCore psali loni v červenci, byla to spíš čerstvá zajímavost než infrastruktura. Mapa repeaterů byla řídká, návody chyběly, lidi tipovali, jestli se z toho stane další zaprášený meshtasticový pokus, nebo něco trvalejšího.

Stalo se to druhé. Mezi únorem a dubnem 2026 česká síť přerostla sama sebe. Jiří Eischmann, který má na blogu jeden z nejčtenějších českých textů o MeshCore, to popisuje jednoduše: sever Brna je tak hustě pokrytý, že mu na jednu zprávu odpoví klidně šest repeaterů najednou. Spojení Brno–Hradec Králové, které ještě v únoru chodilo jen přes jižní trasu Děvín–Hostýnské vrchy–Praděd, teď chodí severní cestou Babí lom–Orlické hory a zprávu i s potvrzením doručí během několika sekund. A když je někdo na Ještědu, dokáže paket skočit až přes Brdy – jeden hop na víc než sto kilometrů.

Síť se za tu dobu posunula i na úrovni firmwaru. Verze 1.15 vyšla 19. dubna 2026 a přinesla podporu pro Heltec V4.3, OTA aktualizace pro nRF52 desky přes mobilní aplikaci a pár změn chování, které stojí za přečtení, než člověk začne flashovat. Heltec V4.3 navíc umí ovládat FEM hardware, což komunitní buildy jako EasySkyMesh 14.1 dovedly až na 5,5 mA klidového proudu. Pro solární repeater je to zásadní detail.

A pak je tu jedna věc, která komunitu poslední tři měsíce zaměstnává nejvíc.

Kampaň 2-byte: proč si po prvním flashi musíš změnit jednu položku v menu

Když dva uzly v síti vygenerují klíče, jejichž první bajt náhodou koliduje, je problém. Cesty (path) v MeshCore se počítají z hashe veřejného klíče a jednobajtová verze umí adresovat jen 256 unikátních prefixů.

V březnu 2026 už v české síti žádné úplně volné prefixy nebyly. Síť rostla rychleji, než byl protokol původně navržený.

Řešení přišlo s firmwarem 1.14. Dvoubajtový hash sníží počet možných hopů (z 64 na 32), ale dá síti 65 535 unikátních prefixů – tedy řádově dost na to, aby kolize přestaly být problém. Česká komunita to vzala jako koordinovanou kampaň. Provozovatelé repeaterů jeden po druhém aktualizovali firmware a od konce dubna je 2B nastavení reálným standardem.

Pro koncového uživatele to znamená jednu položku v menu. Po prvním flashi otevřeš v aplikaci MeshCore Experimental Settings a Default Path Hash Size přepneš na 2 bytes. „V experimentálním nastavení si teď nastavte Výchozí velikost hashe cesty na 2b," stojí přímo na meshcore.cz. Když to zapomeneš, fungovat to bude, ale tvoje zprávy budou v menšině a u některých starších repeaterů by mohly zmizet úplně.

Takhle prozaicky se v praxi řeší škálování decentralizované sítě. Žádný governance token, žádné hlasování přes blockchain. Telegramová skupina, hlasování na Facebooku, postupný rollout.

Tři role, tři firmwary

Na rozdíl od Meshtasticu, kde přeposílá víceméně každý uzel, MeshCore strukturu sítě rozdělil na tři role. To je hlavní rozdíl mezi oběma sítěmi a důvod, proč se v reálném provozu chovají úplně jinak.

Companion je uzel, který si dáš do kapsy nebo na stůl. Přes Bluetooth (případně USB nebo WiFi, podle toho, jaký firmware nahraješ) ho spojíš s mobilem a posíláš a přijímáš zprávy. Provoz ostatních uživatelů nepřeposílá – pokud zpráva není určená tobě, companion ji ignoruje. Tím šetří éter i baterii.

Repeater je naopak součást infrastruktury, ne relé navíc. Jeho jediným úkolem je předávat pakety smysluplným směrem. Bez Bluetooth, bez displeje, často bez krytu kromě 3D tištěné krabičky. Patří na střechu, komín, vysílač nebo kopec. Solární panel, 18650 nebo LiFePO4 baterie, anténa s rozumným výhledem. Operátor si ho nakonfiguruje přes web config tool ještě před tím, než ho někam pověsí, protože jakmile je nahoře, není kam strčit USB-C.

Room Server je třetí typ. Něco jako lokální BBS pro region – uzel, který umí ukládat zprávy, sdružovat uživatele do tematických kanálů a fungovat jako store-and-forward, když je adresát zrovna mimo dosah sítě.

Role nejde přepnout konfigurací. Když chceš ze svého companionu udělat repeater, musíš ho znovu flashnout. To zní jako omezení, ale dává smysl: firmware pro každou roli je jinak optimalizovaný a komunita má jistotu, že když má někdo v síti repeater, je to opravdu repeater, a ne mobil, kterému zrovna umřela baterka.

Hardware: co reálně koupit v polovině roku 2026

Tabulka, kterou bych si přál mít, když jsem s MeshCore začínal.

K hardwaru pár poznámek z praxe, protože tabulka neřekne všechno.

Heltec V3 je pořád nejrozšířenější deska v české síti. Funguje, je levný, návodů na něj je plný Telegram. Pokud začínáš a nechceš řešit detaily, vezmi Heltec V3 nebo V4 v EU variantě (868 MHz, ne 915 MHz – ten je pro USA a v české síti nezachytí nic).

T-Deck je jiná liga. Pro lidi, co chtějí mít komunikaci úplně mimo telefon – na hory, do auta na dlouhé tahy, nebo prostě jako koncept „vlastní pager bez internetu". Pořád stojí kolem 3500 Kč, ale když k tomu přidáš baterii a pořádnou anténu, cena se snadno přehoupne přes pět litrů.

A SenseCAP Solar Node P1 Pro je teď v české komunitě nejcitovanější volba pro hotový repeater. Eischmann o něm píše: „Úplně se mi nechtělo bastlit vlastní řešení, takže jsem zvolil ověřené hotové řešení SenseCAP Solar Node P1 Pro." Pět tisíc je dost peněz na to, aby ses k nákupu rozhoupal, ale když jde o střechu rodinného domu, kde má mít spojení tvůj soused i ty, je to investice, která se vrátí.

BOM pro vlastní solární repeater (DIY varianta, ~1700 Kč)

Pro úplnost, kdyby ti to nedalo a chtěl bys ho postavit.

Zhruba takhle vypadá rozumný DIY repeater postavený na Heltecu, který přežije i bez sítě:

• Heltec V3 (EU 868 MHz) – 750 Kč
• LiFePO4 článek 18650, 1500 mAh – 250 Kč (pozor na firmware ≥ 1.12, kde byly s LFP/LTO články hlášené problémy s napěťovou křivkou)
• TP4056 modul s ochranou – 30 Kč
• 6V/5W solární panel – 200 Kč (zimní slunce v ČR je nízké a krátké, dimenzuj radši s rezervou)
• LoRa anténa 868 MHz, zisk 3–5 dBi – 200 Kč
• Pigtail SMA / IPEX – 60 Kč
• 3D tištěná krabička – pár desítek korun za filament
• IP65 průchodka pro anténní kabel – 80 Kč
• Spojovací materiál, dlaždice, držák – podle situace

Cena pohodlně pod dva tisíce, pokud máš tiskárnu doma. Když kupuješ všechno nové a tiskneš v servisu, přidej k tomu pár stovek za filament a držák antény.

Frekvence a nastavení regionu pro ČR

Tohle bývá první past pro lidi, co začínají. MeshCore v Evropě obecně jede na pásmu 868 MHz, ale česká komunita se sjednotila na konkrétním presetu, který se ne vždycky shoduje s výchozím nastavením „EU" v aplikaci. Konkrétně: frekvence 869,432 MHz, šířka pásma 62,5 kHz, spreading factor 7, coding rate 5, vysílací výkon 22 dBm.

Co to znamená v praxi: vysíláš na bezlicenčním pásmu, žádné poplatky, žádná registrace. Ale musíš respektovat duty cycle limit 1 % – tedy ze sta sekund vysílat nejvýš jednu. Firmware to hlídá sám, ale když si pustíš na síti bota, který každé tři minuty odešle status update, ten limit ti tiše vyžere a tvoje skutečné zprávy se přes něj nedostanou.

A teď k tomu botovi.

Etiketa: žádné automaty, žádné scrapery

Česká MeshCore komunita má jedno pravidlo, které visí přímo na úvodní stránce meshcore.cz a v každém druhém příspěvku na Telegramu. „Síť budujeme striktně pro komunikaci mezi lidmi (keyboard to keyboard). Vyvarujte se automatizovanému posílání zpráv, vyčítání repeaterů nebo jiné komunikaci, která není mezi lidmi!"

Důvod je matematický. LoRa síť má reálnou propustnost zhruba tří kilobitů za sekundu. To není opomenutí, to je fyzika daná modulací. Komunita po hlasování konstatovala, že 75 % generovaného provozu tvořili boti, což snižuje pravděpodobnost doručení skutečných zpráv. Vznikla z toho samostatná kampaň: provozovatelé botů se mají vypnout. Jediný, kdo tam má povolení zůstat, je El Pong – komunitní bot s AI a emailem, který si komunita schválně nechala jako experiment.

Když si tedy zapneš svůj první uzel a napadne tě napsat skript, který bude každou hodinu pingovat dosah, prostě to nedělej. Není to vůči nikomu fér.

Totéž platí pro scrapery a „monitory pokrytí". Existuje veřejná mapa i analyzer, oba běží na backendu, kde tu zátěž nese server, ne LoRa éter. Když si chceš zmapovat vlastní dosah, projdi se s companionem a koukej do aplikace. Žádný autopilot.

Krok za krokem: od krabičky k první zprávě

Předpokládejme Heltec V3 v EU 868 MHz verzi, Android telefon a Chrome v notebooku.

Připoj desku přes USB-C k počítači. Pozor na kabel – některé „nabíjecí" mají jen napájení a žádná data, a flasher se ti k čipu nedostane. Když to nepřipojí, zkus jiný kabel dřív, než začneš googlovat ovladače.

Otevři flasher.meshcore.co.uk v Chromu (nebo jiném prohlížeči postaveném na Chromiu – Edge funguje, Firefox bohužel ne, protože nemá Web Serial API). Po načtení vyber model desky. Pro Heltec V3 zvol Community Firmware a roli Companion Bluetooth. Stiskni Flash. Asi po půl minutě má deska firmware.

Stáhni si aplikaci MeshCore – existuje pro Android i iOS. Po spuštění klepni na „přidat zařízení" a aplikace najde tvůj uzel přes Bluetooth. Spárování chce PIN, který se ti zobrazí na OLED displeji.

První věc, kterou pak v aplikaci uděláš (ano, ještě před tím, než pošleš první zprávu): otevři Experimental Settings a přepni Default Path Hash Size na 2 bytes. To je ta kampaň, o které jsem psal výš. Pak nastav region – pro Česko buď použij preset EU Recommended, nebo manuálně nastav 869,432 MHz / BW 62,5 kHz / SF 7 / CR 5.

Teď klepni v aplikaci na ikonu vlny (advert) a pošli Flood Routed Advert. To je signál „jsem tady, kdo mě slyší". V Contacts by se ti během následujících sekund až minut měly začít objevovat repeatery a uživatelé v dosahu. Když ne, vystup na balkon nebo zkus jít k oknu. LoRa není WiFi a na úrovni ulice mezi paneláky se jí obvykle moc nedaří.

Pošli testovací zprávu do kanálu #test. Pokud uvidíš v aplikaci „Heard X repeat(s)", jsi v síti. Hotovo.

Linuxový klient Meshy: alternativa pro lidi, co nechtějí mobil

Pokud jsi typ člověka, co radši pracuje na notebooku než na mobilu, je tu pro tebe Meshy. Linuxový klient pro MeshCore, který od února 2026 píše Jiří Eischmann. Aplikace má dokonce funkce, které oficiální klient zatím nemá – třeba vykreslení trasy poslední úspěšné zprávy přímo na mapě v chatu.

Meshy se aktuálně distribuuje přes Flatpak repozitář a každý commit do gitu spouští nový build pro x86_64 i aarch64 (díky Roští.cz za poskytnutí builderu). Eischmann teď cílí na publikaci ve Flathubu – hlavní překážka prý je, že kvůli udev pravidlu pro připojení companionu přes USB potřebuje obejít sandbox pomocí flatpak spawn. Časem to vyřeší. Komunita kolem linuxového klienta roste a Meshy je teď nejstabilnější varianta, pokud chceš MeshCore používat z laptopu.

Pro lidi z radioamatérské scény, kteří už znají RTL-SDR, gpredict a další unixové utility, je Meshy přirozenější než přepínání mezi mobilem a notebookem. V brněnské komunitě je to čím dál jasnější volba.

Brno jako centrum české MeshCore scény

Když si zmapuješ aktivitu české komunity, jihomoravský trojúhelník vyčnívá. Většina nejaktivnějších provozovatelů sítě sedí v Brně. Jindřich Skácel měl v únoru 2026 přednášku na 216. srazu spolku OpenAlt na FIT VUT, ukazoval klientská zařízení a praktické nasazení repeateru, video je na vhsky.cz. Na budově Red Hatu v Medlánkách přímo běží repeater techpark.meshcore.cz, který kryje větší část severu Brna.

Není to náhoda. Brno má kombinaci, která MeshCore přeje: hustá technická komunita (Red Hat, FIT VUT, SUSE, NIC.CZ), aktivní open-source scéna kolem OpenAltu, prolínání ham a maker komunity a topologie s viditelností na okolní kopce (Babí lom, Děvín, Hostýn).

Eischmann to v jednom blogu trefil přirovnáním ke CZFree.Netu z přelomu nultých let – komunita, která bere infrastrukturu do svých rukou, protože ji to baví, ne protože musí.

Pokud bydlíš v Brně nebo okolí a chceš se připojit, je to teď nejjednodušší. Telegramová skupina meshcore_cz má aktivní topic Wiki a Repeatery, srazy OpenAltu v Red Hat Labu na FIT VUT chodí pravidelně každý třetí pátek v měsíci (i když ne každý je o MeshCore) a v Brně máš největší šanci potkat lidi, kteří síť reálně staví.

Jiné regiony pochopitelně taky fungují. Praha má pokrytí, Hradec a Liberec mají své sysopy, jižní Čechy mají svou skupinku. Ale hustota brněnské sítě v polovině roku 2026 je v republice unikum a kdyby ses chtěl podívat, jak vypadá MeshCore, když má kritickou masu, stojí za to si sem na jeden pátek vyrazit a vidět to z první ruky.

Co dál

Když máš companion v kapse a fungující spojení do sítě, je to první krok. Logické pokračování je vlastní repeater. Pokud bydlíš výš nebo máš střechu, je to nejspíš něco, co tvoje okolí ocení. Eischmannovi přes zimu umřely baterky na repeateru ivanovice.meshcore.cz, který byl 300 metrů od něj, a najednou byl bez spojení. Jeho ponaučení: „když závisíte na repeaterech ostatních, měli byste mít spojení alespoň na dva. Nebo mít vlastní." Síť odolnou proti blackoutu nepostavíš tím, že čekáš na sysopa o tři ulice dál.

Před tím, než si pořídíš hardware na repeater, vygeneruj si přes Key Generator vlastní prefix klíče. V březnu 2026 už volné jednobajtové prefixy nebyly. Při 2-byte hashi je situace lepší, ale stejně si zkontroluj v analyzeru, jestli zrovna tvůj generovaný prefix neběží už ten den někomu přes ulici.

A pokud chceš jít dál než ke klasickým textovkám – existuje GROUP_DATA, binární typ paketu, který firmware 1.15 přinesl pro pokročilejší aplikace. Telemetrie, řízení vzdálených zařízení, integrace s domácí automatizací. Část komunity tudy už šlape, v Brně víc, v ostatních městech méně.

Co MeshCore není a co se nestane: nikdy z toho nebude bezdrátový internet, nikdy nebude pohánět videohovory, nikdy nezvládne přenášet fotky v rozumném čase. To je v pořádku. Stačí, že umí to, co lidi v Karpatech, na chatě v Beskydech nebo v zatopeném Bohumíně skutečně potřebují: krátkou textovku, která projde, i když všechno ostatní leží.

A taková síť se buduje úplně stejně, jako se před třiceti lety budoval CZFree.Net. Po jednom uzlu, po jedné krabičce, po jedné neděli na střeše.

The post MeshCore v praxi: jak v Česku postavit vlastní LoRa uzel a nezapadnout first appeared on Hard Wired.

Kryptografické útoky na RC522 a MIFARE čipy

RC522 a MIFARE Classic čipy, nasazené v miliardách zařízení po celém světě, představují jeden z nejvýznamnějších případů selhání kryptografické bezpečnosti v moderních dějinách. Proprietární šifra Crypto1, která byla po 14 let utajována, obsahuje fundamentální slabiny umožňující rychlé kompromitování všech sektorových klíčů. Tento článek poskytuje podrobnou technickou analýzu šesti hlavních typů útoků, jejich implementace a obranných opatření.

Výzkum ukazuje, že 95% původních MIFARE Classic karet lze kompromitovat během 10-30 minut pomocí běžně dostupného hardware za méně než 10 000 Kč. Navzdory pokusům o vylepšení v podobě MIFARE Classic EV1, základní architektonické problémy zůstávají nevyřešené. Pro organizace používající tyto systémy představuje jejich nasazení úplnou kompromitaci bezpečnosti vyžadující okamžitou migraci na kryptograficky bezpečné alternativy.

Technické základy RC522 a MIFARE architektury

Architektura RC522 čtečky

MFRC522 (běžně označovaný jako RC522) je vysoce integrovaný bezkontaktní čtecí/zapisovací obvod od NXP Semiconductors pracující na frekvenci 13.56 MHz. Klíčové specifikace zahrnují napájecí napětí 2,5-3,6V, komunikační rozhraní SPI (až 10 Mbit/s), I²C (až 3,4 Mbit/s) a UART (až 1228,8 kBd), a 64-bajtový obousměrný FIFO buffer pro zpracování dat.

Digitální architektura obsahuje bezkontaktní UART pro zpracování protokolu, 16-bitový CRC koprocesor s polynomem x¹⁶ + x¹² + x⁵ + 1, programovatelnou časovací jednotku s 12-bitovým předděličem a generátor pseudonáhodných čísel. Kriticky důležitá je ověřovací jednotka MIFARE Classic s podporou Crypto1, která implementuje celý ISO/IEC 14443-A protokolový zásobník.

Struktura paměti MIFARE Classic

MIFARE Classic karty využívají EEPROM paměť organizovanou hierarchicky. Verze 1K obsahuje 1024 bajtů organizovaných do 16 sektorů po 4 blocích, kde každý blok má 16 bajtů. Použitelné úložiště činí pouze 752 bajtů po odečtení systémových bloků.

Každý sektor obsahuje datové bloky (0-2) a sektorový trailer (blok 3) s rozložením: Key A (6 bajtů), přístupové bity (4 bajty), Key B (6 bajtů). Výchozí klíče jsou nastaveny na 0xFFFFFFFFFFFF, což představuje zásadní bezpečnostní riziko v nenastavených systémech.

Šifra Crypto1 a její zranitelnosti

Crypto1 je proprietární proudová šifra skládající se z 48-bitového lineárního zpětnovazebního posuvného registru (LFSR) s polynomem obsahujícím 16 termů, dvouvrstvé 20-na-1 nelineární filtrační funkce a 16-bitového LFSR pro generování pseudonáhodných čísel během autentifikace.

Kritické kryptografické chyby zahrnují inherentně lineární design LFSR zranitelný vůči algebraickým útokům, pouze 48-bitové klíče výpočetně proveditelné k hrubému prolomení, předvídatelný PRNG používající předvídatelné počáteční podmínky, a možnost obnovení stavu prostřednictvím časové analýzy.

MFKEY32 V2 útok

Algoritmická implementace a matematické základy

MFKEY32 V2 vykořisťuje slabý PRNG v MIFARE Classic kartách analýzou šifrovaných nonce shromážděných během pokusů o autentifikace mezi kartou a legitimní čtečkou. Matematickým základem je struktura 48-bitového LFSR Crypto1 a slabina PRNG používající 16-bitový LFSR, kde znalost jedné poloviny determinuje druhou.

Klíčové rozdíly oproti MFKEY32 V1 spočívají v eliminaci časových omezení - pokusy o autentifikace mohou probíhat v různých časech, což poskytuje flexibilnější implementaci s vyššími míry úspěšnosti.

Implementační workflow

Útok probíhá ve čtyřech fázích: Kolekce nonce - emulace cílové karty pro zachycení čtečkových nonce během autentifikace, analýza dat - extrakce šifrovaných nonce {nT} a paritních bitů z komunikace, rekonstrukce LFSR - výpočet možných stavů LFSR generujících pozorované nonce, a obnova klíče - zpětný chod LFSR do počátečního stavu obsahujícího autentifikační klíč.

Požadované pokusy o autentifikaci: Minimum 2 pokusy (nemusí být po sobě jdoucí), optimálně 4-8 pokusů pro vyšší míru úspěšnosti. Míra úspěšnosti: 85-95% na standardních kartách, snížená na 30-50% u zpevněných karet kvůli vylepšenému PRNG.

Hardware a software požadavky

Proxmark3 RDV4: 2-5 sekund na klíč, cena €200-300. ACR122U: 30-60 minut kvůli pomalejší komunikaci, cena €30-50. Chameleon Ultra: srovnatelná s Proxmark3 pro kolekci, cena €80-120.

Časová náročnost zahrnuje fyzické požadavky: těsná blízkost cílové karty (1-4cm), výpočetní požadavky: moderní procesor s 256MB RAM minimum, čas: 10 sekund až 5 minut pro obnovu klíče v závislosti na hardware.

Darkside útok

Princip a metodika obnovy klíčů

Darkside útok vykořisťuje postranní kanál v autentifikačním zpracování chyb MIFARE Classic, konkrétně šifrované NACK (Negative Acknowledgment) odpovědi. Karta ověří paritu → správná (8 bitů), ověří autentifikaci → nesprávná (špatné aR), odpověď: 4-bitové NACK šifrované keystream.

Technický proces exploitace

Útok probíhá v šesti krocích: počáteční autentifikace - odeslání auth příkazu cílovému sektoru, kolekce nonce - příjem karty nonce nT (32 bitů), parití útok - generování čtečky nonce nR se správnými paritními bity, odeslání šifrované {nR, aR} s úmyslně špatnou aR hodnotou, exploitace NACK - extrakce 4 keystream bitů: ks = NACK_plaintext ⊕ NACK_encrypted, iterace - opakování s různými nT hodnotami pro shromáždění ~32 keystream bitů, a obnova klíče.

Metriky výkonu: Kolekční fáze 5-30 minut v závislosti na kartě a hardware, výpočetní fáze 1-10 sekund pro obnovu klíče, míra úspěšnosti 90-95% na zranitelných kartách (před-EV1), průměrně ~300 pokusů o autentifikaci.

Praktické omezení

Hardwarové závislosti: Proxmark3 typicky 5-15 minut, ACR122U 30-60 minut kvůli pomalejší komunikaci, PN532 15-45 minut s správnou časovou konfigurací. Detekce a omezení: EV1 karty mají opravenou NACK zranitelnost (0% úspěšnost), čínské klony často více zranitelné (95% úspěšnost).

Nested útoky

Klasický Nested útok

Matematickým základem je slabina Crypto1 proudové šifry a předvídatelný PRNG v původních MIFARE Classic kartách. Crypto1 používá 48-bitový LFSR s tendenčními filtračními funkcemi, PRNG používá pouze 16-bitový LFSR s předvídatelným počátečním stavem, LFSR se resetuje do známého stavu při zapnutí, což činí nonce předvídatelnými prostřednictvím časování.

Útok: Autentifikace se známým klíčem produkuje první nonce (Nt1), vnořená autentifikace do neznámého sektoru produkuje šifrované nonce ({Nt2}), časová analýza umožňuje predikci plaintext Nt2, XOR operace: {Nt2} ⊕ Nt2 = 32 bitů keystream, zpětný chod LFSR z jakéhokoli vnitřního stavu pro obnovu 48-bitového klíče.

StaticNested útok

StaticNested útoky cílí karty se statickými šifrovanými nonce - protiopatření, které se obrátilo proti sobě tím, že učinilo útoky jednodušší. Někteří výrobci implementovali statické nonce v domnění, že zabrání vnořeným útokům, ale statické šifrované nonce lze sbírat a analyzovat bez časových omezení.

Výzkum Quarkslab (2024) objevil hardwarové zadní vrátka v Fudan FM11RF08S kartách s univerzálním zadním vrátkem: společný napříč všemi FM11RF08S kartami, implementace statických šifrovaných nonce ve skutečnosti činí útoky efektivnějšími.

HardNested útok

HardNested útok (vyvíjen Carlo Meijer a Roel Verdult, 2015) představuje významný pokrok, ale přichází se značnou složitostí. Jedná se o první útok pouze na šifrový text na zpevněné MIFARE Classic karty, funguje proti kartám s řádnými PRNG (MIFARE Classic EV1, SmartMX), využívá pouze kryptografické slabiny v Crypto1, nikoli implementační chyby.

Technický přístup má tři fáze: Shromáždění šifrovaných nonce prostřednictvím vnořené autentifikace, určení sumových vlastností stavů vnitřní šifry pomocí statistické analýzy, generování seznamu kandidátských klíčů a provedení cílené hrubé síly. Používá sumovou analýzu vlastností k redukci vyhledávacího prostoru z 2⁴⁸ na ~2³⁰, využívá hypergeometrické distribuce pro pravděpodobnostní analýzu.

Současný stav implementace: Plná implementace existuje v Proxmark3 RRG firmware, vyžaduje významnou RAM (1,2GB+) pro ukládání a analýzu nonce, GPU akcelerace (bitsliced) redukuje čas útoku na 5-10 minut.

Relay útoky

Principy relay útoků

Relay útoky využívají základní předpoklad, že blízkost znamená bezpečnost, což umožňuje útočníkům rozšířit komunikační rozsahy a obejít autentifikační systémy bez prolomení šifrování. Útok se skládá z mole zařízení umístěného poblíž oběti karty/štítku, proxy zařízení umístěného poblíž cílové čtečky, a komunikačního kanálu spojujícího obě zařízení.

Implementace v MIFARE kontextu

MIFARE Classic je obecně odolný vůči relay útokům kvůli přísným časovým požadavkům, zranitelný vůči jiným útokům (kryptografické slabiny, obnova klíčů). MIFARE DESFire EV1 je zranitelnější vůči relay útokům, podporuje rozšíření vzdálenosti až na několik metrů, úspěšně demonstrován v kontrolovaných prostředích.

Technické nastavení zahrnuje Proxmark3 platformu pro průmyslový standard RFID výzkumu a útoků, řešení založená na smartphonech s Android telefony s NFC schopností, vlastní hardware s PN532, PN533 čipsety, specializované relay nástroje za $100-1000.

Detekce a prevence

Distance bounding protokoly měří round-trip time (RTT) výměn challenge-response, odhadují maximální vzdálenost na základě rychlosti světla, detekují neobvyklá zpoždění indikující přítomnost relay. Environmentální podmínky zahrnují snímání teploty, magnetometry pro čtení, okolní hluk, fyzickou interakci tlačítkem.

Srovnávací analýza útoků

Účinnost a časová náročnost

Darkside útok vykazuje téměř 100% úspěšnost na zranitelných kartách s časem 5-30 sekund, nevyžaduje žádné předpoklady, ale nefunguje na zpevněných kartách. MFKEY32 V2 dosahuje 85-95% úspěšnosti na standardních kartách s časem 10 sekund až 5 minut, vyžaduje emulaci karty pro sběr nonce.

Klasický Nested má 95%+ míru úspěšnosti s časem sekundy až minuty na sektor, vyžaduje alespoň jeden známý klíč. HardNested dosahuje 80-90% úspěšnosti s časem 15-25 minut celkem, vyžaduje jeden známý klíč plus významné výpočetní zdroje.

Hardware požadavky a dostupnost

Premium tier zahrnuje Proxmark3 RDV4 za $270 a iCopy-X za $400-500. Střední třída obsahuje Chameleon Ultra za $120-130 a Flipper Zero za $170. Rozpočtové možnosti nabízejí ACR122U za $40-60 a čínské Proxmark klony za $50-80 (nedoporučované).

Obranná opatření a detekce

Detekce na straně čtečky zahrnuje monitoring neobvyklých autentifikačních vzorů, časovou analýzu rychlých pokusů o autentifikaci, monitoring míry chyb s vysokou mírou NACK odpovědí. Protiopatření na úrovni karty obsahují vylepšení PRNG (MIFARE Classic EV1), potlačení NACK odpovědí, časové limity autentifikace, diverzifikaci klíčů.

Praktické aspekty implementace

Nástroje a konfigurace

Software nástroje zahrnují mfoc (MIFARE Classic Offline Cracker) pro implementaci "offline nested" útoku, mfcuk (MIFARE Classic Universal toolKit) pro implementaci Darkside útoku, libnfc verze 1.7.1+ pro nízkoúrovňovou NFC komunikaci, crapto1 knihovnu pro implementaci šifry Crypto-1.

Proxmark3 příkazy:

hf search          # Základní detekce karty
hf mf mifare       # Darkside útok
hf mf nested       # Nested útok
hf mf hardnested   # Hardnested útok
hf mf autopwn      # Automatizovaná sekvence útoků

Časové a výpočetní požadavky

Sběr dat typicky vyžaduje 2-10 sekund blízkosti karty, stabilní RF pole během sběru nonce, schopnost emulovat odpovědi karty čtečce. Výpočetní fáze potřebuje moderní procesor (1-2 jádra dostačující), 256MB RAM minimum pro ukládání kandidátů, čas 10 sekund až 5 minut pro obnovu klíče.

Právní úvahy a etické směrnice

Právní požadavky zahrnují písemné povolení povinné před jakýmkoli testováním, definici rozsahu s jasnými hranicemi a omezeními, pravidla zapojení s detailními parametry testování. Zakázané aktivity obsahují neautorizovaný přístup, klonování karet, finanční podvody, narušení soukromí.

Bezpečnostní doporučení

Okamžitá opatření

Hodnocení rizik vyžaduje okamžité bezpečnostní posouzení RFID systémů, implementaci dalších autentifikačních vrstev kde je to možné, monitoring neobvyklých autentifikačních vzorů, zvážení těchto útoků v modelování hrozeb.

Systémová bezpečnost zahrnuje správu whitelistů s databázemi schválených UID, behaviorální analýzu pro monitoring neobvyklých přístupových vzorů, multi-faktor autentifikaci kombinující RFID s PIN/biometrickou verifikací, monitorování síťové bezpečnosti pro detekci rapidních pokusů o autentifikaci.

Dlouhodobá migrace

Bezpečné alternativy zahrnují MIFARE DESFire EV2/EV3 s AES-256 šifrováním, MIFARE Plus se zpětnou kompatibilitou a AES-128 bezpečností, kompletní upgrade infrastruktury s výměnou všech karet a čteček. Kvantově odolné řešení začínají být dostupná pro dlouhodobou bezpečnost.

Závěr

RC522/MIFARE Classic ekosystém představuje studii selhání bezpečnosti skrze utajení. Navzdory rozšířenému nasazení činí fundamentální kryptografické slabiny v šifře Crypto1 tyto systémy zcela nevhodné pro jakékoli bezpečnostně citlivé aplikace.

Kombinace lineárního designu šifry, slabé správy klíčů a předvídatelných protokolových toků vytváří mnohočetné vektory útoků, které byly rozsáhlé zdokumentovány a vykořisťovány od roku 2008. Organizace používající MIFARE Classic systémy čelí úplné kompromitaci bezpečnosti a měly by upřednostnit migraci na kryptograficky bezpečné alternativy.

Výzkum pokračuje ve vývoji pokročilejších útočných technik i obranných opatření. Kvantové výpočty a AI/ML detekční systémy představují budoucí směry jak pro útočníky, tak obránce. Pro bezpečnostní specialisty je kritické udržovat si aktuální znalosti těchto vyvíjejících se hrozeb a implementovat proaktivní obranné strategie.

Klíčová doporučení zahrnují okamžité posouzení všech RFID systémů v infrastruktuře, implementaci dodatečných bezpečnostních vrstev, plánování migrace na moderní standardy s kvantově odolnou kryptografií, a vytvoření kontinuálních monitorovacích procesů pro detekci potenciálních útoků. Pouze proaktivní přístup k těmto fundamentálním bezpečnostním slabinám může chránit kritické systémy před stále se vyvíjejícími hrozbami.

The post Kryptografické útoky NFC first appeared on Hard Wired.

ESP32: Backdooru v populárním čipu

Úvod

V posledních dnech se odbornou i laickou veřejností šířily znepokojivé zprávy o možném backdooru v čipu ESP32 od čínské společnosti Espressif. Vzhledem k tomu, že těchto čipů bylo celosvětově distribuováno přibližně miliarda kusů a nacházejí se v širokém spektru IoT zařízení, vyvolala tato informace značné obavy. Následující analýza objasňuje, co se skutečně zjistilo a proč se nejedná o závažné bezpečnostní riziko.

Co je ESP32?

ESP32 představuje tzv. "system on chip" (SoC) - kompletní mikrokontrolér integrovaný v jediném čipu o rozměrech přibližně 8×8 mm. Při maloobchodní ceně kolem 50 Kč nabízí mimořádný výkon a funkcionalitu:

• Velké množství vstupně-výstupních (GPIO) pinů pro připojení senzorů a ovládacích prvků
• Integrovanou podporu Wi-Fi a Bluetooth pro snadné připojení do sítě
• Podporu komunikačních standardů jako SPI, I2C, CAN-BUS a další
• Vynikající dokumentaci a vývojářskou podporu
• Příznivý poměr cena/výkon

Díky těmto vlastnostem se ESP32 stal dominantním čipem v oblasti IoT zařízení, chytrých domácností a řady dalších aplikací. Jeho hlavními konkurenty jsou některé čipy od Texas Instruments a pravděpodobně Raspberry Pi Pico 2TV.

Co bylo skutečně objeveno?

Na konferenci Rootcon konané 6.-8. března v Madridu prezentovali dva španělští výzkumníci objev nedokumentovaných příkazů v čipu ESP32. Tyto příkazy umožňují provádět některé nízkoúrovňové operace jako zápis do paměti nebo odesílání specifických Bluetooth paketů.

Je důležité zdůraznit, že existence nedokumentovaných příkazů je v hardwarových i softwarových řešeních běžná. Většina komplexnějších systémů obsahuje interní pomocné rutiny a metody, které nejsou určeny pro koncové uživatele, ale slouží k vnitřnímu fungování systému, ladění a podobným účelům.

Proč se nejedná o bezpečnostní riziko?

Klíčovým faktem je, že k využití těchto nedokumentovaných příkazů musí mít útočník již plnou kontrolu nad zařízením. To znamená:

1. Fyzický přístup k zařízení - Pro nahrání vlastního kódu do ESP32 je často nutné zařízení fyzicky rozebrat a připojit se k UART pinům na základní desce.

2. Překonání bezpečnostních mechanismů - ESP32 umožňuje implementaci kontroly digitálního podpisu firmware, kdy čip odmítne spustit kód, který není podepsán správným klíčem.

3. Harvardská architektura jako ochrana - Na rozdíl od běžných počítačů s von Neumannovou architekturou používá ESP32 harvardskou architekturu s oddělenou pamětí pro kód a data, což znesnadňuje spuštění škodlivého kódu.

Jak došlo k nedorozumění?

Společnost Tarlogic, mateřská organizace zmíněných výzkumníků, vydala původně bombastickou tiskovou zprávu hovořící o "ohrožení stovek milionů IoT zařízení". Tuto zprávu převzal server Bleeping Computer, který v titulku navýšil počet potenciálně ohrožených zařízení na miliardy. Následně se informace lavinovitě šířila dalšími médii.

Po bližším prozkoumání problematiky byly původní články staženy a přeformulovány, aby lépe odrážely skutečnou závažnost situace. Nicméně, původní senzační zprávy už stihly vyvolat značné obavy.

https://www.tarlogic.com/news/hidden-feature-esp32-chip-infect-ot-devices/
https://www.bleepingcomputer.com/news/security/undocumented-commands-found-in-bluetooth-chip-used-by-a-billion-devices/

Závěr

Používání čipu ESP32 je nadále bezpečné. Přítomnost nedokumentovaných příkazů nepředstavuje sama o sobě bezpečnostní riziko, protože k jejich využití je nutná plná kontrola nad zařízením, což by útočníkovi umožnilo i mnohem závažnější zásahy do systému bez ohledu na existenci těchto příkazů.

Bezpečnost zařízení s ESP32 závisí primárně na kvalitě jejich návrhu:

• Zařízení, která byla navržena s důrazem na bezpečnost, zůstávají bezpečná i nadále
• Zařízení s bezpečnostními nedostatky byla zranitelná již před tímto objevem

Uživatelé zařízení s ESP32 mohou tedy pokračovat v jejich používání bez obav a vývojáři mohou nadále implementovat tento čip do svých konstrukcí.

The post ESP32 neobsahuje backdoor first appeared on Hard Wired.

V dnešním článku si ukážeme, jak vytvořit signalizační světlo napojené na Home Assistant.

Článek ukazuje možnost, jak vyrobit zařízení, které je připojené k elektrické síti. S tím jsou spojena určitá rizika. Článek je čistě informativní. Výroba a použití jsou na vašem uvážení a odpovědnosti.

Motivace

Mám klasická, na dálku ovládaná garážová vrata. Potřeboval jsem nějakým způsobem monitorovat, zda jsou otevřená. Po vyzkoušení několika levných bezdrátových (bateriově napájených) čidel jsem zjistil, že zpravidla nepřežijí zimu. Proto jsem použil klasický magnetický spínač, natáhl dráty až do Wemos D1 Mini a tak informuji Home Assistant o stavu garážových vrat.

Celý modul je uzavřený v elektroinstalační krabici, kde je Wemos, trafo, relé a žárovka. Pokud se vrata otevřou, relé začne zapínat a vypínat červenou žárovku, která bliká. Tím se upozorní ostatní členové domácnosti, že jsou vrata otevřená. A tady začíná problém. Modul je s čidlem spojený drátem, což určuje jeho pozici, a není možné s ním hýbat. Vzhledem ke členitosti domu není signalizace vždy dostatečně efektivní.

Rozhodl jsem se vytvořit malé signalizační světlo, které lze umístit kamkoliv, kde je zásuvka.

Ano, mohl bych si koupit nějakou chytrou žárovku, která je kompatibilní s Home Assistant. Ale to už není DIY Nemohl bych si udělat vlastní design a už by to nebyla taková zábava.

Očekávání

• Funguje všude, kde je Wi-Fi.
• Je to levné, snadno a rychle vyrobitelné, takže je mohu strategicky rozmístit po domě.
• nemá to vyloženě odpudivý design

Požadavky

• Home Assitant + ESP Home rozšíření
• 3D Tiskárna
• DIY svářečka aka tavná pistole
• sada na pájení a lehce skill

Komponenty

Wemos D1 Mini je konkrétně pro tento případ ideální. Jinak mohu klidně použít ESP32 Dev Kit nebo cokoliv kompatibilního s ESP Home. U Lásky je za 128 CZK, na AliExpressu to jde najít za cca 2 USD.

WS2812B 8x LED 5V pásek je ve skutečnosti PCB s osmi adresovatelnými LED. U Lásky je za 28 CZK, na AliExpressu za necelý 1 USD.

Trocha drátu. Netuším náklady, já jednou rozebral asi 5 starých AT/ATX zdrojů a mám zásobu krátkých drátků asi na pár let dopředu.

3D tištěná krabička sežere asi 33 g filamentu. Když vezmeme trošku dražší Průšův Prusament PLA Pristine White za 799 CZK za 1 kg, vyjde nás krabička asi na 26 CZK + hoďka tisku. Při ceně 500 CZK za 1 kg jsme už na 17 CZK.

Micro USB kabel. U Lásky za 28 CZK.

Napájecí zdroj 5V 1A. Když chceme "vyhořet", tak třeba na Allegro za 29 CZK. Ale dají se najít za rozumnou cenu do 50 CZK. Když ještě fungovalo CZC (nechť odpočívá v pokoji), koupil jsem velice levné nabíječky, otestoval je na umělé zátěži a všechny splnily předepsané parametry.

U Lásky to jde všechno koupit za 300 CZK (započítaná i 3D tištěná krabička, bez poštovného). Z Lidové Demokratické Republiky to může vyjít na 190 CZK i s krabičkou a poštovným. Ale určitě bych si dával pozor na ty nabíječky.

Pravdou ovšem je, že pokud doma něco trochu kutíte, většinu věcí už stejně máte doma.

3D Tištěná Krabička

Krabička se skládá ze dvou dílů: základny a stínítka (návleku). Je navržená na jednoduchý tisk bez supportů. Rozměry stínítka jsou optimalizovány na tisk ve Fuzzy Skin módu pro všechny stěny. Pokud nebude stínítko vytištěno jako Fuzzy Skin, bude příliš volné a nebude dobře držet.

Mechanika je naprosto primitivní: do základny se umístí elektronika a nasune se stínítko. Jednoduché a funkční.

Sestavení

Nachystáme si Wemos, LED modul a naměříme tři dráty, aby nám to pěkně vyšlo. Červený drát napájíme do Wemos 5V pinu a do VCC LED modulu. Černý drát připojíme do Wemos GND pinu a GND LED modulu. Pak libovolnou barvu připojíme do Wemos D5 (GPIO 14) pinu a DI (data in) LED modulu. Můžeme klidně zvolit jiný vhodný Wemos GPIO, ale musíme to zohlednit následně při konfiguraci.

Jak máme dopájeno, usadíme elektroniku do základny a připevníme ji pomocí tavné pistole. Osvědčil se mi následující postup:

• Vložíme elektroniku do základny.
• Upravíme dráty, aby se všechno pěkně vešlo.
• Připojíme přes otvor v krabičce micro USB, tím si vše trochu zafixujeme a víme, že půjde USB zapojit.
• Následně zvednu Wemos, dám pod něj trochu tavného lepidla a usadím ho na místo.
• Chvíli přidržím, až to zatuhne; takto budu mít jistotu, že to neujede a vždy se tam s micro USB kabelem dostanu.
• Až je Wemos pevně uchycený, pomocí tavné pistole uchytím LED modul.

Upozornění: Zařízení je myšleno jako signalizační. To znamená, že signalizuje (je rozsvíceno) jen po dobu nezbytně nutnou, krátkou. Není to myšleno jako lampička. LEDky umí pěkně zatopit a vše je připevněno jen tavnou pistolí. Mějte to na paměti.

Instalace

Připojíme zařízení pomocí USB k počítači. Musíme na zařízení nainstalovat firmware, aby ho mohl Home Assistant adoptovat. Web https://web.esphome.io/ nám s tím pomůže. Budeme ale potřebovat prohlížeč, který podporuje Web Serial API, takže Chrome, Brave, atd.

Dáme "Connect".

V našem případě je to COM8. Po výběru zařízení zvolíme „Připravit pro první spuštění“.

A potvrdíme instalaci.

Začne se instalovat firmware.

Následně budeme vyzváni k nastavení Wi-Fi.

Nastaví a připojí zařízení na nastavenou Wi-Fi. Základní instalace je dokončena.

Na zařízení od teď funguje jednoduchý webový server, který zobrazuje například výpis z konzole.

Když přejdeme do Home Assistant do ESP Home, uvidíme, že detekoval nové zařízení.

Zařízení můžeme adoptovat.

Potvrdíme, že chceme nainstalovat konfiguraci na zařízení.

Můžeme sledovat průběh kompilace a instalace firmwaru. Všechno se děje přes OTA.

Změny můžeme sledovat přes webové rozhraní zařízení.

Jakmile se instalace dokončí, je potřeba jít do Nastavení -> Zařízení a služby a tam přes ESPHome integraci přidat zařízení do Home Assistant. Nové zařízení tam bude vidět. Následně se vrátíme do ESPHome rozšíření a u nového zařízení klikneme na Edit. Tím se dostaneme do definičního souboru, kde přidáme LED modul zařízení. Použijeme ESPHome modul NeoPixelBus Light. Je potřeba nastavit pin, přes který je LED modul připojený k Wemosu. V našem případě jsme použili D5 (GPIO 14). Konfigurace vyžaduje hodnotu GPIO. Nastavíme fyzický počet LED, v našem případě 8. Nesmíme zapomenout si LED modul pojmenovat. Pod tímto jménem ho následně uvidíme v Home Assistant.

light:
  - platform: neopixelbus
    type: GRB
    variant: WS2811
    pin: GPIO14
    num_leds: 8
    name: "Signal Light 03"

Uložíme a dáme instalovat. Zeptá se nás to, jakou metodou chceme instalovat nový firmware. Zvolíme bezdrátově.

A počkáme, než se firmware zkompiluje a nahraje na zařízení. Tady to mají takové neintuitivní. Až doběhne instalace, pro pokračování a „odkliknutí“ tohoto dialogu musíme kliknout na tlačítko STOP. Ono je to připojené na sériový výstup zařízení, takže to asi znamená zastavení monitorování sériového výstupu zařízení.

Poté můžeme se zařízením pracovat a přidat ho do Dashboardu.

A začít ho ovládat.

Tímto je hotovo, zařízení je v Home Assistant a můžeme s ním pracovat.

Pro mě byl dalším krokem přidat zařízení do automatizace. Mám dvě automatizace. Když jsou garážová vrata otevřena, zařízení napojené na tuto automatizaci bliká červeně. Ve chvíli, kdy se změní stav z otevřeno na zavřeno, proběhne sekvence. LED modul se na zařízení vypne, rozsvítí se zelená barva a po nějaké době se vypne.

Tohle je už opravdu vše. Od této chvíle je zařízení integrováno, a pokud bude mít šťávu a uvidí na Wi-Fi, tak bude signalizovat, jestli jsou garážová vrata otevřená, případně jestli došlo k zavření.

Bezpečnostní dodatek

Pokud dostáváte návaly úzkosti, když nejste doma a běží tam vámi vytvořené zařízení, tady je pár tipů, jak úzkost zmírnit.

Odpojení v nepřítomnosti

Není asi nutné, aby světýlka blikala/fungovala, když není nikdo doma a nikdo nemá možnost zasáhnout, kdyby došlo k problému. Na to je docela přímočaré řešení. Použijte chytré zásuvky a nastavte, aby zapnuly signalizační modul jen ve chvíli, kdy se někdo nachází doma. Každopádně toto značně prodraží cenu jednoho signalizačního modulu.

Samozhášivý filament

U elektroinstalace se používají samozhášivé krabice z jasného důvodu. Pokud zařízení „blafne“, snižujeme pravděpodobnost vyhoření. Například PLA filament touto vlastností nedisponuje. Ovšem existují samozhášivé PETG filamenty. Například Prusament PETG V0 je tak dvojnásobně dražší a komplikovanější na tisk, ale řešení pro klidnější spaní existuje.

The post DIY Signal Light first appeared on Hard Wired.

Základní přehled ESPček, už tak v tom může být docela guláš.

Varianty

SoC

• System on a Chip
• integráče
• pro velkovezíry

Moduly

• Připravené SoC v modulu
• stíněné
• certifikace FCC
• pro výrobce a hobíky

Dev Kity

• vývojová deska s modulem nebo SoC
• vyvedený piny
• konektory
• a další fičury
• pro vývojáře a hobíky

Převodníky USB na UART

CP2102

• Silicon Labs
• 1Mbps
• podpora Win, macOS, Linux

CH340G

• WCH (Nanjing Qinheng Microelectronics)
• 2Mbps
• může vyžadovat instalaci ovladačů

Modely

ESP8266

• 32-bit Single Core Xtensa LX106 80 - 160 MHz
• 2.4 GHz Wi-Fi
• SPI
• I2C
• UART
• I2S
• RAM 160KB - 64KB instrukce, 96KB Data
• externí QSPI Flash pamět 512KB a 4MB

Espressif Systems

• ESP-WROOM-02 - PCB anténa, 2MiB Flash
• ESP-WROOM-02D - PCB anténa, 2MiB Flash
• ESP-WROOM-02U - U.FL anténa, 2MiB Flash
• ESP-WROOM-S2 - PCB anténa 2MiB Flash

Ai-Thinker

• ESP-01S - PCB anténa, 1MiB Flash
• ESP-01M - PCB anténa, 1MiB Flash
• ESP-07S - U.FL anténa, 4MiB Flash
• ESP-08S - bez Wi-Fi, 4MiB Flash
• ESP-12F - PCB anténa, 4MiB Flash
• ESP-12S - PCB anténa, 4MiB Flash

WeMos

• D1 R2 - PCB anténa, 1MiB Flash
• D1 mini - PCB anténa, 4MiB Flash
• D1 mini Lite - PCB anténa, 1MiB Flash
• D1 mini Pro - U.FL anténa, 16MiB Flash

ESP32

• uvedena 2016
• 160 - 240 MHz
• FPU
• 32-bit MCU Single & Dual Core
• 2.4 GHz Wi-Fi
• Bluetooth / Bluetooth LE
• Camera Bus
• Hall Sensor
• SD Interface

Espressif Systems

• ESP32-WROOM-32 - 240MHz, 520KB RAM, 4MB Flash, 2.4GHz, BLE 4.2, 26 GPIO
• ESP32-WROVER - 240MHz, 520KB RAM + 8MB PSRAM, 4MB Flash, 2,4GHz, BLE 4.2, 26 GPIO
• ESP32-PICO-D4 - 240MHz, 520KB RAM, 4MB Flash, 2.4GHz, BLE 4.2, 19 GPIO, prcek
• ESP32-CAM - 240MHz, 520KB RAM, 4MB Flash, 2.4GHz, BLE 4.2, 9 GPIO, integrovaná kamera

ESP32-S

• uvedena 2020

• 240 MHz

• Camera Bus

  S2

  • 32-bit Single Core MCU
  • 2.4 GHz Wi-Fi
  • nemá Bluetooth
  • 13-bit ADC

  S3

  • 32-bit Dual Core MCU
  • 2.4 GHz Wi-Fi
  • Bluetooth 5 (LE)
  • podporuje extérní paměť

ESP32-C

• uvedena 2020
• RISC-V procesor
• 120 - 160MHz
• jedno jádrové

C2

• 32-bit RISC-V MCU
• 2.4 GHz Wi-Fi
• Bluetooth 5 (LE)
• náhrada za ESP8266

C3

• 32-bit RISC-V MCU
• 2.4 GHz Wi-Fi
• Bluetooth 5 (LE)
• má RTC

C6

• 32-bit RISC-V MCU
• 2.4 GHz Wi-Fi 6
• Bluetooth 5 (LE)
• IEEE 802.15.4 (LR-WPAN)
• podpora THREAD
• podpora ZIGBEE

C61

• uvedena 2024
• 160 MHz
• Wi-Fi 6
• podpora Matter (ESP Matter SDK)
• 32-bit RISC-V MCU
• 2.4 a 5 GHz
• Bluetooth 5 (LE)
• může být použit jako koprocesor

C5

• uvedena 2024
• 240 MHz
• 32-bit RISC-V MCU
• Wi-Fi 6
• podporuje Dual Band - 2.4 a 5 GHz
• Bluetooth 5 (LE)
• podporuje externí flash paměť
• může být použit jako koprocesor

ESP32-H

• uvedena 2023
• RISC-V
• 96 MHz
• zaměření na IoT aplikace
• podporuje externí paměť
• podpora THREAD
• podpora ZIGBEE

H2

• 32-bit RISC-V MCU
• Bluetooth 5 (LE)
• IEEE 802.15.4 (LR-WPAN)

ESP32-P

• uvedena 2024
• 400 MHz
• RISC-V
• FPU
• zaměřena na vysoký výkon
• nemá Wi-Fi
• nemá Bluetooth

P4

• 32-bit Dual Core RISC-V MCU

The post Základní přehled ESPček first appeared on Hard Wired.

Úvod

V dynamickém světě embedded systémů a projektů Internet of Things (IoT) hrají klíčovou roli dvě prominentní platformy: Arduino a ESP (zahrnující čipy ESP8266 a ESP32). Tyto platformy se staly základními nástroji pro vývojáře, makers a technologické nadšence, kteří chtějí vytvářet inteligentní a propojená zařízení.

Arduino, s svou dlouhou historií a pověstí uživatelsky přívětivé platformy, se stalo synonymem pro začátečnické projekty v oblasti elektroniky a programování. Jeho jednoduchost a rozsáhlá komunita z něj učinily ideální odrazový můstek pro ty, kteří vstupují do světa embedded systémů. Na druhé straně, ESP čipy, vyvinuté společností Espressif Systems, představují novou generaci mikrokontrolérů, které kombinují vysoký výkon s integrovanou Wi-Fi (a v případě ESP32 i Bluetooth) konektivitou, což je činí atraktivními pro moderní IoT aplikace.

Navzdory rostoucí popularitě ESP čipů mnoho vývojářů, kteří začínali s Arduinem, váhá s přechodem na tuto novější platformu. Tento článek si klade za cíl prozkoumat důvody tohoto váhání, porovnat klíčové aspekty obou platforem a poskytnout komplexní pohled na výhody a výzvy spojené s každou z nich.

V následujících sekcích se zaměříme na detailní srovnání Arduino a ESP platforem, včetně jejich hardwarových specifikací, programovacích prostředí, ekosystémů a typických případů použití. Budeme také diskutovat o tom, proč přechod z Arduino na ESP může být pro některé vývojáře náročný, a poskytneme rady, jak tyto výzvy překonat. Ať už jste zkušený Arduino vývojář zvažující přechod na ESP, nebo začátečník rozhodující se mezi těmito platformami, tento článek vám poskytne cenné informace pro informované rozhodnutí.

Arduino: Jednoduchý začátek v embedded vývoji

Co je Arduino?

Arduino je open-source platforma pro elektronické prototypování, která se skládá z hardwarové a softwarové části. Hardwarovou část tvoří různé typy desek (např. Arduino Uno, Nano, Mega), zatímco softwarovou část představuje Arduino IDE (Integrated Development Environment) a knihovny.

Klíčové vlastnosti Arduino:

1. Jednoduchost: Arduino je navrženo pro snadné použití, což z něj dělá ideální platformu pro začátečníky.
2. Rozsáhlá komunita: Díky své popularitě má Arduino obrovskou komunitu, což znamená snadný přístup k návodům, knihovnám a podpoře.
3. Široká kompatibilita: Existuje velké množství senzorů a modulů speciálně navržených pro Arduino.
4. Nízká spotřeba energie: Arduino desky jsou obecně energeticky úsporné, což je ideální pro bateriově napájené projekty.
5. Stabilní vývojové prostředí: Arduino IDE je jednoduché a spolehlivé, což usnadňuje vývoj.

ESP8266 a ESP32: Výkonné Wi-Fi čipy

Co jsou ESP čipy?

ESP8266 a ESP32 jsou mikrokontroléry vyvinuté společností Espressif Systems. Tyto čipy jsou známé svou integrovanou Wi-Fi funkcionalitou a výkonným zpracováním.

Klíčové vlastnosti ESP:

1. Vestavěná Wi-Fi: Nativní podpora Wi-Fi umožňuje snadné připojení k internetu a vytváření IoT zařízení.
2. Vysoký výkon: ESP čipy mají výrazně vyšší taktovací frekvenci a více paměti než typické Arduino desky.
3. Nízká cena: Navzdory své výkonnosti jsou ESP čipy často levnější než Arduino desky.
4. Bluetooth (ESP32): ESP32 nabízí kromě Wi-Fi také Bluetooth funkcionalitu.
5. Flexibilní programování: ESP čipy lze programovat pomocí Arduino IDE, ale také pomocí jiných nástrojů a jazyků.

Hlavní rozdíly mezi Arduino a ESP

1. Výkon a paměť

• Arduino: Typicky používá 8bitové mikrokontroléry s frekvencí 16 MHz a 2 KB RAM (Arduino Uno).
• ESP: Nabízí 32bitové procesory s frekvencí až 240 MHz a až 520 KB RAM (ESP32).

2. Konektivita

• Arduino: Nemá vestavěnou bezdrátovou konektivitu. Wi-Fi nebo Bluetooth vyžadují přídavné moduly.
• ESP: Nativní podpora Wi-Fi (ESP8266 a ESP32) a Bluetooth (ESP32).

3. Energetická účinnost

• Arduino: Obecně velmi energeticky úsporné, ideální pro projekty napájené bateriemi.
• ESP: Vyšší spotřeba energie, zejména při aktivním Wi-Fi připojení, ale nabízí různé režimy spánku pro úsporu energie.

4. Programování

• Společný základ: Obě platformy lze programovat pomocí jazyka založeného na C++, který je používán v Arduino IDE. To znamená, že základní syntaxe a struktura kódu jsou pro Arduino i ESP velmi podobné.

• Arduino:

  • Jednoduchý programovací model a IDE, zaměřený na začátečníky.
  • Nabízí vlastní funkce a knihovny specifické pro Arduino hardware.
  • Programování je obvykle přímočařejší, s menším množstvím nízkoúrovňových detailů.

• ESP:

  • Podporuje Arduino IDE a syntax, což usnadňuje přechod pro Arduino vývojáře.
  • Nabízí více možností programování:
    1. Arduino IDE s ESP8266/ESP32 rozšířením: Umožňuje používat známé Arduino funkce a knihovny.
    2. ESP-IDF (Espressif IoT Development Framework): Nativní framework pro ESP, poskytující plný přístup k funkcím čipu.
    3. MicroPython: Možnost programovat v Pythonu, což je atraktivní pro některé vývojáře.
  • Vyžaduje hlubší pochopení hardwarových specifik, zejména při práci s Wi-Fi a pokročilými funkcemi.
  • Nabízí více nízkoúrovňových API pro přímou kontrolu hardwaru.

• Rozdíly v knihovnách:

  • Zatímco mnoho Arduino knihoven funguje na ESP, některé mohou vyžadovat úpravy nebo nejsou kompatibilní.
  • ESP má vlastní sadu knihoven optimalizovaných pro jeho hardware, zejména pro Wi-Fi a Bluetooth funkce.

• Komplexnost kódu:

  • Arduino projekty jsou často jednodušší a přímočařejší.
  • ESP projekty mohou být komplexnější, zejména při práci s síťovou komunikací, ale nabízejí větší flexibilitu a možnosti.

• Vývojová prostředí:

  • Arduino IDE je populární pro obě platformy, ale ESP podporuje i pokročilejší IDE jako PlatformIO nebo Visual Studio Code s příslušnými rozšířeními.

5. Cena

• Arduino: Oficiální desky jsou obecně dražší, ale existují levnější klony.
• ESP: Obvykle levnější, zejména vzhledem k integrované Wi-Fi funkcionalitě.

Proč mohou mít Arduino vývojáři problémy s přechodem na ESP?

1. Komplexnější architektura: ESP čipy mají složitější architekturu, což může být pro začátečníky matoucí.

2. Rozdíly v programování: Přestože ESP podporuje Arduino IDE, optimální využití jeho možností často vyžaduje pokročilejší programovací techniky.

3. Správa paměti: S větší pamětí přichází větší zodpovědnost. ESP vyžaduje pečlivější správu paměti, zejména při práci s Wi-Fi.

4. Napěťové úrovně: ESP pracuje s 3,3V logikou, zatímco mnoho Arduino desek používá 5V, což může vést k problémům s kompatibilitou.

5. Debugging: Ladění Wi-Fi aplikací může být složitější než u jednodušších Arduino projektů.

6. Více možností = větší složitost: ESP nabízí mnoho funkcí, což může být pro některé uživatele přehlcující.

Závěr

Při porovnání Arduino a ESP platforem je zřejmé, že každá má své jedinečné přednosti a výzvy. Arduino zůstává vynikající volbou pro začátečníky a projekty, které nevyžadují pokročilou konektivitu nebo vysoký výpočetní výkon. Jeho jednoduchost, rozsáhlá komunita a široká dostupnost kompatibilních součástek z něj činí ideální platformu pro učení základů embedded systémů a elektroniky.

Na druhé straně, ESP čipy představují významný krok vpřed v oblasti výkonu a konektivity. Jejich integrovaná Wi-Fi funkcionalita, vysoký výpočetní výkon a nízká cena je činí atraktivními pro pokročilé IoT projekty a aplikace vyžadující bezdrátovou komunikaci. ESP platformy také nabízejí větší flexibilitu v programování, což může být výhodou pro zkušenější vývojáře.

Přechod z Arduino na ESP může být pro některé vývojáře výzvou, ale potenciální přínosy jsou značné. Klíčem k úspěšnému přechodu je postupné učení, využívání dostupných online zdrojů a aktivní účast v komunitách obou platforem. Vývojáři, kteří investují čas do pochopení specifik ESP, mohou těžit z jeho pokročilých funkcí a otevřít si dveře k vytváření sofistikovanějších IoT řešení.

Je důležité zdůraznit, že volba mezi Arduino a ESP by měla být založena na konkrétních požadavcích projektu, zkušenostech vývojáře a dlouhodobých cílech. Pro mnoho projektů může být ideálním řešením kombinace obou platforem, kde Arduino slouží pro jednoduché senzorové úlohy a ESP zajišťuje konektivitu a zpracování dat.

V rychle se vyvíjejícím světě embedded systémů a IoT je schopnost pracovat s různými platformami cennou dovedností. Ať už se rozhodnete zůstat u Arduino, přejít na ESP, nebo využívat obě platformy, každá z nich nabízí jedinečné možnosti pro inovace a kreativitu v oblasti elektroniky a programování.

Závěrem lze říci, že zatímco Arduino a ESP mají své specifické silné stránky, obě platformy mají v ekosystému embedded systémů své místo. Porozumění jejich rozdílům a schopnost využít jejich jedinečné vlastnosti může vývojářům otevřít nové horizonty v oblasti IoT a embedded projektů.

The post Arduino vs. ESP – Rozdíly a výzvy pro Arduino vývojáře first appeared on Hard Wired.

V dnešním článku se podíváme na to, jak se z ESP32 development boardu připojit pomocí SSH ke vzdálenému počítači.

Pro vývoj je použito PlatformIO.

platformio.ini

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200
lib_deps = ewpa/LibSSH-ESP32@^4.2.0

main.cpp

Jediná externí závislost je libssh-esp32.

#include <Arduino.h>
#include <WiFi.h>
#include <libssh_esp32.h>
#include "libssh_esp32_config.h"
#include <libssh/libssh.h>
#include <vector>
#include <string>

Budeme potřebovat SSID WiFi sítě a heslo.

const char *ssid = "ssid-vasi-wifi";
const char *password = "vase-nejtajnejsi-heslo";

Potřebujeme nastavit přihlašovací údaje pro SSH a příkaz který po přihlášení provedeme.

const int ssh_port = 22;
const char *ssh_username = "pi";
const char *ssh_password = "super-tajne-heslo";
const char *ssh_command = "ls -l";

Dále seznam IP adres serverů na které se chceme připojit.

std::vector<std::string> server_ips = {
    "192.168.1.254",
};

Vytvoříme funkci pro připojení k WiFi. Na konci vypíšeme do konzole MAC adresu přístupového bodu, ke kterému jsme se připojili.

void connectToWiFi()
{
    WiFi.begin(ssid, password);
    while (WiFi.status() != WL_CONNECTED)
    {
        delay(1000);
        Serial.println("Connecting to WiFi..");
    }
    Serial.print("Připojeno k AP s MAC: ");
    Serial.println(WiFi.BSSIDstr());
}

Ted ta nejdelší část. Funkce co vytvoří SSH spojení, provede příkaz a výsledek vypíše na standardní výstup. Funkce si po sobě uklízí.

/**
 * Execute SSH Command
 *
 * @param ip Server IP
 * @param username SSH Username
 * @param password SSH Password
 * @param command Command to execute
 */
void executeSSHCommand(const char *ip, const char *username, const char *password, const char *command)
{
    // Create a new SSH session
    ssh_session session = ssh_new();
    if (session == NULL)
    {
        Serial.println("Failed to create SSH session");
        return;
    }

    // Set SSH options for the session
    ssh_options_set(session, SSH_OPTIONS_HOST, ip);
    ssh_options_set(session, SSH_OPTIONS_USER, username);

    // Connect to SSH server
    int rc = ssh_connect(session);
    if (rc != SSH_OK)
    {
        Serial.println("Failed to connect to SSH server");
        return;
    }

    // Verify the server's identity
    rc = ssh_userauth_password(session, NULL, password);
    if (rc != SSH_AUTH_SUCCESS)
    {
        Serial.println("Failed to authenticate");
        return;
    }

    // Create a new SSH channel
    ssh_channel channel = ssh_channel_new(session);
    if (channel == NULL)
    {
        Serial.println("Failed to create SSH channel");
        return;
    }

    // Open a new SSH session
    rc = ssh_channel_open_session(channel);
    if (rc != SSH_OK)
    {
        Serial.println("Failed to open SSH session");
        return;
    }

    // Execute the command
    rc = ssh_channel_request_exec(channel, command);
    if (rc != SSH_OK)
    {
        Serial.println("Failed to execute command");
        return;
    }

    // Read the output of the command
    char buffer[256];
    int nbytes; // Number of bytes read
    nbytes = ssh_channel_read(channel, buffer, sizeof(buffer), 0);
    while (nbytes > 0)
    {
        if (write(1, buffer, nbytes) != nbytes) // Write to stdout
        {
            Serial.println("Failed to write to stdout");
            return;
        }
        nbytes = ssh_channel_read(channel, buffer, sizeof(buffer), 0);
    }

    // Check if there was an error reading from the channel
    if (nbytes < 0)
    {
        Serial.println("Failed to read from SSH channel");
        return;
    }

    // Send EOF and close the channel
    ssh_channel_send_eof(channel);

    // Close the channel
    ssh_channel_close(channel);

    // Free the channel
    ssh_channel_free(channel);

    // Disconnect the session
    ssh_disconnect(session);

    // Free the session
    ssh_free(session);
}

Teď potřebujeme funkci která provede SSH příkaz pro všechny naše servery, které jsou definované v server_ips.

/**
 * Execute SSH Command on all servers
 * 
 * @param username SSH Username
 * @param password SSH Password
 * @param command Command to execute
 */
void executeSSHCommandOnAllServers(const char *username, const char *password, const char *command)
{
    for (std::string ip : server_ips)
    {
        executeSSHCommand(ip.c_str(), username, password, command);
    }
}

Teď už jen zbývá provést vše při startu ESPčka.

void setup()
{
    Serial.begin(115200);
    while (!Serial)
    {
        ; // Wait for serial to be ready
    }

    connectToWiFi();
    ssh_init();
    executeSSHCommandOnAllServers(ssh_username, ssh_password, ssh_command);
}

Hlavní smyčku programu pro tento příklad necháme odpočívat.

void loop()
{
    delay(1000); // Delay for 1 second
}

To je vše. Po kompilaci, nahrání kódu a spuštění ESPčka se připojí k WiFi a poté provede SSH připojení na zadané IP adresy a provede ls -l příkaz. Ten vypíše do konzole.

main.cpp full

#include <Arduino.h>
#include <WiFi.h>
#include <libssh_esp32.h>
#include "libssh_esp32_config.h"
#include <libssh/libssh.h>
#include <vector>
#include <string>

// WiFi Credentials
const char *ssid = "ssid-vasi-wifi";
const char *password = "vase-nejtajnejsi-heslo";

// SSH Credentials
const int ssh_port = 22;
const char *ssh_username = "pi";
const char *ssh_password = "super-tajne-helso";
const char *ssh_command = "ls -l";

// Server IPs List
std::vector<std::string> server_ips = {
    "192.168.1.254",
};

/**
 * Connect to WiFi
 */
void connectToWiFi()
{
    WiFi.begin(ssid, password);
    while (WiFi.status() != WL_CONNECTED)
    {
        delay(1000);
        Serial.println("Connecting to WiFi..");
    }
    Serial.print("Připojeno k AP s MAC: ");
    Serial.println(WiFi.BSSIDstr());
}

/**
 * Execute SSH Command
 *
 * @param ip Server IP
 * @param username SSH Username
 * @param password SSH Password
 * @param command Command to execute
 */
void executeSSHCommand(const char *ip, const char *username, const char *password, const char *command)
{
    // Create a new SSH session
    ssh_session session = ssh_new();
    if (session == NULL)
    {
        Serial.println("Failed to create SSH session");
        return;
    }

    // Set SSH options for the session
    ssh_options_set(session, SSH_OPTIONS_HOST, ip);
    ssh_options_set(session, SSH_OPTIONS_USER, username);

    // Connect to SSH server
    int rc = ssh_connect(session);
    if (rc != SSH_OK)
    {
        Serial.println("Failed to connect to SSH server");
        return;
    }

    // Verify the server's identity
    rc = ssh_userauth_password(session, NULL, password);
    if (rc != SSH_AUTH_SUCCESS)
    {
        Serial.println("Failed to authenticate");
        return;
    }

    // Create a new SSH channel
    ssh_channel channel = ssh_channel_new(session);
    if (channel == NULL)
    {
        Serial.println("Failed to create SSH channel");
        return;
    }

    // Open a new SSH session
    rc = ssh_channel_open_session(channel);
    if (rc != SSH_OK)
    {
        Serial.println("Failed to open SSH session");
        return;
    }

    // Execute the command
    rc = ssh_channel_request_exec(channel, command);
    if (rc != SSH_OK)
    {
        Serial.println("Failed to execute command");
        return;
    }

    // Read the output of the command
    char buffer[256];
    int nbytes; // Number of bytes read
    nbytes = ssh_channel_read(channel, buffer, sizeof(buffer), 0);
    while (nbytes > 0)
    {
        if (write(1, buffer, nbytes) != nbytes) // Write to stdout
        {
            Serial.println("Failed to write to stdout");
            return;
        }
        nbytes = ssh_channel_read(channel, buffer, sizeof(buffer), 0);
    }

    // Check if there was an error reading from the channel
    if (nbytes < 0)
    {
        Serial.println("Failed to read from SSH channel");
        return;
    }

    // Send EOF and close the channel
    ssh_channel_send_eof(channel);

    // Close the channel
    ssh_channel_close(channel);

    // Free the channel
    ssh_channel_free(channel);

    // Disconnect the session
    ssh_disconnect(session);

    // Free the session
    ssh_free(session);
}

/**
 * Execute SSH Command on all servers
 *
 * @param username SSH Username
 * @param password SSH Password
 * @param command Command to execute
 */
void executeSSHCommandOnAllServers(const char *username, const char *password, const char *command)
{
    for (std::string ip : server_ips)
    {
        executeSSHCommand(ip.c_str(), username, password, command);
    }
}

void setup()
{
    Serial.begin(115200);
    while (!Serial)
    {
        ; // Wait for serial to be ready
    }

    connectToWiFi();
    ssh_init();
    executeSSHCommandOnAllServers(ssh_username, ssh_password, ssh_command);
}

void loop()
{
    delay(1000); // Delay for 1 second
}

The post SSH připojení pomocí ESP32 first appeared on Hard Wired.

Grammar detailists beware.

Hacky carky chybi. Jsem sice rodily cech, ale spousta textu moji rukou budiz v jazyce anglickem. Je treba brati na zřetel autorovu deformaci profesnim prostredim.

Na zacatek...

• NDA = Non-Disclosure Agreement, v cestine je to mlcenlivost, potazmo dohoda o mlcenlivosti, chcete-li.
• Department = angl. preklad pro "oddeleni"
• accesses = angl. preklad pro pristupy, v tomto kontextu prihlasovaci udaje do konkretniho systemu tak, aby byl zamestnanec schopen pracovat.
• API = Application Programming Interface, laicky to lze popsat jako cast programu, ktera ma otevrenou "zasuvku" pro jine programy, ktere s timto programem muzou dale pracovat tak, jako by se jednalo o soucast.
• PAN = Personal Area Network - Je to forma pripojeni k internetu (zjednoduseno) pres telefon, ale nejen nutne. Muzete i pracovat se soubory.
• CI/CD = Continuous Integration, Continuous Deployment - jedna se o system hlavne pro vyvojare programu. Je to uceleny balik programu, ktere urychluji testovani, verzovani a v urcitych pripadech i automaticke "zverejnovani" novych verzi programu.
• on-call = Dalo by se rici, ze se jedna o stav, kdy mate pracovni telefon v pohotovosti pro pripad, ze bude treba Vasich znalosti na reseni nejakeho pracovniho problemu. Zpravidla je to placene. Jste vlastne sluzebne porad v praci, jen ne fyzicky na pracovisti.

Jedna se o surove myslenky a vzpominky. Zalozeno na realnem zivote, ktery se neodehraval podle predstav. Autorem budiz clovek jinak uvazujici, prosim o zretel.

Rekneme, ze to byla relativne bezna, vzhledem ke Gretine eco lobby zasnezena zima v prazske metropoli, akorat s jednim zasadnim rozdilem.
Ano, pracoval jsem tam. Ve meste, o kterem jsem vzdy touzil, ze budu v nem pracovat, uzivat si kazdodenniho shonu cesty do prace v zacpach Praze vlastni. Parkrat se mi to i stalo.

Nebudu chodit kolem horke kase, ano, uz tam bohuzel nejsem.
Nebo nastesti?

Jak se to vezme.

Chapter one: The leaver

Vse to vlastne zacalo v srpnu 2022. Mel jsem stabilne-nestabilni zamestnani v nenouzove-nouzovem stavu, jelikoz panovala pandemie a vlada si nutne potrebovala vydupat jinak nepotrebny nouzak, ktery vlastne priskrtil i to, co uz bylo davno priskrcene. Ale nechme politiku stranou a soustredme se na myslenky, ktere mi z toho zustaly.

Vazneji receno, nastala mi turbulence v zivote, kterou jsem musel resit a volba padla na hledani jineho, mnohem stabilnejsiho mista.
Jelikoz v domovskem Brne moc prilezitosti nebylo a nekteri, me hodne blizci lide me "nalomili", rozhodl jsem se jit do neznama, do Prahy. Volba padla na jednoho velmi znameho vyrobce 3Dtiskaren. Tusite, mozna, kdo to je.

Ano, Prusa Research, presneji jejich department Prusa Development, v podstate se jednalo o "samostatnou" spolecnost, ktera primo resila vyvoj.

Vse zacalo de facto v zari, odsouhlasili jsme si navzajem tzv. "testovaci tyden", jelikoz jsem nevedel, co od te prace ocekavat. Tento tyden jsem skutecne do prace zde chodil a dostal zadani na vyreseni jedne chyby ve firmwaru SL1S. Co to bylo konkretne rici nemohu, chci si zachovat uctu a v nekterych pripadech i NDA.

Tento tyden dopadl dobre, tuto chybu se mi povedlo najit, vysledovat jeji zdroj a tim tak chybu opravit. Tiskarna se tedy v teto chvili a pro tuto situaci chovala tak, jak bylo dle dokumentace a pozadavku treba.

Chapter two: Good morning mr. Barter, looks like you're running late.

Prvni den v nove praci zacal pomerne "divoce". Vstaval jsem nekdy v 5 rano, v 6 cca autobus do Prahy a aby situace byla dokonala, na prijezdu jsme se zastavili v kolone, uz nekde od Chodova. A to se projevilo i na pozdnim prijezdu, kteremu zabranit neslo.
Nicmene, vse dopadlo dobre, jelikoz jsem prisel cca 10 minut po zacatku.

Nicmene oproti ostatnim jsem uz zdejsi prostredi znal. Bylo mi receno, ze dalsi nove prichozi byli zrovna na prohlidce, kterou jsem absolvoval uz na testovacim tydnu a bylo mi tedy odpusteno.

Vse probihalo v poradku, po veskerych nalezitostech nutnych pro prvni den v praci jsem se znovu shledal s mym primym vedoucim, mimo jine velmi prijemnym panem (mysleno vazne). Pomohl mi odnest veci na me zname pracoviste a ja tak mohl vlastne z fleku zacit pracovat.

Cekalo me me "misto", ktere jsem si vyhledl uz pri testovacim tydnu. Zaujal jsem jej a se znalostmi z minula jsem si zridil velmi rychle ruzne pristupy, accesses a "ozivil" si ucet na jejich internim komunikatoru.

I was ready to work.

Uterni prvni listopad se zacal chylit ke konci a pomalu jsem zacal resit presun na nove, lokalni bydleni.

Na okraji Prahy.

Chapter three: The hacker

Prvni den byl hekticky i v tom smyslu, ze jsem vlastne nemel zajistene ubytovani. Bylo to v jednom byte na okraji Prahy. Prestup na Kacerove z metra na 189 a skoro na konecnou. Radeji si ponecham, kde presne.
Setkal jsem se majitelem, podepsal jsem smlouvu, zabydlel se a chtel si odpocinou.

A zjistil, ze tam vlastne neni internet.

Takto, ne ze bych na nem nejak zivotne zavisel a uprimne znam par lidi, kteri bez internetu nemohou zit, nicmene mi spousta programatoru da za pravdu, ze bez fungujiciho internetu se programuje hodne tezko, zvlaste, pisete-li robota pro ruzne protokoly predavajici zpravy. Je jedno, zda je to email, ci neco podobneho chatu na Facebooku ci Twitteru.

Nebylo tam nic.

Az na jednu restauraci.

Zacal jsem tedy premyslet, jak si alespon castecne zasituji sve bydleni, jelikoz jednoduchou metodou pokus-omyl jsem uhadl relativne trivialni heslo do te restaurace a dovolil si tak pujcit internet. Termin "pujcit" rikam zde zamerne, jelikoz po strance rychlosti jsem se dostal na hodnoty nizsi, nez bylo kdysi davno vytaceny pripojeni.

A ja jako dite jeste pro jistotu odpojoval kabel z pocitace, co kdyby nahodou byl internet pripojenej.

Nicmene, casem se mi povedlo kombinaci androidich telefonu, celkem kvalitniho USB kabelu z Aliexpressu zasitovat pocitac a ja tak mohl pokracovat v soukrome praci. JavaScript byl ku podivu tolerantni k rychlosti a ja tak mohl otestovat moduly do robota, ktery uz ani robotem nebyl, ale mel blize k ucelenemu reseni, chcete-li API.

Nicmene, nekteri lide, hlavne ze socialnich siti, mi nabidli SIM karty s internetem. Moc si cenim, ze mi to nabizeli, ale jakozto clovek snazici se o maximalni samostatnost jsem chtel nejdrive vycerpat veskere moznosti, ktere jsem mel.

Dovezl jsem si tedy z Brna stary router. V podstate to byl TPLink WRT741ND, na kterem bylo naflashovane openWRT. Takze, jak to maji admini radi, SSH a /etc/config/network, potazmo /etc/config/dhcp.

To se neukazalo jako funkcni reseni.

Jako druhe reseni se mi osvedcil kdysi davno pribuzneho Samsung s "petkovym" androidem. Pres soukromy notebook jsem si hral trochu s pripojenim pres PAN a dostal to do funkcniho stavu.

A takhle jsem zacal fungovat v podsate do konce ledna. Nicmene, pendloval jsem mezi "Praglem" a "Schallingrattem" kazde pondeli a kazdy ctvrtek.

V pondeli ve 4 rano,na budika a v 5 RegioJetem v Lowcostu do Prahy s misty nekvalitnim spankem, ve ctvrtek zpet domu, ale o pul 4.

A ano, tu SL1S jsem si zapujcil domu. Jako vybaveni nutne pro vyvoj firmwaru.

Casem jsem to dostal i do stavu, kdy jsem si od jedne pani v domovskem Brne koupil pojizdny kufr, lehce ho opravil a dostal tak moznost vozit 3Dtiskarny s sebou, v kufru.

Chapter five: Nearby

V podstate jsem jsem v lednu travil cas i hledanim jineho bydleni. To predchozi bylo pro me velmi neoptimalni, hlavne kvuli internetu. V podstate jsem veskere prace delal na koleni a misty si musel popojit k obchodu u zastavky, kde jsem vystupoval z autobusu linky 189 a chytat tam wifi.

Ale take kvuli tomu dobrovolne zustaval v praci, nekdy i 13 hodin denne.

Udelal jsem neco navic pro sebe po zkusenostech a znalostech, ale i se snazil dohnat to, co jsem treba zapomnel, ci se mohl posunout vice dopredu oproti puvodnim planum.

Nicmene, zadarilo se.

Nasel jsem si jiny podnajem a sel do nej. A posunul se do pohodlnejsi casti.
Unor. Brezen.

Nic zasadnejsiho se nestalo, co se tyce prace. Kazdodenni shon, ale autobus a metro jsem vymenil za salinu. Nebo pardon - tramvaj. Mohl jsem si vybrat, zda rano sednu na "socku" (jak tomu nekdy prazsti rikaji - je to vubec pravda, nebo je to urban story?), nebo sednu na tramvaj. Oboji me doveze do prace, jen u metra jsem musel prestupovat na Florenci, coz mi davalo jakysi pocit komplexnosti cesty do prace nebo "domu".

Nicmene, uz jsem se dostaval do pohodlne sfery sveho ziti, kdy jsem mohl (konecne) udelat relativne tradicni vylety do Makra, udelat si nakup a vratit se zpatky na byt zrelaxovat po praci.

At uz modelovanim, ci programovanim.
ale take to dopadlo i tak, ze jsem prisel, dal si sprchu a sel spat. Jen zridkakdy jsem se dostal k modelovani, potazmo vyvoji, nicmene nasel se jeden vikend, kdy jsem tomu skutecne venoval cas.

Chapter six: The Chaos

Az cca do pocatku druheho tydne se nic zvlasniho nedelo, na druhou stranu ano, spousta veci byla neustale dynamicka. Letmo jsem se dotkl i veci v te dobe jeste v rannem pocatku vyvoje. Co se soukromeho casu tyce, uz jsem byl v relativni pohode a klidu.

Nicmene i tak jsem se snazil mimo pracovni dobu promptne resit pripominky a sledoval jsem ze sve vlastni vule interni CI/CD, jak probiha testovani a automatizace, ktera byla de facto moji denni naplni.

Zkratka, byl jsem on-call. Po ruce, ale v omezene mire a snazil se i tak dohnat veci, ktere treba usly, popripade chtely nejaky drobnejsi zasah programatora-devopsaka.

To spatne ale teprve melo prijit.

Zacal jsem si vsimat drobnych nedostatku v konunikaci. Jelikoz byl bohuzel odejit uz v lednu nas predchozi vedouci - ten, ktery me nabiral - komunikace se smrskla z formalni peti, misty ctyr lidi, na ctyri, respektive na tri.

Bohuzel i ja zacal zde "selhavat", co se tyce komunikace. Neopochopeni zadani, spousta dotazovani, snaha pracovat samostatne a misty i drobne poznatky, jak vlastne ti lide fungovali v ramci tymu.

Z nekolika drobnych praci bokem pro jine tymy jsem se seznamil s dalsimi a par mych napadu na zlepseni se bohuzel minulo ucinkem.
V zasade jsem se na zdrojovy kod podival, poznal jsem, ze je misty neoptimalni a navrhl zlepseni, jak to resit spravne, jak to mit dle konvenci.

Programatori z povolani me nejspise budou chapat, v kratkosti.
V zasade jde o to, jak spravne automatizovat instalaci.

Treba Python to ma troska specificke, nicmene oproti JavaScriptu / NodeJS to neni zas tak daleko, v podstate slo o "izolaci" veci pro danou aplikaci od systemu, na coz si pamatuji z predchozich zamestnani - kde se mi to stalo - klient si spatne nastavil prostredi a v te chvili rozbil cely system. Program na instalaci jinych programu prestal z minuty na minutu fungovat a "administratore, res to. Hlavne klientovi nerozbij to, co mu tam bezi."

Chapter seven: The detail

Zacal jsem hodne "bojovat" s nadrizenym. Nikoliv fyzicky, ale jak ma dane zadani vypadat, co tam ma byt. Takze, podivam-li se na to svym analytickym pohledem okorenenym o muj autismus (ano, mel jsem na nej papir, sebrali mi jej, pry jsem sobestacnej...), v podstate jsem komunikoval s clovekem, ktery mel siroke uvazovani, zatimco ja velmi detailni.

Treba rozchodit automatizovane SSH, protoze se sitarum par veci nelibilo a podle praxe by jste jako administratori nemeli mit volne dostupny server se superuzivatelem. Neexistuje.

Zadani treba znelo "Zajistit automaticke predavani klicu", coz jsem vyhotovil, ale treba tam chybel nejaky detail, ktery explicitne nebyl zminen.

Takze ano, zadani jsem formalne splnil, ale melo by to byt resene takto, takto, onakto... To proste v dokumentaci k zadani chybelo, takze i parkrat jsem se musel dotazovat, jak tedy ma vypadat vysledek.

A to tez vzalo spoustu casu.

Jelikoz tento clovek byl v "officu" (prakticky to spis byla dilna s pocitaci a hromadou elektroniky kolem) jen dvakrat tydne, komunikace docela vazla. Z predchozich zkusenosti z tymu dvou lidi - ja a nadrizeny - jsem se snazil udelat co nejvice prace, ale take nedelat ukvapene kroky.

Mozna tusite tu kontradikci. Ano rovna se ne. A naopak.

#define True False

A vysvetlovani zacalo.

Parkrat jsem uz byl "na koberecku", snazice se vysvetlit sve uvazovani, jak resit tu praci a cim zlepsit svuj vlastni vykon.

Chapter eight: Evacuation

Nekdy v polovine dubna doslo k nejhorsimu, a sice meeting s HR, jak se veci budou odvijet dale. Bylo mi receno, ze jina moznost, nez dohoda uz neexistuje.

Takze ano, chteli se me zbavit. Podobny, ne-li stejny zpusob, jako v minule firme.
Zadny vytykaci dopis, zadna snaha o to, jak zlepsit praci. Zadna snaha o to, jak bych tem druhym mohl rozumet lepe a jak pochopit kontext jejich myslenek, coz je kolikrat procesorove narocnejsi operace.

A take zadna reference k tomu dobrovolnemu prescasu, za leden budiz 40 hodin.

V podstate jeden cely tyden prescasu, ktery mi vlastne nikdo nezaplatil. Formalne ani nemusel. Ale jako snahu to akceptovat mohl.

Shrnul-li veskere udalosti, v zasade jsem s tim uz souhlasil. Vedel jsem, ze dojizdet kazde pondelni rano je dlouhodobe neudrzitelne, nehlede na absenci spanku, ktera byla mym vernym pritelem.

Ale nebyl to jedinny duvod.

Zde se naskladalo nekolikero faktoru. Nevim, zda je vhodne o tom hovoriti, ale z vnitrniho prostredi firmy jsem se dozvedel, ze ne, ze je to spis fanouskovske zamestnani.

Na druhou stranu, ano, z jednoho platu jsem vlastne "tahnul" dve bydleni.
Svuj domov 207,7 kilometru ode me a sve prechodne bydleni 5,3 kilometru ode me.

Nicmene doslo k nepchopeni na obou stranach. Oni chteli profesionala, dle me z fleku rozumejiciho dane problematice, zatimco ja jim mohl nabidnout jen pokrocile zkusenosti, byt se schopnosti se zorientovat, popripade si obstarat informace. Uplny zacatecnik jsem v te dobe nebyl ani zdaleka, vedel jsem o vyvoji softwaru, vedel jsem i o automatizaci vyvoje.

Koneckoncu automatizaci testovani firmwaru jsem vcetne podrobne dokumentace realizoval na zaklade tehdy existujicich poznamek z jinych tymu.

Byla to jedna z veci, co me opravdu bavila, nejenze jsem se dostal pomerne hluboko k samotnemu firmwaru, nicmene naucil jsem firemni nastroje primo interagovat s tiskarnou, ktera se vlastne odzkousela sama a tim se prace nutna na rucni testovani mohla investovat jinde. To je pointa automatizace.

Nicmene lehce po polovine tydne jsem uz byl nucen opustit Prahu a vratit se zpet.

Chapter nine: The retrospective

I pres tyto spatnosti doted vzpominam na tuto praci jako jednu z mala, ktera me opravdu bavila. I do te miry, ze jsem byl ochoten investovat nemalou cast sveho soukromeho casu do reseni problemu, jak vyresit automatizaci testovani firmwaru.

V podstate jsem delal DevOps praci, jen doplnenou o vyvoj, ktery treba nebyl tak zajimavy, nicmene byl nedilnou soucasti toho, co se tam delo.

Nicmene, chci to hodnotit i tak pozitivne, byt se hodne velke skraloupy a vymoly na silnici najdou.

• Co me hodne mrzi, je jakasi neochota poznat ten cas, co tam clovek investoval dobrovolne. Je to hodne subjektivni pocit a ano, bude to nahnute tak, ze ne kazdy s tim bude souhlasit.
  Tech 40 hodin mi asi uz nikdo nevrati, natozpak nezaplati, na druhou stranu cast toho kodu moji rukou napsanou tam nejspis je doted (ledaze se to dotycny clovek rozhodl cele vyhodit).
• Osobni pocit z pracovne-uzkeho kolektivu spatny. Bohuzel nebyl jsem jedinny. Konkretni ale byt radeji nechci, opet, chci si zachovat uctu.
• Vladne zde "chaos". Termin "chaos" zminuji zamerne v uvozovkach, protoze ne kazdemu sedne dynamika prostredi, ackoliv me to misty nevadilo.
• Chybela mi exaktnost a detailnost. Ale opet, subjektivni pocit. Predstavte si to tak, ze tatinek programator rekne synovi, aby mu popsal, jak si namazat nutellu na rohlik. Date mi za pravdu, ze kdyz syn rekne "vezmi pomazanku" tatinkovi a ten mu na to odpovi "stala se chyba", asi tusite. Logicky, nemuze vzit pomazanku, kdyz je ta sklenice s nutellou uzavrena vikem. Musite udelat spousty kroku.
  A to zde chybelo. Co konkretne.
• Teamleader failure: Nevim, zda je to muj osobni pocit, ale vlastne doted mi nikdo odtamtud neposlal referenci. Dokonce si ode me nadrizeny vyzadal kontakt na zaslani. Bud zapomnel, anebo se na to vykaslal. Vzhledem k 26. 12. - to druhe.
  Bez ohledu na to, ze na to treba ma obecne clovek pravo, nechal jsem zde hovorit realnou vuli pravnicke osoby.
• Pomerne nedavno se mi dostal do rukou odkaz na YouTube od jednoho pomerne znameho recenzenta. Dozvedel jsem se spousty neprijemnych veci. Na zaklade tohoto si kladu otazku "Chtel bych tam jeste pracovat? Proc to udelali takto? Proc se s tou spolecnosti nedohodli treba na spolupraci? Opravdu jim to za to stalo?" Nechal jsem tam spoustu sveho casu a i kdyz tam treba nekoho konkretne nemusim, porad verim, ze jsou tam uzasni lide, kteri na to treba maji podobny pohled, jako ja. Nechci soudit.
• Z partnerskeho hlediska a mimo profesni zkusenosti, troska jsem touzil, ze tam "nejakou" najdu. Na druhou stranu, asi je to tak dobre, protoze pri pomysleni, ze by ona chtela sedet na gauci se mnou a ja programovat... ona by trpela. Nedejboze, ona by chtela jit treba do virivky a ja chtel tisknout treba nahradni dil do domacnosti.

Ted ty pozitiva.

• Dojizdeni do Prahy z Brna a domu do Brna bylo casove narocne. Nicmene davalo mi to jakysi pocit, ze nejenze byl o moji praci a snahu zajem, ale kdyz si to tak vezmu, brnak mel kapacitu na to nabidnout sve znalosti mimo svoji domovinu. Davalo mi to pocit, ze je o me zajem alespon z pracovniho hlediska a byt je to sebemrskacstvi, to dojizdeni me vlastne i bavilo. Prekonaval jsem dalky, prekonaval jsem sve limity a tak si vlastne dokazal, ze i s poruchou autistickeho spektra - nachylnemu k nestabilite - dobre fungovat i v chaotickem prostredi.
• V podstate znam dalsi system na spravu verzi, coz je dobra zkusenost bez ohledu na ukonceni. Prohloubilo to znalosti a rozumim vnitrnimu fungovani. Dat si ted dohromady Kubernetes a orchestraci kontejnerizace ma ted pro me vetsi smysl, jak ten system vypada, jak ho nastavit... Toto na chodniku nenajdete.
• Ano, poznal jsem tam spousty prijemnych lidi. Vyjma psychologicke nekompatibility - osobne - s konkretnim clovekem, nehodlam zde generalizovat pouze na zaklade negativniho vjemu. Ti lide to treba maji radi, radi tam pracuji bez ohledu na podminky, protoze je to bavi. 3Dtisk je vlastne zivotni styl, ne ze si tam nekde nekdo neco vytiskne, ale davate ostatnim moznost realizovat jejich sny.
• Praha je mesto, jako kazde jine. Ma sve problemy, ma sva pozitiva. I pres tu misty stisnenost ti lide tady jen prozivaji stejny zivot, jako treba v Brne. Ac je to treba chaoticke, chci jen jako autista dokazat, ze i v takovem "chaosu" lze fungovat dobre a netreba se bat.
• Vlastne jsem tam prinesl dobre napady a nektere z nich se zalibily. Na testovacim tydnu jsem se podival hloubeji do nekolika zdrojovych kodu a navrhl opravy. A ty uz tam zustaly.
• Neni to jen prace s firmwarem, ale i bokem. Ac jsem z jazyka C na vysoke skole vyletel s F-kem, zkusenosti zustaly a muj kod v C v tom arduinu je doted soucasti tech testu, i kdyby byl neaktivni. V historii je a to ja pocitam.

Chapter ten: The assesment

Hodnoceni sice uz probehlo a formalne je vice nedostatku, nez pozitiv. Nicmene jedna se o osobni pohled jednoho cloveka, ktery jeste k tomu mel pomerne "davno" papir, na kterym bylo napsany, ze mam o pulkolecka min, nebo vic. Zalezi.

Nicmene jedna drobnost se zapomnela.

Mimo praci, po konci smeny jsem treba jednou sedel i v breznu v kanclu a daval tam dohromady rozbite tiskarny. Kazdy by si rekl, ze odpad patri do odpadu, ale i pres to logo jsem se snazil ty stroje proste zprovoznit.

Jako 3Dtiskar nejen po strance uzivani, ale take i stavby, poskytovani rad a predevsim udrzby stroje v provozuschopne kondici jsem se nemohl jen tak divat na to, jak tam ty Mini lezely smutne v koute a jen cekaly, az je nekdo chnapne a slahne s nimi do odpadaku.
A to i pres to, ze jsem uz tehdy mel problem s odrenymi rucemi a nechybelo mi daleko k tomu je mit vydrene az do krve po ruznych buzirkach a neplanovanych zrychlenich sroubovaku spatnym smerem.

Takze, v podstate jsem opravil i par tiskaren, ktere by jinak nekde skoncily a dal jim druhy zivot. Mozna tam ted nekde spokojene tisknou, protoze prakticky schopne jsou.

Na druhou stranu v popisu prace jsem mel napsano "vyvoj a udrzba firmwaru".

Pro SLA tiskarny.

Ac to bylo vzdaleno tomu, co jsem delat chtel, dalo mi to i jakousi zpetnou vazbu, ze me nejvice bavi prace technika a programatora. V podstate umim "vsechno". Navrhnout si nejaky stroj, vyvinout dilce, vytisknout je, pripravit pro tiskarnu nejen firmware, ale i veci okolo - v podstate postavit si vlastni linku pro vyvojare.

Pridam-li k tomu znalosti cloveka pracujiciho jako pocitacovy spravce a sitovy udrzbar, v podstate jsem schopen postavit podobny system na zelene louce. Co mi k tomu potreba je jen pocitac, internet a tabulka bily cokolady s lentilkami z teska.

Trochu premyslim i tak, ze kdyby mi dnes nekdo z jejich HR zavolal "Dobry den, prehodnotili jsme nase rozhodnuti, chceme Te zpet", popremyslel bych o tom.

Zohlednim-li vsak sve zkusenosti z predchozich textu a tez i recenzi jejich produktu, zacinam vahat.

Je mi to lito, protoze i pres ideologicky nesouhlas to byla prvni prace v zivote, u ktere me bavilo i prescasovat a delat veci navic.
Ano, nejsem dokonaly a mam spoustu vyrobnich zavad, nicmene dnes mi spousta lidi predava slova "Mohli mit jednoho z nejvetsich fanousku do 3Dtisku, ktery tomu opravdu rozumi".

Navrhnout si 3Dtiskarnu, postavit ji a udrzovat ji neni prace na tyden, ale z vlastni zkusenosti na rok. Dal jsem do ni 10 tisic a dodneska stale funguje.

Takze zaverem, mohli mit skutecneho fanouska, zel, uz ho nemaji. Mrzi me to, protoze Prusa Research a Development jsou jinak fajn firmy s fajn lidmi. Ty lidi to take bavi a i tam se najdou myslenkove podobni memu uvazovani.

A toto myslim vazne.

The post The Calamity first appeared on Hard Wired.

Čtvrtý ročník v Brně!

Největší Maker Faire na Moravě se koná již po čtvrté. Letos opět zavítáme do krásných funkcionalistických prostor Brněnského výstaviště ve skvěle padnoucím pavilonu A1. Poznáte okolo 100 makerů a jejich skvělých projektů, zapojíte se do četných workshopů a instalací. Čekají na vás také vědecké pokusy! Program se bude odehrávat převážně ve vnitřních prostorách a částečně také venku.

Co je to Maker Faire?

Festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí. Světová přehlídka kreativity propojuje zájmové tvůrce a odborníky, zároveň slibuje chytrou zábavu pro rodiny s dětmi. Maker Faire v sobě kombinuje moderní technologie, vědu, design i tradiční řemesla.

Text pořadatele MakerFaire

The post Maker Faire Brno 2023 – Fotografie first appeared on Hard Wired.

Arduino UNO R4 je obrovským skokem vpřed pro komunitu s otevřeným zdrojovým kódem.

Arduino představilo nový model Arduino UNO R4, který bude dostupný v několika měsících. Tento nový model je označován jako "revoluční revize" ikonické řady UNO a je navržen tak, aby rozšířil open-source koncepci, kterou Arduino zastává. Arduino UNO R4 je vybaven 32bitovým mikrokontrolerem Cortex-M4, který zvýší rychlost hodin, paměti a úložiště flash o 3 až 16krát. Přesto se zachová kompatibilita s existujícími shieldy pro Arduino UNO a 5V provozním napětím. Tento nový model nabídne vývojářům dlouho očekávanou aktualizaci výkonu a možností. Arduino plánuje i nadále prodávat předchozí model Arduino UNO R3 a poskytovat podporu pro vývojáře, kteří chtějí používat 8bitový mikrokontroler AVR pro své projekty.

Arduino UNO R4

“ V detailech je nový Arduino UNO R4 vybaven Renesas RA4M1 ( Arm Cortex-M4 ) běžícím na 48 MHz, což poskytuje 3x nárůst oproti UNO R3. Kromě toho SRAM přešel z 2 kB na 32 kB a flash paměť šla z 32 kB na 256 kB, aby se přizpůsobily složitější projekty. Kromě toho byl port USB na základě požadavků komunity upgradován na USB-C a maximální napájecí napětí bylo zvýšeno na 24V s vylepšenou tepelnou konstrukcí. Deska poskytuje sběrnici CAN, která uživatelům umožňuje minimalizovat zapojení a provádět různé úkoly paralelně připojením více shieldu. Nová deska konečně obsahuje 12bitový analogový DAC. “

Zde v Arduinu jsme nadšeni, že můžeme oznámit novou revoluční revizi kultovní rady UNO, který rozšíří koncept nejznámějšího a nejoblíbenějšího produktu značky open-source a zároveň poskytne komunitě makerů dlouho očekávanou aktualizaci výkonu a možností. Arduino UNO R4 skutečně zachovává známé vlastnosti rodiny UNO – standardní tvar, kompatibilitu shieldu, 5V provozní napětí, vynikající robustnost – a nabízí 32bitový Cortex^®-M4 a 3 až 16x vyšší rychlost, paměti a úložiště flash.

Tento obrovský skok vpřed začíná novým procesorem od Renesas, světový lídr v oblasti mikrokontrolerů, analogových, výkonových a SoC produktů. Zatímco více než 10 milionů uživatelů si užilo hraní a práci s 8bitovým mikrokontrolerem Arduino UNO R3 ’ více než deset let, nová řada RA4 MCU otevře nekonečné nové projektové příležitosti pro pokročilejší makery a uvede desku na rychlosti současných standardů.

UNO R4 bude dodáván ve dvou verzích – UNO R4 WiFi a UNO R4 Minima –, které nabízejí bezprecedentní výkon a možnosti pro komunitu makerů.

Verze WiFi je dodávána s modulem Espressif S3 WiFi, který rozšiřuje kreativní příležitosti pro tvůrce, pedagogy i fandy; zatímco UNO R4 Minima poskytuje nákladově efektivní možnost pro ty, kteří hledají nový mikrokontroler bez dalších funkcí.

V detailech je nový Arduino UNO R4 vybaven Renesas RA4M1 ( Arm Cortex^®-M4 ) a běží na 48 MHz, což poskytuje 3x větší výkon oproti UNO R3. Kromě toho, velikost SRAM šla z 2kB na 32 kB, a flash paměť z 32 kB na 256 kB což umožňuje složitější projekty. Kromě toho byl port USB na základě požadavků komunity upgradován na USB-C a maximální napájecí napětí bylo zvýšeno na 24V s vylepšeným tepelným designem. Deska poskytuje sběrnice, které uživatelům umožňí minimalizovat zapojení a provádět různé úkoly paralelně připojeným shieldům. A navíc deska obsahuje 12bitový analogový DAC.

Celkově vzato, Arduino UNO R4 je odpovědí na žádosti o zlepšení a aktualizace, které komunita vývojářů a makerů dlouho požadovala.

Hardwarová kompatibilita, pinout, napětí a tvar se od UNO R3 nemění, což zajišťuje maximální hardwarovou a elektrickou kompatibilitu s existujícími štíty a projekty. Na softwarové straně je vyvíjeno velké úsilí maximalizovat zpětnou kompatibilitu nejpopulárnějších knihoven Arduino aby se uživatelé mohli spolehnout na existující příklady kódu a návody. Ve většině případů budou knihovny a příklady fungovat ihned po vybalení UNA, ale několik z nich, které byly optimalizovány pro architekturu AVR používanou v R3, bude muset být přeneseno. Aby pomohli při přechodu, Arduino poskytne veřejný seznam takových knihoven spolu s odkazy na stávající alternativy. Kromě toho byl spuštěn web www.arduino.cc/UNOR4 – pro vývojáře knihoven.

Arduino UNO R3 bude stále podporováno a k dispozici pro všechny kteří chtějí pracovat s 8bitovým mikrokontrolerem AVR.

Vydání Arduino UNO R4 je naplánováno ke konci května, kdy budou zveřejněny další podrobnosti o jeho funkcích.

Co nám Cortex-M4 přináší?

1. Architektura: Cortex-M4 jádro je vysoce výkonné jádro z rodiny ARM Cortex-M procesorů. Je založeno na RISC (Reduced Instruction Set Computing) architektuře, což znamená, že nabízí jednoduchou a efektivní instrukční sadu s nízkou latencí a vysokou rychlostí zpracování.
2. Výkonnost: Renesas Cortex-M4 mikrořadiče nabízejí vysoký výkon s rychlostí až 120 MHz, což umožňuje rychlé zpracování dat a efektivní provádění složitých algoritmů. Navíc Cortex-M4 jádro obsahuje hardwarový násobič (DSP) a akcelerátor pro digitální signálový procesing, což usnadňuje zpracování signálů, jako je zpracování zvuku nebo obrazu, s vysokou efektivitou.
3. Paměť: Renesas Cortex-M4 mikrořadiče mají různé konfigurace paměti v závislosti na konkrétním modelu. Například populární série Renesas RX mikrořadičů, která je založena na Cortex-M4 jádře, nabízí různé varianty s interní flash pamětí o velikostech od 128 KB do 2 MB pro program a interní RAM pamětí o velikostech od 16 KB do 640 KB pro data.
4. Periferie: Cortex-M4 mikrořadiče od Renesas jsou vybaveny bohatou sadou periferií, které umožňují komunikaci s vnějšími zařízeními a řízení různých periferních funkcí. Mezi tyto periferie patří sériová rozhraní (UART, SPI, I2C), časovače, analogově-digitální převodníky (ADC), pulzně šířkové modulátory (PWM), DMA (Direct Memory Access) jednotky pro efektivní přenos dat mezi pamětí a periferiemi, a další.
5. Nízká spotřeba energie: Renesas Cortex-M4 mikrořadiče jsou navrženy s důrazem na nízkou spotřebu energie, což je důležité pro aplikace, které pracují na bateriovém napájení nebo vyžadují nízkou spotřebu energie pro provoz na základě požadavků na energeticky efektivní zařízení.
6. Vývojové nástroje: Renesas poskytuje širokou škálu vývojových n ástrojů pro vývoj s Cortex-M4 mikrořadiči. Patří sem integrované vývojové prostředí (IDE), debuggery, emulátory, a různé vývojové desky a moduly, které usnadňují vývoj a testování aplikací na těchto mikrořadičích.
7. Bezpečnost: Renesas Cortex-M4 mikrořadiče obsahují různé bezpečnostní funkce, jako je například hardwarový modul pro šifrování a dešifrování (AES), hardwarový modul pro ochranu paměti (MPU), a další bezpečnostní funkce, které umožňují zabezpečení aplikací proti neoprávněným přístupům a zárukou integrity dat.
8. Komunikační rozhraní: Renesas Cortex-M4 mikrořadiče podporují různá komunikační rozhraní, jako je UART, SPI, I2C, CAN, Ethernet atd., což umožňuje komunikaci s různými zařízeními a systémy.
9. Široká škála aplikací: Cortex-M4 mikrořadiče od Renesas jsou vhodné pro širokou škálu aplikací, včetně průmyslového řízení, spotřební elektroniky, zdravotnických zařízení, automobilového průmyslu, a dalších. Díky své výkonnosti, nízké spotřebě energie a bohatým periferním funkcím jsou ideální volbou pro mnoho různých aplikací.

The post Arduino UNO R4 – 2023 first appeared on Hard Wired.