Zdravím všechny,
tak jsem víceméně úspěšně zvládl asembler a chtěl bych pokročit výš - teddy do C.
Otázka první: má to smysl, nebo je lepší zaměřit se na asembler a dokonalé využití všeho, co nabízí?
Otázka druhá: Jelikož literatura v češtině k programování v C je pouze pro ATMEL - budou znalosti z ní získané použitelné i pro PIC , nebo je zde takový rozdíl jako v asembleru pro ATMEL a pro PIC?
Otázka třetí: 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?
má to smysl, programy jsou kratší a přehlednější, tzn. člověk zvládne důmyslnější věci v kratším časovém okamžiku
nejlepší je využívat literaturu přímo z www.microchip.com , pokud to s MPC myslíš vážně, bude pro tebe jednodušší naučit se anglicky než shánět českou literaturu
viz. 1) s pomocí literatury ten přechod zase tak těžký není, záleží zda-li jseš uplný začátečník v programování v C nebo ve vyšších jazycích vůbec, C pro MPC je trochu blíže asm, uvažování je potřeba změnit pouze v přístupu k programu jako celku
administrator: Tvá registrace proběhla v pořádku, ale jelikož máš plnou emailovou schránku, nemohl ti dojít aktivační email. Uživatelský účet jsem ti proto ručně aktivoval. Vítej na mcontrollers.com.
Co sa procesora tyka, urcite nezacinaj s nicim mensim ako s ATmega32 (je aj v DIL40). Ten cenovy rozdiel medzi mega32 a mega16, pripadne mega8/88 je minimalny a mas dost Flasky, RAMky i EEPROMky a hlavne si mozes program debugovat priamo v procesore. Kde na to ma taky 89S52.
Ak mas v kompe este LPT, tak ti na programovanie doporucujem PonyProg. stiahnes ho zo stranky:
Je jednoduchy, podporuje vela typov, okrem AVR i EEPROM a dokonca i PIC
Ale s prevodnikmi USB/LPT Ti fungovat nebude. Je trochu pomaly. Ak sa nebojis co to investovat, kup si DRAGON (cca 1500,-Sk). Do ATmega32 podporuje i ISP i JTAG na programovanie(velmi rychle) i na debugovanie.
To debugovanie priamo v procesore moze byt pre teba zaujimave, ale urcite nie nevyhnutne. Ja by som zacal s tym PonyProgom-ak mas LPT. Pri PonyProgu pozor na to, ze ak zakliknes FUSE, znamena to, ze sa FUSE v procesore nastavi na nulu (ENABLE FUSE). Obcas sa niekto najde, co to pose** a potom sa divi. Inak to nastudovanie, ako sa procesor spravne naprogramuje ta neminie pri vyere lubovolneho procesora.
Ak nechces do toho C vela investovat (respektive nic) a nechces porusovat autorsky zakon, potom sa sustred hlavne na GCC pre AVR (WinAVR)
Je oficialne zadara bez obmedzenia, ma slusnu podporu, velmi vela materialu na webe (potrebna minimalna znalost anglictiny aspon typu if-then-else-end Smile ) celkom dobre pouzitelny prekladac (porovnaval som s ICC, ICC vo verzii profesional dopadlo horsie ). S nejakymi osekanymi 4kB free verziami C-cka by som sa ani nezacinal, lebo co trochu vacsi projekt spotrebujes 8-12kB a potom budes zhanat nejaky crack, alebo platit za vacsiu verziu.
uplne skvely a prehladny rychlokurz pre GCC na AVR je na
je v nemcine, ale z obrazkov, nazvov registrov a kusov kodu (ten je v C, nie v nemcine Smile ) sa vysomari snad kazdy (otazka motivacie). Ale je to naozaj velmi pekny strucny a prehladny material. Snad by sa niekto nasiel, co by to spravne prelozil do zrozumitelnejsieho jazyka.
GCC sa da velmi pekne priamo integrovat do AVRstudia - ktore je tiez oficialne zadara. Integruje sa don i ten DRAGON. Takze potom si v jednom prostredi a len klikas po ikonkach. Ale su aj odporcovia tekehoto riesenia.
Urcite sa tu este niekto ozve s jeho skusenostami a doporuceniami, tak si len spravne (pre teba) vyber.
Kratší? byhc se hádal. Možná zdrojáky, výsledný ASM kod po kompilace je ale většinou delší, někdy i víc, než je zdrávo. CHce to umět optimalizovat, automatické optimalizace za tebe všecko nezvládnou.
A kto sa diva na disasembler? Chyba sa hlada predsa v zdrojaku, kde aj v 99% je a nie v disasemblerovanom kode (tam sa divam ked si uz fakt neviem rady a zvycajne zistim, ze ta chyba bola fakt v tom C zdrojaku a disasembler to vlasnte len potvrdil. O dovod viac sa najprv naucit ASM )
A to, ze ten prehladnejsi a kratsi zapis je prisposobeny ako interface k cloveku (co tu sa vsetko pre cloveka neurobi ), aby lahsie videl, ze co to napachal. Uz skoro nikoho nevzrusuje, ze je to za cenu 2-3x vacsieho a 2-3x pomalsieho vysledneho kodu. Hlavne ze je to 5-10x rychlejsie napisane a odladene.
Nevim jak vy, ale u věcí, které s kontroléry páchám, mě docela strojový čas i někdy i velikost kodu tlačí. Takže me neni jedno, že je to pomalejší, a ani me neni jedno, že je to větší. Prostě to celé urobim v asm, a je to bez problémů.
Momentálně páchám hudební syntetizátor s mega32, sám sem zvědavej, co z toho vyleze.
ad 1) Pro tak malé MCU, jako jsou osmibiťáky to nemá moc smysl. Mně to příjde spíše jako hračka a možná taky proto je to zadarmo. Pokud chceš plně využívat možnosti MCU, tak jedině ASM. Stejně většina algoritmů přímo pracuje s periférií a bývá časově exponovaná.
ad 2) Jaký je rozdíl v C mezi PIC a AVR nedokážu posoudit, ale všiml jsem si, že kupříkladu ATmega32 a ATmega644 mají jinak rozhozeny řídící bity v registrech. Pokud by někdo chtěl program napsaný v C pro megu32 přeložit pro megu644 nebude to fungovat a bude muset ručně opravovat části programů stejně jako v ASM.
ad 3) Určitě ano. Každý vyšší programovací jazyk působí na programátora jako svěrací kazajka a byl vyvinut pro vytváření jistého druhu aplikací. Každé klíčové slovo předstauje určitý stavební kámen, ze kterých se vytváří celek a nelze z nich postavit cokoli a jakkoli. Studiem prog. jazyků člověk získává informace o stavbě jednoduchých algoritmů a jejich spojování ve větší celky standartním způsobem, což nestačí např. při řešení vzájemné koordinace periférií. Proto musí programátor mnohdy opustit vžité představy o algoritmech a dívat se na problém trochu jinak a buď hlouběji studovat C nebo je naopak opustit a přejít na ASM, které je v tomto bez hranic. Některé věci ani nelze v C realizovat. Smotné C toho moc neumí, není na rozdíl od C++ objektově orientovené. Pořád se bavíme o 8b MCU. U 32b MCU je ASM příliš jemný nastroj na to, aby se dal použít.
Aj ked si Technikove nazory v mnohom vysoko vazim, s tymto sa neda nic ine iba nesuhlasit. K nazoru ze na zaklade toho, ze je GCC zadarmo tvrdit ze sa jedna o hracku staci povedat len tolko , ze GCC patri pod sadu nastrojov GNU pouzitych pre jadro Linuxu a je pouzivany vo vacsine modernych variant Unixu. Urcite sa pre ten ktory pripad najde efektivnejsi prekladac. Ale to neznamena, ze je to hracka.
Tento problem sa ale netyka temy ci ASM alebo C. HW deklaracie su prirodzene individualne pre ten ktory procesor (aj ked to v ramci rodiny mohli mat jednotne, beriem to ako dat za vyvoj do predu). To iste sa ale tyka vyuzitia a rozmiestnenia pinov procesora. AK mam raz LED na PA2 a inokedy na PD6, tak to musim tomu prekladacu a je jedno, ci prekladam z ASM alebo z C povedat a nemozem sa divit ze to "automaticky " nevie.
Velmi zaujimvay nazor. Podla neho by ludia programujuci v C#, VB, alebo v JAve boli tak zosnorovani, ze by ani nemohli dychat . Kvoli tomu vyssie jazyky urcite navrhnute nie su. Bolo by mozne konkretne uviest co sa v C realizovat neda? Ako mam rozumiet textu ze:
Ved to su vyslovene nezmysly. A prave pre 8 bity by som vobec neporovnaval C s C++. To je nieco ako tvrdit, ze C nieje vhodny pre 8bity a este to ktomu ani nie je JAVA. C++ je jazyk urceny predovsetkym na objektove programovanie. Jeho urcenie je pre abstraknejsiu triedu uloh ako typu prijmi bajt, spracuj komunikaciu, zobraz napis na LCD. Jeho prednosti sa prave pri tejto triede uloh moc do popredia nedostanu, skor naopak, generovanim velmi robustneho kodu “prilis” skoro zaprasi pamat daleko vacsim sposobom, ako program v C plniacim tu istu ulohu. Pomer moze byt priblizne asi ako medzi ASM a C
Pre 32b jadra je zrazu ASM prilis jemny? Co to znamena? Mam tomu rozumiet tak, ze pre 8bit je C nevhodne lebo “Některé věci ani nelze v C realizovat” a pre tu istu triedu uloh (komunikacia, obsluha periferii, casovace, displaye, tlacitka, prerusenia, AD, DA) pod 32b napr. ARM7 uz vhodne je? Mozno sa mylim, ale nazdavam sa, ze skor mal Technik na mysli, ze ASM pre 32b je tak komplikovany (ale o to viac bez hranic ) a tolko veci treba okolo neho drzat v hlave, ze je lepsie programovat v C, aby to vsetko za programatora osetril prekladac. Ale preco tuto vlastnost nevyuzit i pri 8bit (nemam na mysli PIC16Fxx )?
Opat pripominam, ze podla mojho nazoru znalost ASM nemusi byt na zavadu. Ale vonkoncom nie je nevyhnutna pre pracu s mikrokontrolermi s pamatou nad 16kB (vratane) a s RAM nad 1kB (vratane). Pri dnesnych cenach s niecim mensim asi ani mena zmysel pracovat.
V ASM sa bezpochyby da spravit program najrychlesi, najkratsi a najelegantnejsi ale za najdlhsi cas (vratane casu, za ktory sa clovek stane v ASM expertom). S novym typom procesora moze potom pod ASM zacinat skoro od zaciatku (ibaze by si pomohol pouzivanim urcitych algoritmyckych sablon, cim uz vlastnosti toho ktoreho ASM az tak najefektivnejsie nevyuzije a blizi sa k tomu C ). C je zdrojovom kode daleko elegantnejsie a prehladnejsie vo vysledku uz samozrejme menej. Ale hlavne C je prenositelne, podporuje strukturovane programovanie ako programovaci princip a aj dobre jednotne programovacie navyky pre tvoru prehladneho udrzovantelneho kodu. To sa da samozrejme i v ASM, ale to uz zavisi od poriadkumilovnosti toho ktoreho programatora.
Este na zaver jedna osobna skusenost. Pri mojich zaciatkoch v C som samozrejme kazdu sekvenciu obsluhy periferie, alebo nejakej casti programu disasembloval a porovnaval s tym, ako by som to napisal priamo v ASM. Prisiel som na to, ze v podstate o viac ako nejakych 20-40% by to lepsie nebolo. A aj to za cenu, ze by som program nemal rozdrobeny na male “kusky”, samostatne pouzitelne v lubovolnej inej aplikacii, ktora by vznikla jednoduchym povkladanim *.c (cca 8-20) do jedneho projektu. Zapuzdrenie premennych je skvela vec (uz len toto udrzovat v ASM pri spajani viacerych suborov dohromady je dobra makacka), prehladnost a abstraknost algoritmov je skvela vec, praca s polom struktur je skvela vec. A tieto skvele veci bohato vynahradia tych 20-40% vysedneho kodu naviac.
Netvrdim, ze ASM je zly. Veci v nom su uspornejsie a rychlejsie. Ale nie je nevyhnutny a C-cko pre 8bit ATmega je jednoducho velky prinos. Robim iba v C hlavne riadiace a komunikacne aplikacie do priemyslu a pre kontrolu si interne meriam casovu vytazenost procesora. Priemer je okolo 20-30%. Velkost vysledneho kodu je medzi 12-42kB, RAm do tych 2-3kB. To su moje skusenosti, niekto iny moze mat v svojom poli aplikacii ine. Ale generalizovat nazor ze C je pre 8bit hracka sa mi moc nepozdava, obzvlast ak tento nazor nie je podlozeny argumentami.
“ani nema zmysel pracovat” - ? To jako proč? Že do těch menších by se ti Cčko nevešlo?
Souhlasím s Technikem, že Cčko pro 8bity je jen taková hračka. C++ a objektové programování pro tyto procesory nemá vůbec smysl. Neni až tak potřeba říkat proč to není vhodné, spíš si ale řekněme, na co,a proč ho vůbec používat? Při programování na PC jsem se doposud vždy obešel bez objektů. Tak nevím, na co objekty pro 8b procíky, při tak “jednoduchých” věcech co budou dělat.
Mohu vědět, nějaký příklad, jak si říkal, že rpogram měl 12-46kB a SRAM 2-3kB? Co to bylo za program?
Vezmětesi příklad z tohoto: elektronika.kvalitne.cz/ATMEL/MODplayer/MODplayer2.html
Celé to bylo napsané čistě jenom v ASM. Vešlo se to bez problémů do 2kB paměti, a ještě nějaká i zbyla. Zdroják má ca 9.5kB. Zajmalo by mě, na kolik by vyšel program, pokud by to bylo psané v C.
Je v tom přehrávač MODu, komunikace s HDD. (nepamatuju se, možná i FAT16 to zvládá).
To jsou přesně ty věci, které jsem označil za hračku (blikání LED). Samozřejmě, že to musím sdělit překladači, ale v definici HW a né že budu přepracovávat algoritmus. Podstatné je to, že např. mega32 ovládá 3 timery přes 1 registr TIMSK, tak u mega644 jsou to 3 registry TIMSK0, TIMSK1 a TIMSK2. Pokud Ti nedochází, jaké fatální důsledky to může mít a že je někdy nutné přepracovat i algoritmus, potom nemá smysl dále diskutovat. Mega32 lze přímo nahradit mega644, mají stejný pinout, takže nejde v žádném případě o nějakou blbou LED.
Tohle je ukázka toho, jak se dají věci bezmyšlenkovitě smíchat do sebe. Je přeci rozdíl, jestli programuji čístý procesor, kde musím napsat vše od A do Z, a kdy programuji PC které má BIOS, operační systém, rozhraní API. Podle toho se vyvíjí a upravují jazyky. Např. JAVA byla vyvinuta specálně pro nápojové automaty a má snad někdo pocit, že programování 8b MCU přináší stejnou problematiku, jako nápojové automaty? Na to, abych vytvořil na PC aplikaci, která bude mít nějaké tlačítko a něco bude kreslit a vypisovat, bude VB dobré řešení. Přeci nikdo k vůli tomu nebude studovat 2 tlusté bichle WIN API. A protože v VB už je mnoho vyřešeno a uděláno a každý to rád použije, tak to je přesně ta “svěrací kazajka”. Lze použít jen to, co tam je.
A pokud si někdo chce napsat vlasní ovladač pro PC, VB je mu na ho…
Hranice mezi použitím ASM a C není ve velikosti paměti, jak se snažíš přesvědčit, ale v použití MCU a v jeho konstrukci. 8b MCU se dnes používají jako inteligentní periferie, např. řízení motorů, nabíječe, zářivkové předředníky. Programy v těchto případech obsahují vysoké množství instrukcí pracující bezprostředě s registry MCU. Jen málo kódu tvoří části nezávislé na HW. Zápis v C je stejně komplikovaný jako v ASM, akorát že v ASM je to jednoznačně vidět.
Další rozdíl je v samotných operandech. Na 8b se aritmetika moc dělat nedá, takže se musí sdružovat po 2 nebo 4 registrech, aby operandy měly 16b nebo 32b. Ano C to zařídí, ale jak v případech, kdy si 2, 3, 4 vlákan mají předávat výsledky bez zákazu přerušení. Co když nastavím timer o další registr, jak z nich budu číst bezchybně výsledy? U 32b MCU tyto problémy nejsou, nebo jen minimálně.
Čím větší RAM tím se dá předpokládat větší množství proměných. Člověk je schopen si pamatovat jen omezené množství, takže programovací jazyky musí být tak udělány, aby toto programátorům usnadnily. A protože 32b MCU mívají už velkou RAM, je zde použití C na místě. Zpravidle se na nich realizuje nějaké grafické rozhraní na LCD a řídící procesy a to už na ASM není.
Presne tak, nejde o nejaku blbu LED. V prvom rade ak viem ze budem pouzivat viac roznych rodin (a to nie iba mega32 a mega644), vsetky HW zavisle veci si predsa dam do zvlast headrov napr. ako makra, alebo inline funkcie. V samotnom C kode pouzijem iba nazov toho makra, napr. COM0_8N1 a prilinkujem prislusny header. V C sa uz potom nestaram, ako sa tych 8N1 nastavi pre ten ktory procesor ci AVR alebo ARM7 a to sa tyka ako UARTu, tak aj casovacov, AD a podobne. Alebo vy tak programujete, ze si pri inom procesore musite menit algoritmy? Potom sa nedivim podobnym argumentom . Ale prave vyssie spomenuta cast VOBEC ale VOBEC nesuvisi s tym, ci programujem v ASM alebo v C. V oboch pripadoch to musim nejako prekladacu povedat, kde ma co hladat a nastavit. V tomto jak s asnazim tak sa zazim vyhody ASM oproti C nevidim, preto cela diskusia na temu - treba povedat prekladacu kde co mam - je irelevantna od nastolenej temy.
Ale na vlastny obladac mu je dobre prave to C. Ako je v tom C zviazany? Fakt demagogia. Prosim uz nezahmlievajte nevhodnot pouzitia C pre 8b tym, ze to predsa nieje ani C++ ci JAVA. Ved prave o to ide, ze C je C a ma sa pouzit na to, na co je urcene. A ako v PC tak aj v 8b, 32b.
Nesnazim sa o nicom takom nikoho presvedcit, tak mi to prosim nevkladajte do ust. Prave naopak, tvrdim, ze C sa da pouztit aj na male 8b. Alebo tuto moju snahu nie je vidiet?! Efektivne pouzitie C nesuvisi ani tak s velkostou pamate (aj ked tu plati cim viac, tym lepsie), ale je prirodzene mat najlepsie procesor, ktory nema obmedzeny zasobnik konstrukciou procesora (PIC, x51) aj i ked tam sa da za urcitych omedzujucich okolnosti pouzit. Tak ako pre pouzitie Linuxu je dobre mat procesor,ktory ma MMU. Tak aj tato vlastnost so zasobnikom je dolezita pre pouzitie C na 8b (aby prekladace mohli vygenerovat ako tak efektivny kod).
A o co menej jednoznacnejsie je vidiet C ako v ASM?
A v ASM sa toto akoze riesi automaticky? Ved tam to treba osetrovat presne tak isto ako v C. Akyze je toto argument ze je C na 8b hracka a voce - nevhodny? Ak spracovavam viac vlakien, musim zabezpecit bezpecnu datovu komunikaci medzi nimi. To sa da bud napisat od piky(je jedno ci v ASm alebo v C), alebo si (typek podobny tomu, ktoremu sa nechce citat o WinAPI a preto je zosnorovany) aplikuje napr FreeRTOS, alebo iny operacny system do svojho 8b AVR procesora. Tam je na vyber naozaj vela typov.
Ale presne toto sa riesi aj na 8bitoch.
Ano, presne pre to. Ale nie len pre samotne Ccko, to frci aj pre ATtiny25. Ale preto, ze predpokladam, ze zaciatocnik bude chciet neskor vytvorit nieco “velke a nadherne vo svojej dokonalosti a funkcnej krase” A preco by mal travit cas nad tym, aby sa mu do maleho procesora tych par instrukcii este voslo? Obzvlast, ak je dnes rozdiel v cene medzi ATmega8 a Atmega32 cca 30,-Sk. Dovodom moze byt pre ten ktory pripad samozrejme puzdro. Ale pre zaciatocnika, ktory sa chce na nepajivom poli oboznamit s procesorom?
Uvedomte si prosim, ze cele toto vlako je venovane niekomu, kto uz uspesne zvladol ASM a chcel by prejst na C.
Pani prosim, jedine o co mi ide, je vyjadrit hlboky nesuhlas na tvrdeniami pre zaciatocnikov, ktore sa tu v hojnej miere objavuju.
A to, ze C je pre 8b AVR nevhodne, skor hracka a tak podobne. Toto tvrdenie je cirociry nezmysel.
Niektro tu este tvrdil, ze v 8b sa vacsinou pracuje s periferiami a ich registrami. Ono sa s nimi pracuje, ale asi tak max 10% casu. Ak chcem nacitat stav pinu a hned ho nejak malo upraveny zapisat na iny pin, na to pouzijem GAL (aj ked aj uP sa da). Ale ak prijmem bajt z UARTU a ulozim ho do bufra, spracovanie bufra, kontrola CRC, analyza poziadavy (prenos balika dat z/do uP) a jej realizacia je predsa instrukcne daleko daleko narocnejsia (a je jedno ci v ASM alebo v C, aj ked v C o nieco menej efektivna, co je zase dan za prehladnejsie a rychlejsie programovanie a odladovanie), ako samotna praca s registrami.
Ak nacitam data z AD registra, tak ich musim pozberat, spravit 50Hz filter aspon priemerovanim potrebneho mnozstva vzoriek, nakalibrovanie a nanormovanie udaja, aby zvysok programu mohol pracovat v nejakych jednotnych jednotkach pre vsetky AD kanaly. To su predsa tiez omnoho omnoho casovo narocnejsie operacie ako nacitat stav AD hodnoty.
Ak chcem spravit pocitadlo impulzov (pomalych, napr z elektromera, alebo vodomera), nacitany pin musim casovo “odsumit”, aby mi kde aky zakmit nepokazil meranie. A je to presne tam, kde v predoslych pripadoch. Tak aka neustala praca s registrami periferii. Dalsi blud.
A este jeden argument k pouzitiu procesora s vacsim mnozstvom RAM a Flash (v ramci puzdra). Je pravda, ze i s malou pamatou sa da robit “velka” muzika. To ale bezpochyby - a nikdy som netvrdil opak - v ASM a za cenu vymyslania casto exotickych algoritmov (to len cibri mysel). Myslim vsak, ze sa tu nebavime na temu sutaze ako co do najmensieho priestoru vtlacit co najviac ale na temu ako zazit s procesormi ako konickom (v pripadne zarobkovej cinnosti je cas na realizaciu zakazky vzdy az na prvom mieste a uz podla tej ktorej aplikacie profesional usudi, ci C alebo ASM ale to je uplne ina tema) co najvaciu radost, mat zmysluplne vysledky co najskor a bezat dalej k vyssim metam typu “aha co sa mi nove podarilo” a nie konecne som to do tej Attiny 25 narval a usetrim 12,50 za ATtiny45 Ale mozno su aj taky. Netvrdim, ze s ASM clovek radosnte chvilky nezazije. Urcite ano. Ale tie moze zazit i s tym tu tolko pod koberec zametanym C-ckom. To je vsetko o co som sa svojimi prispevkami snazil. Nic viac a nic menej.
Bol som vyzvany na predlozenie mojej “kvalifikacie” na taketo tvrdenia, tak aspon par prikladov.
zber udajov z fakturacnych elektromerov cez RS485, archivacia do AT45DB161, RTC, komunikacia s obsluhou cez 3x16 LCD a 8 tlacitok.
14kB Flash, 1870B RAM. Procesor sa v podstate so svojim 14.7456MHz Ctalom skoro furt spara v nose. Nacitavane dat 1x za 10sekund, lebo tie elektromery to jednoducho inak ani nevedia, tolko im trva 4800Bd vychrlit vsetky nove data, ktore maju. Spracovanie trva cca 100ms. - ATmega32
riadenie kaliacich peci, regulator pre 4 samostatne okruhy. kazdy okruh ma 16 samostatnych recetov, z ktorych si obsluha vyberie. Archivacia teploty do AT45161, RTC, RS485 na dispecing, odkial je cely proces monitorovany a pripadne i modifikovany. Komunikacia s I2C s ADS1112, meranie teplotyu pomocou termoclankov, Pt100, kalibrovanie anormovanie vyfiltrovanych nameranychg hodnot. PID regulacia akcnych zasahov.
rozhranie 3x16 znakovy LCD, 3 tlacitka. Interne vypocty vo float , ze trvaju dloho? 5ms? No a?
34kB Flash, 2860B RAM - ATmega644P
rozne zbery impulzov z elektromerov, vodomerov, plynomerov, komunikacia RS485 ModBus, cca 8-10kB Flash, 1kB RAM
vseliake datalogre, riadiace automaty atd, atd. Do teraz asi 75 roznych typov. Vacsinu som realizoval na ATmega32 (aj keby tam stacil mega16, kto by uz preletovaval osadeny TQFP procesor?)
pre dialkove preprogramovanie pouzivam vlastny bootloader s komunikacnym a funkcnym zabezpecenim - komu by sa chcelo utekat 300km, ked si klient zmysli doplnit alebo upravit nejaku funkciu (alebo nejaka chybycka )? Setri to cas a peniaze ko klientovi tak aj mne. Vsetko samozrejme v GCC.
zaoberam sa vo svojej profesionalnej praxi komunikacnymi, riadiacimi a monitorovacimi aplikaciami. A od ASM som po kratkom case odisiel uplne. Pre moje aplikacie bol jednoducho uplne zbytocny a tazsie sa udrzovali veci pre rozne platformy. Tu sa ukazalo pozitie C ako zjednocovacieho prvku velmi vyhodne a casovo i financne efektivne (aj ked sa pri ATmega minie viac pamati ako by to bolo v ASM - a co by tom inak ta zvysna Flash robila?).
S nejakym MODplayerom nesutazim a ani ma tato oblast vyuzitia uP nezaujima. Skor sa venujem usporam energii, ci vo velkych fabrikach alebo v domacnosti, dialkovym riadeniam a hromadnemu zberu dat.
Urcite su veci, ktore sa daju len v ASM (aj ked keby sa mozno pouzil ARM7, to C by to bez problemov stihalo ) a da sa tam pekne vysantit. O tom nepochybujem. Ale uz prosim nepiste zaciatocnikom, ze C na 8b AVR je iba na hracku. To je jednoducho pri najmensom zavadzanie ak nie priamo klamstvo. Kto chce, nech si robi trebars aj v BASCOMe alebo v ASM. Vsetko ma svoje vyhody. Len priznajte ich prosim verejne i tomu C-cku.
Předně pro pořádek: Příspěvek od Annonyma z 08 listopad 2008, 12:52 je můj. Omlouvám se za chybějící podpis.
Jinak fungující periférii nelze řešit makrem nebo definicí headeru. To by tam byl skoro celý program.
Z tvé argumentace vidím, že jsi nic nepochopil, z toho co jsem psal. Místo toho, promiň to hrubší vyjádření, používáš demagogickou argumentaci. Já jsem do této diskuze nevnesl nic o javě ani o VB. Navíc použávaš citace, které jsem zjevně nepsal. Já totiž zásadně nepíšu slovensky!
A nakonec ti opíšu neco z knihy o C dle normy ANSI/ISO, abys věděl o čem to vypovídá:
“Při posunutí bitů doprava se posouvají jednotlivé bity operandu o stanovený počet doprava. Bity vpravo, které se posunou mimo rozsah čísla, se ztratí. Přitom se v některých implementacích může kopírovat znaménkový bit. Operátor lze využívat například k rychlému dělení kladného čísla mocninami 2.”
Jde o operátor > >. Z toho není jisté, zda se pro překlad použije instrukce LSR nebo ASR. Takže každý překladač si to přeloží jak chce. Zajímavé že? Kdysi probíhala na toto téma diskuze na MCU.cz, kde se k tomu vyjadřoval i soudní znalec a upozorňoval na to.
Pokud překladač není certifikovaný, může generovat cokoliv. A certifikovaný je samozřejmě jen za peníze. Také tam upozorňoval, že logické operace včetně shiftu jsou definovány jen pro kladná čísla.
Citacie su v ruzovych ramcekoch. V ktorej citacii, ktoru som pouzil sa pise po slovensky? Fakt nerozumiem. V pisanom texte som sa odvolaval i na svoje predchadzajuce vyjadrenia, nikde som nepisal ze su od teba,. okrem toho, nemusim citovat len teba .
JAVU a VB som spomenul az ako reakciu na:
z 7.11. 22:12
Ak je to, ze >> nie je jednoznacne definovany taky vazny problem, malo by to byt velkou vyzvou nepouzivat C ani v PC. Nie je dovod, aby bolo riesenie tohto problemu na platforme PC o inom (jedno ci DOS, Win alebo Linux).
Inak, ak chcem delit cislo, preco preboha pouzivat bitovy posun? Ved ak chcem delit, tak napisem delenie. Ten prekladac i bez nastavenych optimalizacii predsa vidi, ze manipuluje bajtovou bezznamienkovou premennou a zachova sa podla toho
332: com_struct.pocet = com_struct.pocet / 2;
+000013C3: 2F89 MOV R24,R25 Copy register
+000013C4: 9586 LSR R24 Logical shift right
+000013C5: 93800679 STS 0x0679,R24 Store direct to data space
O co by bol zapis
com_struct.pocet = com_struct.pocet>>1;
efektivnejsi?
A hlavne co je na pouziti zapisu x = x/ 2 nejednoznacne?
Ak by boli pochybnosti tak este pridam:
332: com_struct.pocet = com_struct.pocet/4;
+00001E31: 918006D1 LDS R24,0x06D1 Load direct from data space
+00001E33: 9586 LSR R24 Logical shift right
+00001E34: 9586 LSR R24 Logical shift right
+00001E35: 938006D1 STS 0x06D1,R24 Store direct to data space
A ze sa daju ine veci programovat v ASM uspornejsie? To som predsa niekolko krat sam zdoraznil.
K tomu kodu v headroch. Nemam pocit ze by napr. makra pre nastavenie casti komunikacnych parametrov pre ATmega32
Ako to tak citam, vidim, ze som z tvojej argumentacie naozaj nieco nepochopil. A to, preco by malo byt C-cko vzhladom na 8b, aby som spravne citoval:
alebo
A hlavne na zaklade osobnej skusenosti ani nepochopim. Opat zdoraznujem, kazdy nech si robi co mu najviac vyhovuje pre tu ktoru aplikaciu. Ale generalizovat pre novacikov vyssie uvedene nazory je zavadzajuce. To je vsetko, o co mi slo.
Vždyť je to přeloženo naprosto blbě! Jestli takhle někdo dělá software, jako třeba pro vlaky City Elefant, tak se nedivím, že jsou tak poruchový.
Bohužel zde chybí deklarace typu proměnné. Pokud by šlo o unsigned byte, přimhouřil bych nad tím oko. Pri signed byte operace
X= X/2
musí být přeložena pomocí ASR. Jinak pro záporná čísla vyjde nesmysl.
Dále by mělo být provedeno u podílu zaokrouhlení, tzn. nejvyšší bit z těch, které se shiftem ztratí, se přičítá do výsledku.
ASR R24
ADC R24,Null ;Null = trvale nulový registr
V případe
X = X>>2
by překlad měl vypadat takto:
LSL R24 ;kde R24 je X
operace je definována jen pro unsigned byte. Zaokrouhlení se neprovádí, neboť nejde o matematickou operaci. Pro záporá čísla vychází nesmysl, viz poznámka výše.
Programuji v C++ pro PC a právě na těchto věcech jsem nejednou pohořel.
To uz fakt nema cenu. Citas ty vobec cele prispevky? Nepisem tam snad ze sa jedna o jednobajtovu unsigned (uviedol som slovo bezznamienkovu, moze snad niekto pod tym slovom rozumiet signed?) premennu?
Samozrejme, ze v texte nie je deklaracia, kedze sa jedna o fragment z disasemblera.
A samozrejme, ze pre signed bude preklad vyzerat inak.
Technik uviedol, ze C nema jednoznacny vysledok pri “rychlom” deleni dvoma unsigned bajtu, lebo >> moze mat vo vysledku nejednoznacny vysledok. Ak taketo delenie povazuje Technik za dostatocne pre ten ktory pripad (pouzitim rotacie bez zaokruhlovania), ako moze rovnaky vysledok generovany Cckovym prekladacom povazovat za naprosto blby?
Snazil som sa ukazat, ze pri potrebe jednoducheho delenia dvoma (styrmi), ktore by niekto za urcitych okolnosti riesil rotaciou, staci zapisat v C napisat x = x / 2 a nie x = x>>1, kedze tento zapis by nemusel generovat rovnaky vysledok pri roznych prekladacoch. Ccko to v tvare x = x/2 pre unsigned bajt vygeneroval tak, ako to bolo povodne pozadovane. Co je na tom naprosto blbe? A co to ma spolocne s nejakymi vlakmi? Ak niekto najde chybu v kompileri lubovolneho jazayka, nech prosim informuje jeho tvorcov, oni urcite spravia napravu. Ale toto nema s chybami prekladaca nic.
Uz fakt neviem, ci tie argumenty maju nejaku logiku. Ak ano, potom mi daco unika, ale zda sa ze hlavne vela casu.
teda, jsem zvědav kdo z téhle “hádky” vyjde jako vítěz
Nechtějte, abych do diskuze zatáhl někoho, kdo Vám naprosto jasně poví, zdali má Cčko smysl pro 8b architekury.
Asi nikto, lebo na sutaz musia byt aspon dvaja a ja nesutazim.
Ale ak uz ma byt vitaz, tak nech su to vsetci ti, ktori sa z tejto diskusie tym ci onym sposobom nieco nove dozvedeli a poucili sa. Ja sam sa polemikam nevyhybam, lebo ma nutia dobre si overit, ak chcem nieco tvrdit a tak si i sam “zvysujem kvalifikaciu”. Mnohe nazory protistrany su casto poucne a nevyplavali by bez polemiky na povrch . Vdaka za ne.
Ja som sa snazil iba podelit sa s mojimi skusenostami so zakladatelom vlakna. Na zaklade mnohych mojich skusenosti viem, ze C na 8b ATmega zmysel ma. Dokonca poznam ludi, ktori profesionalne programuju x51 (89S52) a to vyhradne v C a velmi slusne sa tym uzivia. O ASM nechcu ani pocut. To je tiez dokaz, ze je urcita nenulova mnozina ludi, ktorym to Ccko na 8b vyhovuje. A to je celkom pekny zmysel existencie
Urcite sa najde niekto s rozumnymi argumentami (tie zatial zazneli vo velmi minimalnej miere, skor boli na temu ci Ccko ako take ma vobec pravo na existenciu, vzhladom na jeho niektore uskalia) preco nie. Rad sa s nimi oboznamim.
Neviem si vsak predstavit argumenty, na zaklade ktorych by so mal prestat v C na ATmega robit a mal by som prejst naspat k ASM, kde som volakedy bol.
Tak sa tesim na dalsie reakcie.
bol tu zaujem o porovnanie s nejakymi rychlejsimi grafiskymi aplikaciami (aspon tak som to pochopil). Tak som este nasiel nieco na webe v cistom AVR-GCC [aspon autor to tak pise a ta japonstina je gulas, ale daju sa stiahnut zdrojaky a tie su pekne citatelne - co som videl, ciste GCC]