Arra én is igényt tartanék....jól jönne egy beszédes magyarnyelvű anyag

Sajnos ez nem az a téma, aminél egy könyvben összefoglalják az egész csínját-bínját. Főleg nem magyarul. Én legalábbis még nem láttam ezt a könyvet.
Így maradnak a tutorial-ok, reference manual-ok, application note-ok, példaprogramok, és az ehhez hasonló fórumok.

Keil uVision
"Industrial standard".
Feltelepíted és megy. Nincs barkácsolás, működik minden, nincs meglepetés. Vele az ARM-al foglalkozol, nem pedig az IDE-Toolchain kalapálásával.

Ilyet nem egészen találtam, de a Keil az nem fizetős...?

32KB-ig a Lite verzió ingyenes.

Az azért elég karcsú, vagy sok minden belefér? Pl. egy webszerver?

Nem, az gyakorlatilag semmire nem elég. Ok, ismerkedésre gyakorlásra igen, de munkára (főleg komolyabb CPU esetében) nem.

A Keil uVision azért nem került eddig szóba, mert már a kérdéskor ki lett zárva a "korlátos" IDE, no meg a "hosszútávra való tervezés" is azt jelentheti, hogy egyszer elfogy az a 32kB.
Keil-lel kezdtem, stabil, jó kis IDE. Azt gondoltam mint Bill Gates, hogy xy kB elég mindenre.
Csakhogy ha mondjuk include-olsz egy math libraryt, akkor kb. 10kB-tal megdobja a kód méretét (ez mondjuk GCC esetén -O0 optimalizálással, de Keil sem lehet sokkal jobb). Grafikus LCD esetén beraksz mondjuk pár karakterkészletet, és hip-hop beszól a Keil, hogy túllépted a korlátot. Egy webszerver helyfoglalásáról sajnos lövésem sincs.

Hát ezek alapján a 32kB semmire sem elég. Egyelőre maradok a CooCox-nál.

Bocs az információs kérdésemért.Látom,hogy az ST-k népszerűek ezen a téren.Az NXP-t pl. miért nem preferálják ennyire? Nem drágábbak és van egy 256k-ig free LPCXpresso IDE hozzá.

Hát én már grafikus menürendszert is csináltam lcd-re 32kB-ból. Másik, hogy mindenre megvan a megoldás, így a méretkorlátra is.

Amikor én néhány évvel ezelőtt elkezdtem hobbi szinten ARM mikrokontrollerrel foglalkozni, akkor körülnéztem, hogy melyik gyártónak vannak a legkönnyebben beszerezhető cuccai, amik nem csak a kontrollereket jelentik, hanem a programozót és a fejlesztő paneleket is. Én nem látok azóta sem ilyen olcsón ilyen választékot más gyártó esetében fejlesztő kitekből. Biztosan ugyanolyan jók az NXP kontrollerek is, de itthon van már egy marék STM32 IC-m és egy doboznyi fejlesztő panelem. Amíg ezekkel meg tudom oldani az adott feladatot, addig pénztárca- és energia-takarékosségból nem váltok.
Amíg pedig vannak ingyenes, jó és több kontrollermárkát is támogató IDE-k, addig nem akarnám magam korlátozni egy gyártóspecifikus IDE-vel (hátha egyszer mégis váltani kell )

Én pl NXP-t használok.
Jobb modulokat találtam hozzá: LPC4088, Cortex-M4

Igaz, ha az STM32-vel gyártanának ilyen all-in-one board-ot, akkor tuti csere lenne. De egyébként nem gáz a különbség, bár ezekhez az NXP modulokhoz opció a 32bit-es SDRAM, ez mindenképpen előnyük.

Sziasztok!

STM32F4Discovery panelen próbálnám beüzemelni az UART-ot az alábbi kóddal:



Működik is szépen, csak éppen a baudrate nem jó. Oszcilloszkóppal mérve 9600 helyett 50000 bps az átviteli sebesség. Ha arányosan kisebb számot írok be (1843), akkor megkapom a kívánt 9600-as baudot, és tudok szépen beszélgetni a Bluetooth modulommal, de ez így akkor sincs rendben. Valószínűleg nem órajelprobléma, mert több időzítő és PWM modult is használok, azok helyes sebességgel mennek. Van esetleg valakinek ötlete?

Annyi ötletem van, hogy meg kéne nézni mi kerül a USART1->BRR regiszterbe. Abból már kiderül hogy mennyivel oszt le, és abból pedig, hogy mennyi az órajeled. Ezzel már el lehet indulni hibát keresni.

Először VZoole mérését célszerű elvégezned, másodsorban pedig több mint valószínű, hogy amit kizártál, az lesz a probléma.
USART1 és USART6 PCLK2 forrásról jár, a többiek PCLK1-ről. Ezeket a köztes periféria órajeleket is ellenőrizd, hogy konfiguráltad, ott lesz a kutya elásva. Az, hogy a PWM megy, nem bizonyíték semmire.

Köszönöm a javaslatokat mindkettőtöknek!

Az órajeleket kiírattam:
SYSCLK=168MHz
PCLK1=42MHz
PCLK2=84MHz

Ha a BaudRate-hez 9600-at írok, akkor BRR=1667. Ebből a baud 84MHz/(1667)=50.4kHz, vagyis tényleg kijön az, amit mértem. Vajon a HAL miért állítja be hibásan a BRR-t?

