XC8-pomalý překlad

Čau chlapi a dámy :slight_smile:
Mam problém s XC8 a pomalou kompilací, která vyústí v error.
Ale vemu to pěkně od začátku, stáhl jsem si MPLAB X a XC8 někdy letos na začátku roku, začal jsem psát firmware pro svuj soukromý projekt, vše krásně šlapalo a kompilace probíhala rychle. Nicméně, včera jsem udělal nepatrnou změnu v kódu - vlastně jen u #define změnil typ portu a MPLAB X najednou začal řvát, že XC8 is timeout. Tudíž jsem udělal reinstal jak XC8 tak i MPLAB X a kompilace je od té doby pomalá, tvrá 5 minut a výsledkem je, že háže nesmyslné errory kde nejsou, prestože předtím kompiloval rychle a bez problémů.
Podotýkám, že vše mam instalované na Linuxu Mint a starší mašině od HP, kterou jsem před vánoci upgradoval a ještě ji upgradovat budu ohledně RAM.
Může mi, prosím, někdo pomoci tohle vyřešit?

P.S.: Míchám asm a C, v ASM mam zpožďovací routinu, předtím překlad probíhal naprosto bez problémů. Tak nechápu co se mohlo stát, že najednou stávkuje :frowning:

Řešení: Doinstaloval jsem chybějící balíčky DFP a zrestartoval. Tak to snad je definitivní řešení.

Já v tom dělám denně a není den, kdy bych nemusel celý IDE restartovat. Mám pocit, že čím vyšší verze, tím víc zabugovaná a starý bugy moc neřeší…

Ale mohl jsi hned na začátek postnout chybu co ti to házelo.

To je bohužel smutná pravda :frowning:

Mám koupenej MPLAB-SNAP debugger už víc než rok, ale ještě jsem ho ani nevyzkoušel, a to z toho důvodu, že je podporovanej až od v. 5.05 a já nemám odvahu, právě kvůli těm bugům v prostředí a kompilátorech, zbavit se starý, ale ještě jakžtakž funkční verze (taky pod Linuxem). A popravdě se mi do toho ani moc nechce, když to čtu (zas a znovu pořád dokola, z různých stran a zdrojů), už tak to člověk musí restartovat pomalu před každou kompilací.

Když přišel MPLAB X, tak dost lidí z podobných důvodů zůstalo u poslední starý verze nativního MPLABu (8.92; a u starých verzí kompilátorů) a ani se jim nedivím. I já ho mám pořád ještě nainstalovanej - bohužel to ale vede k tomu, že si pak člověk udržuje například starý PC ještě s WinXP, zásobu starších typů brouků, starej programátor… že si prostě tak trochu pěstuje jakousi “-filii” na assembler a obsolete věci. A taky to byl mimojiné důvod, proč jsem tehdy začal “pokukovat” po tom, co kde nabízí konkurence.

Takže dle mého názoru by se chlapci v Microchipu měli konečně probrat, protože z ostatních na trhu má kdekdo nativní prostředí a ne “běžící” (neustále padající) pod nějakým runtime, kdekdo má zdarma neomezený C kompilátory, kdekdo má taky konfigurátory, atd… Jinak o ten svůj byznys Microchip nakonec taky může do finále přijít, protože i ten profík, co si kompilátor nakonec koupil za těžký prachy a vyvíjí pro výrobu, kde se kupují například desetitisíce brouků, musel jako mladší nějak začít a někde a na něčem se to nejdřív naučit dělat - a pokud těch pár dnešních mladých lidí, co ještě zbylo a co mají opravdový zájem něco dělat a něco se naučit má k dispozici TOHLE, tak je teda upřímně lituju a vůbec se nedivím (když to trochu přeženu) že jdou nakonec šlapat na kole, prodávat zeleninu, připoutají se někde ke stromu a nebo se plazí po lodích a atomových elektrárnách, nebo cokoliv jiného. A to jsme ještě ani nenakousli errata sheety u nových typů brouků často dlouhý jak hajzlpapír atakdále (include soubory vyšších kompilátorů například).

Za výpis chyby bych se taky přimlouval, otázka v případě MPLAB X ale zůstává jestli to má význam, protože co mám zkušenost, tak při běhu toho prostředí dochází k chybám a pádu různých skriptů v paměti, které jsou součástí toho IDE a zajišťují funkcionalitu různých věcí v něm, přičemž když v něm něco padne, tak to prostředí nenahlásí vůbec nic, zatají všechno jako pravej partyzán. Jinými slovy, ona se i ta chyba může měnit podle nálady a aktuálního stavu prostředí, však víš. Rád bych poradil nějak konstruktivně, ale dostali jsme se s Microchipem do bodu, kdy “vystoupit nastoupit” je “řešení všeho” a nejrozumnější co člověk může říct jako řešení problému je “se* na to, jdem na jedno” - to je pak každá rada dost těžká.

Sry za ty nářky, ale to se fakt nedá.

Mahoney: Tak nějak jsi to shrnul a zhrunul :slight_smile:

Já ještě přidám, že jsem vesele nainstaloval ze zvědavosti x 5.35 plnej očekávání, že opravili chybu, kdy se buď rozesere makefile anebo to zahlásí project file “null” a ještě cosi.
Instalace nové verze zmíněné problémy nevyřešila, a jako megální bonus dojebala verzi 5.30, která do té doby fungovala. Reinstalcí asi úplně všecho v různých pořadích nepřivedla verzi 5.30 k životu. Což je pro mě kurevskej problém, protože z velitelství mám nakázanou verzi 5.30 a není možný ji opět rozjet. Tohle mi opravdu zvedá těžce tlak krve.

Errata asi nemá smysl komentovat.
PIC mám rád, dělám na nich víc než 12 let, ale nevím nevím. ARM jsem zkoušel lehce, ale zůstal jsem u blikání s LEDkou a přišlo mi to neskutečně těžkopádný. Ty PIC jsou takový dost jednodušší a je “lehčí” je rozběhat.
Nejvíc mě teď točí několika letech s 16b PIC přechod k PIC18F87K90

Já taky cca 12 let… a právěže je mám taky rád, ale to “nevím nevím” je bohužel přesnej popis aktuálního stavu u nich.

Kamarád si rozjel Code Composer a zkouší MSP430 od TI - a vypadá to, co jsem se tak díval, že z těch “ne úplně obrovských” brouků (a jader typu ARM apod) je to v současné chvíli asi nejrozumnější cesta (když Atmela pozřel Microchip a doje*ává ho úplně stejným stylem). U PICů byla skvělá ortogonalita, ty 8bit a 16bit jádra jsou navržený naprosto geniálně (mimochodem, PIC1640 byl poprvé použitej už v Apple IIc, to je rok tuším 1976 nebo tak nějak… tehdy to ještě ani nebyl Microchip, ale General Instrument), u ostatních se musí všechno stěhovat do a z R registrů (akumulátorů), hnus, a jenom ty LOAD a STORE instrukce dělají čtvrtinu až třetinu velikosti kódu samy o sobě. Věčná škoda

Tak to je vážně smutnej příběh, když čtu co píšeš.

Jinak jsi vystihl podstatu Microchipu úplně dokonale. Já jsem původní profesí elektrotechnik, kdysi jsem se chvilku živil vývojem SW,ale mám blíž k elektronice a tohle pro mne byla jasná volba, je to free a upřímně, mam tu pár brouků a dodělám dva projekty a nejspíš od microchipu odejdu.
MPLAB X verze 5.35 mne dorazila, předchozí verze fungovala jen s minimálními problémy, ale ta poslední mi hází neustále njakou hlášku o chybějícícm plug inu.
Já spíš hledám a přemýšlím nad vhodnou náhradou, která by běžela na linuxu.
Rád bych šel cestou texas Insrruments, jejich IDE je myslim linuxový, akorát mne odrazuje, že nemaji brouky v THT nebo je spíš nenabízí tme… Já si napřed obvod spíchnu na nepájivém poli a pak kreslím dps.

Já jsem tu rozhodně nechtěl šířit nějakej pesimismus, ale když už to pomalu došlo do situace, že člověk musí znát od všech všechno (včetně x51 apod) a vybírat si od všech a od všeho to, co ještě nějakým omylem funguje a/nebo to ještě nestihli nějakým způsobem doj**bat, tak už je to vážně na pováženou a člověk si pár jedovatých poznámek prostě neodpustí.

