Köszönöm mindenkinek a hozzászólást és ötletelést!
A PC-t azért nem akarom teljesen kihagyni, mert a vezérlést azzal szeretném megoldani, parancsok segítségével.
A terminal programon pl. Putty-ot értesz? Itt hogy tudom létrehozni/elmenteni a bin fájlt?

Tehát ha jól gondolom ezek a lehetőségeim vannak:
a) VCP + alkalmazás (COM porton megy vezérlés meg az adat)
b) HID + alkalmazás (ez ismeretlen terület számomra, de felkeltette az érdeklődésem)
c) VCP-vel vezérlés, és az MCU memóriájában (RAM/flash?) létrehozott fájlrendszert csatolni a Win-hez (CDC és FatFs/flash drive kompozit módban)

Mivel vezérleni sima terminalon keresztül tudom már, ezért lehet, hogy első körben a c-vel próbálkoznék, mivel itt csak a fájlrendszer rész hiányzik, de nem akarok lemondani az alkalmazásról sem, mivel hosszú távon univerzálisabban tudom felhasználni, de az EPROM égető esetében nem létszükséglet.

A kérdésem, hogy foglalkozott már valaki ilyen fájlrendszer létrehozással? Van hozzá esetleg jó példa? (STM32) Egyébként van egy STM32VLDiscovery kit-em, és ha azt rádugom PC-re, akkor felcsatol egy meghajtót, amin van 1-2 link. Feltételezem ebben az esetben nem a demo MCU-ban van ez, hanem az integrált ST link MCU-jában?

Nem szeretnék kötekedni, de mit és mennyit foglalkoztál már ilyennel?
USB az nem kispálya. Feltéve ha nem a MikroE cuccával csinálod, de azzal dolgozni kis túlzással olyan dolgozni hogy gőzöd se lesz mit miért csinál a C fordító és az ARM, annyira "bedolgozottak" a gyári rutinok. El is vannak rejtve benne rendesen. Az arra jó hogy kész legyen jó legyen, de okosabb nem leszel tőle. De legalább "működget".

A terminál progi bármi lehet ami teljesíti a feltételeket. Pl a Putty is.

A file rendszer egy külön dolog. Az első hogy kell valami amiben tárolod az ARM oldalán. Ez mondjuk lehet az SD kártya. Nekem három hónapom ment rá órajel szintről, hogy tudjak blokkokat olvasni SD kártyáról. Az írással azóta sem foglalkoztam idő hiányában (pedig de jó volna). Ezek mellett File-rendszer teljesen fölösleges, ráadásul szintén nem egy bit-polling dolog. Vannak előre meggyártott rutinok, kérdés hogy működnek, mennyire üzembiztosak, és a legfontosabb hogy megbízol e benne.
Tehát: Egy HEX editorral felteszed a bináris file-t az SD kártyára, 512 blokkonként beolvasod az ARM-ba az meg ráküldi az EPROM-ra.
Ezek mellett fölösleges bonyolítás az USB és a PUTTY, mert kell rá egy HD44780 meg 5 gomb és kész.
Sosem foglalkoztam a Demo panelek demo programjaival. CMSIS egy elbonyolított valami kopasz szkripteseknek, mint minden program a demo is bizalom kérdése. Vagy elhiszed hogy jó, vagy nem. S a legrosszabb ha nem jó: hetekig vakarózhatsz hogy hol keresd el a hibát keresni.

Annyit foglalkoztam vele, hogy működik az USB kapcsolat, ennyi egyelőre elég.

Azt nem értem, a Putty-ból hogy jön a ki a binary-t, amit később vissza is töltök? Egy sima text fájlba loggolom a karaktereket...?

Nem akarok SD kártyázni, mert az égető egy eszköz egy másik projekhez, de nem akartam gyárit venni, inkább csinálok egyet, ami később tovább fejleszthető. Nem akarok jelenleg SD-t, mert az plusz macera, elég lenne, ha az MCU belső memóriáját fel tudnám csatolni.

Na frankó. Akkor csak lesz belőle valami.

Putty és hasonló progikból úgy jön ki a bináris adatfolyam, hogy bármilyen file-t- lényegtelen hogy mi - kitol magából a soros porton keresztül. A hyperterminal-ban ha jól emlékszem van egy olyan menüpont hogy send file.

