Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   130 / 143
(#) jefflynn válasza kapu48 hozzászólására (») Szept 27, 2018 /
 
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?
(#) vargham válasza david10 hozzászólására (») Szept 27, 2018 / 1
 
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?)
A hozzászólás módosítva: Szept 27, 2018
(#) kapu48 válasza jefflynn hozzászólására (») Szept 27, 2018 /
 
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?
A hozzászólás módosítva: Szept 27, 2018
(#) rolandgw hozzászólása Okt 11, 2018 /
 
Pár újdonság:
STLINK-V3
Új Cortex magok: M23, M33.
Bővebben: Link
(#) Lucifer válasza rolandgw hozzászólására (») Okt 18, 2018 /
 
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.
(#) rolandgw hozzászólása Nov 2, 2018 /
 
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?
  1. void lcd_command( uint8_t d )
  2. {
  3.         HAL_GPIO_WritePin( LCD_RS_GPIO_Port,LCD_RS_Pin, GPIO_PIN_RESET);
  4.         lcd_byte( d );
  5.         switch( d ){
  6.     case 0:
  7.     case 1:   // on longer commands
  8.     case 2:
  9.     case 3:
  10.         HAL_Delay( LCD_TIME_CLR );
  11.        d = LCD_LINE1;
  12.     case 0x80 ... 0xFF:                 // set position
  13.       lcd_pos = d;
  14.   }
  15. }
A hozzászólás módosítva: Nov 2, 2018
(#) killbill válasza rolandgw hozzászólására (») Nov 2, 2018 /
 
Írj két if()-et az egész switch helyett. Vagy írj egy if()-e a default switch ágba.
(#) rolandgw válasza killbill hozzászólására (») Nov 2, 2018 /
 
Köszi! Mérgemben erre nem gondoltam.
(#) rolandgw hozzászólása Nov 3, 2018 /
 
Á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.
(#) vargham válasza rolandgw hozzászólására (») Nov 3, 2018 /
 
Kösz, érdekel.
(#) rolandgw válasza vargham hozzászólására (») Nov 3, 2018 /
 
Ezeket a függvényeket kell a főprogramhoz adni:
  1. __STATIC_INLINE void InitTick(uint32_t Frequency, uint32_t Ticks)
  2. {
  3.  
  4.   SysTick->LOAD  = (uint32_t)((Frequency / Ticks) - 1UL)/* set reload register */
  5.   SysTick->VAL   = 0UL;                                       /* Load the SysTick Counter Value */
  6.   SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk |
  7.                    SysTick_CTRL_ENABLE_Msk;                   /* Enable the Systick Timer */
  8. }

  1. void Init_usTick(uint32_t Frequency)
  2. {
  3.   /* Use frequency provided in argument */
  4.   InitTick(Frequency, 1000000U);
  5. }
  6.  
  7. HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
  8. {
  9.  
  10.         Init_usTick(SystemCoreClock);
  11.   /*Configure the SysTick IRQ priority */
  12.   HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority ,0U);
  13.    /* Return function status */
  14.   return HAL_OK;
  15. }
  16.  
  17. void HAL_Delay( uint32_t Delay)
  18. {
  19.   __IO uint32_t  tmp = SysTick->CTRL;  /* Clear the COUNTFLAG first */
  20.   /* Add this code to indicate that local variable is not used */
  21.   ((void)tmp);
  22.   /* Add a period to guaranty minimum wait */
  23.   if (Delay < SysTick_LOAD_RELOAD_Msk )
  24.   {
  25.     Delay++;
  26.   }
  27.   while (Delay)
  28.   {
  29.     if ((SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk) != 0U)
  30.     {
  31.       Delay--;
  32.     }
  33.   }
  34. }

HAL_InitTick(0U);-al indul, ezután us-ban kell megadni az értéket a HAL_Delay-ben.
(#) Lucifer válasza rolandgw hozzászólására (») Nov 3, 2018 /
 
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.
(#) rolandgw válasza Lucifer hozzászólására (») Nov 3, 2018 /
 
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.
(#) Seton válasza rolandgw hozzászólására (») Nov 4, 2018 /
 
Próbálgatva nekem a --gnu opcióval lefordul (uVision 4.6).
Mellesleg jó tudni, hogy van ilyen switch case megoldás is.
(#) Seton válasza Seton hozzászólására (») Nov 4, 2018 /
 
É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.
(#) rolandgw válasza Seton hozzászólására (») Nov 4, 2018 /
 
Kösz! Van hozzá egy GNU extensions pipa is. Egy kicsit megdobja a kódot nálam is az if-hez képest (V5).
(#) rolandgw hozzászólása Nov 20, 2018 /
 
Üdv!
Kissé megfogott ez a függvény logikailag:
  1. void USART_SendBufHex(char *buf, unsigned int bufsize) {
  2.         unsigned int i;
  3.         char ch;
  4.         for (i = 0; i < bufsize; i++) {
  5.                 ch = *buf++;
  6.                 USART_SendChar("0123456789ABCDEF"[(ch >> 4)   % 0x10]);
  7.                 USART_SendChar("0123456789ABCDEF"[(ch & 0x0f) % 0x10]);
  8.         }
  9. }

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.
  1. USART_SendBufHex((char*)&date,7);
(#) icserny válasza rolandgw hozzászólására (») Nov 20, 2018 /
 
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.
(#) rolandgw válasza icserny hozzászólására (») Nov 20, 2018 /
 
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.
(#) kapu48 válasza rolandgw hozzászólására (») Nov 20, 2018 /
 
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.
(#) benjami válasza kapu48 hozzászólására (») Nov 20, 2018 /
 
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.
(#) killbill válasza kapu48 hozzászólására (») Nov 21, 2018 /
 
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.
(#) rolandgw válasza killbill hozzászólására (») Nov 21, 2018 /
 
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
(#) kapu48 válasza killbill hozzászólására (») Nov 21, 2018 /
 
Jó neked! Elfogadja a fordítod!

  1. char crh = 10;
  2.         printf("0123456789ABCDEF"[crh >> 4]);
  3.         printf("0123456789ABCDEF"[crh & 0x0f]);

Mert a keil kidobja ezzel az üzenettel:
Idézet:
„compiling main.c...
..\src\main.c(109): error: #167: argument of type "char" is incompatible with parameter of type "const char *restrict"
printf("0123456789ABCDEF"[crh >> 4]);
..\src\main.c(110): error: #167: argument of type "char" is incompatible with parameter of type "const char *restrict"
printf("0123456789ABCDEF"[crh & 0x0f]);
..\src\main.c: 0 warnings, 2 errors”
A hozzászólás módosítva: Nov 21, 2018
(#) killbill válasza kapu48 hozzászólására (») Nov 21, 2018 /
 
Neked is elfogadja, csak rosszul írtad:
  1. printf("%c", "0123456789ABCDEF"[chr >> 4]);

A hibaüzenet azt mondja, hogy te char-t adsz át a printf-nek, holott az const char * típust vár.
(#) kapu48 válasza killbill hozzászólására (») Nov 21, 2018 /
 
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);
A hozzászólás módosítva: Nov 21, 2018
(#) killbill válasza rolandgw hozzászólására (») Nov 21, 2018 /
 
Idézet:
„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ó”
Melyik esetben változó?
(#) rolandgw válasza killbill hozzászólására (») Nov 21, 2018 /
 
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.
(#) killbill válasza rolandgw hozzászólására (») Nov 21, 2018 /
 
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)).
(#) ces98 hozzászólása Dec 3, 2018 /
 
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!
Következő: »»   130 / 143
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu