Szia!
A sok beállítás alatt azt értettem, hogy egy port kimenet legyen, egy csomó paramétert kell beállítani.
EZT a videót elnézve legalábbis, egy szimpla 8bites AVR után soknak tűnik.
Akkor próba majd EmBitz és egy csomó példa lehúz

Szimpla 8 bites AVR alatt gondolom nem találkoztál az ATXMEGA családdal (már ott is jóval több minden volt mint az ATMEGA-nál).
Az a sok beállítás lehetővé tesz rengeteg olyan dolgot, amihez különben további hardver elemeket kellene betenni, az SPL használata pedig megkönnyíti a portolást az F0, F1 és F4 családok között. Amíg nem jön ki a LowLayer addig nálam marad az SPL, illetve a direkt regiszter piszkálgatás (ahol megéri a plusz macerát).
Egyébként úgyis copy-paste lesz később a konfigurációd. Az újrahasznosítást pedig megkönnyíti, ha nem direktbe hivatkozol a portokra, hanem definiálsz beszédesebb neveket és összegyűjtöd őket egy külön header fájlba, pl.:

Majd a C fájl:

F1-hez a GPIO-t én így oldottam meg.
A header file:


A c-ben pedig így lehet felhasználni:

A while(1) után nem kell a pontosvessző (csak már nem tudtam javítani) !

Nem rossz megoldás. Mondjuk én maradok az SPL funkcióknál, ahol lehet (úgy értem, nem rejtem őket makrók mögé), bár vmiért eddig nem jutott eszembe makrókkal összefűzni a leszármaztatott elemeket (pedig rendszeresen használom ilyesmi célra a makrókat , lásd példa: )

Sziasztok!

Milyen grafikus könyvtárat használtok vagy tudnátok ajánlani STM32 mikrokontrollerekhez GUI fejlesztéshez?

Sziasztok!
A kereső szerint senki nem akarta idáig a sleep módokat használni, vagy nem szívott vele, én viszont igen, ezért gondoltam megosztom mi kell, hogy működjön. A három alvó módból a stop módot akartam használni, ami nagyjából mindent megállít, de pl. az sram, az rtc működik tovább. Felébreszteni ebből megszakítással, vagy eseménnyel lehet, és ott folytatódik minden ahol abbamaradt. Az eseményben az a jó, hogy nem kell hozzá megszakítást generálni, megszakítást lekezelő rutint írni, miközben ugyanazokkal a bemenetekkel, vagy belső még működő perifériákkal lehet kiváltani, mint egy megszakítást. A szükséges lépések:

Ha GPIO az ébresztő jel forrása (nekem az, ezért ilyen a példa):

Szükséges GPIO-k bekapcsolása és bemenetként definiálása
SYSCFG regiszterek engedélyezése a megfelelő RCC regiszterben.
SYSCFG->EXTICR regiszterekben a GPIO-k beállítása

EXTI regiszterek beállítása:
EXTI->RTSR beállítása, felfutó él detektálásához (opcionális, de legalább az egyik kell)
EXTI->FTSR beállítása, lefutó él detektálásához (opcionális, de legalább az egyik kell)
EXTI->EMR beállítása, hogy eseményként (event) érzékelje
(EXTI->IMR ha irq-t szeretnénk, de ezen a vonalon nem mentem végig)
EXTI->PR-t törölni (csupa egyest beleírni. Ha másra is használva van az EXTI, akkor lehet, hogy finomabban kell.)