MCU belső memóriája? Felcsatolni? Mint file-rendszert? Vagy SRAM, SDRAM inicializáció a gond?
STM32F207-hez van SRAM init-em (csúcsra járatva), STM32F429-hez, LPC1788,4088-hoz SDRAM init. Ennyit tudok segíteni.
Az USB-d érdekelne ha nem gond. Hogy csiáltad? Keil, vagy bármi GNU-ARM-Toolchain?
Bare-metal programming, vagy CMSIS, esetleg MikroE?

Tehát akkor gyakorlatilag így text file-ban tudnám tárolni a binary-t? Mert ugye a VCP-n karaktereket tudok ide-oda küldeni, a "klasszikus" binary-t nem tudom létrehozni (ellenben pl. ha van fájlkezelés, akkor már más a helyzet).

A lényeg az egésznek, hogy minél egyszerűbben szeretném megoldani az F4 discovery kit-et használva. Ezen nincs ugye semmilyen külső memória, csak MCU, és ami abban van. Ha jól értettem azonban, az MCU-ban is létre lehet hozni fájlrendszert, amit fel tudok csatolni USB-n a Win-re. Nekem ennyi elég lenne, mert akkor a binary fájl oda készülne, és onnan lenne beolvasva. Ha jól tudom, az MCU-n belül SRAM van (ami "A RAM"), az SDRAM pedig különálló (lenne)? Én lehetőleg az MCU RAM-jából szeretnék egy pl 100kB-os szeletet kihasítani, gyakorlatilag RAMDISK-nek.
Az STM32F207 SRAM inti mit takar?

Alapvetően Eclipse-ben fejlesztek, HAL könytárat használok (amiben benne van a CMSIS is természetesen). Az ST-nek rengeteg példaprogramja van, ezekből szemezgettem, kigyaktam a sallangot, és létrejött egy csupasz driver, amihez csak egy frontend kell, ami viszont már alkalmazás-specifikus. Nyilván nem akkora szellemi munka, mint nulláról megírni, de ez nem is volt célom. A működése megérthető, a kifejlesztése meg hónapokat venne igénybe, ráadásul feleslegesen, ha egyszer van elérhető használható.

Te mivel dolgozol?

Nézd... A szöveg file az egy (pl) byte-os adatfolyam fizikai megjelenése, amennyiben a byte-okat ASCII kódnak fogod fel. A d65 nevű szám neked csak egy szám. De ASCII-ben meg az "A" betű. Ne ragadj le a szöveg file-nál. A szöveg file azért szöveg, mert valahogy meg kell jeleníteni. Egy file hex editorban megnyitva (megjelenéstől függően) egy hosszú byte-os szervezésű adathalmaz. De ha az első két byte BM akkor az egy BMP file és egy programmal megjelenítve lehet egy tájkép pl.

Igen, bárhol tudsz létrehozni file-rendszert de nem biztos hogy van értelme. Simán meg lehet csinálni, hogy a PUTTY-on áttolt adathalmaz az STM belső memóriájában X-től Y-ig terjedő területen elhelyezve "csak úgy elvan". Aztán majd indirekt címzéssel megfogva szépen tolhatod az EPROM-ba. Egyszerűen fölösleges a file rendszer ehhez. Akkor inkább csinálj az STM-be egy terminál programot, ami a kapcsolatot tartja veled kb mint a debug port.

Én Keil-t használom. Hol STM32F429-et, hol NXP LPC4088-at használok.
Nem használok könyvtárakat, semmit. Bare-metal programming, mindent én írok.

Én lusta vagyok más dolgait bogarászni és fölösleges rétegeket tanulni. Ott a regiszter, aztán bele kell írni amit szeretnél. De az USB-nél lehet hogy rá fogok fanyalodni a gyári dolgokra.
Mit tudtál csinálni az USB-vel, hogy kezdtél neki, mit használtál stb?

Egyébként most kezdtem el tanulmányozni az LPCExpresso fejlesztő környezetet (Eclipse) ingyenes az NXP cucca, és a hozzá való LPCOpen Driver-eket. Szerintem jól dokumentált, és egyszerűbbnek tűnik mint a CMSIS.

Oké, igyekszem túllépni rajta!


Itt most VCP-re gondolsz?

Hát, tényleg elismerésem, de én azt látom, hogy ha valami bonyolultabbat akarok, akkor az rengeteg plusz idő (lenne) így, és az érdemi résztől venné el. Én azt tapasztalom, hogy eléggé használható az ST könyvtára, még ha vannak is benne bug-ok, ezeket azonban nem annyira nehéz kiszúrni (legalábbis eddig úgy tűnt). Meg aztán nyilván megnézem, mi van a kód mélyén, tehát nem vakon használom, és hát ha magam írnám teljesen, akkor low level szinten kb. ugyanazt kellene begépelnem, amik a függvényekben vannak, tehát valójában sokat nem nyernék...

Amit jelenleg tudok az USB-vel az az, hogy CDC osztályt regisztrálom, és létrehozom a VCP-t, amit el is érek terminal-on, ezáltal tudok az MCU-val kommunikálni. E mellé gondoltam az MSD osztályt, de a tanácsaidat megfogadva először megpróbálom akkor a jelenlegi környezetben megvalósítani a fájl ki-bevitelt, aztán meglátjuk.

Amit javaslok, hogy nézz bele az ST USB host/device leírásokba (UM1720/UM1734), amiből megérthető az USB driver működése. Konkrét példákat pedig találsz STM32F429 discovery KIT-hez kapcsolódóan az oldalukon, amiből ki lehet indulni elég jó. Konkrétan asszem USB - UART converter van megvalósítva benne. Én igazából ezen két forrás alapján dolgoztam, de ha van kérdésed, állok rendelkezésedre!

Igen a VCP-re. DE: Én arra gondolok, hogy a PC-t s a terminál programot csak kijelzőnek-billentyűzetnek használod. PC-re nem is kell programot írnod.
Minden adatot az ARM küld, ő küldi ki az összes TAB, CR, LF vezérlő karaktereket, mindent.

Köszönöm a segítségedet. Egyesek az USB-HID-et ajánlják, mert semmi driver nem kell hozzá WIN oldalon. Nem értek hozzá, nem foglalkoztam vele.
Én a PC kapcsolatot Bluetooth-UART-al szoktam kihagyni.

Sajnos Putty-al nem látom, hogyan tudnék fájlt küldeni/generálni. Igazából látnom kéne, hogy is működik ez egyéb esetben, mert úgy érzem, nem áll össze teljesen... Nem tudsz egy jó példát mutatni? A kommunikáció az rendben van oda-vissza, már csupán az a kérdés, hogy tudok bineket be meg letölteni. Ha más nem, marad a PC oldali alkalmazás, már csak amiatt is, mert a jövőben mindenképp szeretnék ilyen irányba elmenni.

Igen, és emiatt a HID-el is meg fogok próbálkozni, de annak a legnagyobb korlátja viszont hogy max 64Kbytes/s-ot tud, ami cserébe garantált. Ez persze jelen alkalmazásban elég lenne, de a jövőben más felhasználás esetén szűkössé válhat...

A driver-rel nincs gond, azt adja az ST. Szerintem ezen felül nem is igényel törődést, hiszen így COM portként látja a rendszer.

Sziasztok,

Nagyon sokáig nem foglalkoztam ezzel a hobbimmal (programozott elektronikák) különböző okok miatt, most szeretnék kicsit visszazökkenni bele, ehhez segítségeteket kérem.
Még valamikor régebben beszereztem magamnak egy STM32F103VET6-tal szerelt fejlesztőkártyát (van rajta valami touch-os LCD is), valamint van itthon egy TI Stellaris Launchpad is LM4F120H5QR proccal szerelve. Tulajdonképpen gyári, hozzájuk adott példákat tudok fordítani rájuk, és le is tudom tölteni a flashbe, a Stellarist még debugolni is sikerült. Ám én szeretnék egy kicsit "tudományosabban" hozzákezdeni az ismerkedéshez Linuxot használok, feltettem egy Eclipse-et, és az gcc-arm-none-eabi cuccokat (bare metal toolchain). Valahol Kína és Magarország között még úton vannak apróságok (JLink, további STM32-es pici boardok, és hasonlók) is, de jelenleg azok nélkül is elvagyok.
Az a gondolatom támadt, hogy ha már ARM, és elvileg mind "ugyanazt tudja" (persze, azért ez így nem igaz teljesen, de mégis), akkor talán jó lenne úgy indulni a fejlesztéssel, hogy a kód pár apróság átállításával (proc típus, IO lábak) egy másik vasra is lefordítható legyen. Nekem úgy tűnik, hogy a CMSIS pont ilyesmire lenne való, de eléggé meggyűlik vele a bajom.
Elég sokat túrtam a netet, de valahogy egyértelmű válaszokat nem találtam sok apró kérdésre. Ma délben vagy 2 órát nyomkodtam az Eclipse-t, hogy egy üres main()-t tartalmazó program leforduljon a CMSIS-szel a Stellarisra, viszont valahogy mintha nem jó startup kódot csinálna. Volt olyan, hogy a map file tanúsága szerint mindent kidobált, mint nem használt session-t, és a végén a kód mérete nulla lett. Szóval elég aggasztó, hogy egy ilyen egyszerű problémán sem tudok túllendülni.
Örülnék neki, ha valaki tudna adni útmutatást, hogy merre, hogyan induljak, hogy nagyjából a cél felé haladjak

