Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
STM32 uputstva za iskusne početnike
#21
+1za CLion
i generalno za JetBrains alate
korisito sam i Rider (za C#), a svakodnevno koristim PyCharm tako da mogu reci da nista nije ni blizu po kvalitetu
Reply
#22
(12-22-2020, 11:41 PM)mikikg Wrote: Da, CLion je vrlo dobar alat.

Na primer radio sam razvoj prakticno na 4 RPi-a odjenom (imam rsync komande), nekakav GUI/touch pa povezan preko LAN/ETH u sklopu jedne masine, veruj mi da mi je svaki od programa koje sam pojedinacno pisao imao 2 do 3 C++ skripte izvornog code-a, bukvalno toliko, nikakave dubioze sa nekim glomaznim stvarima, probrao sam dve bitne stvari i to su OpenCV za grafiku i RayLib koji je isto dobar za crtanje po ekranu i oba odlicno rade na x86 i na ARM sto je prelepa stvar, pokretao ga na PC ili RPi isto radi, to je glavna caka, koristim ceo IDE i par tih biblioteka i prvo programiram na PC-u (macOS, Linux, Win) i tu skockam ceo program i ekrane (sa buttonima i ostalim stvarima), prevodjenje radi u sekundi, debuger radi, skockas sve sto treba i onda samo kada ti treba bildujes isti program za ARM i proveris malo, utegnes i popravis ako ima razlike (uvek ima po malo) i to je razvojni proces koji pokriva bukvalno dve platforme o istom trosku i traje krace nego da si pisao samo za jednu platformu i losim alatima.

Takav razvoj zvuči stvarno fantastično, i svaka tebi čast, kad sve to stižeš!
Meni nedostaje svaki dan bar još 8 sati u danu, da stignem sve što bi trebao... a bavim se samo razvojem hw i fw u C-u...
Nisam stigao ni do C++ ni do ARM-a, evo do sad...
I sa RPi bih se vrlo rado pozabavio, jer mi baš zatreba u nekim projektima, samo ne znam kad...
Imam firmu od 1997.god. i vrijeme mi je od tada najkritičniji resurs u životu... Smile
Reply
#23
Zato su ovi alati "produktivni", skracuje vreme potrebno za razvoj, i ovde je bitno napomenuti da pricamo o ARM Cortex-A arhitekturi koje su zgodne za cross-compile sa x86 (X64).

ARM Cortex-M je slicna ali ipak razlicita arhitekura i ona moze samo sa simulatorima da se pokrece na x86 i da kazemo u sustini da nije predvidjeno da se tako pokrece.
Program preveden za Cortex-M mora da se pokrece na fizickom procesoru (MCU) sa dodadatim JTAG/SW kanalima za programiranje i debug.

I tu dolazimo do glavnog pitanja, da li da se "mucimo" sa low-level i MCU i limitiranim resursima i da svoje vreme trosimo da to napravimo ili da uzmemo Cortex-A sa Linux i da to "skockamo" brzinski i zavrsimo posao? Smile

Ima naravno mesta gde MCU ne moze da se izbegne i ne treba ga izbegavati, treba ga upotrebiti tacno kada ima potrebe za specificnu stvar a sve ovo ostalo prebaciti na Linux i teraj do mile volje ...

---

PS: na primer za spomenutu masinu sa 4 RPi-a (4 touch ekrana sa razlicitim funkcijama) svima nama u ekipi je bilo mnogo jednostavnije da se uhvatimo ARM-a i gotovih RPi pocica bez obzira sto je na prvi pogled skuplja HW varijanta, zamisli samo da sam imao 4 MCU-a i da sam sve morao ponaosob da programiram/flesujem, da uskladim sa ostalim u mrezi, pa ja to mozda nikad nebi ni zavrsio, to bi mi pojelo vreme i ceo posao bi se prolongirao, pa PCB, pravi HW, ovo-ono, nije bilo sanse da izguram posao a da sam koristio Cortex-M umesto Cortex-A i na kraju je sve to kostalo manje i oduzelo manje vremena nego da sam se mucio sa MCU.
Imamo i MCU u masini, STM32F407 i on radi stvari zasta smo ga predvideli i kolega je radio na njemu nezavisno od ovih mojih stvari, samo smo se dogovorili oko protokola razmene podataka i to trenutno radi odlicno, zavrsili smo posao, oziveli smo masinu koju niko pre nas u predhodnih 7 godina nije mogao da zavrsi, prosle razne ekipe elektronicara i programera ... dok nisu nasli "ozbiljnu" ekipu Wink
Reply
#24
(12-22-2020, 11:42 PM)npejcic Wrote: Generalno, jesam zadovoljniji STM32 programatorima i debagerima u odnosu na PIC i PicKit3/4. Kad ST-LINK radi, radi kako treba.

Ja imam još jedan veoma glup problem sa progamatorom STM32-ki, u pitanju je neki treći računar laptop niže klase... recimo da je malo sporiji.
Probao sam i STM32 ST-LINK Utility i novi STM32 Cube Programer, probao sam dva hardverska programatora, dva različita uređaja koje programiram, ali sa tog laptopa nema šanse da se isprogramira. Detektuje STM32 uredno, ali kad krene da programira nikako... Probao da menjam frekvenciju programiranja ali ništa.

Isti HW setup na drugom PC računaru bez problema odradi. Tako da može da zavisi i od PC računara, što mi je totalno "suludo" u toj meri da postoji problem.

A cena programtora kod STM32 je zaista neverovatna, kineski klonovi od 1.9$ rade izuzetno dobro. Imam ih po par komada na svakom stolu Smile

Da odgovorim samom sebi Smile

Rešena misterija sa ovim laptopom.
Problem je bio u napajanju laptopa. Kada je laptop na punjaču, nije moguće isprogramirati STM32. Uredno ga detektuje i čita. Ali programiranje nikako.
Punjač za laptop nije originalni nego neki univerzalni. Verujem da dosta šumi i otud problemi sa STM-om.

Rešenje je da laptop radi na baterije dok se programira MCU.
Reply
#25
(12-24-2020, 11:59 PM)npejcic Wrote: Rešenje je da laptop radi na baterije dok se programira MCU.

Ili da mi kazes koji ti punjac treba.
Novac je sredstvo a ne cilj.
Reply
#26
@Gosha
Hvala na ponudi.
Priča je mnogo kompleksnija Smile Odredio ja korektan budžet da naš tehničar ode i kupi original punjač (to mu dođe kao redovni servis za automobil), ali on je bio uporan da popravi neki buck-boost univerzalni i to je na kraju uspeo. Eto, ova mala nuspojava malkice kvari ugođaj, ali dok god postoji ambicija kod nekoga ja je ne kvarim Smile
Reply
#27
Ajde, bar nekakav napredak!
Svakog dana, u svakom pogledu.... Smile

Sinoc uzmem da probam ove ST-Link v2 klonove na jos 2 druga racunara, na kojima je Win10, i ni jedan ga ne vidi uopste, cak ni u Device Manager-u nije uredno prijavljen...

Ocito je neki zajeb sa drajverima, ali skidao sam zadnju koju nadjoh, verziju 9 ST Link Utility-a, a ova koja mi radi na Win7 je v4.0.0.
Reply
#28
Sad se ispostavilo i da ovaj jedan ST-Link koji sam sinoc spajao na Win10 nece vise da radi ni pod Win7 (ne prepoznaje ga sad ni on u Device Manager-u)!

Nisam mu bas nista radio, jer nisam ni mogao, sobzirom da ga Win10 nije ni prepoznao.

Drugi, koji nisam spajao na drugi racunar i Win10, radi i dalje uredno, bar iz IAR i ST-Link Utility-a, kao sto je i radio.

Ljudi moji, ovo već počinje da me nervira...
Reply
#29
Da li si probao da ponovo dodaš STSW-LINK009 driver? Imaš li ga na tom računaru?
Reply
#30
Jedno moje rešenje a situaciju sa "STLink not detected".
Ustanovio sam da mi se to dešava kad ga na WIN10 u Device Manager-u imam dodatog na "Ports (COM & LPT)"
Nakon toga odradim desni klik na njega -> Update Driver Software -> Browse my for driver software -> Let me pick from a list ... i odaberem ovaj sa sl.1.

Nakon toga je STLink smešten u Universal Serial Bus devices (sl.2)

Radi se o jeftinom klonu kitajskome a možda nekom pomogne... Kod mene prolazi za sada uvek.


Attached Files Thumbnail(s)

Reply
#31
(01-29-2021, 11:53 AM)gorankg Wrote: Jedno moje rešenje a situaciju sa "STLink not detected".
Ustanovio sam da mi se to dešava kad ga na WIN10 u Device Manager-u imam dodatog na "Ports (COM & LPT)"
Nakon toga odradim desni klik na njega -> Update Driver Software -> Browse my for driver software -> Let me pick from a list ... i odaberem ovaj sa sl.1.

Nakon toga je STLink smešten u Universal Serial Bus devices (sl.2)

Radi se o jeftinom klonu kitajskome a možda nekom pomogne... Kod mene prolazi za sada uvek.

Kod mene nije bio takav slucaj, ali sigurno ce nekom koristiti.
Mene je izgleda zazao jedan od 3 STLink-a koja imam, jer je nešto on sam bio problematičan. Vjerovatno IC u njemu, jer su i oni kopije, pa mnogi prijavljuju da imaju probleme, naročito u debagiranju.
Čak sam nabavio iz Mouser-a 2 kom. STM32F103, da mogu zamijeniti onaj na BP pločici, ako počne da se čudno ponaša.
Ako zamijenim i onaj u STLink-u, gdje se može naći hex koji treba upisati u njega?
Reply
#32
Uz ogradu da ovo nisam probao evo linka:

https://github.com/dltech/stlinkv2

Ako ti prođe, javi.
Reply
#33
U firmi imamo tradiciju da pomažamo zainteresovanim studentima Elektronskog Fakulteta u Nišu da urade obaveznu praksu u sklopu studiranja. Podrazumeva se da forsiramo mikrokontrolere jer je oblast široko primenjiva, dok sa druge strane na samom fakultetu se kasni sa trendovima jedno 15 godina (čitaj 150 godina u našoj branši). Nakon jednog takvog druženja sa Nikolom Mitrovićem, nastavio je "druženje" sa ARM mikrokontrolerima, u međuvremenu je doktorirao i sada je predavač na fakultetu. Na našu preporuku da su ARM mikrokontroleri prilično popularni (zasluženo), Nikola je krenuo da radi sa njima i kao jedan naredni korak nastala je knjiga koja je namenjena početnicima sa STM32 ARM mikrokontrolerima. Obrađuje Nucleo razvojne ploče i Keil razvojno okruženje. Njegov rad nesebično deli sa studentima, a ja sam dobio odobrenje da je postavim i ovde za sve nas.

Knjigu možete preuzeti sa ovog linka:
http://www.epraktikum.iz.rs/sharing/Prak...uzenja.pdf
Reply
#34
@npejcic

Sve pohvale za ovu knjigu!
Koliko pratim ovo je prva knjiga na srpskom jeziku koja se bavi konkretno STM32 mikrokontrolerima.

Samo napred, voleo bih da vidim ovu knjihu i u stampanom izdanju ...
Reply
#35
Za koji dan mi stiže iz JLCPCB moja prototip pločica na kojoj treba da radi STM32L071RBT6 (128k Flash, 20k RAM).
U pitanju je RF daljinska kontrola, ali se traži da ima i 'sun readable' kolor displej, a baterija da traaaaje Smile
Zato sam ostavio opcije na pločici za više vrsta displeja, da napravim bar 2 verzije, pa da se donese konačna odluka.

Prvi je klasični 3.5" TFT LCD (ER-TFTM035-6 modul), 320x480, sa ILI9488, jer ih vec imam na stanju.

Druga opcija, koja se uklapa u gornje zahtijeve, je E-Paper (E-ink) displej, pa sam nabavio i ER-EPD027-2, 2.7", 176x264, sa EK79651AB, Red/White/Black color. On bi vjerovatno bio najbolje rješenje, ako ne bude prespor! Ne planiram raditi ništa posebno, pogotovo ne animaciju, pa ćemo vidjeti...

Osim ovoga, nabavio sam još i ER-TFT043A3-3, 4.3", sa ST7282, koji jeste 'sun readable', ali podržava samo paralelni mod rada, pa ga za sada ne planiram koristiti, jer nemam pinova za to. Osim toga takav zahtijev i dugo trajanje baterije neće ići baš zajedno.


E sad, glavno pitanje, koje me muči - kako i sa čim pokrenuti te displeje, u SPI modu ?

TouchGFX su ljudi na net-u prilicno ispljuvali, bar u v15, mada je sada v17 aktuelna, i koliko vidjeh ugl. je to namijenjeno za jače MCU namijenjene za rad sa displejima.

Vidjeh u porukama, od ranije, Mikijevu preporuku za LVGL, i to mi se čini interesantno, mada mi još nije baš jasno kako početi i sa tim, tj. kako povezati tu biblioteku sa konkretnim displejom, odnosno čipom ? Da li ja moram naći ili napisati taj sloj 'drajvera' koji će biti ispod te biblioteke, ili ... ?
Priznajem, nisam baš čitao dokumentaciju, koje ima dosta, ali prvo bih volio riješiti pitanje u kom smijeru uopšte ići dalje? Što se tiče memorijskih zahtijeva, nadam se da se tu uklapam sa ovim MCU.
 
Možda ima i još jednostavnijih rješenja, jer za sada mi ne treba ništa posebno... 2-3 fonta, malo nekakvih menija i sličica tj. ikona itd. (toch se sada neće koristiti za ulaz, nego obični tasteri koji postoje na uređaju), tako da su zahtijevi minimalni, ali opet, kad već radim, možda je bolje koristiti nešto sa čim ću moći raditi i sljedećih godina...
Reply
#36
LVGL biblioteku je preporucio Nebojsa za STM32, tu kombinaciju nisam jos probao, LVGL igrom slucaja koristim na poslu za neki embedded uredjaj ali sa PowerPC jezgrom i Linux 2.x kernelom.

Uglavnom, svako kacenje displeja vece rezolucije od recimo 300x200 i to crno/bele treba preskociti sa Cortex-M jezgrom jer to nije za to napravljeno i predvidjeno, za to treba Cortex-A jezgro i lepo pod Linux-om da se to tera, recimo Raspberry Pi Zero i tome slicno.
https://forum.yu3ma.net/thread-2589-post...#pid114459

Zahtevna je grafika pre svega sa memorijimom pa posle sa osvezavanjem, samo liniju od 300px da nacrtas moras bar 300 komandi da prosledis preko SPI porta, mora da se crta sve pixel po pixel, iz biblioteke ovako ili onako na isto se svodi, svaki element na ekranu mora da se iscrta pixel po pixel, TO JE KADA SE TERA CORTEX-M kao graficki procesor sto to naravno nije.

Druga varijanta je displej sa na primer RA8875, taj ekran na sebi vec ima svoj graficki kontroler i memoriju i njemu na primer mozes da kazes "nacrtaj liniju 300px" kroz jednu komandu i to je vec druga prica, ima svoj Font EEPROM i generalno to je ekran sa grafickom karticom i onda moze da se oslobodi glavni MCU dosta i da to radi pristojno.

Opet kazem, Raspberry Pi bilo koja varijanta je super za grafiku i imas Linux ispod sto sve olaksava, 60FPS na matorom RPi 2 radi bez problema, ovi noviji tek kidaju, to kada budes dosao do Vertex i Fragment shader-a tek da vidis kako to radi ...
Reply
#37
Mislim da nećeš moći ni TouchGFX ni lvgl. Na tom STM-u si tanak sa RAM-om i FLASH-om a za TouchGFX nemaš ni display driver.
Baci pogled na U8g2 možda to može da ide.

Greška, nisam pazio na času. U8g2 je monochromatic. Znači zaboravi i to.
Ja sam lvgl portovao za STM32F407 onako radi probe. Nije testirano ništa samo nešto osnovno poterano da radi.
Reply
#38
Moja topla preporuka je LVGL, koji je napisala i razvija sa čestim nadogradnjama jedna veoma mala ekipa, ali koja je problemu pristupila veoma profesionalno. Iako je projekat na početku bio "one-man-show", ubrzo je pobrao odlične utiske i dosta velikih proizvođača ga je podržala svojim finansijama (između ostalog i ST). Za razliku od glomaznog i zahtevnog TouchGFX (imali su i oni skorašnje pokušaje optimizacije). Meni lično je LVGL zaista "legao". Veoma jednostavan i jasno dokumentovan sa dosta ljudi koji mogu da pomognu u implementaciji. Pogledaj na sajtu imaš uvodni i kratak tutorijal kako krenuti. Potrebno je da sam ubaciš drajver za tvoj kontroler na LCD-u, i kroz dva poziva za iscravanje jednog piksela povežeš ga sa LVGL engine-om. Recimo da ti je dovoljno par sati za taj deo. Rekao bih lakši deo. Javi ako je potrebna pomoć da ti pronađem taj deo dokumentacije, ali mislim da ćeš se brzo snaći.

Moj neki minimalni sistem koga sam testirao sa LVGL, a da to lepo radi do 480x320pix (ILI9841) je sa mikrokontrolerom STM32F407VG. Ispod toga ne treba pokušavati. Nije problem samo memorijski resurs veći komunikacioni, SPI je spor. Konkretno u ovaj sistem sa STM32F407VG je stao bitmap splash screen i dosta dugmića, sa par skrinova i malih bitmap ikonica. Takođe u isti MCU sam "ugurao" i kompletan LAN (lwip stekom) sa HTTP podrškom. Uspeo sam uz dosta truda i pokušaja da nateram ovaj TFT LCD da fluidno radi sa SPI, ali usko grlo je SPI magistrala koja za ovu rezoluciju, ipak, vapi za paralelnim interfejsom. Inače bez DMA, to ne radi nikako, ali baš nikako. U jednom trenutku sam mislio da odustanem i pređem na neki paralelni. Uz dosta truda i tvikovanja uspeo sam, ali ne bih ponovo išao tim putem.

Pametan potez kod LVGL je optimizacija algoritama za low-memory footprint, mislim da ja ne koristim više od 8kBy RAMa u mom projektu, jer render radi samo u okruženju samog objekta koga menjaš dok ostatak piksela ne dira, pa je i samim tim memory footprint manje zahtevan iako 460.8 kBy za celu površinu displeja zastrašujuće zvuči (480pix x 320pix x 3By color).

Ono što ostaje i dalje kao veliki problem, je dosta pešačenja i igranje sa iscrtavanjem koječega po displeju i sam raspored objekata. To znam da je ekipa iz LVGL skoro publikovala u obliku nekog editora, ali nisam koristio. Pre dve godine kada sam radio na projektu toga nije bilo, već onako kodiranje na nivou mapiranja piksela ručno... Hiljade pokušaja i razmrdavanja objekata da sve uklopim. Možda sam i zbog toga napravio ovoliku pauzu, smučilo mi se Smile Smile Smile

Kao što Miki reče, ako hoćeš eleganciju i jednostavno iscrtavanje objekata, ipak ići na neku moćniju "mašinu". Pre par meseci sam imao prilike da vidim STM32H seriju kako radi sa TFT displejima pod TouchGFX i to razvaljuje, kao od šale radi render 3D objekata, fluidno, odziv momentalan. Ali imati u vidu da se pritom isključivo koristi neki specijalni LCD/TFT interfejs sa raznoraznim akceleracijama koji postoje u STM32F4 i jačim.

Za tvoj STM32L071RBT6 bojim se da ćeš morati da radiš sa još nižim nivoom pristupa, direktno rutine za prikaz bitmape i jednostavniji objekti koje ćeš ručno da crtaš. Previše je slab taj mikrokontroler za ove stekove kao što su LVGL ili TouchGFX. Testirano na STM32L082KZ, gde je iscrtavanje pixela bilo vidljivo golim okom Sad

Što se tiče drajvera za tvoj kontroler ILI9488, uz neke minimalne prepravke oko inicijalizacije displeja, možeš koristiti rutine od ILI9341. Ovde ti može biti polazna tačka, jednostavan a funkcionalan drajver za ILI9341:
https://github.com/martnak/STM32-ILI9341
Reply
#39
Ako se odlucite za Linux kernel, tu mogu da preporucim Raylib, sjajna cross-platform biblioteka za bazicnu grafiku i za nesto slozenije procesiranje slike sam koristio OpenCV + CVUI single-file graficka nadogradnja za osnovne GUI elemente i sa tim sam pravio svasta zanimljivo.

[Image: attachment.php?aid=36454]

Raylib sam dosta vise koristio, super biblioteka, bitno je da je cross-platform pa razvijam na host PC-u 1:1 u prozoru i posle samo prevedem program za RPi, moze da se exportuje i za WebGL.
Na Raspberry se koristi OpenGL ES graficka akceleracija, to radi odlicno, malo dok se udje u logiku GPU programiranja nije lako ali rezultati mogu da budi vrhunski ...

https://www.raylib.com/examples.html
https://www.raylib.com/examples/shaders/...processing


Attached Files Thumbnail(s)

Reply
#40
Praktican primer Raylib biblioteke koju sam iskoristio da napravim 4 razlicita GUI-a na 4 RPi-a, i to:

- glavni RPi-2 "SERVER" koji vozi Lidar GUI monitor i LIDAR processor koji preko NGINX i custom modula uvezanog preko shared memorije komunicira preko LAN i HTTP sa "klientima"

- 3 x RPI 3+ sa HD 1920x1080 + Touch + Sound, to se tera sa Raylib + LibCURL za HTTP komunikaciju sa "bezobraznih" 60 req/sec osvesavanjem po klientu Smile

- Custom PLC STM32F407 i FW by Macola povezan preko RS-485 na server, bez toga ovo sve gore nebi moglo da radi Smile

[Image: attachment.php?aid=36456]

[Image: attachment.php?aid=36455]

BTW: Vise GUI-a sam odradio, za ovaj projekat mi je trebalo jos 3-4 dodatna, trebao mi je visekanalni parametarski Osciloskop, pa onda simulator za PLC i simulator za Lidar, slatko sam se isprogramirao sa RayLib, jedna C skripta = jedna GUI-app, toliko mi treba, da je bilo slozenije od toga nikad ovaj projekat nebi priveo kraju Smile

[Image: attachment.php?aid=36457]

[Image: attachment.php?aid=36458]

U pitanju je platforma za simulaciju skijanja, bice vise detalja oko toga ... Wink

BTW2: U ovom projektu sam koristio build/deploy automatizaciju, rsync i ssh kljucevi sa rc.d skriptama koje rade start/stop/build udaljeno iz mog glavnog CLion IDE-a. Zamislite samo da nije bilo to tako umrezeno i da sam morao da kacim na svaki ponaosob uredjaj posebno nekakav programator !!!! Big Grin


Attached Files Thumbnail(s)

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)