Próbáljátok ki az LPC-Expresso-t. Nagyon jó.
J-Linket is kezeli, (az meg sokkal gyorsabb mint ULINK2), szóval nagyon ott van.
És szerintem jobb, "tömörebb", plugin board-okat lehet vele kapni.
Hátrány: STM jobb users manual-okat csinál.

Hát nincs agyondokumentálva az biztos,viszont a fejlesztő környezet nagyon egyben van.

A KEIL-el sincs gond. Puritán, de pont ez a jó (nekem) benne.
A LPC-Open-t hozzá lehet párosítani a KEIL-hez (az bezzeg jól van dokumentálva).

Az elmúlt hetekben én is nagyon sokat néztem az ebay-t, hogy mik vannak és mennyiért. Az STM32F429 DISCOVERY egy nagyon kellemes, full extrás cuccnak látszik, talán még túl nagy is, ha az ember kifejezetten apró, mikrovezérlőre kitalált feladatokban gondolkozik. Egyébként az összes ilyen DISCOVERY panel szimpatikus volt leírás alapján.

Én elővettem a korábban már beszerzett LM4F120 Launchpad-et (ez még a régi CPU-val szerelt, nem a Tiva-C, bár elvileg ugyanaz, mint a most is aktív Tiva-C Launchpad, az most 7e körül vehető meg) és egy LC Studio-s STM32F103RB-vel szerelt demo boardot (ez olyan 2.5e Ft). A Launhpad-en ráépített TI-ICSP van, így azon keresztül a programozás, debugolás megoldott. Kínából időközben megjött egy JLink-OB (~2e Ft), ezzel kiválóan megy az STM32 programozása, debugolása. Most éppen azon ügyködöm, hogy a JLink-kel is megszólítsam az LM4F-et, és a TI ISCP-vel az STM32-t. Elvileg a Tiva boardon lévő ICSP-t lehet külső eszközhöz is használni programozóként, és külső programozóval is meg lehet támadni a Tiva boardon lévő LM4F-et.

Én Linuxot használok, azon fejlesztői kötnyezetként Eclipse-et telepítettem, ez alá izzítottam be a GNU ARM-es tool-okat és a GDB/openocd-t. Azért azt hozzá kell tenni, hogy rengeteg doksit elolvastam mostanában, hogy a kezdeti homályos dolgokat kicsit kifésüljem magamban. Elolvastam az ARM Cortex-M3 és Cortex-M4 leírásait, aztán a konkrét mikrovezérlők adatlapjait. Az STM32 esetében az adatlapon csak általánosságok vannak, ott a családhoz tartozó reference manual-t is forgatni kell sűrűn. És persze nem kellett túl sok idő ahhoz, hogy elő kelljen vennem az ARM (thumb2) utasításkészletet is, úgyhogy azzal is kellett ismerkednem.

A tanulás közben ért pár meglepetés, mint például kiderült, hogy a Cortex magoknál induláskor nem utasítások vannak a memória elején a vektortáblázatban, hanem ugrási címek. A korábban végigrágott, bare metal ARM programok írásáról szóló cikkekben lévők így kicsit át kellet értékelődjenek: mégsem minden "ARM" egyforma. A másik érdekesség, hogy ezek a Cortex magok egyáltalán nem értik a klasszikus ARM utasításokat. Nagyjából világossá vált viszont a vektoros interrupt kezelő működése, bár ott is értek meglepetések: az STM32F103-nál (Cortex-M3) nem lehet a vektortáblát áthelyezni, ez az LM4F-nél simán működik (Cortex-M4), és ahogy talán az LPC1788 doksiban olvastam, ott is menne (Cortex-M3). Ezen kívül a processzormaghoz kapcsolódó perifériák is teljesen gyártófüggők (nekem egyelőre a TI kicsit könnyebben emészthetőnek tűnik ebből a szempontból, mint az STM32).

