Microchip Harmony za PIC32

[Milan_kg]

Pozdrav svima,
da li je neko imao priliku da proba ovo novo cudo microchipa i kakvi su vam utisci?

Taman se naviknes na MPLAB pa na MPLABX pa sa C32  na XC32 a sada opet izmena.

Pre si bar imao iluziju da znas kako ce program da radi a sada ko zna ste se tu desava.
Izgleda da su sada mikrokontroleri isuvise mocni pa svako moze da priusti da na racun optimizacije dobije neke druge stvari.

MPLAB® Harmony is a flexible, abstracted, fully integrated firmware development platform for PIC32 microcontrollers. It takes key elements of modular and object oriented design, adds in the flexibility to use a Real-Time Operating System (RTOS) or work without one, and provides a framework of software modules that are easy to use, configurable for your specific needs, and that work together in complete harmony.

MPLAB® Harmony includes a set of peripheral libraries, drivers and system services that are readily accessible for application development. The code development format allows for maximum re-use and reduces time to market.

[Macola]

Ne znam jer nisam probao, ali sasvim sam užasnut već načinom programiranja za ARM CORTEX M4, gde se svemu živom pristupa sa nekim masivnim strukturama i dve tone biblioteka, gde je veoma teško biti svestan šta se unutra na nižem nivou događa.

Jbg, to je izgleda neminovnost ekstremno visoke gustine integracije i modela razmišljanja konstruktora MCU gde bi sve moguće osobine hteli da strpaju u jedan jedini MCU.
To je nalik današnjim mob. telefonima gde ima svega i svačega, što treba i ne treba a osnovna funkcija telefona je prilično nezgrapno postavljena u svemu tome.

Iz prakse sa industriijskim automatskim mašinama, znam da je jedan od najzastupljenijih mikroprocesora na svetu više od jedne decenije bio obični 6502 (kao u Comodore 64) i viđao sam da pokreće mašine vrlo složene građe sa preko 600 in/out.
Prost kao dečja noša i sa dovoljno periferije je čuda pravio.

Stari dobri PIC16 i PIC18 se polako gase, a nasleđuju ih oni kojima je potrebna "kobasica" od 100+ linija koda za uključenje jedne LED :-).
Mislim, sve se na kraju svede ipak na malenu naredbu, ali kada se osmotri koje čudovišne biblioteke iza te jednostavne stvari stoje... :-)

Na račun strahovite brzine tih novih naprava umire polako hardverska posvećenost nekim funkcijama, i umesto upotrebe mozga sve je češće u upotrebi copy-paste...

P.S.

Sasvim mi je krivo i žao što nisam nastavio da učim Forth (kad sam već lepo to bio započeo i stekao neka znanja na nižem nivou).

U Forth, bez obzira na složenost MCU ili samog programa, ima se pristup do poslednjeg bita unutra.
Sasvim je moguće da ću se ipak konačno vratiti na Forth.
Sasvim besplatna platforma gde čoveku treba da pokrene terminal koji može da radi na najstarijem 286, a sve ostalo je u MCU: kroskompajler, interpreter, ma baš sve.
Žešće me nervira kad nešto u MCU radi ispod a da nemam pojma šta radi.

Pretpostavljam da imam vrlo konzervativan način razmišljanja oko toga...

[gorankg]

Kljuc svih tih softverskih lelemudija je u ovoj recenici:
"The code development format allows for maximum re-use and reduces time to market."
Nisam koristio Harmony jer ne trosim te PIC32 a za ono za sta meni treba PIC dovoljan je stari MPLAB. Gledao sam STM32Cube za njihove ARM i smaranje je zesce kad krenes redom po fajlovima da vidis sta se tu zapravo desava. Bas ovo o cemu prica Macola. Dok upalis LED smrkne ti se. Medjutim, ko i za sve drugo. Bezbroj sati ponavljanja i to ti postane normalno. Ko sto rece jedan intelektualac: "Hiljade i hiljade sklekova..."
Delimican razlog za svu tu kompleksnost je sto bi svi da im sad i klonja bude na netu pa da nesto daljinski upravljaju i analiziraju. Sve satro treba da bude connected, IoT, mora da ima RTOS, Ethernet, USB, WiFi. Ma ajde...

[npejcic]

