Igen, időben korábban! Debugger alatt nézve, minden érték jó timer indítás előtt közvetlenül, és a flag mikor beáll, 0 a számláló értéke, tehát látszólag minden úgy működik, ahogy kell, csak éppen az első időzítés rossz.
Tegnap már csak annyi idő volt ezzel foglalkozni, hogy át tettem a tim6-ra, mert hogy ide az is elég. De ugyanaz az effektus volt...

Megtaláltam az okát a jelenségnek!
Az előosztó működése okozza ezt. Ha új értéket kap, az csak akkor jut érvényre, amikor lefut egy update esemény a timeren. Ezért volt az, hogy az első esemény, nem időben jött, hanem jóval hamarabb, mert hogy addig a pillanatig nincs előosztás.
A megoldás: az előosztó állítása után kézzel kell generálni egy update eseményt az UG biten keresztül. Utána lehet csak használni megfelelően a timert...

Érdemes ilyenkor belenézni a CubeMX LL generált kódba, a timer konfigurálás végére beteszi ezt a részt automatikusan:

Egyrészt..., nem használom. Másrészt..., a kódgenerátorok elég gyakran raknak bele felesleges, vagy annak tűnő részeket is a forráskódba! Amíg nem tudod, hogy konkrétan mi az értelme bármelyik sornak, addig pl ez is egy semmitmondó sor önmagában véve....

Kevés önmagában ez még a gyakorlatban! Meg is kell várni, hogy ténylegesen beálljon a flag...

Kódgenerátor nélkül meg sokkal hosszabb a fejlesztési idő. Különösen, ha összetettebb periféria, mint USB, ETH vagy BLE is van a dologban.

Nézegetem itt az STM32F303-as vezérlő ADC moduljainak lehetőségeit. Van ez az váltott mód(interleave). A doksi szerint a mintavételezés fázisa mondjuk 1,5 (ADC)órajelig tart. Utána pl 12 bit esetén jön a 12,5 órajelig tartó konverziós szakasz. Ehhez szerintük be kell állítani egy 5 órajelnyi késleltetés a DELAY struktúra tagban, hogy jó legyen a váltott mód.
Viszont, akárhogy számolom, 5+1,5=6,5 órajel jön ki. 14 a teljes konverzió időigénye. Ennek a fele kell, hogy legyen, az az 7 órajelnyi késleltetés a pontos váltott üzemmódú konverzióhoz. De a 6,5 az nem 7 nálam..., és ez érzékelhető pontatlanságot visz be!
Valamit nem jól értelmezek? Vagy ilyen trehányul alkották meg az ST-sek ezt a modult??

Most egy kicsit elbizonytalanodtam. Itt van egy pdf és a 31. 32.-ik lapon van egy grafikon ahol a cortex M3 skálái magasabban vannak . Ez azt jelenti hogy ARM cortex M3 erősebb/jobb M4-nél? Nem fordítva kéne lennie? M4 nem gyorsabb és erősebb?

Szerintem a grafikonok Y tengelyén az elvégzéshez szükséges idő van ábrázolva normalizálva a Cortex M3-hoz.
Vagyis pont azt mutatja, hogy mennyivel kevesebb idő kell az M4-nek az M3-hoz képest.

Köszi. Tényleg ez lehet

Y tengely alá odaírhatták volna hogy time

5 órajelnyi késleltetéssel tripla átfedéses módban találkoztam (3 órajel mintavételezési idő + 12 órajelnyi konverzió mellett), de ez STM32F446RE volt. (lásd ezen a weblapon a 2020. december 3-i előadásom utolsó mintapéldáját a 34. diától kezdve).

Duál módú átlapolásos mérésnél az 1.5 + 12.5 órajelciklushoz szerintem is 7 órajelnyi eltolással kell indítani a konverziókat.

Én a 429-es adatlapját néztem meg. Ott ez hasonlóan másképp van. Egész ADC ciklus van megadva, mind a mintavételezésnél, mind a konverziónál, így ott szépen és pontosan be is állítható a szükséges időeltolás mértéke a másik csatornára. Ráadásul itt már a késleltetés a mintavétel kezdetétől van számítva, nem annak a végétől...
De a 303-asnál ugye mind a két fázis fél órajel értékkel van megadva. Viszont a késleltetés pedig egésszel adható meg. Így sehogy se jön ki a pontos 90 fokos eltolódás...

STM32F103C8 (Bluepill) kártyával foglalkoztam még, ott is 1.5 + 12.5 órajelciklus van megadva, így duál módban 7 órajelciklus az eltolás és pont egészre jön ki.
Erre is van mintapéldám ezen az oldalon a 2019. december 19- előadásban. (Ez viszont Keil-es bitfaragás)

A 303-ashoz nem tudok hozzászólni, de szerintem a késleltetés a mintavétel kezdetétől kellene, hogy számítson ott is.

