PIC32Mx vývoj v Linuxu

[mhi]

Pouzivate nekdo standardni mips-gcc pro vyvoj pro PIC32Mx (MIPS SoCy od Microchipu) v Linuxu  ?

Existuje xc32 pro Linux, ano, vim o tom, ale rad bych pouzil idealne mips-gcc (v Ubuntu je crosscompiler, kterym jsem vygeneroval zda se spravnou binarku). Hlavni problem tam je s atributem "address", ktery se pouziva na vsechny registry - to umim obejit pres #define pro celociselne registry.

Motivace meho asi nezvykleho prani je to, ze vyvoj v Linuxu (vi, gcc,make) je pro mne mnohem rychlejsi nez v MPLABu X, navic obcas crosscompiluju na ARM hostu, pro ktery xc32 neni. Presne takhle resim ruzne Cortexy-M. Popravde jsem byl dost prekvapen tim jak MPLAB X funguje, uplne jiny svet, nez na ktery jsem zvykly.

[Reklama]

[z_sk]

Hm, https://onlinedocs.microchip.com/pr/GUID-471BA167-B55F-488B-A1CC-D88BAA7832CA-en-US-1/index.html?GUID-1CD0A2C3-CE77-47BB-82DA-9FEBDE79930A sa používa GCC.

[mhi]

Ano, xc32 je zalozene na gcc, zdrojaky (asi nejake ne uplne kompletni) jsou zde: https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/SoftwareTools/xc32-v4.30-src.zip

(da se tam doklikat pres https://www.microchip.com/en-us/tools-resources/archives/mplab-ecosystem )

Jenze to clovek zase skonci s Microchipim prekladacem se vsemi nevyhodami. Proc, kdyz tu je fungujici GCC pro MIPS ?

(otazka mimo tema-nemate nekdo zdrojaky gcc+binutils pro TriCore a C166 ? )

[mhi]

Zapomnel jsem dodat, ze workaround na specificky atribut adress toho xc32 je zde: https://godbolt.org/z/rMrz4j71W, to by melo prinest urcitou miru kompatibility na urovni zdrojaku, i kdyz idealni to rozhodne neni. CMSIS-style mi prirostl mnohem vic k srdci.

[mhi]

Nebudu zakladat nove vlakno, kdyz se to tyka tematu - potrebuju do toho MIPSe (nebo obecne jineho embedded zarizeni se SoC s opravdu malo RAM - zde je to 20kB*) nahrat vyvijeny kod do RAMky toho procesoru.

Reseni, ktere mne napadlo je vzit stripnuty ELF a nahrat ho pres nejake rozhrani (seriak apod.) do toho procesoru, kde bude jednoduchy "linker", ktery provede relokace (-fPIC to hodne omezi) a nabinduje symboly z flashky. Tenhle loader uz mam hotovy z jineho projektu. Problem je v tom, ze ELF co vyleze z GCC je moc velky a ne pro muj ucel uplne optimalne sestaveny. A ja nechci vymyslet kolo, treba uz existuje reseni, ktere optimalizuje ELF tak, aby zabiral co nejmin mista, a veci nutne pro load mel az na konci. Netrvam na ELFu, muze to byt klidne i jiny format, ktery splni tenhle ucel. Znate nekdo neco takoveho, nebo resili jste takovou vec?

Vyse uvedene reseni vyrazne zvysi "development cycles per minute" (ted to je dokonce mensi nez 1 :-( ).

Asi bych to pak recykloval i na risc-v (ESP32C3), tam je development cycle take priserny.

Dekuji

------------
* s cca takovym mnozstvim pameti pry ridili cernobylsky reaktor :-)

[Reklama]

[z_sk]

Mrkni, prípadne študuj: https://www.abclinuxu.cz/blog/analyza_greenie_20_04/2022/2/najmensia-binarka-hello-world-v-c.