Ez a típus (se intl piacra STLink, se kínai piacra gyártott STLink) nem fog tápod adni, hiszen 1.65V-tól 5.5V-ig level-shift a kimenet, azaz érthető okokból nem is adhat tápot, hiszen neki a céláramkör tápfeszültségéhez kell illesztenie az IO jelszintjeit, ezért az ő VCC-je valójában bemenet. És ez így korrekt is

A kínai pendrive klónok adnak tápot, de ők 3.3V-os fix kimeneti jelszinttel dolgoznak.

Kösz, mindezt én is tudom. Pont ezért kérdeztem vissza. Mert úgy tűnt, hogy az eredeti kérdező nincs ezzel tisztában.

Uhh bocsi. Igen, az általad írt linkre reagáltam, de nem a hozzászólásodra kellett volna címeznem a választ

Köszönöm a válaszokat!
Igen, olyan fajta ST-Link. Vásárolnék pendrive St-link-et is, de arról azt hallottam, hogy selejt STM ICből keszülnek és az USB részükkel vannak gondok.
Számomra meglepő volt az, hogy logikai analizátorral nézve megvolt a magas jelszint (mármint amit annak érzékelt a szintén kínai Saleae klón), de mégse ment akárhogyan próbálkoztam. Azzal egyidőben rendeltem új STM8S-et az egyik CAN nyákhoz, (mert azt hittem hogy tiltva van a programozás mint pl. az atmegáknál) és három darab STM8S003 vagy STM8S103 fejlesztői nyákot (0.60 euró volt darabja), amikor összekötöttem, akkor láttam, hogy a ledek nem világítanak rajta és amint adtam tápot az USB dugaszba, egyből égtek a ledek és ment a programozás is.
A CAN nyákokra tápot adva kiírja, hogy MCU is protected. A következő lépés a védelem levevése lesz.

Kár, hogy az STMCube nem támogatja az STM8-at. Kezdőknek (akik nem szeretnek külsò IDE-t beállítani és megelégednek azzal is ha notepad++-al tudják szerkeszteni a forráskódot) melyik fordító ajánlott?

ST7 sorozattal játszott már valaki?

Ez így van. STM32F100 van bennük, amikben a specifikáció szerint nincs USB periféria. Gyakorlatban pedig van, és vagy működik, vagy nem. Nekem nagyon tetszik a 2 dolláros ára. Vettem 20 darabot, és minden projektemen fixen rajta is hagyom. Eddig kb 3 halt meg.

STM8-at nem használnék, hacsak nem milliós tételben akarsz gyártani valamit, ahol minden fillér számít. Nincs hozzá se GCC, se más C++ fordító. Van ST Visual Develop IDE, ami borzalom. Fordítónak meg Cosmic C és SDCC. Ennyi. Próbáltam, nem jött be. Maga az MCU nem rossz, de a szoftveres környezet borzasztó. Ezzel szemben például az AVR némely területen gyengébb, mégis szívesebben fejlesztek rá, hiszen ott az Atmel Studio és a GCC.
Az ST7 ráadásul ősrégi, már nem fejlesztett termékvonal.
Ja, és ez itt OFF, mert egyik sem ARM, hanem valami saját 8 bit architektúra.
Az STM32 ráadásul alig kerül többe, egy-egy darabnál nem számít, és sokkal többet tud. Van hozzá számtalan ingyenes IDE, és GCC fordító is.
Összegezve: Hacsak nem muszáj, nem kezdenék el egy régebbi dolgot tanulni, és használni.

Amit keresel, azt úgy hívják, hogy STM8CubeMX. Mondjuk kódot azt nem fog neked generálni, mert olyat nem tud.

STM8S103F3P6-hoz tökéletes az IAR Embedded Workbench for STM8 ingyenes változata (méretkorlátos ugyan, de az MCU-nak sem több a memóriája).

Van benne C++ compiler, ez jó. De a 8 kB az elég kevés.

