Sziasztok !

Sikerult megoldani az optimalizacios problemat: SMT32F4 @ GCC.
Tegnap kapu48 segitsegevel rajottem hogy csak -O0 optimalizacio eseten mukodik a program. Mas optimalizacio eseten hardFaultot dobott. GDB-ben is latszott. A hardFaultot az okozza, hogy (-O0 optimalizacio kivetelevel) a fordito befordit egy VPUSH utasitast a main-be, de ekkor meg nincs inicializalva az FPU.

Az .lst filebol:



Ez -O0 opt. eseten igy nez ki:



A megoldas pedig az hogy a startup_stm32f4xx.S fileba a Reset_Handler cimke alatt inicializaljuk az FPU-t.


A C kodban ekkor mar folosleges inicializalni az FPU-t.
Kiprobalva ( -Os eseten is ) mukodik !
(program = arm_fir_example modositott valtozata - az eredetit nem probaltam ki ujra !)

A kódban tudsz utasításokat adni a fordítónak hogy hol, melyik részt milyen erővel optimalizálja?

Nem tudom. A volatile-t kiveve.

Sziasztok !

STM32F407VG -ARM ot hol tudok venni, ill. hol érdemes?

Válaszokat előre is köszönöm!

FDH

"Szállításra vár "

Ha ilyen formában rendeled, akkor még olcsóbb is, és van is nekik.

Aztán lehőlégfúvózza?

Ha semmiképp nem jó neki azon a panelon...

Hát köszönöm, ez elszomorító. Akkor várok, amíg érkezik. Próbáltam külföldről is, de sajnos a postaköltség túl drága.

Itthol is az a bajom, hogy a pofátlanul magas postaköltségek elviszik az árakat.

Én itt találtam
http://hu.rs-online.com/web/p/mikrovezerlo/7468226/

Tud valaki valamit a texas LM3S procijainak az NRND jelzeserol? Furcsa számomra, hogy az M3-akat a texas levette a termék listáról, ezernyi számra van a beszallitoknal. Nem javasolják új designhoz, de úgy tűnik nem jelöltek meg "utódot".
Az LM4F egyáltalán nem helyettesíti az LM3S szeriat. Ethernet, CAN stb témában nyomába sem ér.

Nem akarom elhinni, hogy a szemétbe dobja a TI az Ethernettel es a CortexM3-al megszerzett részesedését a piacon.

Fura.... A fórumozók reakciói nem hangzanak túl jól.
Bővebben: Link Bővebben: Link

Első reakcióm az vol: f@xom... kicsit kultúráltabban: mélységes szomorúság tölt el ( bár nem a leggyorsabb, de ETH projectekbe a legfelhasználóbarátabb ) kontrollercsalád NRND-be kerül.
Bár a gyártás nem áll le, de nem tudni meddig lesz(elérhető) mert ugye a nagy felhasználók bevásárolnak, hogy kifusson fejlesztéseik.
LM4F-ben várható hasonló tudású kontroller valamikor, de az átállás sem olcsó.
Most én is vakarózhatok, hogy androidos távfelügyelet másik végén LM3S helyett mi legyen.
Remélem lesz még LM3S amíg LM4F "elkészül", addig felvásárlás

TMS570 tervezés alatt (hercules)
Concerto szerintem bonyi...
Valakinek tapasztalat?

Sziasztok!

Úgy látom, itt az ARM világban inkább divat valamilyen OS-t használni, mint saját bare-metal rendszert csinálni, bár én eddig a PIC-eknél ezt tettem és nagyon jól meg voltam a saját állapotdgépeimmel és irtó módon kerültem a végtelen ciklusokat, illetve a főciklust kivéve .

Ezen gondolkodva eszembe jutott, hogy míg a státuszgépes világomban tudtam, hogy mondjuk, ha egy spi eepromba ki kell írnom valamilyen adatot akkor azt tudtam, hogy még ha darabokban írom is ki, de tuti, hogy az állapotgép legalább egy ciklust befejez, mielőtt tovább lép.
Tehát ezután akár jöhetett egy másik "task" ami olvasott az eepromból és nem kellett attól félnem, hogy egy félig befelyezett írásra rájön egy olvasás parancs.

