prechod z ASM na C

Mikrokontroléry Jiné
21

Přeci nejde o to, kdo bude vítěz a kdo poražený. O to mi nejde a není to předmětem diskuze. Není to zápas Sparta - Slávie.
Od okamžiku, kdy jsem napsal, že C je pro 8b MCU spíše na hraní, popudil jsem tím Martina a on vykopal válečnou sekeru. Od toho okamžiku reaguje emotivně jak býk na červený hadr na vše co napíšu aniž by si to pořádně přečetl.
Vraťme se k původní otázce tazatele:
“Jak těžký je přechod z ASM na C - je to jen další stupeň ASM, nebo je třeba úplně změnit uvažování při konstrukci programu?”
Odpověď: Je těžký a je nutné změnit uvažování při konstruci programu. Tedy pokud si s tím nechce jenom hrát. Zatímco v ASM se člověk těch 118 instrukcí naučí za chvíli, v C je toho mnohem víc a má to své záludnosti a o některých jsem už psal. Programátor ASM se musí ještě naučit elementární věci jako je aritmetika jedno i více byteová, vytvážení polí, buffferu atd. čehož je uživatel C do značné míry ušetřen. Díky tomu se o to nezajímá.
Programátor vždy řeší jen to, co vidí na obrazovce, nezajímá ho to, co je zatím jak se to přeloží. Takže když deklaruje dvourozmerné pole
int Data[10][20]
asi netuší, že je to totéž co
int Data[200]
Rozdíl je pouze ve výpočtu adresy, kdy pro n-rozmerné pole je potřeba n násobení. Programátor v ASM si toto musí odpracovat na vlastní kůži, ale za to dobře na to vidí a nekonstruuje zbytečné složitosti. Jinými slovy přemýšlení nad “ASM” je jiné než nad “C”.
Vyjádřil jsem se s určitou nadsázkou, že C je trochu jako svěrací kazajka. Je to stejné, jako když se staví dům. Lze ho postavit jen z toho, co seženu ve stavebninách. Nemohu zdít příčku 12cm tlustou, když cihla má 15cm. Pokud se rozhodnu stavět z betonu (analogie k ASM), odleju si příčku třeba 11,5cm. Když bude programátor stát před problémem, jak udělat např. pole stringů s proměnlivou délkou, céčkař je v koncích, protože pole Ansistring není v C, ale jen v C++ a mám pocit, že je to pouze výsada borlandského C++. Asmblerista má možnost se pokusit to naprogramovat v rámci vybraného MCU. Pakliže neuspěje, není ani šance pro céčkaře.
Podobné to je u dynamického přidělovaní paměti (malloc, free). To je přeci geniální řešení alokovat si paměť, když ji potřebuju a pak ji uvolnit zvláště u MCU, kde mi paměť schází. Bohužel je to tak složitý algorytmus, že si nedokážu představit, jak to na nějakém MCU s 2KB RAM bude efektivně fungovat, když nemá MMU ani DMA. Možná tak na Xmega, ale na ty si budeme muset ještě chvíli počkat. To je lepší podívat se na celý program, jestli některé proměnné nebo pole nemohou být překryvné. A tak bych mohl pokračovat do nekonačna.

Koukl jsem se na odkaz, který uvedl Martin:
mikrocontroller.net/articles … C-Tutorial
To, co se zde uvádí v příkladech, je opravdu jen na hraní. Přeci žádný rozumný programátor nemůže ani na vteřinu uvažovat o tom, že by program měl někde uvíznout v nekonečné čekací smyčce na přijetí znaku z UARTu. Takže, když nic nepříjde, tak to celý zamrzne. Takto se programy opavdu kostruovat nedají.
A nakonec ještě jednu perličku z onoho serveru.
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
Každý, kdo se tím profesionálně zabývá ví, že toto nemůže vždy napsat. Asmblerista by použil instrukci CBI PORTA,MEINBIT a tím je z obliga.
Pokud existuje přerušení v němž se manipuluje s PORTA, vzniká konflikt, pokud překladač to přeloží takto:
IN R16,PORTA
CBR R16,(1 << MEINBIT)
OUT PORTA,R16
Pokud příjde přerušení po 1. nebo 2. instrukce, je to stejné,jako by se nekonalo.

22

O tom nech si urobi nazor citatel sam.:slight_smile: :slight_smile: :slight_smile:
Nikdy som sa nevyjadroval sposobom typu "Navíc použávaš citace, které jsem zjevně nepsal. Já totiž zásadně nepíšu slovensky! " a “Vždyť je to přeloženo naprosto blbě!” ak to este k tomu nie je pravda. Ale beriem to ako text napisany v “zapale boja” :slight_smile:. Ak som Technika niecim popudil, je mi to luto, nebol to moj zamer. Iba som sa snazil vyvratit tvrdenia, ze C je na 8b hrackou. Nikto mi toto moje tvrdenie nevyvratil a nepouzil relevantne argumenty v kontexte 8b, ktore som uvadzal (ATmega32/64/128). Padli tu hlavne argumenty upozornujuce na zaludnosti samotneho C. S tymi suhlasim, ale netyka sa to temy , preco by C malo byt len hrackou pre 8b. To co sa da v GCC “vykuzlit” sa da pozriet z odkazov ktore som pripisal k mojmu predchadzajucemu prispevku. Aj ked samozrejme sa to da i v ASM a urcite rychlejsie.