Ha ennyi erőforrás kevés, akkor használj STM32-t!

Sziasztok,

32H7. Keszitettem nehany merest es az integeres FFT ez alapjan gyorsabb mint a float ( FPU-val ). Hogy lehetseges ez?

2048 point fft
q31 560 us
float 3 ms

4096 pt fft
q31 ~ 2 ms

Én szinte kizárólag azt használok. Munkához és hobbihoz is. Nekem bejött, hogy sokféle MCU van a nagyon kicsitől a nagyon nagyig, a kód jól hordozható, és vannak jó fejlesztőeszközök is.

Rendben, kifogok próbálni egy pendrive programozót is.
STM8-ra azért szeretnék fejleszteni (egy nagyon kicsike programot), mert van belőle egy csomó kész nyák, amiket egy biztonsági hiba miatt kellett lecseréljek.
ST7-et autóipari dolgokban láttam, de mivel ahhoz 0 támogatás van, ezért nem foglalkozok vele.
Fogok játszani az STM8CubeMx-el, a IAR-t is kifogom próbálni, STM8-ra kb. led villogót meg egy egyszerű CAN buszos programot szeretnék írni.

Nagyon szépen köszönök mindent! További sok sikert mindenkinek a fejlesztésekhez!

Én az STM8-cal assemblyben próbálkozom. Ehhez teljesen jó az STVD-STM8. Egy nagyon kicsike program így is összehozható. Egyébként az STVD az ST7-et is tudja. Az STM8 programozási leírásai általában az ST7-t is leírják.
Még egy; STM8S003-t csak sorozat égetéshez érdemes venni, nem pedig fejlesztéshez, mert csak 100 flash írás garantált, egyébként meg ugyan azok.

Nekem megy a blue pill ST-Linket használva minden külön táp nélkül, szóval nem értem mihez kell táp.
(Most csak sima pin headerrel van összekötve ami hosszabb is, 10->12, hogy ne lötyögjön, amíg nem jön meg az IDC20-as csatlakozóm).
Egyébként Linux (Wine) alatt futó EmBitz.

Ha nincs a lábakon (I/O) semmi, akkor a belső felhúzókon és védődiódákon keresztül tud annyi energiához jutni a programozón keresztül, hogy arról még épp elfut. De ez az erős néha, és "egyes esetekben" kategória. Használni így semmiképp sem ajánlatos, mert elkóborolhat flash írás közben, ha nincs stabil tápja.

Ha a programozó 19-es pinjét (másik szélső mint ahol most a piros van) kötném a panel 5V feliratú pinjéhez?

Sziasztok,

LTDC, 1. layer OK, a 2. layer framebufferebe betoltott szin nem jelenik meg. A leyer hatterszine igen.
Alpha0 = 0, Alpha tobb ertekkel kiprobalva. Valakinek van otlete ezzel kapcs ?

Lay 2 framebuffer: Flashbol olvassa, RAMbol nem.

Sziasztok,

Valaki nem tudja veletlenul hol talalnek egy egyszeru DMA2D -vel megvalositott szovegmegjelenites peldat ? TFT mukodik csak egy peldat sehol nem talaltam szoveg megjelenitesere. Udv.

Sziasztok,
Szeretném a github-on lévő egyik projektet:
https://github.com/rene-dev/stmbl
"átemelni" Eclips-be, vagy valami hasonló barátságosabb környezetbe, mert a Linux nagyon idegen számomra.

Valaki esetleg próbálkozott már hasonlóval?
Vagy ha lenne valakinek javaslata, megköszönném.

Üdv.

A stringek pontjait karakterenként kel össze szedni, ezt a DMA nem tudja.
Pláne ha még Szinezni is kel a pontokat, pontonként 16 bits, összerakni.

Szerintem nem éri meg 16 – 32 Byte-ról van szó karakterenként?

