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   143 / 143
(#) icserny válasza kepitu62 hozzászólására (») Aug 5, 2019 /
 
Olyan USB-soros átalakítót kell használni, amit az Android felismer. FTDI FT232 pl. esélyesebb volna.
(#) kepitu62 válasza Peppe hozzászólására (») Aug 5, 2019 /
 
A jumperek rb. működnek, hidegen kimérve és feszültség alatt a chip lábakra a megfelelő feszűltségszinteket adja. Nálad egy gyári új ST feszültségre kapcsolásakor csak a piros led ég,
a zöld led pedig sötét mindaddig míg valami progit betoltesz?/ pl. Blink/
A hozzászólás módosítva: Aug 5, 2019
(#) don_peter válasza vargham hozzászólására (») Aug 6, 2019 /
 
Ezt megerősíthetem, 1-2 hete futottunk bele egy ilyenbe, nem akart rendesen működni.
(#) icserny válasza kepitu62 hozzászólására (») Aug 6, 2019 /
 
A Dfuse nyilván nem ismeri fel, mert az STM32F103C8T6 bootloadere csak UART módban működik.

Windows alatt STM32Flasher vagy STM32 Cube Programmer (ez utóbbi Linux alatt is működik) letöltőprogram kell hozzá, meg egy USB-soros (TTL) átalakító. A boot0 jumpert 1 állásba kell tenni. Az átalakító Tx lába A10-re, az Rx lába A9 menjen, az 5 V-os és a GND kimenete pedig értelemszerűen a "blue Pill" 5V és GND lábára menjen.

Az általad belinkelt oszcilloszkóp projekt v1.03 firmware nálam nem működött valamiért. Az 1.05 (kísérleti) firmware jól működött, de csak a feleségem telefonján (nálam 4.4 Android van, az nem támogatott (nem ismeri fel a csatlakoztatott eszközt).
(#) cross51 hozzászólása Aug 14, 2019 /
 
Sziasztok!

Egy kicsit homályos az interrupt-nál a prioritás grouping működése.
(a kérdésben vegyük úgy, hogy 4 prioritás bitünk van)

Ha a priority grouping 0 akkor van 16 db prioritásunk.

Ha priority grouping 5 (2-2 bit) akkor kap értelmet a preemt és a sub priority.
A preemt dönt vagy azonos időben vagy ISR alatt fut be más megszakítás.
A sub priority meg akkor jön szóba ha két IRQ preemt prioritása azonos.

1. Kérdés, hogy ezt jól értem-e
2. Írás közben meg találtam, hogy a 0-ás prioritás (STM32F4) a nagyobb ez globális vagy gyártó függő és akkor a preemt-re is ez vonatkozik?

És egy mellékes kérdés szerintetek van értelme emberire invertálni (kisebb-kisebb, nagyobb-nagyobb) a prioritást egy függvénnyel (én PIC-ről az emberi verziót szoktam meg) vagy inkább álljak át/szokjam meg hogy hol így hol úgy?
(#) csatti2 válasza cross51 hozzászólására (») Aug 14, 2019 /
 
Jól értelmezted. Azért a kisebb szám a nagyobb prioritású, mert az ARM mag lehetővé teszi a gyártóknak, hogy maguk döntsék el hány bitet használnak a maximális 8-ból a megszakítások prioritizálására. Ráadásul mindig a legfelső bitek használatosak (a háttérben pl. az 5-ös prioritást shifteljük 4-el balra, így 80 lesz a tényleges érték). Ez azért jó, mert ha utána olyan mikrokontrollerre fordítjuk a progit, ami mondjuk csak 3 bitet támogat, akkor még jó eséllyel működőképes marad a program (egyszerűen elveszítjük a legkevésbé szignifikáns bitet).
(#) csatti2 válasza csatti2 hozzászólására (») Aug 14, 2019 /
 
Csak azt nem magyaráztam el, ténylegesen miért is.

Na szóval, léteznek negatív prioritású megszakítások (ezek a rendszermegszakítások, pl. Hard fault). Ezek mindig fix prioritással rendelkeznek és a felhasználó nem állíthat be magasabb (alacsonyabb értékű) megszakítást náluk. Azzal, hogy az alacsonyabb érték a magasabb prioritás, mindössze egyetlen bitre van szükség, hogy ezen megszakításokat az IC-ben megkülönböztessék (3 bit megszakításnak minden modellnél garantáltan van). Ha azonban értékben magasabbnak kellene lennie akkor mindig meg kellene valósítani mind a 8bitnyi alapprioritást és 1bitnyi rendszerszintet, ami jelentősen növelné a szükséges IC komplexitást (csomó plusz kapu, miközben semmi szükség egy egyszerűbb mikrokontrollernél annyi megszakítás szintre).
(#) cross51 válasza csatti2 hozzászólására (») Aug 14, 2019 /
 
Köszi, így értelmet nyert az érthetetlen.
Ha már a szóba jött a fix 16 "égetett" IT ezek az NVIC_EnableIRQ-val nem piszkálhatóak?
pl.: SysTick-re CTRL-jében lehet engedélyezni az IT-jét.
(#) csatti2 válasza cross51 hozzászólására (») Aug 15, 2019 /
 
Az ARM megkülönböztet rendszer kivételeket és megszakításokat (ami szintén egyfajta kivétel) egymástól. A kivételek (ez ARM specifikus) egy része ki/be kapcsolható (különböző ARM regiszterekben, fejből nem tudom) és a prioritásuk megváltoztatható, egy része pedig fix (-3-tól -1-ig) terjedő prioritással rendelkezik. A megszakítások viszont gyártó specifikusak. A rendszerkivételek a CPU felől érkeznek az NVIC-be (a SysTick kivételével) a megszakítások pedig a perifériák felől.
(#) cimopata hozzászólása Aug 17, 2019 /
 
üdv.

Hogyan szoktéteok védeni a mikroproszesszorok 3v3 tápját a tápfelől érkező feszültségimpulzusok ellen? AMS1117 stabilizátorokat használok amik általában egy 5V AMS1117-3.3 ből állítja elő a 3,3-ot. Az AMS1117-5.0 nak pedig magasabb feszültségű DC_DC konverter adja a tápot 30-200V tápfeszültségből.

Néha előfordul hogy bezárlatosodik 1-1 STM32-es proci. Próbálom maximálisan bevédeni őket miden létező módon. Minden külső bemenet BAT54-es diódával védve, proci alatt amennyire lehet teli GND. 3v3 tápban 10µF kondi + minden VCC-n 100nF közvetlenül alatta. ADC bemenetek 100nF kondizottak. Digitál bemenetek is ha lehet pluszban kondizom kcsit. Ennek ellenére néhe bezárlatosodik 1-1 proci. Már csak arra tudok gondolni hogy a táp felől jövő valami megnyomja az 5V tápot. Vagy pedig a DC_DC feől átjön valami tranziens.

Mivel lehetne pluszban védeni a 3,3v tápot? 3,3v tranziens diódákat nézegettem de nekem kicsit magasnak tűnik a nyitási feszütlsgük 4V-felett. 4V meg felette lenne az abszolút maxnak.

Szerintetek?
A hozzászólás módosítva: Aug 17, 2019
(#) vargham válasza cimopata hozzászólására (») Aug 17, 2019 /
 
Bezárlatosodik? Ez alatt mit értesz?
Nálam nem volt eddig probléma ezekkel az eszközökkel.
Publikus a kérdéses NYÁK terved? Töltsd fel ide!
Pontosan melyik MCU?
Mi van még a NYÁK-on? Tápot honnan kapja? A hiba bekövetkezte után az AMS1117 még működik?
(#) csatti2 válasza cimopata hozzászólására (») Aug 17, 2019 /
 
Az AMS1117 egy régi design abból a korból, amikor még inkább tantál kondenzátorokat használtak az 1µF körül SMD méretben. Nem tudom a jelenlegi áramkörödben mit használsz hozzájuk de ha nem megfelelő az ESR akkor a táp instabillá válhat. Manapság sokkal jobb és modernebb LDO-k is kaphatóak.
Én egyébként az 5V-os sínt védeném TVS diódával, az LDO feladata lenne, hogy ebből szép stabil 3V3-at állítson elő.
Ami a külső bemenetek védelmét illeti, nem biztos hogy a BAT54 önmagában elég (sőt, akár azon keresztül szállhat el a 3V3-as buszod). Ehhez ismerni kellene a felhasználás körülményeit. Az ipari elektronikákban például többlépcsős védelmet szoktak használni.
(#) cross51 hozzászólása Aug 21, 2019 /
 
Sziasztok!

Nem igazán szeretem a gyári a controller-ek gyári függvényeit (gondolok itt az periféria könyvtárakra) mert "gyerekes" vagy nem nem tetszik az API-juk, persze ha sürget az idő nem érdekel használom azt ami van.

A könyvtár egy dolgot használhat a gyári header-ökből azt ami leírja a regisztereket és ebben a periféria clock control-ra "nincsen" támogatás, ahhoz kellene már az RCC-s header (stm32f4-ről van jelenleg szó).

Viszont alkottam egy ilyen elgondolást:
  1. static constexpr uint32_t
  2.         APB1ENR_OFFSET = ((size_t) & ((RCC_TypeDef*)nullptr)->APB1ENR) << 16;
  3.  
  4. enum class PeripheralBusClockENR
  5. {
  6.  
  7.         // *****************************************************************
  8.         // APB1 Peripherals
  9.         // *****************************************************************
  10. #if defined(RCC_APB1ENR_TIM2EN)
  11.         TIM2CLK = APB1ENR_OFFSET | RCC_APB1ENR_TIM2EN_Pos,
  12. #endif // RCC_APB1ENR_TIM2EN
  13.  
  14. #if defined(RCC_APB1ENR_TIM3EN)
  15.         TIM3CLK = APB1ENR_OFFSET | RCC_APB1ENR_TIM3EN_Pos,
  16. #endif // RCC_APB1ENR_TIM3EN
  17.  
  18. #if defined(RCC_APB1ENR_TIM4EN)
  19.         TIM4CLK = APB1ENR_OFFSET | RCC_APB1ENR_TIM4EN_Pos,
  20. #endif // RCC_APB1ENR_TIM4EN
  21.  
  22.         // ...
  23. };
  24.  
  25. static bool PeripheralBusClockIsEnabled(PeripheralBusClockENR peripheralClock)
  26. {
  27.         return (*(uint32_t*)(RCC_BASE + ((uint32_t)peripheralClock >> 16))) &
  28.                 (1 << ((uint32_t)peripheralClock & 0x1F));
  29. }
  30.  
  31. static void PeripheralBusClockEnable(PeripheralBusClockENR peripheralClock)
  32. {
  33.         (*(__IO uint32_t*)(RCC_BASE + ((uint32_t)peripheralClock >> 16))) |=
  34.                 (1 << ((uint32_t)peripheralClock & 0x1F));
  35. }
  36.  
  37. static void PeripheralBusClockDisable(PeripheralBusClockENR peripheralClock)
  38. {
  39.         (*(__IO uint32_t*)(RCC_BASE + ((uint32_t)peripheralClock >> 16))) &=
  40.                 ~(1 << ((uint32_t)peripheralClock & 0x1F));
  41. }


A kialakítás lényege annyi, hogy a define-ok nem igazán járatosak C++-ban meg enum-al sokkal kisebb az esélye, hogy hülyeséget ír be az ember valamint így nem kell tudnom, hogy melyik bit melyik register-ben van menet közben (ez meg van írva minden APBx/AHBx-re csak nem másoltam be) az enum-nak itt a hátránya mivel RSTR és LPENR nem feltétlen tartalmazzák ugyanazokat a biteket így azokra is meg kell írni az enum-ot.

Az F4-es reference manual-okat végig bújva azt láttam, hogy az ENR-re vonatkozó bitek adott perifériához mindig ugyanazon a néven mennek (és ugyanott vannak, de elvileg nem okoz neki problémát ha máshol lenne).

Kicsit hússzúra nyúlt, de a kérdés szerintetek mennyire fogok ezzel szívásba ütközni, ha adnak ki újabb F4-eket valamint kíváncsi vagyok a véleményetekre szerintetek mennyire van értelme így megoldani a dolgot?
A hozzászólás módosítva: Aug 21, 2019
(#) cross51 hozzászólása Szept 1, 2019 /
 
Sziasztok,

A Visual Studio (Visual GDB-vel) az intellisense-nek van egy header ami #define-onlja az asm (_asm, __asm, __asm__) kulcsszót (mert ezeket a VS nem támogatja) viszont az az asm volatile-al szenved van egy #define-om a debug breakpointra mennyire okozhat problémát, ha az
  1. __asm volatile("BKPT " "#0");

csak
  1. __asm ("BKPT " "#0");

-ként jegyzem?
Vagy GCC alatt esetleg van valami __builtin függvény?
Következő: »»   143 / 143
Bejelentkezés

Belépés

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