Knihovny u PIC a ARM

[Mimar]

Ahoj,

nikdy nekončícím evergreenem internetových diskuzí je porovnávání mikroprocesorových platforem, například Atmel AVR vs Microchip PIC vs ARM.... Člověk občas žasne, co dokáží diskutující vymyslet, aby si obhájili zrovna tu svoji platformu.
Asi každý vývojář se občas vyskytne na křižovatce, jakým směrem se vydat, u jakého výrobce zakotvit. I mně se toto rozhodování v minulosti nevyhnulo, s výsledkem, že mikrokontroléry Microchip, zejména PIC24 a PIC32, jsou ty pravé. Časem přibyla platforma ARM CM od Freescale (dnes NXP), která PICky odsunula poněkud dozadu.

Každá z rodin má své kladné, ale i záporné stránky, o kterých byly popsány stohy papírů. Zajímavým se mi ale jeví, že jsem téměř vůbec nenalezl diskuzi nad knihovními funkcemi u PICek. Zatímco u ARM CM existují dle výrobců různé SDK, HAL, low-level drivery atd., u Microchipu toto prakticky chybí. Ano, např. pro PIC24 se vyskytovala (legacy) peripheral library, dnes převzatá funkčností konfiguračního nástroje MCC, bohužel se obě vyznačují určitou těžkopádností. Uvedu příklad: když chci u Kinetisů nastavit sériové rozhraní, mám k tomu jednu funkci, jejíž jeden z parametrů představuje číslo kanálu. U MCP se pro každý kanál vyskytuje jedna inicializační funkce, tudíž u procesoru se třemi UARTy mám taktéž tři funkce lišící se akorát v čísle, což mi zrovna dvakrát elegantní nepřijde. V podobném duchu se nese zacházení i s ostatními perifériemi. Toto mě pěkně štve, kdy důvodem je podle mě debilně napsaný header file každého MCU. Několikrát jsem uvažoval nad jeho překopáním, ale investovaná práce by se nevyplatila.

Uf, to jsem se tu nádherně vypsal....

Zajímalo by mě, jestli výše uvedené vadí jenom mně, či se někdo přidá

[Tribec Zacks]

Mimar, mna by zaujimalo co touto otazko sledujes ?? ale skusim sa pridat a aspon svoj nazor ti tu napisat. vo firemnom prostredi sa vsetky volne dostupne a dodavane hal/sdk/drivery pouzivaju bud uplne minimalne, alebo takmer vobec a ak sa jedna o bare-metal vyvoj, tak si to firma robi vsetko sama. ak sa robi nieco pre rtos/linux tam je uz situacia trochu ina, system si firma osvoji a dalej si snim robi to co potrebuje. dovodom su casto open source licencie ktore vyzaduju otvorenie aj tvojej roboty pokial pouzivas nejaky open-source kod vo svojom projekte(zalezi od licencii).
v domacom prostredi to mas uplne jedno a pouzivaj to co ti najviac vyhovuje, to kde vies najlahsie ziskat nejaku pomoc ak ju potrebujes atd. ake mam preferencie na tu alebo tamtu kniznicu ti nedam, lebo ich nepouzivam, rad sa babrem priamo s registrami mcu a rad rozumiem tomu co mi kod robi a asi najdolezitejsie, rad pisem minimalisticky kod ktory robi len to, co robit ma. a co je najdolezitejsie nemusim sledovat ziadne release-notes a bugy samotnej kniznice.
ale nech ti tu nevypisujem len same pocitove bludy, hal layer od stm funguje pomerne slusne, z toho minima co som skusil prekompilovat medzi cortex0, 3 a 4, som nemal problem, zmena mcu v nastaveniach, skontrolovat ci ten ktory timer pouzivas ma hardwarovo aj mcu na ktory kompilujes, prekonfigurovat gpio, zmenit nastavenie pll a je vybavene (aspon co sa tyka malickych domacich projektov).
kazdopadne ani std-periph ani hal nepouzivam, skompilovat jednoduchy hello-world v podobe blikajucej ledky mi na stm32f7 spapalo cca 4kb kodu a ja toto nemam rad ked tam je nieco skompilovane co tam nema byt, popripade co neviem co robi. mne osobne je aj tak podstatne jednoduchsie otvorit datashit, najst si ten ktory peripheral a nakonfigurovat si ho manualne ako skumat nejaku kniznicu. kniznicky su pre arduinistov (situacia je trochu ina ak clovek potrebuje cely usb/ethernet stack)

[Mimar]

Abych řekl pravdu, tak touto otázkou nesleduju v podstatě nic, jen jsem se potřeboval vypsat z menší flustrace Ne, vážně, v aktuální době se věnuji paralelně několika projektům, z nichž je třetina realizována na PIC24 a zbytek na Kinetisech od NXP.
U ARMů využívám jak SDK dodávaný výrobcem, tak i CMSIS přístup, výkon a efektivita mě zas popravdě tolik netrápí. No a jak tu mám na stole i mašinky s PICkami, tak jsem se neubránil srovnávání Prostě a jednoduše, PICky mě i přes kopici kladných bodů přístupem ke knihovnám (i kdybych si je psal sám) trochu naštvaly....

[Tribec Zacks]

Mimar, mozes aspon napisat preco ti tie hal/std-periph layery tolko chybaju? nieje to nic viac ako kopa enum pristupov k registrom mcu. mne pride podstatne lahsie a prehladnejsie nakonfigurovat napr timer s pomocou header subora ako enum typov a nazvov (ktore aj tak treba niekde hladat), napr zakladny timer config pre cortex:

Kód: Vybrať všetko

void TIMER2_Global_Time_Config(void){

	// Enable clock
	RCC->APB1ENR |= RCC_APB1ENR_TIM2EN;

	// Prescaler 54000 = 1khz = 1ms per tick
	TIM2->PSC = 0xD2EF;

	// Update - re-Initialize the counter
	TIM2->EGR = TIM_EGR_UG;
					
	// Timer enable
	TIM2->CR1 = TIM_CR1_CEN;

Aj ked si uvedomujem ze hal styl konfiguracie je, ze sa sam cloveku vysvetli a da sa rovno precitat co ten config znamena, stale mi pride takyto (hore timer) sposob prijemnejsi, s datasheetom v ruke presne hovori co ten config robi a co kde zapisuje. a to este nehovorim o rozhraniach typu fmc alebo ltdc kde clovek naozaj musi rozumet tomu co robi. btw presne tieto dve rozhrania boli dovod preco som sa na hal vypr.ol, ani za ten svet a podla hladania na nete a roznych forach som nemohol rozbehat lcd a sdram na jednej cinskej f7 placke kde bola cinska sdram s rozdielnym timingom ako na vsetkych forach, s minimom trapenia a po prestudovani timingov ramky a displaya bol config na svete. no... ale asi len starnem a neviem co je nove a "moderne" btw, teraz ma napadlo.. pracoval som v prostredi kde sme mali podobny abstrakcny layer koli testovaniu mcu pred releasom, a kde sme nemuseli riesit kazdy mcu v rodine zvlast, mali sme podobny hal layer ako stm... ci to neurobilo aj stm stylom ze svoj interny nastroj takto nedotiahlo dotiahlo do naozaj peknej a pouzitelnej podobny a proste nespristupnilo pre zakaznikov... hmm kto vie