Beágyazott szoftverfejlesztők Miskolcon: Vélemények és kedvező árak

Beágyazott szoftverfejlesztő Miskolcon magánmegbízásokhoz

Beágyazott szoftverfejlesztő akkor kell, amikor egy eszköz működik, de nem úgy, ahogy kell, és ezt nem egy nagy cég, hanem egy magánmegbízó szeretné rendbe tenni. Miskolc környékén is előfordul, hogy egy okosotthon modul, egy vezérlődoboz, egy szenzoros mérő, vagy egy kisebb gép vezérlése furcsán viselkedik. Lefagy, pontatlan, vagy néha újraindul. Ilyenkor nem elég egy általános programozó. Ilyenkor olyan ember kell, aki érti a hardver közeli részeket, és türelmesen kibontja, hol csúszik szét a rendszer.

Sokan elkövetik azt a hibát, hogy a hibát rögtön a kódra fogják, és közben a tápellátás vagy a rossz kábelezés a gond. Én személy szerint szeretem az elején kimondani, hogy a beágyazott fejlesztés fele mérés. Ha nincs mérés, csak találgatás van. És a találgatás drága.

Magáncélú feladatok beágyazott fejlesztésnél

Magánmegbízásnál a firmware fejlesztő tipikusan javít, egyszerűsít, vagy bővít egy meglévő megoldást. Például új érzékelőt kell hozzáadni, pontosabb szabályozás kell, vagy a naplózás hiányzik. Sok eszköznél a gond az, hogy a prototípus működött, de a valós használatban jöttek elő a szélső esetek. A mikrokontroller fejlesztő ilyenkor nem csak ír, hanem visszafejti, mit csinál az eszköz valójában.

Gyakori kérés a fogyasztás csökkentése, az ébresztés megbízhatóvá tétele, vagy a kommunikáció rendbetétele. Bluetooth, Wi Fi, soros port, CAN, Modbus, ezek mind előfordulnak, még magánprojektekben is. Én azt látom, hogy a legtöbb ügyfél nem extra funkciót akar, hanem stabilitást. És ez teljesen érthető.

• Hibakeresés fagyás és újraindulás esetén
• Szenzorok kalibrálása és szűrése
• Kommunikációs hibák javítása és új protokoll
• Naplózás és diagnosztikai mód beépítése
• Energiafogyasztás csökkentése alvó móddal

Tipikus hibák és félreértések a hardver közelében

Beágyazott rendszernél sokan azt hiszik, hogy ha néha jó, akkor kész. De a néha jó az a legrosszabb. Volt olyan eset, amikor a kliens azt mondta, csak hetente egyszer indul újra az eszköz, az belefér. Aztán kiderült, hogy az újraindulás pont akkor történik, amikor a fűtésnek tartania kell a hőmérsékletet. Az ilyen hiba nem látványos, mégis kellemetlen.

Volt egy eset, amikor egy miskolci megbízó hozott egy vezérlőt, ami estére mindig megbolondult. Mindenki a kódot gyanúsította. A végén kiderült, hogy a tápegység melegedéskor beesett, és a feszültség esése pont a flash írás közben jött. A javítás nem csak szoftver volt, hanem egy egyszerűbb írási stratégia és egy stabilabb táp. Sok ember itt rontja el. Csak egy oldalról nézi a problémát.

Hogyan zajlik a fejlesztés és mi a kézzelfogható eredmény

Az első lépés általában egy rövid állapotfelmérés. Milyen eszköz, milyen környezet, milyen hiba. Ha van forráskód, az sokat segít, de nélküle is lehet haladni, csak lassabban. A jó embedded fejlesztő nem ígér azonnali megoldást. Inkább megmondja, milyen információ hiányzik, és hogyan lehet pótolni. Én ezt szeretem, mert így nem csúszik el a munka a harmadik napon.

A kézzelfogható eredmény többféle lehet. Javított firmware, részletes hibaleírás, mérési jegyzet, vagy egy rövid útmutató a teszteléshez. Magánmegbízásnál fontos, hogy ne maradj egyedül a végén. Ha később újra előjön a gond, tudnod kell, hol vannak a kapcsolók, hol vannak a naplók, és mit jelentenek a jelzések.