Otázka je právě to, jakou vhodnou náhradu… a nebo se můžem spojit a začít psát pro Microchip vlastní kompilátory, ostatně podobně to udělala MikroElektronika (myslím tu srbskou firmu) a vydělává na tom celkem slušný peníze… převzít nějaký IDE a ohnout ho k obrazu svýmu nemůže bejt tak těžký, zprasit to víc než Microchip zprasil Netbeans snad ani nejde :smiley:

Ale vážněji, můžem z toho udělat v nějaké vedlejší sekci challenge, kde si můžeme zmapovat co je k dispozici, za jaký peníze, pod čím to chodí a jaký jsou výhody a nevýhody, nějaký screenshoty, a uvidíme jestli z toho něco vypadne… berete? Za mě by to mělo běžet pod Linuxem (prostředí samozřejmě), mít zdarma aspoň nějakej kompilátor kterej bude opravdu kompilovat, pokud možno bez týdenní konfigurace za pomoci voodoo a podobně a brouci by měli být běžně dostupní (nejradši TME apod) v nějakých rozumných pouzdrech a za rozumnou cenu. Neberu Renesas, ten je jen pro profi scénu a podmínky nesplňuje, dál se klidně vyjádřete pokud o něčem víte. Primárně bych mapoval osmi- a šestnáctibitové mikrokontroléry, ale pokud někdo prošlapal schůdnou cestu např s ARMy, ať se klidně podělí o své zkušenosti také.

Souhlasím s jinou sekcí.
jen bych dodal, že nejen pod linuxem, ale aby to nebylo proprietární, tudíž ideálně gcc na překlad.
Profi věci od renesas nebo keil bych rovnou vyřadil, keil snad ani Linux nepodporuje.

No zo zadania vyplýva:

  1. prekladač GCC. Ten je aj na moje dlhoročne používané ATmegy

  2. Priohnúť sa dá na hocičo Eclipse. Veď nato bol vyrobený.Netuším, či beží pod Linuxom, ale je malá pravdepodobnosť, že by nebežal

  3. Dnes vzhľadom k cenám a perspektíve využitia naučeného nemá absolútne zmysel uvažovať nad 8 či 16 bitovými procesormi. V zásade tieto (ano, aj tie moje obľúbené ATmegy) už len kolabujú do hlbokého obsolete.

Ak človek príde do bodu, že už má pôvodných vecí dosť alebo nestačia, musí si vybrať niečo, k čomu mu novonadobudnuté informácie vydržia na najbližších 10-20 rokov. Všetci vieme, že vedomosti a skúsenosti sa ťažko získavajú a to aj napriek chvalabohu veľkému množstvu zdielnych ľudí na fórach.

Moje skúsenosti sú také, že sa netreba báť obrovského množstva nových fičúr v nových procesoroch. Stačí ich jednoducho nepoužívať až do času, keď už iná cesta nie je dostatočne efektívna. V tomto sa potom nové procesory nemusia v použití nijako líšiť od starých známych 8 bitov. Sám v používam mnohokanálové sw riešenie I2C, či SPI na pinoch, ktoré chcem/môžem využiť. A to bez žiadneho výkonového obmedzenia dokonca aj na ATmege na 18,432MHz.

S cenou je to však omnoho záludnejšie.

Áno, 32b procesor s mnohonásobne väčšou RAM, Flash a taktom ako 8 bit stojí rádovo niečo medzi 0,5 - 2EUR. Dobrým príkladom je STM32G071.

Avšak je tu už pár rokov prazvláštna konkurencia. Začnem tou najjednoduchšou.

ESP8266.
V podobe modulu WT 8266 za cenu v okolí 2EUR je neprekonateľná vlastnosťami, rýchlosťou a hlavne množstvom funkčných príkladov na vývojovom prostredí Arduino. Inak nad ním ohŕňam nos posledných 6 rokov. No keď som chcel začať skúšať niečo s týmito procesormi, iba v tomto prostredí mi všetko fakt fungovalo ako malo do pár minút práce.
Áno, málo UART-ov, ale áno perfektne a jednoduho spraviteľné rozhranie cez vnútornú web stránku a hladkací mobil, ktorý má dnes prakticky každý.

