-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.

Akkor érdemes az elsőt megrendelnem..
Köszi..

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)

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.

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.

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.

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

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.

Neki egy J-Link klónja van. Azzal igen is szokott gond lenni.

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..

A flash parallelism módot 2-re állítottad? Anélkül nagyon lassú a feltöltés ST-Link-kel.

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.

Ezt még nem néztem, de köszi a segítséget.. Ki fogom próbálni..

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.

Közben rájöttem a titok nyitjára.. Most már jól működik a hosszú fájlév is.

Mi az a: ?

Hosszú fájlnév, csak elírta.

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.

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ó:

Ezzel meg is oldódik a hosszú fájlnevek tárolása és használata.

És mire állitottad az _USE_LFN -t?


1-re?

Igen, ez a feltétele hogy lefusson.

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.

Nem tűnt fel, hogy ki van szürkítve az lfn-es rész?

Ú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.

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!

Miért 512?
Byte típusú a változó.
Vagy dupla buffer-t hoz létre a folyamatos tároláshoz?

Nem tűnt fel, mert nekem nem is volt benne a kódban.

Ez csak a _USE_LFN 3-as változatnál igaz.
Részlet a ff.c-ből:


Vagy tévedtem?
Mert mindenüt a lefoglalás tipusa (mérete 2 Byte):
typedef unsigned short WCHAR; ?

Azert 512, mert ez van odairva. Valoszinuleg az UTF-16 kodolas miatt, mivel a disk-re UTF-16 kodolassal irjak ki a nevet.

Pontosan mi a kérdés?
Mert nem értem, lehet nem is nekem akartad címezni?

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.