Imao sam prilike da radim sa Harmony (smo radi probe), bio sam na nekom seminaru koji je organizovao Microchip na ovu temu. Takođe paralelno učim i STM32 M0..M4 kroz Keil i njihov CubeMX. Uh, iskustvo je iz nekog ugla zastrašujuće. Spadam u ljude koji su po konceptu rada kao što je Macola rekao. Znači imam svoje, godinama razvijane, biblioteke za štošta od periferija gde držim prilično toga pod kontrolom a kada se ukaže potreba lako modifikujem od aplikacije do aplikacije.

Međutim, sada smo "primorani" da koristimo ogromne "framework"-e, gde ne samo da stvar nije pod kontrolom, već imam utisak da su mnogo toga uradili nabrzaka i veoma često ne-inženjerski. Taj stav sam osetio na svojoj koži kod STM32 i novih biblioteka, gde je manevarski prostor sa nekima od njih sveden na veoma neupotrebljiv nivo. Ovo pokazuju i dosta ljudi na internetu koji se žale na slične stvari koje sam primetio. Harmony nije ništa bolji. Ima još uvek puno bagova, nejasnoća i dosta toga što je ranije radilo nije "portovano" kako treba.

Sa druge strane, ako bih pisao svoje biblioteke za napredne periferije kao što su Ethernet, USB, GLCD itd... trebale bi mi godine rada na tome, a da ne pominjem prelazak sa jedne na drugu arhitekturu. Iz ovog ugla, nažalost, neminovno je upustiti se u odabrani framework i koristiti ga koliko god spretnije možemo

I dan danas uživam u kodiranju za PIC16 seriju kontrolera, jer nekako sve je pregledno, lagano itd... ali sve više imam zahteva za veoma kompleksne uređaje sa puno procesorskih aktivnosti (brzine). Recimo, trenutno aktivno radimo na projektu gde je segment da primenimo Kalman filtar-predikciju (3D "indor" praćenje) gde PIC24F počinje da se prilično joguni jer je floating point matematika na brže od 100Hz čitanja senzora prilično zahtevna za PIC-ove... naredni skok je na recimo Cortex M4, ima FPU...

Kod ARM-a, već i kod Cortex M0, dovoljno je što me već užasava gomila instrukcija samo da bih iskonfigurisao jedan pin na portu, da ne pričam dalje. Ali kao što reče Macola, izgleda da sam i ja konzervativan

Ali, kao što reče gorankg, nakon dovoljnog broja "sklekova" čovek se prilagodi

[mikikg]

Harmony nisam probao ali planiram kada uhvatim malo vremena.

Kao ostali slazem se sa konstatacijom da je taj (ili bilo koji drugi) frejmwork prosto postao nametnuti nacin rada i za ljude koji su nekad pisali u ASM, Forth i ostalim low-level jezicima i okruzenjima, stvarno igleda preglomazan, nepouzdan, komplikovan itd.

Medjutim, postavite se u ulogu developera koji pise te frejmwork-ove, kome je posao da po ceo dan u tome pise nekakav code, jos u timu da se "slozite" i namirite sve "zelje-i-cestitke" koje se tu traze, naravno da je bezuslovno potrebno da se ceo tim programera sinhronizuje i da ra radi svako na svom zadatku, ne ugrozavajuci code drugih developera i tada je neophodno da se uvede jedan "vislji" nivo organizacije code-a gde sad u ovom spomenutom slucaju sa Harmoni imamo jedan relativno prost API sa kojim komuniciramo sa periferijama.

Takodje, alati, pisalo se nekad i u "ed", "vim", pa UltraEdit …
Ne vredi, potrebno je da se koriste ova nova GUI okruzenja, IDE koji pod svojom kapom imaju (uglavnom) sve sto treba da se vodi jedan projekat, od source repozitori (SVN, GIT), preko build skripti, debug i ostalo.

Nivo programiranja je sad prakticno isti za bilo kakve SW i HW aplikacije, unificiran je work-flow, mnooooogooo code-a je vec napisano za jedne te iste stvari (sad koji je dobar je drugo pitanje) ali generalno pisali za PIC, STM ili nesto trece svodi se na isto, code baza jednih isti LCD, I2C, SPI, GPIO drivera itd.
Sedite pa napisite u "svom" pseudo jeziku ove funkcije i napravite parser i compajler za C/C++ ili ASM pa ce da radi fino, a sto ce se potrositi stotine sati rada to niko ne pita … i da bude cross-prevodivo …
Moze i u Forth, moze i u Luna, C, Python, JavaScript … moze i ceo Linux da se potera (embeded linux), zavisi sta vam treba …

Ozbiljno i profesionalno programiranje zahteva ozbiljnu posvecenost i podosta vremena i realno bez svih ovih moternih alata pisati code za MCU je realno mucenje, nisu oni za dzabe napravljeni, ima tu dobrih koncepta i pristupa, stedi se dosta vremena na nekim stvarima.

Pa dalje, ko od vas radi Unit Testing ili slican code-base testing patern? Slabo?
Pa naravno, zato sto programiramo, letujemo, busimo, idemo na teren da montiramo, popravljano umesto da se ozbiljno posvetimo pisanju code-a a to zahteva vreme …

Znam ja sta sve moze u 1K da stane sa Forth vrlo dobro i tu nema sumlje ali na srecu ili na zalost prinudjeni smo da koristimo ove nove alate, ne sad ovaj konkretno Harmony (treba da se testira) pricam uopsteno za npr Eclipse, NetBeans i slicnih IDE okruzenja.

Izbor samog framework-a je vrlo bitan korak kod nekog projekta, ako se koristi mora da bude dobro testiran, pouzdan, brz a sad ako nam se potrefi da bude i "citljiv" tim bolje

[gorankg]

Moje najgore prilagodjavanje je bilo sa asm 8051 na asm PIC. Od tad su mi zivci ko konopci pa mi sve dodje normalno. Skoro sam pokusao da iz CubeMX neki primer za jedan ARM prepevam na drugi i totalno se smorio. Nece nikako da proradi. Znam da je hardver potpuno ispravan jer imam neki drugi primer za graficki displej i vidim da je to OK. Hteo sam ipak da koristim ono sto dolazi od ST kako bih imao tu jednoobraznost kod koriscenja njihovih biblioteka ali uzalud. Od tada mi se vrzma po glavi ideja da je ipak bolje izuti se za neki bolji i jaci development kit a ne recimo Discovery (konkretno za STM32) jer imas gomilu primera koji rade iz prve nego zezati se sa prepevavanjem.

[npejcic]

Miki, sve što si rekao stoji.

Postoji još jedan problem, zbog koga ja lično žalim, a to je recimo predivno iskustvo sa Microchip TCP/IP stack V5.42 i nižim-a. Fascinantno je to šta su developeri uspeli da "uguraju" u recimo jedan PIC18F67J60 koji ima svega 3.8kBy RAM-a. Međutim uvidom u kod koji stoji iza ovog steka, embedded programer može uvideti odlične optimizacije koje su korišćene i ideje koje su primenjene da to radi i više nego odlično. Imam bar 10-ak rogusnih projekata koji rade 24h/365dana godišnje sa njim bez saplitanja a podržava bezmalo sve protokole koji su danas akutelni kod IT-a.

I šta je Microchip uradio sa tim, "sahranio" ga. Obustavio podršku za ove kontrolere, prevaziđeni. Zatim, ljudi koji su radili na ovom steku a svega ih je nekoliko su otišli iz Microchipa... Veoma aktivan na forumima sa mnogo pomoći koje je pružio recimo Howard Schundler.

Ovaj stek je besplatan, ako se koriste Microchip kontroleri ili Ethernet čipovi.

Preporuka Microchipa je da se ovaj stek sada koristi iz Harmony-ja. Uf, to nije ni približno isto. Zahtevniji je i naravno podržava samo PIC32 generaciju MCU.

Pokušaj da pronađem nešto slično na ARM (STM32) došao sam do recimo CycloneTCP koji košta više od 3000 evpropskih novčanica po pojedinačnom projektu!.

I dan danas mi nije jasno zašto su "sahranili" dobri stari TCP/IP stek.

Poenta ove moje priče sa je da nisu nam učinili olakšanje novim i "naprednijim" verzijama (Harmony), već upravo suprotno.
Inače nema dileme da se "stack"-ovi i "framework"-ci moraju koristiti...

[gorankg]

Ja sam testirao taj TCP/IP prvi put sa PIC18F452 i RTL8019 a posle sa PIC18F97J60 i zaista je bio OK. Testirao sam jedan komercijalni TCP/IP koji je bio plaćen i on je i primenjen kod uređaja koji je išao u prodaju. Ovo sad nemam ni želju da probam. 
Verovatno je ista situacija i sa USB stekom. Za STM32 imaš LwIP ali ja nemam neko duže iskustvo sa tim. Probao, video da radi i odložio na neko vreme.