Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   145 / 177
(#) kapu48 válasza csatti2 hozzászólására (») Okt 9, 2019 / 1
 
Viszont az APB2-esen van a PORTB, azt letudom venni 36MHz-re, ha minden kötél szakad.
Elég is lenne nekem az a sebesség minden porton.
(#) icserny válasza kapu48 hozzászólására (») Okt 10, 2019 /
 
Megint félreértést sejtek, mert neked nem a periféria buszt kell lassítani, hanem a CPU-t (a program futását, az adatok kirakását). Rakjál be NOP-okat, vagy szervezd úgy a programot, hogy amíg várni kell, addig vegye elő a következő adatot, vagy ilyesmi...
(#) kapu48 válasza icserny hozzászólására (») Okt 10, 2019 /
 
Én ezt úgy képzeltem, hogyha lassabban dolgozik a periféria busz?
Akkor a gyorsabb CPU-nak ki kel várnia a kiszolgálását.

Viszont ez is csak egy kipróbálható ötlet volt. Ami nem is tetszett olyan nagyon, mert így az ADCk órajele is le esik 12MHz-ről 9MHz-re.

A NOP-os variációt már az előző oldalon megoldottuk.
A hozzászólás módosítva: Okt 10, 2019
(#) benjami válasza kapu48 hozzászólására (») Okt 10, 2019 / 1
 
Próbáld ki, hogy a mellékelt a projectel is hibázik-e a kijelző. A lábakat és az írási és az olvasási sebességeket is az Src/Lcd/lcd_io_gpio8.h fájlban tudod beállítani. A sebességekhez nagyobb számot írva fog lassulni az LCD vezérlés sebessége.
(#) kapu48 válasza benjami hozzászólására (») Okt 10, 2019 /
 
Köszönöm a segítséget!
Ezekből a definíciókból már látom, hogy hova kel tenni a várakozásokat:
  1. #define LCD_DUMMY_READ        { GPIOX_ODR(LCD_RD) = 0; LCD_RD_DELAY; GPIOX_ODR(LCD_RD) = 1; }
  2. #define LCD_DATA8_WRITE(dt)   { lcd_data8 = dt; LCD_WRITE(lcd_data8); GPIOX_ODR(LCD_WR) = 0; LCD_WR_DELAY; GPIOX_ODR(LCD_WR) = 1; }
  3. #define LCD_DATA8_READ(dt)    { GPIOX_ODR(LCD_RD) = 0; LCD_RD_DELAY; LCD_READ(dt); GPIOX_ODR(LCD_RD) = 1; }
  4. #define LCD_CMD8_WRITE(cmd)   { LCD_RS_CMD; LCD_DATA8_WRITE(cmd); LCD_RS_DATA; }


Ezzel nem voltam tisztában.
Majdnem egyezik a lábkiosztás is az enyémmel, csak a vezérlő lábak vannak máshol.
Feltétlenül ki próbálom!
(#) rolandgw hozzászólása Okt 16, 2019 /
 
Elnézést az off-ért, de nem valószínű, hogy erre a kérdésre linux-os fórumon választ kapnék.
Telepítettem a tegnap megjelent új Cube IDE-t és Programmer-t Ubuntura, sajnos a helyzet változatlan.
Az IDE függőségi hibát okoz, a frissítéskezelőt le is ülteti, hibajelentés küldés.
A Programmer-nél pedig írják : "STM32CubeProgrammer does not work under Ubuntu® 18.04. "
Vajon melyik linux disztribúcióra fejleszthetnek? Merthogy nem az Ubuntura az biztos.
(#) icserny válasza rolandgw hozzászólására (») Okt 16, 2019 /
 
AZ egyik fórumon azt is írják, hogy "Java 11 and 12 are not yet supported, can you please use openjdk8 or orcle java8".

Kérdésedre a válasz: valószínűleg régebbi Linux disztribúciókra fejlesztették...
(#) vargham válasza rolandgw hozzászólására (») Okt 16, 2019 /
 
Az elmúlt 6 év tapasztalata: Beágyazott fejlesztőeszközök főleg Windowsra érhetők el. Utána jön a Linux és a MacOS.
(#) rolandgw válasza icserny hozzászólására (») Okt 16, 2019 /
 
Ez már a 16.04-nél is probléma volt. Downgrade kellett a java-ra és ki kellett zárni a frissítésből. A Programmer-hez jfx is kell. A programban van egy szkript, ami induláskor ránéz a jfx-re, de a jdk könyvtárában keresi. Ha nem ott van hibát ír. Márpedig az újabb open java-nál nem ott van. A 16.04 viszont az új IDE-t telepítés után törött csomagként kezeli a synaptic szerint.
(#) rolandgw válasza vargham hozzászólására (») Okt 16, 2019 /
 
Én a win10-től kiütést kapok , ha ingyen adnák, akkor is meggondolnám.
Közben az IDE-t sikerült megoldanom 18.04-en, a programozó is menni fog előbb-utóbb.
(#) kapu48 hozzászólása Okt 17, 2019 /
 
Szevasztok Urak!

Már megint a tudatlanság csapdájába estem!
Tudna valaki segíteni? Az alábbi hibajelzés kiküszöbölésében.

Idézet:
„*** Using Compiler 'V5.06 update 3 (build 300)', folder: 'C:\Keil_v5\ARM\ARMCC\Bin'
Rebuild target 'MIDI02'
assembling startup_stm32f407xx.s...
compiling cs43l22.c...
compiling lis3dsh.c...
compiling lis302dl.c...
compiling stm32f4_discovery.c...
compiling stm32f4_discovery_accelerometer.c...
compiling stm32f4_discovery_audio.c...
assembling libPDMFilter_CM4_GCC.a...
..\Drivers\BSP\libPDMFilter_CM4_GCC.a(1): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4_GCC.a(2): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4_GCC.a(3): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4_GCC.a(4): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4_GCC.a(5): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4_GCC.a(6): warning: A1313W: Missing END directive at end of file
assembling libPDMFilter_CM4F_GCC.a...
..\Drivers\BSP\libPDMFilter_CM4F_GCC.a(1): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4F_GCC.a(2): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4F_GCC.a(3): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4F_GCC.a(4): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4F_GCC.a(5): error: A1167E: Invalid line start
..\Drivers\BSP\libPDMFilter_CM4F_GCC.a(6): warning: A1313W: Missing END directive at end of file


Hogyan kel beilleszteni ezeket a lib-eket a keilbe?

Köszi előre is!
(#) kapu48 válasza kapu48 hozzászólására (») Okt 17, 2019 /
 
Bocsi Urak!

Közben megtaláltam a Keil-es .lib változatokat, amik már fordulnak.
Bővebben: Link
(#) rolandgw válasza rolandgw hozzászólására (») Okt 17, 2019 /
 
Most GUI probléma van. ST fórum:
Idézet:
„I confirm there is issue with Gui under linux (you can check known problems and limitations in release note for STM32cubeProgrammer).
Devlopement team is already working to fix this issue . I will send you a patch fixing it as soon as it is ready.
Meanwhile you can use CubeProgrammer CLI .”
(#) rolandgw válasza rolandgw hozzászólására (») Okt 24, 2019 /
 
Linkelem a megoldást, lehet, hogy mást is érint. A probléma eredete az Oracle licensz változtatása, például a 8-as java már nem tölthető le szabadon. Az IDE is az AdoptOpenJDK-t telepíti. Egy régi openjfx-et kell feltenni, ami a jdk könyvtárba települ, és ki kell zárni a frissítésből.
Bővebben: Link
(#) HiMen hozzászólása Okt 30, 2019 /
 
Sziasztok!
Volna egy nagyon fontos kérdésem, úgy értem nem szórakozásból hanem egy komoly fejlesztés okán kellene megtudom:

Megoldható-e STM32F103C8T6 ARM STM32 Minimum System Development Board Module -al, hogy az egyik kontroller megkap egy lefordított .hex állományt mondjuk soros adatátvitellel. Majd másik két lábával a programot feltölti egy másik kontrollerre az USB csatlakozóján keresztül. Azaz a megkapott programmal egy másik kontrollert felprogramoz, mintha a PC volna.

Szerintetek megoldható?
(#) Topi válasza HiMen hozzászólására (») Okt 30, 2019 /
 
USB host és device is tud lenni (F103-on is), tehát csak a protokoll a kérdés. Elvi akadálya nincs, hogy az egyik STM USB-n kommunikáljon a másikkal, viszont a kérdés az, hogy amelyik eszközt programoznád, az jelentkezne be DFU bootloaderen keresztül USB-n?

Tehát ha jól értem, akkor
Soros -> STM32 -> Host USB -> Device USB -> STM32 DFU amit szeretnél? Mert akkor cél oldalra olyan típust kell választanod, aminek a ROM-jában van DFU, illetve vagy HW-es bootselect vagy szoftveres program counter ugrasztással a főprogramból kell ROM-ra tenni a futtatását, hogy a cél procin fusson a DFU bootloader.

Szerk: DFU protocol
A hozzászólás módosítva: Okt 30, 2019
(#) HiMen válasza Topi hozzászólására (») Okt 30, 2019 /
 
A mikrovezérlő már adott, azon nem tudok módosítani.
Lerajzoltam.
Tehát az 1. kontrolleren fut egy program. Ez fogad a PC től sima soros kommunikációval egy kész .hex adatot. Majd ezt másik két lábon, a 2. kontroller USB -jén keresztül felprogramozza a 2. -nak. Tehát "elhiteti" hogy Ő egy PC és programot tölt fel rá.

STM32.png
    
(#) Topi válasza HiMen hozzászólására (») Okt 30, 2019 / 1
 
Jelen formában nem fog menni. USB-hez nem csak láb, hanem háttérhardver is szükséges, illetve azt megszólítani képes USB stack. Hagyományos TX-RX nem elegendő hozzá, az USB enumerációt cél oldalnak végig kell vinnie, illetve a Host oldalnak (1. kontroller), fogadni kell az enumerációkor eszköztől (device oldal, 2. kontroller) kapott endpoint description-öket.

A rajzodból nekem láncolt felprogramozási igény látszik, ezt a legegyszerűbben saját bootloaderrel lehet megoldani, és akkor maradhat a hagyományos sima RX-TX soros kommunikáció.
Ha nem bootloader, akkor a főprogramot kell felokosítani futás közben saját Flash-ének írására.

Én legtöbbször ezeket együttesen használom. Bootloader CRC ellenőrzést végez, de protokollal nem rendelkezik, és a kontrolleren a főprogramból van kettő. Egy ami éppen fut, és egy ami az update terület. Futás közben tudsz akkor szoftvert frissíteni, és bármikor már az újat futtatni reboot után.
Ekkor a flash-ed így fog kinézni mondjuk:
[Bootloader 8K | Fő program 32K | Update terület 32K | Egyéb vackok, config stb... ]

Ha nem nagyon akarsz komolyabb programozást választani, akkor még mindig maradhatsz sorosporton keresztüli programozásnál, viszont akkor a beépített soros ROM bootloadert kell használnod.
STM32 beépített soros bootloader
Ez esetben az USB csak maximum az első eszközön használt, utána sorosporti a frissítés.
Előnye, hogy egyedül annyi főprogram módosítással jár, hogy MSP és PC regisztereket kell átállítanod, hogy a ROM-ból fusson, és a feltöltő vezérlő (1. kontroller) pedig akár USART bridge-ként átjátszhatja az adatot, még implementálni sem kell rajta a fentebb linkelt protokollt, csak továbbadja amit kapott a következőnek (kaszkád)
(#) HiMen válasza Topi hozzászólására (») Okt 30, 2019 /
 
Zseniális vagy!
Rengeteg fontos információt mondtál. Bár ilyet még nem csináltam, úgyhogy rögös út áll előttem, de legalább látom merre induljak! Köszi!

Igen, a végcél az, hogy az elsőnek átadott program egymás után végigmenjen nagyon sok kontrollerre. Tényleg nagyon sokra... Az eszköz mindegy hogyan. Azért gondoltam az USB csatlakozójára, mert azt hittem programot csak onnan tud fogadni a kontroller. Nem is gondoltam, hogy soros porton is lehet felprogramozni. Ez remek!

Ha találok rá mintaprogramot akkor az is sokat segíthet.
(#) Topi válasza HiMen hozzászólására (») Okt 30, 2019 /
 
Örülök ha segítettem. Amit még célszerű tanulmányoznod, ha máshoz nem, prototípus tesztekhez:

STM32 Flash loader demonstrator (ez a kliens progi, ami a soros ROM bootloaderrel beszélget, Bővebben: Link)
(#) HiMen válasza Topi hozzászólására (») Okt 30, 2019 /
 
Milyen fejlesztő környezetet érdemes hozzá használni? Van saját nyelve mint az arduinonak?
Esetleg C -ben?
(#) benjami válasza Topi hozzászólására (») Okt 30, 2019 /
 
Az F103-as csak USB device tud lenni. Az F1-es sorozatból az F105 és az F107 tud csak USB OTG-t (USB host). Azok között viszont nincs 48 lábú, csak 64 illetve 100 lábú.
(#) HiMen válasza benjami hozzászólására (») Okt 31, 2019 /
 
Végülis nem probléma. Ahogy Topi elmondta, megoldható soros porton keresztül fogadva is a felprogramozás (vagy saját bootloaderrel vagy akár a beépítettel), ha jól értettem.

Jól látom, hogy Keil-ben programozzátok C nyelven?
(#) vargham válasza HiMen hozzászólására (») Okt 31, 2019 /
 
Idézet:
„Van saját nyelve mint az arduinonak?”

Az Arduinonak sincs sajt nyelve. C/C++ az is, sok saját könyvtárral.
(#) Topi válasza benjami hozzászólására (») Okt 31, 2019 /
 
Igen, igazad van, csak connectivity lineban van host. Köszönöm a korrekciót
(#) cross51 hozzászólása Okt 31, 2019 /
 
Sziasztok!

STM32F4-en az USART-on RX TX engedélyezve van (TE, RE) error interrupt-ok engedélyezve vannak (PEIE, EIE) viszont az RX TX interrupt-ok vannak tiltva (RXNE, TXE) viszont, ha én így adatot küldök az USART-ra nem kapok interrupt-ot viszont ha megállítom a debuggert akkor az SR reg ORE flag '1' -van nem igazán értem, hogy miért nem generál interrupt-ot.
(persze a cél jelenleg az, hogy a nem normál működést teszteljem, ezért van RX/TX it letiltva)

Valakinek van sejtése mi lehet a probléma?
(#) rolandgw válasza cross51 hozzászólására (») Okt 31, 2019 /
 
Mivel az RX megszakítást tiltottad, csak akkor generál megszakítást, ha a PE is 1. A G0-nál így működik.
(#) benjami válasza HiMen hozzászólására (») Okt 31, 2019 / 1
 
Én speciel a CubeMX - Truestudio párost használom. Mindkettő ingyenesen letölthető az st oldaláról (egy e-mail címmel kell regisztrálni a letöltési lehetőséghez). A korlátja annyi, hogy csak az stm32 mikrovezérlőkhöz használható. Nincs kód méret korlát és az amúgy is ingyenesen elérhető arm gcc fordító van beleintegrálva. Az optimalizálási lehetőségek is használhatóak. Itt egy video ezeknek a használatáról.
(#) HiMen válasza vargham hozzászólására (») Okt 31, 2019 /
 
Én azért saját nyelvnek hívom. A vezérlési szerkezeteken kívül olyannyira különbözik a C -től... Egészen más hardver amihez egészen más függvények vannak.
(#) csatti2 válasza HiMen hozzászólására (») Nov 1, 2019 / 1
 
Attól még nem az. Az Arduino egy keretrendszer. Egyébként pedig nem C nyelvű, hanem C++, így nem csoda ha különbözik tőle. Hardverről pedig megint csak nincs értelme beszélni, mivel a keretrendszert implementálták kismillió különböző mikrokontroller támogatására, amelyek még architektúrában sem egyeznek meg (pl. AVR, Cortex-M ARM-ok Atmel és ST perifériákkal, Tensilica RISC, stb.).
Következő: »»   145 / 177
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem