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.

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...

É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.

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.

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:


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!

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.

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...

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.

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.

É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.

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.



Hogyan kel beilleszteni ezeket a lib-eket a keilbe?

Köszi előre is!

Bocsi Urak!

Közben megtaláltam a Keil-es .lib változatokat, amik már fordulnak.
Bővebben: Link

Most GUI probléma van. ST fórum:

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

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ó?

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 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á.

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)

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.

Ö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)

Milyen fejlesztő környezetet érdemes hozzá használni? Van saját nyelve mint az arduinonak?
Esetleg C -ben?

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ú.

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?

Idézet:
„Van saját nyelve mint az arduinonak?”

Az Arduinonak sincs sajt nyelve. C/C++ az is, sok saját könyvtárral.

Igen, igazad van, csak connectivity lineban van host. Köszönöm a korrekciót

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?

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.

É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.

É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.

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.).