Fórum témák
» Több friss téma |
Nincs mit.
Még egy tipp, ha változókat kell szorozni:
Igy a szorzás előtt konvertálja az a x1 változót. Nem túl szép ha sokszor kell tipust kényszeríteni, de hatásos.
Float típusú számításoknál is hasonló a helyzet?
Az Ansi C standard szerint a float a művelet előtt double-lé konvertálódik és azt eredmény is az lesz.
A C18 esetében azt hiszem a double mérete akkora mint a float, de lehet hogy tévedek. Idézet: „A C18 esetében azt hiszem a double mérete akkora mint a float” Ez elvileg így van... :yes:
Teljesen. Én is ebben a cipőben járok mostanság, miután polinom együtthatókkal kell dolgoznom.
Például, ha egy long típust, float változóba akarsz osztani, elég ennyi:
Most próbálom a float típust elkerülni, mert elég nagy gubancot csináltam.
 Szerk.: bár nem ide tartozik, de van olyan PIC, amiben hardveres osztó van?
A PIC32 családban 32bites szorzó-osztó van.
No még egy indok, amiért ki kéne próbálni a PIC32 típust.
Ha jól rémlik a dsPIC-ekben is van.
A float elég erőforrás igényes, de nem vészes, elég gyors a PIC, csak zabálja a program memóriát ha sok a művelet.
Üdv!
Újra elővettem a régi ledmátrixomat, mert már valamit kellene kezdenem vele... A HI-TIDE HI-TECH C PRO 9.60PL2 fordítóját használom, a cél ic PIC16F59. A problémám az, hogy folyamatosan hibával bombáz a fordító, pedig eredetileg 16F57 volt a vezérlője mégis ráment a program. (1253) could not find space (18 bytes) for auto/param block [C:\Program Files\HI-TECH Software\PICC\PRO\9.60\sources\wmul.c] Az eredeti program a led.c, az átírt pedig a main.c . Valaki megtudná nézni mi lehet a gond? Köszönöm! Idézet: „const unsigned char CoName[224]={” Csak egy otlet: Nem tudom ennel a forditonal konkretan hogyan van, de van olyan PIC fordito ahol kulon meg kell adni a 'rom' kulcsszot is, nem eleg neki a 'const' hogy ROM-ba keruljon a tabla.
Egy kisebb fajta fordulat a dologban, hogy a pointer függvénynél levő cnt_flag kivétele csökkenti eggyel a hiányzó byte-ok számát.
value=*(CoName+(guide<<0)-(guide<<0)+cnt_flag); Viszont mostmár nincs probléma, lefordul a program, majd műszaki javításokat kell végeznem az élesztés előtt. Ezzel a HI-TIDE-al sosem voltam kibékülve, mindig más szituációt hoz egy forráskódnál, most kibővítettem az eredeti nyomógomb és állapotgép kezeléssel és mégis lefordul a program, megcsonkítva viszont sipákol. Lehet, hogy ez a 45 napos PRO próbaverzió átka. Kb. 2010-es hsz-emben írtam erről a dologról, még akkor az volt a problémám, hogy nem megy a teljes kijelző felület elérése, minden 7. sor után egy sort kihagy, vagyis folytatja a kijelzést. A gyári dokumentációt csatolom. Ha esetleg valaki tudna egy kis transzformációs segítséget adni, hogy ezt a programot meg lehet-e assembly-ben írni, támogatnám. Köszönöm a segítségét minden szak fórumtársnak!>>>>
Miután már többször átbogarásztam a leírást és mégsem találtam a megfelelő választ, ezért a kérdésemet felteszem ide is, hátha valaki járatos a témában. Nagyon régóta az SDCC fordítót használom, ugyanis ott világosan látszódik, mire fordítja le a C sorokat a program, amiből viszont szintén kiviláglott, hogy a korábban megírt assembly rutinjaimat hogyan tudnám beilleszteni objektum szinten a PIC programjába, meg hogy milyen módon férhetek hozzá C-s változókhoz az assembly rutinban, illetve assembly változókhoz a C-rutinokban.
PIC váltás miatt azonban ( az SDCC nem támogatja még a 16F1xxx sorozatot ), előszedtem a HITech fordítóját. Ott már mindent C-ben kellett megírnom, egyrészt az idő rövidsége miatt, másrészt meg nem látok assembly listát, ami segítene az illesztésben. Kérdés tehát, hogy hogyan lehetne rávenni a HITech fordítót, hogy assembly listát generáljon, illetve melyik dokumentáció taglalja a paraméterátadásokat, változónév használatokat külső objektumok és a HITech C kódja között?
Mindent meg lehet írni ASM-ban. Hogy meg tudod-e, azt nem tudhatjuk. Ha ilyen dolgokat csinál egy fordító, akkor váltani kell. Nekem a gyártó oldaláról letöltött Hi-Tech C semmi ilyesmit nem csinál!
A fordító készít egy *.lst fájlt. Ebben minden tökéletesen megvan.
Idézet: „melyik dokumentáció taglalja a paraméterátadásokat, változónév használatokat külső objektumok és a HITech C kódja között?” A PIC10/12/16 User's guide valamint a PIC18 manual is 3. fejezetben a "MIXING C AND ASSEMBLY CODE" részben leírja. Idézet: „hogyan lehetne rávenni a HITech fordítót, hogy assembly listát generáljon” watt válasza plusz .as kiterjesztéssel ezt megteszi, illetve MPLAB-ben a Disassembly Listing-gel szépen megnézhető... Látom írás közben az ".as" is felmerült... 
Köszönöm a válaszokat.
Sziasztok! Szerintem ebbe a topicba még belefér a kérdésem. Azt szeretném megtudakolni, hogy amikor C18-al usart-on akarok adatot küldeni, akkor ugye ezt a parancsot használom : putrsUSART("szöveg") és ez még megy is, remekül, de ha egy számot, vagy egy számot tartalmazó változót akarok elküldeni vele pl.: putrsUSART(10) akkor egy halom értelmetlen karaktert rak be. Szóval nem tudjátok, hogy milyen függvénnyel lehet egy értéket elküldeni a PIC-nek usart-on? Előre is köszönöm!
Szia!
Tedd idézőjelek közé, így: putrsUSART("10"); Valószínűleg az ASCII kódot küldte ki. Ha ASCII kódban akarod kiküldeni, akkor két karaktert kell elküldeni, az "1"-et és a "0"-át így:
Ha ragaszkodsz a karakterfüzért küldő függvényhez, akkor a numerikus adatokat előbb szöveggé kell alakítani, nem feledkezve meg a szöveget lezáró nulláról sem.
Én inkább a karakterenkénti küldést használom, s a számok kiírásához egy ilyen függvényt használok:
Az első paraméter a kiírandó szám (előjeles 32 bites egész), a második paraméter a levágandó tizedesek száma. Például, ha a feszültség mV egységekben van megadva, akkor outdec(3300,3) hatására +3.300 íródik ki. Ha a hőmérséklet tizedfokokban adott, akkor outdec(273,1) hatására +27.3 íródik ki.
Nos, első körben azt kéne tudni, hogy mit akarsz elküldeni. A 10 értékét(azaz a bájt ami átmegy hex 0x0A legyen), vagy az 1 és 0 karaktert egymás után. Ez utóbbinak nem sok értelme van szerintem, mert a forgalmat jelentősen növeli. Ha átküldöd a 10-et, mint szám, akkor az majd a PIC-ben alakíthatod át kijelzendő digitenkénti karakterkódokká. Az értéket a putcUSART-al tudod küldeni egyenként.
Annyit még megjegyzek, hogy a putcUSART egy agyrém! Ha megnézed a gyári kódot, akkor láthatod, hogy egy sorért, a TXREG=változó -ért egy szubrutint alkottak. Ez borzasztóan erőforrás igényes és abszolut felesleges tortura. Tudom, először a lényeg, hogy működjön, de gondoltam adok egy löketet, hogy érdemes mögé nézni a dolgoknak. A while (BusyUSART()); hasonló agyrém. A while(!TXSTAbits.TRMT) ugyanazt csinálja. Ha készítesz hozzá egy definíciót így: #define TX_Redy TXSTAbits.TRMT akkor ilyen formában lehet használni subrutinhívás nélkül:
Csatoltam két képet, látható, hogy az ajánlott verzió két utasításra fordítódik, a másik pedig nem is számolom és a CALL-t nem is említem! :bummafejbe:
Beillesztettem a kódod, és kis alakítással sikerült küldeni számot, szóval köszönöm szépen!
Watt: Igazából a puTTY nevű konzol programmal küldök a pic-nek egy hex kódot, és utána rávenni a hogy egy értéket, valami 0-255-ig küldjön vissza nekem. Ez úgy tűnik most már működik is. Csak az a bajom, hogy áttérnék visual basic-ben írt programra, magyarul onnan küldeni az infót a pic-nek csak az meg valamiért nem akar működni, de az már nem ide tartozik Köszönöm a segítségeteket!
A bajt én ott látom, hogy nem világos számomra, hogy tisztában vagy-e az elküldött bájtok információ tartalmával! Tudsz válaszolni a korábbi hozzászólásomban feltett kérdésimre? Mert a VB-vel pont másképp érdemes infót cserélni, mint most teszed.
Csak azt kérdezted, hogy mit akarok elküldeni én pedig mondtam hogy egy számot nullától 255-ig. Nem tudom amúgy, hogy hogy érdemes VB-ben adatot küldeni, de ahogy én akartam csinálni, az végül is sikerült.
Szerintem watt ugy erti, hogy Te atalaitod szovegge amit atkuldesz amit a masik oldalon vissza alakitasz. Es, hogy ez a modszer noha mukodik, feleslegesen foglalja a CPU idot es terheli a kommunikacios csatornat (hisz egy byte helyett 3-at kuldesz at egy szamhoz amennyiben atalakitod karakter lancca...).
Amugy az itoa() es atoi() fuggvenyek miert nem voltak jok?
255-öt el lehet küldeni úgy, hogy 0x32("2"), 0x35("5"), 0x35("5"), és úgy is, hogy 0xFF. Ez utóbbihoz semmi nem kell, csak TXREG=0xFF;
Ahh, így értem
Hát igen, a másik megoldás tényleg jobb, majd még próbálkozom más módszerrel, ezen a pic-en úgyis csak "gyakoroltam"  Majd egy másik pic-re kell a tényleges jól működő kódot megírnom, akkor bizonyára máshogy fogom csinálni, mert ez a mostani egy agyrém. Működik nagyjából, de nagyon össze vissza van meg zavaros. Mindenesetre, köszönöm a segítséget, biztos zaklatlak még titeket |
Bejelentkezés
Hirdetés |