A potom je tu jej ďalší stupeň.
ESP32. Aj s bluetooth. Napríklad v podobe modulu

tme.eu/sk/details/esp32-wro … over-16mb/

so 16MB Flash a 8MB RAM za cenu cca 5EUR, keď nemusím riešiť plošák na úrovni 0,5mm cestičiek, toto nestihá žiaden Cortex. V cene 5EUR ponúta Cortex procesor s pevným Ethernetom a cca 256kB RAM a do 512kB Flash.

Lenže ten WROVER už má v tej cene na sebe všetko vrátane WiFi, či Xtalu s 10ppm. A hlavne, nenarazil som na príklad (a že ich je hafo) v prostredí Arduino, ktorý by nefungoval. Pevný Ethernet riešim cez modul Wiz850

tme.eu/sk/details/wiz850io/ … et/wiznet/

za cca 15EUR. Lebo ten konektor, trafáčik a ďlšie obvody by niečo stál aj pri tom Cortexte.

Stále mi na ESP32 chýbajú UARTy a tiež mi chýba USB host. Ale už začali vyrábať ESP32-S2 a ten už USB host má. Aj keď iba USB1.1

A teraz vážne.
ESP32 (samotný procesor stojí cca 2,53EUR)

tme.eu/sk/details/esp32/mod … 32-d0wdq6/

je dvojprocesorový čip bežiaci na 240MHz. V tejto cene v takom výkone a RAM nie je žiaden iný 32b procesor. Teda o tom neviem.
Naviac hotové moduly WROOM začínajú v okolí 2,5EUR

tme.eu/sk/details/esp32s2-w … room-32mb/

Takže aj keď pre moje účely majú furt celkom málo UARTov, výkonovo a pamäťovo sú na trhu z môjho pohľadu neprekonateľné.
Hlavne si na plošák zaletujem už hotový modul, ktorý hneď na prvý šup z prostredia Arduino (stále ho nemám rád, no natívne prostredie ESP-IDF sa mi nepodarilo rozbehať ani na 852 pokus (furt mu niečo chýbalo až ma to furt prestalo baviť), aspoňže v Arduine sa dá písať čistým C kódom) funguje, je po mnohých bádateľských pokusoch s inými platformami priam neuveriteľné.

Samozrejem WiFi sa dá neaktivovať a len čisto využiť výkon dvoch procesorov do 240MHz s obrovským množstvom Flash, RAM, súborového systému a primeraného množstva IO nožičiek. Nejaký skvelý analóg očakávať netreba. Na to práve využívam ten SMT32Gxxx. Ale pre základné funkcie a komunikačné rozhranie s obsluhou je to obrovské.

Nová ESP32-S2

tme.eu/Document/18ca9048e8f … eet_en.pdf

Nerobím žiadnu reklamu, sám stojím na rázcestí.

Asi teda tak to momentálne vidím.

Teším sa na vaše postrehy a skúsenosti

Koukám že ESP32 je lenější než PIC 18F46K22 se kterým teď pracuji.
Škoda, že je pouze v smd provedení, dle tme :frowning:

Jooo, Martin má pravdu ESP docela dost promíchává vody a krásně to shrnul.

Zkoušel jsem na nějakým STM NUCLEO64 kitu rozblikat LEDku a nebylo to tak jednoduché jak rozchodit na ESP8266 Web server. Tohle mě baví o hodně víc, ale jak říkáš, Arduino IDE je na to fakt napytel. Občas to sochání dokumentace k tomu co dělají nějaké funkce…

Dělám na jedné aplikaci, kde jesem po američanech dostal HW k naprogramování a je to postavený na PIC18F87K90, krmím tím PICem grafický LCD přes SPI bez DMA a to je fakt děs.
Přemýšlel jsem o budoucí verzi hw postavené na nějakém PIC24Exx, ale i to ESP32 by se dalo náramně použít. Poslední dobou jsem si hodně zvyknul na krokování programu v aplikaci přes ICD4. Takže pokud bude možnost tohle na ESP a nějaký jiný IDE, tak je to opravdu na hodně hluboké zamyšlení.
KDysi na začátku jsem pro ESP napsal program v ide Atom, pak jsem přešel na Arduino IDE. Tak možná bude asi na čase pomaloučku zkoumat vývojové větve.

