Fórum témák
» Több friss téma |
Átírtam a cuccot nyomi mikrovezérlőhöz.
![]() Annyi változást eszközöltem még, hogy az összeadások helyiértéksorrendjét megcseréltem, mert itt így volt jobb. Tehát a művelet: (d3:d2:d1) = (a3:a2:a1) + (b3:b2:b1) + (c3:c2:c1) A 3. byte (pl. a3) viszont csak a számoláskor kell, tehát azzal sem előtte, sem utána nem kell foglalkozni. Hp41C megoldása teljesen jó, de... Ha 3 változót kell összeadni, amik közel vannak valamelyik határhoz, akkor adódhatnak vele gondok.
Nem hiszem el, hogy valamit mindig elnézek!
![]() (Az első összeadásnál csak akkor nem lenne átvitel, ha csak pozitív számokat használnánk. Tehát az egyszerűsítés nem használható!) Javítottam a kódot. Bocsi! Még annyi: az összeadás során az a, b és c változók értékei nem módosulnak, csak d-é.
Csupán érdekességképpen átírtam a szaturációs eljárást PIC16-ról (Midrange és Baseline) PIC24-re. Összevetve a két (három) kódot, megfigyelhető hogy a 16-bites változat mennyivel tömörebb és egyszerűbb. (Persze közrejátszott ebben az is, hogy ott a változók munkaregiszterekben vannak tárolva. De hát erre vannak...)
Ja... és bocsi a sok egymásutáni hozzászólásért!
Ugye, ugye?
![]() ![]() Most akkor megpróbálom ezt a kódot. Köszi.
Nincs gond az összeadással, csak macerás hogy a kisebb procik gyérebb utasításkészlete miatt egy egyszerű műveletet (sokszok jelentősen) több utasítással kell megoldani. A figyelem így nem a konkrét problémára irányul, és a kódhossz is megnő.
Szóval... Ha nem akarsz sokat szopni, akkor ne ilyen nyominger procit használj! Szabadulj meg töle! ![]() Csupán poénból csináltam egy PIC24 - MC68000 összehasonlítást is ugyanarra a témára.
Már haladok a C tanulással, csak lassan.
A gyorsabb haladáshoz kellene egy kis segítség: Olyan PDF, link, vagy help kellene, ahol a mikrochip c parancsok pontos szintaktikája, egybegyűjtve (esetleg példákkal kiegészítve) megtalálható.
Hát igen, szívok is vele rendesen.
![]() Egyébként MPLAB szimulációban, hogy kell időzítésekkel ellátott kódokat szimulálni? Tehát nem szeretnék várni 10 percet míg túlcsordulás történik az egyik timeren.
Na leteszteltem a valóságban és nem teljesen működik jól. Valamilyen változó értékeknél át tud fordulni a minimumból a maximumba az egész és fordítva. Az nem kavarhat be a programnak, hogy pl. a B változó értéke a maximumon van és úgy kezdi az összeadást?
Sziasztok.
Soros párhozamos átalakító ic-t szeretnék használni (pl: 74ls192). Assembly-ben programozok. 2 vezeték áll rendelkezésünkre. Egyik az adat másik az órajel. Hogyan oldom meg a soros adat kiküldését? Én arra gondoltam hogy megcsinálom mind a 10 számjegynek külön az adat kiküldést. És akkor lenne összesen 10 makró és csak arra ugrok amelyik éppen nekem kell. Jó az elképzelésem?
Szia!
A szimulátorban be lehet állítani az órajelet (Debugger / Settings), de ez nem feltétlenül a végrehajtás sebességét módosítja, hanem a stopperóra időegységét. Van néhány ötlet, amivel fel lehet gyorsítani a szimulációt: - Átállítod a timert a szimuláció idejére, - Megállítod a programot egy törésponton, módosítod a regiszterek értékét, - Beállítod a regisztereket egy neked tetsző állapotba beleértve a PC -t is (Set PC at cursor) és onnan indítod vagy folytatod a szimulációt.
Szia!
Betöltöd egy memória rekeszbe a kiküldendő adatot, törlöd a számlálót, ha a adat > 0 egy ciklusban annyi órajelet adsz ki, amennyi az adat értéke a memória rekeszben. Makro: egy a felhasználó által definiált magasabb szintű utasítás, amit a fordító minden hivathozás helyére kifejt. Eljárás: Egy utasítássorozat, amit csak egyszer lesz a kódban annak ellenére, hogy több helyrői is meghívhatják. Szerintem az utóbbira gondoltál.
Hogyan lehet beállítani az MPlab editorjában, hogy mutassa a sorszámokat ne kelljen számolnom a sorokat, hogy hol a syntax error?
Szerkesztő ablak jobb gomb, tulajdonságok vagy editor beállítások, pontosan nem jut eszembe a menüpont neve
![]()
Nem értem hogy hogy gondolod.
Én arra gondoltam hogy csinálok 10 db (a felvilágosításodnak köszönhetően most már ezt is tudom) eljárást. Pl: 7 szegmenses kijelző meghajtás. 1-es számjegy: 01100000 Kimenet: 0 Órajel Kimenet: 1 Órajel Kimenet: 1 Órajel Kimenet: 0 Órajel .... és így tovább.
Ha kattintasz a hibaüzenetre, akkor a szerkesztő odaugrik, ahol a szintaktikai hiba van...
Tehat mondjuk van egy orad, annak tegyuk fel, 4 szamjegye. Ezeket valamilyen modon meg lehet jeleniteni a 7szegmenseseken, gondolom, megfelelo out a megfelelo szegmensre kerul.
tehat 4 byte adatod van es ezt szeretned kishiftelni soros vonalon. Ilyenkor a 4 byte-ot egyutt kell mozgatni egy adott iranyban, bitenkent. rrcf vagy rlcf , attol fuggoen, hogy legfelso vagy legalso bittel akarod kezdeni. Mondjuk jobbra leptetsz, az ora a szam1, szam2, a percek meg a szam3, szam4 memoriarekeszekben vannak. Ilyenkor a carryt torlod, aztan kiadod a leginkabb BALRA, vagyis a szam1-re a rrcf-et. ilyenkor a legalso bit belekerul a carry-be, amit tovabb kell vinned a kovetkezo szam legfelso bitjere...es igy tovabb. Csak a legeslegvegen, amiko mar a szam4-et is shiftelted, akkor lesz a carryban a legalso bit. Ezt szepen kiadod az adatporton. Utana clock hi/lo. aztan ismeteled a fenti eljarast osszesen 32x (4 szamjegyx8bit), mig az osszes soros-parhuzamos chiped megtelik. Ha felfele leptetsz, akkor a szam4-el kezdesz, majd szam1 utan lesz a carryban a kiadando bit. De oszinten szolva ket vezetekkel elegge randa lesz a kepe, mert shifteles alatt villognak ossze-vissza. Szokott lenni hatterpuffer, hogy egyszerre irodjanak at az ertekek es ennek is van vezerlojele. Idézet: „Az nem kavarhat be a programnak, hogy pl. a B változó értéke a maximumon van és úgy kezdi az összeadást?” Nem. A 3-byteos összeadás érzéketlen erre. Hadd kérdezzem már meg: Biztosan kettes komplemens számábrázolást használsz, és nem offszet ábrázolást? Mondj egy példát, ahol az eredmény nem stimmel!
Köszi
![]() Most már csak az előző kérdésemre kellene egy jó klink, és akkor nem lesz annyi hiba. [quote] Hogyan lehet beállítani az MPlab editorjában, hogy mutassa a sorszámokat ne kelljen számolnom a sorokat, hogy hol a syntax error?
Szia!
Ha az Output ablakban a hiba sorára klikkentesz, a hibához tartozó forrás ablakban arra a sorra áll, ahol a hiba van...
A kettes komplemens biztos, de már azt hiszem megtaláltam a hibát. Az volt a hiba, hogy a kódodban lévő A változót én egy negatív számmal is működő szorzással állítottam elő (A=x*y), ahol az y-t nyomógombbal állítom be a x meg konstans, és ez nem volt lekorlátozva nekem, tehát beírhattam neki 32767-et is, így többszörös túlcsordulás történhetett. De most lekorlátoztam, mert amúgy sincs szükségem csak max. 256-ra, és így működik rendesen.
Csak annyi bökkenő lesz még, hogy ezt a végeredményt ismét be kell majd szoroznom egy konstans értékkel. Ekkor lehet már fel kell bővítenem az eredményt 24-bitre amit nem szeretnék, főleg, hogy csak 8 bites a PIC. Lehet tényleg venni fogok inkább egy 16 bites kontrollert. Abból mit ajánlotok, az olcsóbb kategóriából?
Szia!
Ne add fel, a szorzás is elmegy akár 24 bites eredményre is a 8 bites kontrollerrel: Már sokszor linkeltem be ezt az oldalt... A 16 bites gépen is kell a bővítés a 24 bit kezelésére...
Ha sokat számolsz többbyteos számokkal, akkor megéri váltani 16-bitesre. De nem feltétlenül szükséges, mivel a Midrange sorozat alapból támogatja a többbyteos (átviteles) műveleteket. Meg 24-bites összeadásnál a PIC24-nél is átvitelre van szükség, tehát ezt semmiképp nem kerülöd el. Ha az ember tisztában van a matematikai alapokkal, a számrendszerekkel, akkor nem okozhat nehézséget még a lebegőpontos számokkal való művelet sem.
Hogy milyen 16-bitest ajánlok? Nem ajánlok semmit!
A megvalósítandó cél dönti el hogy mit használsz. PIC24-ből is vannak 14 lábú, ill. 5V-os példányok, kevés perifériával. De vannak kisfeszültségű, 144 lábú, LCD vezérlős, ill. akár 70 MIPS sebességű típusok is. Ha pedig bonyolult matematikai műveleteket akarsz végezni lebegőpontos számokkal, akkor ott a PIC30, ill. PIC33. (De ne feledd, hogy az alapokkal akkor is tisztában kell lenned! A mikrovezérlő nem fogja helyetted megoldani a problémát.)
Tudom, hogy kell de legalább kevesebb művelettel van meg.
A linket már ismerem. ![]()
Te mondtad, hogy elavult már a 8 bit. Jelenleg most ilyen számokkal kell számolnom, hogy mit hoz a jövő azt még nem tudom. De nyilván nem fogok venni egy 32 bites pic-et ha pl. egy hőmérőt szeretnék készíteni. Jelenleg most robotikai célokra kell, oda meg nem ártana egy olyan típus aminél kevesebbet kell agyalni pl. egy egyszerű szorzás vagy osztás végrehajtásánál.
De ahogy nézem árban sem nagy különbség van a 8,16 és 32 bites példányok között.
Egyszerűbb célokra teljesen jók a 8-bitesek is, de a Baseline sorozat tényleg elavult. Ezeket a Microchip minden területen leváltja a Midrange-el.
Viszont komolyabb számolásokhoz tényleg szükség van a 16-bites procikra. Nem csupán a 16-bites adatkezelés miatt, hanem a sok munkaregiszter és a jól használható utasítások miatt. Meg még sorolhatnám... Láthattad hogy egy ilyen egyszerű feladatnál is mennyivel kevesebb kód (és idő) szükséges a megoldáshoz, mint egy 8-bitesen. Szóval... Én semmiképp sem szeretnélek lebeszélni arról, hogy használd őket, ha szükségesnek látod. Sőt... ![]()
A PIC32F -en a 24 bites összeadás csak egy gépi kódú utasítás, azzal még sokkal könnyebb.... Csak mire elindítod, megtanulod beállítani, megtanulod a MIPS utasításokat, már rég megcsinéltad egy 8 bitessel...
A dsPIC30 dsPIC33F -ben van két 40 bites akkumulátor (ACCA, ACCB) is...
A PIC32 jóval bonyolultabb, mint a többi Microchip mikrovezérlő. Kezdőknek semmiképp nem ajánlanám. A PIC24, ill. dsPIC viszont nagyon barátságos jószágok. Természetesen dsPIC-nél a 40-bites akkumulátorok is munkára foghatók, de azok több előkészületet igényelnek. Tulajdonképpen a lebegőpontos számok kezelésére lettek kitalálva, emiatt működnek egész és tört módban is. (Persze nem lebegőpontos formában számolnak, hanem fixpontos egész ill. tört módban. Így külön kell számítani a karakterisztikát és a mantisszát.)
|
Bejelentkezés
Hirdetés |