Beleírtam egy programomba szándékos Hard Fault generálást, és a hatodik elem adja meg a fault előtti PC-t. Így viszont FFFF.FFFE cím jön ki, ami nem lehet. Ez okozná a hard fault-ot, hogy nem létező címre megy a végrehajtás? De hogy kerülhet oda?

Nem. Az STM32 Nucleo-n lévő ST-Link csak SWD (ARM) debug protokollt ismer, ami az STM8-hoz nem jó, mivel az nem ARM.
Vegyél STM8 Nucleo-t. Esetleg külön ST-Linket, azzal STM32-t és STM8-t is lehet programozni, és hibát keresni.

(Ezt az információt a mindenki számára elérhető STM32 Nucleo kézikönyvében olvastam. Te olvastad?)

Ezek szerint nálam van zavar a fejben?

Ha lesz, időm én is csinálok ilyen asm verem tesztet. Mert eddig csak a könyvek alapján volt róla elképzelésem.

Lehet, rossz értéket kap 1 pointer, vagy kioptimalizálta a fordító az üresnek vélt szubrutinodat?
Esetleg valamelyik nem definiált megszakítás beugrik?

Pár újdonság:
STLINK-V3
Új Cortex magok: M23, M33.
Bővebben: Link

Az új Stlink az penge kis vas, bár a VCP firmware még kicsit bugos: bár 15 Mb/s kijön belőle, de van benne pár buffer túlcsordulásnak kinéző bug.

API még nincs a bridgekhez, pedig tök jó kis USB-GPIO/SPI/I2C/bármi lehetne belőle.

Portoltam egy jól működő lcd könyvtárat AVR-ből STM32 KEIL-be. Mikor késznek hittem, utolsónak kidobta ezt a hibát. Elfelejtettem, hogy a case 0x80 ... 0xFF: gcc-ben működik. Mit tudok csinálni, írjak 127 case-t?

Írj két if()-et az egész switch helyett. Vagy írj egy if()-e a default switch ágba.

Köszi! Mérgemben erre nem gondoltam.

Átírtam a HAL_Delay-t us-osra és nem ugrál megszakításba a systick, hanem csak a COUNTFLAG-et használja. A HAL-ba nem is kell belepiszkálni, mert az érintett függvények weak-ként vannak megadva, a főprogramban a függvénytörzs felülírható.Ha valakit érdekel, megosztom. 32MHz-es ST-vel teszteltem.

Kösz, érdekel.

Ezeket a függvényeket kell a főprogramhoz adni:


HAL_InitTick(0U);-al indul, ezután us-ban kell megadni az értéket a HAL_Delay-ben.

Ez a switch case range valami újabb C szabványban van, meg kellene keresni és megnézni, hogy a Keil-nek nem-e lehet megmondani, hogy olyan szabvánnyal fordítson.

Lehet, hogy van valami beállítás, de nem jöttem rá. Egy if-el megoldottam. Az avr-gcc már régóta kezeli.

Próbálgatva nekem a --gnu opcióval lefordul (uVision 4.6).
Mellesleg jó tudni, hogy van ilyen switch case megoldás is.

Érdemes viszont megjegyezni, hogy egy ilyen case 0x80 ... 0xFF: var += 10; feltétel -O0 beállítás mellett ~500 byte-tal dobja meg a kódméretet, az optimalizációt rákapcsolva csak 100 byte (-O1, -O2). A --gnu parancsnak nálam nincs hatása a kódméretre amúgy.

Kösz! Van hozzá egy GNU extensions pipa is. Egy kicsit megdobja a kódot nálam is az if-hez képest (V5).

Üdv!
Kissé megfogott ez a függvény logikailag:

Azt értem, hogy az index BCD- bináris konverzió, mert a hívás egy karakteres mutatót ad át ami BCD értékeket tartalmazó struktúrára mutat (date), de a hexa string előtte nem áll össze.

A függvény a 8 bites karakterkódot két négybites félbájtra bontja (nibble) és a négybites egységeket hexadecimmális karakterekké alakítja.

Pl. a 139, 147, 230 kódú karakterek hatására 8B93E6 karaktersort küld ki.

Hogy ez kinek és mire jó, azt nem tudom.

Rosszul írtam, BCD-hexa-t akartam a BCD-bináris helyett. ST I2C-vel ismerkedtem, így akadtam rá.:
A 436. sorban kiíratja a DS3231-ből az idő/dátum adatokat, amik BCD-ben vannak.
Bővebben: Link
A szintaktika zavart meg, tömb azonosító helyén egy sztring konstans.

Eléggé szokatlan megoldás! Kérdéses, hogy működik e?

Én kapásból beraknám char tőmbe: char *HEX[] = "0123456789ABCDEF";
Így ráadásul csak egyszer foglal helyet a memóriában.

Ráadásul a tömbindex számítás végén levő %0x10 is felesleges (gondolom a túlcímzés megakadályozása miatt rakta bele), mert ha egy 8 bites változót 4 bittel jobbra tolok, csak 0..15 közötti lehet az eredménye, ha meg & 0x0F műveletet végzek, az is csak 0..15 eredményű lehet.

Működik. A tömb a C-ben: mutató [ index ] vagy index [ mutato ]. Mindkettő megoldás használható, nincs különbség köztük. Akár azt is állhatna a fenti hex konvertáló sorban, hogy
(ch >> 4) [ "0123456789ABCDEF" ], az is lefordul és teljesen jól működik. A % 0x10 a teljesen felesleges.

Mivel a "0123456789abcdef" az egy "const char *", azaz egy mutató, a fenti megoldás teljesen jo.

És egyáltalán nem biztos, hogy kétszer lesz a memóriában, ugyanis egy jobb C fordító felismeri, hogy a két string ugyanaz, ezért csak egyszer teszi le a const memóriába.

Kösz az infót! Az zavart meg, hogy a sztringet így is megadhatom: char name[]= "0123456789ABCDEF" ez esetben a name egy konstans mutató, a másik esetben változó, de itt nincs jelentősége, mert műveletet nem végzünk vele, csak kiolvasunk. Ha jól értem a C-t

Jó neked! Elfogadja a fordítod!


Mert a keil kidobja ezzel az üzenettel:

Neked is elfogadja, csak rosszul írtad:

A hibaüzenet azt mondja, hogy te char-t adsz át a printf-nek, holott az const char * típust vár.

Köszi!
Közben rájöttem! Azért töröltem a hszt.

ui.: Most látom, hogy csak akartam törölni!
Különben van ez a formátumozás is hexa ki íráshoz: printf("%X", C);

Melyik esetben változó?

const char * p = "0123456789ABCDEF" , ebben a p egy változó. Írhatom azt, hogy p++, vagy
const char * p = "foo", de azt nem írhatom, hogy name++. Erre gondoltam. Itt nincs jelentősége, mert a name[ i ] hivatkozás *( name+ i )-re konvertálódik.

Igen, így van. És ezért cserélhető fel a [ két oldalán levő kifejezés, mert az összeadás kommutatív művelet. A K&R könyv úgy definiálja, hogy az E1 [ E2 ], az pontosan ugyanaz, mint a
*((E1) + (E2)).

Sziasztok!

STM32duino -ban (Arduino for STM32) szeretnék megszakítás kezelő rutint indítani USART1 eseményekre. Ilyen pl. a fogadásnál byte érkezett, küldésnél, pedig kiment az utolsó byte is.
Tudtok ebben segíteni?

Előre is köszönöm!