Mondjuk a ChibiOS esetében ugye a task-ok egymástól elzárva futnak és mi van, ha az egyik task-ban ki akarok írni valamit a másikban meg éppen beolvasnék, és mondjuk pont akkor történik a task váltás, amikor kiadtam az írás parancsot, de még nem fejeztem be a műveletet és ekkor ugrik át a másik task-ra ahol meg olvasás folyna?

Vagy az OS-nél el kell felejteni, hogy én alacsony szinten piszkálom a perifériákat és csak annyit kell csinálni, hogy megmondom az OS-nek, hogy ezt írd ki, azt meg olvasd be és a többit elintézi? (mint anno a DOS-nál? nem a HDD-t alacsonyszinten piszkálva kezeltem az adatokat, hanem a rendszer magasszintű függvényeivel fopen, fread stb...)

Vagy hogy kell ezt elképzelni? A ChibiOS-ben pl van HAL layer, de pl a FreeRtos-ban nem láttam.

Nagyon érdekelnének ezek a dolgok, mert enélkül nemnagyon lehet boldogulni, vagy legalábbis nehéz, ha olyat erőltetek a rendszerre amit ő nem akar.

Muszály ebbe is képben lenni, mert úgyis ez a jövő, és nem sokat érek a saját "tákolmánnyal", ha jön valaki egy OS-el és feleannyi idő alatt összekalapál egy projektet mint én, mert neki már a lényegi részek benne vannak az OS-ben, és neki tényleg csak a projekt feladatit ellátó részt kell hozzátenni.

Vagy eleve rossz a gondolatmenetem?

Ha olyan perifériáról beszélünk, amin egyszerre egy dolgot lehet művelni, amit egyszerre csak egy valaki matathat, ill. ahol a regiszterek konzisztenciáját biztosítani kell (ezek elég tipikus követelmények a perifériáknál), akkor az OS-nek valahogyan meg kell oldania, hogy egyszerre csak egy valaki akarja piszkálni azt. Erre számos megoldás létezik OS szinten.
A legegyszerűbb a interrupt tiltás (enyém az egész CPU, amíg matatok).
Aztán van az ún. lock: mielőtt valaki bármit csinálhatna a perifériával, megmarkol egy lockot, és amíg az nála van, addig más ezt nem tudja megtenni, ergó kénytelen megvárni a művelet befejezését. A lock egyfajta szinkronizációs primitív elem, amivel a taskok egymáshoz képest tudnak várakozni. A lock implementációja is többféle lehet, attól függően, hogy mennyire sok várakozó várható, és milyen egyéb követelményeket kell kielégíteni (átlagosan ill. maximum mennyi ideig tartják megfogva a lockot; vannak-e prioritásos jelentkezők, akiket előbbre kell venni; kell-e garantálni, hogy mindenkire belátható időn belül sor kerül, stb).
Bizonyos esetekben, főleg, ha a task szempontjából aszinkron végrehajtást szeretnénk (a task "kiküldi" a melót a perifériának, az meg "majd egyszer" válaszol, közben a task mást is szeretne csinálni), és sok párhuzamos taskunk van, akkor logikus megoldás, hogy a perifériát csak egy task kezelje, ami ciklusban várja a többi tasktól a kiküldendő feladatokat egy queue-n keresztül, a válaszokat meg visszaküldi nekik. A taskok feladata annyi, hogy a queue-ba berakják a feladatot, majd örülnek az eredménynek.

A dologhoz persze hozzátartozik, hogy egy gyengébben eleresztett mikrokontrolleren nagyon nem mindegy, hogy hány taskunk van (hiszen mindegyiknek saját stack, azaz memória kell), nagyon nem mindegy, hogy várakozás nélküli esetben kell-e plusz context switch, vagy sem. Ezek jelentősen meg tudják változtatni a rendszerből kinyerhető teljesítményt.

Bonyolult a kérdés és nincs egyértelmű válasz. Vannak olyan RTOS-nak nevezett rendszerek, amelyekben csak a taszkok szervezését, kezelését, kommunikációjukat, szinkronizálásukat dolgozták ki, a perifériakezelést nem. Vagy írtak bele perifériakezelést is, de csak szokásos dolgokhoz: USB, TCP-IP, filekezelés.

A ChibiOS-t nem ismerem, így nem tudom, hogy a HAL eszközkezelők mit takarnak. Azt biztosan nem tudthatja, hogy mit és hány eszközt kötsz az SPI vagy I2c buszre, de adhat olyan általános célú SPI vagy I2C kezelő függvényeket, amelyekből esetleg összerakhatod a kívánt tranzakciókat. Ez mindenesetre már egy "haladottabb" szintnek tűnik a fentebb írtakhoz képest.