Utánaszámolva úgy tűnik, hogy a HAL 84 helyett 16 MHz-nek veszi a PCLK2 órajelet. Ami azért furcsa, mert belenéztem a forrásokba, és úgy látom, az UART inicializálásakor pontosan azzal a függvénnyel kéri le az órajelet (HAL_RCC_GetPCLK2Freq), mint amit én az előbb a kiíráshoz használtam, tehát elvileg jó eredményt kell kapnia.

Megoldódott a probléma. Új projektet generáltam Eclipse-ben, és - fogalmam sincs mitől, de - most jó.

Hát az eclipse fog még meglepetéseket okozni , nekem nem volt valami pozitív az élményem vele.

Valószínűleg igazad van, nekem sem először volt hasonló esetem az Eclipse-szel. De sajnos a többi ingyenes fejlesztőkörnyezetnek is vannak ilyen nyűgjei, fizetőset vagy kódméret limiteset pedig nem szeretnék.

Meg lehetne próbálni a NetBeans-t. Én annó odáig eljutottam vele, hogy (Linux alatt), a GCC-ARM-GNU-NONE-EABI-val szépen együtt működött és fordított. Utána St-Link OpenOCD-vel hajtva és elvileg rendben is van.
Ezeknek a göncöknek számomra a legnagyobb hátránya hogy nagyon hiányzik/hiányos a regiszterek megjelenítése. Eclipse alá van egy kiegészítés ehhez, de szerintem NetBeans sokkal kezesebb, egyszerűbb. Nem védeni akarom mert Microchop szerintem egy szakadékba zuhan éppen, de a NetBeans az Eclipse helyett szerintem egy nagyon jó döntés volt.
Csak hogy lebeszéljelek az Eclipse alapokról.

Köszönöm a javaslatot! Per pillanat némileg rá vagyok kényszerülve az Eclipse-re (nem egyedül fejlesztek), de mindenképp meg fogom nézni ezt a NetBeanst, eddig nem ismertem.

Válaszolok a saját, régi kérdésemre, hátha valakinek segítek vele a későbbiekben. A processzor NUC240 (Cortex M0), és így kell kiolvasni a veremből, hogy hol történt a WDT timeout. Nyilván előtte engedélyezni kell a WDT megszakítást.

Sziasztok!

Szeretnék PC és MCU között kapcsolatot teremteni, és adatokat átvinni PC-re, vezérlő utasításokat pedig az MCU-ba. Mondjuk szeretnék csinálni egy saját EPROM égetőt. A kérdésem az lenne, hogy mi a célravezetőbb szakmai szemmel:
a) VCP kapcsolat létrehozása, majd pedig a PC oldalon egy kisebb SW írása, ami vezérli az MCU-t, írja/olvassa az adatokat VCP-n keresztül, vagy
b) VCP kapcsolat és FatFs használata, azaz az MCU rákapcsolódik a fájlrendszerre, és azzal operál, a PC-től csak a vezélést kapja VCP-n. Itt lenne is egy kérdés pluszban: lehetséges párhuzamosan használni a két csatornát ("class"-t)? Tehát az megoldható, hogy pl. terminalon adom ki a vezérlő utasításokat, és közben az MCU írja/olvassa a HDD-t?

Az a) esetben milyen programnyelvet érdemes választani, amivel könnyen hozzáférni a soros porthoz (GUI annyira nem lényeg most)? Pl. C/C++/C#/Java ?

Végiggondolva a b) verzió úgy nem is működik valószínűleg, ahogy gondoltam. Tehát eleve NTFS fájlrendszer van a PC-nél, másrészt, ahogy nézem, ez a FatFs API igazából mindenféle flash drive kezelésére van, ahol az MCU a host, nem pedig PC HDD kommunikációra.
Erősítsetek meg, úgy tűnik, marad a PC oldali szoftver készítés. A feladat ugye az lenne egyébként, hogy le kéne menteni a binary fájlt az adott EPROM-ról, hogy működjön offline is az égetés, ne csak azonnali (párhuzamos) másolással.

Mi lenne, ha az egészből kihagynád a PC-t?
Lenne egy flash-ed, amibe elég sok eeprom képét lementhetnéd, és akármikor visszatölthetnéd.

PC esetén az a) változat a nyerő. Szerintem pc programot sem kell írnod, egy terminal program megteszi.

Ha USB vezérlővel ellátott mikrovezérlőről van szó, akkor c) változatként az USB HID device módot javaslom. Ehhez is írni kell egy alkalmazást a PC oldalon, akárcsak az a) esetben, de a HID kapcsolat robusztusabb, mint virtuális soros port.

A b) változatban nem kell hostnak lennie az MCU-nak, hanem a saját memóriájában (vagy az MCU-hoz kötött SD kártyán) kezelt fájlrendszert teszi elérhetővé a PC számára.

Kompozit eszköz is megvalósítható (pl. USB flash drive mód és VCP mód párhuzamosan).

Linux-on, Mac OS X-en pl. tökmindegy, mert a sorosvonal egy sima file, mondjuk /dev/ttyUSB0. Megnyitod és irod/olvasod. Persze a baudrate és egyéb beállításokhoz kellenek ioctl hívások, de C-ből nincs benne semmi különleges.

Windows esetén C/C++, C#, Java vagy Processing egyaránt használható hozzá - amelyik neked szimpatikusabb...