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   160 / 177
(#) vorosj válasza vargham hozzászólására (») Nov 10, 2021 / 1
 
Idézet:
„Van 8 lábú ARM is...”

Előszeretettel használom az STM32G031-et. Még a chip hiány előtt vettem néhányat 0.8 usd/db áron. Most persze drágább, de így se vészes.
(#) vorosj válasza cross51 hozzászólására (») Nov 10, 2021 /
 
Idézet:
„szerintem az uVision használhatatlan”


Meglep hogy ennyire nem tetszik neked, mert én az évek során sok mindent kipróbáltam és valahogy mindig visszatértem a Keil-hez. Elsősorban SMT32-t programozok, kényelmes, hogy az STM32CubeMX közvetlenül együttműködik vele. A debuggere mindent tud ami kell, különösen Jlinkkel.

Az Eclipse alapú IDE-k nekem nem tetszettek, bár tulajdonképpen nincs velük különösebb baj. Próbáltam az Atollic-ot, meg az ST ezen alapuló CubeIDE-t.
Ami bejött:
Segger Embedded Studio, jó a debuggere, és az RTT tetszett. De visszatértem a Keil-hez, beteszem az RTT-t a projectbe ha kell.

VSCode&PlatformiIO párost is használok olyan uC fejlesztéshez, aminek nem akarom komolyan megtanulni a tulajdonságait, csak Arduinóval próbálok összehozni vele valami egyszerűt. Pl. ESP8266 és ESP32, Pi Pico. A VSCode tetszik mint IDE, sajnos a debuggolási lehetőségei a PIO pluginnel nagyon korlátozottak. Ha ravaszabb probléma adódott, Segger Ozone-nal debuggoltam a PIO-val létrehozott .elf-et.
Mivel a VSCode tetszett, próbaképpen STM32-es fejlesztést (CubeMX HAL alapon) is próbáltam vele. Nem volt semmi gond, jól ment, de valahogy mégis visszatértem a Keil-hez.
(#) vorosj válasza kiborg hozzászólására (») Nov 10, 2021 /
 
Idézet:
„Egy 640x240 LCD vezérlése lenne a feladat. 8 bit és vezérlő jelek.”


Úgy célszerű bekötni, hogy a 8 bit egy port 8 bitje legyen, és a többi bitje ne legyen bekötve, akkor egy utasítással ki tudod vinni a 8 bitet. GPIOx->ODR = 0xakármi
Ha szükség van a többi port bitre és békén kell hagyni, akkor több lépés, beolvas, kinulláz, hozzávagyol.

A vezérlő jeleket meg bitbang-elni a
GPIOx->BRR = GPIO_PIN_yz
GPIOx->BSRR = GPIO_PIN_yz
utasításokkal. Ez nagyon gyors tud lenni.
(#) vorosj válasza vorosj hozzászólására (») Nov 10, 2021 /
 
Az LCD-k meghajtóinak általában van 16 bites módja is. Ha a uC elég sok kivezetéses, akkor a 16 bitet egyetlen portra kötve többszörösére gyorsul a dolog. Simán el lehet érni 20msec-es frame sebességet.
(#) toto válasza vorosj hozzászólására (») Nov 10, 2021 /
 
Az Eclipse-szel (CubeIDE, Atollic True Studio, stb.)én is hasonlóan vagyok. Nem rossz, de kösz nem kell.
A Keil nekem is tetszett anno, de a 32kB korlátot túlléptem. A VSCode bejövős, de a PlatformIO helyett Cortex Builder + Cortex debug plugineket használom, bár én csak STM32-t programozok vele. Ami hiányzik, hogy a debugban nincs live variables.
Most a VisualGDB-t nézegetem, de eddig nem jött át az a WOW érzés. A Visual Studio irdatlan beállítási lehetősége a sírba visz. A debug esetén a live variables megvan, de ez máshol is megtalálható. A változók grafikus megjelenítési lehetősége nem lehet rossz, de még nem sikerült előcsalnom. Az STMStudio is tudja ezt, igaz debug nélkül.
Ezen kívül mi az, ami olyan nagy előnyt jelent a VisualGDB-ben, hogy érdemes lenne pénzt adni érte?
lehet, hogy inkább cross51-nek kellett volna feltennem a kérdést, mert ő írta, hogy VisualGDB-t használ.
A hozzászólás módosítva: Nov 10, 2021
(#) vargham válasza toto hozzászólására (») Nov 10, 2021 /
 
Seggert használok Nordic ARM-hoz, Atmel Studiot AVR-hez és nagyritkán SAM-hez.
STM32-höz sokáig VisualGDB-t használtam, szerintem annak a legjobbak a debug képességei, mint élő változók, RTOS taskok, memória használat, stb. A munkahelyemen átálltunk a CLionra, mert az multiplatform. Nekem nem jön be, még nem tud túl sokat a beágyazott debug módja, de folyamatosan fejlesztik. Az utóbbi időben viszont átszoktam a CubeIDE-re, az Azure RTOS támogatás miatt.
(#) kiborg válasza vorosj hozzászólására (») Nov 10, 2021 /
 
Köszi. A bekötés természetesen így van. Egy porton az az adat és másik port a vezérlő bitek.
Ez csakis 8 bites vezérlést tud. Less át az LCD élesztése topicba, ott van lábkiosztás és össz népi tanácstalanság.
Annyival vagyok már előrébb az ott tárgyaltaktól, hogy a lábkiosztás tutibiztos és van egy analizátorral lelopott vezérlési metódusom a gyári meghajtóval.
(#) benjami válasza kiborg hozzászólására (») Nov 10, 2021 / 1
 
Ha FMC/FSMC képes kontrollert használsz, akkor az hardverből le tudja kezelni a vezérlővonalakat, így az írási művelet mindössze memóriaírási műveletnek számítana, amit lehetne akár DMA-val is működtetni.
(#) vorosj válasza kiborg hozzászólására (») Nov 10, 2021 /
 
Idézet:
„Less át az LCD élesztése topicba”


Ez hol van? Nem találom.
(#) kiborg válasza vorosj hozzászólására (») Nov 11, 2021 /
 
(#) vorosj hozzászólása Nov 11, 2021 /
 
Próbáltam STM32CubeMX alapon egy USB audio kapcsolatot létrehozni, a PC felől hang streamet átvinni egy STM32F103C8-ba. Egy sor programot se írtam le, mégis hibás. (úton vagyok a program nélküli hiba felé) Rádióamatőr cucchoz kellene.

Csak az abszolút minimumot csináltam: CubeMX (latest greatest), beállítom az órajeleket, hs oscillatort, system-ben a debuggert, engedélyezem az USB-t, middleware-ben az audio-t. Egyetlen paramétert állítok, 48KHz-es hang. Minden egyéb, VID, PID stb defaultban.
A managerben a heap-et felviszem 4k-ra (mert malloc-kal csinál majd egy nagy buffert), a stacket 1k-ra. Ennyi.

Ami történik:
- enumeration rendben lemegy, a PC audio eszköznek látja, ki tudom választani a PC-n mint hangszórót
- a debuggerben látom, hogy létrehozza a malloc a buffert a bejövő stream számára, mikor rádugom az usb-re
- viszont egy bit hang streamet se tesz a bufferbe, ha hangot küldök ki a PC-vel az audio eszközre

Kipróbáltam betűre ugyanezt másféle uC-kkel is:
STM32F407V: rendesen tölti a buffert, ha hangot küldök (csak ennyire teszteltem, a debuggerben látom ahogy frissül a buffer)
STM32F411C: rendesen működik, mint az F407
STM32F303C: nem működik, nem tölti buffert, ugyanolyan mint az F103-mmal

A PC felől is látszik a különbség a következő módon: Gépház, rendszer, hang, tulajdonságok, az eszköz további tulajdonságai. Enhancements fül, Disable all enhancements. Majd Speciális fül, itt mutatja szépen, hogy 16bit 48000Hz. Mellette Tesztelés gomb. Ha ezt megnyomom, máshogy viselkedik a működő és a nem működő:
F411, szerintem jó: kb 3 másodpercre feketére vált, majd visszajön a zöld, ennyi ideig nyomta ki a teszt hangot. Ha megint megnyomom, ugyanez történik.
F103, hibás: első megnyomásnál több mint 5 másodpercre feketére, vált, majd visszajön zöldre, és újabb megnyomásnál már nem vált feketére
(meg persze a debuggerben is látom, hogy az F411 tölti a buffert, az F103 meg nem)
De az F103-ban is látszólag fut a háttérben a program, nem fut hardfault-ra vagy ilyesmi.

Tanácstalan vagyok, hogy a CubeMX hibás, vagy én kattintgatok rosszul valamit.

Amit még próbáltam:
Google-lel kerestem, hátha valaki feltett valahová működő usb audio speaker programot F103-mmal, mivel a BluePill a legnépszerűbb STM. Nem találtam CubeMX HAL alapút.
Olyat találtam, ami SPL-lel van megírva, kipróbáltam, nekem is szépen működik.

Vagyis tulajdonképpen meg tudom oldani amit szeretnék, akár az F411 BlackPill-lel, akár a F103-mal a standard library-vel.
Viszont egy napot elszerencsétlenkedtem a CubeMX-szel, és nagyon szeretném tudni, miért nem sikerült.

Van esetleg ötletetek, mi ez, mit kellene kipróbálni?
(#) Lucifer válasza vorosj hozzászólására (») Nov 11, 2021 /
 
Én első körben tolnék egy lsusb -vvvv-t a mindkét MCU-n, hogy lássuk van-e valami eltérés az USB descriptorokban. A CubeMX, HAL meg kb. sosem szentírás csak elindulni jó
(#) vorosj válasza Lucifer hozzászólására (») Nov 12, 2021 /
 
usbtreeview-val megnéztem a jót is, rosszat is, nem látok gyanús különbséget.
Az USB minden rétege jó bonyolult, ha egy mód van rá, nem szeretném beleásni magam. Ha nincs megoldás, beletörődök, és valamelyik működő változattal folytatom.
(#) Lucifer válasza vorosj hozzászólására (») Nov 12, 2021 /
 
Idézet:
„valamelyik működő változattal folytatom.”

Hát ha nem termék lesz csak pár darab kellene belőle akkor ez a legjobb megoldás.
Bár ST fronton manapság az F103 azért jobb választás lehet, mert annak tuti vannak GigaDevices klónjai .
(#) vorosj válasza Lucifer hozzászólására (») Nov 13, 2021 /
 
Vagy 1db lesz belőle, vagy egy se - ha nem sikerül.

A CubeMX-es verziót feladtam, mert az usb audio részt sikerült olyan bonyolultra megírniuk, és olyan eszetlenül dokumentálni, hogy több óra tanulmányozás után se jöttem rá alapvető dolgokra.
Az SPL alapú példa meg egyszerű, mint a faék. Egyből látom, mi hol van, mit akartak, hogyan oldották meg.

Egy FT8 adót tervezgetek. Nem azért, mert kell - van kész gyári transceiverem. Hanem mert szeretek programozgatni.
A lényeg, hogy az FT8 üzemmód a szokásos módon úgy működik, hogy a PC-n futó WSJT-X program előállít egy hang jelet, amit a transceiver SSB üzemmódban felkever a sávba. Maga a jel egymáshoz közeli frekvenciák között váltogat.

Én ezt SSB nélkül próbálom megoldani. A uC USB-n megkapja a hang streamet, és folyamatosan méri a frekvenciát, és egy SI5351 szintézer csippel előállítja magát a kész jelet, amit már csak erősíteni kell és antennára küldeni. Van ilyen készülék, a qrplabs megoldotta, szóval lehetséges.

Egyelőre a küszöbön botlottam el. A példa program 8 bit 22kHz, ez kevés, 16bit 48kHz kellene. Próbálom átalakítani, de valamit elrontok, ha állítok valami, nem jön a stream. Idő és tipródás kérdése, szerintem menni fog.
(#) vorosj válasza vorosj hozzászólására (») Nov 14, 2021 /
 
A tipródás megvolt, működik az USB-s hang stream 48kHz 16 bit módban. A frekvenciamérés nullátmenet interpolálással sima ügynek látszik.
Az SI5351 vezérlése érdekesebb lesz, a szokásos könyvtárak általában nem képesek a szükséges finomsággal állítani a frekvenciát. (8 tone van egy 50Hz-es sávban, pl. 7,074MHz-en)
(#) kiborg hozzászólása Nov 24, 2021 /
 
Sziasztok!
Valaki dolgozik assemblyben STM32F103-al? Milyen program/IDE-t használ?
Mit érdemes használni, ami mint az avr időkben kód ír, lefordít, letölt és tudok debugolni.(JTAG-ICE)
ST-LinkV2 programozóm van és BluePill-t nyúzok.
Találtam ezt az oldalt:nicerland, de a Keil-t használja,ami kódméret limites.Ezt szeretném elkerülni,ha lehet.
(#) kapu48 válasza kiborg hozzászólására (») Nov 24, 2021 / 1
 
Használd a gyári :
Bővebben: stm32cubeIde
Ingyenes, gyorsabban fordít mint a keil, a asm és C. rész az pedig egységes ezért hordozható.
(#) kiborg válasza vorosj hozzászólására (») Nov 25, 2021 /
 
EmBitz és asm. Lent a kód.
Hozzáférek a system regiszterekhez és így egész jól tudom állítani az órajelet, viszont akkor is kevés. A 11,99MHz-t milyen beállításokkal sikerült elérni?
A lenti kóddal 8MHz belső órajelről 190kHz jel van a kimeneten, ha PLL-t használok,és PLLSRC->HSI/2 és PLLMUL=2,akkor ugyanaz a 190kHz-et kapok.
Ha átváltok fixen PLL-re és HSE-re, növelem a PLLMUL értékét,akkor szépen nő a kimeneti freki is, egészn 1,71MHz-ig.
A CubeMX órajel konfigurátora szerint PLLMUL=9 a legnagyobb, hogy a Systemclk=72MHz a megengedett legnagyobb.
Ha ennek ellentmondok és PLLMUL értékét beállítom x16-ra,akkor 3,05MHz-lesz.(amikoris a CubeMX szerint már 128MHz a systemclk)
Tehát szépen skálázódik,de a megengedett értékig. De hogy lett 11,99MHz ?

Valahol utána lehet nézni, hogy melyik utasítást hány órajel alatt hajt végre ?

  1. .thumb
  2.     .syntax unified
  3.  
  4.     .equ RCC_APB2ENR, 0x40021018
  5.     .equ GPIOC_CRL, 0x40011000
  6.     .equ GPIOC_CRH, 0x40011004
  7.     .equ GPIOC_ODR, 0x4001100C
  8.  
  9. loop:
  10.     nop
  11.     nop
  12.         LDR     R1,=RCC_APB2ENR
  13.         ORR R0,R0,#0xFC         //;enable the clocks for GPIOs
  14.     STR R0,[R1]
  15.  
  16.         LDR R1,=GPIOC_CRH
  17.         LDR R0,=0x44344444
  18.         STR R0,[R1]                     //;PC13 as output
  19.  
  20. main:
  21.         LDR R1,=GPIOC_ODR
  22.         LDR R0,[R1]                     //;R0 = ODR
  23.         EOR R0,R0,#0x2000       //;toggle bit 13
  24.         STR R0,[R1]                     //;ODR = R0
  25.         B       main
  26.  
  27. .global loop
A hozzászólás módosítva: Nov 25, 2021
(#) vorosj válasza kiborg hozzászólására (») Nov 25, 2021 /
 
Mellékelek egy képet, azon látszik a kód, és az is, hogy mire fordult le. Keil IDE, Keil compiler. De ha a disassembly ablakban látható kódot beírod az Embitz-be, nyilván azonos lesz az eredmény.

Beállítások:
CubeMX: 72 MHz 8 MHz-es kristályról
GPIO C13, high speed-re állítva
Compiler:
-03 optimalizálás, speed bejelölve

Az eredmény 12MHz a C13 pinen. Ha a C13 low speed-re van állítva, akkor 8MHz a kimenet.

A te assembly kódod több utasításból áll, és valószínűleg nem állítottad high-re a port speedet (low a default), ezért kisebb a frekvencia.

code1.jpg
    
(#) vorosj hozzászólása Nov 25, 2021 /
 
Feltűnt nekem, hogy az Embitz kicsit mintha homályosan jelenne meg (úgy értem, nem teljesen élesek a betűk, mintha túl kis felbontású fényképen nézném). Ugyanez Keil-lel is előfordult, ha közvetlenül indítottam, ha viszont a CubeMX-ből, akkor éles volt.
Talán másnak is segíthet a megoldás. A Windows csinálja vele, jobb katt az indító ikonon, tulajdonságok, és a képen látható magas DPI beikszelése.

blurry.jpg
    
(#) vorosj válasza kiborg hozzászólására (») Nov 26, 2021 /
 
Idézet:
„Valahol utána lehet nézni, hogy melyik utasítást hány órajel alatt hajt végre ?”


Tipikusan 2, ha flashben fut a kód, mivel a flash lassú, ezért 1 wait-et iktat be. Ha literalt tölt flashből, vagy lassabb buszon futó perifériához nyúl, akkor persze több. Pl. GPIO utasítás is lehet hosszabb, ha low speed van beállítva.

Nem vagyok túl gyakorlott az ARM utasítások időzítésében, próbálom kerülni. (Sokat dolgoztam PIC-kel, ott természetes gyakorlat volt időket számolgatni, de ARM-oknál már nem.) Abban a nagyon ritka esetben, ha ciklusból időzítek, szkóppal meg szoktam mérni. De inkább arra törekszem, hogy timerekkel vagy más perifériákkal, DMA-val stb érjem el a megfelelő real-time viselkedést. Különösen, mivel a kicsit nagyobb uC-kben már végképp elbonyolódik a dolog, mert gyorsítótár van stb, és ha interruptok ketyegnek, ráadásul kiüríthetik a gyorsítótárat is, akkor kegyetlenül nehéz kisakkozni korrekt ciklusidőket.

A példában látszik, hogy mindhárom utasítás 2 ciklusos, ebből jön ki a 12MHz. A 99 végződés oka, hogy a CubeMX defaultban felhúzza a systick interruptot, ami persze beleszaggat a négyszögjelbe.

Nem próbáltam, de szerintem tovább gyorsítana, ha a kész kódot RAM-ból futtatnád, mivel a RAM elérésben nincs wait.
(#) vorosj válasza vorosj hozzászólására (») Nov 26, 2021 / 1
 
Ha pl. az a feladat, hogy gyors, komplex bitfolyamot kell létrehozni, az spi-vel lehet legkönnyebben megoldani. Ha DMA eteti egy RAM pufferből, akkor alig terheli a cpu-t.
(#) kiborg válasza vorosj hozzászólására (») Nov 26, 2021 /
 
Igen, gyors, komplex byte folyamra van szükség, plusz 3 egyéb bit bizergálása. Kipróbálom a módosítást. Köszi az ötleteket.
(#) kiborg válasza vorosj hozzászólására (») Nov 26, 2021 /
 
Siker, másképp, de megoldva a 12MHz-s kimenet jel.
Végképp eldőlt, hogy ASM irányba megyek tovább.
Lényegében egy drivert kell írni egy 640x240-es LCD kijelzőhöz. Plusz ami nehezebb lesz, hogy úgy kell adatot fogadni (SPI,UART,stb, még képlékeny), hogy ne akadjon meg a kijelzés.
Bár az lenne a legjobb, ha lenne egy olyan memóriám,amit egyik oldalról a driver olvas, míg másik oldalról egy másik MCU tölt meg időnként adattal. Létezik ilyen memória?
(#) kiborg válasza vorosj hozzászólására (») Nov 26, 2021 /
 
Ha minden igaz, megtaláltam
Lint, ha ha kattintasz
(#) vorosj válasza kiborg hozzászólására (») Nov 26, 2021 /
 
Ez az alap, de nem elég, mert ezt még módosítják az egyedi hw sajátosságok. Pl. ami itt 1 ciklus, az az STM32F103 esetén 2 ciklus lesz, ha a szokásos módon flash-ből fut a kód, mert beiktat a hw 1 wait ciklust minden flash elérésbe.
(#) vorosj válasza kiborg hozzászólására (») Nov 26, 2021 /
 
Idézet:
„Plusz ami nehezebb lesz, hogy úgy kell adatot fogadni (SPI,UART,stb, még képlékeny), hogy ne akadjon meg a kijelzés.”

Ez DMA-val könnyen megoldható. A DMA az érkező adatot szépen memóriába pakolja anélkül, hogy a cpu működését lassítaná. Persze előbb-utóbb csinálni kell valamit a memóriába került adattal. A DMA interruptot adhat minden fél memória átlépésnél, így lehet tudni hogy hol tart, és hogy melyik memória szegmenst lehet feldolgozni éppen anélkül, hogy a dma felülírná munka közben.
(#) vorosj válasza kiborg hozzászólására (») Nov 26, 2021 /
 
Idézet:
„Lényegében egy drivert kell írni egy 640x240-es LCD kijelzőhöz.”

Ebben a műfajban a hasonló árfekvésű Pi Pico ügyesebb.
- maga a periféria is programozható, így pl. a vezérlő bitek kiadását teljesen rá lehet hagyni
- 2 cpu van, egyik foglalkozhat a kijelzővel, a másik meg zavartalanul minden mással
- eleve gyorsabb cpu-k

Az STM32F103-at már nem gyártják. A különféle utánérzett gyártmányok közül a GD32F103 vagy F303 (ez M4 magos) vált be, eddig nem tapasztaltam inkompatibilitást (ellentétben több más gyártmánnyal), és gyorsabbak az eredetinél, mert egyrészt RAM-ból futtatnak alapból, másrészt 108MHZ a specifikált maximum.
Az F303 elnevezés némiképp megtévesztő, mert azt lehetne gondolni, hogy ez az STM32F303 megfelelője, de nem az. A perifériái az F103-mal egyeznek meg. A fő különbség az M4 mag, és egy D/A konverter pluszban.
A hozzászólás módosítva: Nov 26, 2021
(#) vargham válasza vorosj hozzászólására (») Nov 26, 2021 / 1
 
Idézet:
„Az STM32F103-at már nem gyártják.”

Ez nem igaz. Kérlek, nézz utána, és linkelj forrást.
Az STM 2021 januárban kiadott hosszútávú tervében azt nyilatkozta, hogy még legalább 10 évig gyártásban marad. Nem szoktak egyik napról a másikra megszűntetni egy-egy termékcsládot.
Bővebben: STM Product Longevity
Következő: »»   160 / 177
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem