Nem pont topic tema, de nem is tudom hova kellene irnom. Azert nem teljesen tema idegen, hisz csak kicsivel feljebb emlitettem az osi radios modulok illeszteset a modern mcu-hoz, amihez ugye kell egy manchester en-/decoder is.
Szinten emlitettem a vscode-ot, mint (nekem, most) elsodleges fejlesztorendszer es github copilot-ot.
Ha esetleg valaki nem ismerne az utobbit, ez ahogy gepelsz az editorban ugy kutat megfelelo, relevans kodreszlet utan, es felkinalja ha szerinte valami passzol az adott kodhoz.
Neha megdobbentoen pontos amit kinal. En most screenshot-ot csinaltam, mert azon latszik epp hol tartottam a gepelesben, amikor felkinalta a teljes fuggvenyt (amit amugy is terveztem, illetve hasonlot mar regebben hasznaltam mas repository-ban)
Szinte teljesen perfect megoldas.
Hogy ez aldas vagy remiszto, mindenki dontse el maga , az biztos, hogy a napi munkam soran tomenytelen unalmas melotol szabadit meg, amit aztan mas, erdekesebb vagy bonyolultabb feladatokra fordithatok...

Havi előfizetésed van?

Ceges csomagban van, de mivel nekem engedelyeztek a privat gep hasznalatat, raadasul a vscode tobb github account-ot is kezel egyszerre, igy mukodik mindenhol

A kerdesek 90%-a a doksi olvasasanak hianya, altalaban Hatha valakinek mar nem kell megkerdeznie:

A STM mernokei gondoltak erre a kerdesre, piros pont nekik. A nucleo-L432 board aljan a tucatnal tobb solder bridge mellett ott egy miniatur jumper, ami a proci tapagaban van, az lehuzva es valamit ramutve (1.27mm-es header) mar merheto is a proci fogyasztasa. Lehet mukodtetni a boardot elemrol is, az stlink nelkul, az picit tobb beavatkozast igenyel.
Mindenesetre jol latszik, hogy a proci fogyasztasa mindenfele teli almos buveszkedes nelkul is, pusztan az orajel beallitasaval leviheto atlagos 16mA-18mA-rol 500uA-2mA-re. (Persze attol fuggoen mit es mennyire hasznalunk).

Kicsit matekoltam meg ezzel a VBAT pin problemaval, nevezetesen, hogy a birtokomban levo blue pill-ek donto resze meghajtja a VDD labakat ha a VBAT-ra elemet (barmilyen tapot) dugok.
Elsore ugye az tunt fel, hogy vilagit a power LED, ennek megfeleloen a fogyasztas is valahol 2mA kornyeken alakult.
A dokumentacio eleg vilagosan fogalmaz, ahogy a mellekelt abran latszik ez eleg egyertelmuen nem tortenhetne meg.
Jelenleg het panelem van, harom kulonbozo helyrol (lasd masodik kep). Az ket jobb szelso egy csapat, csak a szelsorol hianyzik mar a proci.
Mint latszik osszesen ketfele panel, haromfele szereles. Ami nem latszik: A bal szelso kivetelevel a procik egyformak.
No ezeken nem mukodik a VBAT lab. A bal szelso az teljesen rendben van.
Amikor a kiemelt proci VBAT laba ~3.0V-ot kap, akkor a VDD labakon ~2.5V jelenik meg.
Van eredeti nucleo is (F103RB proci), az szinten mukodik ahogy a doksi leirja.
Az utolso kep csak a dokumentalas miatt, szegeny proci sorsat bemutatando keszult (nem volt hova beforrasztanom, ezert maradt a kabel hegesztes..)

Ezt csak azert tettem ide, ha valaki hasonlo fogyasztasi problemaba fut, akkor ezt is ellenorizze...

A konklúziót lehagytad. Az a tipped, hogy a rosszul működő MCU-k hamisak, és belül a VBAT és a VDD össze van kötve egy diódával?

Hogy pontosan hogyan van osszekotve azt nem tudom, de velhetoen igazad van, es egy dioda van ott. Es igen, ugy nez ki hamisak.
Szerintem amikor klonoztak, akkor beneztek a doksit, ahol a VBAT es Vss osszekoteset javasoljak ha nincs battery
Jovo heten talan megjon a Farnell-tol rendelt (velhetoen 'igazi') F103C8T6, feldobom a board-ra es meglatom.
(nem biztos hogy ideer Leeds-bol ot nap alatt, a DHL eleg jol josolhato Leeds, Leipzig, Singapore, Sydney, Auckland uton hozza ezeket... )
Ahogy feljebb irtam egy blue pill-em van a hetbol, ami ugy mukodik ahogy a doksi szerint kellene.

