Příspěvky

1

Studium a uplatnění / Re:Uplatnění pro junior embedded vývojáře

« kdy: 18. 02. 2026, 14:58:39 »

Co opajcovali nevím, ale pro vzorkování mají vlastní 2GSps ASIC - jsou tam dva, tudíž na stejný kanál 4GSps když jedou spolu s posunutou fází hodin. Popsané pěkně v tom videu kolem 9:50. Dave pěkně vysvětluje, že variabilní náklady na ty čipy jsou skoro nulové, fixní raketa byl vývoj + výrobní masky - Rigol fixní náklady rozpouští do všech modelů a proto si může dovolit takové ceny.

2

Studium a uplatnění / Re:Uplatnění pro junior embedded vývojáře

« kdy: 18. 02. 2026, 13:15:32 »

Skvělé jsou teardowny těch (i dalších a nejen) osciloskopů na youtube  Dejva https://www.youtube.com/@EEVblog , kde ukazuje, jak se Rigol dokáže dostat na tyhle ceny. Chytrá kombinace custom ASICu (jednotného přes spoustu řad výrobce, tudíž s rozumnou cenou za kus) a levného zbytku + linux.

3

Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)

« kdy: 17. 02. 2026, 09:22:49 »

Zrovna včera jsem o tom uvažoval: je to asi totéž, jako když máte rád solidní dřevo tak se vyučíte truhlářem, chcete postavit skříň, vyberete materiál, připravíte desky, nafrézujete lišty, vyřešíte a vyrobíte spoje, pečlivě slícujete, uděláte povrchovou úpravu, přidáte kování a pak pečlivě odvezete zákazníkovi. Versus to, že vezmete dřevotřísku nebo nějaké MDF desky, nasypete do CNC nějaký předpřipravený program, celé to pak slepíte dohromady, hodíte do expedičního skladu ať si pro to Hornbach dojede a prodá to a jedete další. Ano, to druhé je taky truhlařina. Ale fakt ne svět, ve kterém chci třeba já osobně žít natož pracovat.

Každý to vidí jinak, což je samozřejmě dobře. Pro mě to umožňuje použít technologie, do kterých bych se jinak nepustil, protože steep learning curve, která by mi za jednorázové využití nestála. Příklad toho ESP - bez AI bych to lepil v Arduinním SDK, kde bych musel hodně omezit featury, protože boj s paralelním během. S AI jsem samozřejmě rovnou šel do ESP-IDF s FreeRTOS a implementoval vše, co mě víceméně napadlo, i nice-to-have funkcionality.

4

Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)

« kdy: 17. 02. 2026, 08:58:06 »

Jenom to ukazuje, že "nadšenci s AI" jsou buď začátečnici, junioři kteří s ní řeší maximálně ty běžné triviálnosti které by slušný programátor "zvládl i ve spánku" a jejíchž příkladů, návodů je na internetu požehnaně a proto je ty modely umějí.

To si osobně nemyslím. Na tomhle projektu měla AI problémy až ve fázi složitých technických algoritmů, ale ten zbytek rozhodně nebyl o "zvládnutí ve spánku", obzvláště když s tou technologií člověk nikdy nedělal.

Předtím jsem s AI dělal alsa-lib plugin spolupracující s tím Pico - dva dny. V alse sice dělám, ale pluginy jsou poměrně specialitka, opět hodně složité API. Tam byl algoritmus trošku jednodušší, s rozsáhlejší sadou testů, aby se měl čeho držet, to pro model zásadní problém nebyl.

Předtím jsem s AI dělal kontrolér ESP32 pro ovládání sauny - opět jsem nikdy ESP32 nedělal a celý program byl hotový za tři dny, včetně webového serveru s ovládáním přes wifi, renderování fontu a grafiky na TFT (vyšlo rychleji, než řešit, jakou gfx knihovnu použít). Nejvíc času strávil tím renderováním fontů, protože trochu složitější algoritmus - slabé místo LLM.

