Bővebben kifejtve:
Azért nem használok CMSIS-t mert:
- gőzöm sincs mit csinál a háttérben.
- tele van bug-al
- ezért kerülöm mint a tüzet, sőt a hajam is hullik tőle.

A CMSIS-el ellentétben ha beírom az hogy:



Az tuti hogy a 0. bitet 1-re állítja és indul a konverzió.
Ez utóbbit hívják bare-metal programming-nak.

Nem tudom mi az a CMSIS. Egyről beszélünk? mert a programomban nem látok ilyet.

Értem.
CMSIS olyan mint PIC-nél az előre létrehozott függvénykönyvtárak?
Tehát minden előre meg van írva, csak gyakorlatilag nem tudod mi mit csinál, csak beírod a függvény nevét és a paramétereket, vagy jobb esetben még azt sem.
Sok a hiba PIC-nél is ezen függvényekben, ezért írok ott meg én is mindent az alapoktól.

Lehet rossz hozzászólásra kattintottam mint válasz. De egyébként igen. Nagyjából. Itt olvashatsz róla bővebben.

CMSIS

Az az érzésem, hogy te a device firmware library-ket is CMSIS-nek hívod. Mind pl. az STLIB. Holott a CMSIS az csak a mag kezelésére való, pl. az ADC-t már nem tudod CMSIS-el kezelni, mert az már nem magfüggő.
CMSIS nélkül viszont egy csomó dolgot csak assemblyben lehetne megvalósítani. Te tényleg Assemblyben programozod a magközeli dolgokat? Esetleg a startup kód még a BSS és a Data inicializálásig belefér, de a többit nem merném bevállalni. Ha te igen, akkor le a kalappal!

Írtam, hogy lehet rossz post-hoz írtam a hozzászólást, két program hibája futott egyszerre tegnap post-ban.
Nem, nem assembly-ben írok, de:
- A CMSIS egy C nyelven írt közbenső réteg a bare-metal és az application layer között. Én ezt a köztes réteget hagyom ki magam megírt programokkal.
- A CMSIS nem csak a maghoz kellhet. A mag az ALE, az NVIC, az RCC, és még pár dolog. Az UART, SPI, FSMC, és hasonlók már nem a mag, és CMSIS-ben ehhez is vannak előre írt rutinok. Így a fenti állításod nem igaz, mert az ADC-hez is van CMSIS library. Minden mag közeli és távolabbi perifériához van.
- CMSIS arra van, hogy kellőképpen bonyolítsa az életet, hogy utána ne tudd mi történik, és ezért legyen miért ide írni. Jah meg arra hogy ha mondjuk LPC-ről STM-re váltasz akkor úgy ahogy működjön a kódod. De mivel énúgy vagyok vele az ST mindent lefed mélységben és magasságban amióta a 429-el van SDRAM és TFT vezérlőjük, így már nem kell (nekem legalábbis) gyártók között ugrálni. Amit megírok M0-ra az ugyan olyan regiszter nevekkel fut M7-en is. Legfeljebb (nagy ritkán) kell a lábakat átvariálni.

Ahogy írtam a két program közül az egyikben láttam CMSIS-es részeket, meg a kérdést hogy na vajon miért nem megy. A bare-metal programmingról a neten olvastam azt jelenti hogy közvetlenül írod a proci különféle perifériáinak regisztereit, CMSIS vagy éppen az LPCOpen nélkül.

