Én vettem mikroszkópot, rátettem egy 19-es monitorra, de használhatatlan volt, mert másfelé nyúl a kezem, mint ahová nézek. Nem tudtam megszokni. Állandóan eltévedtem. Inkább elajándékoztam.

Meg kell tanulni, mint a tükörből hegesztést!

Arduino tényleg egyszerű is. Angolul meg már bárminek a megtanulásához érdemes tudni. Úgy is mondhatjuk, hogy az olvasás mellett most már az angol nyelv is előfeltétele, hogy tanulni tudj. Ami amúgy nem baj.

Igazad van, én is mérhetetlenül fel vagyok háborodva, hogy már nem kell nyelvvizsga sem a diplomához.
Szerintem már a felvételihez is kellene, legalább emelt szintű érettségi (mérnöki pályán természetesen angol).

A nyelvtanulás az esetemben nem egyszerű. Bár Óvoda után a magyaron kívül oroszul és németül is jól beszéltem, olvastam, de egy gyerekkori agyhártyagyulladás elintézte a rövid távú memóriámat. 7-ben 5-ös voltam oroszból, de 8-ra már csak éppenhogy átcsúsztam. Folyamatosan igyekszem karbantartani, egy élet munkájával, de a szótanulás szinte reménytelen. Van angol kifejezés, amit ismerek, tudom a jelentését, de képtelen vagyok emlékezni rá akkor is, ha 1000x használtam. Úgyhogy igen - elvárható lenne - de esetemben nem megy. Ha menne, már régen külföldre költöztem volna, nem itt kínlódnék.

Amúgy ha az angolt csak a programozáshoz akarod használni akkor nem is kell túl sokat tanulni, de ha a leirásokhoz is , az más tészta. Amúgy nagyot fejlödött a google forditó már jobban fordit mint 5-10 éve (oroszul én is el olvasok bármit de hogy mit jelent ne kérdezd )

En 46 eves voltam amikor nekialltam angolul tanulni. (dokumentaciot tudtam olvasni, de annak nem sok koze van a beszelt angolhoz). Igaz en elesben tanultam

Azért a gépi fordítás mögött is nagyon sok meló van. Például oda kell tenni az adott nyelvre jellemző dolgokat, meg a szakterületre vonatkozó adatbázist is az MI számára.
Persze igazán ezt az emberi fordításra is el lehet/kell mondani.
Jó példa, a múltkor dicsekedtek nálunk, hogy egészen jó próbálkozások vannak a "többnyelvű" dokumentációra. Még a bemutató alatt az egyik Technical Writer kolléga bedobott egy saját dokumentációból szövegdarabot, kiválasztotta a célnyelvként a magyart.
Vicces lett, mert az informatikában teljesen alap stateful-vs-stateless kifejezést szépen lefordította "terhes vagy hajléktalan"-ra.
Egyébként a maga nemében tökéletes a szótár szerinti fordítás, csak itt értelmetlen (csapkodtuk a térdünket a nevetéstől).
Nem ez a szövegkörnyezet volt, és meg is jött a válasz, hogy magyar adatbázissal nincsen rendesen feltöltve, mert a magyar nagyon kicsi és jelentéktelen részhalmaz, az általános adatbázist alkalmazta...

Nem tökéletes de aki nem tud angolul annak nagy segitség

Egyébként kétségtelenül ez a jövő, sok helyen már kinyomtatva is elismerik, például: Ez a leírás gépi fordítással készült.
Akinek nem tetszik, az meg olvassa el eredetiben, vagy szótárazza ki magának.
Például a múlt hétig én sem tudtam hogy a "süpürge" porszívót (is) jelent törökül (bár rájöhettem volna, mert eléggé logikus).

Srácok, STM-re C nyelven írok egy programot és belefutottam egy (számomra) érdekes megoldásba.
Még pedig egy 2 dimenziós tömböt szeretnék pointerként egy függvénynek átadni, majd az pedig feltölti adatokkal. Hogy tudom ezt jól megoldani?

Kérdéses tömb:
Majd ezt szeretném átadni egy függvénynek, mutatom, prototípus:
És maga a rutin:
A rutin lefut, de mikor a tömböt feltöltené, akkor hibára fut az MCU.
Valszeg típus problémája van, vagy a pointer megadása nem jó. Köszi előre is.

Használat lemaradt:

Első ránézésre felesleges a dupla csillag! Te címet adsz át, az eddig egy sima mutató! Hogy függvényen belül ezzel a címmel mit kezdesz, az már magánügy....

Ha egy csillaggal adom meg a következő hiba érkezik:

Alakítsd át hozzá sima egy dimenziós tömbbé. Majd a függvényen belül oda castolod ezt a címet, ahová akarod...vagy csak simán mutatón keresztül használod továbbra is!

