Fórum témák
» Több friss téma |
Ezért írtam,hogy jó C fordító és direkt nem akartam ellenpéldát felhozni külföldi fórumról,ahol már akkor is megmosolyognak ,ha csak egy karakteres LCD vezérlésnél is asm-el próbálkozol...de ez egy más történet,nem szeretnék "haragosokat" szerezni itt ez ügyben
Nem tudom, mert soha nem foglalkoztam PIC16-al, és nem is fogok, a PIC 32-től meg még messze járok. Azért a hardverfüggetlenséggel bánjunk óvatosan. Amúgy az említett példádban, szereplő tételt nem érzem akkora pukk-nak, bár még csak egysoros és kétsoros közti váltást csináltam ugyanazon PIC-en belűl, de azt úgy, hogy egy PIC hajtotta mindkét LCD-t, ugyanazon az adatvonalon. Még a R/W láb is azonos volt, csak az engedélyező nem. Ráadásul ugyanaz a rutin írta, csak néhány paramétert átkapcsolt.
A hardverfüggetlenség nem lehet kritériuma egy jó programnak. A jó program úgy van megírva, hogy egy másik programozó is tudja módosítani. Assembly nyelven írt program is lehet olyan, hogy egyszeri megírás után többször felhasználható.
Ha valami "teljesíti az elvárásokat", attól még lehet rosszul megírt kódsorozat. Ha valamit másik hardverre kell átvinni, az azt jelzi, hogy tervezéskor rosszul mérték fel az erőforrásokat és igényeket. Idézet: „Egy program attól jó, ha csak egyszer kell megírni, teljesíti az elvárásokat és hardverfüggetlen.” Nagyon szép és jó megközelítés egy nagy kapacitással, rengeteg féle kiépítéssel forgalomban levő környezetben. Ld. PC, stb. Egy kontroller sokkal közelebb van az áramköréhez. Csak igen ritkán készül rájuk olyan nagy elvonatkoztatási szintű program (FFT), aminél lényeg lenne a hordozhatóság. Az A/D átalakító kezelése jelentősen eltér még a PIC típusok között is. Használhatom a "gyári könyvtári" függvényt az eredmény kiolvasására, de akkor oda lesz a sávszélesség. Egyszer kell megírni... Ha elkészítem azt az emlegetett LCD kezelés eljárás gyűjteményt olyan szinten, ahol a bitek a kontroller tetszőleges portjának tetszőleges bitje lehet. Ekkor a 8 bites értéket a port bitekre rendkívül időigényes lesz. Ha a 8 adatbit csak egy 8 bites port megfelelő portja lehet, akkor ugyan gyors a rutin, de nem elég általános. Ki olvasott már az RTOS-os autós botrányról? A stack belemászott a változók közé... A hozzászólás módosítva: Okt 12, 2015
Idézet: „2-3ezer sor már nem hobbi kategória” Én hobbi szinten írtam a forrasztóvezérlőm programját és több mint 3e soros, C18-ban. Pl. a 18F452-őt azért kellett már cserélnem mert nem fért el a memóriában az új v3-as programja ami már GLCD-t, alsó, felső fűtésvezérlésű + saját setup rendszere van. Ezt már másik egy dupla akkora PIC-et kellett alkalmaznom mint a 18F452. Kb 4-5e sornál járok és még nincs kész  Ezt csak azért, hogy simán lehet hobbiból is több ezer soros kódokat írni..
Sziasztok! Kezdő kérdés, régen foglalkoztam a témával, de tuti csak vmi kis dolgot somtam el, segítséget szeretnék kérni. A lényeg:
-nyomógomb RC0 lenyom --> RB7 led világít majd elalszik -RC0 és RC1 lenyom ---> RB6 led vilagit elalszik -RC0 és RC2 lenyom ---> RB5 led vilagit elalszik. Áramkörileg a nyomógomb 10k-val felhúzva, rámértem, meg is vannak a logikai HL szintek a lábakon, szerintem programilag leszek béna. Nem érzékeli a gombokat, csak végigfutnak a ledek.
A hozzászólás módosítva: Okt 12, 2015
Látod? Ha assembly -ben írtad volna elég lett volna a kisebb PIC is.
 Viccet félretéve a glcd- re kíváncsi lennék ha nem titkos. Milyen kijelzőt használsz?
