Fórum témák
» Több friss téma |
Rakosgatom a verziókat 2.3-at letöröltem felraktam a 3.3-at ezzel gem F031-es lát. Ha simán program& verify nyomok akkor megy feltéve ha az options WDG_SW be lett állítva.
Ha bemegyek automatic mode ba (ez lenne a cél hogy egymás után levédve tudjam programozgatni) akkor valamit ráprogramoz de vagy nem idnul a proci vay csak újraindulgat. Most éppen egyáltalán nem indul el automatic mode-ban a felprogramozás csak vár az eszközre, pedig rajta van. Totál beteges a szoftver. 3.8 jó volt de gondolván frissebb verzió jobb frissítettem a 4.1-re de az is egy kalap szar a 3.8 bezzeg nincs fent a neten sehol . ST-nek üzenetet írni???.... hagyjuk.... nulla a weboldaluk nem várok tőlük segítséget. Mondjuk az ST szoftvereitől már megszokhattam a CUBE is olyan kódokat generál hogy tele van hibával. Felrakom a 4.1-et azzal még egy kicsit még ba...tom de már itt van mellettem a fejsze készenlétben...
Magát a programozót nem lehet vagy érdemes frissíteni?
Én megvettem 2 hete, egyből toltam rá a gyárira meg a klónra is az utolsót ami fent van.
Sziasztok!
Egy egyszerű kérdésem lenne, még nem vagyok járatos az ARM assemblerben. Ha egy while ciklusban ránézek egy flag-re egy status regiszterben és a reserved bitek az ábra szerint vannak meghatározva, akkor 0-ra kell maszkolni ezeket a biteket? Vagy úgy is kérdezhetném, hogy ez read-modify-write művelet? Két könyvtáram is van adott chip-hez, az egyikben így van, a másik Codebundle-ben pedig nem.
Sziasztok!
Ha van egy Arduino bootloader egy BluePill-en, akkor ha egy IDE-ből(EmBitz) letöltök STLink V2-n keresztül egy C programot, akkor a bootloader felül fog íródni? Ha nem, akkor van arra mód, hogy kérdés és boot nélkül az én programom induljon el? (nem akarok bootloadert írni,ahhoz még messze vagyok) vagy van valami gyári,amit fel kell/lehet rakni? Kiborg A hozzászólás módosítva: Okt 2, 2017
Az STM kontrollerekbe gyárilag van (ebben pl. soros porti ) bootloader, azt kitörölni nem lehet. Ez a BOOT0 '0' szintjével aktiválható. A BluePill is alapban ezt tartalmazza. Persze rengeteg más bootloader létezik, itt már más a helyzet.
SZia!
Az ebben a hozzászólában linkelt bootloader van rajta,amit a soros porton keresztül töltöttem fel rá. Ez úgy kezdett, hogy gyorsan villantott párat, majd futott az én programom. Letöltöttem rá most az EmBitzen keresztül a saját programomat és megszünt a pár gyors villogás. Akkor felülírta a bootloadert vagy mi történt?
Igen, az általad rátöltött bootloadert felülírta.
Ha újra Arduino IDE-vel akarod használni és USB bootloaderrel (elvégre az a legkényelmesebb), akkor előtte újra töltsd rá a generic_boot20_pc13.bin bootloadert, pl. a soros porton, a beépített bootloader segítségével. Ahogy ha1drp kolléga írta, a soros porti gyári bootloader viszont mindig rendelkezésre áll. Csak a BOOT0 jumpert kell állítgatni...
SZia!
Köszi az infót. Úgy néz ki, hogy nem lesz Arduinos kitérőm. Pár próbálkozás után rájöttem, hogy nagyon elrejti a hardvert, nem szimpatikus. Még mindig a megfelelő IDE kiválasztásán gondolkozom. EmBitz tetszik, de nem nagyon találok mintakódokat,pedig SPI-t jó lenne használni. Van esetleg valami mintád STM32F103C8 vagy valami hasonlóra?
EmBitz szerintem jó választás, én is azt használom.
A bootloader szintén nem olyan bonyolult. Ha nem akarod, hogy a főprogramod felülírja akkor meg kell változtatnod pár dolgot, hogy ne az alapértelmezett pontról induljon a progid (és ne oda tegye a programozó se). Első lépésként meg kell változtanod a linker scriptet (ld fájl): A példában láthatod, hogy eltoltam a kezdőcímet 64K-val és lecsökkentettem az elérhető flash-t is ugyanennyivel.
Ha az új low layer HAL-t használod, akkor a system_stm32f1xx.c-ben módosítanod kell a vektor tábla (megszakítások) ofszetet az alábbi módon:
Ugyanez a régi SPL HAL-nál a system_stm32f10x.c-ben található. Az ofszetet értelemszerűen annyival kell eltolni, mint amennyivel eltoltad a programot a flash-ban a linker script-el. Ahhoz, hogy a bootloader miután végzett elinduljon a főprogram, módosítanod kell a program kezdőcímét a bootloaderben az ORIGIN-nél megadott értékre.
Létezik gyári mintaprogram mind SPL, LL, illetve Cube HAL-hoz. Csak regisztrálni kell az ST oldalán és letölthetőek.
Ha megmondod mit használsz a fentiek közül, akkor lehet tudunk adni saját implementációnkra is példát. Van itt köztünk olyan is, aki regiszter szinten piszkálja a saját mikrokontrollereit (a low layer is ugyanezt csinálja, csak olvashatóbb marad a kód). A hozzászólás módosítva: Okt 3, 2017
Blue Pill-t használok most én is, előbb utóbb szeretnék leszokni a HAL használatától, igaz még csak most kezdtem de már nem szimpatikus. Ráadásul többen ajánlották itt hogy inkább alacsonyabb szinten kéne programozni.
Alap dolgokat ADC DMA-val és Timer megszakítással már elég jól sikerül kezelni, plusz soros porton küldi ki szépen az adatokat. Most egy olyat szeretnék hogy ADC watchdoggal figyeltetni a jelet és a jel hosszát mérni. Az én elgondolásom az hogy mikor küszöbszintet átlépi, megszakítást generál de ezt minden AD átalakításnál meg fogja tenni, megszakítási rutinban indítom a számlálót. Majd ha nincs megszakítás megállítom a főprogramban? Vagy az alsó hátárérték küszöböt viszem a felső határ alá pár tizeddel, és megszakításban eldöntöm hogy kisebb e vagy nagyobb a felső határértéknél , és indítom vagy megállítom a számlálót. Watchdog szépen működik, menet közben gombbal állítom be a felső értéket, az AD átalakítóra meg egy poti van kötve, LED jelzi ha felette van.Gombnyomás után persze össze vissza villog egyrészt nyers jelet dolgoz fel,másrészt elég kicsi a lépték(3,3V/4095). Megszakításon belül nem szerencsés nagyon számolgatásokat végezni gondolom, csak mondjuk változót beállítani, aztán főprogramban ettől függően számolgatni? Nem vagyok programozó, csak egy amatőr. Nagyon ritkán kérdezek, próbálok csak olvasás módban maradni, de néha nem találom meg amit keresek vagy nem tudom hogyan keressek. A hozzászólás módosítva: Okt 3, 2017
> előbb utóbb szeretnék leszokni a HAL használatától, igaz még csak most kezdtem de már nem szimpatikus
Konkrétabban? Mi nem tetszik benne?
Szia!
A bootloader nem izgat, jobb is, hogy eltűnt Igazából nem a HAL-t használom, hanem szeretném megérteni a működést,ezért regiszter szinten piszkálom a vezérlőt,mint a 8-bites AVR-es időkben. Egy SPI-s VFD-t kötnék rá (Samsung 16L102DA4S),tehát vissza nem olvasnék semmit, de ez a beállítást nem befolyásolja. SPL az minek a rövidítése? HAL-t már halottam, de pontosan ezt sem tudom. LL - Low Layer, gondolom valami assemler szintű programozás. Én C-ben tolom,de ott is frankón hozzáférhetőek a regiszter bitek és tényleg olvasható marad a kód.
Ezeket most úgy írom hogy nagyon keveset foglalkoztam vele , és nem vagyok szakértő.
Egyrészt az olvasottak alapján se szimpatikus, több helyen írták hogy bugos, és tanácsok alapján is jobb nem használni. Valószínűleg az én szintemen jó ez is. Az se tette szimpatikussá az információk után, mikor elkezdtem használni és belefutottam a CubeMx által generált hibába, ekkora cég és ilyen hiba... Valamit sokkal egyszerűbb beállítani, mint HAL-nak átadni és majd ő megcsinálja. Gondolom akkor van értelme HAL-nak ha hasonló eszközökre kell ugyan azt lefejleszteni. Aztán dupla meló megtanulni a HAL-t , és a regisztereket is. Oké hogy ez csinál egy ellenőrzést is.
De nem könnyebb ha tudom a regiszter és betöltöm az értéket pl: ADC_HTR A hozzászólás módosítva: Okt 3, 2017
Nem volt még időm komolyabban foglalkozni vele. Elvileg az mbed környezetben is programozható. Bővebben: Link
SPL - Standard Peripheral Libraries, ezt tartalmazza alapból az EmBitz STM32-höz. Már nem támogatják, ehelyett hozták be a low layer-t. Valamelyest absztraktabb, mint a low layer.
HAL - Hardware Abstracture Layer, azokat a könyvtárakat szokták így hívni, amelyek egy plusz réteget képeznek a programod és a vas között. HAL tehát a low layer is, az SPL is, illetve a CubeMX magasabb szintű HAL-ja is. LL - Low Layer, nem assembler hanem C könyvtárak. Gyakorlatilag a regisztereket hívja direktben a legtöbb utasítása, megkönnyíti valamelyest a hordozhatóságot a különböző ST mikrokontrollerek között (persze komoly korlátokkal) és olvashatóbb marad a kód, mintha te magad írogatnád közvetlenül a regisztereket. Én személy szerint most már ezt használom. Viszonylag új dolog és még vannak benne bug-ok. Ami a dupla melót illeti, HAL és HAL között is óriási a különbség. A legmagasabb szintűt, amit a CubeMX generál én sem szeretem, mert túl absztrakt és nem elég hatékony. A low layer viszont jelentősen megkönnyíti a munkát. Itt némileg több regisztered van mint a 8bites AVR-nél. Kezdőként iszonyat megnehezíted a dolgod, ha egyből regiszterekkel kezdesz. Direkt regiszterkezelés a low layer-hez viszonyítva pedig nem igazán hoz teljesítmény többletet. Ettől még természetesen tudnod kell majd a dokumentáció alapján ellenőrizni, hogy mégis minden jól lett beállítva debugoláskor az élő regisztereknél.
Próbálj majd egyszer egy FSMC buszt felkonfigurálni regiszterekkel, majd rájössz miért is jó egy kis absztrakció.
Akkor SPL-ben dolgozom. Most már legalább ezt is tudom.Nincs semmi extra fenn, csak amit az EmBitz felrakott alapból.
Így szeretném az SPI-t munkára fogni. Köszi az okosítást. Délután rakok fel egy kódrészletet majd,ahogy inicializálom az SPI-t.Majd ha ránéznétek,azt megköszönném.
Na igen.
Köszi az információkat, akkor kicsit utánaolvasgatok az LL-nek.
Azért nem kell leírni a HAL-t elég jó ütemben dolgoznak rajta. Fejlesztőként pedig nem mindegy, hogy napokig, hetekig regisztereket piszkálok, vagy tervezés után azonnal írhatom az alkalmazást, amiért a piac, vagy a megbízó fizet.
Dolgozom egy projektben, ahol az applikációt STM32 HAL és RTOS fölé fejlesztjük. Szuperül hordozható az applikáció a különféle mikrokontrollerek között. Kell is, mert nem szeretnénk minden komponensre újra megírni. A projekt alapvetően Makefile alapú. A fejlesztéshez és hibakereséshez a legtöbben EmBitz-et használunk. Az applikáció fejlesztési nyelve a C++, 2014-es szabvány. Kidolgoztuk a mikéntjét, hogy a CubeMX által összerakott kódhoz egy sort sem kell hozzáírni. Az applikáció is egy osztály, és minden szükséges objektumnak tulajdonosa, nincsenek globális változók sem. A megfelelő osztályok konstruktor paramáterben kapják a CubeMX által inicalizált eszköz handlerjét, így az applikció fejlesztője nem találkozik HAL hívásokkal, csak a saját, C++ API-val. A sok HAL-t lehúzó fórum hozzászólás főleg 2015-ös. Azóta sokat javult a HAL minősége. Kár szidni az STM-et, semelyik cég kódja nem tökéletes. És nem csak a kódja. A hardverben is előfordulnak bugok. Fejlesztés közben folyamatosan figyelni kell az errata dokumentumokat, és számon tartani, hogy melyik gyártási időpontú MCU-n mi nem működik... Ez egy ilyen szakma. Az SPL-t dobta az STM, nem érdemes alapozni rá. Az LL is C, és főleg a felfelé adott interfészben klönbözik a HAL-tól. Például LL-ben I2C olvasás: Generate start condition, write I2C address, read bytes, generate stop condition. Ez 4 hívás. HAL-ban van egy darab olvasás függvény, ami paraméterben kapja a címet, és az olvasandó bájtok számát, a többit intézi maga. Mindenki döntse el, hogy neki melyik kényelmesebb.
Azt nem tudom, hogy a forrás amit felhasználtam, az a // connect SPI1 pins to SPI alternate function részt másképp oldotta meg, három utasítással,külön PIN-enként. Jó-e ez így ahogy van? EmBizt 1.11 SPL Ez meg az adatküldő modul:
Szerintem nem jó.
Az SCK-t és a MOSI-t GPIO_Mode_AF_PP-nek szoktam konfigurálni. A MISO-t pedig GPIO_Mode_IN_FLOATING-nak. Az adatküldőbe betennék vmilyen timeout mechanizmust, illetve a while-okat is átrendezném úgy, hogy először ellenőrzöd, hogy szabad-e küldeni (ez később lesz igazán hasznos, amikor kiegészíted DMA-val az SPI kezelést, mert csak úgy gyors igazán). Ezután küldesz, majd megvárod lehet-e vmit beolvasni. Beolvasod. A BSY flag-es várakozás felesleges.
Szia!
OK, kipróbálom. Viszont, hogy egy kijelző van csak rákötve az SPI-re, az nem küld vissza semmit,mert nincs is olyan PIN-je, amit a MISO-ra kellene kötni, azt így szabadon hagytam. DMA-t még hanyagolom,mert nem igazán hizsem, hogy szükségem lesz rá, hobbi szinten nyomom csak még. Akkor felmerült bennem a kérdés, hogy van-e értelme, a wait until receive complete while-jának vagy azt is törölhetem jelen esetben? A BSY-s sort meg töröltem. Így néz ki a móka:
A remap-os részt jónak véled ? A mintát pedig innen vettem, bár ez nem STM32F103, de nagyjából hasonló.
Szerintem neked nincs szükséged remap-re.
A "while( !(SPI1->SR & SPI_I2S_FLAG_TXE) );"-t tedd az "SPI1->DR = data;" elé. A DMA nem csak a profik játékszere. Nem olyan bonyolult a használata és cserébe sokkal gyorsabb képernyőkezelést lehet megvalósítani a CPU felesleges blokkolása nélkül, arról nem is beszélve, hogy a fent vázolt regisztereken keresztül írás/olvasás, majd flag-ekre várással kb. 5-öd olyan lassú a kommunikáció, mint DMA-val. Az egyik projektemben például direktben olvasok ikonokat és képeket egy külső SPI-os flash memóriáról az FSMC buszon keresztül meghajtott LCD-re DMA-val, eközben pedig a CPU teljesen mással foglalkozhat. Ez látszólag periféria-periféria kommunikáció (valójában az is ), amit a DMA alapból nem tudna, de szerencsére az FSMC automatikusan működik, ha a megfelelő memóriacímre tolom az adatokat (ez a cím a hardveres bekötéstől függ). A hozzászólás módosítva: Okt 3, 2017
Akkor ahonnan vettem, mi célt szolgál ez a rész:
Remapot kiveszem és próba.
Az az F4-es sorozatra vonatkozik, semmi köze az F1-es remapunkhoz.
OK, akkor köszi és próbálkozok.
Egyelőre semmi, de nem tudom, hogy miért. Az SPI_CPOL és SPI_CPHA állítgatásával próbálkoztam, de nincs eredmény egyelőre. Ránézek majd szkóppal is. Viszont ami kérdéses még, hogy elvileg a kijelző 5V-os szintekkel megy. Kipróbáltam egy 3,3V és 5V-ról is működő uC-vel, hogy ha 3,3V tápot kap a uC,akkor is vezérelte a kijelzőt, tehát elvileg nem szabadna, hogy problémát okozzon a 3,3Vos jelszint.
AZ SCk és MOSI vonalakon van jel, bár nem igazán felismerhető, hogy mi, mert csak egy DSO138-al tudtam ránézni hirtelen, de a kijelző egyelőre meg sem mukkan
Hát ez már a te harcod. Én inkább logikai analizátort szoktam ilyesmihez használni, de a szkóp is jó ha más nem akad.
Sajnos logikai analizátorom nincs
Viszont van egy működő programom AVR-re, abban megnztem, hogy pontosan hogyan is inicializáltam a kijelzőt és láss csodát úgy néz ki, hogy működik Nagyon örülök és köszönöm a segítséget. Legközelebbi nagy falat majd az I2C lesz. Ha nem boldogulok, remélem abban is kapok majd némi segítséget. Köszönöm mindenkinek! |
Bejelentkezés
Hirdetés |