Én itt az önképzés közepette viszonylag hamar arra a gondolatra jutottam, hogy a mikrovezérlő flash-be írjak olyan startup kódot, ami a vektortáblát áthelyezi a RAM elejére, és a felhasználói programokat, amikkel kísérletezek, azokat egy olyan linker scripttel linkelem, hogy minden részük a RAM-ba kerüljön. Így nem nyúzom minden egyes apró javítás után a belső flash-t, nem kell aggódni azon, hogy hányszor fordítom újra vagy indítom el a debuggerrel. Erre a célra viszont nagyon hasznos olyan mikrovezérlő típust választani, amiben "elég sok" belső RAM van ahhoz, hogy elférjenek benne azok a programok, amiket fejleszteni szeretnénk. A 429DISCOVERY pont emiatt tűnik kiválónak, bár abba talán már egy komplett Linux is elférne.

Nekem elvileg még fog pár filléres kacat is érkezni a távolból, azok között lesz Cortex-M0 board is, ami kb. egy 24 lábú DIP IC-hez hasonlatos "core" kiépítés. Nomost egy ilyet meg lehet venni 1000Ft körül, de valószínűleg sokkal rugalmasabban, sokrétűbben tudom minden apró csip-csup gondolatomhoz felhasználni majd, mint egy 1000Ft-os PIC-et. Arról nem is beszélve, hogy a GNU C és a nagyon hasonló "nagyobb testvérek"-en történő fejlesztés miatt valószínűleg a programfejlesztés is gyorsabb lesz.

Hmmm... Az abszolút bare metal-os minimal programomat először a TI Launchpad-re barkácsoltam, majd amikor megjött a JLink-OB, akkor azt gondoltam, hogy pikk-pakk átviszem majd az STM32-re. Hát ahogy azt Móriczka elképzeli

Ugye ott kezdődött, hogy a nem ARM által specifikált perifériák teljesen gyártófüggők, ezért már rögtön a startup-nál az oszcillátor beállításoknál elkezdtem bújni az STM32 manualokat. És hát a regiszterleírásoknál a base-hez képesti offset szerepelt mindenhol. A regiszterblokk base adressét valahol teljesen máshol, a memory mapping-nál találtam meg a doksiban. Kicsit meglepődtem, mert a TI doksiban ott volt kéznél, egy helyen minden, ami kellett.

A másik, amit "hiányoltam": timer teljesen alapeset, "one-shot" időzítésének felprogramozására példa vagy legalább egy lépéssor. Még korábban a PIC-es doksikból emlékszem rá, hogy voltak inicializálási példák a leggyakoribb esetekre, hogy ne kelljen végigbogarászni a kb. 40 regiszter leírását tüzetesen. Még a TI doksiban voltak lépéssorok arra, hogy egy ilyen egyszerű feladatkor melyik regisztereket kell felprogramozni. Az STM32-nél nem láttam hasonlót.

Ettől függetlenül persze jók a doksik, sőt, kötelező olvasmányok, csak gyártónként más a nyelvezetük, kicsit a felépítésük is, és ezt meg kell szokni.

Milyen környezetet használtok STM32 programozásához?

- nekem a mezei C a struktúráival nehézkesnek tűnik (nem fejben tartható)
- a libmaple egész használhatónak tűnik, a kérdés, hogy mennyiben korlátoz maga a library

Olyan lib érdekelne, ami az ADC-t, PWM-et, USART-ot, DMA-t,... támogatja. Magyarul egyszerűsíti előre megírt függvényekkel a használatot és fejben tarthatóvá teszi.