Předtím androidí appka. Sice dělám javu 20 let, ale tohle je především o androidím API, které bych musel pracně nastudovat. Tam má LLM dobrý základ. Obrazovka výpisu logů s rozdělením kritické vs. info/debug s rolováním - dvě hodiny. Webový server spouštěný po startu wifi pro zobrazení téhož vzdáleně - hodina. Přidání stránky pro servování fotek a videí ve storage - hodina + doladění grafiky dva requesty. OpenGL transformace videa dle transformačních křivek uživatelem nakreslených na obrazovku - několik dnů, protože je tam motají různé soustavy souřadnic android vs. opengl. S OpenGL jsem předtím nikdy nedělal, jenom než bych nastudoval základy...

Ne, opravdu si nemyslím, že AI nemá zásadní přínos a že to není drastická změna v oboru. Již dnes zvládá daleko víc, než triviálnosti.

5

Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)

« kdy: 16. 02. 2026, 22:16:19 »

Jasně, takže prostě dokumentace v md, ke které se lze pořád odkazovat. Na to je samozřejmě LLM skvělé.

Bohužel složitější algoritmy jsou pořád ještě boj. Dělám teď složitější věc v RPi Pico, několik spolupracujících PIO programů, spoustu DMA, fronty mezi procesory, docela složité algoritmy na bitové úrovni a tam má celkem problémy. Technologii samozřejmě umí, i překvapivě zvládá analyzovat logy vůči očekávané funkčnosti, ale na detaily algoritmů se moc nechytá. Ale upřímně by s tím bojoval i člověk, pokud nemá s tou technologií větší zkušenosti (např. já). Na druhou stranu bych se do toho bez LLM vůbec nepustil, jenom než bych nastudoval všechny detaily SDK toho hardwaru...

6

Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)

« kdy: 16. 02. 2026, 15:02:00 »

Doporučuje se postupovat tak, že dialogy s AI člověk ukládá do .md souborů v projektu, odkud si většina nástrojů umí brát kontext. AI pak bere ohled na zavrhnuté směry vývoje apod. Někdy je pak naopak problém AI přesvědčit, že otvíráme nové téma nebo novou hypotézu 

Jo, tohle je důležitá ingredience té tajné omáčky, kvůli které to některým lidem generuje užitečné věci a jiným to akorát hází klacky pod nohy.

To ukládání dialogů s AI se provádí automaticky, nebo si je člověk musí vybrat a uložit sám? Dělá se nějaké "sesypání", aby to nebobtnalo? Historie dialogů - přijde mi, že jen malá část z toho by mohla být užitečná.

Pro IDEA bych taky velmi rád viděl něco, jako dělá Antigravity - má svůj vlastní diff space, který se plní tím LLM, a ukazuje inline diff, co AI změnila - bez ohledu na to, co je, nebo není commitnuté. A pak můžu selektivně přijmout/odmítnout jednotlivé chunky. Takže commit se dá dělat logicky, kdy potřebuji, a přitom je vidět, jaké změny LLM udělalo a ještě jsi je neapprovnul. Jen to je na začátku lehce matoucí, než si člověk zpracuje ten rozdíl, kdy je kde co vidět v jakém diffu. :-)

S Antigravity zkušenost nemám. VSCode má také vrstvu změn navržených LLM a potvrzuje se to na úrovni chunku, ale přijde mi to velice nepřehledné (chunků bývá spoustu, nikde jsem nenašel seznam změněných souborů, abych si je následně sám diffnul, abych to viděl v kontextu. Navíc jak jsem říkal ten diff viewer je hodně syrový. Defakto po chvíli člověk začne potvrzovat změny hromadně, což akorát vede k zaneřádění kódu a člověk ztratí nad kódem kontrolu.

7

Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)

« kdy: 16. 02. 2026, 13:08:39 »