A fenti kódrészletben látszik, hogy a CMSIS rutinját használtam, ami pár dolgot még beállít, de ha csak simán meghívtam nem ment el az uC aludni. A procinak van egy titkos kis bitje, ami jelzi ha esemény történt, és ha az 1-ben van, akkor a WFE utasítás nem tudja elaltatni. Annyit viszont megtesz, hogy törli ezt a bitet, így egy következő WFE (ami ott van a függvényben) már el tud menni aludni. (Na ehhez kellett egy félig kínai, félig angol nyelvű oldal elejtett megjegyzése...) Az lutri, hogy az említett státusz bit milyen állapotban van (lekérdezni nem lehet), ezért az első WFE előtt 1-be kell állítani, nehogy az is elmenjen aludni. (Nem biztos, hogy az ébresztő esemény két leálláson is keresztül tudja verekedni magát.) Erre a SEV utasítást lehet használni, aminek az a feladata, hogy multiprocesszoros rendszerben a többi processzornak ébresztő jelet küldjön. Erre esetleg figyelni kell, de nálam ez nem jelent most problémát.
Az altatás lelövi teljesen a PLL-t, ezért ha nem közvetlenül HSI-ről megy a rendszer, akkor újra be kell állítani az órajelet. Egyik timer-t megszakításhoz használtam, azt nem kellett letiltanom, vagy újra konfigurálnom, ébredés után dolgozott tovább probléma nélkül. Stm32f407-esen kísérletezek.

Ez hasonlóan működik Cortex-M3-nál is, csak ott oda kell figyelni, hogy a régebbi revíziók bug-osak és nem mindig állítják be az event bitet, ezért a megszakítások végére oda kell biggyeszteni a __SEV(); -et.

Ezt jó tudni, de ott még nem tartok, hogy értsem miért jó, ha a megszakítás végén 1-be kerül az a státusz bit? Kinek lesz arra szüksége? Gondolom a szoftver egyik fele inkább változókon keresztül dumál a másik felével.

Azért kell, mert beragadhat a program a WFE-n és nem folytatja a futást a megszakításból való visszatéréskor (mint írtam ez egy bug, ami az első pár revíziót érintette).

Akkor hiba esetén pont egy SEV-WFE végrehajtás között jött az irq, vagy egy már WFE-vel altatott procit felébresztett, de az azonnal vissza is aludt, amikor az irq rutin befejezte?

Utóbbi.
Ezért is használom a fenti makrót a megszakítások definiálásához, mert így könnyen hozzáfűzhetek a megszakításaim elejéhez/végéhez kiegészítő utasításokat szükség esetén (pl. DSB, ISB, SEV, stb.) anélkül, hogy mindenütt át kelljen írnom őket. A fenti példában pl. egy kimenetet billegtettek, hogy egy logikai analizátor segítségével megmérhessem a megszakításokban töltött időt.

Értem. Szép makró! Azt hiszem sokat fogom tanulmányozni.

Üdv.

2. processzorral járok úgy hogy visszaküldték az áramkört mint kiderül bezárlatosodott az SMT32 a panelen. Nem igazán értem hogy mi a kiváltó oka. A 3.3v tápot egy ld1117-33 ról kapja az pedig egy ld1117-5.0-ról mindegyik jó szépen csinálják az 5v és 3.3v-ot. Túlfeszt kaphatott volna valamelyik bemenetéről? Igazából nem szoktam diódázni a bemeneteket hanem teszek a bemenetek elé egy minimum 2k-s ellenállást és a maradékot rábízom a belső diódákra amik a táp felé mennek. Mi lehet a baj? Hasonló valakinek?

A belső diódákra bízni a védelmet talán elmegy egy hobbista prototípusánál, de nem olyan áramkörnél, amit árusítasz. Mondjuk a leírásodból biztos nem mondjuk meg mi lehet a probléma. Talán ha mellékelnél egy kapcsolási rajzot, illetve leírnád milyen körülmények között használják az áramkört (ipar, iroda, otthon, kültéri).

Erre szokták mondani, hogy együtt sírunk, együtt nevetünk!

Erősen ipari, viszont össz vissz 2 külső bemenete van (1 analóg és egy digitális) minden más az áramkörön belül mozog. Minden analóg bemenet 0-3.3v közti tápról kapja a jelet (műveleti meg potik a panelen). PWM kimenetek vannak még amik használ a fetmeghajtó.