Egy ötlet.
Készítesz a drawChar-nak módosított változatát, hogy egy tőmbe pakolja a pixeleket.
Azt a tömböt már könnyen kiküldheted DMA2D-vel egy ablakba.

Erre is van példa, amin csak keveset kel faragni:

Min ezt itt megtalálod: Bővebben: Link
Keres rá! :\STM32Cube_FW_F4\Projects\STM32F429I-Discovery\

TrueStudio-val (eclipse alapú) lefordíthatóak saját makefile-os projektek (és debugolhatóak is). Annyi feladatod lenne, hogy toolchain.mak fájlt rendesen felkonfiguráld (hol vannak a különböző eszközök a gépeden, pl. python), illetve a nem támogatott linux parancsokat átírd windows kompatibilisre a makefile-ban.

Mintának itt egy saját projektem, ez működik windows alól és makefile-os (pár külső könyvtárat kell letölteni, amelyeknél nem voltam biztos a terjeszthetőségről ezért inkább nem tettem bele direktben). A projekt különlegessége, hogy mind ARM-ra, mind windowsra lefordítható a kód és így a grafikus felület módosításait sokkal gyorsabban tudom tesztelni (nem kell állandóan felírni a mikrokontrollerre).
https://github.com/csatti/SolderingStation

Hardverből minden megy.

Definiálsz egy ablakot a TFT-ben, egy tömbbe feltöltöd a pontokat, utána DMA.

Én még a 90/180/270 fokkal elforgatott több soros szövegeket is DMA-zom. Csak meg kell adni, hogy honnan hová milyen irányban csinálja.

A legtöbb TFT okos, képes ezekre.

Akkor egyet értünk!

Mert én is ezt javasoltam, még azt is megadtam, hogy melyik rutinokat lehet a legkönnyebben átírni a célra.

Bár még nem csináltam meg magamnak. Szerintem nagyon memória pazarló megoldás lenne!
Vegyünk példának 16*24 pixeles karaktert 16bites szín mélységet, 16 karakteres stringet: 16*24*16=6140*2Byte.
Megtérül ez a gyorsaságon?

Még kel a SD-nek is 2*512Byte

Megtérül. Ilyen teljesítményű mikrokontrollereknél már érdemes úgyis RTOS-t használni, illetve dinamikusan allokálni az ilyen ideiglenes memóriaterületeket.

Az előző hozzászólásomban linkelt projektnél például az összes grafikus elem automatikusan egy pixelmap-ra rajzolódik (memóriában allokált puffer). A képernyőfrissítésért egy dedikált task felel. Amikor elkészülnek, bekerülnek egy sorba. A program pedig a következő elem megrajzolására vált. A sor kezelését egy másik task végzi. Amikor a DMA végez az aktuális feladattal (itt is van egy plusz absztrakciós szint, a grafikus "driver" szintjén), a sorkezelő task felébred, felszabadítja az előző feladat memóriaterületét, kiveszi a következő elemet a sorból majd kiküldi a képernyőre, ezután elalszik. És így tovább. Ezzel a módszerrel olyan sebesség érhető el, egy "vacak" SPI-os TFT-vel is, hogy gyakorlatilag nem látszik a képernyőfrissülés.

Nézegettem a projectedet.
De sajnos linuxos, ahhoz pedig nem értek. (És már vén vagyok, hogy megtanuljam!)

Linuxos? Hát ezt honnan vetted? Az egész projektet windows alatt fejlesztettem.

Teljesen más szerkezete van, mint amit az ST oldalain találunk. Vagy amit a C_MX generál.
Ezért gondoltam, hogy linuxos.

Annak semmi köze az operációs rendszerhez. Nem nagyon rajongok a cubeMX által generált kódért, jobb szeretem tudni mi az, ami tényleg történik. Ettől még ez a kód is az ST LowLayer HAL-ját használja.

Egyébként ha átnézed az ST által készített demó projekteket, legalább 10 féle stílusban készültek.