Nekem, mint IDE a Visual Studio jött be a legjobban, de főleg .net-hez használtam. Eddig nem volt benne ARM MCU támogatás, de most jön: ARM GCC Cross Compilation in Visual Studio
AVR-hez és SAM-hez Atmel Studio, ami szintén jó, mert Visual Studio alapú.
Az Eclipse nekem nem jött be, se C se Java nyelvhez. Pedig dolgoztam vele Androidra, és különböző variánsaival ARM-ra is (TrueStudio, SW4STM32, stb). Lassú, nehézkes, időnként felbukkanó rejtélyes hibák, stb.
ARM-hoz (STM32) jelenleg EmBitzet használok, és elégedett vagyok vele.
Keil az jó, de nem vásároltuk meg, a 32 kB pedig hamar elfogyott.

Nem, ARM-hoz silabs miatt vagy Simplicity Studio(Eclipse) innen vannak a "jó" tapasztalatok az eclipse-ről, Keil vagy Visual Studio(visualgdb) a másik ágon PIC32-höz használom az MPLAB X-et ami meg NetBeans-es.

Az STM32-őt csak nagyon futólag használtam.
Maga az ARM register szerkezete jobban tetszik, de a STM32-es és EFM32-es doksik nem tetszenek, nagyon Microchip doksis vagyok.

Most kezdesz átmenni PIC32 vagy STM32 vitába.

Szerintem árversenyben győz az STM32 mivel olcsóbb!
Ezért inkább felhasználó barát.
A többi csupán részletkérdés.

ááá, nem akarok semmiféle vitát indítani csak leírtam hogy "ebbe ez" "abba az". Inkább a függetlenség a cél, ha a megrendelő "ezzel" szeretné vagy "azzal" akkor ne okozzon problémát.

Szerintem azért van mert az open source Java alapú IDE-k nagyobb múltra tekintenek vissza. A Netbeans, Eclipse 10 éve már kész szoftverek voltak amikhez már akkor fejlesztettek pluginokat, stb.

A Visual Studio nagyon sokáig zárt dolog (súlyosan fizetős termék) volt. Az MS csak hozta el (a wikipédia szerint) 2008-ban adta ki a Visual Studio Shell-t ami lehetővé tette, hogy saját IDE-t építhettél belőle. Nyilván egy félvezetőgyártóként nem tolhatod le az ügyfelek torkán, hogy srácok telepítsétek a VS community editiont majd telepítsétek fel az addonunk-at. A felhasználónak (fejlesztőknek) egy next-next-finish telepítő kell aminek a végén ott az IDE, a toolchain, a build system, a debugger a programozó. Na ezt VS alapon a Shell megjelenése előtt nem lehetett megoldani. Illetve az, hogy a VS Shell használatát milyen licenszfeltételek mellett engedélyezi az MS arról nincs információm.

Amit nem értek/sajnálok viszont az az, hogy a QtCreator vonatra nem ült fel egy félvezetőgyártó sem. (Biztos olcsóbbak Indiában a Java kóderek mint a C++ kóderek )

Most egy nagy rejtélyt tisztáztál bennem
De amit például vargham mondott az kifejezetten érdekes, a vizsgaidőszak miatt csak rákukkantottam, de így végül is viusalgdb nélkül free-be lehet használni a vs-t.

Ehhez képest az STM-nek eddig semmilyen saját megoldása nem volt a saját ARM sorozatához...

Nyilván az AC6 csupán saját jókedvéből/hobbiból szegeli a STM32Workbenchet...

Tudja a fene...
A weboldal nem túl bőbeszédű, nem árulja el, hogy kik csinálják. Elvileg community...
Az ST weboldala szerint: "This product is supplied by a third party not affiliated to ST." Úgyhogy vegyük ezt a hivatalos helyzetnek.

A gyártók vagy együttműködési szerződést kötnek a külső szoftverfejlesztő céggel, vagy felvásárolják azokat. Nyilván megfontolják, mikor melyik éri meg jobban...

ST ezt csinálta SMT8 fronton is: ott a Cosmicnak fizetnek éves díjat azért, hogy legyen free fordító a piacon.

Én most úgy gondolom, hogy az IDLE jelet nézem USART megszakításban. Amikor megjelenik
ez az IT jel, leállítom a DMA-t, átírom a mutatóját kezdőre, átteszem a DMA USART buffert egy másik bufferbe és a főciklusban majd feldolgozom. Egyszerűsíti talán a dolgot, hogy minden bejövő csomag előről kezdődik a DMA bufferben.
Működhet így??
IDLE jel mikor generál megszakítást? Addigra a DMA összeszedte a bájtokat?
Köszönöm.

Tegnap kaptam értesítést, hogy letölthető az új: TrueSTUDIO for STM32 9.0.0 released
Bővebben: Link

Első próbálkozásra tetszik, hogy gyorsabban fordít, mint az uVision5
Még ami nagyon érdekel a Debugolás, mivel azt még eddig nem volt alkalmam kipróbálni.

Szerintem ez nagyot fog lendíteni az STM felhasználói táborán.

Sziasztok!
Egy rutin sebességét szeretném lemérni. Elég 10 us "pontossággal"
Arra gondoltam, hogy egy timer-t elindítok 10 us ütemmel, majd a megszakításában
növelek egy változót. Mérendő rutin belépésekor lenullázom, kilépéskor lekérdezem
a számlálót. Ennyi idő alatt futott le 10 us időalapban mérve. Ez így jól menne?
Esetleg van olyan regiszter, amiben az eltelt órajel ciklusokat le lehet kérdezni?
Oszcilloszkóp és egy port kapcsolgatása nem játszik.
(stm32f103rb, coocox 1.7.8)
Köszönöm,
Roland