Egyetlen nagyobb mért jel a tápfesz ami 22k/1k leosztással megy maximum 50V-ot mérek.
A külső potiról kapott jelet 4k7 ellenállással előtétezem a digitálisnál is 4k7 viszont ott elég furán van az ST bemenete mert PB4-es lábnál most, hogy eszembe jut nincs a táp felé diódázva hanem Vcc+4V-nál megfogja ha van valami.

Nem mondom hogy ez lehetett a baj de megnyugtató lenne találni valamit.

Továbbá minden ADC bemenet 100nF al földelve van ami az EMC zavarokat végképp elnyomja. Egyedül a digitális bemenet aggasztó ilyen szempontból.

A fel nem használt lábakat szoktátok konfigurálni pl bemenetnek leúzóellenállással?

Ipari, és mégis kihagytad a védődiódákat... A katonain kívül nincs is nagyobb igénybevételű terület.

A bemeneteid a képen látható módokon védheted meg. Első fokozatként használj zener vagy TVS diódát (szupresszor). Az első ellenállás nagyobb teljesítményű TVS dióda esetén opcionális (de ártani nem árt). A második ellenállásnál figyelembe kell venni a TVS/zener dióda max. feszét, hogy becsülni lehessen a max áramát a schottky diódáknak (az ehhez tartozó nyitófesznek kell 0,3V alatt lennie). Ha túl nagyok az ellenállások, akkor az viszont hibaként jelentkezik majd a diódák szivárgó árama miatt.

Érdekes lehet még, hogy leválasztottad-e a digitális és analóg földedet a teljesítmény, illetve bejövő jelek földjétől (és ha igen, hogyan).

Ha 5V toleráns a bemenet, akkor nincs is dióda a 3.3v táp felé. Az ESD diódák meg ESD ellen védenek csak.

Oké, ezeket akkor legközelebb figyelembe veszem.

Sziasztok!

CooCox és STLinkV2 esete forog fenn. Lefordítom a programot, nincs hibaüzenet,majd amikor debugolni akarom,akkor :
Error: Failed to open flash driver file
Program Download Failed ! hibaüzenet fogad. A rendszer mfizikailag nem hibás, jól van összekötve,mert EmBitz letudja tölteni és működik is.
Mi lehet az ok és hogyan lehetne elhárítani? Járt már más is így?

Helló Urak!
Kíváncsiskodnék.
Van valakinek Dallas 1-wire driver a birtokában?
Semmi különös, csak send, recieve, ennyi

EmBitz.
A Session Start/Stop-al letölti a programot ugye?
Mert látom, hogy a rákötött led villog, tudom a villogás sebességét változtatni,stb.
De szokás szerint jön a DE ! ha megszüntetem a proci tápját (kihúzom az usb-ből) és újra tápfeszültség alá helyezem, nem történik semmi. Az addig múködő/villogó led megszűnik életjelet adni. Ez nem tetszik Hogy lehet ezt kiküszöbölni?

Release módra váltasz és úgy töltöd fel. Ha úgy megy, akkor nézd át a beállításaid a debug módhoz.

DS18B20-hoz írtam még anno, használd egészséggel
GPIO konfigos, timer vezérelt.

Kipróbáltam Relase módban is, ugyanaz a helyzet.
Kipróbálgattam, hogy ha a boot jumpereket pakolászom,mi történik, de semmi változás.

A debuggert bedugva hagytad, vagy kihúztad? Milyen fejlesztői kártyát használsz?

Szia!

A board-ot a programozó (STLinkV2) látja el 3,3V-al.
Minkét esetet próbáltam.
a; debuggert kihúz USB-ból, minden áramtalanít.
b; debugger bedugva maradt és csak a debugger és target közötti 3,3V szakítottam meg.

Mindkét esetben ugyanaz az eredmény.

Ilyen lapot használok. Amiben STM32F103C8T6 proci van.