Fórum témák
» Több friss téma |
Ha bele gondolok a mindenkori sebességet a (sec/lépés * 1lépés előtolás mm) számból tudod meg?
Ebből számolsz futás időt, és ezt próbálod vezérelni? Elégé nyakatekert megoldásnak tartom! És a lépéskimaradásra így sincsen semmi garancia.
En arra gondoltam hogy van HW-es visszajelzes, pl. enkoder.
Ja!
Az sajnos elég drága, bár nagyon hasznos jószág! Viszont akkor megkel oldani a figyelését megszakításban. Itt már tudnál mérni időt is, a 2 lépés között. Ebből észrevennéd és korrigálhatnád az esetleges szorulást is És a pontos lépés szám ismeretében, végkép szükségtelen lesz a futás idővezérlés. Inkább a lépések közti idő számítására kellene koncentrálni. A hozzászólás módosítva: Jún 6, 2015
Semmiképp nem szeretnék kukacoskodni, de az elmúlt pár hozzászólás nem konkrétan ARM, szépen belesimulna a CNC-s topikba (trafó VA-ek, 12V-ok, stb). Nem égeti a topikot az OFF még, de figyeljetek oda rá légyszíves.
Köszönöm (T) Szerk: Kapu48 észrevétele is jogos a két téma kéz a kézben járnak, maradjon is így  A hozzászólás módosítva: Jún 6, 2015
Idézet: „Szerintem, majd ahogy szaporodnak a feladatok, és kezd kifulladni a proceszor idő, rájön, hogy spórolni kel az erőforrásosokkal!” Annyira nem akarok már sokat írni a firmware-hoz hogy annyira spórolni kelljen Még max egy körinterpolátort fog kapni egy vészleállító nagy piros gombbal és egy kézi kereket a manuális mozgatáshoz.Ez egy egyszerű vezérlés, semmi motor túlhajtással, gyilkolással, max sebességre törekedésre. Egy egyszerű CNC vezérlés amely soros porton fogad egy sort, olvassa, feldolgozza és megteszi az utat. A cél műanyag (előlapok) , nyák max alu marás, gravírozás volt, meg persze a kihívás mind hardver mind szoftver terén.
Egy nagyon hasznos Tutorial, amit ajánlok figyelmedbe!
STM_f401_f429_disco. Serial Communication, DMA, UART, USB COM Port Bővebben: Link
Jó ez a kör_interpolátor!
Csak 1..2 gomb hiányzik róla! 1.: G kódgenerálás 2.: Save G kód 
Nem lehetne ezt kiszedni az ISR-ből? Mi a processzorod pontosan? 168MHz az valami 407, 417 lehet ugye? A 427/429 tud alapbóll 180-at, de 207-et hajottam már 158MHz-el, 417-et meg 240-el szóval lehet el kellene gondolkodni vagy egy overclock-on, vagy kódoptimalizáláson (mindig van jobb megoldás) vagy pedig procicserén.
Keil-ben nyomod? Nézted az optimalizációs beállításokat?
Ügye most viccelsz?
Wbt írta: Én igaz, hogy 16MHz/AVR-re és csak 2D-t csináltam, de 5000step/sec-el tudtam menni! Ehhez képest 1 ARM407-es rakéta. (Minek túlhajtani? Kockáztatja a biztos működést!) Csak hát nem megszakításban kellene számolni a vektorokat, mert addig minden más várakozik. És jobban ki kellene használni a HW adta lehetőségeket. Most vagy túl sok feladatot adtunk Suncorgonak, vagy elvettük a kedvét a közléstől? Igaz minden kezdet nehéz! Lesz ez még jobb is! (Az előző hszt. Wbt-nek szántam volna!) A hozzászólás módosítva: Jún 8, 2015
Én fordítva állok a dologhoz:
- minek a lassú proci ha ugyan abban a tokban van kompatibilis rakéta is? - egy fölöslegesen gyors proci a nem legjobb programot is jó eredménnyel futtatja, tehát ad sikerélményt. - ez nem akkumulátoros konstrukció, MHz kontra üzemidő nem játszik - a te eredményeid szintetikusan jók, de kérdés hogy bárki másnál hogy alakulnak egyéb feladatok, esetleg egy nagyon elrontott bármilyen egyéb ISR mellett. - az ISR-nek örök érvényű szabálya hogy gyorsan be gyorsan ki. Én azt csinálnám hogy az ISR rutin eldöntő paramétereit még ISR előtt számoltatnám, az ISR-ben meg már csak switch-case. De mindenkinek szíve joga úgy csinálni ahogy gondolja. Asztalra kell egy univerzális "erőmű", aztán ha ott jól működik mehet a down-scale. 
+ a Cortex-M4 ugye DSP-vel kiegészített cucc, tehát lehet megérné a DSP utasításokban, library-ben túrni egy kicsit, biztos van erre valami célszerű C okosság.
Kiszedni az ISR-ből? Miért? STM32F407VGT6 Ez nekem bőven elég egyenlőre. Még mondhatnám hogy a sebesség (lépési) képességei többek is a vártnál. Nézem a youtube vidiket és az enyém is megy olyan gyorsan mint az ottaniak, minek a túlhajtás? Én is a biztos működés pártján állok, a túlhúzás soha nem vezet semmi jóra. Gondolom debuggoltál már switch-et sorról sorra. Ennek nem jártam mélyen utána de, én azt látom hogy az összes case-en végiglépked a program, mint ha if feltételt vizsgálna, innentől szerintem mindegy hogy if else vagy case. Igen Keil, ezt sikerült "szerezni". Az optimalizációs beállításokat lefotóztam egy pár hsz-el visszább. Ezzel nem megbántani akartalak, szeretem az építő jellegű hozzászólásokat.
 Idézet: „Most vagy túl sok feladatot adtunk Suncorgonak, vagy elvettük a kedvét a közléstől?” Egyszer ha sok-sok időm lesz, lehet írok egy cikket ennek a gépnek az építéséről, programjáról ide a hobbira. Semmitől sem vetted el a kedvem, hobbi szinten, én akinek egy villamosgép tekercselői szakmája van + érettségi, az internetről minden infója. Ennyire futotta. Nem érzem magam zavarban mert önszorgalomból vagyok képes minderre éjjel-nappal az internetet bújva, olvasva és tanulni. Meg persze néha néha tőletek a fórumról segítséget kérve és remélve nem is a megoldást, csak útbaigazítást. Szóval mire is vagy kíváncsi? A komplett forrás a link alatt. (hardver-pc szoftver, PCB tervek Altium designer 15) ha valami elvetemült hobbista elkezdi utánépíteni az elektronikát szóljon, elérhetővé teszem a frissebb szoftver is mert még nincs kész A hozzászólás módosítva: Jún 8, 2015
