Fórum témák
» Több friss téma |
C-ben én is keveset és kényszerűségből programoztam, c++ pedig semmit, így az arra vonatkozó definíció működését nem ismerem.
A __gpio_H-t jól gondolod, és ezt a saját .h fájljaidban is használd, hogy az azokban lévő definíciók is csak egyszer forduljanak le. A extern arra való, hogy azok a modulok is tudjanak egy-egy közösen használt változóról, vagy függvényről, amit nem bennük definiáltál, de használniuk kell. Próbáltam egy picit szemléletesebbé tenni. disp5x7_stm.h:
disp5x7_stm.c:
A hozzászólás módosítva: Aug 11, 2018
A .h fájlokat kiegészítettem a gpio-h mintájára, de valami nem jó. A következő fájljaim vannak a main-en (és a többi gyárin) kívül: myVariables.h, myFunctions.h és myFunctions.c.
A myVariables.h és myFunctions.h meghívom a main.c-ben. A myFunctions.h-ban meghívom a myVariables.h-t, a myFunctions.c-ben pedig a myVariables.h-t és myFunctions.h-t is. Eleinte működött, amíg csak define volt a myVariables.h-ban. Aztán tettem bele egy változó deklarálást (double batteryVoltage=12; ) amit a myFunctions.c-ben használtam volna. Illetve ezt az értéket később felülírnám majd, de erre még nem került sor. Ekkor a fordítás végén panaszkodik, hogy batteryVoltage-t többször definiáltam. Erre mi lenne a megoldás, vagyis hol rontottam el? Mellékeltem a source és include mappákat, a benne lévő fájlokkal talán jobban érthető amit leírtam. A szemléltetést köszönöm, így már érthetőbb, de használni nem tudnám még magamtól.
A myFunctions.h-ba belevetted (nem meghívtad) a myVariables.h-t ezért a main.c-be csak az előbbi kell.
Kivettem a main-ből a myVariables.h-t, de ugyan azt írja:
Idézet: „... Src\myFunctions.o: (.data.batteryVoltage+0x0): multiple definition of `batteryVoltage' Src\main.o: (.data.batteryVoltage+0x0): first defined here collect2.exe: error: ld returned 1 exit status”
A batteryVoltage-t nem deklaráltad hanem definiáltad. H-ban deklarálunk .c-ben definiálunk.
Köszi! A myVariables-h-ból kivettem az értékadást (double batteryVoltage; ). Létrehoztam egy myVariables.c-t amibe belevettem a .h-t, és ebbe tettem az értékadást (double batteryVoltage=12.0; ) Nem tudom erre gondolták-e, de így működik.
Nem néztem bele a programodba, a leírás alapján egy header is elég lenne, változók és függvények deklarációja együtt. A batteryVoltage definíció pedig a myFunctions.c-be,ahol használod.
Bocs, hogy a programodat nem bogozom ki, de vagy egy éve nem programoztam egy sort sem. Én a helyedben valami egészen pici programot csinálnék csak ahhoz, hogy rájöjjek hogyan működik több .h és .c fájl együtt. Lehetne egy main.c, kozos.c, egy.c, ketto.c és hozzájuk .h-k. Fájlonként 1-2 függvényt készítenék, és azok hívogatnák egymást oda vissza. Ha minden egyes függvény csak annyit csinál, hogy kap egy int-et, változtat rajta és ezt adja vissza, az már kísérletezni elég.
Sziasztok!
Valaki tudna eben segíteni Bővebben: Link van egy hiba a programjában sleep módban nincs szabályzás vagyis a sleep menü nem veszi figyelembe a beállított értéket! Sajnos az arm nem értek nem is érdekel csak ezt az egy projektet szeretném megcsinálni belőle! Hiba a videón jól látszik! Bővebben: Link Köszönöm!
Szerintem hex fájlt nem lehet csak úgy szerkeszteni. Ha át is írod a szövegeket, szerintem nem fog működni a hex felprogramozás után. Vissza kellene fejtened ASM-be, és ott átírni amit akarsz, majd lefordítani. Még ekkor sem 100% a siker, de nagyban növelheted az esélyt, ha minden szöveget ugyanolyan hosszúra fordítasz le, akár szóközzel kibővítve.
Csak a kitöltési hosszra kell ügyelni szerintem!
Vagy tudsz valami crc jelegű firmware ellenőrzésről stm32 nél?
Nekem van mindkétféléből. Amit leírok, az az enyémekre vonatkozik, sosem lehet tudni, hogy neked majd milyet küldenek.
Mindegyikre lehet szoftverfrissítést tölteni. Az első egy viszonylag korrekt klónja az eredetinek. STM32F103 MCU, kivezetések rendben, detektálja a cél MCU feszültségszintjét, stb. A második nagyon olcsó, de STM32F100 MCU van benne, amiben az adatlap szerint nincsen USB... (Gyakorlatilag az ST csak F103-at gyárt, és amelyikben a teszten megbukik az USB, az F100 lesz, ezt használják ki a kínaiak.) A tapasztalat pedig az, hogy időnként szó nélkül elszáll az USB kapcsolat, és soha többé nem jön vissza. Kb 10-ből háromnál, a többi pedig vígan működik bármeddig. Szóval nem érdemes ötnél kevesebbet venni. Nincs rajta kivezetve a ARM target reset, se a SWO, nincs feszültség detektálás, nincs védelem, stb. Mindig van itthon legalább 10, aztán dobom ki őket, ahogy hullanak.  Az ára miatt érdemes tartani, kb minden fejlesztésemen fixen lóg egy ilyen, hogy ne kelljen dugdosni.Vehetsz még eredetit, 6000 ft, nem hatalmas összeg https://hu.farnell.com/stmicroelectronics/st-link-v2/icd-programmer...892523 Vagy veszel egy ilyet https://www.aliexpress.com/store/product/STM32F103C8T6-ARM-STM32-Mi...8.html Raksz mellé 4 ellenállást, 2 LEDet, és van egy korrekt ST-Linked. Komplett építési leírás és bootloader is megtalálható a neten.
De, szerkeszthető. Rendszeresen szerkesztem is. A titok az, hogy nem az ASCII, hanem a mellette lévő hexa számokat tudod szerkeszteni.
Ahogy már többen írták, ezzel a módszerrel csak ASCII karaktereket tudsz bevinni, vagyis NINCSENEK magyar ékezetek, valamint minden szöveg hosszának meg kell egyezni az eredeti szöveg hosszával.
Ha ilyen szutykok akkor inkább csinálok egy megbízhatót!
Ez pontosítanád? --------------------------------------- Vagy veszel egy ilyet https://www.aliexpress.com/store/product/STM32F103C8T6-ARM-STM32-Mi...8.html Raksz mellé 4 ellenállást, 2 LEDet, és van egy korrekt ST-Linked. Komplett építési leírás és bootloader is megtalálható a neten. ----------------------------------------- kapcsolás/firmware érdekelne! Blackmagic néven fut egy ilyen programozó az az lehet? Idézet: „Ha ilyen szutykok akkor inkább csinálok egy megbízhatót!” Nem szutykok. Ahogy írtam: Az olcsóbbik esetén fel kell készülni, hogy néhány százalékuk nem éli túl az első 10 használatot, de ami bírja, az általában megmarad. A drágább tökéletesen működik. Idézet: „Ez pontosítanád?” A kapcsolási rajz ismert, nézd meg bármelyik Nucleo / Discovery board debugger részét. A firmware feltöltéséhez szükség van egy bootloaderre. Keresgélj a neten, meg fogod találni. Mondjuk a feltöltéséhez szükséged lesz egy másik ST-Linkre. Ha megvan a bootloader, akkor már USB-n keresztül megy a firmware frissítés.Idézet: „Blackmagic néven fut egy ilyen programozó az az lehet?” Az más. Open source debugger firmware, ami sokféle mikrokontrolleren képes futni. Például STM32F103-on is, így az ST-Link STM féle firmwareét le lehet rá cserélni.
Ezt találtam van 2 fajta stm32 vel is szerelt!
Bővebben: Link Akkor a botloadert nem lehet uart egyáltalán feltölteni mert most csak azzal cserélgetem a szoftvereket ?!
De lehet. A mikrokontroller típusától függően lehet őket USART-on, CAN buszon, I2C-n, USB-n keresztül programozni a beépített bootloaderrel (minden STM32-ben van gyárilag bootloader, a boot láb(ak) segítségével lehet engedélyezni). Keress rá a neten hogyan.
De itt a bootloader beégetés van szó azt uart lehet e cserélni?
A firmware feltöltés az megy uarton nincs gondom vele!
Mégis mi a különbség? A gyári bootloader-t természetesen nem lehet lecserélni. A saját bootloader pedig egyfajta firmware (vagy legalábbis a firmware-d része), ezért épp úgy írható rá a mikrokontrollerre akárcsak a tényleges programod (gyári bootloader-en vagy pl. a fent linkelt programozókon keresztül). Igazság szerint, ha csak nincs rá különösebb indok, felesleges saját bootloader-rel bajlódni, a gyári tökéletesen megfelel (indok lehet pl. speciális diagnosztikai funkciók megvalósítása, a nyákra ültetett egyéb hardver elemek felprogramozása, pl. SPI flash IC-k, EEPROM-ok, kriptográfiai IC-k, stb.)
Idézet: „ha csak nincs rá különösebb indok, felesleges saját bootloader-rel bajlódni” Ilyen eset például ha titkosítani szeretnéd a firmware-t, hogy ne lopják el... De fentebb az ST-Link klónozásáról volt szó. Az ST titkosítását feltörték, az ST-Link bootloadere elérhető a neten. Ha azt feltöltöd egy STM32F103-ra,majd USB-n csatlakoztatod a számítógéphez, akkor az ST-Link firmware frissítő ST-Linknek fogja felismerni, és feltölti rá a titkosított firmware-t. A bootloader pedig dekriptálja, és beírja a flashbe.
Igy érthető!
köszi! Még annyit kérdeznék melyik a legjobb debbug szoftveres környezet?
Ezt nem tudom ezért kérdezem eddig csak arduinoztam ott ide alá könyvtárakat bootloaderes megoldás kezelgeti az ezekből megírt firmwaret!
Vagyis az ARM új nekem!  Idézet: „melyik a legjobb debbug szoftveres környezet?” Amelyiket a legjobban tudod használni azok közül, amiket meg tudsz fizetni. Én fogtam a listákat (ARM IDE) a wikipédiáról és hasonló oldalakról, és végig próbáltam kb húszfélét. Volt köztük fizetős próbaváltozata és ingyenes is. Aztán döntöttem. Szerintem ezt senki sem tudja megúszni. Függ attól, hogy milyen operációs rendszer van a gépeden, milyen MCU-t akarsz használni, mennyi pénzt, időt szánsz rá, stb.
Windows STM32F103 használnék és jó lenne mi zajlik benne hiba szűrésre!
Ha az ingyeneseknél maradunk, akkor windows esetén tudom ajánlani az EmBitz-et és az Atollic TrueSTUDIO-t. Mindkettővel remekül lehet debug-olni (soronként léptetés, regiszterek értékei, változók aktuális értékei, stb.), támogatják a fent említett programozókat is (többek között). Én J-Link-et használok debug-ra (eredeti verziót, a kínai másolat messze nem teljes értékű), ez ugyan sokkal drágább (az EDU verzió azért megfizethető, a mini EDU pedig még inkább, ST-Linkből ha jól tudom lehet ilyen mini EDU-t csinálni, de én még nem próbáltam) viszont sokkal gyorsabban lehet vele felprogramozni az IC-ket (amikor a program meghaladja a 100k-t kezd ez az idő számítani), illetve jó-pár további debug funkciót támogat, amit az ST-Link nem.
Első körben azért inkább ST-Link-et vegyél, ha elkezded érezni a korlátait, akkor ráérsz ránézni a J-Link-re. A hozzászólás módosítva: Szept 4, 2018
Köszi Ránézek ezekre a progikra!
Ezt próbálta már valaki Bővebben: Link?
Ez nem MCU-hoz, hanem SOC-hoz van.
De ha már kérdezel, és válaszolnak is, akkor nézd meg az EmBitz-et, és a TrueStudio-t. Ezek jók. Az is kérdés, hogy milyen szinten szeretnéd programozni az MCU-t? Regiszterek és CMSIS? SPL? (Ez régi, nem ajánlom.) HAL? LL? Ezek újabbak, de több bennük a felesleg. Én a munkám során HAL-t használok, mert számít a hordozhatóság, és a rövid fejlesztési idő. Ehhez van egy CubeMX nevű inicializációs kódot generáló eszköz, nagy segítség. Csak ott megyünk regiszter szintre, ahol probléma van a HALlal. Inkább nagyobb (RAM, órajel, flash) MCU-t választunk, hogy bőven elférjünk benne. A fejlesztés jóval költségesebb, mint az MCU ára. És ez igaz a hobbira is. Hacsak nem a bitpiszkálás valaki hobbija. Ezt nem bántásból írom, különbözőek vagyunk. Nekem mind munkában, mind a saját projektben az az első, hogy működjön az applikáció, az mellékes, hogy 500 vagy 1500 ft az MCU. De minden tiszteletem azé, aki ugyanazt kihozza egy 150 forintos cuccból.
Én csak örülök ha ilyeneket írsz természetesen hatékony programozás érdekelne!
|
Bejelentkezés
Hirdetés |