Nem egészen érem.
A fejlesztői környezet, az "pofa" kérdése. Én Keil-t használok, mert nincs agyonbonyolítva mint az ECLIPSE, de ha a NETBEANS alá lehetne összeütni valamit azonnal váltanék.
Amiket írtál az nem fejlesztői környezetről szól, mert egy switch-case mindenhol ugyan úgy néz ki begépelve.
Ami a te "bajod" lehet az a BARE-Metal kontra CMSIS (NXP alatt esetleg az LPCOpen.
Rossz hírem van, nincs kitaposott út.
Én a CMSIS-t kerülöm mint a tüzet, fentebb volt taglalva miért.
Nem hiszek nagyon az előre megírt LIB-ekben, csak akkor ha olyan írta akit már láttam élőben, (azaz fel tudom hívni és tudom hol lakik).

Ami perifériákat említettél, azok a legegyszerűbbek közé tartoznak, nem nevezhetők egy lapon egy SDIO-val, esetleg egy CAN modullal.

Ha tényleg nagyon nagyon egyszerűen akarod ezt az egészet megúszni akkor MikroE-t ajánlom ott a MikroC-t. Oly annyira beépített függvényei vannak hogy:
-Soha nem fogod látni hogy mi történik belül.
-Soha nem fogod tudni hogy a függvény a bolond vagy te.
-S ha már kiidegeskedted magad, ott is eljutsz odáig, hogy magad uram...

Köszi, átnézem.

Igen, tényleg nincs kitaposott út. Nálam a regiszter-állítgatás nem jön be, mert jobb szeretem érthető formában látni a dolgokat (arról beszélek, amikor egy struktúrát felépítenek egy regiszterre).

Igazából ingyenes dolgok érdekelnek, de lehet, hogy maradok az Arduinonál.

Nekem a véleményem az, hogy legyenek előre megírt rutinok, amik azonnal mennek. Csak azt kelljen megírni, ami valamilyen okból kifolyólag nem működik a könyvtárak segítségével.

De észrevettem már, hogy ahány könyvtár, annyi elnevezéssel megy ugyanaz a regiszter, szóval tényleg nincs bejáratott út.

Szerintem amire te gondolsz, az az ingyen fejlesztes. Te megmondod, hogy mit szeretnel, a fejleszto meg megcsinalja. Igy neked nem kell erteni hozza, nem kell ismerni a regisztereket, stb. Csak ezt ingyen nem sokan vallaljak...

Nem, amire én gondolok, az a Nokia bukására és a Google szárnyalására hasonlít.

A Nokia dollár milliókat ölt egy Symbian nevű hulladékba, amit a fejlesztők utáltak, kárpótlásul fizetni kellett nekik rendesen, hogy ne mondjanak fel, lassan haladtak az új alkalmazások kiadásával, de baj nem volt mert piacvezetők voltak.

Aztán jött a Google és az Android. A Nokiának esélye sem volt, mert olcsóbb Java-t ismerő fejlesztőkkel gyorsabban, szerintem negyedáron haladtak. Pusztán a nyelvből kifolyólag a Nokia a versenyben eleve kudarcra volt ítélve, annak ellenére is, hogy piacvezető volt.

Ennyit ér egy jó keret-rendszer, jó library-k. Nem a hulladék takarításával foglalkozol, nem azzal, hogy most melyik regiszterbe mi a frászhalált kell beírni, hanem hátradőlsz, megadod az SPI frekvenciáját, 0-ás módban, azt hogy mesterként viselkedsz és küldöd az adatot.

A program kész fél óra alatt, a regiszterírogatók meg mehetnek a munkaügyi központba segélyért.

A Nokia kizarolag abba bukott bele, hogy a mikorofostol odament egy mokus fonoknek, aminek hirere masnap leesett a Nokia reszvenyek ara 7%-kal. Ez azert onmagaban is jelet valamit. Aztan amikor a vindozfon miatt a Nokia piacreszesedese a beka .. ala esett, akkor az egeszet megvette kilora adolf bilgec. Az osszes know-how-t, technologiat, mindent. A Nokia, ha nem megy oda az a mikrofosos CEO-nak, akkor ma az egyik vezeto Androidos gyar lenne, mert a HW-ei jók, es (szerintem) azt ok is belattak volna, hogy az - egyebkent annyira azert nem rossz Symbian - nem lett volna versenykepes az Androiddal vagy az IOS-szel szemben. Nekem 1996 ota most van a 3. (harmadik) telefonom. 2110i, 6110i, 6310i. A jelenlegi 12 eves, es koszoni szepen, meg mindig elmegy 1+ hetet egy toltessel az eredeti gyari akkuval. Es kisebb, mint ezek a mai tepsifonok. Email-t nem lehet rajta olvasni, fenykepezo sincs benne, de telefonalni es SMS-t kuldeni lehet vele akkor is, ha ugy mentem el nyaralni, hogy nem vittem toltot. Vegulis ez telefon es nem zsebszamitogep. Ennyit a Nokiarol.

A programozasban nem allok le vitazni, mert ertem, amire gondolsz, eleg nagy problema ez a szakmanak. Marmint a sok kokler, kozepiskolas, asztalos, aki nem ert hozza, csak 1000 Ft-os oraberert osszehuzgal xbezikben vagy nemtudom milyen grafikus izeben valamit mikrokontrollerre es azt hiszi, hogy ert a fejleszteshez. De fogalma sincs rola,hogy mi az a stack, RAM, vagy egyeb alapfogalmak. Ez a mindent keszen vegyunk, illesszuk ossze, nem kell tudni, hogy mitol megy, csak gyorsan adjukl el, ami lenyomja a szinvonalat... Es egy ido utan mar nem is keresik a szinvonalas munkat, mert a managereknek teljesen termeszetes, hogy ha atallitasz valamit a vindozon, akkor ujra kell inditani az egesz gepet. (Jol neznenk ki, ha kernel cseret es HW javitast leszamitva barmi miatt is ujra kellene inditanom a linux-os gepeimet.) Es el lehet adni 10 millio forintert (!) ugy egy oszcilloszkopot, hogy a gepkonyv azzal kezdodik, hogy "erosen javasolt egy virusvedo szoftver telepitese". Az oszcilloszkopra! Hat az eszem megall! Es ezt siman le lehet nyomni az emberek torkan. Hat hova jut igy ez a vilag?!

Olyan, mindenre hasznalhato keretrendszert sosem fogsz talalni, amihez nem kell erteni. SPI. Az ugye attol fugg, hogy mit akarsz. Mert lehet, hogy 8 bye-os BURST-ok kellenek, de lehet, hogy folyamatos stream, de lehet, hogy egy byte ki, egy byte be, akarmi. Es kozben mi van a SS jellel, ugye? Mindenre nem lehet felkeszulni, viszont egy-egy ilyen modulnak van 6-8 regisztere, beallitod a biteket, es menni fog, pont ugy, ahogy te akarod.
Na, pont errol beszelek. Te csak azt hiszed, hogy a program kesz fel ora alatt. Te fel orat foglalkoztal vele, de fogalmad sincs, hogy mit adsz ki a kezedbol. Keszen akkor van, ha atment a teszteken. Egyebkent, meg ez sem igaz, mert a legregebbi sw-es szolas az, hogy egy software soha nincs kesz, legfeljebb mar nem fejlesztik tovabb.

Ebben igazad van, de az esetek 90%-ában az UART-ot úgy használod, hogy pufferbe fogadsz és puffert küldesz. Ezen nincs értelme sokat filozofálni. Átadod a puffert, a rendszer meg IRQ-val, vagy DMA-val, vagy ahogy optimális átnyomja.

Ráadásul mi van, ha lecseréled a mikrovezérlőt? Újraírsz mindent? A regiszterek mindenhol mások.

Az Arduino nem optimális kód, oké, elfogadom. De: szükséged van optimális kódra ahhoz, hogy beolvasd a digitális hőmérő értékét másodpercenként és kiírd LCD-re?

Semmi szükséged rá. Az Arduino pont ezért jó, mert vannak kész megoldások, ahol csak programot írsz. Amikor ez nem megy, na akkor kell gondolkozni és elkezdeni dolgozni. Amit mások megírtak, te ne írd újra. Amit a kínaiak 1000 Ft-ért legyártanak, azt te ne találd ki újra. Vedd meg tőlük.

Nem lehet az egész világot előre libekkel leprogramozni, de bőven elég csak azokat a dolgokat, amiket gyakran használsz és jellegzetesen ismétlődnek.

Nekem még egy lib sem jött be. Se DS18b20-hoz, se LCD lib, se DHT-11, se UART. Vagy nem működtek, vagy mire megtaláltam, hol lehet a megfelelő lábakhoz illeszteni a libet, eltelt fél óra. Vagy nem lehettek külön porton az LCD lábai, plusz nem is volt jó a clock jel ( duplán adta ki), én meg néztem, hogy miért pont a g betű nem jelenik meg a kijelzőn. Aztán atmega328-on 1 usart van. De én atmega128-on akartam használni a lib-et, és pont nem az usart0-t, hanem az usart1-et. Akkor egészíthetem ki az egészet. Aztán DS18b20-nál nézem, hogy be van vonva az egész float lib is, mikor nekem nem is kell, plusz még a számolás is hibás volt. Hiba megkeres, fél óra, aztán javít... Egyedül eddig az SHT-11 lib-je ment rendesen, de ott is van egy 100mS-os késleltetés, amit én nem engedhetek meg. Azt ki kellene onnan vennem. Tehát én inkább megírom magamnak, ami kell, de minimum átnézem a lib-et, kiszedem a feleslegeset, kijavítom, és utána használom. Ami lib-et én találok, annak 75%-a nem megy pöccre... Lehet az én hibám, de érdekes, hogy miután kijavítom, megy. Plusz ezekről az önkényes interrupt tiltásokról meg ne is beszéljünk... Meg Arduino alatt a timer0-t nem is használhatod, ha beraksz egy lib-et pl. szervó-hoz, buktál még egy timert, és a gond ott kezdődik, amikor a 3. lib újrakonfigurálja a szervó által használt timert. Kész a teljes katasztrófa. Ezt kijavítani már nem fél óra...

Ami mindig ugyanaz, azt egyszer megirod magadnak, es legkozelebb csak masolod. Ha kicsit modositani kell, akkor kicsit modositod. En sem irok minden projekthez uj UART ISR-t.
Te azt mondod, hogy legyen keszen, ne kelljen megirni mindig ujra. En azt mondom, ird meg egyszer es hasznald ugyanugy, mintha mas irta volna. Uj mikrovezerlohoz igen, ujrairom, ha mas a UART. De eppen ezert nem cserelgetem a uC-ket. Par eve raalltam az NXP LPC sorozatra, azokat hasznalom. Persze haladok a korral, ha uj tag jon es megeri valtani, akkor valtok. De ez nem olyan nagy problema. Z80, HC11, AVR, ARM. 30 ev alatt azert nem olyan sok. Amit masok megirnak, az vagy jo, vagy nem. C forditot nem irok tobbet, mert irtozatos munka, de azert alapveto dolgokat szivesen csinalok magamnak, ahelyett, hogy masok kodjaban keressem a hibat. A batyam az egyetlen, akiben megbizom, de persze o is hibazik, ahogy mindenki, csak az o munkaiban hamarabb megtalalom a bug-ot, mert ismerem az eszjarasat, hiszen tole tanultam az egeszet. De amikor a mikrocsip tcp/ip stack-ben vagy USB storage class driver-ben kellett hibat javitanom, az igen faraszto volt. Hosszutavon nekem jobban megeri megirni az egeszet nullarol, mint hasznalni a mikrocsip takolmanyat. Meg oszinten. Egy 2x16 karakteres LCD-hez tenyleg keresni kell a neten lib-et? Ha valaki komolyan foglalkozik ezzel a szakmaval, akkor fel ora alatt megirja maganak.

Minel nagyobb darabokban van az "eloregyartott" elem, annal jobban meg van fogva a kezed. Latszolag annal gyorsabban lehet belole epitkezni, de valojaban minel nagyobbak, annal kevesbe tudod testreszabni a vegeredmenyt. Ezt a hatart mindenki maganak huzza meg es donti el, hogy mit "vesz meg" keszen es mit ir meg maganak. En elhiszem, hogy a mai vilag nem igy mukodik, mert latom a fiatal mernokok viselkedesebol, de nem vagyok benne biztos, hogy ez igy jo.

Konkretizálom a dilemmámat. Az AVR kevés, egyre kevesebb lesz, váltani kell.

- vagy ESP
- vagy STM32
- vagy más

A nagy helyzet, hogy fogalmam sincs, hogy a régi AVR-es libjeim melyik platformra nyomjam át.
Mindkét IC családnak vannak vonzó és visszataszító részei. Értelemszerűen a már meglévő kész lib-ek sokat nyomnak a latban.

Különbséget kell tenni a hobbicélú alkalmazások és a "professzionális" - vagy legalábbis iparszerűen űzött programfejlesztés között. Ha csak az a cél, hogy egy új eszközt (hőmérő, fénymérő, nyomásmérő, hobbirobot) kipróbáljon az ember, vagy hogy egy egyszerű IOT eszközt összekalapáljon, akkor ostobaság volna nekiállni saját USB vagy TCP-IP kommunikációt fejleszteni, saját RTOS-t írni.

Aki viszont a fejlesztésből él, és jól kézbentartható programkönyvtárakra van szüksége, amelynek minden csínját-bínját ismeri, az bizonyára megfontolja és nekivág. Ez persze több szakértelmet és nagyságrendekkel több időt igényel (amit egy hobbista nem feltétlenül engedhet meg magának).

Ha a könnyű kipróbálhatóság/megírhatóság a cél, akkor az Arduino is egy lehetőség. Hasonló céllal készült az mbed környezet is, mely újabban nyíltforrású és egyre több mikrovezérlőt támogat. Természetesen az egyszerűség ára a sok kötöttség és "eleve elrendelés". Amikor az ember úgy érzi, hogy ez a fejlődés akadálya, akkor vagy saját könyvtárat ír, vagy átlép a másik (a bitfaragó) kategóriába.

Akár hobbi, akár "profi" kategória, a nem nyíltforrású könyvtáraktól óvakodnék!

Ez egy nagyon érdekes kérdés ám! Én jelenleg nem ebből élek, de nagyon izgat a téma, szeretek vele foglalkozni. És talán pont ezért érzek késztetést arra, hogy az eszközt, amit használok, megismerjem lehetőleg bit szinten. Hatékony, tömör és gyors szoftvert szerintem csak úgy lehet írni, ha ismered a "vasat", amire készül.

Persze a dilemma nagyon sokszor előjön, hogy mi lenne az üdvözítő megoldás az előre valakik által elkészített megoldások illetve a saját alacsonszintű kódok terén. Én most nem egy konkrét terméket tartok szem előtt valamilyen konkrét probléma megoldására, hanem azt, hogy - jelen esetben - az ARM alapú mikrovezérlők használatába rázódjak kicsit bele. Ennek leglényegesebb része az ARM mag valamilyen szintű megismerése, emiatt az ARM-es doksikat (utasításkészlet, Cortex-M működési leírások) elég sokat bújtam. Amikkel kezdtem, azok a TI Stellaris Launchpad és STM32 C-M3 MCU-k, lesz még Atmel SAM3 is a közeljövőben. A Stellaris és az STM32 perifériái is teljesen eltérőek, és mivel én szerettem volna megismerni a hardvert, azokat a minimális rutinokat (pl. precíz időzítés timer-rel, GPIO lábak konfigurálása, billegtetése, HD44780 megszólítása) meg kellett írnom mindkettőre, amikre a minimális tanulmányprogijaimhoz szükség van.

Ezeket a kódokat persze érdemes úgy írni, hogy majd adott esetben könnyen áthurcolhassa az ember egy másik projektbe, sőt, ha nagyon komfortossá akarja tenni a munkát, akkor akár MCU típusonként vagy családonként más implementációt lehet megvalósítani bennük. Sajnos minél inkább elmegy az ember az általánosítás felé, annál inkább elveszíti a mikrovezérlőkbe épített konkrét hardveres apróságokat, amik miatt esetleg az egyik típuson frappánsabban lehetne megoldani egy problémát, mint a másikon, mert csak azzal építkezhet, amit "mindenki tud". Emiatt az embernek magának kell meghúzni azt a határvonalat, ameddig elmegy a hardver absztrahálásában.

Visszatérve a másik kérdésre: én jelenleg GCC-t használok, és más MCU-k esetén (pl. PIC) is próbáltam a szabadon használható megoldások felé tolódni. Mint a témában abszolút hobbista azt gondolom, ezekkel az eszközökkel is fantasztikus dolgokat lehet megvalósítani, az önképzésre tökéletesek, nem mellesleg hatalmas a felhasználói közösség a neten, ahol lehet keresgélni megoldásokat problémákra, ha elakad az ember. A C preprocesszor és a GNU linker lehetőségeit is érdemes tanulmányozni, mert nagy varázslatok rejlenek bennük. Ezekről is rengeteg doksit olvastam el az elmúlt hetekben.

Most éppen azzal kínzom magam, hogy az STM32 USB device interface-ét külső lib-ek nélkül munkára tudjam fogni. Sajnos most is igaz az, hogy a doksikban nincs minden teljes részletességgel leírva, így a gyári példák forrásait bújva kell apróságokra rájönni. Viszont tapasztalatom szerint az így megszerzett ismeretek maradnak meg legjobban az emberben, és ezek által kap egy átfogó, részletes tudást az adott technikáról. Így kénytelen lesz megismerni azt is, hogy mi történik a háttérben, emiatt egy csomó kapcsolódó dologról is kell olvasni közben, esetemben pl. az USB kommunikáció alsóbb rétegeiről, egészen az elektromos paraméterektől elkezdve.

A program kész fél óra alatt. Hát az a program olyan is.
Aki mikrokontrollerekkel foglalkozik annak regiszterekkel kell bajlódnia. Ilyen ennek a természete.
Természetesen meg lehet úszni. De akkor gőzöd sem lesz mi folyik. Na ezért olyanok ma a "nagy" programok amilyenek.

Véleményed köszönöm, nem megyek a munkaügyi központba. De egy kis segítség:

CAN1BTR regiszter 21. bitjén 3 biten tudod változtatni mondjuk a BaudRate Prescalert. 24. biten meg monjuk a SWJ nevű paramétert.
Az elején a .h file-ba beírod.



majd a kód:



Szerintem egész olvasmányos.
A tudás hiányát kár arroganciával pótolni...

Csak a pontossag kedveert:
A makro vegen megszokasbol van egy pontosvesszo, nyilvan elgepelted. Viszont a makroknak atadott parametert reflexesen illik zarojelezni, hogy ne erjek meglepetesek az embert. Ne felejtsuk el, hogy a makro kifejtes egyszeru karakterbehelyettesitessel tortenik, meg a C forditas elott. A bitenkenti or vagy and precedenciaja alacsonyabb, mint a shift-e, ezert ha azt adod at a makrodnak, hogy BTR(BIT_EGYIK | BIT_MASIK); akkor abbol az keletkezne, hogy:
BIT_EGYIK | BIT_MASIK << 21, marpedig te nem csak a BIT_MASIKAT akarod feltolni a 21. bitre, hanem mind a kettot.

Teljesen igazad van.
Csupán egyszerű(bb)en akartam szemléltetni.

Ez teljesen feladat fuggo. En ugy irtam SMT32F4-re SSB radio kodot hogy szinte alig lattam regisztert. Nem is az volt a lenyeg benne, hogy kihagyjam a CMSIS-t es 0-rol megirjam a periferiak kezeleset stb, majd dicsekedjek hogy sikerult megirnom.Teljesen esszerutlen lett volna.
Viszont volt nehany dolog (pl. DMA ad/da adatmozgatas) ami miatt jobban bele kellett asnom magam az adatlapba.

Sziasztok!
Egy STM32F103-ason nem tudom GPIO módba használni PB3-at és PB4-et. Ezek alapból ha jól tudom JTAG lábak. A JTAG-et ki lehet úgy kapcsolni, vagy remappolni a kivezetéseket, hogy az SWD megmaradjon?
Üdv: Suncorgo

Vagy ha nem lehet megoldani a JTAG kikapcsolását úgy hogy az SWD maradjon a helyén és működjön is, akkor az egy járható út lenne-e hogy mielőtt a programkódomban végrehajtódna a remap függvény, elé tenni egy kis késleltető ciklust amíg van időm átprogramozni?

Hello,
nem tudom használsz-e CMSIS-t ha igen akkor:



Így mennie kell, én csak PB4-et használtam, de elvileg így a JTAG lábak felszabadulnak és SWD-n tudod programozni.
szerk: Persze először engedélyezni kell a PortB órajelét is.

link neve
Ennek a doksinak a 176. oldalán van egy táblázat, amiben ezeknek a speciális lábaknak a mapelését taglalja az AFIO regisztereknél. Szerintem neked a táblázatban szereplő SWJ _CFG [2:0] = 010 beállítás kell, itt a serial wire debug engedélyezett, bár az az 1-es megjegyzés nekem nem teljesen világos, hogy mit takar, mikor használunk "aszinkron trace"-t. Az AFIO_MAPR regiszter a 183. oldalon látható, ebben vannak a táblázatban tárgyalt bitek.

A PB4-et egyébként én is használom kimenetként, én az alábbi kódrészlettel vettem használatba:

Ezután már a GPIOB->CRL regiszterben a portláb módját a szokásos módon lehetett állítgatni:

Üdv.

Olyan kérdésem lenne, STM43F030-al kapcsolatban, hogy referencia feszültséget miként lehet variálni. Előállítok +2,5V referenciafeszültséget de nem vagyok biztos hogy melyik lábra is kellene kössem. 64 lábú procinak van külön lába VREF bemenettel én viszont a TQFP32 -es STM32F030K6T-t választottam amiben van egy VDDA de VREF nek nem látok semmi mást.
VDDA itt most a ADC referenciája is egyben? Ha megtáplálom 2,5V referenciával akkor ahhoz mérten végzi az átalakítást?

Van egy ilyen hogy vrefint channel. Az micsoda?

köszi

Én nem látom, hogy a 64 lábasnak lenne külön VREF bemenete.
Ahogy az ábra mutatja a referencia a VDDA lábra csatlakozik.

A VREFINT egy belső feszültségforrás, amin referencia mérést tudsz végezni.

The internal voltage reference (VREFINT) provides a stable (bandgap) voltage output for the
ADC. VREFINT is internally connected to the ADC_IN17 input channel. The precise voltage
of VREFINT is individually measured for each part by ST during production test and stored in
the system memory area. It is accessible in read-only mode.

Keil uVision 5.18 simulátor problémám van. Esetleg tudna valaki segíteni?
StmCube szépen legenerálja a HAL project-et.
Beállítja a proci órajelet Target Xtal-t 160 Mhz-re a HCLK szerint.
A SystemCoreClock viszont mindig csak 16 MHz-et mutat.
A simulátor idő szerint a SysTick 1 msec helyet 100 usec-el megy.
HSI_VALUE eredetileg 16 MHz próbáltam 160-ra tenni.
Meghívogattam azokat a HAL függvényeket amiket gondoltam de egyenlőre nem tudom beállítani.
A szimulátor egyáltalán tudja követni a valós hardver beállításokat ?