Podľa toho, čo som analyzoval okolo ESP32.

Asi ani nemá zmysel z pohľadu ceny použiť iba samotný procesor ESP. Rozdiel ceny za samotný procesor a ceny za najlacnejší oživený modul, ktorý okrem ESP32 obsahuje aj všetku potrebnú bižutériu je tak maličký (bez integrovanej WiFi anténky ale s konektorom, napríklad WT8266, WROVER), že využiť výhody letovateľného rastra 1,27mm po obvode modulov a brať modul ako “procesor” sa naozaj oplatí. Tým odpadá problém s letovaním malej rozteče pinov 0,5mm v domácich podmienkach.

Naviac cez WiFi sa dá procesor preprogramovať.
WiFina ma celkom potešila, lebo jednak sa vie správať ako samostantý server - stačí si mobilom vyhľadať vlastnú sieť genrovanú ESP no súčasne vie fungovať ako jedna stanica v domácej WiFi sieti. Takže s modulom sa dá baviť súčasne dvoma samostatnými kanálmi.

Ak by chcel niekto použiť iba samotný procesor, upozorňujem, že niektoré modely obsahujú celkom slušnú internú Flash priamo v sebe.

Čo som používal to Arduino, normálne v tom ide spraviť projekt pozostávajúci z viacerých *.c. Len si treba dať pozor na vhodné použitie include.
Teda ak je nejaký súbor *.c v danom adresári, automaticky sa pri preklade zlinkuje, čo nemusí byť vždy želaný stav. Preto verzie *.c, ktoré sa nemajú prilinkovať treba vložiť do iného adresára.

Najlepšie by však bolo rozchodiť to ESP-IDF. Tam sa dá program aj krokovať. Kúpil som si k tomu nie drahý originálny HW pre programovanie ESP.

Nač tolik nářků ? Začněte dělat s ARM M0/M3 a budete mít vystaráno. Já sice preferuju KEIL, ale takovej ATOLIC taky není úplně zlej a je free.

Trochu konkrétnější informace než jen M0/M3 bys prosímtě neměl? Ne že bych to nezkoušel, mám tu od NXP pár LPC1347 a LPC1768 a nějakej kitovej programátor k tomu, ale přestali mě bavit přesně ve chvíli, kdy začali dělat potíže s tím jejich Xpresso IDE a já netušil, jak jinak ten programátor rozjet.

Ale jistě. Historicky jsem začínal na kitu CORTEX M3 STM32F103VET
lillyelectronics.com/arm-cor … ouchscreen
Prodával to tady kdysi I4WIFI a taky se u nich dal koupit JLINK. Dost levně a brzy to přestali nabízet.

Měl jsem licenci na KEIL4 z práce, takže nebylo co řešit. Chodilo to naprosto dokonale. Překlad, nahrávání, debugování, všechno spolehlivě, svižně a to i na celkem slabé mašině. Zkoušel jsem taky ULINK půjčenej z práce a ten chodí taky skvěle. STLINK V2 pomalejší, ale pořád dost dobrý. V KEIL3 jsme taky ve firmě programovali x51 a lepší prostředí neznám. MICROCHIP prostředí? K smíchu(k pláči).

Aby bylo jasno - preferuju jednoduchá prostředí, abych když k tomu příjdu po delší době, protože dělám taky jiný věci, nemusel, když chci něco změnit, hodinu bloudit a klikat.

Později jsem měl možnost si vyzkoušet jak se s tím dělá v prostředích založených na eclipse (arm plugin v eclipse , atolic) a nebyl jsem tak spokojenej (pomalejší, míň stabilní, zbytečně složitý - umí všechno, ale né všechno vždy funguje). Podotýkám, že jsem na eclipse taky dělal LEON3 ( SPARC V8 ) a taky dost hrůza, ale nebylo na výběr.

Teď ty procesory co používám a doporučil bych:

M0 - STM32F030
M0 - STM32F051
M0 - STM32F042

M3 - STM32F103

S M4 a M7 mám nějaké zkušenosti, ale né ve formě velkých projektů, takže spíš pokusy. Na nic je opravdu nepotřebuju. Jestli přiberu do výběru něco, tak nějakou odlečenou M4 kvůli float point jednotce a trochu vyššímu taktu.