Az elnevezéssel kapcsolatban SBahadurD-vel kell egyetértenem. A CMSIS csupán néhány file-ból áll, pl. startup_stm32f10x_md.S, system_stm32f10x.c, core_cm3.h, stb. Nem ezekkel van a probléma (ezeket szerintem majd' mindenki használja), hanem a Standard Peripheral Library-val. Ezek a file-ok segítenének kezelni a perifériákat ...adc.c, ...fsmc.c, ...spi.c, ...tim.c. Ezektől én is frászt kaptam, nem használom őket. Helyette - ahogy írod - én is inkább közvetlenül a regisztereket állítgatom. Lassabb a fejlesztés, de hibamentes.

A CMSIS nem szoftver, hanem specifikáció. Nem látom tehát, hogy hol az ellentét a bare-metal programozásod és a CMSIS között? Ha nem tetszik, hogy a CMSIS specifikációt követni próbáló támogatói könyvtárakat hogyan gányolta össze a gyártó (vagy a szoftvercég, akiknek kiadták gebinbe), akkor semmi sem akadályoz meg abban, hogy a CMSIS specifikáció alapján megírd a saját verziódat. Ebben az esetben lesz egy általad maximálisan kézbentartható, de másokkal kompatibilis programkönyvtárad, amelyet akár értékesíthetsz is - ha jó, és lefedi az általános igényeket.

A CMSIS RTOS pedig csak egy mintaimplementáció (a Keil RTX alapján), amelyet ízlés szerint lecserélheted bármelyik CMSIS API kompatibilis RTOS-ra, vagy írhatsz helyette másikat/jobbat.

Akkor deklarald ugy, hogy
Ha nem volatile, akkor a C fordito optimalizacio kiszedheti a latszolag felesleges muveleteket, mint pl. tobbszor felolvasni egy valtozo erteket, ami normalisan nem valtozhat meg. A C nyelv nem definial megszakitast vagy DMA-t, ezert nem szamol azzal, hogy egy valtozo csak ugy magatol megvaltozhat.

Valaki el tudná mondani értelmes emberi nyelven - nem úgy mint az users manual - az AD konverter "injected chanel" mire való az STM32, nálam most éppen 207-es procin?
A sima "regular" módot a 16+3 bemenetével értem, meg azt is hogy tetszőleges sorrendben, mintavétellel, stb lehet őket kérni. De ez az "injected" ez vakfolt...

Itt beszélnek róla.
Ha jól értem, csak annyi, hogy néhány (max. 4 db) analóg csatornát külön ki lehet jelölni, amelyeket más időzítéssel (független triggereléssel), külön kezelhetsz.

Azt hiszem meg van.
A "regular" csatornákat beállított sorrendben, mindet külön külön mintavételezéssel konvertálja az STM. De kijelölhetsz 4-et amelyek bármikor az adott trigger-feltétel teljesülésekor megszakítják a normál ügymenetet, és beékelődnek. Gyakorlatilag elsőbbséget élveznek, bármikor.

Végül sikerült megoldani, nem ez volt a probléma, hanem a while(1) függvényt kellett"lassítanom kicsit ugyanis ha beraktam egy 1us-os késleltetést a while(1) után akkor már megjavult és adja az adatokat.

Jelenleg ott tartok, hogy 995x vesz mintét 10u-sonként és utána 5 másik bemenetről. Viszont valami nem stimmel amikor az 5 bemenetet egymás után kellene beolvasni.

létrehoztam egy 5 változós short bemenet[5]; tömböt. Ebbe jönnének az adatok így:


bemenet [0] lenne a P1 poti
bemenet [1] lenne a P2 poti
bemenet [2] lenne a P3 poti és így tovább.
A baj az hogy a bemenet[0] -ra beolvassa a CH_0-t ami nincs is kijelölve.

Bemenet [1] lenne már a P2 poti de itt kezdi a P1-et de úgy hogy CH_0 bemenettel bele tudok "zavarni" a beolvasott értékbe +/-3% ot kb

Bemenet [2] a P2 poti de úgy hogy P1-el bele tudok "zavarni" a beolvasott értékbe közben a proci lába stabilan ugyan annyi marad. Nem értem.

bemenet [3]-[4] -egyenlőre nem néztem de ott is ezek lehetnek.

Miért van ez az "áthallás" ha a proci lába stabil? Továbbá miért olvassa CH_0-t ha nincs is kijelölve?

Az áthallási hibára közben rájöttem. Parazita kapacitás miatt volt. Megpakolom majd a bemenetek tövét pár nanós kondikkal. De hogy miért mintavételez a CH-0-ról is amikor azt 0-ra állítom azt még mindig nem értem.

Megnéztem a CHANNEL SELECT registert és a CH_0 0.

Üdv.

Olyan kérdésem lenne, hogy egy felprogramozott procit, hogyan tudom lezárni hogy utána már ne tudják kiolvasni belőle a kódsort és esetlegesen sokszorosítani? Alapvetően STM32F030-astól van szó

Esetemben pl a uVision 5.0 használok. be lehet ennél valahogy állítani ezt?

köszi

Nincs olyan SYSTEM regiszter amiben ezeket a program, memória védelmeket lehet állítani?
Adatlap nem segít ezzel kapcsolatban? (PIC-ből kiindulva)

Én azt csinálnám hogy a processzor egyedi sorozatszáma alapján generálj kulcsot, és a program csak azon a sorozatszámú procin fusson. Így hiába szedi ki hex-file-ba a kódot, másik procin nem fog futni. Szerintem.

STM32F0 is rendelkezik RDP-vel (read out protection). Ha a libjeid nem tartalmazzák akkor a 0x1FFFF800 cím alatt megtalálod az RDP byte-ot M0 esetében.

Szintek
Három szintje van az RDP-nek, ami a védelem fokát jelöli. Érdemes odafigyelni, hogy a legmagasabb szint még a JTAG/SWD elől is elzárja a flasht.
Level 0 - Nincs védelem (írható-olvasható bárki számára bármin)
Level 1 - Olvasás elleni védelem. Feloldható erase-el, visszazárható programozóval / programkódból
Level 2 - "Se írás, se olvasás", nincs debug hozzáférés sem, kizárólag ROM bootloader-ből törölhető.

Mintakód CMSIS esetén
Level 1 kiolvasás elleni védelem engedélyezése programból.


Mindenképp légy észnél ha használod

Heló.

Level 1 elégségesnek tűnik.
Ezek szerint ha ezt berakom a program első soraiba akkor rendben is lesz?

Köszi.

STM32F40xxx and STM32F41xxx Flash programming manual

1.6.3 Read protection (RDP)
...
● Level 2: Disable debug/chip read protection
When the read protection Level 2 is activated by writing 0xCC to the RDP option byte,
all protections provided by Level 1 are active, system memory and all debug features
(CPU JTAG and single-wire) are disabled when booting from SRAM or from system
memory, and user options can no longer be changed.
Memory read protection Level 2 is an irreversible operation. When Level 2 is activated,
the level of protection cannot be decreased to Level 0 or Level 1.
Note: The JTAG port is permanently disabled when Level 2 is active (acting as a JTAG fuse). As a
consequence, boundary scan cannot be performed. STMicroelectronics is not able to
perform analysis on defective parts on which the Level 2 protection has been set.

Read Protection:
Migration of microcontroller applications from STM32F1 to STM32L1

OK! A következő lapon már megválaszolták a kérdést!

HAL könyvtáram van ilyet találtam:





Ezekkel gondolom megoldható.

Így van!

Oké, kipróbálom hamarosan. Köszi.

Van egy problémám: stm32f0discovery board + hd44780. 8 bites módban megy a kijelző, 4 bitesben nem. Ezt egy macróval állítgatom. A portok PB0..7-ig van, nyilván 4 bitesben ez 4..7-ig változik. A 8 bites mód teljesen működik, a 4 bitesben viszont krix-krax és nem érti az utasításokat. A GPIO portokon jól jelennek meg a karakterek, kimértem. 2ms clock jelek vannak, systick int-el előállítva. Kód:
https://drive.google.com/drive/folders/0B0T6b2efIoQ5MFpwUUl2blNEaUk

Valakinek ötlet?

Csinálj egy rendes 4-bites inicializálást! Bővebben: Link

Valakinek sikerült már STM32-n FMC-vel hajtott SDRAM-ból kódot végrehajtani?
Nekem STM32F207-en külső SRAM-ból, amit az FSMC hajtott, ment a kód végrehajtás, de most az SDRAM-on nem megy. Ha valakinek sikerült már, szívesen vennék pár tanácsot.
Érdekes módon, szimpla adattárolóként tudom használni az SDRAM-t. Be is tölti oda a programot az SD kártyáról. De amikor átadná a vezérlést az SDRAM-on lévő kódnak, hardfault-t okoz.
Köszi előre is a segítséget.

Srácok, nézegetem az ARM programozását.
2 féle módot látok, az egyik a JTAG a másik az SWD.
Mi a különbség a kettő közt?
Azt látom, hogy az SWD az szerencsére csak 2lábat emészt fel, a JTAG viszont sokkal többet.
Annyi talán, hogy a JATG-al lehet debugolni de az SWD-vel nem?
Előre is köszi.

SWD-vel is lehet debugolni. A nagy különbség igazából az, hogy míg JTAG-el ASIC, FPGA, CPLD, stb is programozható, addig az SWD-vel csak ARM.
Lábszáma igen, kevesebb az SWD-nek, egy hajszálnyival lassabb is, viszont lehetőség van arra például (egyes fejlesztői környezeteken keresztül), hogy a sima stdout / printf függvényt "ki route-old" a fejlesztői környezetre mint "konzol log".

A kevesebb SWD vezetéket sokszor egyszerűbb behuzalozni, mint a 10P-s JTAG csatit. Kezdésre teljesen jó az SWD. Ha nem fűzöd fel az eszközöket akkor JTAG nagy előnyt nem tud felmutatni Neked.