Ha nem használod a systick-et másra, akkor javaslom azt használd mivel a többi timer-rel ellentétben az 24bites (ha nem tart nagyon hosszú ideig a rutinod, akkor nem kell megszakítás sem). Órajele lehet a CPU órajel vagy pedig annak a nyolcada, így bőven elég pontos.

Köszönöm.
A systick-et használom. Pont azt akarom megmérni, hogy a két systick között mennyi idő az interrupt ciklus ideje. Mennyi idő marad a főciklusra.
A systick 1 ms, tehát a rutinnak jóval kevesebb idejűnek kell lenni, hogy maradjon idő másra is.

Akkor miért nem kérdezed le a systick számlálóját a rutin végén? Kész is egyből a végeredményed.

Én azt hittem, hogy a számlálója az interrupt meghívásakor/előtt növekszik ergo 1 ms-onként...
Ezzel állítom be:


systickIni(1000);

Sziasztok!

Még mindig stm32f103c8t6 és EmBizt.
Ránézne valaki hozzáértő a LINK-en lévő programban a delay függvényre?
Ez is a systick-et használja, de nem látom, hogy interruptként használná.
Mennyire használható megoldás ez? Jól látom, hogy tényleg nem használja az interruptot?
Ezt egy az egyben át tudom venni az EmBitz-be?

Ha a késleltető függvény csupán arra szolgál, hogy a CPU-t várakoztassa, akkor szoftveresen is figyelhető a túlcsordulás, nem kell hozzá megszakítás.

Rosszul tudod. A számlálója akkor resetel, amikor a megszakítás meghívódik. Az 5-ik sorban kapott értékkel hasonlítja össze a számlálóját a hardver, ha megegyezik hívja a megszakítást.

Szia!
Igen, csak perifériára való várakozás a cél. (kijelző, gomb, VFD, stb...)

beállítást és

delay_us(1000000);
utasítást használva a mintakód alapján 1sec időzítésnek kellene lennie. De nem így van. Miért ?

A mintakódban a kommentben azt is leírják, hogy a pontos időzítés feltétele az, hogy a SysTick 1 MHz-es órajelet számlál: "The clock source is assumed to be the internal 8MHz RC oscillator
divided by 8 (1MHz)"

Ha nem ennyi az általad beállított frekvencia akkor természetese nem 1 000 000-nak kell lennie a betöltési értéknek.

A PM0056 Programming manual 4.5 fejezetében találsz leírást a SysTick regisztereiről. A SysTick->CTRL regiszter 2. bitje választja ki az órajelet (0 esetén: AHB/8, 1 esetén: AHB)

Próbálkozom, de nem akar sikerülni.

Ha SysTick_CLKSourceConfig(SysTick_CLKSource_HCLK_Div8); sort használom, akkor fut ugyan, de nem 1 másodpercre kapcsolja ki és be a ledet,hanem gyorsabban.
Ha meg a SysTick_CLKSourceConfig(SysTick_CLKSource_HCLK); sorral fordítom le, akkor nem is történik semmi, hanem a while(!(SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk)); soron megáll és ott várakozik állandóan .
Annak ugyanaz a hatása hogy ha egyik sincs benne, mint ha a Div8-as benne van. Mondhatni semmi hatása a Div8-nak.
Szóval hogyan?

Azért nem látszik a hatása, mert a Power on/Reset alapértelmezetten az AHB/8 frekvenciát választja ki a SysTick->CTRL regiszter nullázásával.


Mivel a CPU nem 8 MHz-en fut, hanem ... te tudod mennyin.

SysTick->LOAD = time; helyett a time érték átskálázott értékét kellene beírni.
Pl. 32 MHz esetén 32/8 * time értéket kell betölteni.

SysTick->LOAD 24 bites, a maximális időzítést ez fogja korlátozni (az 1:8 leosztás miatt 1 s bele fog férni).

Sajnos, csak korlátozottan tudok segíteni, mert STM32-vel még nem sokat foglalkoztam.

A proci 72MHz-n fut.
Ha 9000000-t töltök be a SysTick regiszterébe,akkor működik az 1 másodperc, tehát a késleltetni szánt időnek a kilencszeresét töltöm bele,akkor kapok pontos időt.
Köszönöm a segítséget.

Sziasztok!
Valaki használt már HDC1080-as szenzort? Ha igen és megosztaná a rutinokat, azt megköszönném.

Ugyan ARM-hez nem értek de a szenzor adatlapján csak pár regiszter van (sietősen átnézve), amit I2C protokollal lehet írni/olvasni. Az I2C protokollal kapcsolatban van kérdésed?

Csak érdeklődtem, hogy hátha egyszerűsíteni tudom a dolgomat, de közben már megírtam működőképesre.

Viszont olyan kérdésem merült fel, hogy sikerült fordítva összedugni az SWDIO és SWDClk lábakat a programozó és a target board között. Azóta megszűnt a kommunikáció. Nem tudom írni, sem olvasni
Meghalt volna valamelyik ettől? Target proci vagy a programozó ? Egyéb ötlet?

Szerk: Sikerült kideríteni, hogy a targetboarddal van a gond. De mi lehet? A rajta lévő program fut, csak éppen hozzáférni nem tudok. Visszahozható az életbe?