Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Martin Sivák

Stran: [1] 2 3 ... 13
1
Vývoj / Re:Budoucnost Rust v embedded světě
« kdy: 14. 05. 2025, 15:26:04 »
Nevím, kde jste vzal nesmysl, že nezkušený vývojář v Rustu něco udělá lépe a levněji než průměrný vývojář v C (C++, Javě, Go, Pascalu, whatever...).

že programy v Rustu nejsou víc sexy, než kdyby byly napsány v čemkoli jiném. Důvodem je, že Rust nepřináší nic tak zásadního, jako bylo C oproti assembleru..

Jenže napíše a přináší. Rust přináší nejlépe integrovanou statickou analýzu, jakou jsme dosud pro nízkoúrovňové programování měli k dispozici. Tudíž i ten nezkušený vývojář se vyhne spoustě paměťových a souběhových chyb.

Nemluvě o tom, jak vypadají chybová hlášení překladače v Rustu a C/C++. Viděl jste někdy, jak moc Vás to navádí k tomu, co máte opravit?

Pro C/C++ existují nástroje na statickou analýzu, ale nikdy nebyly tak pohodlné a integrované. To samé infrastruktura kolem unit testů a vůbec správy závislostí.

Rust se prostě objevil ve vhodnou chvíli a hodně zvedl komfort a jistotu při vývoji. Nic nového na této úrovni zatím na obzoru není. Naopak Rust má za sebou firmy jako Ferrocene a díky ní i certifikaci překladače pro kritické systémy.

2
Vývoj / Re:Budoucnost Rust v embedded světě
« kdy: 13. 05. 2025, 16:52:02 »
Tohle do jisté míry platí na desktopu a na smartphonech. Ale tady se bavíme o embedded a průmyslových aplikacích, kde je situace dost odlišná. Navíc u těch příkladů nešlo o žádnou optimalizaci na krev. Tam šlo o to, jestli to píše někdo, kdo používá hlavu, nebo blbec.

..


Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho.

Embedded zahrnuje masově vyráběné jednorázové hračky i kusovou výrobu pro konkrétní speciální případ (třeba satelity). Nemůžete obojí hodit do stejného pytle, protože ty firmy optimalizují na úplně jiné metriky.

Můžete optimalizovat na určitou kombinaci

čas do nasazení - rychle něco vyrobit a získat trh, optimalizace se dělají dodatečně nebo vůbec, trošku vyšší cena hardware může být bohatě kompenzována náskokem před konkurencí.

cena podpory - optimalizace se opět dělají málo nebo vůbec, protože požadavky zákazníka se často mění a je potřeba umět rychle reagovat, proto je dneska většina věcí software-defined-něco. Software se upgraduje snáz, než hardware.

Oproti tomu můžete taky optimalizovat na druhý protipól

náklady na vývoj - absolutně co nejnižší cena za kus - levné cpu, levný vývoj, protože spotřební elektronika a nulová podpora

Ani jedno z toho nevyžaduje optimalizaci a super schopného génia, který zná všechny kličky.


Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.

Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).

Když děláme real time, tak průmysl ani nepotřebuje lepší RTT, než zhruba milisekundu. Telekomunikace jsou horší, ti chtějí max desítky mikrosekund.

Absolutní optimalizaci dělají tak možná filmová a herní studia, která potřebují nacpat novou hru s lepšími efekty na existující hardware nebo konzoli. Případně ten film vyrenderovat dřív než lidi ztratí zájem. A i ti si ten 3D engine koupí a dodělají detaily, protože je to levnější.


Takže ne, optimalizace výkonu a zabraného místa dávno není prioritou, pokud nejsou speciální požadavky. Typicky je mnohem důležitější cena vývoje (včetně platu vývojářů), čas pro nasazení a efektivita podpory a oprav na místě.

3
Vývoj / Re:Budoucnost Rust v embedded světě
« kdy: 06. 05. 2025, 11:07:46 »
Stačí, aby velké firmy angažovaly zkušené profesionály za odpovídající peníze. Vyřešilo by to i další problémy.

Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.

I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...

https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu

A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.

MISRA je dlouhodobě terčem různé kritiky, to není žádný argument. Jestli to dává, nebo nedává smysl, to nejlépe posoudím já sám.

To si klidně posuzujte. U Vašich vlastních projektů.

Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.

MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.

Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.