Köszönök minden tippet!

Nem pont a helyes válasz amit írok, de méltatlanul elhanyagolt procik az NXP cuccai.
Nagyon jók, a gyári fejlesztőkörnyezete az LPC-Expresso. Jobb mint a CMSIS szerintem, és Linux alatt is plug & play az IDE. A CMSIS helyett a saját LPCOpen nevű könyvtárát használja. És meg kell mondjam nem rossz. J-LINK-el csodálatosan működik. Ettől függetlenül én (is) a bare-metal-t preferálom.
A többféle procis dolgodat viszont nem egészen értem.
Ha STM akkor 32Fxx-től 7xx-ig ami létezik minden alkalmazást le tudsz fedni, ugyan ez igaz az NXP-nél az 11xx-től 407xx, 8xx,-re (most direkt csak é kizárólag M0-M4-ig írtam a dolgot.

Van aki STM-re esküszik (többség), van aki a Stellaris-ra (kisebbség), és másról nagyon nem is tudok aki NXP LPC-t nyomat csak én.

Szóval én inkább azt ajánlom hogy ess neki egy gyártónak, nem lesz hátrányodra.

Néztem én is "Kínában" az NXP-s starter boardokat, de az STM32-eseknél érezhetően drágábbak, ettől függetlenül lehet, hogy beszerzek olyat is. A portabilitást meg úgy gondolom, hogy pont azért, mert az ARM kód mindegyik gyártmányon ugyanúgy fut, elég lenne csak kicsit a "helyi viszonyokhoz" igazítani a gyártófüggőségeket, és akkor a forráskód maradhatna ugyanaz. Mondjuk belakok STM32-esekhez egy fejlesztői környezetet, és egyszer ha éppen úgy adódik, hogy nem egy STM32-vel valósítanék meg valamilyen ötletet, akkor se kelljen átszokni a másik gyártó saját szája íze szerinti perifériakezelésre például. Azt gondoltam volna, hogy a CMSIS pont ezt hivatott megvalósítani, de egyelőre csak még jobban összekuszálódtam benne.

Szerintem annyit nem ér a CMSIS (és bugos), és mellette ugyan úgy vágni kell a perifériákat gyártónként. Nagyobb fegyvertény az, hogy egy gyártó mekkora felületet fed le, mint hogy a CMSIS kisegít(het) a bajból.

Az a helyzet, hogy sokan a hardver árát nézik. 10$ ide-oda nem számít. Ellenben az hogy mennyi idő megy el arra hogy hozzászoksz (kiszenvedsz) egy másik gyártóhoz, na az az igazi "pénz".

Én ezt használom. NXP LPC 4088 Board

Amit lehet erre feltettek, a TFT-t is direktbe csatolhatod, és 32bites (is) lehet az SDRAM adatbusza. STM32-nél nem láttam ilyen széles busszal szerelt board-ot. A Discovery is csak 16-os.

Sziasztok!

Valaki foglalkozott itt Cortex M3-as Atmel mikrovezérlőkkel? Szeretnék egy ILYEN demopanelt venni és elkezdeni beletekinteni a programozásába. PIC és AVR mikrovezérlőkkel is foglalkoztam csak a C nyelvet nem ismerem olyan jól. Esetleg valaki tudna nekem segíteni hogy mire érdemes ügyelni, vagy milyen cortex mikrovezérlővel volna érdemes elkezdeni foglalkozni?

Ha már ezt választottad?
Ajánlott kihasználni a rajta levő botloadert.
És ezt az útmutatást követni: ARDUINO PRODUCTS > Arduino Due
Bővebben: Link

A rendszer telepítése során.
És ha igazán ki akarod használni az eszköz adta lehetőségeket?
Ajánlott fejleszteni a C, Cpp ismereteidet!

Igen a C ismereteimet szeretném bővíteni mert eddig csak assemblyben programoztam. Ezzel a boatloaderrel lehet az avr stúdióból tudom egyenest programozni a mikrovezérlőt vagy mindenképpen az arduino softverét kell használnom a felprogramozáshoz?

Úgy látom nincs debug lehetőség rajta, ami nem előnyös.
Inkább valami itthon is jobban elterjedtet javasolnék (gyári- ST, NXP, TI).
Pl.: ST F4 Nucleo

Ez soros portot emulál az USB-n, csak az arduino használja tudtommal.

Simán be illeszted a sketch könyvtárba az *.cpp, *.h álományaidat.
És C, IDE szabályok szerint használhatod, lefordithatod.

Külső szerkesztőt alkalmazhatsz, és szerkeszthetsz akár AVRStudio környezetben is.
Csak arduinos fordítás előtt elkel menteni a méshol szerkesztet álományaidat.

Debugolni lehet a arduinoba beépítet terminálon keresztül.

AVRStudiohoz be kell szerezned valamijen ISP programozót. Akor már ugrott a botloader.

Meg lehet csinálni, hogy AVRStudio-val a bootloaderen keresztül töltsd fel a programot. Az avrdude.exe-vel és néhány paraméterrel megoldható. Igaz, nem a szokásos feltöltés gombbal kell a programfeltöltést elindítani, hanem ugyanabban a menüben lesz egy plusz menüpont.

Azért szeretnék kimondottan az atmel felé menni, mert akkor nem kell több programot telepítenem a kisebb mikrovezérlők és az arm-ek számára valamint ha kell programozót vennem akkor az jó lesz az arm-hez és a 8 vagy 32 bites mikrovezérlőkhöz is, és általában azokban már van debugger is. Mondjuk a debuggert nem nagyon szoktam kihasználni piceknél sem. Inkább a programot szétosztom részekre és minden részt külön tesztelek. És ha már az egyik működik akkor írom tovább.

Na ez a megoldás már jobban tetszik. Már megrendeltem a panelt, remélem két három héten belül megjön. Azután ránézek és ha nem boldogulok vele akkor ismét jelentkezem.
Köszönöm az eddigi segítséget!

De ami proci van a lapon, az nem AVR. Akkor hogyan tudná az AVRstudio kezelni? Én eddig Atmega328-cal használtam, Arduino bootloaderrel.

Ez egy Atmel ARM. Miért ne tudná az Atmel Studio kezelni (az AVRStudio már történelem)? Programozónak/debuggernek meg jó pl. egy Atmel ICE. Az kezeli az AVR és ARM cuccokat is.

Pontosan ez az amiért az atmel szerintem jobb mint a microchip. Itt az összes mikrovezérlőt egy szoftveren keresztül lehet programozni ugyan azzal a programozóval. Az sem utolsó szempont, hogy ingyenes a fordító.

Nagyon tudom ajánlani ezt:
NXP LPC4088

vagy

STM 32F407

Ha kell a TFT vezérlő is az STM-nél akkor:

STM 32F429

Ha pedig csak plug&play kell elsőre akkor STM32F429 Discovery

ezek szerintem bazi drágák elkezdeni az ismerkedést.
Akkor már a discovery...
Egyébként az MBED IDE-nek van létjogosultsága? (Viszi a discovery-t is)

Persze, ismerkedni lehet a Cortex-M0 típusokkal is.
Az NXP-t azért ajánlom, mert az LPC-Expresso egy nagyon nagyon jó IDE.
És az LPCOpen szerintem jobb és direktebb mint az CMSIS.

Ugyanannyira van, mint az Arduino IDE-nek és társainak. Könnyen kipróbálható vele egy elképzelés (proof of concept), komolyabb tanulmányok és erőfeszítések nélkül összekalapálhatunk vele egy projektet, de sok mindent elfed, illetve megköt és trehányságra szoktat.

akkor lehet jó lesz nekem...
...
egyébként emlékeim szerint én is belefutottam a CMSIS pontatlanságába, pont egy
discovery board esetén már a clock és GPIO konfigurálás sem volt problémamentes
emlékszem, mennyire nehezen ment aztán CMSIS nélkül, de csak sikerült...