Kösz!

Ha jól látom akkor vigyázni kell, mert alapból a védelem 0.szinten van 1. szintre átállítva vissza lehet állítani 0. ra, de ha 2-esre állítom akkor úgy maradt.
Az SFU-ról nincs infó?

A kérdés inkább az, hogy miből gondolod, hogy ehhez a szöveghez tartozik bármiféle kód... Nekem az jön le a PDF-ből, hogy ez egy gyártói szolgáltatás leírása, amihez olyan kódot írsz, amilyet akarsz.

Értem, ezért nem találtam hát.

Akkor esetleg az lesz, hogy a meglévő pendrive bootloadert úgy átalakítom, hogy az előzőleg pcn- lekódolt bin fájlt az ARM bootloader dekódolja és úgy frissít majd.Más ötletem nincs.

Én is ezt csinálom olyan helyeken ahol a felhasználó frissítheti a firmware-t. Általában egy termék verziónként egyedi bootloaderben tárolt kulcsot használok (kódsorozat).
A kódsorozatot biztonsági okokból mind a bootloader mind pedig a főprogram tudja változtatni (bármiért később kulcsot kellene változtatni, akkor a főprogram legelső futása ezt megteszi).

Adott blokkméretet (kulcsméret többszöröse) kódolok végig vele, így pl ha 512 byte-ot olvasok be a firmware fájlból egyszerre akkor 32 × a 16 bájtos kulccsal végigkódolom mielőtt flash-be írnám. SAM3-on, SAM7-en, LPC-n régebben és most STM32-n is ezt az elvet használom.

