GCC pro PIC

Už mi to jde nastavil jsem to podle videa na youtube ale nevím kde je soubor hex viz příloha
edit
OK už je to v pořádku

A teď bych potřeboval píchnout :jak napsat program v tomto kompileru pro PIC12F629 který měří kmitočet na jednom vstupním pinu ?na netu jsem hledal ale nic jsem nenašel :blush: díky

Pánové, ohledně optimalizace kódu u free verze XC8 doporučuji přečíst tento zajímavý článek: t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

Uvedené informace představovaly, alespoň tedy u mě, jeden z podstatných důvodů, proč jsem nakonec migroval od Microchipu k ARMům, pro které existuje výkonný GCC kompilátor dostupný bez jakéhokoliv omezení.
V souvisloti s GCC ale nechápu přístup a politiku Microchipu ohledně kompilátoru XC16, který, byť vytvořený právě pod hlavičkou GCC, není v “plné” verzi distribuován zdarma, ale poměrně za veliký pěníz. Když si vezmu, že významní vendoři ARMů poskytují vývojové nástroje zdarma (např. CCS7 od TI, MCUXpresso od NXP…), kroutím jen hlavou. :unamused:

Je to škoda, řada PIC24/dsPIC se nejeví vůbec jako zlá, ale s uvedeným přístupem MCP se nelze divit, že jim odcházejí zákazníci ke konkurenci.

Pravdu máš (jo a dík za ty brouky - sice starší, ale dobrej kšeft :wink: ), taky už s ARMy “koketuju”, ale je tam jedno velký ALE - a sice to, že NXP to s ARMy v podstatě odpískala (tedy zrovna s těmi pro nás nejzajímavějšími, což jsou LPC11xx, LPC13xx, LPC17xx) a zůstaly jen LPC8xx a LPC2xxx, přičemž to první už je moc malý a na to druhý pro změnu nemám programátor. Co teď? STM?

Dost mě naštvali.

Ještě na skok zpátky k těm PICům - pro někoho může být pořád ještě výhoda i to, že je jich stále dost i na 5V (i nových typů). Ovšem ty XC kompilátory jsou s tím jejich přístupem vážně opruz (a to čtení z linku je opravdu “výživný” :-/ )

ARMy: STM, ATMEL, LUMINARY. Za mě STM, pice už mi na stůl nesmí.

To Mahoney: za ty brouky nemáš vůbec zač, naopak mě těší, že je ještě někdo využije :wink: Úplně jsem ale zapomněl, komu jsem je tenkrát posílal, tudíž děkuji za připomenutí :smiley:

Co se týče ARMů, tak jsem po různých peripetiích zakotvil nakonec u Kinetisů od bývalého Freescale, dnes NXP či snad Broadcomm, uf. Až na pár maličkostí jsem s němi docela spokojený, k vývoji používám Eclipse s toolchainem pro ARM, i když mě v poslední době docela nadchlo MCUXpresso přímo od NXP. Proprietárnější Kinetis Design Studio mi zrovna dvakrát nesedlo.
Kolega z práce jede na STčkách, taktéž si je velice chválí. Uvidím, třeba je taktéž začlením do svého portfolia.

Aka je vlaste posledna funkcna free verzia od hitech firmy 9.xx ?

Pokud se nepletu tak HI-TECH PICC Lite Compiler 9.50. Novější verze jsou volitelně (dá se to instalovat i jako Pro verze pokud má člověk koupenou licenci)
Neví někdo jak je na tom s velikostí kódu SDCC ve free verzi pro PIC ?

Ona existuje ještě nějaká jiná verze SDCC? :open_mouth:

Nevím jestli jsi četl ten odkaz od Electrina, jestli ne tak si ho přečti, protože v tomto případě nejde ani tak o velikost kódu, jako spíš o to, jestli výsledný kód ne/obsahuje uměle přidaný balast zhoršující fungování programu a kradoucí strojové cykly a tudíž výkon, čiliže o efektivitu běhu. I když SDCC možná není v překladu tak efektivní kompilátor jako placený XC8, tak i přesto u něj tohle rozhodně nehrozí, tam nikdo nemá důvod přidávat nějaký balast navíc. Otázkou je podpora novějších čipů, tam to asi bude trochu drhnout.

Klidně ho vyzkoušej, když ho bude používat víc lidí a trochu se zapojí, tak jeho komunita i efektivita časem vzroste :wink: Já ho taky ještě nemám pořádně otestovaný, zkusil jsem ho jen jednou, zřejmě je načase to napravit.

sourceforge.net/projects/sdcc/files/

Mahoney> nevím,asi ne.Já jen že je po instalaci v adresáři složka non free.(nezkoumal jsem do podrobna,nepoužívám jej)
Ten “balast” je mi jasnej.Zkusím porovnat kód možná časem. Já používám primárně PMP Pascal.Ten funguje tak,že se pascalovský kód přeloží do asm a ten hned na pozadí v MPLAB IDE(instalace MPLAB IDE je nutností pro samotnou funkčnost PMP).XC8 používám jen na odzkoušení příkladů.Kód bych v něm psdal klidně taky,pokud by bylo třeba.
Velikost kódu *.hex je z PMP Pascalu o něco menší než xc8.Na netu jsem četl,že má konverzi do asm dobře řešenej,ale chyby nový verze PMP dle netu čas od času odstraní.
Jo a jaký IDE se používá pro SDCC (pokud je,nebo je třeba si napsat svoje) ?

To je na tobě, každé slušnější IDE ti umožní použít kompilátor jaký mu řekneš (ale konfigurace může být netriviální). Na vyzkoušení pár ověřených kódů pro porovnání překladu ovšem postačí předhodit to kompilátoru z konzole napřímo.

sourceforge.net/projects/eclipse-sdcc/

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:).