Urcite ano, s tym sa da len suhlasit

V kazdej ucebnici C s ktorou som prisiel do kontaktu v kapitole venovanej poliam a strukturam je presne vysvetlene co sa kam v RAM uklada i pri viacrozmernych poliach. Je to potrebne vediet, ak clovek spracuva pole pomocou ukazatelov, co casto velmi sprehladnuje a zjednodusuje program.

ach jaj :slight_smile:
Je pravda, ze C nepozna premennu string, ale pole charov po plne zvladne.

Herout str.224
ako sa robi pole retazcov s premenlivou dlzkou.

char *p_text[3]
p_text[0] = “prvy”;
p_text[1] = “druhy”;
p_text[2] = “popokatepetl”;

a potom v programe napriklad

…
printf('%s \n",p_text[1]);
…

pre koho by bol printf prilis narocny na pamat, tak aj

…
char *p_pom = p_text[0]
while (*p_pom != ‘\0’)
putchar(*p_pom++);
…

prekladac vlozi \0 za kazdy retazec pri deklaracii tych ukazatelov.

(dufam, ze tuto moju reakciu nebude nikto povazovat za vykopavanie vojnovej sekery, iba sa snazim uviest priklady [aj inokedy] ako programator v C nie je v koncoch a pripravuje ho na to bezna ucebnica C pre zaciatocnikov)

s 2kB pre C ani neuvazujme. Az ked su k dispozicii varianty s 16 a viac kB a aspon 1kB RAM, ma zmysel hovorit o C, dovody som pisal daleko vyssie. Malloc a free su naozaj velmi zrave na pamat. Okrem toho mame vo firme pravidlo, ze v case spustenia aplikacie MUSI byt jednoznacne dane, kolko pamati sa na jej potreby minie. Ak by bola chyba v programe, ktora by pomocou malloc alokovala i to co nie je, je to v rozpore so snahou o bezpecny chod aplikacie v zmysle jej prevadzkovej bezpecnosti. To pouzitie malloc a jemu podobnych uplne vylucuje. Tu by som sa tiez odvolal na diskusiu , ktoru spomynal Technik v suvislosti s bezpecnostou. Je dobre si ju precitat. Inak tie normy som si kupil a su tam veci, ktore sa daju dobre dodrzovat i za podmienok nevlastnenia certifikovaneho prekladaca. Ten okrem toho norma exaktne ani nepozaduje.

Mozem Technika ubezpecit, ze C vie rovnako dobre narabat i s prerusenim a moznost cakania az sa prijme znak v nekonecnej slucke nie je vysadou vylucne Ccka. Okrem toho musim podotkut, ze pisatel dokumentu pisal text pre zaciatocnikov. A tym sa spravidla “ukazuje” ako blika LED tak, ze sa medzi jednotlive zmeny vlozi dost dlha slucka. Tu je to asi podobne. Nechcem autora obhajovat, mozno sa to dalo napisat i inak, didaktickejsie a celkovo lepsie. Ale to stale nie je dovod, preco by malo byt C pre 8b nevhodne. A o to v tejto diskusii ide. Aspon si este stale myslim :slight_smile:

No ved, to. :slight_smile: Tieto tvrdenia su pravdive, az na to,ze prekladac mi vygeneroval nasledovny kod (je to kusok skopirovany s disasemblera a vytrhnuty z celku, za pochopenie dakujem :slight_smile: )

481: if (b_prvy_prechod) PORTA &= ~(1 << 4);
+0000FDB5: 2300 TST R16 Test for Zero or Minus
+0000FDB6: F019 BREQ PC+0x04 Branch if equal
+0000FDB7: 98DC CBI 0x1B,4 Clear bit in I/O register
+0000FDB8: E000 LDI R16,0x00 Load immediate
+0000FDB9: CFD3 RJMP PC-0x002C Relative jump

Takze presne to, co by ocakaval Technik. :slight_smile:
To co vidim a na co reagujem nie je cervene sukno :slight_smile:
Autor toho dokumentu pisal popis pre GCC. Vie, ze GCC sa v tomto pripade sprava voci pinom korektne. Preco by to potom nezapisal
“PORTA &= ~(1 << MEINBIT);”
Co je na tom chybne? To, ze na inych prekladacoch to moze byt inak je mozne, ale tu to tak nie je. Ak sa niekto bude zaujimat o iny prekladac ako je GCC, ku ktoremu je spomynany text napisany, musi si samozrejme nastudovat jeho nuansy. Nikdy som netvrdil, ze naucit sa pracovat s C je lavou zadnou. Vsetko sa predsa treba naucit. I to C a jeho konktetnu implementaciu.
Iste ze sa najdu veci, kde by prerusenie bohlo robit problem. Programator si toho musi byt vedomy. Ak nie je a narazi, tak sa pouci a bude si davat vacsi pozor. O tom sa tu uz predsa pisalo a nema zmysel opakovat, ze je jedno ci sa to tyka ASM alebo C, alebo BASCOM, alebo neviem coho este. Ani toto sa mi nevidi ako argument, preco by bolo C hrackou pre 8b. Tak prosim skuste dalej.

Prajem vsetkym prijemne nedelne odpoludnie :slight_smile:

23

Promiň, ale musím Ti oživit paměť. V Tvém příspevku z 08 listopad 2008, 16:30 je 6 citací, všechny nadepsány Anonymous napsal:, z nichž jen 5 je z mého příspěvku. Tehdy jsem se zapomněl podepsat. Text 6. citace není můj.

To není pole s promenlivou délkou, ale konstantní. Pointer má velikost vždy 2B (tedy v našem případě). První řádek alokuje paměť velikosti 6B a ta se v průběhu programu nemění. Další 3 řádky nastaví pointry na konstanty umístěné v kódovém segmentu. Deklarace s proměnou velikostí by mohla vypadat takto:
Ansistrind text[3];
Množství textu uchovávavjícího v text* je omezeno pouze velikostí dostupné paměni a mění se za běhu programu. Ansistring není proměná, ale je to třída. Důvod je zřejmý. Berme toto jako ilustraci k následujícímu modelovému příkladu.

Zařízení tvořené třeba ATmega32 bude příjímat po sériové lince povely a data v paketech s různou délkou. Bude je zpracovávat, ale né v pořadí v jakém přicházejí. Bude tudíž nutné povely někde skladovat do vyřízení. Po vyřízení jsou už zbytečné a zruší se, aby uvolnily místo pro nové. Jak je ukládat a jak zařídit přidělování a uvolňování paměti?

V ASM na to existuje docela jednoduchý princip, jež by se teoreticky dal přepsat i v C, ale výsledek by pak byl dost žalostný. Tohle je poměrně nestandartní věc, která je řešitelná v C nebo C++ právě na větších MCU, tedy 32b. Řešení toku dat, jeho bufferování, zpracování přichází dost často na pořed dne právě u MCU mající ADC, PWM,UARTy, I2C, SPI,IC. Jejich výkon není až tak vysoký, aby svůj čas mohl utácet v neefektivě přeložených algoritmech. Takže ten, kdo chce 8b MCU využívat do mrtě, ať sáhne po ASM, a kdo tvoří algoritmy časově nenáročné, může se věnovat C.

Tak to si přesně udeřil hřebík na hlavičku. Nikdo nevyndavá deštník, dokud neprší, takže každý vlastně trochu zmokne. Stejně tak programátor - začátečník se nebude při programování pídit po problémech dokud nenastanou. Až nastanou, reakce pak bývá různá. Např.:“Oni za to mohou bludné proudy, je tam rušení.” Proto tvrdím, že by každý programátor a budoucí profík měl zvládnou ASM a seznámit se s problematikou algoritmů a jejich problémy v četně MCU, protože v něm to vidí jako na dlani. Teprve potom může postoupit výše třeba k C. Protože jinak nebude ani tušit, co v těch učebnicích a příručkách hledat a na co si dát pozor. Nikdo nehledá to, co nezná!*

24

Ano, to je Jan16. Chyba kopirovania autora textu 1x zo 6. Sorry, ale aj ten jeho prispevok je cesky pisuceho autora, okrem mojej citacie samozrejme :slight_smile:. O tom myslim uz nema zmysel diskutovat.

Ano to je uplna pravda. Pochopil som tvoje tvrdenie ako popis viacrozmerneho pola s roznou dlzkou jednotlivych “podpoli”, nie ako popis pola s dynamickou alokaciou. Preto som uviedol ten priklad. Nejedna sa o dynamicke pridelovanie pamate pre priklad, ktory popisujes. Ja som uviedol skor priklad vhodny pre rozne popisy na LCD. Pracujem s procesormi v systemoch s komunikaciou typu Master Slave napr.Modbus, InNet a podobne. V tychto systemoch nie je potreba nacitavat viac sprav s roznou dlzkou a neskor ich postupne spracovavat. Sprava, ktoru odosle master sa ma v stanici spracovat a odoslat vysledok. Ak sa vysledok neprijme v mastri do urciteho casu, vyhlasi sa timeout. V pripade multimastrovych systemov si mastre odovzdavaju “token” a situacia je potom rovnaka, ako pri jednomastovej sieti. Ale pre zaujimavost, ako by si to riesil v ASM? dynamickou zmenou indexov v ramci jednorozmerneho pola? Lebo ak naplnis za sebou napr. 15B a potom 25B,potom 15B “uvolnis” a potrebujes zapisat spravu 30B a chces vyuzit tych 15B, to uz dost zavana segmentaciou pamate. ale mozno existuje aj nejake elegantnejsie riesenie. Daj vediet.

V principe sa vyhybam dynamickym alokaciam z dovodov sw bezpecnosti. Teda ak moze prist viac sprav sucasne, musim zobrat do uvahy najhorsi mozny pripad a to je ten, ze vsetky spravy maju najvacsiu povolenu dlzku a zaroven musim vediet , kolko takych sprav moze najviac naraz byt. A i ten najhorsi pripad sa moze stat. Preto musim mat v pamati vyclenenych tolko bajtov, kolko je max. treba. Kedze malokedy budem vediet s istotou prejudikovat, ze tento stav nastane len vtedy, ak nejaka ina cast programu nebude potrebovat nejaku pamat urcite pre seba. Ale to sa da s urcitostou povedat malokedy. Potom sa cela uloha zjednodusi na dvojrozmerne pole s konstatnou dlzkou. Po preklade hned viem, ci mam dost pamate i pre ten najhorsi pripad. Ale velmi by ma zaujimalo ako by sa to dynamicke alokovanie riesilo v ASM.

Absolutne suhlasim a nikdy som netvrdil opak. Je to presne tak. A kto chce robit s BASCOMom, nech robi s BASCOmom. Jedine o co mi islo, ze C na 8b nie je iba na hracku. Tot vsjo. :slight_smile:

Vzdy so tvrdil, ze znalost ASM moze byt iba na uzitok.
Povedal by som , ze v ASM si clovek moze robit vsetko, co mu dana architektura umoznuje. Vyhne sa niektorym chybam, ktore mu moze (ale to neznamena ze musi) podsunut prekladac napr. z C. Preto je dobre vediet co a ako prekladac preklada.
Ccko ma vsak iny vyznam a to je ten, ze sa programator viac moze sustredit na abstrakciu rieseneho problemu a nie na to, ako tu abstrakciu prekoduje do ASM. Prekladac riesi za cloveka obrovske mnozstvo veci, v ktorych bezny smrtelnik vie narobit omnoho viac chyb a preslapov ako su tie potencionalne ktore moze zase zabezpecit prekladac. Ci uz sa jedna o rozvrhnutie RAM, zapuzdrenie premennych, typova kontrola, lokalne premenne - nemusim si pamatat, ze tato cast ram je niekedy k dispozii i inym castiam programu a niekedy zase nie a nemusim strazit tento stav. Myslim, ze velka cast beznych programatorov su schopni si tymito chybami - ak pracuju v ASM - zabezpecit dost prace a hladania na volny cas.
Okrem toho nie vsetci, ktori programuju potrebuju vzdy “vyzmykat” procesor co najviac a okrem toho nie kazdemu je aj “dane”, aby to zvladol, pripadne mal na to dostatok casu.
C-cko programatorov v mnohom od rutinnych veci oslobodzuje a zjednodusuje pracu. Zaroven ich - ako to priblizne nazval Technik - zosnoruje v preferovani strukturovaneho programovania. To moze viest niekedy k zlozitejsiemu vysledku, ale vo vacsine pripadov to zavadza do programovania aky taky poriadok a prehlad i do buducna. Opat podotykam, su aj lumeni, ktory sa bez toho zaobidu, ale pre vacsinu beznych programatorov to vnimam ako pozitivum.

Je to vsak za cenu o nieco dlhsieho a o nieco pomalsieho vysledneho kodu. Ccko v “zakladnej zostave” obsahuje omnoho menej veci na ucenie ako ASM. Hovorim o samotnom ASM, nie o poznani periferii, ich fungovania a nastavovania. V niektorej z diskusii som to aj uvadzal. Myslim, ze to bolo okolo 26 zakladnych poznatkov. To je oproti 118 instrukciam znacne menej a pritom v tom Ccku uz ide o cele progamove struktury. I preto si myslim, ze je na zaciatku programovanie v C “jednoduchsie”. ale ako uz uvadzal Technik, ma aj svoje uskalia.

zakladatel vlakna uz podla jeho slov ASM zvladol a uvazuje na C. Ak ma zaujem v C pracovat, ja mu nemozem nic ine, iba doporucit C na ATmega s perspektivou vyuzitia nadobudnutych znalosti ci uz v PC alebo na ARM, alebo uz na com len bude v blizkej ci dalekej buducnosti chciet. V ziadnom pripade nemozem suhlasit s nazorom, ze C je na 8b hracka :slight_smile: :slight_smile: :slight_smile:

Velmi by ma zaujimalo, aky ma na to vsetko zakladatel vlakna a ci mu nase prispevky boli v niecom prospesne.

25

Nevim, jak zakladateli, ale ja si pro jistotu pojistil 2 programky pracujici s prerusenim, ktere modifikuje I/O registry :wink: Manipulace s 1 bitem pri zapnutych optimalizacich neni problem, ale s vice bity najednou uz ano (tam uz se pouziva ldi, andi, ori, out). ty 2 makra (sei a cli) procesor k smrti neudřou :slight_smile:
Obcas clovek i v datasheetu narazi na problematiku “atomic” operaci, ale kazdeho hned nenapadne to resit vsude…

26

Představ si skladníka, který přijíma různě vysoké krabice na sklad a vrší je do stohu vždy tak, že je dává na vršek. Dokud je mezi vrškem stohu a stropem místo, může je přijímat. Ze stohu ale může brát ktabice odkudkoli, zespodu, zprostředka nebo i zvrchu. Pokud odebere z prostřed, všechny krabice nad ní spadnou dolu a mezera se zaplní. Také se zvětší prostor mezi vrškem a stropem.
Tak toto je základní filozofická myšlenka řešení. Má to několik háčků:

  1. 1KB dat se v paměti bude přesouvat min. 0,5ms při 16MHz u AVR. Data přijímana z UARTU by musela přicházet pomaleji takže by to bylo tak na max. 14400b/s
  2. Během přemmísťování dat nesmí žádný proces do nich zasahovat, ani číst ani zapisovat.
  3. V paměti musí být nějak označeny začátky paketů. Pokud by to byly pointery, jejich počet by se měnil. Pokud by to byly znaky (třeba null terminátor jako u char) musel by zpracující program neustále prohledávat paměť.
    Teď už jde jen o to, jak odstranit výše uvedené problémy. To ale nemohu prozradit, neboť je to součást výsledků mého bádání, za které jsem placen. Jistě každého programátora napadne nějaké řešení a určitě jedno z nich bude použitelné.
27

Ano, kdybychom chěli být důslední, tak by to byly 3 instrukce navíc
in R2,SREG ;schova stav I
cli ;
lds R16,PORTx
ori R16,1<<bitx
sts PORTx,R16
out SREG,R2 ;obnoví I do původního stavu

28

Zaujimavy problem. Pri jeho rieseni by som asi vychadzal z nasledovych predpokladov. Velkost RAM je presne ohranicena (8b v pohode splnaju :slight_smile:)
Mozem minut do 15% pamate na pomocne operacie a ulohy.

RAM pre spravy by som virtualne porozdeloval po 8B (je jedno ci cez ukazatele a heap, alebo ako prvky jedneho suvisleho pola, pricom dolne tri bity indexu urcuju poradie bajtu v sektore a horne bity cislo sektoru,index moze byt uint16_t). Kazdej osmici by prisluchal jeden bajt - identifikator v dalsom poli/tabulke. Pre nevyuzite sektory by tento bajt obsahoval hodnotu 0. Pre pouzite sektory poradove cislo prijatej spravy. Predpoklad je, ze procesor nebude naraz spracovavat viac ako 127 sprav. Tento predpoklad snad moze byt rozumny, inak by identifikator musel byt typu word.
Prijem spravy:
Pri prijme spravy jej pridelim poradove cislo.
Najdem prvy identifikator s hodnotou nula a vlozim don poradie prijimanej spravy + 128. Pomocou tej 128 rozpoznam prvy sektor pri dalsom spracovani. Do sektora, ktoremu tento identifikator patri, zacnem vkladat data. Kam sa maju data vlozit moze byt definovane ukazatelom, jeho dolne 3 bity mozu obsahovat poradie bajtu v sektore. Poziatocna adresa ukazatela sa da lahko nadefinovat. To su uz vychytavky pre optimalizaciu. Pre strucnost to budem to pisat bez nich.
Po naplneni sektora najdem najblizsi vyssi s nulovym identifikatorom a proces zopakujem, len uz k identifikatoru nepripocitavam 128. Takto postupne zaplnim tolko sektorov, kolko potrebujem. Ak dlzka spravy nie je jazna z jej kontextu, mozem ju mat odlozenu v nejakom poli. Ak si oznacim prvy sektor suboru, mozem takto hladat volne sektory dokolecka, ak by sa medzitym nejake vyprazdnili. Ak si nikde nepamatam poradove cislo sektora v sprave, potom to do kolecka plati obmedzene az to tzv. “pretecenia” naplnani sektorov. Bez pamatania si poradia sektora v subore mozem teda plnit data napr. sektor 7,8,10,26,57,2,4,5
ale uz nie sektor 7,8,10,26,57,2,4,5,9,13. Lahko sa ale spravi kontrola na takyto stav.

Spracovanie spravy:
Program prehladava identifikatory a ak narazi na nejaky nenulovy vie, ze je k dispozicii dalsia sprava. Ak jeho hodnota je>0 a zaroven <128 pokracuje v hladani identifikatora s najvyssim bitom nenulovym, Program vie, ze nasiel zaciatok spravy. Potom ju postupne nacita a spravuje. Po jej spracovani vsetky identifikatory, ktore ukazovali na sektory spravy vynuluje.

Ak budu spravy skor dlhsie ako kratsie, bola by asi lepsia volba velkosti sektoru 16B, pripadne 32B. Pri 16B bude redundantnost spotreby RAM v dosledku identifikatorov menej ako 10% a pri 32B este menej. RAM bude teda efektovnejsie vyuzita vzhladom na mensi pocet indentifikatorov.
Ale to zavisi od aplikacie. Pre casovu usporu by som sa snazil nepresuvat baliky dat, ale len menit ich identifikatory. Pri zmene dat treba bud zakazat prerusenie, alebo nastavit nejaky semafor.
Baliky dat sa sice nepresuvaju, ale riesenie ma samozrejme nevyhodu v nevyuziti celej RAM v poslednych sektoroch.
Toto riesenie predpoklada, ze sprava je ulozena, i ked rozkuskovana, v sektoroch za sebou. Ak by tento predpoklad nemohol platit, potom by som este identifikator rozsiril o poradove cislo sektora v sprave.

Tento moj popis prosim berte iba ako taku studiu, snad sa objavi niekto iny s lepsim riesenim. uz sa na to tesim. Len som si neni isty, ci to este patri do temy. Ale snad to tu admini este chvilku nechaju, kym sa neozve zakladatel vlakna, ako nakoniec dopadol. :slight_smile:

29

Neni uschovavani a obnovovani SREG zbytecne? avr preci maji i instrukci “SEI” (ma ji i tiny13, tak predpokladam, ze ji maj i ostani).
Snad jedine pro zamezeni zmenam ostatnich priznaku v SREG, ale tezko bude nekdo manipulovat s porty uprostred aritmeticke operace, ktera ty priznaky potrebuje.

30

Jediná dvě účelná míste, kde je schovávání SREG potřebné je přerušení (PUSH/POP) a to samé u některých podprogramů/rutin (řikejte tomu jak chcete) :slight_smile:
Mimochodem AVR mají v instrukční sadě co jsem si všimnul tak každý bit (možná na výjmky) má svojí vlastní instrukci na nastavení/vynulování. Viz SEI, CLI,… Moh bych dohledat další.

31

Není to zbytečné, ba dokonce nutné, máli tato část být zapouzdřena do makra nebo procedůry. Není předem známo, zda bylo či nebylo povoleno přerušení před vykonáním takového makra či procedůry. Kdyby byly použity instrukce CLI a SEI, k povolení přerušení by docházelo i v těch částech progaramu, kde si to programátor nepřeje.

Uvedený příklad by asi nikdo takto nepoužil pro PORTX, protože jsou vždy bitově adresovatelné (SBI, SBI), navíc by každý použil místo LDS a STS instr. IN ,OUT. Jsou případy, kdy IN a OUT nedosáhnou na příslušný registr a pak se to musí řešit takto.

Ještě jsem si vzpomněl na jednu zajímavost resp. novinku u nové řady AVR. (mega48,88,164,168,324,664 ale i u tiny261,461,861) Obsahují registry GPIOR0, GPIOR1 a GPIOR2, které nepatří žádné periferii a mohou sloužit jako podpora jádra. První je vždy bitově adresovatelný a lze dle něj např. větvit program (sbic, sbis). Všechny lze použít k rychlé úschově registrů např. při přerušení a vyhnout se tak zhlouhavému PUSH a POP. Stejně tak je možné použít jako virtuální porty. Docela by mě zajímalo, jestli ty C kompilátory jsou schpony zahrnout tyto registry do svého překladu.

32

Já zastávám názor, že uschovávání SREG je nutné pouze tehdy, vstupujeme-li do přerušení, nebo pokud voláme nějakou rutinu, která zasahuje do bitů SREGu. Pokud zásah do SREG nevadí, netřeba zbytečně PUSHovat a POPovat kde není třeba. Bere to akorát drahou paměť, které není zas tolik. Na ASM to ale bohatě dostačuje.

CHystám se trochu experimentovat s přehráváním zvuku, a to přes mega8. Jsem zvědavý, zdali si vystačím s 1kB paměti. Řek bych že jo. Pokud by se našel nějaký dobrovolník, který by se podle vývojového diagramu (který rád poskytnu) pokusil přepsat to do C, docela by mě zajímalo, co z toho vyleze. Zatím to ale nemám hotové, tak až někdy jindy.

33

Technik to psal pro pouziti v makru, tam je potreba resit veskery mozny situace.

Ti to klidne do C prepisu, teda pokusim se :wink: az do toho budes chtit jit, dej vedet. “Ostatni” by pro to mohlo bejt dobry tema (ono i tohle vlakno by se tam vyjimalo lip) :wink: Akorat budu muset bud nainstalovat starsi gcc (ten asm, co leze z toho posledniho je docela chaos - vklada to tam prikazy C asi pro nazornost, ale kod pod prikazem casto odpovida jiny casti), nebo to disasemblovat z binarky…

34

este pekna praca v AVR-GCC v spolupraci s ASM

avga.prometheus4.com/index.php?p=6-0

k stiahnutiu su aj zrojaky, da sa tam pekne vidiet spolupraca ASM a C.

Autor okrem najnutnejsich driverov cely zvysok aplikacie napisal v C. Asi mal svoje dovody (a neznalost ASM to urcite nebude :slight_smile: ), preco to C pouzil vsade kde sa len dalo. Myslim, ze to doklada, ze pouzitie C minimalne pre autora nieje otazkou “hracky”, aj ked pomocou neho “hracku” vytvoril. :slight_smile:

35

Vidím, že Ti můj výrok o hračce nedává spát, ale pořád si myslím to samé, co jsem napsal hned na začátku. Děkuji Ti za tento příklad, potvrdil si mi to, co už dávno vím. Autor krom C použil ASM né k vůli neznalosti něčeho, ale proto, že C na to v exponovaných částech nestačí. Kdyby to šlo napsat celé v C, jistě by to udělal. Ostatně na to nestačí samotné AVR a dělat z něj grafický kontrolér nejde. Možná tak ATxmega, ale ty ještě nejsou na trhu. Ale i tak by to byla slabota.

Správně si poznamenal, že je to hračka. Dnes už nemá smysl se zabývat generováním videosignálu pro CRT monitory, když je na trhu hafo barevných LCD, v nejrůznějších velikostech a i v půmyslovém provedení.

36

zakladatel vlákna na to:

dlouho jsem tu nebyl a zírám kolik příspěvků se sešlo
dík tedy všem za odpovědi a i když trochu s “křížkem po funuse”, přesto jsou pro mně přínosem, ačkoli některým věcem moc nerozumím.

A proč s křížkem po funuse? - první odpovědi na mé otázky přišly až zhruba po půl roce. Mezitím jsem nezahálel a zakoupil knihu V. Váni Atmel AVR - programování v jazyce C. A současně si stáhl jak CODEVISION AVR, tak MP LAB C18 pro pic a učil se na obou paralelně.
Čímž jsem si odpověděl na jednu z otázek (rozdíl v C pro PIC a AVR).
Ten rozdíl je minimální - snad pouze v práci periferiemi (porty, čítače, převodníky…). A zde je první věc , které nerozumím: jak by se se daly MCU programovat v C++, když oba výše uvedené compillery pracují s jakousi omezenou a upravenou verzí jazyka ANSI C ?

A mé poznatky po půl roce? :

Ačkoli nelituji času stáveného studiem ASM, přesto v něm už asi pracovat nebudu - zvítězilo tedy C pro jeho pohodlnost, hotové knihovny pro téměř vše co začátečník potřebuje (sériová rozhraní, ovládání LCD, převodníky atd.atd.), přehlednost programu- skutečnost, že 200 řádkový prográmek v C má po překladu do ASM zhruba 3000 řádků mluví za vše.

K 8 bit MCU: zatím s jinými nedělám a myslím že na učení a jednodušší aplikace typu: vyhodnotit stav vtsupů, data ze sběrnice čí výsledek AD převodu a na základě toho provést nějakou akci a ještě to zobrazit na LCD úplně stačí, ale to, že v budoucnu asi budu muset přejít na 16(32) bitové je mi jasné.
[/quote]

37

Na co potřebuje začátečník knihovnu na UART? :angry: Nechápu. Otevřu datasheet, a najdu si potřebné nastavení UCSRx registrů.

C++ nemá smysl realizovat na 8b procesorech. To už je opravdu jen na hraní. Běžné osmibity nemají dostatečný výkon, aby se na tom daly dělat slušné aplikace v ASM. (Ptal jem se na to známého, který pracuje v Německu pro firmu ST, a ten tomu bude asi rozumět. Dělá tam s konstroléry a hradlovými poli FPGA a podobné.)
Cčko se prý použít na 8b ještě dá, ale kompiler by měl být certifikovaný (překládá správně). V Cčku se dají psát i některé programy pro 8bity, prý ale na 8bity je lepší ASM: Těch pár instrukcí se naučit dá. Cčko a C++ má smysl až od 16bitů/32bitů.

38

Nezaspals trochu? :slight_smile:
Stejne v aplikacich, ktere vyuzivaji 8b mcu, v drtive vetsine procesor dela 2 veci… hadej jaky :slight_smile: Kdyz potrebujes vykon, tak 8bitu nepomuze ani svecena voda…
Delej, jak uznas za vhodny, ale osobne budu dal psat programy prehledneji, rychleji a mensi (mam na mysli zdrojak, vysledek ve flash me vazne netlaci). :wink:
Pravda ale je, ze pouzivat nejakou knihovnu na uart je trochu uchylny :slight_smile:
Co se tyka komunikace, ma kazdej program svoje specificky pozadavky, ktery knihovna postihnout nemuze (nebo se ji musi pisatel prizpusobit) a samotna obsluha je par radku…

39

Tak tuhle knihu jsem si taky před pár lety pořídil a muhu říci, že mě spíše odradila od C. Není to ani učebnice programování, ani učebnice C, je to něco napůl a od každého kousek dohromady nic. Spíše mi to připomíná manuál na CodeVision s návody na stavbu toho či onoho.
Vlastní asi 5 knih o C a C++ a mohu jen konstatovat, že C je velmi propracovaný jazyk s velkými možnostmi, které bohužel nelze uplatnit na většině 8b MCU.

Aby to bylo objektivní, měl bys připočítat k 200 ještě to co je v těch knihovnách, které jsi použil. 3000 řádků v ASM by také mohlo svědčit o neefektivním překladu. Všechny funkce, které jsou ve výše zmíněné knize lze napsat v ASM a pak je volat jen CALL nebo makrem. Např. céčkovská zápis
PORTB=0x00;
DDRB=0X00;
lze napsat stejně jednoduše pomocí maker takto:
outi PORTB,0x00
outi DDRB,0x00

To zrovna není málo a jen tak pro informaci. AVR jsou uplatnitelná pro zpracování analogového signálu tak do 4kHz. Tomu také odpovídá šířka pásma gain stage. I tak bude mít dost práce. Dříve nebo později si stejně budeš muset vytvážet vlasní knihovny ať v C nebo v ASM.

40

Myslim, ze Burkhard Kainka vo svojej knihe o Ccku pre AVR porovnaval vysledny kod programu v C a v C++ pre mikrokontrolery. Jazyk C (nie len C) zavadza do programovanie strukturove programovanie.
Jazyk C++ (nielen C++) objektove programovanie.
Zhruba povedane, objektove programovanie umoznuje este vacsiu davku abstrakcie ako C. To je ale vykupene este vacsim a pomalsim kodom. Ta miera abstrakcie je vsak pre urcite triedy uloh taka skvela, ze sa objektove programovanie hojne vyuziva v prostrediach, kde jeho nevyhody nie su na zavadu. Aj preto tie PC maju dnes GHz a GHz a GB RAM.
Uloh, pre ktore je vyrazne vhodnejsie objektove programovanie oproti samotnemu strukturovanemu programovaniu je pre 8b prostredie ako safranu (nie na safranej farme :slight_smile: ) a preto zavadzat prvky C++ do 8b architektury nie je prinosne, kedze ta nabobtnalost vysledneho kodu je uz neumerne obmedzujuca. Preto C++ na 8b asi nenajde velke uplatnenie.

Nazor, ze praca s ASM je pri dnesnom vykone dobrych 8b zbytocna pre vacsinu uloh, mozem len podporit. Pri prechode z ASM na C som bol velmi opatrny, casto som si vysledny kod kontroloval, porovnaval s cistym ASM a zvazoval, ci sa to ci ono “neoplati” prepisat do ASM. Pre nase ulohy sa to “neoplatilo” nakoniec vzdy.
Ako tu uz viac krat odznelo, praca s C je ina ako s ASM a teba sa ucit “nove” postupy a principy. Nakoniec som dospel k zaveru, ze pre moje aplikacie ASM nepotrebujem vobec.

Vykon ATmega mi ten konfort plne umoznuje. Program je napisany rychlejsie a prehladnejsie (co na tom, ze prekladac kde co prilinkuje aby vysledny kod mal tych spomynanych 3000 riadkov ASM? To “opticky” v zdrojaku nezavadzia a ten je vdaka tomu prehladnejsi. A ze je kod menej efektivny, malokedy vadi).

V slove, ze praca v C je pohodlnejsia, sa neskryva “len” lenivost pouzivatela, ale skusenost, ze vacsinu chyb ktorych sa bezny smrtelnik dopusta v ASM a nad hladanim ktorych stravi hodiny a hodiny, Ccko principialne osetruje. Na to Ccko je. Ale pre spravodlivost treba dodat, ze aj v C sa daju robit chyby, ktore sa hodiny a hodiny hladaju, problematika je vsak v abstrakcii o uroven vyssie a vdaka principom jazyka (zapuzdrenie, pretypovanie, lokalne a globalne premenne) sa da pripadna chyba dobre izolovat a odhalit.

Dnes zaciatocnikom, ktory chcu pracovat s ATmega, doporucujem hned od zaciatku na 8b programovat v C. O nic principialne neprichadzaju, ten ktory procesor si musia tak ci tak nastudovat a k zaujimavym vysledkom svojej prace sa dopracuju omnoho skor ako by nastudovali nejaku procesorovo zavislu mnozinu instrukcii.
Cloveku je prirodzenejsie uvazovat a pisat v kategoriach a zapisoch a = b +c; (bez ohladu, ci je cislo 8b, 16b alebo float), if a while (samozrejme v ekvivalentoch materskeho jazyka) ako v 35, ci vyse 100 instrukciach toho ktoreho procesora.
Mnohi so mnou urcite nebudu zase na zaklade svojich skusenosi a uloh ktore riesia na 8b suhlasit, ale to je dobre. Len v roznorodosti nazorov moze vzniknut impulz pre zmenu a pokrok. Ale porovnavanie tychto dvoch pohladov mi vzdialene pripomyna polemikou typu ci je lepsi prikazovy riadok, alebo klikacie ikonky.

Co sa tyka free C prekladacov, uvediem vlastnu skusenost. zacinali sme volakedy s ICC profesional verzion (15000,-Sk) . Problem vznikol pri praci s externistami. Zhanat nejaky krek pre docasnu pracu pre niekoho mi pripada voci autorom sw sproste. Nakoniec kolega narazil na GCC. Tym ze je free, sme zo zaciatku nan hladeli cez prsty,ale vysledky boli (na malych - par stovar riadkov - programoch) velmi vyrazne v prospech GCC oproti ICC. Netvrdim, ze ICC je zle, ale nam to vtedy na nasich prikladoch tak vyslo.

Az neskor sme ocenili portovatelnost GCC na ARM a PC. Verim, ze mnohe profesionalne prekladace C pre ATmega by mohli mat lepsie vysledky v preklade, ale prakticka stranka veci im nedava u nas sancu.

Inak videli ste uz toto?

mcu.cz/news.php?extend.1291.14

Je to krasne IDE, tie funkcie pre FAT, MMC a tak podobne a za velmi velmi dobru cenu. Jednoduchy programik, mi to prelozilo o 50% efektivnejsie ako GCC.

Inak to AVR- GCC ma v kolekcii dokonca i C++ prekladac, takze by sa na AVR mohol napisat program v C++, ale nikdy som to neskusal.

Co sa tyka moznosti prelozit Cckovy kod medzi roznymi prekladacmi C, par krat som to skusal pre porovnanie vysledkov prekladu. Vacsi projekt trvalo upravit viac ako 4 hodiny prace a viac casu som nemal. Takze som namatkovo testoval iba male prgramy (stovky riadkov) a tam sa urcite neda hovorit o nejakej vypovednej hodnote medzi jednotlivymi prekladacmi.
Nie je samozrejme problem v cistom C kode, ale v kode obhospodarujucom periferie. kazdy prekladac ma svoj vlastny system tvorby headrov a to upravit… to vam poviem. :slight_smile: Taketo problemy v ASM fakt nie su. Tam su zase uplne ine problemy pri prenositelnosti zdrojakov na typ procesora s inym jadrom :slight_smile:. GCC nam vo firme vyhovuje prave pre jeho pritomnost na mnohych platformach a preto ,ze sa da praca korektne voci tvorcom a pritom efektivne organizovat i medzi prilezitostnymi externistami. Nevyhoda “mozno” vacsieho vysledneho kodu oproti inym platenym prekladacom nie je badatelna. Ako tu uz bolo spomenute, treba dobre zvolit platformu na riesenie daneho problemu a na FFT do 20kHz nenavrhovat hw s AVR.

Inak moznost zacat robit s prekladacom, ktoreho free verzia je obmedzena na 2kB vidim od predajcu ako dobru namotavku :slight_smile:. Do 2kB sa toho (na rozdiel od ASM) vela v C spravit fakt neda. Nase aplikacie zacinaju niekde od 6kB kodu a 200B RAM. Podla toho volime i typ procesora, ATmega8/32/128. GCC samozrejme bez obmedzenia.

Inak v slovnom spojeni - kniznica pre com port - sa moze skyvat zopar vhodne pomenovanych makier, ale aj kompletne kniznice pre ten ktory komunikacny protokol. Dany prekladac nepoznam a preto by som existenciu takych kniznich nenazyval prave uchylka. Ale mozno je :slight_smile: