Dost. z IAR Embedded Workbench subor zroz. pre dsPIC30F6014?

zdravim.
mam taku jednoduchu otazku. ako dostanem z compilera (ide prostredia) IAR Embedded Workbench for dsPIC V1.40A subor, ktory bude zrozumitelny pre dsPIC30F6014 (dsPIC PRO 3 development board od mikroelektronika)? hladal som to, skusal ale jednoducho mi to nejde. napriklad tu:
phytec.com/kb/index.php?article=61

sice to ulozi nejaky .hex subor, ale po nahrani cez dsPICFLASH do mcu vobec nefunguje. kompilovany kod je isto funkcny, lebo na skusku som ho ako prve skompiloval v microC dsPIC. ak by to niekto vedel, bol by som vdacny za strucny zrozumitelny postup. velmi dakujem.

preco nepouzivam microC ked odtial bez akychkolvek nastavovani “vylezie” .hex funkcny subor? :smiley: jednoducho c++ je pre mna olej do motora :laughing: , a nepoznam ine prostredie pre mcu v ktorom sa da programovat v c++.

:arrow_right: administrator: příspěvek byl upraven
:arrow_right: administrator: přejmenováno z "iar embedded workbench"

GCC :slight_smile:, ale neviem o tom, ze by na PIC. Okrem toho to nie je vlastnost prostredia, ale kompilatora. Mozno Ti tato info pomoze skombinovat funkcne s nefunkcnym.

A nahodou toto nieje c++ do MPlabu pre 30F procesory ???

MPLAB_C30_v3_00-StudentEdition

tak toto: MPLAB_C30_v3_00-StudentEdition urcite nie je c++ do mplab-u. uz v nazve je c a nie cpp. ak som si dobre prelozil s mojou mentalnou eng, tak tu:
ww1.microchip.com/downloads/en/D … 0v3_00.htm

je napisane: C filename extension is used, the compiler assumes that the file is a C++ file, which is not supported. co dost jasne naznacuje ze nie je podporovnany c++ :wink:

:arrow_right: administrator: příspěvek byl upraven

A je to az taky problem c a c++ ?

Na urcitu triedu uloh a urcite navyky ako rozdiel medzi autom a lietadlom.
Kazde je vhodne pouzit na ine riesenia. A neda sa ani povedat, co je lepsie. Autom sa dostanes tam kam lietadlom, ale to trva omnoho dlhsie, cesta je vsak zaujimavejsia. Cestovat lietadlom v ramci sidliska asi nie je moc vhodne, ale uz do Kosic by som volil radsej to lietadlo.

A je to az taky problem c a c++ ?

uplne velky. pre mna najvacsi. ked potrebujem (co som este nepotreboval) len procedurovo cize c, tak to mozem krasne a jednoducho pisat tak isto v c++, ba dokonca jednoduchsie. tak uvediem priklad aby to neboli prazdne reci. struct v c++ nemusim po zadefinovani furt pisat ako maly. cize:

struct nieco {
   int a;
   int b;
};
nieco n;
n.a = 10;
n.b = 15;

ked definujem strukturu “nieco” nemusim tam pisat struct. dalej struktury v c++ mozu dedit, a co je najdolezitejsie (pre COM - component object model) struktury v c++ mozu mat funkcie. a to vsetko sa da vyuzivat bez OOP v c++. je tam toho samozrejme viac. prirovnanie k lietadlu a aute by som to fakt nedaval. skor bicykel a motorka. dojdes s bike sice (relativne) tam kde s motorkou, ale motorka je jendoznacne rychlejsia, pohodlnejsia a viac si na nej uzijes :smiley: .

dost som odbocil, dolezite je, ze sa mi nepodarilo rozbehat ten IAR.

Nic proti vyhodam C++, len by ma zaujimali pamatove naroky algoritmu vyjadreneho v C++ a toho isteho v C. Kdesi som cital studiu, ktora uvadzala pomer okolo 1 : ( 2 az 3 ) v kode i rychlost v neprospech C++. Priblizne to iste plati i pre pomer medzi C a ASM. Uz si nepamatam, ake vsetky ficury boli z C++ v teste pouzite, ale pre mnohych na tomto fore (nic v zlom :slight_smile: ) je na jednocipy nestravitelne i samotne C, nieto este C++. Ak by sa tu dala urobit nejaka osveta C++, budem rad, aspon sa to samotne C lahsie vstrebe :slight_smile:

Martin:
Ano tyhle nezory zde na foru me vzdycky pobavi. Jen mam dojem, ze je zde siri povetsinou uzivatele GCC. On je zasadni rozdil mezi nejakym a kvalitnim compilerem. Ja si treba u blbyho C30 pro DSP Microchipu snadno muzu prohlidnout co mi udela pridana podminka nebo nejakej floating vypocet. A muzu rict ze casto zasnu s kolika instrukcema to compiler chrousta (jako ze s velmi malo). Na druhou stranu vim, jak kolegovi zdrojak slozenej z podminek zere v Atmelu mnoho kilo pameti.
To je co se kodu tyce. Co se tyce realne pouzitelnosti pro rychly vyvoj a modifikovatelnost, tak ASM je pro 95% aplikaci davno mrtvy pro prime psani kodu. Pokud si chcete hrat, tak si hrajte. Ale pro realnej vyvoj jsou tyhle uvahy opravdu davno mimo.
Aby nedoslo k omylu… znat ASM a jeho pravidla a priblizne jeho interpretaci funkci v C je NUTNOST. To je mimo diskuzi. Clovek muze psat pohodlne a rentabilne zdrojakt v C, ale musi mit kdesi v hlave na pameti, ze to proste pujde do MCU.

P.S. Kamarad mi rikal, jak u nich ve firme maji sefa, kterej je starej vyvojar assemblerista. Prej jen tak obcas zkusi neco co vyvojari delaji v C zkutit v ASM. No a vetsinou prijde za dva dny s necim co oni odladi za par hodin. :slight_smile: Ale jako vedouci je prej velmi dobrej.

Aj mna velmi bavia ludia co sa tvaria, ze vedia o com je rec.
Informacie o pamatovych narokoch na program vychadzaju zo zdrojov IAR, ktory oznamil zavedenie ec++ (podla Chucka asi urcite kvalitny kompilator :slight_smile: ). Je pravda, ze tie pomery som si nezapamatal spravne. V zdroji z ktoreho som cerpal, (Burkhard Mann: C pro mikrokontrolery, str. 178-179) sa vyslovene uvadza:
C 25347 B
EC++ 56526 B
C++ 312926 B bez exception handling
C++ 378466 B s exception handling

za nepresnost sa omluvam :slight_smile: :slight_smile: :slight_smile:

osobne som to neoveroval. Myslim, ze zdroj je dostatocne vierohodny.
Aj napriek velkemu rozdielu si nemyslim, ze C++ je pre jednocipy blbost.
Ak niekomu vyhovuje a vysledny program je rychlostne i velkostne zmestitelny do vybraneho procesora, preco nie.

To dokedy si budu niektori jedinci mysliet, ze Linux je napisany v nejakom kompileri? :smiling_imp:
Videl pisatel napriklad dokument AN52-ARM-C-Benchmark.pdf ? Ale co sa vobec pytam :slight_smile:
OSobne robim na ATmega + GCC. Skusenosti mam este s ICC od ImageCraftu, ktory som po porovnani s GCC rychlo zahodil. Nikdy som vsak netvrdil, ze GCC je jediny a najsam. To je jednoducho blbost.

Este moze byt rozdiel vo vykone v ramci portovatelnosti. Pred casom som tu viedol s Technikom (nie len) velku diskusiu (zaujemcovia si lahko najdu), v ktorej on namietal proti pouzivaniu C-cka na jednocipoch. Hlavne argumenty boli mensia efektivita kodu, casova narocnost, nejednoznacnost prekladu nejakeho zapisu a hlavne ze programator nevie kde, co a ako ma prelozene. Jeho priklady som naprogramoval a tu zverejnil aj vysledok. Preklad bol v sulade s poziadavkami Technika. Neobhajujem nikajo zvlast GCC. Jednoducho v nom robim a som spokojny.
Ked som volakedy patral po tom, ako prelozi to ci ono, nenaprogramoval by som to v ASM v zasade vyrazne kratsie. Skor rovnako. Teraz to uz neriesim, je to uplne zbytocne. Kto by uz skumal, ci by napisal 40kB kod do mensej pamate. To je totalna strata casu, hlavne ak sa treba programovanim zivit. Pre istotu by som vsak netvrdil, ze C-cko vygeneruje kod velkostou blizky tomu pisanemu priamo ASM. Tu sa drzim vseobecnych nazorov roznych vedeckych a skolskych institucii, ktorych pokusy statisticky ukazuju na pomer zhruba 1:2.
Samozrejme, nie kazdy by vedel v ASM napisat naozaj velmi efetivny kod.

Uplne ina vec su pridane hodnoty vyrobcov kompilatorov, ako napriklad konfortne IDE (tu ma este AVRstudio co dohanat, preto je dobra alternativa ako IDE pouzivat CodeBlock alebo nieco podobne), casovy analyzator kodu atd. Tieto nastroje ale nie su kompilatorom.

To si fakt niekto mysli, ze GCC nepodporuje prezeranie asembleru i po C-ckovych instrukciach, ze sa po nich neda trebars aj krokovat? To tu fakt ziju taki mudrlanti?

Absolutne suhlasim a s tychto dovodov tu budem vzdy C-cko obhajovat (bez ohladu na kompiler).

Absolutne nepravdiva a zavadzajuca informacia. Pre programovanie jednocipu v Ccku nie je potrebne poznat ziadnu asm instrukciu. Ziadna vedomost nie je na skodu, ale nevyhnutna rozhodne nie je. Ucil som niekolkych ludi pracovat s ATmegou. Bez akejkolvek zmienky (okrem tej, ze ho nepotrebuju poznat) o ASM a bez problemov si programuju co potrebuju. Tak isto, ako programatori v PC nepotrebuju proznat ASM x86-tky. A je jedno ci robia nejaky .NET, alebo komunikacnu konzolovku. Tak isto, ASM nepotrebovali poznat programatori pod DOS-om.
Co je potrebne poznat, su nazvy hw registrov a ich bitov, ktorymi sa riadia periferie jednocipaku. To ale nie je ASM.

A co ma ta informacia v hlave spolocne s poznanim ASM? Bud sa vysledny program do pamate vybraneho MCU zmesti, alebo nie. A ked nie, treba bud optimalizovat, alebo vybrat iny MCU. Vysledky optimalizacii sa vsak prejavia zmensenim kodu, nie rozoberanim a porovnavanim ASM instrukcii. Tu jednoducho staci dodrzovat vseobecne pravidla pre tvorbu efektivneho kodu v C-cku.
Okrem toho som si neni isty, ci by zacinajuci programator na jednocipoch v C vobec vedel posudit, ze by rozasemblovane to ci ono vedel SKUTOCNE optimalnejsie naprogramovat v ASM. A ak sa ten jedinec najprv nauci ASM a spravi si v nom vsetky zakladne podprogramy, nemusi mat velku motivaciu k C-cku vobec prejst.

Ako som uz pisal v inych diskusiach myslim, ze o presadzovanie ASM na jednocipy ako jedinej pravovernej cesty sa staraju stari bardi, ktori maju odladene svoje ASM rutinky a subrutinky, maju navyky a preto im takato praca vyhovuje.
Zacinajucemu adeptovi programovania by som rozhodne doporucil C-cko, lebo je to jazyk omnoho jednoduchsi na syntax, vyrazovo a algoritmicky omnoho bohatsi a prehladnejsi a hlavne sa nadobudnute vedomosti a napisane kody daju pouzit na roznych procesorovych platformach.
Ak niekomu dojde pamat v ATtiny25 bude asi jednoduchsie/lacnejsie a rychlejsie kupit ATtiny45, ktora je o 0.7EUR drahsia. Ak ovsem nejde o duchovne cvicenie a ekvilibristiku. Tu ale proti gustu ziaden disputat. :slight_smile:

Nevim proc tak jedovate podrobne rozebiras kazdou mou vetu. Beres to trosku zbytecne osobne. To ze jsem odpoved adresoval pro zacatek Tobe neznamena ze byla proti Tobe. Ani nebyla konkretne proti necemu cos psal takze hned moje prvni veta kterou vyseknul nebyla o C++ jak me hned poucujes.
Druhej vysek: zkusenosti by byly jak s GCC i IAR a promin dle me je IAR krapet jina liga co se prave optimalizaci. Ale SORRY opet mluvim o C.
Treti vysek: Opet jsem nemluvil o prepnuti se do rezimu kompilovaneho ASM a jeho krokovani.
Ten zbytek se tykal optimalizace a to treba uz behem psani kodu. Tu NUTNOST co jsem napsal jsi taky nepochopil. Ale zase mas potrebu me chytat za slovicko. Jiste ze lamka ktera nezna MCU ale zna C napise pri seznameni se hrube s periferiemi a registry MCU funkcni zdrojak. Ale pokud nebude mit na pameti ze treba pracuje s malym 8bit MCU bez matematickych periferii tak jednak velikost zdrojaku a doba zpracovani nesikovne a nerozumne napsanejch procedur v C muze nekoho samozrejme vydesit a to je asi najvetsi kamen urazu. Pokud nekdo potrebuje delat neco co funguje krapet pouzitelne. To je vec za kterou si stojim a na projekty si vybiram jen studenty se zakladni znalosti ASM. Klidne me za to sudte.
Ale zacalo to byt osobni takze to stejne jako diskuze nema cenu. Obzvlast kdyz mas tak moc dojem ze s tebou nesouhlasim.

Tazko nebrat osobne prve dve vety v Tvojom predchadzajucom prispevku.
Pobavenie spojene spouzivatelmi GCC (v podstate vycucanym z prsta) v suvislosti s mojim C++ podporujucim prispevkom.

Ale samozrejme, ze to neberiem osobne :slight_smile: . Ani ma to nenapadlo ani ma taketo pristupy nezaujimaju a ani na take nieco nemam cas. Kazdy ma pravo na svoj nazor a prirodzene na jeho obhajobu.

Ale o to mi nejde. Je chybou moj prispevok brat ako “jedovaty”. Vety som rozoberal, len aby bol jasny suvis mojej reakcie. V ziadnom pripade som Tvoj prispevok nebral ako utok, skor som to bral ako vyzvu na uvedenie konkretnych informacii v ramci sirsich suvislosti. Myslim, ze sem tam nejaka polemika moze byt iba na prospech. Uz sa tesim na dalsie. Osobne si vazim kazdy nazor podporeny argumentami. Co nemam rad, su silacke reci. Ale tych sa nastastie vyskytuje na tomto fore velmi velmi malo.