Analóg digitális port beállítás, az RC0..RC2 mind analóg amíg nem kell analóg port addig az inicializálás részhez ezt írd be:
Egy C nyelvű rutin, ahogy elsőre megirnánk:
Ez így 375 utasításra fordul. Egy kicsit átdolgozva:
Ez csak 176 utasítás...
Hát nekem egyik sem mond semmit. Lehet az Mplab Program memory nézetében többet látnék.
Igen, sejtem, hogy ASM-ben gazdaságosabb lenne, de sajnos az nekem nem megy.
Lehet majd egyszer neki fogok, de úgy vélem jelen pillanatban nem írok olyan programokat amelyeknél ennyire és élesen számítana az optimalizáció. De a tény az tény, ASM == nehéz, de cserébe optimalizáltabb, C == könnyebb, de cserébe nagyobb az erőforrás igénye. GLCD-ből már 2-ővel foglalkoztam eddig, a könnyebb és jobb a t6963c, és a nehezebb és rosszabb az st7920. A t6963c-ről van egy kis videó is fent: DPTP System - V3 Forrasztást vezérlő prototípus Itt sokat beszéltünk róla: Bővebben: Link Az ST7920 még programozás alatt, éppen az x y tengelyenkénti pixelezést írom hozzá, de elég gány ez a kijelző.. Később erről is lesz majd kis videó, egy elektromos kerékpár vezérlőjének lesz az LCD kijelzője, ha kész lesz. A hozzászólás módosítva: Okt 12, 2015
Első lépés: nagyon szépen köszönöm! Működik.
Második: kicsi én állj a sarokba 10 percre és gondolkodj el... Köszönöm!
Sziasztok! 12C508A típusú picet kéne égetnem a kazánban biztosan menne . Ami rendelkezésre áll az egy pickit2 (és a hex file), de úgy látom a támogatott eszközök listáján ez a típus nem szerepel. Van valakinek tapasztalata a fenti piccel kapcsolatban?
A hardverfüggetlenség itt gyakorlatilag azt jelenti, hogy nem kell újra, nulláról kitalálni az egészet.
Persze a C nyelv és az OO okozhat meglepetéseket. Egy kritikus alkalmazásnál megnyugtató az, ha az ember bit szinten ismeri minden regiszter tartalmát. A 18-as sorozatnál talán még megvan ez az illúzió, de fentebb már nincs.
Régebben már javasoltam, hogy vegyék be ezt is témakörhöz tartozó fenti sárga szövegbe, mert rendszeresen visszatérő hiba, de eddig sajnos nem történt meg.
Sziasztok!
Kicsit követtem a C és ASM nyelvek közti beszélgetést és rászántam magam, hogy PIC24-re írjak egy tényleg nagyon egyszerű programocskát ami egy LED-et hajt meg PWM-el. A programot először assemblyben dobtam össze és a lehető legkisebbre próbáltam összegyűrni minden felesleges dolog nélkül. Az eredmény egy 177 bájtos program lett. Ennek pont egy az egyben C-s másolatát készítettem el melyet XC16-os PRO licenszes fordítóval fordítottam. A legkisebb eredmény amit ki tudtam belőle hozni az 423 bájt lett. Tehát mondhatjuk hogy bő kétszerese az eredeti asm programnak. Nekem mondjuk sokkal egyszerűbb, átláthatóbb és logikusabb volt megírni assemblyben mint C-ben de lehet hogy csak én vagyok nagyon béna C-ben (mondjuk ez volt a második programom C-ben). Csatoltam a disassemblyt és az asm forrásfájlt, aki szeretné megnézheti a különbséget.
A C program esetében nézz meg első körben egy teljesen üres programot, ahol csak a main függvény van, de az is üres. Nézd meg azt mekkorára fordítja, és utána nézd meg mennyivel lesz nagyobb ha berakod a PWM forrásodat is. A C fordító ugyanis akkor is kitölti a teljes megszakítás ugrótáblázatot is, ha nem is használod + még a startup kód is bele kerül.
Szia!
Még nem foglalkoztam PIC24-el, ezért érdeklődnék. Ennek a szériának ennyire eltér az asm.-je a régebbiektől? Mert én semmit nem tudtam ebből kihámozni. Mit csinál voltaképpen?
Az összehasonlítás szemléletesebb lenne, rávilágítana néhány fontos részletre, ha közölnéd a C forrást és az asm forrást PIC16-ra, 18-ra, 24-re, 32-re.
Köztudott, hogy a forgalomban lévő C fordítók nem csontig optimalizáltak, de nem is az a cél. A fordító egy szoftver eszköz, egy szerszám, eltérő lehetőségekkel, amit célszerű megismerni annak, aki ezen a területen ténykedik. Miután megismerte, akkor lesz választási lehetősége eldönteni, hogy mikor melyiket használja. De ha fogalma sincs a C nyelvről és csak innen-onnan hallott féligazságokat szajkózva áll ki, vagy tör lándzsát valamelyik fordító mellett, fölött, az siralmas. Mert a lustaság és a tudatlanság áll mögötte.
Szia!
Nem beszélek a c nyelv ellen ugyanis nem ismerem annyira a lehetőségeit. De mindenképp szeretném megismerni. Most csak egy egyszerű programot írtam meg c és assembly nyelven majd a c nyelvből fordított assembky kódot hasonlítottam össze az én általam megírt kóddal. Persze assemblyben sokkal lassabban ment a megírása mint c-ben. És persze ismerni kell az assembly által adott és a c által adott kehetőségeket is.
Szia! Nem tér el nagyban. Voltaképp ez egy ledet vezérel hardveres PWM-el. Először növeli a Led fényerejét azután csökkenti. Ha megnézel egy-két példaprogramot akkor el tudsz indulni.
Láss egy kicsit a dolgok mögé.
Mit is csinál gyakorlatilag egy magasabb szintű programnyelv, illetve annak fordítója? Kész függvényekből megpróbálja a leginkább a programkörnyezetbe illőt beilleszteni. Minnél profibb a fordító, annál több előre megírt függvényből válogathat. Leginkább az Inventor 3D-s tervezőszoftveréhez lehetne hasonlítani. Alapból a legolcsóbbal is bármit megcsinálhatsz, de kicsi pl. a raktárkészlete, így nem tud mindent készen felkínálni. (pl: fogaskerekek) Tehát vagy megrajzolod magadnak (asm.), vagy azt rakod bele, ami van (C könyvtár). Idézet: „Először növeli a Led fényerejét azután csökkenti” Szia! Ehhez képest 177 byte-ot kissé soknak érzek! Egy gázkarról vezérelt PWM motormeghajtás programja gyorsításvezérléssel és relés fék vezérléssel PIC12-re írva asm.-ben 107 byte.
Szia!
Találomra megnéztem egy adatlapot. Elég korrekt leírás van az utasításokról a végén. Nem nagyon tér el, az általános parancsok ugyan azok csak itt az értékeket 16 biten kell megadni és van vagy 70 egynéhány utasítás.
Upsz!
Na jó! Úgy erzem, nekem a 24-es család még odébb van. Még a 18-as szériának is vannak számomra sötét foltjai.
Szia sonajkniz!
Miért nem használjátok a kettő programozási nyelvet együtt? A c kódba be lehet illeszteni az asm kódot, így azt használod amelyik előnyösebb. Igaz a beillesztésnél bizonyos szabályokat be kell tartani. _asm és az _endasm parancsok közé kell az asm kódrészletet beírni.
Srácok!
Nem gondoljátok, hogy sokkal több szót pazaroltunk el erre az egészre, mint amennyit megér? Aki a C-ben hisz úgysem fogja az asm-et használni és fordítva is így van! Az értelmes dolgok helyett teleszemeteltük a fórumot ezzel az értelmetlen és soha véget nem érő vitával.
A C18, XC8 azon fele, ami a 18F -re fordít, a 16 bites és a 32 bites C fordító elég korrekt kódot fordít. Az a legfőbb probléma velük, hogy a korrekt kód a PRO optimalizálásnál elfogadható (családonként 290000 Ft+Áfa), de a standard és a free mód inkább belepakol felesleges utasításokat mintsem optimalizál.
Az XC8 12F és 16F magokra fordító része még PRO optimalizálásnál sem ad elfogadható kódot. Ez nem attól van, hogy szeretem a C -t vagy utálom az assembly -t...
Szerintem ezeket a vitákat a moderátorok élvezik.
Van külön C-s és külön asm.-es topic is, mégis mindenki ide írkál. Ha itt tényleg csak a kezdők kérdései jelennének meg, azaz mindenki oda írna, ahova kell, vagy a moderátorok áthelyeznék, ezeknek a vitáknak a kialakulására esély sem lenne. |
Bejelentkezés
Hirdetés |