Sziasztok!
STM32-Blupill-el mérnék feszültséget( 8 csatorna) gyakorlatilag potik gnd és 3,3V közé kötve. Lesz csatlakoztatva egy nRF24L01-is. Két sorosan kötött 18650-es akkuról kapja a tápot egy AMS1117- stabilizátoron keresztül.
Hogy tudnám elérni, hogy az analóg olvasás a legstabilabb legyen, minél kisebb legyen az alsóbb bitek billegése ? Érdemes külön tápról járatni a nRF-t és az STM-et vagy a potikat ? Válaszokat előre is köszi.

Teszel az analóg bemenetre egy kondit a föld felé. Minél nagyobbat, de a mérés sebességigényéről még nem írtál. Általánosságban pár nano elég, ha a potit tekergeted kézzel.
Az adó szerintem nem fogja rángatni a tápot, de ki kell próbálni, egy nagyobb kondi a táp-föld közé oda sem árthat.
Meg persze szoftveres átlagolás, szintén a sebesség elvárásának függvényében.
Én úgy szoktam, hogy 64 egymás utáni mérés, utána sorbarendezés és a középső elem értéke.
Gyorsabb változat: 64 mérés, összeadod őket és utána leshifteled 6-szor.

Igen, kézzel van "tekergetve". RC távirányító, tehát dinamikus mozdulatok azért előfordulnak. Eddig 100nF-t raktam a poti lábaira, de akkor közelebb viszem az MCU-hoz. Eddig nem volt átlagolás, de akkor ezt kipróbálom. Köszi szépen.

Ne a potira rakd a kondikat, hanem tégy be egy soros ellenállást(pár k) a poti után, és azt szűrd egy kondival! Így nagyjából fix időállandód lesz, bármilyen állásban is lesz a poti, és valamennyire a poti alap értékétől is független lesz.
Akkora kondit tégy oda, aminek a hatását épp csak érezni kezded, gyors mozdulatoknál.
Ha az utolsó biteket is ki akarod nyerni, akkor átlagolás mindenképpen kell... Nézd meg mekkora szórás van enélkül az eredményekben, és abból már ki lehet számolni, milyen mélységű átlagolásra lesz szükség?!

Rendben, kipróbálom, köszi az ötletet.

A gyári STM32F103-al (bluepill) valójában mennyire kompatibilis a CKS32F103 (szintén bluepill) ?
Arduinoval használnám, észre fogom venni a különbséget ?

köszi a válaszokat.

Nem feltetlen bluepill de a majdnem, STM32L432 nucleo board, max orajelen fut (80MHz), a periferiak is.
Nem derult ki elsore a doksibol, talan egyszerubb, ha megkerdezem, mintha orakig keresgelek.
Arra lennek kivancsi pontosan mi tortenik az External Interrupt detektalasa es a HAL_GPIO_EXTI_Callback kozott.
A mellekelt kepen a [1-Yellow] a main() vegtelen ciklusban billegteti az egyik labat, a [4-Blue] felfuto elere triggerelt az interrupt.
A [1-Yellow] labon jol latszik az interrupt kiszolgalasi ideje, ami kb 52 oraciklus (662ns) , viszont az interrupt csak max 12-13 utasitast hajt vegre:


Lehet ezt javitani valahogy, (eltekintve a megszakitasban foglalt kodtol, az odaig vezeto ut erdekelne) vagy nezzek gyorsabb mcu-t?

A kontextusváltáshoz kell sok idő. Teljes regiszterkészlet elmentése. Ha használod az FPU-t, akkor még annak a regisztereit is menteni kell.

