GCC pro PIC

Po studiu této “králičí nory” z odkazu chystám nějaké testy a možná i webovku (ještě uvidíme). Další příspěvky, příklady, linky a doplnění k tématu uvítám (a případně i testovací kódy, pokud vás zajímá něco specifického).

K “osmibitům” (PIC10F, 12F, 16F, 18F) existuje alternativní C kompilátor SDCC (forknutý z GCC), kdo by věděl o alternativních free-open C kompilátorech pro PIC24 (16bit) a PIC32MX (32bit MIPS), ať pro úplnost tématu neváhá informovat.

Edit 1706051933: Má tu o to vůbec někdo zájem, nebo to tady chcíplo už úplně?

No ja som síce viac na AVR ako na PIC, ale čítať si to čítam. Človek nikdy nevie, kde ho vietor zaveje …

Pomalu bych řekl, že pokud cílová HW aplikace funguje, tak je i jedno, že je přeložená ve free verzi XC8 nebo XC16.
Poslední dobou jsem začal používat 16MHz hodiny i u PIC12F1822 a nějaká výkonová penalizace mě absolutně neštve. Pokud by to bylo potřeba, tak se dá vždy nainstalovat trial verze se včema optimalizacema na 60 dní :smiley:

Každopádně to byl pro mě velký impulz si koupit 3 kity na NXP KINETIS Cortex M0+ a Cortex M4 :smiling_imp:

Zájem určitě je,ale v současnou dobu není moc čas.

To Billy Bob Bean: Ahoj, mohu se zeptat, jaké Kinetis kity jsi konkrétně vybral? Když si zkusím tipnout, tak ohledně jádra Cortex-M0 to bude FRDM-KL25Z, z M4 pak K64F, třetí nevím :smiley:

Jinak mně teď na stole přistála destička C2000 Launchpad od TI osazená procákem Piccolo TMS320F28027, který je určený pro řízení motorů, měničů a výkonovky obecně. Kdysi jsem už měl něco k řešení s jeho vyspělejším bráškou z řady Delphino (F28335), který mě bude strašit ještě asi dlouhou dobu (naprosto šílený MCU, brrrr), tak jsem zvědavý na tento kousek. Asi poletí do koše…
Způsobem práce jsou MCP (PIC24F, dsPIC) daleko pohodovější, a to i přes handicap s překladačem, viz hlavní téma tohoto vlákna.

Koupil jsem KL22, KL25 a KV10Z. S tím, že ten 10Z by měl být obecně na výkonovku. Totálně nemůžu z toho Mass Storage programátoru. To je totální pecka. To by se mi líbilo dostat dp mojí techniky. Prvotní naprogramování programátorem a pak kvůli aktualizaci píchnout do USB a bez instalace čehokoli tam nacpat aktualizaci.

PIC24 a dsPIC je poměrně pohodový MCU na rozchození a přechod z 18F. Ta filosofie je tam stále stejně jednoduchá.
Každopádně nehodlám od dsPIC přejít jen proto, že jsem teď objevil ARM. Absolutně nejvíc mě sere na Microchipu u velké spousty MCU piměrně obsáhlý seznam chyb v ERATA a nepřijde mi, že by to nějak chtěli řešit. Ale to se už opakuji, na ty chyby nadávám často.
Kvůli tomu jsem přestal používat dsPIC33FJ16GS504, totálně zabugovaný PWM… Jinak je to neuvěřitelně nabušenej brouk za ty prachy do zdrojový techniky. Řada MC je na tom líp, ale už nemá takok rychlý PWM, perfektní reference ke komparátorům a tak…

Ještě k XC16:
Mám větší projekt sestávající z cca 9x C a k tomu je pak ještě jedno C, kde si borci pak mění obsah dvou funkcí.
Je to moje velice speciální PLC, těch 9 knihoven tvoří něco jako OS a to poslední C co se mění, tam je aktuální funkce česování přepínání relátek, iterakce vstupů a tak…

Jde těch 9 knihoven nějak částečně přeložit, aby do toho nebyl přístup a zůstalo jen měnitelný to jedno C?

Jo, jde… nikdy jsem to sice nedělal, ale podle tohoto by to mělo jít linkeru předhodit. Objektové soubory se tuším vytvoří už při běžném překladu, měly by být někde ve složce s projektem, ale nikdy jsem to blíž nezkoumal… zkus si s tím pohrát.

Mahoney: Dík moc. Je to perfektní a funguje to.
Pokud se to pak ještě oskazuje na nějaké další knihovny, tak už to k nim chce jen .h soubory. C není potřeba. :smiley:

Ahoj všichni,

po delší době si dovolím opět přispět do tohoto vlákna. Ne že by se něco podstatného změnilo, ale nedávno jsem nalezl na netu poměrně zajímavý odkaz, který stojí za přečtení: jaycarlson.net/microcontrollers/

Z recenzovaných MCU nevychází zástupci firmy Microchip (PIC24F a PIC32MM) zas tak špatně, hlavně ten druhý uvedený, i když na konkurenci ztrácejí v několika podstatných náležitostech, např. zde diskutovaným kompilátorem jazyka C, dále drahými vývojovými prostředky a pomalým debuggováním. Nic nového pod sluncem. Kdyby se v tomto Mcp poučil, vybojoval by si daleko lepší pozici mezi vývojáři, kteří se dnes stále více přiklánějí k ARMům (včetně mě :slight_smile:).