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   151 / 177
(#) don_peter válasza Topi hozzászólására (») Aug 26, 2020 /
 
Az igazság az, hogy ezt a kódot használtam már máshol és szépen működik a mai napig. Furcsa számomra, hogy ennél a kontrollernél meg kell egy olvasást kezdeni mielőtt a jó adat jön. ezért akadtam le.. Van analizátorom, de azt csak akkor használom, ha konkrét adatokra vagyok kíváncsi, itt a debug is elegendő volt a hiba azonosítására, csak arra nem hogy megoldjam illetve kiküszöböljem a hibát. Mostanra az is megvan.. Köszi még egyszer..

ui: mondjuk változott a lib is mert észre vettem hogy a CubeMX másként generálta a projektet mint régebben. Meg is lepődtem..
(#) cimopata hozzászólása Szept 2, 2020 /
 
Üdv

STM32F103 al játszok és észrevettem hogy nincs külön transitter és received register az USART-nak.
F030-nál volt két külön regiszter de a 103 nál 1db közös USART_DR register van.

Azon gondolkozom, hogy lesz így problémamentes a küldés fogadás?

F030 nál úgy használtam hogy a küldés DMA-val volt feltöltve.
A receiver pedig megszakításban indította a függvényt és kiolvastam az adatot.
Ha így hagyom az F103-al akkor nem fog felülírni a küldés parancs az épp beérkezett adatot az USART_DR regiszterben?
(#) vargham válasza cimopata hozzászólására (») Szept 2, 2020 /
 
A konkrétproblémáról jut eszembe: A munkahelyemen is többször belefutottunk ilyesmibe. Az F103 elég régi darab, egy csomó mindenre nincs benne külön regiszter. Most például az USB/CAN kommunikáció jutott eszembe. Szóval mi arra jutottunk, hogy újabb MCU-kat használunk az STM32 sorozatból.
(#) benjami válasza cimopata hozzászólására (») Szept 2, 2020 /
 
Két külön regiszter van ott valójában, csak az elérhetősége van azonos memória címen. Ha írási művelet történik, akkor a TDR regiszter lesz kiválasztva, ha olvasási művelet akkor meg az RDR regiszter. A referencia adatlapon látszik is, hogy ez két teljesen külön regiszter.
(#) cimopata válasza benjami hozzászólására (») Szept 2, 2020 /
 
Értem köszönöm.

Közben nem tudom mit rontottam el a Keil ben de ezt az üzenetet kapom. Próbálom megnyitni a projektet amin dolgozom de indulásnál a uVision hibát ír ki.
Tegnap még úgy zártam be hogy ment.
Másik gépen megnyitódik.
Mi lehet a baj. Azt írja Visual Studio bla bla bla, de ilyen nincs is a gépemen.
A hozzászólás módosítva: Szept 2, 2020

Névtelen.png
    
(#) cimopata hozzászólása Szept 3, 2020 /
 
Sikerült végül megoldanom a hibát, elavult volt a uVision mert a frissített CubeMX már alap kódo generált. Legújabb verzióval már eltűnt a hiba.
(#) cimopata hozzászólása Szept 4, 2020 /
 
Üdv.

32F103-nál tudna valaki segíteni , hogy ha 56Mhz az órajel akkor mi lesz az USRAT BRR regiszter beálltás 9600, 19200, 38400 baud sebességnél? Nehezen értelmezhető az adatlap.
(#) cross51 válasza cimopata hozzászólására (») Szept 4, 2020 /
 
Csak egy tipp, mert nekem is katyvasz nagyon a doksi, hogy is kell baud-ot számolni én ilyenkor szoktam azt trükközni, hogy előveszem a gyári lib-et és azzal kiszámoltatom.
Vagy ha nem akarsz szenvedni, de nem szereted a gyári lib-eket én LL-t használtam saját driver-hez az kb register szintű, csak olvashatóan.

Ha ezt a módszert használod a SystemCoreClockUpdate-ot hívd meg.
(#) cimopata válasza cross51 hozzászólására (») Szept 4, 2020 /
 
Sajnos ami írtál az még az adatlapnál is nehezebbnek tűnik
(#) cimopata hozzászólása Szept 4, 2020 /
 
A képlet szerint Baud= 36Mhz/(16xUSARTDIV)

36Mhz a PCLK1
Csaz azt nem értem hogy mi az a Mantissa meg a 3 bites Fraction.
(#) cross51 válasza cimopata hozzászólására (») Szept 4, 2020 / 1
 
Én se szeretem (a Microchipes egyszerűbb volt) de annyi a lényeg, hogy ott a képlet ami lebegőpontos eredmény fog adni a mantissa lesz az egészrész a fractional a törtrész.

De ha egyszerűbb levezetem: (a ref manualból példákkal)
Vegyük 36 MHz-en 9600 baud-al
Fck=36M, B=9600
B=Fck/(16*USARTDIV)->
USARTDIV=Fck/(16*B)=234.375

Ezt az értéket kell a BRR-be programozni úgy hogy
DIV_Fraction=16*0.375=6, ha nem egész a legközelebbi egész
DIV_Mantissa=234
BRR=DIV_Mantissa<<4|DIV_Fraction=0xEA6

És egy értékre nálad:
USARTDIV=56M/(16*9600)=364.5833
DIV_Fraction=16*0.5833=9.33->9
DIV_Mantissa=364
BRR=0x16C9

Szerk.:
ha a legközelibb szám a 16 lenne akkor a fractional part túlcsordul és a mantissához 1-et (carry) hozzá kell adni.
A hozzászólás módosítva: Szept 4, 2020
(#) cimopata válasza cross51 hozzászólására (») Szept 4, 2020 /
 
Köszönöm, nagy segítség így már érthető.
Lesz több baud beállítás így ki kell számoljak többet is de így ezzel most már biztos leszek.
(#) cimopata hozzászólása Szept 12, 2020 /
 
Sajnos megakadtam az STM32F103-as USART összerakásával.

Ezt a HAL_UART_Transmit_DMA(&huart1, usart_tx_store, 1); függvényt használnám ami a F030-as programomban jól működött itt már nem működik jól.
A probléma az hogy 1x tud csak lefutni utána mintha semmit sem csinálna.

Ha a sima USART1->DR = 0x00; parancsot használom ahhoz hogy adatot küldjek akkor azt simán teljesíti, de a HALos parancsot resetelés után csak 1x.
Arra gyanakszom hogy valami feltétel nem teljesül és valami FLAG-et rosszul néz vagy nem tudom.
Annyi biztos, hogy a hardveres beálltásom jó lehet mert egyszer lefut és utána ha akarom küldetek adatot a USART1->DR paranccsal csak HAL-os nem.

Járt már valaki így?
Lehet hogy hibás a HAL-os gyári függvény?

Van valami egyszerű kódotok amivel kiválthatom a HALos cuccot?
(#) icserny válasza cimopata hozzászólására (») Szept 12, 2020 /
 
Nem próbálkoztam még ilysmivel, de úgy látom, más is járt már hasonló cipőben:
Ebben a fórumtémában panaszkodnak hasonló problémáról. Nem tudom, hogy rajtad segít-e az, amit ott javasoltak.

Vagy esetleg az ebben a társalgásban leírtak.
(#) cimopata válasza icserny hozzászólására (») Szept 13, 2020 /
 
Köszönöm, jó lett HAL-os DMA USART küldés.
Beraktam a

  1. HAL_UART_IRQHandler(&huart1);

sort a szemgszakítás elejére és a végére is.
Eddig csak a végén volt de ezek szerint valami bökenő volt.
Azért kíváncsi lennék egyébként mit csinál mit állít amit én nem tudtam. Nem igazán szeretem ezeket a HAL-os IRQHANDLER függvényeket, mert így kb 2usec egy megszakítás ki-be lépés. Anélkül meg kb 500nsec. Manuálisan szoktam törölni a flagaket az gyorsabb de itt most valami más van, kénytelen vagyok benne hagyni. Kicsit lassabb lesz a lefutása...
Másik kérdésem is lenne.
AZ alábbi megszakítás priorítás beállításánál a magasabb vagy az alacsonyabb szám hívódik elsőnek?

  1. HAL_NVIC_SetPriority(ADC1_2_IRQn, 0, 0);

  1. HAL_NVIC_SetPriority(TIM1_UP_IRQn, 1, 0);

  1. HAL_NVIC_SetPriority(TIM1_CC_IRQn, 1, 0);

  1. HAL_NVIC_SetPriority(TIM4_IRQn, 1, 0);

  1. HAL_NVIC_SetPriority(USART1_IRQn, 2, 0);


Az ADC-t szeretném legmagasabb prioritással sz időzítőket másodikra és a USART legkevésbé fontos így megfelelő vagy pont fordítva van a számozás?
A hozzászólás módosítva: Szept 13, 2020
(#) rolandgw válasza cimopata hozzászólására (») Szept 14, 2020 /
 
(#) moltam hozzászólása Szept 24, 2020 /
 
Helo.
WS2812 ledeket hajtanék stm32f103 ról, spi dma val. Felmerült a kérdés, hogy mi történik ha a kimeneti tömbömet átírom menet közben. Meg kell ilyenkor fogni a kiküldést vagy felesleges? Ha igen hogy érdemes szüneteltetni addig? Transfer complete megszakításban kilőni addig a dma enable bitjét? Sejtésem szerint hogyha megy is ki fals adat gyorsan helyreáll a rend mert folyamatosan löki ki az spi a biteket, és az írás utáni következő körben már helyes lesz az adatfolyam. Azt nem tudom hogy ez okoz e problémát.
(#) david10 hozzászólása Szept 24, 2020 /
 
Sziasztok,
Arról hol találok leírást hogy egy mikrokontrollerre futás közben miként lehet programot feltölteni ami egyből tudna futni is?
Tehát arról van szó hogy egy programozót szeretnék építeni ami tud LIN, CAN, RS485, K/L-line, J1850 protokolokkal kommunikálni, még 256KB flash se lenne elég hogy az összes program bele férjen + a másik lényeges dolog az lenne hogy ne kelljen firmware-t se frissíteni amikor egy új programrésszel kibővítem a PC-s programot.
Ilyen megoldással már láttam egy programozót, abban AT91SAM7S256 van, az teljesen egyértelmű hogy az is ilyen elven működik mivel ha valamit kiválasztok a menüjében akkor "valamit" feltölt a programozóra, a feltöltés sebessége függ az USB port sebességétől is, hosszú kábelen és USB hubon keresztül lassabban tölti fel a programot, szerintem RAMba kell feltöltse a programot mert ha kihúzom/újrabedugom a programozót és próbálok kattintani a Read gombra akkor az "Unknown unit already running" hibaüzenet jön elő.
A választ előre is köszönöm.
A hozzászólás módosítva: Szept 24, 2020
(#) csatti2 válasza moltam hozzászólására (») Szept 24, 2020 / 2
 
Az emberi szem nagyon érzékeny a hirtelen változásokra, semmiképpen se írj ki hülyeséget, észre lehet majd venni és nagyon zavaró lesz.
Ami a helyes megoldást illeti, több dologtól függ. Első lépésként határozd meg milyen gyakran akarod frissíteni a LED sorodat. Hány LED-ed van és ehhez mekkora adattömbre van szükséged. Mennyi ideig tart kiszámítani a kimeneti színeket.
Ha ezekre a kérdésekre megvan a válasz, akkor választhatsz az alábbi példa megoldásokból:
- Viszonylag sokáig kell a színeket számolni: Használj kettős puffer-t. Egyiket küld ki DMA-val, másikba "rajzolj", majd csere.
- Nagy a kimeneti puffer, nincs hely kettős puffernek: Használj körkörös DMA módot, dolgozz a puffer egyik felén, amíg a másikat épp kiírja, amikor jön a megszakítás (half done / completed), akkor váltsál
- A DMA idő és rajzolás ideje bőven belefér a kívánt frissítési ciklusba: Ne bonyolítsd túl ilyenkor mert minek, rajzold meg a puffert, majd lődd ki DMA-val, várj a következő ciklus kezdetére és kezdd elölről.
(#) benjami válasza moltam hozzászólására (») Szept 24, 2020 / 1
 
Ezt általában úgy célszerű megcsinálni, hogy a kimeneti tömböd tartalmát folyamatosan küldöd ki körkörösen. Ehhez a DMA CCRx regiszterben a CIRC bitet kell bekapcsolni. Amíg a tömböd első felét küldi ki a DMA az SPI-re, addig a tömböd második felét irkálhatod szabadon a programodból. Amikor a DMA a második felét küldi ki az SPI-re, akkor meg a tömböd első felét töltsd fel a szükséges adatokkal a programodból. Az ISR regiszter HTIFx bitje fogja közölni veled, hogy a DMA a tömböd feléhez ért, a TCIFx meg azt, hogy a végére ért. A DMA megszakítást engedélyezni a CCRx regiszter HTIE és TCIE bitjével tudod. A jelzés bitet törölni pedig IFCR regiszter megfelelő bitjeivel tudod. Az 'x' a DMA stream számát jelenti.
A hozzászólás módosítva: Szept 24, 2020
(#) csatti2 válasza david10 hozzászólására (») Szept 24, 2020 /
 
Ez így túl általános. Egyrészt jó lenne, picit leszűkíteni milyen mikrokontrollerre is gondoltál, mert nagyban függ a válasz arra, mik is a lehetőségeid. A 256kB flash nem tudom miért került elő, manapság ennél sokkal több flash-el rendelkező mikrokontrollerek is kaphatóak.

De hogy írjak egy példát is, ha megnézed mondjuk a STM32F4 családot (Cortex-M4), akkor ott az I-bus hozzá fér a flash-hez, az SRAM1-hez és az FSMC buszhoz. Azaz ezekről a területekről futtathat programkódot. Ha tehát írsz egy egyszerűbb kódot a flash-be, ami kommunikálni tud a PC-vel, akkor az letölthet tetszés szerinti programrészleteket futásidőben a PC-ről és beteheti a saját SRAM-jába vagy egy tetszés szerinti külső memóriába (amit FSMC buszon érsz el) és a feltöltés után ráállíthatja a PC regisztert és máris onnan fut a kód.

Példaként nézz bootloader-t. Gyakorlatilag ugyanazt kell csinálni, csak nem a flash a cél, hanem vmelyik másik memóriaterület és pont úgy kell a végén átugrani is az új kódra.
A hozzászólás módosítva: Szept 24, 2020
(#) david10 válasza csatti2 hozzászólására (») Szept 27, 2020 /
 
Köszönöm a válaszodat.
Lévén hogy létezik 1MB-os flash-el is STM32 mikrokontroller így nem éri meg hogy a ramból való program futattással kísérletezzek.
Ami nem fér bele az 1MB-ba (pl. memóriaképek) azokat egy SD kártyán tudom tárolni.
(#) phr3ak válasza cross51 hozzászólására (») Szept 27, 2020 /
 
Mi az hogy HAL-os, mi az az LL?
(#) vargham válasza phr3ak hozzászólására (») Szept 28, 2020 /
 
Mindkettő szoftverkönyvtár a hardver elérését segíti. Nem kell közvetlenül piszkálnod az MCU regisztereket.
HAL: Hardware Abstraction Layer. Magasszintű elérést tesz lehetővé. Például I2C esetén átadod a függvénynek a címet, az adatot, blokkoló vagy DMA legyen mondjuk az olvasás, és már csinálja is. A HALra épülő kód hordozhazó lesz az MCU családok között is. Minden olyan eszközön futni fog, amin az adott funkció, periféria elérhető.
LL: Low Level. A fentebbi I2C példa itt már több lépésből, vagyis függvényhívásból áll. Generate start condition, send byte (address), generate start condition, start read, stb. Hasonlít a regiszter szintű eléréshez. A hardver több funkicóját éred el, de a kód nem feltétlenül hordozható.
(#) rolandgw válasza vargham hozzászólására (») Szept 28, 2020 / 1
 
Elég sok segéd makro is van az LL-ben, amivel kevesebb lépésből meg lehet oldani feladatokat.
STM32G0, I2C MX példa:
  1. LL_I2C_HandleTransfer(I2C2, SLAVE_OWN_ADDRESS, LL_I2C_ADDRSLAVE_7BIT, ubNbDataToTransmit, LL_I2C_MODE_AUTOEND, LL_I2C_GENERATE_START_WRITE);
(#) madazg77 hozzászólása Okt 20, 2020 /
 
Sziasztok!

Egy MPU6050-es giroszkóp regisztereit szeretném olvasni a Githubról letöltött minta programmal. A board egy STM32L452RET6.
Kiegészítettem az LCD kiírással ami jól is működik, viszont a struktúra olvasást nem biztos, hogy jól csinálom. Mellékelek egy képet amin látszik a programom és a struktúra elemei. Az I2C kommunikáció gondolom jól működik, mert az MPU6050 init-et befejezi és az LCD kiírás elindul.
Mit rontok el?
Üdv.

Névtelen.png
    
(#) jefflynn válasza madazg77 hozzászólására (») Okt 21, 2020 /
 
Amit kiírsz (rec, illetve rec->ax) az üres. Nincs benne semmi, legfeljebb véletlenszerű memóriatartalom.
(#) kapu48 válasza madazg77 hozzászólására (») Okt 21, 2020 /
 
Ez a példa több sebből vérzik!
Ezért inkább linkelek egy oldalt a tankönyvből: Bővebben: Struktúrák
(#) madazg77 válasza kapu48 hozzászólására (») Okt 21, 2020 /
 
Hello.

Köszönöm a válaszod és a linket. jefflynn válaszát is köszönöm.
(Van még bőven mit tanulnom.)
Üdv.
(#) cross51 hozzászólása Nov 3, 2020 /
 
Sziasztok!

Nem tudom ez normális vagy nem:
egy magasabb és egy alacsonyabb prioritású task ugyanarra a semaphore-ra vár ezt egy harmadik köztes prioritású task release-eli, a két task indulása után (ez most csak egy test kód)
FreeRTOS:
mindegy melyik task indul előbb mindig a magasabb prioritás kap elsőnek jelzést a semaphore-ról
C#:
az a thread aki előbb kezdett el várni a semaphore-ra

Nem a második lenne evidens az első esetben is?
Következő: »»   151 / 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