Presne toto - "Urobil som úpravy a,b,c ktoré si chcel" "... A ešte som urobil niečo čo si vôbec nechcel, lebo sa mi to tak zdalo lepšie".  Plus cestou ešte niečo aj pokazí a ani o tom nevie

S "přísným" user promptem se mi tohle u webového copilotu už delší dobu téměř nestává. Ale ten "přemýšlící" režim ve VSCode chatu je úplně jiný, ukecaný a utržený z řetězu, který se mi nedaří zkrátit...

8

Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)

« kdy: 16. 02. 2026, 09:41:43 »

Zatím tady nezazněla jedna rovina, která mi po nějakých zkušenostech s používáním LLM při vývoji přijde úplně zásadní.

LLM se z mého pohledu opravdu chová jako juniorní kolega, který poměrně do hloubky zvládá defakto libovolnou (veřejně známou) technologii. To je obrovská výhoda. Ale současně se musí držet na extrémně krátkém provazu. Protože rychle generuje velké množství kódu/změn (některé vynikající, některé dobré, některé špatné), jsou k ní naprosto nezbytné velice kvalitní nástroje pro review a akceptaci změn.

A na toolingu prostě narážím. Jsem zvyklý na velice produktivní prostředí v IntelliJ - udržování zatím nekomitnutých změn v samostatných changesetech a přepínání mezi nimi, snadné přesouvání kódu do shelfů. A především přehledný a snadno ovladatelný diff viewer. Bez toho se vývoj nedá pořádně dělat ani v lidech, natož s "dychtivým" juniorem AI, který diffů k review vygeneruje mraky.

Bohužel integrace IntelliJ integrace s kódovacími modely/postupy AI mi přijde hodně pozadu oproti klasice VSCode + integrovaný Copilot Chat (chápu, MS má obojí). Chat vidí na všechny soubory, čte si je jak model potřebuje, spolupracuje daleko agilněji. Jenže navrhne změny a teď co s nimi. To daleko nejdůležitější - diff viewer - je velice nepřehledný, skoro bych řekl  téměř nepoužitelný. Nemám k dispozici rozhození ucelených změn do changesetů, ani integrované shelfy, abych si změny mohl uložit pro později. Můžu maximálně co nejčastěji komitovat, abych mohl diffovat jen minimální změny (tedy tak poslední odpověď copilotu), to ale vede na zcela nepřehlednou a nic neříkající historii repozitáře, což je úplně stejně špatně. Často to pak končí "peču na to, beru všechno", čímž jde celý projekt do kopru a x hodin vývoje končí revertem a začneme znovu...

Jaké máte s tímto praktické zkušenosti? Nějak mi nejde do hlavy, že/jak by někdo efektivně dlouhodobě používal nástroje VSCodu pro efektivní review výstupu copilotu. To je pro mě největší překážkou opravdu produktivního využívání AI pro vývoj. IMO jeho schopnosti už jsou docela na úrovni, ale dostupné nástroje pro "hlídání na krátkém provazu" jsou velice nedostačující.

Takže nakonec mi produktivnější přijde vygenerovat změny ve webovém prostředí copilotu a kopírovat je ručně přes "diff with clipboard" v IntelliJ. Což je opruz, ale vede na udržitelný vývoj.

Nebo je již nějaká integrace do IntelliJ na úrovni VSCodu, ale s produktivním pohodlím správy změn v IntelliJ? Díky!

9

Studium a uplatnění / Re:Uplatnění pro junior embedded vývojáře

« kdy: 14. 02. 2026, 13:09:23 »

mi se embedded libi, ale kdyz se podivam kolik je s tim drbacky, tak radeji zustanu u normalniho pc programovani :-)

To ja na každém, co se mu líbí. Mně přijde embedded daleko zajímavější než PC, právě kvůli té HW stránce.

10

Studium a uplatnění / Re:Uplatnění pro junior embedded vývojáře

« kdy: 14. 02. 2026, 13:08:33 »

Osciloskop z práci asi ne

