Fórum témák
» Több friss téma |
Fixpontos és lebegőpontos osztás/szorzás kapcsán érdeklődnék. Nézegettem a már többször belinkelt oldal Multiply / Divide linkjein lévő példákat, és néhány kérdés felmerült bennem.
Az rendben, hogy hány bites operandusokkal számolunk, de ezek egészek/fixpontosak/lebegőpontosak? Milyen processzorra készültek a mintaprogramok? Például a PIC 24 közvetlenül a DIV.UD WM,Wn -el tud Unsigned 32/16-bit Integer Divide -t, vagy a MUL.SS Wb,Ws,Wnd -el Wnd+1:Wnd = sign(Wb)*sign(Ws) -t. Ha magam akarok például fixpontos számot ábrázolni mondjuk 16 biten én határozom meg az egészrész / tötrész bitjeinek számát kedvemre egy PIC 18 -on? És még valami: Fixpontos ábrázolás esetén miért kell negatív szám esetén mind az egészrésznek, mind a törtrésznek a venni kell a kettes komplemensét?
A már többször belinkelt oldalon a Multiply / Divide linkjein lévő példák egész számokkal működnek, a rutiniknál le van írva, hogy előjeles vagy előjel nélküli számokat használ. 8 bites midrange PIC -ekre (16F) készültek, de kis munkával átírhatók 18F -ekre is.
Rendeben van, hogy a 24F el tud osztani egy 32 bites számot egy 16 bitessel, de a következő fennakad a torkán: 134217727 / 22 = 6100805 azaz 0x7FFFFFF / 0x16 = 0x5D1745, mivel az eredmény 16 bitnél nagyobb lesz... Ekkor ezekből a rutinokból kiindulva meg lehet írni a 16 bitesekre is az osztást, ami 32 bites hányadost is megenged. 16F vagy 18F -re lebegőpontos eljárások is léteznek Assembly szinten: An575 Már a jó öreg 16C84 -en lehetett használni... A 18F -re készített frekvenciamérőben 48 / 64 bites egyész aritmetikával számolom a frekvenciából a periódusidőt (vagy fordítva) és külön tartom nyilván a tizedespont helyét... Idézet: „de a következő fennakad a torkán: 134217727 / 22 = 6100805 azaz 0x7FFFFFF / 0x16 = 0x5D1745, mivel az eredmény 16 bitnél nagyobb lesz...” A túlcsordulás bit jelzi hogy az eredmény nem ábrázolható 16 biten. Ilyenkor az osztót szorozhatjuk 256-tal (balra toljuk 8-cal), majd megismételjük az osztást. Az eredményt 32 bitre bővítjük, majd 256-tal szorozzuk (balra toljuk 8-cal). Ezután az osztás maradékát újra osztjuk az eredeti osztóval, és ezt az eredményt az előző részeredményhez adjuk 32-bitesen.
Egy minden esetet pontosan lekezelő rutin körülbelül olyan bonyolult lesz, mit a 8 bites kontrollereken...
Üdvözlete!
Megpróbáltam megépíteni egy E-dobókockát. A nyákot megcsináltam, csak a pic 12 es hiányzik belőle. Csináltam egy pic égetőt: http://www.picnick.hu/egeto/eget.htm ez a kapcsolás alapján. A pic égetéskor kiírja, hogy "oscillator configuration found" vagy hasonlót. A program beállításokat: http://www.picnick.hu/egeto/ic_prog_beall.htm erről az oldalról néztem. A dobókockába berakom a pic et de semmi nem történik! Ha van ötletetek elfogadnám.
Az Ic-programernél csak a program részébe kell adatot vinni?
Az eeprom részt hagyjam üresen? A bevitelnél ha a karakterek "kínaiak" az probléma?
Szia!
Egy újabb áldozat.... Vedd ki a 7405 vagy 74LS05 tokot az áramkörből, tegyél a helyére 7406 vagy 74LS06 áramkört. A 7405, 74LS05 alkalmatlan a feladatra.
Köszönöm a segítséget, megpróbálom megcserélni ahogyan írtad, ha végzek vele megírom a fejleményeket.
üdv. speed008
Megnéztem a pontos hibakád. Oscillatior Callibration Value.
Bocs, hogy érdeklődök, de ez már másoknál is előjött? Nem vagyok szakértő, de miért van ez pontosan?
Szia!
Csatolj inkább képet a hibáról és töltsd fel a hex állmányt is.
Üdv!
A probléma abból áll, hogy a pic et nem ithon írom, hanem az egyik ismerősömnél, mert a laptopokon nincsen soros port. Az IC-Prog konfigurálás után, amikor a hex filet importáltam bele és fel szeretném . égetni, hogy No "Oscillatior Callibration Value" Rányomok, hogy igen és a program végigfult, majd kiírja, hogy a felírás sikertelen. Próbáltam visszaolvasni, ami elvileg sikerült is. Amikor berakom a kockába semmi sem történik vele. Próbáltam tisztítani az PIC et dés újraírni, de a hiba ugyanúgy fenn áll. A dobókocka kapcsolását innen vettem: http://www.hobbielektronika.hu/kapcsolasok/elektromos_dobokocka_pic...2.html a program pedig itt van: http://www.hobbielektronika.hu/kapcsolasok/files/459/dobokocka.hex A nyáktervemet mellékeltem, a ledeket próbáltam megforgatni, hátha fordítva raktam be, de semmi. Az a gondom, hogy szerintem az égető áramkörrel van hiba, lehet az amit te mondtál, hogy 74LS05 helyett 74LS06 kellene. A Picall program például nem ismeri fel az égetőt, pedig elvileg azzal teljes kompatibilisnak kellene lennie. Az normális, hogy a .hex filet amikor hozzáadom a programhoz, akkor vannak benne érdekes karakterek? vagy ez valami nyelveltérési hiba?
Szia!
Lefordítottam a következő C programot 24FJ32GA002 -re.
Vettem a fáradságot és megnéztem a program memóriát, ami a mellékelt exportált listán látható. A 8 biteseknél is bevált léptetős megoldást látom. A fordítom nem optimalizált jól, vagy a div utasításokkal bonyolultabb lenne?
Szia!
Elnézést de beszúrom ide a hex állományt - nem hosszú. Így kellene kinéznie - a színezést leszámítva...
Az a baja, hogy a 25. sorban egy retlw 0x00 utasítás áll. A 0x00 helyett annak az értéknek kellene benne lennie, ami az első törlés előtt volt a kontrollerben. Mivel nem eget rengető az órajel pontossága, írj bele egy tetszőleges, nem 0x00 adatot. Azaz a programozás előtt a 0x3FF program memória címen a 0x3455 értéknek kellene lennie. (A 0x55 a tetszőleges adat.)
Köszi mindent!
Nem lenne nagy kérés, hogy ezt a sok jót, leírjad nekem egyszerűsítve? Még nem dolgoztam PIC el és programozó sem vagyok. Arra rájöttem, hogy a Pic 12F629- nél van programozáskor egy program és egy EEprom ablak. A kérdésem, hogy az EEprom ablakába kell valamit változtatni? A 74LS06 os ic-t rakjam bele égetéskor? Ha a te leírásodat bemásolom az égetőbe akkor lev jó lesz? Bocs, hogy kérdezek, de kezd érdekelni a téma. 
Üdv.
Csináltam pár képet a hibáról. Az első képen a hiba felirata látszik. A másik kettőn pedig amikor a programot beimportáltam a programba. (Az második módszernél Assembley kódolásba is látszik valami, az elsőnél csak kérdőjelek vannak.
Inkább ezt próbáld meg...
Beimportáltam a programba, de a hiba még mindig fent áll.
A kocka még mindig el van vetve. Ha lesz időm szerzek 06-os ict aztán megpróbálom azzal is.
'07 is jo. Csak a programban at kell allitani, mert a '06 invertal, a '07 nem invertal.
Még egy apróság: Sok programozó a gyári érték megtartása érdekében importáláskor kiolvassa a kontrollerből az osccal értéket, a hex állománybelit felülírja a kiolvasottal. Lehet, hogy az általad használt program is ilyen (én nem használom). Ez esetben az importálást úgy kell elvégezni, hogy a programozóra van csatlakoztatva a kontroller vagy az importálás után kell az értéket kézzel módosítani.
Ideje lenne egy gyári programozót beszerezni vagy utánépíteni...
A DIV utasítást 16-bites számokkal való osztásra tervezték. Míg az osztandó szabadon bővíthető, az (A+B)/C = A/C + B/C azonosság értelmében, addig az osztó nem bontható fel így. Emiatt kell saját iterációs osztó eljárást írni 32-bites (vagy nagyobb) osztóhoz. Egyébként a DIV utasítás ugyanilyen iterációs algoritmust használ, csak hardveresen némileg megtámogatva.
Ez a programozó elvileg ProPic2 néven fut.
Megpróbálom először kicserélni az ic-t. Meg megpróbálom a beállításokat finomhangolni.
Szia!
PICKit2 -t használok, ott az importálás kiolvassa az OSCCAL értéket a kontrollerből.
Üdv!
Megpróbáltam a WinPic800 programot. Ez a hardver elvileg törléskor viszaolvas mindent. Bevittem vele egy programot, de itt is hibát írt ki az ellenörző egység. Amikor az ic üres benne, akkor kiolvasáskor mindent rendben talál és 3FFF lesz mindenhol. Olvastam olyat, hogy a túl gyors gépek is bekeverhetnek a rendszer működésében? Nem tudjátok, hogy mi okozhatja a hibát amit kiír?
Szia!
Ezen hozzászólásod alapján nem értem erre a hozzászólásomra adott válaszodat. Mégicsak a léptetős, iterálós eljárás a megoldás a 16 biteseken is. (Sőt a 32 bitesen is, ha 128 bit / 128 bit osztást kell végezni.)
Üdv.
Nekem is ugyan ezeket a hibaüzenetet dobta a(z) Icprog és a winpic is akkor "utáltam" meg a jpm-et  belefogtam a pickit2-be de idő és pénz szűkében még csak a nyáknál tartok!Ui: Mérd meg a vpp-t és a vdd-t is hogy megvan-e, esetleg szkóppal rámérhetsz az adat és órajelre, a pic adatlapjában megtalálod mit kellene mérned.
Már kezd lasan engem is idegesíteni a dolog. Ne, lehet hogy a pc-s programok csinálják a feszkót?
Még próbálkozok más beállításokkal. Van egy tartalék win98 as gépem, poénból kipróbállom azon is valami öskövület rendszerrel [code=c]
Megnéztem jobban a kapcsolási rajzot, és úgy látom az MCLR láb nincs felhúzva VDD-re, így a pic nem léphet programozói módba, úgy tudom 10K ellenállással felkellene húzni +5V-ra.
Üdv!
Végül is egy próbát megér. Majd keresek ellen?lást aztán megpróbállom. Az alkatrészjegyzékbe volt egy plusz ell. ami nem lett felhasználva. De lehet, hogy a programozó magába jó, mert amikor rákötöm gépre felismeri a pic et. Ha figyelmen kívül hagyom a hibajelzést fel is viszi elvileg a pic re, bár nem lehet, hogy a hex ic be megy csak adat? Visszaolvasásnál pedig mintha megírta volna a pic et. Kipróbállom a felhúzó ellenállást, hátha segítene.
Üdv!
Valaki tudna ajánlani nekem egy jól működő, könnyen megépíthető, lehetőleg USB-s pic programozót? |
Bejelentkezés
Hirdetés |