Miért nevezted el „ISR”-nek? : void linearis_interpolator_ISR()
 Mikor ez nem megszakítás, csak egy sima programból hívható függvény! Így nagyon megtévesztő!
Mert azokat a függvényeket csak megszakításból hívom meg.
Lehet egy kicsit kiszekuszának tűnik az egy c fájlban való egész program de, nekem így könnyebb volt keresni és navigálni benne írás közben.
A hozzászólás módosítva: Jún 9, 2015
Megszakításban rossz szokás külső rutinokat hívni!
Mert csak nyújtod a hosszát a ki/be ugrálással. (Törekedj a minél rövidebb ORQ rutinokra!) Tegyed be őket a TIM2_IRQHandler-be. (Itt most nem az olvashatóság a fő szempont! ) És én ezt átszervezném:
A hozzászólás módosítva: Jún 9, 2015
Idézet: Egyetertek veled, egy ISR legyen a leheto legrovidebb. Mindazonaltal, ha egy fuggveny static (ahogy a fenti esetben nem...) es csak egyetlen helyrol hivod meg, akkor a gcc magatol beleintegralja a hivo fuggvenybe, nem lesz ugralas. Gondolom, a keil-nek is van ennyi esze. Allitolag meg tobb is, mint a gcc-nek. „Megszakításban rossz szokás külső rutinokat hívni! Mert csak nyújtod a hosszát a ki/be ugrálással.”
Egyenlőre meg akarom írni teljesen a uc és pc oldalt. Még uc oldalon körinterpolátor, pc oldalon az OpenGL marópálya kirajzolás van hátra. Aztán jöhet az optimalizálás, sebességnövelés.
Tetszik a programozó stílusod!
Jó könnyen olvasható, és értelmezhető elnevezéseket használsz!  Még az Keil uV5-öst is felraktam a programod kedvéért. Már nagyon közel jársz az uV5 Lite határához! Aztán kezdhetsz gondolkozni az Optimalizáláson. 
Érdekelne, hogy perzisztens adat tárolást EEPROM hiányában mivel csinátok:
- BKP regiszterek + elem a VBat-on - Külső soros EEPROM (8 lábú I2C) - vagy a Flash memória utolsó lapjait felülírjátok Csaba
En sepeciel kulso i2c EEPROM, vagy ha nagyon arerzekeny a dolog, akkor a belso FLASH. De nemelyik NXP LPC chip-ben van belso EEPROM is.
Én mellérakok egy SPI eeprom-ot. Már olyan olcsó (60Ft), hogy nem éri meg vacakolni vele.
Általában úgy is van valami egyéb SPI perifériám, mellette elfér. Sőt, néha még egy soros flash-t is rátervezek, sose lehet tudni milyen kérés jön elő.
Én most pont azzal játszadozom, hogy egy kontroller Flash-ébe mentsek el pár byte-ot. Egy grafikus LCD touchscreen-jének a kalibrációs adatait szeretném menteni, és hát a panelre nem terveztem anno EEPROM-ot, gondolván, hogy a Flash is jó ilyen célra. Azonban a netről vadászott példákat nem sikerült még működésre bírnom.
Ha valakinek van STM32-höz ilyen kódja, azt megköszönném.
SD kártya SDIO módban.
Mit ertesz az alatt, hogy SDIO modban? (Tudtommal az SDIO az egy olyan valami, amit SD kartya foglalatba lehet dugni, de pont nem SD kartya, hanem valami egyeb eszkoz.)
Elírtam, bocsánat, siettem. SD mód a helyes.
Itt biztos ellesheted, hogyan kel a Flasht írni?:
Open source flash program for STM32 using the ST serial bootloader Bővebben: Link
Kicsit félreraktam eddig a témát, azért nem válaszoltam korábban.
Úgy tűnik, hogy most már működik az adat mentés a belső Flash-be dolog. Hátha más is ilyenen agyal, és neki segítség lehet, ha leírom röviden, hogy mikkel küzdöttem. Rájöttem, hogy nem magával a Flash írásával volt gondom, az a példák alapján működött. Csakhogy a neten talált kódok arra voltak kialakítva, hogy magát a futtatandó programot írják be a mikrokontrollerbe, és hát ezek nem működtek megfelelően, ha csak adatot akartam elmenteni a Flash-be. Miért is? A flash írás úgy történik, hogy minden írás előtt töröljük az adott szektort. Első próbálkozásomnál szépen ki is fagyott az egész programom, mert kitörölte az első szektort úgy megszakítás-vektorostól, mindenestől.  Meg kellene tehát mondani, hogy fizikailag milyen címre tegye az elmentendő adatot. Nos, ez utóbbi nem olyan egyszerű GCC-ben. Nem is tudtam megoldani anélkül, hogy a linker file-hoz ne nyúljak hozzá: Deklaráltam egy const tömböt a programomban, amit elhelyeztem egy olyan szektorban (ehhez kellett a linker-file-t szerkeszteni), ahol más még nem volt. Ennyi. Keil-ben egyszerűbb megoldani, hogy egy konstans értéket egy megadott címre helyezzen, ott nem kell a linker file-hoz hozzányúlni, GCC-ben ez nem működik. Legalábbis nálam nem működött. Idézet: Es ez miert baj? A linker script ugyanolyan resze a munkanak, mint a C forrasok vagy a Makefile. Egyebkent, ha csak arrol van szo, hogy egy strukturat akarsz egy valamilyen cimen tudni (legyen 0x80000000), ahhoz nem feltetlenul kell a linker script-et modositani:„Nos, ez utóbbi nem olyan egyszerű GCC-ben. Nem is tudtam megoldani anélkül, hogy a linker file-hoz ne nyúljak hozzá:”
|
Bejelentkezés
Hirdetés |
