Nekem ez van mindegyikre

Biztos eredeti a bluepillen a proci?

Van kettő, nem egy forrásból, ráadásul egyik hazai forgalmazótól. Az mindenképp eredeti és pont az van rádugva most.

Nos, valami ezzel az STM V2-vel van, ugyanis előástam egy 407-es discovery kitet a fiók aljából, amin jumperrel le lehet választani az SWD-t és valóban működik vele a debug mód, ha kivezetem a bluepillekre.
Az ebayes USB programozóban nem STM kontroller van, hanem valami tök más, az nem annyira kérdés, gondolom kinek milyen jut, vagy megy, vagy nem.
Viszont az STLINK V2-vel a discoverykitet se tudom csesztetni, ami eléggé eredeti és a sajátjával működik is.

Az SWD az debug protokoll, tehát a kínai klón is tudja.
Frissítettél firmwaret rajtuk?

Nekem ebay-es STlink V2 van, és simán frissítette a firmware-t rajta az STM32 CubeIDE. Ha nem ST proci (vagy olyan klón ami kompatibilis) lenne benne, akkor szerintem eleve sikertelen lett volna a fw frissítése, vagy nem működne a frissítést követően.

Mindegyiket frissítettm igen, a CubeIDE kéri is, amikor először elindítod egy régi verziós programozóval.

Egyébként még este feltoltam az STlink firmware-t egy sima bluepill-re is, ami szintén nem tud semmit SWD-n programozni, hiába kötöm össze egy másikkal. Az első screenshotot dobja a gyári eredeti STlink is, a bluepill is. A másik meg a működő a kitről.

Újabb, igen érdekes dologba futottam bele a bluepill-el kapcsolatban.

A történet ott kezdődik, hogy a forrasztóállomás fejlesztésekor egy baki miatt kinyírtam 2db BluePill panelen a processzort. Ezeket eltettem későbbre, hogy majd eldöntöm mi legyen velük, ugyanis másik procit venni rá drágább mint az új panel, viszont az legalább eredeti.

Aztán vettem az itt apróban STM32F101 procikat, baráti áron. Ezek annyiban különböznek a BluePill-en használt STM32F103-tól, hogy 72MHz helyett 36MHz a max órajelük, kettő helyett csak 1db A/D konverter van benne, és nincs USB. Egyéb tekintetben viszont láb kompatibilisek.

Egy barátom a rossz BluePill-ekre felforrasztott nekem ilyen processzort, így legalább ki tudjuk próbálni, van hozzá "fejlesztőpanel". Kiváncsiságból rátöltöttem egy BluePill-re készített programot és meglepetésre el is indult. De az igazi meglepetés ezután jött: mindkét panelen működik az USB is! Annak ellenére hogy ezen a processzoron elvileg nincs USB!

Ezután tovább kísérleteztem, és rátöltöttem az USB-s boot loadert. Az is működik! Most már lehet USB-n keresztül is programozni, Arduinoval!

Ez nem meglepő. Egy gyártó kevesebb fajta terméket gyárt, mint ahány félét árul. Az STM32 sorozatban is a legtöbb szolgáltatást nyújtó darabot gyártják, majd tokozzák akár kisebb lábszámú tokba. Ez sokkal egyszerűbb és olcsóbb, mint többfélét gyártani. Valamint a gyártáskor minőségellenőrzés végeznek rajtuk, és valószínűleg az alapján sorolják kategóriákba őket. Tehát legyártják az F103-t, és ha bukik benne az USB vagy nem stabil a működése 72 MHzen, akkor F101 néven árulják, ha a flash valamelyik szektora gyengébb, akkor kisebb flash mérettel árulják, stb. Te megveszed, rátöltöd az F103 programot és örülsz. Csak éppen senki sem garantálja neked, hogy hosszú távon normálisan fog működni. Példa erre a pendrive formátumú, olcsó ST-Link klón. Abban is F101 van az F103 helyett. Rendszeresen vásároltunk belőle, eddig nagyjából százas nagyságrendben. Kb a 25 százalékuk néhány használat után megdöglött. Egyszerűen debug közben elszállt bennük az USB, nem érte őket semmilyen sokk. A legtöbb programozható maradt ugyan, de az USB periféria röbbé nem működik. De olyan is van, amelyik az első néhány percben működik, aztán melegszik, és megáll. Az a 72 MHzet nem bírja.

És esélyes, hogy a 128kB flash is működni fog benne.

Az ST-Link util detektálja a flash méretét, és 64k-t ír ki.

Akkor a kínai BluePill modulokon is ilyesmi lehet, mert kb a felén nem megy az USB.
Viszont ha jó szériát fogtam ki a prociból, akkor lehet, hogy mindegyik jó lesz F103-nak is?
Majd nyúzom a jelenleg használatba vett két MCU-t, hogy sikerül-e kinyírni.

Az ST-Link annyi flash-t detektál, amennyit a chip mond magáról (vannak kitüntetett ROM tartalmak amik a chip azonosítója mellett a tartalmazott flash méretét mutatják). Ettől függetlenül programból simán írható lehet az állítólag nem létező második 64kByte is.

Igazad van, fél év után most vettem észre, hogy már kezdetektől fogva a másik 64k-s részt írom a szoftverből...

Ez csak most tűnt fel: Megkérdezhetem mire kellett 100-as nagyságrendben ST-Link?

Ja és még egy kérdés felmerült bennem. Előfordulhat, hogy az F105 procikban is ugyanez a chip van? Tehát elképzelhető, hogy pl. a "nemlétező D/A konverter" is életre kelthető mondjuk egy F101-es feliratú MCU esetében? Vagy mondjuk egy BluePill-en? Vagy az már más széria?

Eredetileg az volt a tervem, hogy a BluePill mintájára készítek néhány fejlesztőpanelt az STM32F101 procihoz (mivel mint említettem vettem néhány darabot baráti áron). De kiderült, hogy eddig kivétel nélkül mindegyik megy 72MHz-en, mindegyiken megy az USB, és úgy tűnik, hogy a 128k flash is benne van mindegyikben, ahogy benjami is említette, így gyakorlatilag ugyanúgy használható mint a BluePill. A neve pedig: eredetileg fehér panelt szerettem volna de bizonyos okokból zöld lett - de talán készül majd fehérben is.

Ugayn, a panel színe legyen legnagyobb gondod. Addig is nevezheted "GreenPill"-nek.

Van nagyjából 10 fejlesztőnk, mindegyik kapott eddig több darabot. Részben azért, mert néha megdöglenek a klón ST-Linkek. Másrészt azért, mert elosztott rendszert fejlesztünk, kommunikációs hálózaton lógnak az eszközök. Mindegyiknek más a funkciója, közös protokollal. Egyszerűen macera folyton átcsatlakoztatni a debuggert egyikről a másikra. De előfordul olyan is, hogy egyszerre három eszközt párhuzamosan single step debuggolunk. Szerencsére jól támogatott a több MCU kezelése, ST-Link ID alapján tudja az IDE, hogy melyikre kell feltölteni.
Innen a több tapasztalat. Eredeti ST-Link V2 és V3 sosem halt még meg attól, hogy bedugtam az USB-be, ahogy az általam készített F103 alapú klón sem. Az F101-es klónok viszont néha elhullanak szimplán attól, hogy bedugom az USB-be, pedig még target sincs rajtuk.

Üdv Mindenkinek!
Valakinek sikerült már STM32 alatt beizzítania ezt a fajta kijelzőt? Már több, a neten található inicializáló szekvenciát próbáltam, de egyikkel sem sikerült beindítani. Arduino alatt megy, de az onnan átvett inicializáló menettel sem működik.
Van rá eshetőség, hogy esetleg egyébb gond van, de talán nem nagy eséllyel. Elözőleg sikeresen megbírkóztam az ILI9341-el és az ST7735S-el. Ennek ST7789 a drivere.

Sziasztok!
Bele futottam egy érdekes hibába.
Timer 4 és 2-t encoder módban használom.

#define PPR 5000

Timer4.setMode(1, TIMER_ENCODER); //set mode, the channel is not used when in this mode (but it must be [1..4]).
Timer4.pause(); //stop...
Timer4.setPrescaleFactor(1); //normal for encoder to have the lowest or no prescaler.
Timer4.setOverflow(PPR); //use this to match the number of pulse per revolution of the encoder. Most industrial use single channel steps.
Timer4.setCount(0); //reset the counter.
Timer4.setEdgeCounting(TIMER_SMCR_SMS_ENCODER3); //or TIMER_SMCR_SMS_ENCODER1 or TIMER_SMCR_SMS_ENCODER2. This uses both channels to count and ascertain direction.
Timer4.attachInterrupt(0, Timer4Irq); //channel must be 0 here
Timer4.resume(); //start the encoder...

Reset után PPR-nél nem áll 0-ra és a megszakítás se fut le, hanem elmegy 65535 ig.
Az eredmény se jó, olyan mintha nem számolna minden inpulzust.
Itt a megszakítás lefut és kezdi 0-tól.
Ezután viszont rendben működik. Ha visszafelé tekerem az encodert, akkor rendben PPR-től
számol visszafele.
Mi lehet a hiba oka?
Az nem megoldható hogy bekapcsolás után körbetekerem az encodert.
Köszi Szabolcs

Minek kell egyáltalán timer az enkóder kezeléséhez? Megszakításból is simán kezelhető.

A megszakításnak is van költsége. Context switch, stb. A timer periféria pedig fel van készítve arra, hogy a CPU nélkül is tudja, merre mennyit tekerték az enkódert. Egész egyszerűen hardveresen számolja az impulzusokat. Egyik irányba növeli, másik irányba csökkenti a számlálót. Nagyon kényelmesen lehet így encodert kezelni.

A megoldás egy Timer4.refresh(); sor berakása lett.
Érdekes mert az encoderes minta programokban nincs ilyen.
Megszakításból kezelni azért nem akartam mert egy fordulatra 115 200 élt kell számolni,
és a lépés tévesztés nem jó. Ezen kívül több idő érzékeny feladata is van a kontrollernek.

Sziasztok

Arduino után gondoltam kipróbálom stm32 blue pill-t. Vettem hozzá egy stlink debugger programozót . Bekötése GND-GND, 3,3V - a másik széle, SWDIO(4)- +3.3V mellett a pillen, SWCLK(2)-GND mellett a pillen. Addig minden ok hogy CP2102 driver fent van , látja a gép az eszközt. Az eszközök -> alaplap STM32F1 boards -> Generic STM32103C series van beállítva, Variant STM32F103C8 (20k ram , 64K flash) , Upload menthod: "STLink" , CPU speed(MHz): "72MHz normal" , Optimize "smallest (default)" , Port: "COM3" . Állítólag a jumpert ilyenkor nem kell rakosgatni sehova de még a blink programot sem tudom feltölteni. Mit nem csináltam jól?

ST-Link driver fent van? USB eszközök között látszik?

Igen.

Nincs rx tx led és nem látom ha feltölti a programot.

Milyen Rx/Tx LED? Ez nem soros port.

Mi a hibaüzenet?

Nincs hibaüzenet . Csak beállítottam hogy delay(10000); ig várjon de csak a gyári gyors villogást hajtja végre ami kb delay(300);