Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   124 / 177
(#) vargham válasza don_peter hozzászólására (») Máj 28, 2018 / 1
 
Idézet:
„Itt az első és második közt mi a különbség”

-Az SWD debug tekintetében egyformák. Mindkettőn a gyári szoftver fut. Átvátel után ajánlott frissíteni a legújabbra.
-A másodikon nincs se JTAG, se SWO kivezetve.
-A másodikban nem STM32F103 MCU van, mint az eredetiben, hanem STM32F101. Ezzel csak az a probléma, hogy ez utóbbiban hivatalosan nincs is USB periféria. A firmware viszont ugyanaz, a gyár ifrissítőből kilopott. Ez úgy működik, hogy kevesebb féle MCU-t gyártanak, mint ahányat forgalaznak. F103-nak indul ez is, de F101 lesz belőle, ha a minőség ellenőrzésen bukik az USB.
-A másodikban nincs semmi védelem a programozó lábakon, emiatt gyakran halnak.
-A másodikban nincs kivezetve a reset. A programozás általában anélkül is működik, úgyhogy nem gond.
(#) don_peter válasza vargham hozzászólására (») Máj 28, 2018 /
 
Akkor érdemes az elsőt megrendelnem..
Köszi..
(#) don_peter válasza csatti2 hozzászólására (») Máj 28, 2018 /
 
Iszonyat szar ez a program.
Ragad esztelen, valamikor csak vár másodperceket semmi visszajelzéssel, nem lehet eldönteni, hogy éppen dolgozik vagy csak szarakodik, vagy bármi.
SRAM-ot akartam megnézni, hogy mit ír bele, de semmi, egy csomó ablak nem is működik, érthetetlen.
Azt sem értem, hogy ami program megy rendesen debug módban az miért nem megy relase módban. Nektek mindent klappol ezzel a programmal? (Atollic TrueSTUDIO)
(#) csatti2 válasza don_peter hozzászólására (») Máj 28, 2018 /
 
Hát, nekem eddig ilyen gondom nem volt. Működik minden ablak és a sebesség is elfogadható. A memóriát is meg lehet nézni. Gyanítom, hogy a klón programozóddal lesz valami.
(#) vargham válasza csatti2 hozzászólására (») Máj 28, 2018 /
 
A klón programozókkal nem szokott gond lenni, eredeti firmware fut rajtuk.
A TrueStudio működése nekem sem jött be. Ami nekem bevált az az EmBitz.
(#) don_peter válasza csatti2 hozzászólására (») Máj 28, 2018 /
 
ST LINK-el már megy a program, és végre memória is látszik.
Sajnos a debug indítása 30mp, de legalább megy.

Csatoltam egy képet.
Ami debug módban lefordul és működik, az nem jól relase módban.
Idézet:
„Description Resource Path Location Type
#error "Please select first the target STM32F4xx device used in your application (in stm32f4xx.h file)" stm32f4xx.h /teszt/src line 102 C/C++ Problem

Mire kell itt gondolnom?
Azt értem amit ír, csak azt nem hogyan adhatnám meg neki amit kér.

debughiba.PNG
    
(#) vargham válasza don_peter hozzászólására (») Máj 28, 2018 /
 
Pont azt kell csinálni, amit ír a hibaüzenet. Kell a fordítónak a define, hogy melyik MCU-ra fordítasz. Ez alapján választja ki a periféria kezelő include-okat.
Ha a debug lefordul, akkor másold át onnan a beállítást.
(#) csatti2 válasza vargham hozzászólására (») Máj 28, 2018 /
 
Neki egy J-Link klónja van. Azzal igen is szokott gond lenni.
(#) don_peter hozzászólása Máj 31, 2018 /
 
Rendeltem J-Link-et.. remélhetőleg azzal is jó lesz.
Most egy kölcsön darabbal használom, lassú de most úgy fest jól működik..
(#) csatti2 válasza don_peter hozzászólására (») Máj 31, 2018 /
 
A flash parallelism módot 2-re állítottad? Anélkül nagyon lassú a feltöltés ST-Link-kel.
(#) vargham válasza don_peter hozzászólására (») Máj 31, 2018 /
 
STM32 only ST-Linkből (Discovery és Nucleo boardokon van) hivatalosan is lehet J-Linket csinálni. Támogatott a firmware csere, és vissza is lehet állítani.
(#) don_peter válasza csatti2 hozzászólására (») Jún 1, 2018 /
 
Ezt még nem néztem, de köszi a segítséget.. Ki fogom próbálni..
(#) don_peter válasza csatti2 hozzászólására (») Jún 8, 2018 /
 
Kipróbáltam a fájlok listázását és észrevettem, hogy a normál esetben finfo.lfname nem tartalmazza a hosszú fájlnevet.
Ezt külön be kell kapcsolni vagy valami hibádzik a programban?
Meg tudnád ezt nézni? Előre is köszi.
A hozzászólás módosítva: Jún 8, 2018
(#) don_peter válasza don_peter hozzászólására (») Jún 11, 2018 /
 
Közben rájöttem a titok nyitjára.. Most már jól működik a hosszú fájlév is.
(#) kapu48 válasza don_peter hozzászólására (») Jún 11, 2018 /
 
Mi az a:
Idézet:
„hosszú fájlév”
?
(#) killbill válasza kapu48 hozzászólására (») Jún 11, 2018 /
 
Hosszú fájlnév, csak elírta.
(#) kapu48 válasza killbill hozzászólására (») Jún 11, 2018 /
 
Ezt én is tudtam!

Csak ki akartam provokálni, hogy ide is írja hogyan csinálta! Hátha valaki másoknak éppen segítségére lenne.
(#) don_peter válasza kapu48 hozzászólására (») Jún 12, 2018 /
 
De akkor miért nem ezt írod?
Ha segítség kell, és tudok is segíteni, akkor azt szívesen teszem, nem esik nehezemre.
Azért nem írtam be, mert gondoltam mindenkinek annyira egyértelmű ez a dolog, hogy ezért nem is próbálja leírni nekem. Ezek szerint még sem és ezért nem érkezett reakció.
A megoldás pedig alant látható:
  1. #if _USE_LFN
  2.             static char lfn[_MAX_LFN + 1];
  3.            finfo.lfname = lfn;
  4.            finfo.lfsize = sizeof lfn;
  5.         #endif

Ezzel meg is oldódik a hosszú fájlnevek tárolása és használata.
(#) kapu48 válasza don_peter hozzászólására (») Jún 12, 2018 /
 
És mire állitottad az _USE_LFN -t?
  1. #define _USE_LFN        0               /* 0 to 3  ??? */
  2. #define _MAX_LFN        255             /* Maximum LFN length to handle (12 to 255) */
  3. /* The _USE_LFN option switches the LFN support.
  4. /
  5. /   0: Disable LFN feature. _MAX_LFN and _LFN_UNICODE have no effect.
  6. /   1: Enable LFN with static working buffer on the BSS. Always NOT reentrant.
  7. /   2: Enable LFN with dynamic working buffer on the STACK.
  8. /   3: Enable LFN with dynamic working buffer on the HEAP.
  9. /
  10. /  The LFN working buffer occupies (_MAX_LFN + 1) * 2 bytes. To enable LFN,
  11. /  Unicode handling functions ff_convert() and ff_wtoupper() must be added
  12. /  to the project. When enable to use heap, memory control functions
  13. /  ff_memalloc() and ff_memfree() must be added to the project.


1-re?
A hozzászólás módosítva: Jún 12, 2018
(#) don_peter válasza kapu48 hozzászólására (») Jún 12, 2018 /
 
Igen, ez a feltétele hogy lefusson.
(#) killbill válasza don_peter hozzászólására (») Jún 12, 2018 /
 
Az nem csak a lefutás feltétele, hanem sokkal inkább annak, hogy egyáltalán bele legyen fordítva a kódba a hosszú file-név kezelés. De lehet állítani 2 és 3 értékre is, csak akkor másképp foglalja a munkaterületet, aminek a hossza (_MAX_LFN + 1) * 2, ami a te esetedben 512 byte.
(#) benjami válasza don_peter hozzászólására (») Jún 12, 2018 /
 
Nem tűnt fel, hogy ki van szürkítve az lfn-es rész?
(#) kapu48 válasza don_peter hozzászólására (») Jún 12, 2018 /
 
Úgy emlékszem próbáltad sebességre optimalizálni az SD kezelést.

Ezért gondoltam, hogy letesztelted mindhárom tárolási lehetőséget, melyik a jobb 1-3.?

Nekem mondjuk az alap Dos 8.3 nevek is elegek. És a leggyorsabbak is.
(#) kapu48 válasza killbill hozzászólására (») Jún 12, 2018 /
 
Idézet:
„aminek a hossza (_MAX_LFN + 1) * 2, ami a te esetedben 512 byte.”


Mondjuk ez is vissza rettentő! Csak a LFN-nek lefoglalni ekkora területet?

Hiszen csak STM32F4-röl van szó nem 1 PC-ről!
A hozzászólás módosítva: Jún 12, 2018
(#) don_peter válasza killbill hozzászólására (») Jún 12, 2018 /
 
Miért 512?
Byte típusú a változó.
Vagy dupla buffer-t hoz létre a folyamatos tároláshoz?
A hozzászólás módosítva: Jún 12, 2018
(#) don_peter válasza benjami hozzászólására (») Jún 12, 2018 /
 
Nem tűnt fel, mert nekem nem is volt benne a kódban.
(#) kapu48 válasza don_peter hozzászólására (») Jún 12, 2018 /
 
Ez csak a _USE_LFN 3-as változatnál igaz.
Részlet a ff.c-ből:
  1. #if _USE_LFN == 0                       /* No LFN */
  2. #define DEF_NAMEBUF                     BYTE sfn[12]
  3. #define INIT_BUF(dobj)          (dobj).fn = sfn
  4. #define FREE_BUF()
  5.  
  6. #elif _USE_LFN == 1                     /* LFN with static LFN working buffer */
  7. static WCHAR LfnBuf[_MAX_LFN+1];
  8. #define DEF_NAMEBUF                     BYTE sfn[12]
  9. #define INIT_BUF(dobj)          { (dobj).fn = sfn; (dobj).lfn = LfnBuf; }
  10. #define FREE_BUF()
  11.  
  12. #elif _USE_LFN == 2             /* LFN with dynamic LFN working buffer on the stack */
  13. #define DEF_NAMEBUF                     BYTE sfn[12]; WCHAR lbuf[_MAX_LFN+1]
  14. #define INIT_BUF(dobj)          { (dobj).fn = sfn; (dobj).lfn = lbuf; }
  15. #define FREE_BUF()
  16.  
  17. #elif _USE_LFN == 3             /* LFN with dynamic LFN working buffer on the heap */
  18. #define DEF_NAMEBUF                     BYTE sfn[12]; WCHAR *lfn
  19. #define INIT_BUF(dobj)          { lfn = ff_memalloc((_MAX_LFN + 1) * 2); \
  20.                                                           if (!lfn) LEAVE_FF((dobj).fs, FR_NOT_ENOUGH_CORE); \
  21.                                                           (dobj).lfn = lfn;     (dobj).fn = sfn; }
  22. #define FREE_BUF()                      ff_memfree(lfn)


Vagy tévedtem?
Mert mindenüt a lefoglalás tipusa (mérete 2 Byte):
typedef unsigned short WCHAR; ?
A hozzászólás módosítva: Jún 12, 2018
(#) killbill válasza don_peter hozzászólására (») Jún 12, 2018 /
 
Azert 512, mert ez van odairva. Valoszinuleg az UTF-16 kodolas miatt, mivel a disk-re UTF-16 kodolassal irjak ki a nevet.
(#) don_peter válasza kapu48 hozzászólására (») Jún 13, 2018 /
 
Pontosan mi a kérdés?
Mert nem értem, lehet nem is nekem akartad címezni?
(#) kapu48 válasza don_peter hozzászólására (») Jún 13, 2018 /
 
Nem kérdés, inkább program elemzés lett volna.

Arra az állításodra, hogy char típusú tömböt foglaltál LfnBuf -nak.
A példa szerint viszont „typedef unsigned short WCHAR;” használnak.
  1. #elif _USE_LFN == 1               /* LFN with static LFN working buffer */
  2. static WCHAR LfnBuf[_MAX_LFN+1];
A hozzászólás módosítva: Jún 13, 2018
Következő: »»   124 / 177
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem