forum.mcontrollers.com - hlavní stránka forum.mcontrollers.com - fórum

 

.: fórum - hlavní stránka :.
FAQFAQ HledatHledat Seznam uživatelůSeznam uživatelů Uživatelské skupinyUživatelské skupiny RegistraceRegistrace
ProfilProfil StatistikaStatistika Soukromé zprávySoukromé zprávy PřihlášeníPřihlášení

 
XC8-pomalý překlad
Jdi na stránku 1, 2  Další
 
Přidat nové téma   Zaslat odpověď    Obsah fóra mcontrollers.com -> Microchip
 
Teodor
Nováček
Nováček


Založen: 20.2.2020
Příspěvky: 3

PříspěvekZaslal: 03 duben 2020, 23:17    Předmět: XC8-pomalý překlad Citovat

Čau chlapi a dámy 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 Sad
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Teodor
Nováček
Nováček


Založen: 20.2.2020
Příspěvky: 3

PříspěvekZaslal: 04 duben 2020, 22:26    Předmět: Re: XC8-pomalý překlad Citovat

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



Teodor napsal:
Čau chlapi a dámy 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 Sad
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Billy Bob Bean
Profesionál
Profesionál


Založen: 21.9.2009
Příspěvky: 335
Bydliště: OLOMOUC - BRNO

PříspěvekZaslal: 06 duben 2020, 14:43    Předmět: Citovat

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.

_________________
Stavím UPSky
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Mahoney
Profesionál
Profesionál


Založen: 26.12.2013
Příspěvky: 160

PříspěvekZaslal: 07 duben 2020, 13:38    Předmět: Citovat

To je bohužel smutná pravda Sad

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á.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Billy Bob Bean
Profesionál
Profesionál


Založen: 21.9.2009
Příspěvky: 335
Bydliště: OLOMOUC - BRNO

PříspěvekZaslal: 07 duben 2020, 14:04    Předmět: Citovat

Mahoney: Tak nějak jsi to shrnul a zhrunul 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

_________________
Stavím UPSky
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Mahoney
Profesionál
Profesionál


Založen: 26.12.2013
Příspěvky: 160

PříspěvekZaslal: 07 duben 2020, 14:28    Předmět: Citovat

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š.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Ted
Anonymní





PříspěvekZaslal: 08 duben 2020, 10:36    Předmět: Error Citovat

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.





Mahoney napsal:
To je bohužel smutná pravda Sad

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á.
Návrat nahoru
 

 
Mahoney
Profesionál
Profesionál


Založen: 26.12.2013
Příspěvky: 160

PříspěvekZaslal: 08 duben 2020, 17:30    Předmět: Citovat

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 Very Happy

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é.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Ted
Anonymní





PříspěvekZaslal: 08 duben 2020, 19:45    Předmět: Souhlas Citovat

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.


Mahoney napsal:
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 Very Happy

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é.
Návrat nahoru
 

 
Martin
ATmega pouzivatel
ATmega pouzivatel


Založen: 5.1.2008
Příspěvky: 1548

PříspěvekZaslal: 08 duben 2020, 20:41    Předmět: Citovat

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

https://www.tme.eu/sk/details/esp32-wrover-16/moduly-iot-wifi-bluetooth/espressif/esp32-wrover-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

https://www.tme.eu/sk/details/wiz850io/moduly-ethernet/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)

https://www.tme.eu/sk/details/esp32/moduly-iot-wifi-bluetooth/espressif/esp32-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

https://www.tme.eu/sk/details/esp32s2-wroom-32/moduly-iot-wifi-bluetooth/espressif/esp32-s2-wroom-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

https://www.tme.eu/Document/18ca9048e8faaf453430b872452cab92/esp32-s2_datasheet_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
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Ted
Anonymní





PříspěvekZaslal: 09 duben 2020, 10:28    Předmět: ESP32 Citovat

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



Martin napsal:
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

https://www.tme.eu/sk/details/esp32-wrover-16/moduly-iot-wifi-bluetooth/espressif/esp32-wrover-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

https://www.tme.eu/sk/details/wiz850io/moduly-ethernet/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)

https://www.tme.eu/sk/details/esp32/moduly-iot-wifi-bluetooth/espressif/esp32-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

https://www.tme.eu/sk/details/esp32s2-wroom-32/moduly-iot-wifi-bluetooth/espressif/esp32-s2-wroom-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

https://www.tme.eu/Document/18ca9048e8faaf453430b872452cab92/esp32-s2_datasheet_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
Návrat nahoru
 

 
Billy Bob Bean
Profesionál
Profesionál


Založen: 21.9.2009
Příspěvky: 335
Bydliště: OLOMOUC - BRNO

PříspěvekZaslal: 09 duben 2020, 12:31    Předmět: Citovat

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.

_________________
Stavím UPSky
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Martin
ATmega pouzivatel
ATmega pouzivatel


Založen: 5.1.2008
Příspěvky: 1548

PříspěvekZaslal: 09 duben 2020, 14:43    Předmět: Citovat

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.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Radius
Profesionál
Profesionál


Založen: 22.2.2013
Příspěvky: 540

PříspěvekZaslal: 12 duben 2020, 21:51    Předmět: Citovat

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.
_________________
x51 , ARM , XILINX
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovy WWW stránky
 

 
Mahoney
Profesionál
Profesionál


Založen: 26.12.2013
Příspěvky: 160

PříspěvekZaslal: 12 duben 2020, 22:46    Předmět: Citovat

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.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

Zobrazit příspěvky z předchozích:   
Zobrazit předchozí téma :: Zobrazit následující téma  
Přidat nové téma   Zaslat odpověď    Obsah fóra mcontrollers.com -> Microchip Časy uváděny v GMT + 2 hodiny
Jdi na stránku 1, 2  Další
 
Strana 1 z 2
Přejdi na:  
Můžete přidat nové téma do tohoto fóra.
Můžete odpovídat na témata v tomto fóru.
Nemůžete upravovat své příspěvky v tomto fóru.
Nemůžete mazat své příspěvky v tomto fóru.
Nemůžete hlasovat v tomto fóru.
Můžete k příspěvkům připojovat soubory
Můžete stahovat a prohlížet přiložené soubory
 



Copyright © 2020 Rudolf Veselý, mcontrollers.com.
Je zakázáno používat části tohoto webu bez souhlasu autora.