Potival le tudtam húzni az értéket 6-ra. Tehát az ADC jó?

Jónak néz ki. Végig kellene menni az áramkörön lépésről lépésre, és műszerrel mérni, hogy mikor hol mekkora feszültség mérhető. Az LDR-t külön is le kellene valahogy tesztelni, hogy mit csinál. Biztos van hozzá adatlap, ahhoz kellene hasonlítani, hogy mit csinál szélsőséges esetekben (tök sötét / napfény) és egyéb fényviszonyok mellett, amihez használnád. Abból már látnád, hogy jó, vagy rossz. Azután beépítve végig kellene mérned az analóg részt, illetve ki kellene számolnod, hogy adott megvilágítás mellett milyen feszültségeket várhatsz az áramkör egyes pontjain egészen az ADC bemenetéig és ha ott egybevág a számolás a mért értékekkel, akkor a programban kell keresni a hibát. Ha próbapanelon dolgozol, akkor lehet, hogy valamelyik lyukról, csak te gondolod, hogy össze van kötve a többi résszel, mondjuk a földdel, de a valóságban (már) nem így van.
Kiegészítés: emiatt ott is mérj, ahol tápot, vagy 0V-ot, vagy egyéb fix feszültséget várnál egyébként.

Az LDR, gondolom, egy feszültségosztót képez egy másik ellenállással (pl. 10 kOhm) és a föld meg a tápfeszültség közé. Ezek rendben vannak, mind?

Igen úgy van , és kb 1 hete még tök jól végezte a dolgát aztán egyik napról másikra a minimum érték nem akar 690 alá menni, ez tök sötétbe olyan 6 és 120 között szokott lenni.

Kéziműszer megmondja, hogy ki a ludas.

Már elkezdtem méregetni

Annyit még hozzátennék, hogy ahol 0V-ra számítasz, ott mérd meg a táphoz képest is, mert a műszer akkor is 0V-ot mutat, ha csak úgy a levegőben van a bemenete. Így meg, ha a táphoz képest nem a tápfeszültséget méri a műszer, akkor ott valami érintkezési hiba van. Pl az LDR földre kötött lába, ha ő van alul a feszültségosztóban.

Sziasztok, vajon hogyan lehet ebből a szószátyár fix cím megadásból
__attribute__((section(".ARM.__at_0x2000"))) valami ilyen egyszerű
_at_fix(0x2000) formát makrózni? Nem jövök rá, mert szövegbe van ágyazva a paraméter.

A makró paraméter # prefixszel szerintem stringként illeszti be. Ha a section elfogadja két darabból a stringet, akkor működhet: https://gcc.gnu.org/onlinedocs/cpp/Stringizing.html

Köszi a tippet, ebben a formában műkszik:
#define _ADDR(FIX) __attribute__((section(".ARM.__at_"#FIX)))
Külön öröm, hogy az _ADDR kifejezés szabad volt még.

Sziasztok!

Egy devboard esetén szeretném letesztelni a külső SD-RAM-ot. Tud valaki segíteni ebben?
W9825G6KH-6 a RAM. FMC beállítva, debugger-el rátöltve, de nem olvasható a 0xC0000000.
STM32H750XBH az mcu.
ART-PI panel kínából szeretnék megbizonyosodni hogy nem rossz az IC

Köszönöm!

Sziasztok!
Hirtelen felindulásból rendeltem egy ilyen dev.boardot:
STM32MP157
800MHz, 256MB RAM, 1W fogyasztás
Van ilyen kialakításban is, hogy ha valaki kész cuccba építené:
STM32MP151-MYiR
A cél a tanulás, hogyan működik Linux-szal, esetleg bare-metal programozás. ST-linkkel lehet debugolni, ugyanazt az IDE-t lehet használni, mint a mikrokontrollerekhez.
A boardon van HDMI is, bár ezt átalakítással oldja meg.
Valakinek van már tapasztalata ST mikroprocesszorral? FreeRTOS fut rajta? Mert erre még nem olvastam megoldást. Milyen értelmes feladatokat lehet egy ilyennel megoldani, amire mondjuk az F7 nem képes? (Még nem jött meg a cucc, csak felkészülök.)

A chipben van A mag és M mag is.
Az A magon futtatod a Linuxot. Oda majdnem pont úgy fejlesztesz, mint desktop Linuxra. Ha jól emlékszem Yocto támogatást ad hozzá az ST.
Az M mag olyan, mint egy tipikus mikrokontroller. Ott használhatóak a szokásos Cube eszközök.
A perifériák szétoszthatóak az A és az M mag között.
Arra kell figyelni, hogy mindig a Linux bootol elsőnek, az tölti be a binárist a mikrokontrollernek RAM-ba. Ugyanis az MCUnak nincs boot flash memóriája.
A FreeRTOS az a mikrokontrolleren futtatható.


Almát a körtével. Az F7 egy mikrokontroller, míg a másik egy CPU, ami körül van egy komplett számítógép, és Linux fut rajta.