Teď zrovna mě nenapadá, k čemu bych to využil. Ale život mě za ta léta naučil, že umí nastolovat situace, jež nevymyslí ani ta nejbujnější fantazie. Víte, já si velmi dobře uvědomuji, jaké chyby to může způsobit, to mi tu nemusíte vykládat. Stejně jako si uvědomuji, co se může stát, když v autě přejedu dvojitou plnou čáru. V naprosté většině situací to činit nebudu. Ale dovedu si představit i situace, kdy bych to udělal, zatímco kdyby tam bylo svodidlo, tak mám situaci výrazně komplikovanější.

A proto právě máme unsafe, které to svodidlo odmontuje (v místech prokázané propasti teda nadává i tak) a dá tam jen dopravní značku. Velkou, oranžovou a s vykřičníkem.

Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.

Suhlasim s tym, ze v embedet svete Rust neprinasa ziadnu killer feature, lebo aj tak polka kodu bude unsafe (skusal som to).

Nebude. Pokud nepíšete vnitřnosti nějakého RTOS, tak se unsafe dá celkem pohodlně vyhnout ked sa clovek nesprava ako prasa.


Skor dufam, ze sa v embedet svete presadi Zig, na low-level veci, WASM a embedet ovela zuajimavejsia volba ako Rust alebo Go.

Zig se neprosadí, nemá prakticky žádnou komerční nebo komunitní podporu ani publicitu.

A to Go jste do té skupiny asi zařadil omylem.. ten jazyk má úplně jiné cíle a vlastnosti.

4
Vývoj / Re:Budoucnost Rust v embedded světě
« kdy: 06. 05. 2025, 09:18:44 »
Rust je IMHO možná náhrada za C++, nikoli za C. Jakožto embedded a low-level vývojáři mi Rust nepřináší žádné killer-features, jen mi svazuje ruce. Nemám rád jazyky, které mě chtějí školit a vodit za ručičku, svá dětská léta mám už dávno za sebou.

A proto velké firmy hlásí, že největší počet problémových chyb byl právě z oblasti správy paměti, kde C neposkytuje žádné pomůcky.

K příkladům, jež tu padly - když z jakéhokoli důvodu budu chtít znát mimo příslušný lexikální kontext absolutní adresu, na níž byla na zásobníku nějaká lokální proměnná, tak nechci, aby mi nějaký blbý překladač házel klacky pod nohy, protože mě považuje za vola. Potřebuji se soustředit na řešení svého problému, ne přemýšlet nad tím, jak přemluvit překladač, aby udělal to, co potřebuji.

Adresu si klidně získejte i v Rustu, jen nesmí opustit funkci, ve které je platná. A za vola by Vás považovaly i bezpečnostní standardy jako MISRA C.

On ten Váš problém (máte praktický příklad?) se možná dá vyřešit přímým přístupem do paměti, ale tak nějak tím riskujete celkem velkou plejádu možných chyb. Od poškození zásobníku až po přístup do náhodné paměti a záhadné pády aplikace.

Rustí borrow checker je přísný a neodhalí všechno (jak ilegální, tak legální aplikace). Proto máme i unsafe, kde je povinností programátora zdokumentovat, proč je zrovna tento trik v pořádku, aby to při code review bylo naprosto zřejmé i ostatním.

Osobně jsem stejný projekt (průměrně komplikovaný firmware a rádiový protokol pro senzorovou síť) postupně napsal v C, C++ i Rustu a i přes přísnost jazyka je ten Rust nejlépe udržovatelný.

Samozřejmě existuje třeba demo scéna nebo triky z 80. let se samopřepisujícím kódem. Některé ty výsledky byly úžasné... ale do prostředí s garantovanou bezpečností se to prostě nehodí.

5

2G tu s nami bude este dost dlhu dobu a to pre niekolko dovodov:

No.. nebude. O2 má nařízeno provozovat 2G do roku 2028: https://ctu.gov.cz/ctu-obnovil-o2-pridel-spektra-2100-mhz-zajisti-tim-provoz-site-i-pro-starsi-telefony

A může to vypnout i dřív, pokud klesne počet uživatelů pod 5%.

- Stale je este velke mnozstvo telefonov, ktore pre rozne dovody nevedia VoLTE...
- z 2G sa postupne stava IoT siet. Spolocnosti ako Secar zabespecuju monitoring vozidiel a priestorov,
- cez 2G sa casto prensaju rozne telemetricke data, napr namerane udaje z elektromeru a podobne.