Az ok, de hogy jön ki egészre?? Ahogy feljebb is írtam, az adatlap szerint ezeknél nem a mintavétel kezdetétől értelmezett a késleltetés, hanem annak végétől(1,5 ciklustól számítva).
Az különbség a kettő típus között....

Részlet az adatlapból!

És az alatta lévő ábrákon is a mintavételi fázis végétől jelölik a DELAY idő számolását....

Megnéztem a 103-as adatlapján hogy van ez?! Ott viszont a mintavétel elejétől van ábrázolva az idő indulása. Bár elég szűkszavú az adatlap ezt illetően...

Így a 103-ason és pl a 446-oson is megadható pontosan a késleltetési idő, függetlenül attól, hogy az előző x.5-es időzítésekkel dolgozik, míg az utóbbi egész számokkal.
Viszont, a 303-asnál a feles idők miatt, és azért, mert a késleltetés számítása a mintavétel végétől indul, már nem adható meg korrektül a késleltetés.
Legalábbis az adatlapokból ez derül ki..., és a 303-as mérései is kb ezt támasztják alá. Bár, nem túl egyszerű ezt pontosan, korrektül lemérni.

Üdvözlet Urak

Habár nem blue pill-ről lesz szó de ugyanúgy STM32 és ez miatt nem akartam új topikot nyitni. Örülnöm kéne de ehelyett szétvet az ideg.
Megfogadtam vargham tanácsát és blue pill helyett rendeltem inkább NUCLEO-t . A kütyük hibátlanok , igényes, szép aranyozott pinek ,ARM cortex M4 van rajtuk ami szerintem nagyon jó , gyárilag van rajta egy program ahol a kék nyomogomb megnyomására a villogás sebessége változik. Tehát a hardware-ek tökéletesek (3db)!

A probléma ott kezdődött , hogy STM32 driverét felraktam. Már az elején gyanut kellett volna fogjak mert a windows Kiírta, hogy ismeretlen gyártó (1. kép). Majd kiírta , hogy nincs digitálisan aláírva így is telepítem? Megbízok ebben a szoftverben? Megbíztam a szoftverben mert az STM hivatalos oldaláról van letőltve (2. kép). NAGY HIBA VOLT mert 2 vírust kaptam a letöltésért cserébe (3. kép alul).

Egy vírusellenőrzést hajtottam végre a driver telepítése előtt és után is, és előtte nem volt vírusom az 100%. A kérdésem az lenne , hogy mivel én arduino IDE-ről akarom programozni a NUCLEO-t ezért van-e lehetőség stm32 driverét kihagyni valahogy? Vagy egy olyan régebbi verziót beszerezni ami még nem fertőzőtt. (egyébként ez a 2 vírus a STM32CubeProgrammer software for all STM32-ben is benne van)

Szerintem ez vaklárma nálad. Ugyanezt a szoftvert használom 5 különböző számítógépen, és kiválóan működik. Most letöltöttem újra, futtattam 3 ellenőrzést is (Windows Defender, Microsoft Safety Scanner, Malwarebytes), és egyik sem talált semmit.
STM32 driver nem létezik. ST-Link, ami a debugger, driver viszont igen. Drivert nem tudod kihagyni, anélkül nem beszélget vele a Windows.

Ne viccelj már Tele lenne a vírusos hírrel az ST fórum és az internet. Nem a nyílászárók szoftveredet kellene frissíteni? Kérdezem, mint Linuxos

Ugyanezt a szoftvert használod 5 különböző gépen de azt nem most töltötted le. Vagyis szerintem régebbiek azok. És ha Microsoft Safety Scanner régebbi akkor szintén nem találja meg csak a legújjabb verzió. Egyébként iszonyat gyors géped lehet mert az enyém I7, 8gb ram, kigston ssd-vel több mint 1 óra alatt fut le úgy hogy nincs semmi feltelepítve csak a windows 10.

Ezek olyan vírusok amit laikus nem vesz észre mert nincs tünet (látszólag).

STM32F303-as alany... Szeretném lemérni a belső Vrefint-et.
Ehhez a doksi szerint be kell kapcsolni a VREFEN bitet a CCR regiszterben, valamint az analóg csatornát átállítani a 18-asra.
Ám hiába teszem ezt meg, közel sem azt kapom vissza, amit kellene!
Van még valami más dolog is itt, amit be kell állítani, és elkerüli a figyelmemet?

Maga az ADC konverzió jó, külső feszt beadva szépen mér is, ahogy kell..., de ez a belső ref kifogott rajtam..., pedig jó lenne a pontos kalibrálási folyamathoz, ha ehhez tudnám számolni a kalibrációt!

Olvastad, amit írtam? Ott van benne, hogy a kedvedért letöltöttem újra. A scanner szoftvereket is frissítettem. Továbbra is fenntartom, hogy nálad van a probléma.