Neříkám, že je to nejlepší možná volba - záleží co s tím kdo chce dělat .

Složitost těch procesorů je řádově větší než PIC/ATMEGA/x51 ale je to navržený řekl bych dost logicky a genericky (stejné periférie se stejně konfigurují na M0/M3/M4). Nepoužívám SPL ani HAL od STM. Je jednodušší těch několik registů nastavit a netahat si do projektu hromadu zbytečnýho kódu.

Čipy nejsou bez chyb, ale dovolím si tvrdit s ohledem na množství funkcí, že v normálu. Samozřejmě, čím větší a novější kladivo, tím víc chyb. Ale zase to celkem opravujou :wink:

Ještě jedna výhoda arm cortex m0/m3/m4 core je v tom, že určitej základ je ve všech (všech výrobců) stejnej - systémovej časovač, systémové vyjímky atd.

Pokud Tě zajímá něco konkrétního, tak se ptej, téma je dost obsáhlé aby se dalo obsáhnout v jednom příspěvku.

Ptát se konkrétně budu, ale možná tak za čtvrt roku, teď zrovna řeším nějaký existenční věci a elektroniku aktuálně moc nedělám. PICy mám “celkem zmáklý”, tam vím na co se ptát, ale konkrétní otázky s ARMy by se vynořily, až by s tím člověk něco dělal. Ale každopádně dík za příspěvek, a doplním to o zjištění, která jsem ohledně něj učinil aktuálně:

Keil MDK lite - omezený do 32KB kódu; jestli to běhá i pod Linuxem jsem se nedozvěděl; za registraci - nechce se mi, po tom, co ze mě u NXP udělali kkta mám k tomuto postupu jistou nedůvěru. Kdybych to nutně potřeboval tak bych to asi musel zkousnout (i když i tohle mě dost se*e, že na to ti výrobci hřeší, že když to někdo fakt potřebuje “tak prostě musí”), ale nepotřebuju, neživí mě to. Ceny vyšších verzí jsem se nikde nedozvěděl, všude “napište nám” (a my už si tě zpracujem).

Hledáme to nejlepší možné z čehokoliv pro amatérskou scénu a začátečníky (a nejlépe nativního, neomezeného, svobodného, pokud možno) - žádné “upiš se nám” by to obsahovat nemělo. Možná jsem trochu idealista když myslím na amatéry, a možná budeme vyvedení z omylu :smiley: Ale porovnání s TI je celkem vtipné - prostě kliknu a stahuju (dál nevím, zatím jsem neinstaloval, klidně doplňte).

Jó TI, to je na eclipsu… :wink:

MDK lite - na M0 s tím uděláš spoustu věcí, takže to smysl pro dost lidí má.

KEIL3 pro x51 kolega provozoval ve WINE na linuxu. Jestli budou chodit vyšší verze pro ARM nevím. Ceny vostrejch verzí jsou řádově v tisících euro.

Pokud chceš mít všechno free, ideálně na free OS a aby to dobře chodilo, tak to budeš mít těžký. ARM GCC je ok, ale ty návaznosti jako nějaký prostředí a třeba ladění přes JTAG/SWD si budeš muset vyladit sám. Prože, jakmile začně nějakej projekt opravdu fungovat, obvykle se přesune z verze for-free na verzi for-cash.

ps: Registrace mě taky serou (mám na to garbage mail), ale dokud za to dostatnu co chci, tak budiž.

pps: Prostředí je absolutní základ. To rozhoduje, jestli to dáš nebo ne. Pokud teda nejseš nejakej geek :slight_smile:

ppps: Začít a pochopit můžeš i na nepreferované konfiguraci - usnadní Ti to přechod na něco jiného, protože pak řešíš míň problémů současně.

Zdravím, uvítal bych pokračování na téma Keil a STM32. Klidně heslovitě a třeba samostatné téma vedle. Postřehy k instalaci, jak založit nový projekt pro určitého brouka, jak postupovat v odlaďování a debug, jednoduchý projekt pro blikajicí ledku. Pokud bych mohl poprosit.

Tak jo. Založ tématické vlákno, začni instalovat, zkus založit projet atd… a až narazíš na problém, postni dotaz a společně se to tu pokusíme vyřešit.