To se počítá do těch 5% provozu a nikoho to nezajímá.

https://eshop.sectron.cz/2g-a-3g-site-se-globalne-vypinaji/a-6316/

Všimněte si, že v zahraničí už často 2G nemají. A globální výrobci elektroniky to moc dobře vědí.

- 2G je vo vseobecnosti prevadzkovane na nizsich frekvenciach. Tie sa lepsie siria.

Frekvence a protokol jsou na sobě nezávislé. Operátoři uvolněné frekvence samozřejmě obratem použijí pro nové protokoly.

A krom toho, to co tvrdíte už dlouho není pravda. LTE už dnes běží i na frekvencích uvolněných po NMT (450 MHz).

https://vyvoj.hw.cz/modul-eg950a-enl-pro-inteligentni-mereni-v-sitich-lte-450-a-lte-410.html

6
Sítě / Re:Více než /64 IPv6 adres u O2
« kdy: 17. 02. 2025, 19:26:25 »
A to je problém  si těch 16 triliońů rozpalcelovat na pár sektorů, třeba jenom milión? Má to nějaké technické omezení? Jde to takto provozovat s nějakou konfigurací ? Četl jsem, že to takto není uplně 100% funkční, ale jde to nějak přenastavit ,aby to takto fungovalo?

Ano, je to problém. Protože s tím nepočítá SLAAC a ten používá třeba Android (iirc).

7
Sítě / Re:Metronet končí, ke komu přejít?
« kdy: 23. 01. 2025, 10:06:20 »
Jedině, že by snad mezi nimi byla smlouva, podle které se JON, u smluv na DSL, stává právním nástupcem Metronetu. To by možná šlo, to by asi byla podobná situace jako ta, kterou jsem popsal s Dragonem. To je ale jenom taková moje laická úvaha. Zatím nemám důvod se domnívat, že taková smlouva existuje. Nejspíš ne, protože jinak by nám i ní řekli. Odvolávali by se na ni, byl by to právní základ pro to jejich tzv. "postoupení".

To se dělá běžně. Je to vlastně "rozdělení firmy" a prodej její části. Třeba Nej.cz si taky rozebrali CETIN a O2 (technologie vs. zákazníci).

Nicméně platí původně uzavřená smlouva, takže JON nemůže jednostranně změnit podmínky ohledně IP adres nebo cen. V tu chvíli by nastupovala možnost odstoupit od smlouvy atd.

Musíme počkat s čím přijdou, jakákoliv změna musí být oznámena písemně v předstihu minimálně 30 dní.

8
Software / Re:FreeCAD: vybraný objekt nelze použít
« kdy: 20. 01. 2025, 12:01:35 »
Ano, 1.0 obsahuje část řešení Topology Naming problému: https://wiki.freecad.org/Topological_naming_problem#Topological_naming_algorithm

Pořád se to může stát, pokud je změna v rodiči zásadní.

9
Hardware / Re:Relativně přesné RTC
« kdy: 05. 12. 2024, 19:05:21 »
ad 50Hz) Frekvence v síti se řídí globálně (Evropa). Odchylka může být až 0.2Hz, ale udržuje se i odckylka síťového času proti UTC. Více třeba zde, zde a zde.
Pokud u hodin dokážete zajistit, že mají stálý přístup k síti bez výpadků, tak by mělo být vše OK.

Koukněte dobře na ten graf odchylek z 2012 a 2013. Je tam vidět +100 až -160 po dobu jednoho měsíce! Stejně tak si pamatuju na https://www.idnes.cz/technet/technika/zpozdene-budiky-srbsko-kosovo.A180308_192054_tec_technika_pka - odchylka 6 minut!

Takže ani síť není spolehlivá.

RDS není spolehlivé vůbec, i když hodně záleží na stanici. Viděl jsem na svém radiobudíku, jak si stanice (ne)všímají třeba změny na letní čas.

Český Rozhlas například kdysi umožňoval synchronizaci vysílaným časovým signálem (přímo těch pár pípnutí v audiu): https://www.irozhlas.cz/veda-technologie/historie/ceskoslovensky-rozhlas-casove-znameni-vyroci-gong-signaly_2104011045_tzr a je možné že to RDS udržují splehlivé, ale jestli to i garantují nemám tušení.

