Olyan USB-soros átalakítót kell használni, amit az Android felismer. FTDI FT232 pl. esélyesebb volna.

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/

Ezt megerősíthetem, 1-2 hete futottunk bele egy ilyenbe, nem akart rendesen működni.

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).

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?

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).

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).

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.

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.

ü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?

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?

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.

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:


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?

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

csak

-ként jegyzem?
Vagy GCC alatt esetleg van valami __builtin függvény?

Elképzelhető, hogy hülyeséget kérdezek, de ha mondjuk Windows alá írok egy konzol alkalmazást, az futhat mondjuk egy ARM-ben?

Milyen nyelven írod? Milyen környezeti elemeket használsz? Az ARM az egy bare-metal mikrokontroller, vagy CPU operációs rendszerrel?

Watcom C-re gondoltam.

Semmi komoly, csak portokat kapcsolgatna.
Meg lenne benne egy kevés lebegőpontokkal való számolgatás.

Még egyszer: Mikrokontrolleren, közvetlenül a vason akarod futtatni vagy operációs rendszer (Linux) fölött?
Miért pont Watcom C?
Ha Linuxos ARM-ra, akkor kb bármit használhatsz, ami ott elfut.
Ha mikrokontrollerre, akkor C/C++, amit az ARM-GCC tud lefordítani (ingyen). Pénzért léteznek más fordítók is.


GPIOkra gondolsz?


Lebegőpontos számítást bármivel tudsz végezni (Intel 8051-en is). Legfeljebb mindent a CPU számol, és lassú lesz. De most már a legtöbb ARM mikrokontrollerben is van FPU. Némelyikben már duplapontosságú is

Engem a linux soha nem érdelet.
Ha lehet, nem használnék operációs rendszert.

Azért Watkom, mert ez valamennyire ismerem. Nem vagyok egy ász programozásban sem.

A cél egy egyszerű CNC valami lenne. Mondjuk, eszterga.
16 bit bemenet és 16 bit kimenet. Ezeket kéne működtetnie.
No meg valami kijelzőt.
Soros porton kapná a feladatot egy PC-től.
Lehet persze, hogy az egész halva született ötlet.

Akkor mikrokontroller kell neked.
Az ARM nem gyárt semmit. Csak CPU magokat tervez és ad el. Válassz egy gyártót, és használd valamelyik ARM magos mikrokontrollerét. Én az STM32-t ajánlom.
Watkom C az szerintem nincs beágyazott fejlesztéshez.

Valamint válasz a kérdésedre: Nem, a PC parancssorához írt program nem fog egy az egyben futni egy mikrokontrolleren.

Értem.

Köszönöm szépen a válaszokat.

Ez a panel tényleg nagyon jó lehet.
Van hozzá valamilyen dokumentáció is?

Melyik panel?

"Én az STM32-t ajánlom."

Ezt írtad.

Rákattintottam a linkre és a Hestore oldalára mutatott, ahol egy fejlesztői panel is látható.

Erre írtam, hogy jó lehet.
Olyan alkatrészekkel, aminek ilyen sűrűn vannak a lábak, én nem tudok mit kezdeni.
Nem tudom megcsinálni. Itt meg készen van. Lehet kísérletezgetni vele.

Azt a linket a fórummotor automatikusan generálja.

Közben rájöttem.
Szerintem nagyon hasznos funkció.

Igen, a bluepill nevű board jó cucc. Olcsó. Van hozzá az ST saját szoftverkörnyezete, mbed és Arduino is.
De mintha neked 2db 16 bites portra lenne szükséged. Annyi ezen nincs. Érdemes lehet egy Nucleo-t választani, 4-5 ezer ft között megvan az is. Ha leírod még pontosabban, hogy mit szeretnél, akkor szívesen segítünk választani.

Ha csak sima be- és kimenet kell, 2x16biten, érdemes shift regisztert használni, pl. 74HC595, olcsó, megbízható. Mármint ha megfelelő a feladatra.