Nem mondtad, mi a feladat. Te tudod, hogy milyen gyors reakcióra lenne szükség.
A mikrokontrollerek így működnek, szoftverből sok idő egy-egy külső triggerre reagálni.
Ha azonnal (10-20 ns) kell reagálni, akkor azt hardveresen kell megoldanod.
- Egyszerű logikai áramkörrel. A trigger hatására átbillen. Közben az MCU is odaér, megcsinálja, amit kell, és reseteli. Ha egymás után sok ilyenre van szükség, akkor ez nem működik.
- FPGA vagy egyéb olyan konfigurálható logikai hálózattal, ahol szoftver nélkül, órajelre egyszerre történik minden.
- Olyan mikrokontrollerrel, amiben van szoftver nélkül működő, konfigurálható logikai háló. RPI2040, újabb AVR és PIC sorozatok, stb.
- Töbszáz MHz órajelű mikrokontrollerrel is próbálkozhatsz. Ott is ugyanennyi órajel a kontextus váltás, csak hamarabb megtörténik.

A feladat: felfuto elre indulo trigger es a reakcio kozti ido csokkentese a rendelkezesre allo eszkozokkel

Adott egy ketfazisu, ~500kHz-es orajel, abbol allit elo az mcu egy SYNC jelet, a fenti kepen az also, [2-Cyan]. Ekozben vegrehajt par feladatot, ez a resz most lenyegtelen, belefer a kivant idobe.

Azert STM32xxx, mert ez a leggyorsabb, ami itthon van es van hozza felkonfiguralt fejlesztoi kornyezet es valamennyi tudas...
Van RPi2040 de azzal nem foglalkoztam eleget, es van BeagleBone is aminek ugye van 2 db PRU-ja, eleg impozans sebesseggl (Unibus kartyahoz hasznaltam, ahol 15ns a loop), de azt egy kicsit soknak erzem ehhez, raadasul nem szeretnek 'akkora' aramkort hozzaadni a meglevohoz. Raadasul ott is fejlodnom kellene.
Nem a tanulni akaras hianyzik, hanem az ido
STM32 csaladbol sem vagyok profi, egszeruen csak szimpatikus, alapszinten elboldogulok a periferiakkal, eddig ez eleg volt. Radasul legtobbszor meg mindig arduino (8 bit-es cuccokhoz) vagy ha kell wifi akkor az esp32 a nyero, azokkal a legegyszerubb hirtelen megoldanom a felmerulo problemakat.

Ebben a projectben (regi 8 bites szamitogep ujraepitese) eddig eleg volt egy mezei ATmega2560 (lasd a kepen), ami elvitte a kerdeses kartyak mind a 40 csatlakozojat, de most kicsivel furgebbet szeretnek. Ezert log ott a kep bal also sarkaban a Nucleo..
Az eddigi eredmeny nem rossz, de a kesobbiekben elofordulhat, hogy megszakitasban futo kod kifut az idobol.
Az is lehet jobban jarok ha csak egyetlen megszakitast hasznalok, vagy epp egyet sem, siman egy loop-ban poll-ozom a kivan labakat, az csak 2-5 utasitas, kevesebb, mint 100ns.
Valahol lattam (de sajnos most nem talalom) hogy 3xx ns csak a megszakitas kezelo elerese, igazabol a kerdesem erre vonatkozott hatha valaki fejbol tudja hol keressem

Így van. Azon nem tudsz faragni.

Pár éve megnéztem ezt néhány MCUnál.
A trigger ment a szkópra és az MCU bemenetére. A megszakításlezelőben nem volt semmi más csak egy kimenet átbillentése, a kimenet szintén a szkópra kötve. Ott néztem az eltelt időt.
8 bites géphez szerettem volna a belső buszra illeszkedő kiegészítőt építeni, de ez így túl lassú.

Koszonom a megerositest, gyanus volt, hogy igy nem fog menni.
Erdekes a tablazat, azt hittem azert a H473 kicsit jobban teljesit...

Amit feljebb irtam kiprobaltam, az persze hogy hulyeseg poll-ozni , hisz akkor a loop minden vegrehajtasanal bukok minimum kb 90ns-ot, fuggetlenul, attol, hogy van-e megszakitas (pin felfut) vagy nincs...
Az eredeti terv (jelenlegi felallas) szerint kb 45-50 utasitasnyi idom van ket (kulso, ketfazisu) orajel kozott, ez egyelore elegnek tunik, de lehet vannak olyan esetek/kovetelmenyek, amiket most meg nem tudok/latok.
Ez esetben nezek valami mast. Tudom, hogy ideje lenne FPGA kurzusnak, regota izgatja a fantaziamat, de nem nagyon latom az idoszeletet ra