Köszi , hogy a kedvemért letöltötted újra de nekem az az érzésem , hogy a quick scann-t választottad ami nem nézi át az egész gépet csak a letöltéseket meg 1-2 windows mappát. Én a full scann-t használom mindig mert csak az megbizható (a virusok sem ott bujnak meg ahol a legkönnyebb megtalálni öket)

Van itthon még egy pc.. lehet azt is megfertőzöm a próba kedvéért

Nehezen tudom elképzelni, hogy az ST annyira gondatlan lenne, hogy fertőzött állományt osztana meg letöltésre!
Sokkal, de sokkal nagyobb a valószínűsége annak, hogy amit talált a kergetőd, mindössze valami túlbuzgó vaklárma jelenség, ami elég gyakran előfordul, már elég régóta!
Ha rám hallgatsz, nem leszel paranoiás, és nem foglalkozol ezekkel a riasztásokkal!
Ha mégis jogosnak érzed, ott a virustotal egyenként mindent leellenőrizhetsz, aztán statisztikai alapon eldöntheted, mit akarsz hinni....

Nagyon bizonytalan vagyok. Most kisérletezek olyan gépen aminek nemszámit, hogy mi lesz vele.

Szia. Csak ötletelek. Esetleg téves CCR regiszterben állítod be a VREFEN bitet(ADC12_CCR - az 1-es és 2-es ADC-k 18-as csatornáján kapcsolja, ADC34_CCR a 3-as és 4-es). A VREFEN bitnél van egy megjegyzés hogy csak kikapcsolt ADC -nél írható ez a bit.

Idézet:
„Software is allowed to write this bit only when the ADCs are disabled (ADCAL=0,
JADSTART=0, ADSTART=0, ADSTP=0, ADDIS=0 and ADEN=0).”

Egy 48 ezer embert foglalkoztató, 200 ezer céges ügyféllel rendelkező vállalatnál senkinek nem tűnik fel egy vírusos fájl, csak egy hobbielektronika fórumozónak. Ne nevettesd ki magad.

Mind a 4 ADC-n le szeretném mérni a Vrefint-et, így egyszerre próbáltam mérni mind a 4 ADC-vel(időben persze el vannak egymáshoz csúsztatva a mérések)
Kikapcsolt ADC-nél is ugyanaz van, mint bekapcsoltnál, maga a bit beáll, debuggernél látom, hogy be van állítva, ahogy szeretném! Viszont ennek ellenére teljesen hülyeségeket mérnek az ADC-k, konkrétan a 2,3,4 egymáshoz viszonylag közeli értékeket, míg az 1-es kb az előbbiek 3x-át méri. A várt értéktől mindegyik messze van igencsak...

Mellékszálként a Vbat-ot sem sikerült lemérnem. Ugyanaz a jelenség, a bit be van állítva, de a mért érték valami úszkáló valami, ami messze van a fél tápfeszből származtatott értéktől...

Közben kiderült az is, hogy sajnos nem csak offset eltérések lehetnek az ADC-k között, de meglepő módon erősítésbeli eltérések is adódnak(kb 3%). Így nem elég már a pontos kalibráláshoz egy offset-et számolni, amihez elég lenne a Vrefint mérése is, kell egy másik feszültség is, amiből az erősítést lehet majd számolni. Így úgy néz ki, mindenképpen külső forrás kell majd hozzá, az az meg tudom kerülni a Vrefint mérés problémáját...., viszont ettől még zavar nagyon ez a dolog, hogy miért nem tudom mérni?!!

Értem, akkor lehetséges hogy gyártási hiba? Az ERRATA-ban meg van említve az , gondolom hogy ez a gyártás folyamán meghatározott érték (VREFINT_CAL) és később a számítást eltolja, hibát visz be. Lehet a tiéd is bele esik ebbe a sorozatba.

Én azt feltételezném, hogy a gyári kalibrációs folyamat során is ezt a belső Vrefint-et használják... Mivel más viszonyítási alap nincs benne, amihez számolni lehetne az eltérést. Így azt gondolom, mivel az viszonylag jól, és stabilan lefut, +-1 bin értékkel mindig ugyanazt az eredményt adja, valószínűleg magával a Vrefint-el nincs baj. Olyan, mintha a belső átkapcsolás nem működne megfelelően...
Egyelőre elengedem ezt a dolgot..., ha lesz kis időm és kedvem, megnézem ezt a jelenséget egy másik procival, 407-essel. Köszi az agyalást...

A ST-Nucleo-F302R8 - nál is van minden digitális lábon belső felhúzóellenállás?
pinMode (button, INPUT_PULLUP) ; működne ugyanúgy mint az arduinonál? (pl nyomógombhoz)
VIN-en hány volt mehet be? 7-12?
power 5V pinen lehet 5V-al táplálni vagy inkább a VIN-en legyen táplálva?