Őőőő, pont az lenne a lényeg, hogy többdimenziós tömbként, hogy tudom szépen megoldani a feladatot. Nem akarom a tömböt módosítani, azt csak át akarom adni a függvénynek. Más módokon, pl enum, vagy struct-ként meg tudom oldani, de tömbként érdekesebb a dolog.
Erre nincs valami megoldás?

Ez mennyivel bonyolultabb így?

De ha mindenáron ragaszkodsz a 2 dimenziós ábrázoláshoz, hívhatod pl így is...

Nyilván ez így működik. De kíváncsi voltam a több dimenzió esetében hogy lehet normálisban megoldani a kérdéses feladatot. A szeparáció miatt jobb lenne a többdimenziós, főként mert azért sokkal több adat lenne.

Ez szerintem nem jó megoldás, mert így nem pointerként hivatkozik a tömbre és ebben az esetben nem írja felül a tömb értékeit, ha csak nem globális változóként nem adom meg a tömbömet, akkor meg sokkal egyszerűbb megoldása is lenne rá.

Hát ha globális tömbként a címét adja át, akkor lokálisként miért lenne ez másképp?

Köszi, lehet még is jó lesz ez a megoldás. Megnézem élesben hogy viselkedik..
Köszi.

Így jól működik:

Ami fura, hogy amikor a typedef-nél csak simán a két dimenziós tömböt adtam meg struct nélkül, akkor nem jól működött.

Igen, itt említettem is, hogy enum és struct-tal meg tudom oldani, de valamiért normál tömbként nem akart működni. Végül amit sdrlab javasolt, azzal oldottam meg a dolgot, de a struct megoldás is szép és letisztult lenne. Köszi.

Sziasztok.

F103C8 -nál két uart-ot használok (tesztelgetem őket). Mindkét uart megszakításban fogad adatokak.
A kérdésem az lenne, hogy a két soros vonal tud egyszerre adatokat fogadni?
A CubeIde-be az USART1-nek állítottam priorítást. Az a fontossabb.

Szerintem olyan nincs hogy egyszerre, ha csak nem szándékosan így idéznéd elő két független eszközről küldve a jelet. Mindig van kis eltérés és szerintem elég ahhoz, hogy te úgy érzékeld, hogy egyszerre tudja kezelni az eszköz..

Amíg a soros bufferben van hely, addig egyszerre.
Ha DMA-val használja, akkor is egyszerre, míg van hely a DMA bufferben.
A perifériák önállóan, a CPU-tól függetlenül működnek, ahogy a DMA is.

Sziasztok!

Viszonylagosan kezdő vagyok arm témában. Bevallom a CudeIde és a CubeMx tudott pár meglepetést okozni számomra. Eddig előbb-utóbb megfejettem a működést, de most falba ütköztem, úgy érzem.
Frissítettem a két programot, és most nem tudom lefordítani a projektet.
A kép szerinti fatal error üzenetet adja a rendszer, mert nem talál meg néhány include állományt.

Ha megnézem a fa struktúrában a jelzéseket, akkor a kis piros jelölések mutatják a problémás elemeket.
Az is látszódik, hogy a Drivers/CMSIS tag alá sok olyan dolgot is betett, amelyet én nem is kértem, vagy legalábbis nem volt szándékos.

Egy korábbi fa nézetet is befotóztam, amely mutatja a jelentős különbséget.

Kérdésem a hosszabb bevezető után:
a.) Hogy a manóban lehet kikapcsolni az MX-ben vagy az IDE-ban ezt a sok felesleges kód generálást, amely akár a DSP-haz, RTOS2-höz tartozik? Ezeket én biztosan nem fogom most használni. Szerintem.

b.) Ha nem lehet kikapcsolni, akkor mit kell telepíteni a gépre még, hogy megfelelő include állományok megtalálhatók legyenek?

Köszönöm figyelmet!
Zoli

Most akkor a CubeMX-et, vagy a CubeIDE-t használod? Csak azért, mert a CubeMX arra való, ha nem a CubeIDE-be szeretnél dolgozni, hanem mondjuk a Keil vagy más egyéb fejlesztői környezetben. Ha a CubeIDE-t használod, akkor meg elegendő ő egymagában. Akármelyikről is van szó, a felesleges dolgokat kapcsold ki a Cube részen (pl. a freertos-t).

Ez nem így van.
A CubeMX az projekt (MCU) konfigurátor és kódgenerátor.
A CubeIDE pedig integrált fejlesztőeszköz.
A CubeMX tud CubeIDE projektet generálni, amit ez utóbbival nyitsz meg.
A CubeIDE meg tudja jeleníteni a saját felhasználói felületén a CubeMX-et, de attól az még egy külön szoftver.

Ha nincs benne semmi titkos, akkor töltsd fel valahová az IOC projektet.