Hibrid megoldásnak jó lehet a RP2040. Még nem próbáltam, de sokan mások sikerrel alkalmazták hasonló feladatokra. Van benne 2 ARM CPU és 2 programozható IO blokk. Ideális ilyen helyre.

..csak az erdekesseg kedveert osszeraktam egy RP2040 kornyezetet.
Nulla tudassal, c (nem tudom a uPython mennyire gyors), szokasos irq callback.
Indulasnak, minden extra beallitas nelkul 1.3us mire meghivja a callback-et.
Szimpla pin billegtetese egyelore ~52ns, de itt tuti nem eleg a standard megkozelites, annal joval tobb kell
Egy kicsit probaltam csalni, feltoltam 250MHz-re az alap orajelet de nem sokat segitett (raadasul bizonytalan lett kicsit, vagy csak zavarerzekeny).


Lehet egy idore elengedem ezt a reszproject-et, van enelkul is mit tanulnom

Az RP2040 ben tudtommal assemblyben programozható PIO van nem logikai blokk, bár lehet az is jó lehet erre a célra. PIC nél használtam már a CLC t, az jó cucc, regiszterekkel beállíthatóan lehet összekötögetni a kapukat/flip flopokat.

A micropython meglehetősen lassú. SPI felületű TFT-nél - persze túlzással, - de az érzés az, hogy látom ahogy pixelenként rakja össze a betűket.

Meg este fel szemmel lattam, hogy van aki 8ns kornyeki loop-ot hozott letre vele. Az nem rossz, kerdes, milyen furgen reagal a megszakitasra, hany ns kell mire egy felfuto elbol eljut az elso utasitasig.
Nem tudom mostanaban lesz-e ra idom, erdekes terulet, es most jol jott volna.

Meg annyit a meresekhez, hogy megneztem egy STM32WB5MMG-t is (volt a fiokban), amihez hirtelen nagy remenyeket fuztem (azt nem tudom miert...), de aztan rajottem ez is csak 64MHz-en megy.
1.13us-ot tudott.... :-|

A HAL_GPIO_EXTI_Callback majdnem biztos, hogy nem a megszakításkezelő függvény, hanem valami amit az eredeti megszakításkezelő meghív pointer alapon. Ennek a pointer szerinti függvényhívásnak van egy overheadje amit le lehet sprórolni ha a gyárilag adott megszakításkezelő helyett sajátot írsz. Alacsony szinten programozva meg lehet spórolni azon regiszterek mentését is, amit nem használsz. Például AVR-ek esetén lehet olyan trükköt csinálni, hogy az ember fixen allokál egy regisztert a megszakításhoz, és akkor egyáltalán nem kell menteni meg visszaállítani semmit. Ehhez hasonlót talán megtehetnél ARM-en is, csak itt még nehezebb, mert a C fordító se támogat ilyen trükköket. Csak azért mondom, hogy elvileg azért lehet faragni ezen a válaszidőn még, de talán nem sokat.

Igen, ilyesmi 'trukkon' gondolkodtam en is, foleg, hogy nekem tenyleg nincs mit menteni, gyakorlatilag megszakitaskezeloben futhatna ami kell.
Lehet ideje lenne nekiallnom stm32 assembly-nek, erre a feladatra tokeletes lenne/lehetne.
BTW, lehet stm32 mcu-kat siman halt-al megallitani? Ha igen, akkor a befuto megszakitasra gyakorlatilag csak egybol egy ugras kellene a kiszolgalo rutinra, bar lehet ez gyarilag kicsit bonyolultabb

PIO-t kell használni hozzá. Ami az ARM CPU-tól függetlenül, 1-2 órajel alatt le tud kezelni egy csomó mindent.

Igen, mar kiprobaltam, izgi. Ugytunik azt (PIO) csak assembly-ben lehet matatni es kell hozza egy bootstrap szeru akarmi c-ben.
Egyelore ott tartok, hogy tudok mar pin-t billegtetni, abbban hozza is a ~63MHz-es sebesseget (~16ns), mikozben a foprogram akar csinalhatna mast is
Meg csak fel szemmel neztem ra megszakitasra, az sem tunik nagyon elvetemultnek.

Viszont megjott a kedvem megirni ezt STM32-re is, assembly-ben. Ahogy mar irtatok feljebb csak a ballaszttol kell megszabulni. .. es idot kell talalnom ra.

Ballaszt nélkül is marad majd valamennyi késleltetés. A PIO valószínűleg gyorsabb.