Fórum témák
» Több friss téma |
A PLL lehet erre jó megoldás.
Az assembly programozás alapja a közvetlen tárgykód, így egy programot akár tárgykódban is meg lehet írni.
Hogy ne kelljen 0/1-ekkel bíbelődni, kitalálták a mnemonikokat. A tárgykód előállítása, a fordítás, annyiból áll, hogy a mnemonik, vagy adat egy- két, rövidke táblázatból kikeresett számmal lesz helyettesítve. A fordítón nincs sok fejleszteni való.
Ez csak fél igazság. Mivel az MPLAB X makro fordító is egyben. Ahhoz pedig, hogy hatékony makrókat
lehessen írni, ne csak egyszerű "delay"-t, a fordítót sem árt fejleszteni. A több byte-os számok beírása, az ugrások néven nevezhetősége, egy valamilyen név alá beírt táblázat helyének kiolvasása és behelyettesítése mind a fordítóra ró munkát. Ha jó a fordító, jók a makróid, vannak tökélyre fejlesztett saját rutinjaid, amiket a fordító szépen behelyez a program megfelelő pontjára, akkor assemblyben is lehet közel olyan gyorsan programozni, mint C-ben, csak jobb lesz a végeredmény. Idézet: „Ha jó a fordító, jók a makróid, vannak tökélyre fejlesztett saját rutinjaid, amiket a fordító szépen behelyez a program megfelelő pontjára, akkor assemblyben is lehet közel olyan gyorsan programozni, mint C-ben, csak jobb lesz a végeredmény.” Megfordítva sem utolsó a gondolat: A magas szintű nyelven írt sorok is assembly makró kifejtések egymásutánjára fordulnak. Kedvencem C -ben 18F -re:
sor
sorokra fordul, pedig az eredmény a második sor végrehajtása után is a WREG -ben van. A makró ugyanis arra van felkészítve, hogy az eredményt valamilyen változóban tárolni kell. Arra már nem készítették fel, hogy a tároló maga a WREG. Még egy példa: Ráfutás után a RCREG -et ki kell olvasni, az olvasott értéket el kell dobni.
lenne a legjobb, de itt is szorgosan tárol a fordító
Egy jó macro assembly -vel egészen más processzorra is tudsz fordítani. Pl. egy (rossz kifejezés) virtuális gépet is létrehozhatsz a programodon belül. Pl. float point aritmetika, stb. A hozzászólás módosítva: Máj 16, 2017
A makró csak egy másik táblázat, a tárgykód helyei pedig egy harmadik és így tovább. A makró fordítás egyszerű másolás.
Ezek csak a kényelmet szolgálják és a csilivilit. Nem ilyesmihez írták az MPLABX-et. Szerintem. Idézet: „A makró fordítás egyszerű másolás.” Meg formális - aktuális paramétercsere, aritmetika, változó kezelése (set), ismétlés (repeat), feltételes elágazás, feltételes kódgenerálás. Mindez az aktuális paraméterekkel vezérelve. A hozzászólás módosítva: Máj 16, 2017
Igen, de mindezek csak a kényelmet szolgálják. Nincs semmiféle átalakítás, optimalizálás, a tárgykód egy az egyben a forráskód megfelelője, a fordítás így néhány régóta ismert, bevált módszerrel történik.
Szerintem. Az eredeti felvetés az volt: Idézet: „...Lehet, hogy az MPLAB X-et direkt assemblyhez fejlesztették? Az egyéb programnyelveket pedig csak szőrmentén kezeli?..” A hozzászólás módosítva: Máj 16, 2017
Kilyukadni nem szeretnék, csak azt szerettem volna megmutatni, hogy azért működik jól Nálad az assembly, mert azt nehéz elrontani.
És persze azt, hogy az MPLABX megalkotásánál nem az assembly fordító volt az elsődleges szempont, hanem együtt több programnyelv, többféle kontroller, hozzá sokféle hardver, mindezek részletes beállíthatósága, kényelmes használata programozásnál és hibakeresésnél.
Értelek, és nyilvánvaló, hogy nem az asm a fő céljuk.
De azért ez: Idézet: „részletes beállíthatósága, kényelmes használata programozásnál és hibakeresésnél” nem nagyon sikerült nekik...  Azért valljuk be, hogy elég sok baj van az MPLABX-szel.
Még egy okkal több, hogy maradjak az assemblynél.
Ott semmi bajom nincs az MPLAB X-el.
Én is így vagyok vele, amit meg lehet oldani 8 biten, arra szerintem bőven jó a "régi" 18F széria. Ha meg valami nagyon cudar dolog kell, akkor arra már inkább ARM-et kéne használni.
Csak egyelőre a lustaságom keresztbe tesz ennek a tervnek. 
Nálam akkor bukott meg az MplabX, amikor próbáltam megérteni egy projekt könyvtárszerkezetét.
Nem nagyon, hanem nagyon nem
De hátha olvassák ezt a fórumot és egyszer csak ráeszmélnek mi is a fő cél. Mert összetett, meg bonyolult, meg sok a meló és egyebek, de úgy árulni kontrollert, hogy a meglévő és működő C fordító nincs beszélő viszonyban a felhasználóval, az szomorú. De miket beszélek itt. A fizetős verziónál ilyen gond biztosan nincs. 3-10 év és a most új eszközök is fognak működni. Mert az kizárt, hogy egy profi programozónak ez akkora meló, hogy évekkel később kerüljön be egy új eszköz az IDE-be.
Egy jól működő rendszer részletei a felületes szemlélő számára tűnhetnek öntörvényűnek, szokatlannak.
De ezt hajlandóak vagyunk készséggel tolerálni, ha a végeredmény brilliáns, kényelmes, vagy legalább használható.
Szia! Mellékelek 1 nagyon alap progit. Jó régi,de gyorsan átírtam benne ezt-azt.Elméletileg menni fog,ha Explorered van
.8MHz-es kavicsra van beállítva.Sajna már nem tudom kipróbálni,mert a GA010-es plug in module-omon már kicseréltem egy másik típusra ,vagyis kikaptam róla,és ráforrasztottam egy jobbat .
Nos van némi igazság abban, amit írsz:
Idézet: „Mert összetett, meg bonyolult, meg sok a meló és egyebek, de úgy árulni kontrollert, hogy a meglévő és működő C fordító nincs beszélő viszonyban a felhasználóval, az szomorú.” Amikor a C18 fordítót megjelentette a Microchip a 18F252 helyett egy 18F2520 -at is megjelenetetett (nagyobb program memóriával)... Idézet: „De miket beszélek itt. A fizetős verziónál ilyen gond biztosan nincs.” A PRO verzió is tele van ügyetlenségekkel, a STANDARD -ban hemzseg, a FREE egyszerűen kriminális, amit csinál. Egy olyan program, ami assembly -ben röhögve belefért a 16F628 2k-s programtárában XC8 FREE módban nem fért bele 8k -ba sem. (Nincs standard Midrange nagyobb programtárral.) Idézet: „3-10 év és a most új eszközök is fognak működni.” Három év már letelt. (Kb. ennyit vártunk a 32MZ beharangozása és a forgalomba hozatala között). De ne feledjük, egy világhírű cégről van szó... A konkurenciát behozni ezzel a módszerrel ? Idézet: „Mert az kizárt, hogy egy profi programozónak ez akkora meló, hogy évekkel később kerüljön be egy új eszköz az IDE-be.” A MpLab X egy keretrendszer. Alkalmazkodnia kellene a feltelepített fordítókhoz (akkor is, ha ugyan az a gyártó készítette és akkor is ha más). Így pl. nem értem, miért a keretrendszer készíti el a konfigurációs szavak beállításából a forrást, ha minden verzióban változtatjuk egyes kontrollerek include állományát? Megvizsgáltam és átírtam a PICkit2 és a PICkit Serial Analyzer programját. Időnként a hajam szála is égnek állt volva, ha lenne még. Fizetett, főállású programozói gárda készítette.  A hozzászólás módosítva: Máj 17, 2017
Sziasztok!
Minap unatkozásképp elkezdtem próbálkozni hogy milyen jeleket tudok szépen a PIC-ből kicsikarni. Az alany egy PIC12f752-es, van benne DAC megfelelő memória és PWM kimenet. PWM szépen megy is, timer1 adja ugye az alapot, fűrészjelet is tudok vele generálni, úgy mint háromszögjelet, a probléma a szinusz generálásánál van. timer0 adná az alapot, 0-tól 180-ig számoltatom emellé társul egy bool ami megmondja hogy melyik félben járunk. A kiemenetet a DAC-al generáltatom, az alábbi formulával:
Itt jön a probléma; a sin a math.h könyvtárban van, és akkora memóriát foglal hogy az már bőven sok a kis PIC-nek. Van valami egyéb megoldás erre? Ki hogyan generálna szinusz egy ilyen kis jószággal, ha egyáltalán belefér a fejébe. Köszönöm ! A hozzászólás módosítva: Máj 17, 2017
PIClist oldalról az Implementing the Sine function on the PIC.
A hozzászólás módosítva: Máj 17, 2017
Valami hasonló jutott az eszembe, de itt szépen leírja, köszönöm !
Még amit nézegettem, van olyan 16 bites PIC amiben van DAC és támogatja a PICkit2? Már vagy 1 órája kattingatom a filtereket és nézem amit kidob, hasonlítom össze a readmevel de nemigazán találok. Vagy amiben már van az nincs támogatva ? Idézet: „Fizetett, főállású programozói gárda készítette.” És sajnos azt se merem elképzelni, hogy mindezt éhbérért. Ez a szörnyűbb. Komoly pénzekért teszteletlen, lomha bughalmaz a végeredmény. Hát mindenek lehetnek erre a termékre, de büszkék semmiképp.
Az a baj, hogy fel sem tűnik már. Most már nincs fenn a honlapukon az a díj, amit nyertek vele.... Milyen lehet a többi pályázó?
Idézet: „Még amit nézegettem, van olyan 16 bites PIC amiben van DAC és támogatja a PICkit2?” Sajnos csak nagyon kevés 16 bitest ismer a PICkit2 2.61. Miért is? Mert a gyártó úgy döntött, hogy a fejlesztését abbahagyja... Egyébként tudhatná az összeset.
A Kónya László féle PIC mikrovezérlők alkalmazástechnikája c. könyv harmadik, Kopják József által írt fejezetekkel bővített kiadásában pont az Explorer 16 fejlesztőkártyához igazodó mintapéldákon keresztül vezetik be az olvasót a 16bites PIC-ek C nyelvű programozásába.
Itt megtalálod a könyv szkennelt változatát: Bővebben: Link
Valamikor olvastam egy projektet, volt aki elkészítette(továbbfejlesztette) a pickit2 förmverét úgy hogy majdnem mindent támogatott az összes hibája pár bug volt. Szóval tényleg képes rá csak nem érdekli őket.
Beletrafáltam volna ?
És valóban, megtaláltam a fórumtémát
Na megérkezett a Pickit3, kipróbáltam. Tökéletesen működik a kódom. A proteus meg be....
Akkor mehet tovább a tanulás....  A hozzászólás módosítva: Máj 17, 2017
Örülök.. Összetettebb feladatnál, főleg ahol még te is végig tudod gondolni a megfelelő működést és úgy érzed, hogy hibázik a Proteus, mindig érdemes élesben is tesztelni.. Szerencsére nem sokszor fordul elő, de számítani azért kell rá.. Ettől független nagyon jó, hogy létezik az a program.. Hajrá..
Uraim, nekem is lenne 2 kérdésem..
Az egyik ide vág a másik nem annyira, de nem akarok két külön kérdést feltenni és talán még bele fér az az egy igen vagy nem. Első: Van egy kis rutinom, amely így fest:
A break; utasítással kapcsolatban kérdezném, hogy jót e tesz illetve biztonsággal lehet e használni? Most szépen működik, de lehet nem a legjobb megoldás. A lényege, hogy ha megtalálja a rövid fájlnévhez csatolt hosszú fájlnevet, egyszerűen lépjen ki a for ciklusból és ne keressen tovább. Ez a break vagy esetleg még a 2. for ciklus x változóját tudnám megváltoztatni, hogy a feltétel beigazolódjon és abba hagyja a futást. Melyik az értelmesebb PIC felől nézve? Második: Ez nem ide tartozik, de hátha nem kapok érte most rovást. SD kártya esetében, ha használom az engedélyező lábat, akkor minden újra engedélyezésnél le kell futtatnom az inicializálást? A kérdés azért merült fel, mert az OLED kijelző hajtása ugyan azokról az SPI lábakról történik mint amiről az SD kártyát hajtom.. Előre is köszi. A hozzászólás módosítva: Máj 18, 2017
|
Bejelentkezés
Hirdetés |