Még annyit az előzőhöz, hogy a fórumokon azt olvastam, hogy az ST nem támogatja az MP1 bare-metal programozását, de egy fejlesztő érdekes példákat helyezett el a Githubon, azt mutatva meg, hogy lehetséges.
A múlt héten pedig azt olvastam, hogy az ST webinar-t rendez ezzel a témával: "Maximize performance and efficiency: bare metal application development for STM32 MPUs"
Úgy tűnik, meggondolták magukat.
Egyébként a Linux kb. 7 másodperc alatt bootol ezen a vason egy fórum és a youtube szerint.

Persze, nem lehetetlen a bare-metal programozása egy applikációs processzornak sem. Kérdés, hogy mikor érdemes? Nagyon kevés olyan eset van, amikor egyetlen feladathoz brutális számítási teljesítmény kell folyamatosan. Simán lehet, hogy ha nagyon specifikus a feladat, akkor egy FPGA + MCU kombináció sokkal jobb. Aztán bare-metal módon kissé macera USB, Ethernet és hasonló dolgok működtetése. Nem lehetetlen, de kérdés, hogy megéri-e.
A 7 másodperc kegyetlen sok tud lenni egy csomó applikációban. De néha még a 2 másodperc is. Dolgozom olyan embedded Linux projekten, ahol a hálózati környezet időzítése olyan, hogy a táp megjelenésétől 500 ms időn belül kommunikálni kell, különben kizár. Akkumulátorról működik, tehát a folyamatosan bekapcsolva tartás nem játszik. Simán lehet, hogy a végén kell mellé tennünk egy mikrokontrollert is, ami intézi a hálózatot, míg a Linux bootol.
Szóval sokmindenre nagyon jó ez a cucc, sok más dologra meg nem ideális. Most is azt mondom, hogy a célhoz kell eszközt választani, és nem fordítva.

Igazad van, de ha asztali Linux-szal akar az ember szórakozni, akkor vesz egy Raspberry Pi-t magának és játszhat mondjuk Python-nal.
Én arra gondoltam, hogy van egy űr a mikrokontrollerek és processzorok sebessége között a beágyazott rendszereknél. Néha a RAM szükségessége is felmerül MCU-nál is.
Nem lenne jó egy MPU sebességét az MCU programozhatóságával ötvözni?
(egyébként olvastam, hogy elérhető real-time Linux is ehhez a cucchoz, bár még nincs fogalmam róla, hogy ez programozhatóságban mást jelent-e a "mezei" Linux-hoz képest)

vargham (2): optimalizált Linux: 600 ms bootidő youtube szerint, de ez könnyen lehet, hogy fizetős, és a te példádhoz még ez is sok. (Az FPGA-t is most tanulom. de az még inkább zsebbe nyúlós)

Nálunk a saját Linuxhoz vannak tapasztalt rendszermérnökök. Na, ők küzdenek a boot idővel. Ha nem sikerül leszorítani, akkor az én dolgom lesz betervezni a hálózatkezelő mikrokontrollert.

Mi a felhasznalasi celterulet ennek a kombinacionak?

Sziasztok, értetlenkedem. Nem úgy van hogy ha egy if(bájt && fuggveny()) feltételnél a (megszakítás által irt) bájt 0, akkor meg se nézi a függvényt? Én ehhez szoktam ,de most nem ez van. Mitől? (Optimalizálástól függetlenül ilyen)

Ez érdekes. Tudnál több részletet is mondani?

Ezt igennek veszem, szóval akkor itt hiba van Megnézem mélyebben...

Biztonságritikus kódba például ilyet tilos írni. Ott a két feltételnek külön ifben kell lennie. És ha nem egyértelmű, akkor még magyarázó kommentet is kell írni mellé.
Szerintem általában is érdemes megfontolni ezen szabályok használatát.

A "C programozási nyelv B. W. Kernighan - D. M. Ritchie" könyvben van egy ilyen mondat:
"Az && vagy || operátorokkal összekapcsolt kifejezések kiértékelése balról jobbra
történik, és a kiértékelés rögtön abbamarad, amint az egész kifejezés igaz vagy hamis volta
nyilvánvalóvá válik."
Szerintem innen egyértelmű. Ha a függvényedet mindenképp le szeretnéd futtatni, akkor vagy az if elejére tedd, vagy még a feltétel előtt futtasd le, és az eredményt tartalmazó változót tedd csak az if-be.

Elvileg úgy kell lennie, ahogy írod. Ha volatile a 'bajt' és 0 az értéke, akkor a fuggveny()-t nem hívhatja meg.

Miért lenne tilos? Ez teljesen egyértelmű 'C' kód, 100%-ban ugyanaz fordul belőle, mintha két if-be tennéd.

A biztonsági szabályok nagyon kicsi része vonatkozik olyan esetekre, ahol nem definiálja a C/C++ szabvány a fordírás eredeményét. Azok egyértelműen tilosak.
A legtöbb szabály azért van, hogy a programozók minél kevésbé nézhessék be az általuk írt kódot. Ezek a szabályok projektről-projektre változnak. Egy részüket ki lehet szűrni statikus analízissel, más részükre kódrivjúkon derül fény.

Pár egyszerű példa:

Kiegészítem annyival, hogy nincsenek abszolút érvényű szabályok, mindig az adott projekt kódolási szabályai döntik el, hogy tilos-e.
Ha a béldában szereplő feltétel első fele általában igaz az adott rendszer futásakor, vagy a második részben hívott függvényt máshonnan is hívják, akkor jellemző programozói hiba, hogy olyasmi kód is kerül bele egy idő után, aminek minden esetben le kellene futnia. Ezeknek persze egyébként is ki kellene derülniük kódrivjú során. Például a függvények nevei legyenek beszédesek, egy függvény csak pár sorból álljon, és egyetlen dolgot csnáljon, stb.

Ez eleve egy örök kérdés számomra, hogy egy projektnek vannak kódolási szabályai, vagy az adott programozónak, aki írja a kódot. Én nem nézem el a szorzás / összeadás precedenciáját, soha nem fogom bezárójelezni. Viszont van, amit igen, pedig annak is adott a precedenciája, csak nem tudom fejből, inkább bezárójelezem. Ha olyasmit kényszerítenek egy programozóra, amit nem akar, akkor azzal szerintem csak rontjuk a hatékonyságot, megbízhatóságot.

Szervezetnek/projektnek van kódolási szabálya. Ha ott akarsz dolgozni, és azt szeretnéd, hogy a rivjún elfogadják a kódodat, akkor annak megfelelően kell kódolni.


Dolgoztál valaha biztonságkritikus szoftver fejlesztésén? Egészségügy, autóipar, ipari robotika, stb?
Nem véletlenül alkották meg ezeket a szabványokat, és tették kötelezővé az alkalmazásukat ezen területen. Például egy besugárzó berendezés vezérlésében a működési parmétereket két példányban adjuk át függvényhíváskor (RAM hiba ellenőrzés), valamint minden egyes rétegben (UI, adatküldés a konzolról, adatfogadás a gépen, elektronika beállítása) ellenőrizni kell a helyességüket. Haltak már meg emberek olyan miatt, hogy a UI után már nem volt ellenőrzés... Aztán a következő rétegben valaki benézett valamit.


Ez nem kérdés. Több dolog miatt sem.
- Egy termék fejlesztésén több programozó is dolgozik. (Ez alatt azt is értem, ha ugyanaz a programozó pár hónap vagy év kihagyással nyúl a saját kódjához. Szinte idegen lesz a saját kódja.) Alapszabály, hogy a forráskódot nem a gépnek írjuk, hanem egy másik programozónak. Legyen minél könnyebben érthető. Ha nem így van, akkor növekszik a hibázás esélye. Ezt az esélyt akarják csökkenteni.
- Pont ezért szabványok határozzák meg a teljes fejelsztési folyamatot. Tervezés, validálás, jóváhagyás, implementálás, tesztelés, végfelhasználói próbák, stb. És mindezek dokumentálása.
- Ezen szabványok jó része kötelező erejű ahhoz, hogy egy orvostechnikai eszközt, gépjárművet, stb forgalomba hozhass.
- Ezek rászoktatnak arra, hogy a lehető legátláthatóbban kódolj. Ez a legtöbbször NEM a legtömörebb formát jelenti.
- Ha bármi probléma adódik a termékkel, ami anyagi kárt vagy személyi sérülést okoz, akkor jön a hatósági vizsgálat. Ahol bizony megnézik a kódot, és kihallgatják a fejlesztőket, rivjúereket, stb. Természetesen nem létezik hibátlan program. Arra kíváncsiak, hogy megtettek-e minden tőlük telhetőt azért, hogy minimalizálják a hibázás lehetőségét. Ha ilyenkor megmutatod a rizikóanalízised, a mitigációs tervedet és azt, hogy a kódot mondjuk megfelel a MISRA kódolási szabályrendszernek, akkor jobbak az esélyeid a bíróságon, mintha a saját fejed után dolgoztál volna.
- Az egy projekten dolgozók kódolási stílusa, kódjának kinézete, logikája legyen egyféle. Hiába lehet ugyanazt a feledatot nagyon sokféle módon jól megoldani, nem tud több ember együtt dolgozni, ha mindenki mehet a saját feje után.

Mindezt az orvostechnikai hardver/szofvter fejlesztésben szerzett tapasztalatom, a szabványok ismerete és kódrivjúk alapján írom. Nem állítom, hogy ez így ahogy van tökéletes. Azt tudom, hogy ez az ipar így működik jelenleg. Ezek az érvényes előírások.

Megnéztem a weboldaladat, látom sok év szakmai tapasztalat áll mögötted. Dolgoztál több érdekes helyen, kicsitől a nagy cégig. Ennek fényében még kevésbé értem ezt a kijelentésedet.
- Ahol biztonságkritikus szoftvereket fejesztenek, ott jó eséllyel MISRA C szerint kódolnak.
- Egy szervezetnél minden fejlesztőre egyformán vonatkoznak a szabályok.
- Akinek a kódja nem felel meg az automatikus ellenőrzésen, ileltve a rivjún, annak a kódja nem kerülhet be a közösbe. Ha ezek után is makacskodik, akkor nem fog az adott szervezetnél dolgozni.