Hát akkor így nem sok értelme van, sok projekt van a neten ami két ledet villogtat, de ezt OS nélkül is meg lehet, tehát olyan példát még nem láttam, amire azt mondtam volna, hogy na ez igen, ezt már nem bare-metalkodnám össze.
Nekem valahogy idegennek tűnnek ezek a taszkos többszálú cuccok, de ha most nem folyik bele az ember később már nehezebb lesz.

Egyébként a ChibiOS-nek itt a HAL által támogatott eszközök:


A másik előnye, hogy létrehoztak egy komplett csomagot, ahol egy eclipse-be beleintegrálták az egészet, és le lehet tölteni, benne a fordító, az os a debugger és működik is, tehát nem kell többet vesződni az IDE építgetésével. Itt van ChibiStudio néven fut.

Hát nem tudom... Én nem szeretem se OS-t, se a CMSIS-t... Szerintem ezek csak bonyolítják a dolgot. Eddig még mindig mindent meg tudtam csinálni nélkülük, így számomra fölöslegesek.
További hátrányuknak tartom, hogy elvonják a figyelmet a hardvertől. Aztán ha nem működik elsőre - márpedig szinte sose - akkor lehet vakarózni, hogy hát akkor most melyik végén is kezdjek neki? OS, és CMSIS csak egy Layer, ami bonyolít, és lassít.

Meg van a CMSIS-nek és az operációs rendszernek is a maga helye. Neked lehet, hogy csak bonyolítja az életedet, ez természetes, hiszen téged hobbi szinten érdekel a téma. De ha egy fejlesztő napi 2000 dollárba kerül, akkor nem mindegy, hogy 3 vagy 13 embernapba kerül egy probléma megoldása.

WoW!
Hol fizetnek ilyen fejlesztésért napi $2000?
Hívom is őket

Igazad van. De azt se felejtsük el, hogy itt hobbisták vannak hobbi sebességgel. Akikről te írtál ők vérprofik szerintem, és szerintem ők is csak egyszer izzadnak ki valamit mint én (mondjuk FSMC, ECAN on M3, és minden egyéb periféria). Ami meg már meg van nekik, azt egyfelől védik, nem osztogatják mint mi. És mivel a programozó az egy lusta állat, nagyon szereti úgy megírni a programot hogy "mindenhol" jó legyen. Amikor meg napi 2000$-é dolgozik az nem az a rész neki hogy vakon van, és túrja a netet.

Költségről volt szó, nem a fizetésről.

Pont az a lényege ezeknek a dolgoknak, hogy ne kelljen vért izzadni, sok időt spórolhat meg egy amatőr is, ha eltanulja és hozzászokik ahhoz, ahogy a "nagyok" dolgoznak.
Bárki, aki szoftvert ír CortexM mikrokontrollerre kerülhet olyan helyzetbe, hogy beszállítót kell váltania. Ezen a téren nincs különbség a vérprofik és a hobbisták között.
Nem mindegy, hogy mekkora részét kell újraírni a meglévő kódnak, a tesztek hány százalékát kell újra lefuttatni stb. Ha van egy szabványos gyártótól független réteg, az sokat segíthet.

Idézet:
„És mivel a programozó az egy lusta állat, nagyon szereti úgy megírni a programot hogy "mindenhol" jó legyen. Amikor meg napi 2000$-é dolgozik az nem az a rész neki hogy vakon van, és túrja a netet.”

Még mindig félreértem?
Sebaj, a tizede is elég

Egészen biztosan Én arról írtam, hogy egy fejlesztő napi 2000 dollárba kerül. Nem annyit kap kézhez, annyi megy el bérre, biztosításra, licenszre, vízre, villanyra, fűtésre, stb.

Ilyet vett már valaki?

NXP LPC 1788

Pöpec.
Azt írja, hogy:


Én eddig ahány TFT-LCD kijelzővel találkoztam, annyiféle lábkiosztása volt. Tehát ezzel óvatosan.

Persze persze... Legrosszabb esetben rövid FFC kábel, egy "keverő" panel, és megint FCC csati. De szerintem jó lesz, még sosem volt gondom.

Mondjuk ezen az alaplapon van benne fantázia:
Bővebben: HY-LPC1788-SDK ( only motherboard ) Overview