Příspěvky

1

Studium a uplatnění / Re:Začátek kariéry, zamyšlení nad penězi

« kdy: 26. 10. 2023, 11:56:30 »

a ty děláš čistě vývoj FW nebo i návrh HW od schématu po layout?

Jak kdy, nejčastěji do toho ale vstupuju už ve fázi specifikace se zákazníkem, interně pak na úrovni blokového schematu. Pak znovu MCU pinout. Pak oživení, ověření prototypu a ostrý FW, případně někdy ještě tester k oživování sériových výrobků. Layout a výrobu neřeším.

Dá se freelancovat/"švarcovat" jenom na to, že ti ta firma pošle prototyp?

Ano dá. Nešvarcuji, freelancuji, okruh zákazníků je sice už delší dobu uzavřený, protože nemám další kapacitu, ale pro každého z nich dělám postupně nové a nové projekty. Často to jsou deriváty předchozích designů, často to běží paralelně, takže jeden FW pak obsluhuje několik řad výrobků. Kde samodetekce není možná, tam se alespoň sdílí codebase.

Je 10000MD realný?

V tom co a pro koho dělám není.

2

Studium a uplatnění / Re:Začátek kariéry, zamyšlení nad penězi

« kdy: 26. 10. 2023, 09:54:20 »

4-5MD? To se asi nevyplatí, ne?

Nezávislý projekt na 4-5MD pro nového zákazníka by se nevyplatil, administrativa s jednáním apod by z toho ukousla moc. Pokud je to ale stabilní zákazník, pro kterého dělám třeba 4 velké projekty za rok od nuly, pak i takovýhle drobek navíc dává smysl, protože je to jenom jeden řádek na faktuře navíc, kterým se vyplní třeba čekání na prototyp.

Nechápu tady tu diskuzi o městech, regionech, dělám devops z domova, klidně můžu v regionu za stejné peníze vzdáleně, stejně nechci denně chodit do kanceláře. A pokud embedded nejde dělat vzdáleně, tak bych to určitě zahodil, alespoň já.

Vzdáleně to dělat jde. Ale znovu se dostáváme k tomu, co jsem psal předtím. Většina mých zakázek jde do Brna a do Prahy. A potřebuju na to vlastní vybavení, které bych jako zaměstnanec někde v kanclu řešit nemusel. Mně to tak vyhovuje, ale naprosto rozumím i těm, co radši budou jako zaměstnanci chodit do kanclu, protože to má i své výhody. A alespoň v mém případě jsem na začátku freelancování musel přesvědčit zákazníky, že to plnohodnotně zvládnu i ve full-remote režimu.

3

Studium a uplatnění / Re:Začátek kariéry, zamyšlení nad penězi

« kdy: 25. 10. 2023, 11:27:12 »

V embedded se pohybuju celou dosavadní kariéru. Posledních 5 let jako freelance. Zlatý důl a automat na peníze to není. Dostat se na 100K lze, ale průměr je výrazně, výrazně níž, alespoň v regionech. Je taky problém najít něco smysluplného mimo Prahu, Brno a možná Plzeň. Vstupní investice do plnohodnotného freelance (ne švarc u někoho v kanclu) není jen o počítači, je potřeba nějaké základní vybaverní pro vývoj - jako takové základní minimum pár měřáků, zdroj, 4ch osciloskop, logický analyzátor, kvalitní debugger a výbava na pájení. Není to katastrofa, proti třeba autodílně je to míň, ale je třeba počítat s tím, že takových 100K do začátku na vybavení mimo počítač padne.

Otázka je, co si představit pod "samostatně fungovat a dodávat výsledky" a jak daleko je okolí, které tě může rychle táhnout nahoru. Samostatně fungovat můž být "už neotravuju kolegy, když mi kompilátor vypíše chybu" a dodávat výsledky může být "za měsíc uplácám misku špaget, ve které se za půl roku nevyznám ani já sám, když se k tomu budu muset vrátit". Nechci se tazatele nijak dotknout, předpokládám, že taková katastrofa to není. Ale když si zpětně vezmu svoji cestu kvalitou nahoru, vezmu v úvahu, jak fungovali kolegové kolem mě na různých úrovních seniority, tak o schopnostech po půl roce fungování mám celkem kritickou představu. I po >>10 letech praxe, když se vrátím k projektu třeba dva roky nazpět, vnímám, že se pořád posouvám dál, ale pořád nemám pocit, že bych byl tam, kde bych si přál, pořád to není úplně ono. Když si vezmu první MCU projekt, který jsem dělal v rámci zaměstnání, tak jsem nad tím tehdy spálil cca měsíc času. Dnes bych si za to samé zákazníkovi nedovolil říct o víc než 4-5MD a kvalita by byla tak o dva řády výš.

4

Vývoj / Re:Srovnání algoritmů na prvočísla

« kdy: 07. 12. 2022, 09:48:36 »

pricom jeho otazka je uplne jasna.

