Fórum témák
» Több friss téma |
A tömb első elemére mutató pointert szokás C-ben átadni. Azt viszont neked kell tudni, hogy a tömb mekkora, mert ez az információ a pointerré alakítás közben elveszik.
Tudtommal nem, a Microchip nem tette közzé a kódot.
Találtam viszont egy német nyelvű topikot ezzel kapcsolatban: Bővebben: link A hozzászólás módosítva: Szept 8, 2012
Sziasztok!
Két fix pontos számot hogy lehetne beszorozni egymással viszonylag egyszerűen? Pl. 8,24 * 42,56 = 350,6944 Én most magamtól csak annyit tudnék csinálni, hogy felszorzom őket 100-zal, (824 * 4256 = 3506944) majd az eredményt beosztom 10000-rel. Pontosabban: egészrész = eredmény / 10000; (2 byte) törtrész = eredmény % 10000; (2 byte) De szerintem ez megölné a procit, nagyon lassú lenne. Amúgy a törtrész elég lenne 2 tizedes jegy pontossággal is. Ti hogy csinálnátok?
Nem értem... A fixpontos szám lényege, hogy integerben tárolom, eleve felszorozva mondjuk esetedben 100-zal. Azaz 8,24 helyett az van tárolva, hogy 824. Ezek után minek szorozgatni még?
Nem is a szorzáson volt a hangsúly. Nyilván nem fogok a PIC-ben egy float konstanst tárolni, hogy felszorozhassam 100-zal.
Az osztást tartom elég időigényesnek, meg mondjuk a 2 nagy szám szorzását is (824 * 4256). Amiből mellesleg az egyik érték változhat 200,00-ig is, tehát 20000-rel kellene szoroznom. Nem tudom, hogy egy 8 bites PIC mennyi idő alatt tudná ezt kiszámolni. Véleményem szerint jobb volna ha külön integer-ben tárolnám az egészrészt és a törtrészt, ahogy az összeadásnál is tettem. Mert az eredményből úgyis csak az egészrészt tudom felhasználni (de kell a törtrésszel is számolni a pontosság miatt) és egyszerűbb ha mondjuk az alsó integert elhagyom ami reprezentálja a törtszámokat és nem elosztom az eredményt 100-zal vagy ne adj Isten 10000-rel. De akár ezekből az összeadásokból is származhatna a tört szám és akkor már szorozgatni is kellene, hogy megkapjam pl. a 824-et. Egy példa: 160 * 9,2 = 1472 Vagyis a PIC-be egy 92 értékű konstanst hozok létre, és ezzel végzem a műveleteket. Tehát 160*92=14720 De ehhez hozzá kellene adnom még egy egész számot is ami legyen 78. Igen ám de ahhoz, hogy a 78-at hozzá tudjam adni és helyes eredményt kapjak muszáj felszoroznom 10-zel, vagyis 780-at kell hozzáadni, különben az eredmény 10-zel való leosztásakor ('/', '%') helytelen eredményt kapok. Tehát mégiscsak kell szoroznom. Egyébként kicsit utána nézve a dolognak (na nem nagyon  , mert nem sok érthető dolgot találtam ez ügyben) azt találtam, hogy a fix pontos műveleteket egyáltalán nem így végzik ahogy leírtam meg ahogy te is írtad, hanem úgy hogy pl. a 0,5-öt úgy tárolják le egy külön integer változóban, hogy az 16384-nek feleljen meg, a 0,05 pedig 1638-nak és így tovább. Szóval én azt vártam volna, hogy valaki az ilyen számokkal történő műveletvégzések lényegét leírná. De lehet, hogy rossz helyen keresgéltem, mert számomra elég pontatlannak tűnik ez a módszer.Az viszont biztos, hogy külön tárolják az egészrészt és a törtrészt. De ha ti sem ismertek hatékonyabb módszert a fent említett osztásos módszernél, akkor inkább hagyjuk az egészet. Idézet: Nem tudom, hogy van-e értelme külön tárolni az egészrészt és törtrészt. Én feszültséget mV, hőmérsékletet tizedfok egységekben számolok, s az egészrész meg a törtrész kiszámítása helyett csak kiíratásnál határozom meg a tizedespont helyét. Lásd például ezen az oldalon! Az outdec() függvény így néz ki:„egészrész = eredmény / 10000; (2 byte) törtrész = eredmény % 10000; (2 byte)”
Helló!
Ha csak én is kiíratni szeretném akkor nem bajlódnék vele, de nekem számolni is kell a törtrésszel és a PIC-be nagy sebességgel érkező impulzusok számát is hozzá kell adnom a törtszámhoz, aminél ha nem tárolom külön az egész- és törtrészt akkor az impulzusok számát fel kellene szoroznom 10-zel, 100-zal, hogy helyes eredményt kapjak az összeadás végén. De most hogy futási időben ugyanott vagyok-e ezzel a külön tárolással mintha beszoroznám az impulzusszámot, azt még át kell gondolnom. De valószínűleg lassabb lenne, mert ami most elfér 2 bájton ahhoz lehet 4 bájtra lenne szükségem ha a ti módszereteket használnám. A számolás végén meg úgyis be kell osztanom és elhagynom a tizedes törtet, mert kijelezni nem akarom, csak a belső számítási folyamatnál van szükség rá.
Szia!
Egy átmeneti megoldás, ha a 350,6096649169921875 megfelel a 350.6944 helyett. Használjunk 4 byte -os egészeket a műveletek végzésére, a bináris törtpont legyen középen. Ekkor a 8.42 * 42.56 az alábbi longint szorzásra vezet : 0x83D * 0x2A8F. Elvégezve a 0x15E9C13 értéket kapjuk. Értelmezve a 0x15E egészet és 0x9C13 törtrészt: 350 + ( 39955/ 65536) = 350.6096649169921875 értékhez jutunk. A fenti módszer szerint végezzük a szorzást, de elvégezhetjük az összeadást is. Pl. ha egy egészet (dec. -49 ) akarunk a fenti számhoz hozzáadni, akkor megtehetjük az alábbi módon: 0x15E9C13 + ( dec -49) = 0x15E9C13 + 0xFFCF0000 = 0x012D9C13 átszámolva: 301.6096649169921875 A műveletekhez nem kellett szorozni, osztani, csak a számokat 16.16 bites (bináris egész).(bináris tört) formában kell megadni. BCD konvertálás a kijelzéshez: Nem kell osztást és moduló művelet végezni (egy 24 bites számnál ez 16 egész osztás, azaz 256 léptetés, ha valaki megnézi az assembly kódot...). Elég a léptetés művelet (a fenti esetet véve csak 24 db.). Ez a rutin egy 24 bites számot konvertál 8 digit pakolt BCD formára 24 léptetéssel és korrigálással - osztás és moduló nélkül.
Miert nem jo neked amugy a float tipussal szamolni?
Itt egy lehetseges megoldas ahol a tort resz es az egesz resz kulon van szedve:
Szia, en meg mindig probalom kibogozni mire gondoltal. Azt irod:
Idézet: „Ekkor a 8.42 * 42.56 az alábbi longint szorzásra vezet : 0x83D * 0x2A8F. Elvégezve a 0x15E9C13 értéket kapjuk” Ahol a 0x8 az ugye dec 8 az stimmel, 0x2A az is stimmel mert az dec 42, name a 0x3D es a 0x8F az mar nem tunik jonak, mert nem .42 ill .56 ... Hogyan jott ki neked ez az ertek?
Szia!
Idézet: „Idézet: „Ekkor a 8.42 * 42.56 az alábbi longint szorzásra vezet : 0x83D * 0x2A8F. Elvégezve a 0x15E9C13 értéket kapjuk” ” Sajnos már itt elírtam, eredetileg 8.24 * 42.56 -ről volt szó. A többi jó. Ezek bináris törtszámok:
Ja, ertem mar mit csinalsz, vegulis 256-tal felszorzod a tort reszt, hogy egeszeket kapj, es azzal szamolsz, majd pedig kiirasnal pedig be kell szorozni 100-al utana elosztani 65536-tal, hogy integerkent kiirhato legyen.
Amugy meg mindig azt mondanam a beepitett floatokkal egyszerubb es gyorsabb lenne szamolni.
Sziasztok! PIC programozásban nagyon kezdő vagyok. Viszont C nyelven már programoztam (PC-n).
A közeljövőben PIC18F-el kellene egy áramkört építenem, ami analóg értékeket mér (12bites felbontással), és kb. 2x 15...20 digitális In/Out adatot fogad/küld, illetve soros porton (UART - RS232) is fogadja/továbbítja az adatokat. Valamint 2x16-os karakteres LCD-n is kellene adatokat megjelenítenie. A kérdésem, melyik C fordítót lenne érdemes használnom? Melyiknek elég jó pl. a helpje, hogy gyorsan beletanuljak, és viszonylag hamar érhessek el eredményt? Melyikben van sok függvény gyárilag megvalósítva (hogy ne nekem kelljen megírni), pl. soros port kezelés pufferelés, LCD kezelés stb... Tehát merre induljak el? Esetleg konkrét PIC tipust is tud valaki ajánlani a feladatra (ami később is beszerezhető lesz - tehát pl. nem kifutó tipus)? A hozzászólás módosítva: Szept 18, 2012
Szia!
Valami ilyesmire gondoltam én is, hogy csak tologatni kelljen a biteket. A pontosság talán megfelel. Köszi! Egyébként ha C-ben azt írom le, hogy x/256 vagy x/65536, akkor a fordító igaz tudni fogja, hogy csak tologatni kell, nem kell a << és >> operátorokat használnom?
Szia! Egy float szorzás gyors, de egy összeadás már nem. Hiszen két float számot összeadni csak úgy lehet, hogy előbb azonos kitevőre kell hozni őket, aztán összeadni és végül visszanormálni a float alakra. A fenti számolásomban nincs 256 -tal, 65536 -tal való szorzás vagy osztás, hiszen azt a megfelelő byte elővételével vagy beírásával meg lehet tennni. Az összeadás egy longint összeadás, persze az összeadandókat a megfelelő helyiértékre kell beírni, a többit ki kell nullázni. A szorszásnál van egy kis stikli. (8 bit egész és 8 bit tört) szorozva (8 bit egész és 8 bit tört) -tel ad (16 bit egész és 16 bit tört) -et. A kiírási BCD formára hozáskor lesz még egy szorzás (10 annyiadik hatványával, ahány tizedest szeretnénk). Magához a BCD átalakításhoz elég az egészek és a törtrész bitszámának megfelelő számú léptetés. Összességében jóval kevesebb művelet, mint a 8.24 * 42.56 + 0.23 művelet float számokkal elvégezve...
Ti mondtátok, hogy ne számoljak float-okkal mert időigényes, úgyhogy ne gyere nekem most azzal, hogy használjak float-ot!
Sziasztok!
olyan problémám van beviszek 7 ascii számot ebből szertnék ki vonni másik 7 ascci számot ezt hogy tudnám megvalósítani? lenti kódom nincs benne a kivonás csak átalakítás hogy majd eltudjam végezni a kivonást 4 ascii karakterig jó csak utána - eredményt kapok az 5. számtól... előre is köszönöm a válaszokat!!!
A hozzászólás módosítva: Szept 18, 2012
Szia!
Az unsigned int általában 16 bites, azaz maximális ábrázolható szám 65536. Használj unsigned long típust, abban elvégezheted a 7 decimális számjeggyel történő számítást. A hozzászólás módosítva: Szept 18, 2012
Kösszi a segítséget! már majd nem jó, csak Longtostr-nél át másolom a LCD_temp-be belevisz 4 karaktert pluszba vagyis 4-helyi értékel később írja ki LCD_Out(2, 4, Lcd_temp) ; vagyis a 4 helyi értékbe nincs semmi azt is kiírja ezt valahogy ki lehetne küszöbölni?
elöző kérdésemet át fogalmazom
char Lcd_temp[6]; ebből hogy lesz "Lcd_temp[13];" vagyis longtostr hogy rak bele plusz karaktert ha 7 karaktere van definálva Lcd_temp?
Sziasztok!
Ismerkedek az új XC8 fordítóval. A rutinok forrását nézegetve találtam egypár gyöngyszemet: cos.c:
Ezek után nem meglepő a sin.c és a tan.c is tartalmas i8086 és i8087 -re való utalásokat. Még az is lehet, hogy a 6 lábú PIC10F320 mellé beköthetünk egy levedlett Intel 8087 kooprocesszort is?  Idézet: Nem, ez akkor kell, ha a PIC10F320-ra írt alkalmazást PC-re portolod. „a 6 lábú PIC10F320 mellé beköthetünk egy levedlett Intel 8087 kooprocesszort is?”  Idézet: Aggódok... Akkor miért nincs a többi float műveletben? A szegény szerencsétlen Pentum mit_tudom_én_hány kénytelen lesz a float osztást, szorzást, összeadást stb. maga megcsinálni a kooprocesszora helyett. Kicsit sánta ez így...„PIC10F320-ra írt alkalmazást PC-re portolod” Én inkább a slendriánságot vélem felfedezni...
Szerintem nem erdemes teljesen bele bonyolodni ebbe, egyreszt nem tudjuk (vagy legalabbis en nem tudom), hogy milyen mas platformokra is szeretnek forditani a kodot, masreszt azt sem tudjuk, az azon a platformon hasznalt X vagy Y fordito amivel az eredeti kodot forditani szandekoztak milyen definiciokat keszit ha a target Pentium pl (konnyen lehet ott van az az i8086 is).
A lenyeg a Te semszogodbol most, hogy toroldd ki az ifdef-ek kozotti reszeket, neked az most ugy sem kell es igy tisztabban fogod latni mit csinal a kod...
sziasztok!
mikroc-vel van pár rossz tapasztalatom... melyik fórdított lenne érdemes helyette használnom... amivel nincs annyi gond mint a mikrocvel.... előre is köszi válaszotokat!
Mi a bajod a MikroC-vel én azt használom és tökéletes. Komoly rendszert(PIC18+uSD+MP3 decoder+LCD+RS-485+RS232) is meglehet benne írni. 2 éve használom és nem váltanék másra. Igen vannak betegségei de melyik fordítónak nincs?
Ha leírod a problémád lehet tudunk rajta segíteni. A hozzászólás módosítva: Szept 21, 2012
Szia
előre is bocsi nem a másik topicba írtam!!! Én is sok mindent megcsináltam már vele dallas kulcsos eeprom szimulálása stb... eddig jó tapasztalataim voltak mikrocvel. de jártam már úgy is vele hogy, TRISA = 0b1101111; de muszáj volt beírni utána hogy TRISA7_bit = 1; mert valahogy nem lett bemenet az a láb. persze többi láb jó beállt. de a beépített keypad lib-el is úgy jártam csak 8 gombnál kifagyott a program, persze a többi gombott olvasta rendesen ezért váltottam másik keypad lib-re. mostani kódnál az egyik dolog amit nem értek ha én lefoglalom pl. lcd_temp 7karatere hogy írhat bele többet? oké tudom nullákat is kiratom de akkor is másik dolog egyik helyen múködik atol parcs máshol nem... érdekes
előre is köszi a segítséget! A hozzászólás módosítva: Szept 22, 2012
Idézet: „TRISA = 0b1101111; de muszáj volt beírni utána hogy TRISA7_bit = 1; mert valahogy nem lett bemenet az a láb. persze többi láb jó beállt.” Na igen ez betegség, ilyenbe már többször belefutottam én is. Melyik verziót használod? A legújabb már okés ilyen hibákra. Az hogy lefoglalsz 7 karaktert nem azt jelenti, hogy csak 7 karaktert enged beleírni futási időben. Futási időben akár 1000karaktert is beleírhatsz csak felül fog írni más változókat. Ebből lehet később hibás számítás vagy lefagyás. A parancs anomália már érdekes. Ezt is meg kell debugollni.
hát pedig a legújabb verzió volt... bemenet probléma
7 karakter oké hogy tobbit bele írja de hogy olvassa ki? amúgy ha elhagyom a withzero parancsot akkor is úgyan úgy rossz... A hozzászólás módosítva: Szept 22, 2012
|
Bejelentkezés
Hirdetés |