Já bych zvolil DCF77 (pokud je dostatečně silný) nebo GPS. V nouzi GSM.

10
Hardware / Re:Relativně přesné RTC
« kdy: 04. 12. 2024, 09:33:05 »
DCF77 - Hodně záleží na poloze v rámci ČR. Čím blíže Německu, tím lepší signál. Nicméně i ta jedna synchronizace měsíčně je pro požadovanou přesnost dostačující. Jen to chce rozumný modul (který umí i měření fázového posunu a nejenom toho on/off signálu). Conrad dělával docela schopný s feritovou anténou.

RDS - Bacha na úlety, nemá to status garantovaného zdroje a přesnost není zaručená. Navíc taková maličkost jako změna letního na standardní čas není vždycky řešená stejně atd.

GPS - Anténa je malý čtvereček někde na konci koaxiálu a opravdu stačí jeden jediný satelit, třeba i jednou týdně (pro danou přesnost). Pokud není dlouhodobě signál, tak obvykle modul chvíli stahuje katalog.

GSM - Záleží na modulu, ale může fungovat i bez SIM karty, protože musí umět nouzové volání. Nicméně třeba mnou používaný SIM800L má tendenci se občas zaseknout a 2G se navíc bude vypínat. Takže ty 3 roky už jsou problém a bude potřeba se podívat po 5G modulech.


Co jsme se z popisu nedozvěděli je, jestli existuje v celé instalaci někde alespoň jedno vyvýšené místo pro ten radiový přijímač. Libovolný, pomůže to všem těm možnostem.

11
...  a nebo ať přejde na LoRa.

Ta LoRa by pomohla přesně v čem? Sice jede na nižší frekvenci (868 MHz), ale má v lepším případě omezený duty cycle na 10% a je to taky UHF. Takže přímá viditelnost je velkou výhodou až skoro podmínkou (pokud nepomůžou odrazy).

Krom toho typická přenosová rychlost jsou max jednotky kilobitů za sekundu.

To už může rovnou přejít na poštovní holuby, ti zvládnou obletět i překážky a IP nad nimi taky jde: https://www.rfc-editor.org/rfc/rfc1149

12
Software / Re:"bezheslové" přihlašování
« kdy: 24. 09. 2024, 11:31:13 »
- KeePassXC správce hesel (lokální!)
- Syncthing (synchronizace mezi počítači)
- Nextcloud (synchronizace pokud je potřeba i mobil)
- https://addons.mozilla.org/en-US/firefox/addon/keepassxc-browser/

- KeePassium (iOS)
- https://f-droid.org/en/packages/com.kunzisoft.keepass.libre/ (Android)

13
Hardware / Re:Pomoc s diagnostikou ESP32 + LoRa
« kdy: 17. 09. 2024, 12:01:17 »
ma na modulu priletovane piny a zamatlane epoxidem, at se mu to nepokrouti.
paradicka.

To vypadá spíš na tavné lepidlo. To není úplně neobvyklý trik. Vídal jsem ho už před dvaceti lety u značkových PC, kde tak jistili konektory.

Problém je jen s tím, aby to nerozpustilo izolaci drátů. Takže to chce to nízkoteplotní.

14
Software / Re:Software na poznámky – náhrada OneNote
« kdy: 02. 09. 2024, 14:09:16 »
A nemluvim o tom, proc ma poznamkovy blok zrat gigabajty pameti. K cemu? I ten Onenote si vystaci s par desitkami (alespon verze, co jsem videl naposledy par let zpet).

Pár let zpět není dnes. Dnes ty poznámkové bloky mají kompletní rendering, umí uložit webovou stránku (a musí ji umět zase zobrazit), umí uložit odkaz na Youtube a rovnou ho i přehrát atd.

To není textový vim. Už dávno ne.

Popravdě všechny moderní co jsem zkoušel v tomto byly stejné.

15
Software / Re:Software na poznámky – náhrada OneNote
« kdy: 02. 09. 2024, 13:42:00 »
Ok, tak Joplin žere přece jenom víc, neuvědomil jsem si, že tam pak ještě byly další izolované rendering procesy. Přece jenom je to Electron. Popravdě je těch Electron aplikací poslední dobou fakt hodně.. ono se to UI v html/css/js asi dobře programuje :)

Stran: [1] 2 3 ... 13