Sokszor két rövid egyeztetés többet ér, mint egy hosszú. Én a gyakorlatban azt tapasztalom, hogy ha a megbízó hetente egyszer ránéz és visszajelzést ad, akkor a beágyazott szoftverfejlesztő gyorsabban megtalálja a valós használati mintát. És a végén nem egy laborban működő, hanem otthon is stabil megoldás születik.

Minőség, tesztelés és megbízhatóság

A beágyazott fejlesztésnél a teszt nem extra, hanem alap. A hiba gyakran csak hosszú futás után jön elő, vagy csak bizonyos sorrendben. Ezért jó, ha van legalább egy egyszerű stressz teszt és egy napló. A firmware fejlesztő tud úgy dolgozni, hogy a hibát mérhetővé teszi. Ha mérhető, akkor javítható.

Szerintem az egyik legnagyobb csapda, amikor valaki gyors javítást kér, és közben nem enged időt ellenőrzésre. Ilyenkor a javítás után jön egy új hiba, mert a rendszer határon működik. Én személy szerint inkább vállalok egy plusz ellenőrző kört. Kevesebb a visszajárás, és a megbízó idegeit is kíméli.

Biztonság és adatkezelés kis eszközökben

Magánprojektnél is előkerül a biztonság, főleg ha a készülék hálózaton lóg, vagy távolról elérhető. Sok okosotthon eszköz alapból túl nyitott. Alap jelszó, nyitott port, frissítés nélküli könyvtár. A mikrokontroller fejlesztő itt nem ijesztget, hanem lezárja a legegyszerűbb réseket. Például kikapcsolja a felesleges szolgáltatást, rendbe teszi a hitelesítést, és beállítja a frissítési folyamatot.

Volt már olyan ügy, ahol a kliens csak annyit vett észre, hogy néha eltűnik az eszköz a hálózatról. A végén kiderült, hogy egy rossz automatikus frissítés többször félbehagyta a folyamatot. Ilyen helyzetben a biztonság és a megbízhatóság összeér. Ha nincs kontroll a frissítésen, az nem csak kellemetlen, hanem kockázat is.

Beágyazott szoftverfejlesztő árak és tipikus tételek

Az ár attól függ, mennyire tiszta a kiindulás. Van e dokumentáció, van e kapcsolási rajz, van e forráskód, és reprodukálható e a hiba. Magánmegbízásoknál gyakori a 2 - 6 órás első blokk, amikor kiderül, hogy merre kell menni. Tapasztalatom szerint 12.000 - 18.000 óradíj alatt ritkán lesz alapos a munka, mert a mérés és a teszt időigényes. És olcsóbban 12.000 alatt a javítás sokszor csak látszólagos. Olcsóbb 15.000 alatt ritkán látok olyan minőséget, ami hosszú távon nyugodt használatot ad.

A fenti számok irányadóak, de segítenek reálisan gondolkodni. Én azt tapasztalom, hogy a drága nem attól drága, hogy sok a kód, hanem attól, hogy a hiba ritka és mérni kell. Ha a probléma csak néha jön elő, az időt kér. És ezt jobb előre kimondani, mint utólag vitatkozni.

Hogyan válassz beágyazott fejlesztőt itt

A választásnál nézd meg, kérdez e az eszközről, és kér e konkrét információt. A jó beágyazott szoftverfejlesztő rákérdez a tápra, a környezetre, a hibajelenség pontos idejére. Ez nem akadékoskodás, hanem munka. Én személy szerint azt preferálom, ha a szakember már az elején megmondja, hogyan fogtok haladni, és milyen bizonyíték alapján dönt. Így kisebb az esélye, hogy a végén csak érzések maradnak.

A Qjob.hu oldalon érdemes úgy leírni a kérést, hogy mi az eszköz, mi a hiba, és mikor jelentkezik. Miskolc megadásával könnyebb helyi szakembert találni, de sok hiba távolról is elemezhető, ha van videó és napló. És ha van korábbi kód, azt is érdemes előkészíteni. Minél tisztább a kiindulás, annál gyorsabb lesz a megoldás, és annál kevesebb lesz a felesleges kör.