Právěže není. Wasper na to upozorňuje taky. Nejsme na webu o matematice, ale na webu o počítačích. Tazatel neumí/nechce konkretizovat zadání. Nevíme, co je cílem, nevíme, jaké jsou omezující podmínky, nevíme, co je k dispozici.

Podstata je že  nezáleží na tom jestli dělení je rychlejší než modulo. Ale kolik operací dělá který algoritmus pro velké vstupní n. Přesněji operací v nejhlubším cyklu. Nebo se pletu?

Podstata je, kolik taktů je potřeba na výpočet. Resp. kolik taktů navíc oproti N je potřeba pro výpočet N+1. A zde záleží na tom, jaké aritmetické operace se budou používat, s jakými datovými typy, na jaké architektuře. "...operací v nejhlubším cyklu" - to chápu jako úvahu o vnořených cyklech (for, while), ale tak to nemusí nutně být.

5

Vývoj / Re:algoritmus na prvočísla - srovnání

« kdy: 05. 12. 2022, 07:22:03 »

Záleží na implementaci a architektuře. Záleží na tom, jestli se bude provádět dělení nebo násobení a porovnání - jestli je celočíselné násobení a porovnání na 1 + 1 takt a dělení na desítky až stovky taktů, pak zdánlivě hloupý algoritmus s násobením a porovnáním může být řádově efektivnější. Záleží na datových typech. Záleží na tom, co se myslí pod pojmem asymptoticky - matematický význam a význam v reálném světě VT je jiný. Záleží na (ne)dostupnosti paměti. Pak se to dá i spočítat nebo ozkoušet a změřit, ty algoritmy nejsou tak složité, aby se nedaly napsat.

6

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 26. 11. 2022, 12:55:14 »

Kdo se tímhle živí zpravidla už 8bity dávno opustil. Za sebe nevím za posledních několik let, že bych narazil na něco, kde by se mi po nějaké atmeze stýskalo nebo kde by nebyl kdejaký cortex ve všech ohledech lepší.

7

Studium a uplatnění / Re:Zvýšení hodinovky

« kdy: 25. 10. 2022, 14:37:55 »

Jako OSVČ diverzifikuju, tzn. i když mě jeden zákoš umí vytížit na 100%, nespoléhám na to. Aktuálně dělím čas mezi 3. Každý z nich ví, že pro ně nemám 100% času. Každý z nich ví, že nemá tolik provazu, za který by tahali, aby si mohli diktovat podmínky a já na všechny kývnul, protože o ně nemůžu přijít.

Navýšení cen řeším vždy osobně, vždy s nějakým předstihem a vždy jsem připraven na nějaký kompromis - např. stávající projekty dojedou za stávající cenu i kdyby se to protáhlo za termín zdražení atp. Zatím se to daří udržovat tak, že tam, kde spolupráce pokračuje, tam je to win-win. Ani přes win-win vztahy ne každý projekt vyjde hezky a v černých, někde to vyšlo i hodně do mínusu, ale zase je tam rozšíření skill-setu, takže investice do budoucna. A nejpoholnější je oznámení navýšení poslednímu - ostatní už kývli, jestli chceš zachovat nějaký podíl z mého času, tak to bude za tolik.

Nahrazení interním nováčkem za půlku už jsem taky zažil, ale díky širšímu rozkročení mi to vůbec nevadilo, prostě spolupráce na tuhle stranu skončila. Nemá cenu se podbízet cenou a pak se drbat za uchem, že to dělám vlastně zadarmo.

8

Vývoj / Re:Rozdělení úloh v týmu: vývoj, testování, CI/CD

« kdy: 21. 10. 2022, 08:52:26 »

Testy by mali prebehnut po merge requeste. Ak nedopadnu dobre, tak to nejde mergnut a autor to musi opravit.

PRED. Testy musi kompletne projit PRED mergem. To co jsi napsal nedava smysl.

Povedz si to este raz pomaly nahlas - "merge request" - "merge". Ak stale ostane zhasnute, tak opakuj...

Moje zkušenost ve "formálnějším" prostředí je taková, že aby vůbec bylo možné udělat merge request, musí být splněný checklist. Checklist obsahuje mimo jiné to, že to projde testy, že to prošlo přes code review atd. Připomínka od to_je_jedno je v tomto rámci naprosto namístě. Setkal jsem se i s tím, že checklist nebylo třeba splinit u commitů, jejichž message začíná na "WIP:", kde se větší featura rozdělí třeba na více commitů, aby byla v několika commitech zdokumentovaná cesta a důvod velkých změn. Jenže na takový commit zase není možné uvalit merge request...

9

Hardware / Re:Pracovní stůl

« kdy: 21. 03. 2022, 11:27:49 »

Mám sit2stand a nemůžu si ho vynachválit. Tichý, pohon s pamětí, od stolu se můžu v případě potřeby vysunout i do boku, nohy jsou ve tvaru asymetrického I - vertikální část nohy je až dost vzadu.

10

Studium a uplatnění / Re:Jak získat zaměstnání jako programátor?

« kdy: 28. 12. 2021, 13:50:17 »