Sziasztok!
Egy kis segítségre lenne szükségem egy környezet beállítással kapcsolatban.
Nem olyan rég vettem egy STM32F4 discovery demo panelt és a hozzá tartozó környezet összehozása nem egészen egyszerű számomra.
Feltettem az Eclipse-t, MinGW-t és a Mentoros fordítót. Elvileg szerintem beállítottam mindent és sikeresen is lefordítottam egy LED villogtató kód. (Innen vettem mindent: http://tecsploit.com/?page_id=124)
Ennek ellenére letöltés után nem akar villogni az adott LED, míg a linken található forrás az villog. Összehasonlítva elég rövid lett a .hex file-om a működőhöz képest.
Kaptam egy warning-ot: cannot find entry symbol Reset_Handler; defaulting to 08000000, lehet emiatt van minden.

Kérdésem, hogy miket kell pontosan beállítani a környezetben és mi ez a warning?

Szia Ven!
Én is kezdő vagyok, de úgy tűnik az okosok most nyaralni mentek, így megpróbálok én válaszolni a kérdésedre.
Nézd meg, hogy a "startup_stm32f4xx.c" vagy a "startup_stm32f4xx.S" hozzá van-e adva a projecthez. Ennek kell tartalmaznia többek között a Reset_handler függvényt is, amely ha jól tévedek az alapértelmezett megszakítás-vektorokat állítja be, meg a stack beállításához is tartalmaz instrukciót. Ezt a file-t a CMSIS is tartalmazza, több verzió is van belőle az IDE-nek megfelelően. (a profik később átírhatják a file-t, de a LED villogtatáshoz megfelelő ez a sablon is)
Elvileg az általad linkelt oldalon lévő forrás is tartalmazza, nem tudom, hogy miért nem működik.
Egyébként ha GCC fordítót akarsz használni, én az Eclipse+egy csomó más csomag feltelepítése és állítgatása helyett ajánlanám a Coocox IDE+Arm GCC-t. Sokkal gyorsabban lehet vele célt érni, mint az Eclipse összetákolásával, és ez is ingyenes. Ez tartalmazza a letisztított Eclipse-t és ráadásul az elinduláshoz különböző forrásokat is hozzáadhatsz a projecthez, mint pl. a CMSIS boot, ami a fenti file-t is tartalmazza. Hozzá már csak a fordítót kell feltelepíteni, és kész is, minden be van állítva az induláshoz. CoIDE

Egy LPC1788-on felprogramoztam, 320x240 RGB TFT-t gyönyörûen hajtja. Nem volt semmi meglepetes, elsore elindult.

Hello!

Közben azt hiszem sikerült azt a problémát eltüntetni, startup_stm32f4xx.s filet átneveztem startup_stm32f4xx.S azaz nagy "S"-re. Azért mondom, hogy azt hiszem, mert közben jött másik hiba, mégpedig az Eclipse aláhúz pár dolgot miszerint "undefined reference to". Fordításnál is dobja ezt a hibát, annak ellenére, hogy az Eclipse F3-mal odaugrik simán. A project -> properties -> Path and symbols -> GNU C++ helyen beállítottam a kívánt includeok elérhetőségét, gondolom ezt látja az Eclipse is ezért lehet benne navigálni. Viszont a fordítónak valószínűleg máshol kell megadni a PATH-t, csak azt nem tudom, hogy hol.
Ötlet?

(Még nem foglalkoznék a CoIDE-vel, ha látok esélyt beüzemelni az Eclipse-t, ugyanis lehet még át kell térnem Linuxra).

Az STM32F4XX szimbólumot hozzáadtad a project-hez?
Milyen hivatkozásokat nem talál?

Le tudnád írni pontosan hogyan és mit kell beállítani?

Most újabban ez a hiba jön és a google nem segít (hogy mit akar futtatni sh-val azt már nem tudom):

make
Building file: C:/Elektronika/Elektro/ARM/STM32F4_Discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/misc.c
Invoking: ARM Sourcery Windows GCC C Compiler
arm-none-eabi-gcc -DUSE_STDPERIPH_DRIVER -DUSE_STM32F4_DISCOVERY -DSTM32F4XX -I/C/Elektronika/Elektro/ARM/STM32F4_Discovery/STM32F4-Discovery_FW_V1.1.0/Utilities/STM32F4-Discovery -I/C/Elektronika/Elektro/ARM/STM32F4_Discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -I/C/Elektronika/Elektro/ARM/STM32F4_Discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Include -I/C/Elektronika/Elektro/ARM/STM32F4_Discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc -I/C/Elektronika/Elektro/ARM/projects/proba_01/src -I/C/Elektronika/Elektro/ARM/projects/proba2/inc -I"c:\Elektronika\Elektro\ARM\STM32F4_Discovery\STM32F4-Discovery_FW_V1.1.0\Libraries\CMSIS\ST\STM32F4xx\Include\" -O0 -Wall -Wa,-adhlns="StdPeriph/misc.o.lst" -c -fmessage-length=0 -MMD -MP -MF"StdPeriph/misc.d" -MT"StdPeriph/misc.d" -mcpu=cortex-m4 -mthumb -g3 -gdwarf-2 -o "StdPeriph/misc.o" "C:/Elektronika/Elektro/ARM/STM32F4_Discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/misc.c"
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [StdPeriph/misc.o] Error 2

**** Build Finished ****

Az STM32F4XX szimbólum hozzáadását a mellékelt kép mutatja. Ez Coocox, de mivel ez is Eclipse alapú, feltételezem, hogy valami hasonló lehet nálad is a View/Configuration menüpontban. Ha mégsem, akkor bocsi. (esetleg Preprocessor Symbols menüben)
A beollózott hibaüzenet nekem semmit sem mond. Mintha a misc.c megsérült volna.

Szia!

Azt mondja, hogy hianyzik egy zaro ". Ami lehet is, mert az egyik -I opcio megadasanal a lezaro " elvesz, mert \"-re vegzodik a szoveg, amitol a unix sh a macskakormot elnyeli (talan).
Nem biztos, hogy ez a baj, de egy probat meger, hogy minden file eleresi utvonalat atirsz / jelesre \ helyett.

Udv,
Andor

Szia!

Isteni magasságokba lennél emelve, ha egy ZIP file-ba elküldenéd nekem a projectet! Kiokoskodni most nincs időm, hogy miért nem működik, a logikai analizátort a panelra még nem tudom csatlakoztatni, amíg egy PCB meg nem jön postán. Annyira nem akar egyébként működni, hogy kezdek arra gyanakodni (4 példaprogi után), hogy a kijelzővel van valami gond...

Ezt


Simi.

Hali!

Hát, ez nem az a projekt, amit odaadhatnék másoknak. Bővebben. Az LCD vezérlô felprogramozása két részbôl áll: egyrészt az I/O-k beállítása az LCD-hez. Ez hw függô, te tudod, hogy melyik uC láb hová van kötve az LCD-n. De magának az LCD controllernek a felprogramozása nagyjából 8 sor, az viszont a kijelzô és a választott bpp függvénye. Az a sok konstans a TIMV, TIMH regisztereknél, az mind kijelzô specifikus érték, a kijelzô adatlapjából származnak. Ezek a HSYNC és VSYNC jelek elhelyezkedését és az impulzusok hosszát határozzák meg. Ja, nekem saját head-erjeim vannak, de önmagukért beszélnek. Ezen felül van még a külsô SRAM, amiben a framebuffer van.

Van valami különösebb oka annak, hogy a 1788-hoz SRAM-ot használsz, SDRAM helyett?

Az igazság az, hogy ezt a kérdést már én is feltettem magamnak Talán annyi, hogy így 100% biztos voltam a hw-ben, amúgy meg semmi nem indokolta a nagyobb RAM alkalmazását. Csak a kijelzô használja, neki meg 76k kell.

Ilyesmit csináltam én is.
A lábak beállítása ok, többször ellenőriztem.
Arra szeretnélek kérni hogy amikor a TFT elkezd működni, add meg a TFT regiszterek HEX értékeit, és én kikukázom belőle az egyes paramétereket. Add oda kérlek mellé a TFT adatlapját, hogy a regiszterek értékeit mellé tudjam tenni az adatlap értékeinek.
Aztán ha ez megvan, már a saját TFT-mmel szeretném ugyan ezt visszafelé csinálni.
Jól látom akkor hogy a PCLK az 60MHz, és a TFT vezérlőn belül osztod le hogy 6.6MHz legyen belőle?
UPBASE = LPBASE = 0xA000 0000; nálam azaz a külső SDRAM kezdő címe, ami működik, ellenőrizve.
A piros számokat csak most írtad be, hogy lássam mit hova írtál?

A pontos ertekeket nem tudom neked megadni, mert azokat pont ezek a makrok allitjak elo a beleirt (piros) szamokbol. Azaz, az adott regiszter adott reszebe shiftelik az erteket, esetenkent levonnak belole 1-et es ugy shift-elik. Nekem a PCLK 100MHz es 15-tel osztva lesz belole 6.66MHz. A kijelzo tipusa: ET0350G0DM6.

A makrokat ideteszem neked:

Üdv!

Usb host mód esetén nem hívódik meg az alábbi eseménykezelő USBH_USR_DeviceDisconnected.

Gondolom, ha kihúzom a pendrive-ot akkor csak észre kéne vegye.
Ugyen ez a helyzet ezzel is USBH_USR_DeviceAttached. Ez is csak akkor hívódik meg, ha a pendrive már csatlakoztatva van az USB init előtt. Ha utána csatlakoztatom akkor nem veszi észre a csatlakozást, magyarán semmi nem történik.
Kell ezeket az eseménykezeléseket valahol külön engedélyezni? Én kerestem, de nem találtam erre utaló részt.
Mi lehet az oka, hogy ezek nem hívódnak meg, pedíg nekem fontos lenne tudnom érzékelni, hogy van -e pendrive csatlakoztatva, vagy nincs, vagy menet közben kihúzták.

LPC_SCB az milyen regiszter tömb? Mert nekem csak LPC_SC van.
Jól érzem hogy az a System & Clock control, melyben a PCONP 0. bitje kapcsolja a TFT vezérlőt?
lpc_scb->lcd_cfg: ez az az osztó ahonnan a TFT vezérlő működik?

Csak a pontosság kedvéért. A 'C' nyelvben a kis- és nagybetûk számítanak, nem keverhetôk. Én lpc_scb-t írtam és az nem ugyanaz, mint az LPC_SCB. Általában a 'C' nyelvben megszokás, hogy a csupa nagybetûs azonosítók makrók. Nem mindíg, de általában. Mindegy is, mert jelen esetben az lpc_scb is egy makró... Szóval az általam írt lpc_scb az egy struktúra pointer (ez az utána írt -> operátorból jól látható), ami a mikrovezérlô system control block-jának a regisztereit foglalja egybe (nálam). Ez egy logikai blokk, és az ilyenek használatától áttekinthetôbb a program. Mert az, hogy RBR az lehet bármi, de ha lpc_uart0->rbr akkor az már sejteti, hogy ez az LPC mikrovezérlô egyik uart-jának valamely regisztere. Ez csak stilisztikai kérdés, de egy 10-20 ezer soros programnál ennek van jelentôsége.

Az lpc_scb->pconp az az általad említett PCONP regiszter megfelelôje. Hogy melyik bit-je mit állít, azt hadd ne tudjam, ezért vannak a makrók. Ha azt írod, hogy PCONP |= 1; az senkinek nem mond semmit, de a |= SCB_PCONP_LCD az sokkal beszédesebb. Nyilván az LCD-vel kapcsolatos. Persze a forrásszövegbôl nem derül ki minden, az adott hardvert ismerni kell. De a mikrokontrolleres programozásban ez szerintem elvárható.

Az lpc_scb->lcd_cfg meg az LCD_CFG nevû regiszter, amivel az LCD controller pixel clock frekvenciáját lehet beállítani. Az LPC178x User's Manual leírja, hogy mit hogyan kell bekötni, hogyan kell felprogramozni a regisztereket. Mondjuk azert tisztában kell lenni az LCD interface mûködésével. Speciel ez a regiszter egy kakukktojás, mert az LCD vezérlô szerves része, de ennek ellenére a system control block címtartományban van valamiért. Ezt csak az NXP tudja, hogy miért. Tulajdonképpen betehetném én is az lpc_lcd strukturába. Sôt. Bele is tettem.

Pár apróság:
Nem vagyok kopasz. Azért kértem a segítséget, mert most nincs időm kiszenvedni mi a baj, haladni szeretnék.
A KEIL header file-okban a hardverek regiszterei csupa nagy betűvel vannak írva, ezt szoktam meg, szinte mindenhol így láttam őket. Ezek szerint te a header file-okat is magadnak írod. Okay, nem volt gond, átírtam az én környezetemre.
Ha valaki ilyen alacsony szinten programoz, szerintem elvárható hogy ismerje a regisztereket és az egyes biteket. Ha az ember kommentel a PCONP |= 0x01; is beszédes lesz. Csak hát a lustaság a legtöbb embernél...

Szia!

Ok, nem vagy kopasz, nem is mondtam. De szerintem az nem hasznos segitseg, hogy elkuldom neked a kijelzo adatlapjat es a binaris ertekeket, amiket a regiszterekbe kell irni. Az adatlap eleg vilagosan leirja, hogy ide ird be a pixelek szama-1 erteket. Ide meg a horizaontalis szinkronjel hossza-1-et pixel clockban merve, satobbi. Vagy tudod, hogy mi az a pixel clock es szinkron jel, vagy nem. Ha nem, akkor a regiszterek erteke csak es kizarolag az enyemmel megegyezo kijelzo eseten fog segiteni. Ha tudod, hogy mi mit jelent, akkor meg nem nagyon lehet tevedni, nem sokbol all a felprogramozas. Lathattad, 7 regiszter, semmi magia. Mondjuk az NXP dokumentacio nincs a helyzet magaslatan, azt meg kell hagyni. Sokszor eleg pontatlan, hianyos. A kijelzo doksija meg a masik fele, koszonhetoen a kinai angolnak.

Tudom, hogy a legtobb gyarista header-ben csupa nagybetusen adjak meg a regisztereket. Nem csak a KEIL, masok is. De ettol ez meg nekem nem tetszik. Igaz, en mar 20 eve a 68HC11-en, 68000-en meg AVR-en is igy csinaltam, es amikor a mikrokontroller sajat regiszterei mellett volt vagy 120 regisztere az FPGA-nak is, akkor azert gondolhatod, hogy olvashatobb volt az

mint a




Hat, ez felreertheto. Az alacsony szinten valo programozas egyik ismertetojele a konstansok hasznalata definiciok helyett Egyebkent meg nem ertek veled egyet; miert kellene nekem tudnom fejbol az adatlapot, az osszes regiszter osszes bitjet? Ezen az alapon azt is tudni kellene, hogy melyik regiszternek mi a cime. Szep is lenne. *(volatile unsigned int *)0x400cf100 |= 1; Pont ezert vannak a hardware-t leiro header file-ok.

Abban igazad van, hogy a kommentekkel (majdnem) ugyanolyan beszedes lesz a forras. Csak attol meg nem szep. Es hat József Attila is megmondta, hogy dolgozni csak pontosan, szépen.. Megaztan, amikor valtozik valami, bár az LPC kijelzovezerloje ritkan valtozik, de a sajat HW valtozhat, akkor csak a define-t kell atirni, nem az egesz programot 100 helyen. Ez tovabbra is stilisztikai kerdes. Olyan, mint oltonyben menni a szinhazba. Semmi ertelme es meleg is, megsem rovidgatyaban megy oda az ember. En is szoktam konstansokat irni, de csak hirtelen, magamnak, es idovel ugyis atirom, csinalok neki #define-t, mert zavar.

Jól eldumálunk egymás mellett.
Szerintem:
A regisztereket azért kell tudni, hogy tudd hogy működik. Azt tudom, hogy működik, de valamit benéztem.
A regiszter értékek azért kellenek, hogy azokat az értékeket hozzávessem egy adatlaphoz, ami páros bizonyítottan működik, majd adaptáljam a sajátomra.
SSD-hez én is írtam kiszámolós konfigot. Jól működött. De még nem tartok ott. Most még csak az a cél hogy fix értékeket beírva működjön. Aztán megírom a kiszámolót, és ha ugyan azt az értékeket hozza (és még mindig működik) akkor jó a kiszámolós-kényelmesítő header is, ahogy a tied bizonyosan jó, hisz működik.
Én 15 évig csak ASM-et használtam, nem vagyok "igazi" C programozó, de azért haladok...
Kérdés:
P2.0 LCD_PWR ami a DISP lábra megy, standard-on 31.es láb a TFT-n az neked GPIO, és te kapcsolod, vagy ráhagyod a 1788 TFT vezérlőjére?

Hello!

Nekem a P2.0 lab nincs sehova kotve. Itt a rajz idevonatkozo resze. A jobb also sarokban latod a kijezot. Belemegy az R-G-B, HS, VS, CLK, DEN meg a RESET. A maradek ket lab (PWRCTRL, LEDCTRL) csak a hattervilagitast vezerli. Mivel a kijelzo DEN labara meno uC lab bemenetre van allitva, azt igazabol be sem kellene kotni. Csak amikor terveztem a panelt, akkor meg nem volt biztos, hogy melyik uzemmodot fogom hasznalni. Azt irja a kijelzo adatlapja, hogy "SYNC MODE"-hoz a DEN labat nem kell bekotni, csak a HSYNC es VSYNC-et, mig "DE MODE"-hoz a HSYNC es VSYNC kell lebegjen, es a DEN labon kell vezerelni az adatforgalmat. En SYNC modban hasznalom.

Es itt vannak az I/O felprogramozasok is:

Latom, a rajzot a forum lekicsinyiti, felteszem ide

Sziasztok !

Milyen lehetoseg van arra C-ben, hogy fuggvenybol ki tudjak ugratni es "n" ido elteltevel ugyanoda visszaugratni ? Ha valaki hasznalt ilyesmit ne tartsa vissza. Karakteres lcd delayt kellene kivaltsak valami hasonlo modszerrel.

Timer Interrupt.

Például Protothreads.

Sziasztok!

Elkezdtem mindent az elejéről felhúzni, de gyakorlatilag ugyanott akadtam el.

-fmessage-length=0 -MMD -MP -MF"src/stm32f4_discovery.d" -MT"src/stm32f4_discovery.d" -mcpu=cortex-m4 -mthumb -g3 -gdwarf-2 -o "src/stm32f4_discovery.o" "../src/stm32f4_discovery.c"
../src/stm32f4_discovery.c:69:34: error: 'GPIO_Pin_12' undeclared here (not in a function)
../src/stm32f4_discovery.c:69:44: error: 'GPIO_Pin_13' undeclared here (not in a function)

A fordító nem látja, de az eclipse igen. Mit lehet ilyenkor csinálni?
(Kicsit kezd már elegem lenni ezzel a linuxos sz.rakodással, főleg Windowson.)

Üdv!