Tak dnes 4kanál 12bit 350MHz 4GSps stojí do tisíc eur, 4kanál 100MHz 1GSps pár set euro, zcela dostupné i pro domácí hobby, natož domácí placenou práci.

11

Hardware / Re:Počítač se nezapne se zařízeními v USB

« kdy: 17. 01. 2026, 14:44:36 »

Ano, obyč dioda tam nepatří, pokud mám v obvodu k dispozici jen 5V. Ale je řada jiných řešení, např. ideální dioda (MAX40200 drop 85mV při 1A, příp. diskrétní obvod s mosfetem, příp. kvalitní schottky), brát těch výstupních 5V z jiného napětí a započítat do toho ztrátu na ochraně, atd...

Ano, specifikace natvrdo nevyžaduje přepěťovou ochranu u USB-A, ale očekával bych, že dobré základní desky na to své USB-A porty chrání a přivedení 5V zvenku do VBUS PC nespustí (jak tu bylo již zmíněno, IMO špatný design).

12

Hardware / Re:Počítač se nezapne se zařízeními v USB

« kdy: 17. 01. 2026, 12:26:32 »

Tím „by ani neměl být napájen“ jsem myslel, že by samice neměla dostávat napájení od samce. Nikdy. Ani při vypnutém počítači, ani při zapnutém.

Nikdy, ale port by s tím neměl počítat a měl by zabránit průniku případného napětí z portu hlouběji do PC, diodou nebo jinak. Stejně tak by neměl připojit své napětí, pokud je tam jiné z venku.

13

Hardware / Re:Počítač se nezapne se zařízeními v USB

« kdy: 12. 01. 2026, 07:56:46 »

To je zajímavé. ATX +5VSB má doporučených min. 2A, na webu se píše o minimálních 720mA, myš si nevezme víc než 500mA povolených na USB-A (i to by byla myš s vytápěním). To už je na reklamaci vadného zdroje...

14

Hardware / Re:Počítač se nezapne se zařízeními v USB

« kdy: 09. 01. 2026, 12:36:03 »

IMO je tahle oblast docela komplikovaná. AI mi říká, že OTG USB-C nesmí připojit VBUS portu k napájení, dokud nezdetekuje Rd na CC lince - tj. připojené device. Současně ale signalizuje svůj "intent" hostitele připojením Rp CC na interní +5V, aby druhá strana viděla, že chce být hostitelem. Toto připojení nemá být trvalé, ale pravidelně to má odpojovat, aby mohl zdetekovat, že druhá strana chce také být hostitelem (jinak nemůže poznat Rp na druhé straně, protože by byly obě strany připojené Rp na 5V).

Ale současně AI říká, že každý hostitel by měl před sepnutím napájení do VBUSu zkontrolovat, zda druhá strana tam neposílá napětí. To platí i pro USB-A hostitele které nemají žádnou CC na komunikaci. Současně musí zajistit, aby se přicházející napětí z portu nedostávalo dál do zařízení.

Tudíž mi přijde, že v tomto případě jsou na vině obě zařízení - ten Rode nemá aktivovat VBUS, dokud na CC nevidí device, a ten PC host (který má USB-A  a tedy VBUS pod napětím před připojením Rode) by měl zabránit příchozímu proudu jít dál do PC (natož se z portu nechat napájet).

Ale pak chápu, že se dobře udělané PC odmítne spustit, když na USB portu zdetekuje příchozí VBUS, což tam nemá co dělat (OTG USB-C Rode to tam nemá co pouštět).

Ale možná jsem to pochopil blbě...

15

Hardware / Re:Počítač se nezapne se zařízeními v USB

« kdy: 09. 01. 2026, 08:54:13 »

Co tedy ten Rode konkrétně dělá, že dokonce způsobí poškození napájení portu? Odebírá větší proud, než kolik udává jeho deskriptor (resp. > 500mA)? Překvapuje mě, že by port neměl nadproudovou ochranu. Díky!