Tohle má jednoduché řešení — brát jen seniory. U nás se to náramně osvědčilo.

Jakkoliv se s tím dá souhlasit a pro spoustu situací je to jediné ekonomicky zvládnutelné řešení, pokud by se tak chovali plošně všichni, seniory by nebylo kde brát, aby se jím člověk stal, musí si projít juniorní i mediorní fází. Což ale nejde, když junior nedostane šanci...

11

Hardware / Re:SPI blbne při programování

« kdy: 02. 09. 2021, 18:10:23 »

Podobný strašení jsem letos řešil, problém byl v nezarovnanem přístupu o jehož potřebě se jaksi výrobce zapomněl zmínit a ECC potom ve snaze to opravit to v reálu akorát pokazil. Po přepsání na zápis po 512B už OK.

12

Vývoj / Re:Cirkulární závislost

« kdy: 23. 07. 2021, 11:29:49 »

Nevím, jestli je to dělá přesně to, co hledáš, ale já jsem používal free nástroj arquanator. Co jsem teď hledal, jako by zmizel z internetu, ale nainstalovat se pořád dá pomocí gem install arquanator.
Použití pak

Kód: [Vybrat]

arquanator -i -o -u -l 2 -p gcc `find . -name '*.expand'`>analysis.dot
arquanator -i -o -u -l 3 -p gcc -g smells `find . -name '*.expand'>smells.txt`
dot analysis.dot -Tpng -O

Vykreslí to obrázek se závislostma, používal jsem to při přebírání legacy projektů, abych určil místa kde začít rozhrnovat špagety na hromádky. Expand soubory se vygenerují nějakým přepínačem pří překladu.
No a pak taky nástroj cppcheck.

13

Studium a uplatnění / Re:Home Office po pandemii

« kdy: 02. 07. 2021, 13:14:50 »

Jinak by tě ty myšlenky napadaly v pracovní době anebo jsi tak neschopný že nedokážes usměrnovat/ovlivňovat svou mysl, soustředění tak jak to dokážou všichni schopní. Pokud platí druhá varianta pak jsi zjevně nevhodný pro intelektuální práci neboť tvá intelektuální efektivita je velmi proměnná a nepredikovatelná(tvz. random) a to je dost na hovno.

Neskutečný. Takhle se chová snad jen hulvát, že uráží jiné. Možná to dělá schválně.

Intelektuální efektivita je do určité míry random už z podstaty. Mozek není homogenní hrouda hmoty, kterou nestačí jen nakrmit živinami a nechat někdy odpočinout. Mozek je v některých ohledech těžce asynchronní a u tvůrčí činnosti to platí o to víc. Někdy dodá výsledek zadání i po timeoutu - to je právě ten "nápad" před spaním, ve sprše apod., kdy se ani nemusí člověk snažit něco řešit, ale přijde to samo a "práce" mimo pracovní dobu spočívá třeba jen v zapsání si poznámky na zítra.

Ještě k té efektivitě: Třeba lidi s ADHD mají tu amplitudu efektivity větší, na horním peaku jsou i násobně produktivnější a kreativnější než ostatní, ale jsou mnohem citlivější na prostředí, takže leckdy se můžou jevit podprůměrní, ale oni jen nemají podmínky, aby se projevil jejich potenciál. Schopnost soustředění v suboptimálním prostředí u nich není jen záležitost vůle. V nevhodném prostředí je takový člověk za lempla, co jen kouká z okna, dopřejte mu klid na práci a ten samý člověk za 3 hodiny udělá víc než průměrný za směnu.

14

Hardware / Re:Minimální SBC

« kdy: 30. 06. 2021, 12:44:57 »

V tomto projektu má MCU 20kB RAM, využito mám méně než polovinu z toho drtivá většina na komunikační buffery mezi jednotlivými komponentami.

Pohodlně vyvíjet bez IDE je pro mě oxymoron, ale můj setup by určitě šel snadno obsluhovat i pouze z CLI.

Mám projekty založené na cmake, od ST jsem použil linker skript, system_stm32xxx.c, startup_stm32xxx.s a základní headery, abych nemusel přepisovat adresy a položky registrů a zakazovat přerušení assemblerem (core_cmFunc.h, core_cmInstr.h, core_cmxxx.h, stm32xxxx.h, system_stm32xxx.h, stm32xxx.h). Překlad pomocí gcc (arm-none-eabi-gcc). Nadstavbové knihovny typu HAL, Cube a podobné nepoužívám.

Na začátku jsem se odpíchnul od tohoto: https://github.com/jobroe/cmake-arm-embedded nyní to mám více custom, jedním sestavením se vytváří zpravidla několik cílů atd.

15

Hardware / Re:Minimální SBC

« kdy: 30. 06. 2021, 09:11:55 »

Tohle nevypadá na úlohu s linuxovým SBC. Kontinuální sběr dat a 1x za 10 minut report na server pomocí NB v rozsahu <100B mi teď včetně komunikace žere průměrně cca 300uA a ještě je tam prostor na snížení spotřeby v řádu nižších desítek uA. MCU je STM32.