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

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

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.

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.

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

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.

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

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.

Sajnos ami írtál az még az adatlapnál is nehezebbnek tűnik

A képlet szerint Baud= 36Mhz/(16xUSARTDIV)

36Mhz a PCLK1
Csaz azt nem értem hogy mi az a Mantissa meg a 3 bites Fraction.

É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
F_ck=36M, B=9600
B=F_ck/(16*USARTDIV)->
USARTDIV=F_ck/(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.

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.

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?

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.

Köszönöm, jó lett HAL-os DMA USART küldés.
Beraktam a


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?







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?

Bővebben: Link

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.

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.

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.

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.

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.

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.

Mi az hogy HAL-os, mi az az LL?

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

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:

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.

Amit kiírsz (rec, illetve rec->ax) az üres. Nincs benne semmi, legfeljebb véletlenszerű memóriatartalom.

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

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.

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?