Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Köszi Srácok!
Ma délutánra megírom a programot. Aztán beviszem neki! Mondtam, hogy ha van időnk irhatnék több verziót, is szkópon szivesen megnézném melyik a gyorsabb. Egyrészt mert érdekel, másrészt szerintem az ő verziója lassabb lenne  Idézet: Ott nem füstöltem, velem volt a barátnőm „Amszterdamba mentetek? Nagyon fustolsz...”  De durva mennyi puccér csaj vonaglik az ablakokban.... 
Üdv!
Valami apróságot elronthatok és nem veszem észre, mi a hiba. A PORTD-be akarok berakni biteket teszt gyanánt, ezt bemásolni a POSI-ba, de nem megy bele, a watch ablakba nézem és nulla marad a PORD és a POSI is. Nem értem!
> movlw PORTD
Nemregiben epp errol ertekeztem itt, Mi a jelentese az L es a W betunek ebben az utasitasban? Ja, meg par dolog: 1. Biztosan ki kell olvasnod a portot? Merthogy az amit bele irsz az ugye a W-ben van mert kozvetlen elotte irtad azt ki a portra 2. Figyelj ra, hogy port iras utan kozvetlenul ne akard kiolvasni a tartalmat - ugye az output portbitek allasa meg nem garantalt akkor. Tegyel koze egy NOP-ot...
Reset után a portok általában bemenetek, ha kimenetként szeretnéd használni, az irányregiszterét is módosítani kell (pl. TRISD-t, teleírni 0-val).
A "movlw PORTD" nem jó, mert a port címét fogja beolvasni, nem az értékét. Helyette "MOVF PORTD, 0" a szükséges. Idézet: „Helyette "MOVF PORTD, 0" a szükséges.” Na ettől kapok kiütést!  Ha már egyszer valamit javasolunk, akkor az legyen korrekt!  MOVF PORTD,W ;és nem 0! Még ha ugyanazt fordítja a fordató, akkor se! Ennyi erővel számokkal is lehetne programozni, mint régen az Enterprisével tettem...
Nem látszik, hogy a műveletek előtt milyen bankban voltál! Lehet, hogy állítottál valami TRIST és elfelejtetted viszaállítani a bankot. A többiek intelmére is figyelj, nem mindegy, hogy idd ki, vagy vidd ki!
Anélkül, hogy kötekedni akarnék (sőt, el is ismerem, hogy jobban otthon vagy PIC-ben, mint én), csak megjegyzem: ha ettől kiütést kapsz, akkor kaphatsz az adatlaptól is. Abban ugyanis így szokott lenni; a W már csak az MPLAB "hozománya", mert az .inc file-ban deklarálva van, hasonlóan az 1 helyetti F-hez.
Lehet, hogy szintaktikailag nem megfelelő volt, amit írtam, de funkcionálisan korrektnek érzem. Vitát azért ne nyissunk róla, ki hogyan szokta meg, szerintem.
Funkcionálisan korrekt, de jobb a szimbólumokat használni hibakeresés miatt. Egy 0 vagy 1 nem sokat mond önmagában. De ha ott az áll, hogy W, akkor az már arra utal, hogy valamit a W regiszterrel csinál. És a kezdőknek inkább olyat mutassunk, ami a hasznukra is válik.
Persze hogy ezt miért kell rendszeresen elmondani itt a témában, azt sem értem... Idézet: „MOVF PORTD,W ;és nem 0! Még ha ugyanazt fordítja a fordató, akkor se! Ennyi erővel számokkal is lehetne programozni, mint régen az Enterprisével tettem...” Teljes mertekben egyet ertek! A fenti kod azonos ezzel:
Kerdes persze, hogy melyiket ertjuk meg konyebben?
A többiek már leírták a véleményem.
Részemről csak annyit, hogy ennek semmi köze nincs ahhoz, hogy mennyire értünk a PIC-ekhez. Ha lehet valamit jól csinálni, akkor csináljuk úgy. Eddig se volt szó nélkül hagyva, ha valaki ilyen kódformában szúrta be a problémáját, és ezután se lesz. Te úgy használod ahogy akarod, de ne taníts erre másokat, ha ezt lehet kérni.
Én is leírtam a véleményemet. A Tiédet, Tiéteket megértem, tudomásul veszem, és nem próbálom cáfolni. Ha a népnek W-t kell írnia, írjon azt, én azt is szó nélkül el tudom olvasni. Tanítani meg eddig sem akartam, de ígérem, hogy ezután jobban odafigyelek, ne is próbáljam meg.
Na de off-ból elég, és ez nekem is szól. Idézet: „Tanítani meg eddig sem akartam” Ha válaszolsz egy kérdésre, azzal tanítasz, utat mutatsz. De igazad van, ez már off, és így én is befejezem... Idézet: „Nem látszik, hogy a műveletek előtt milyen bankban voltál!” Teljesen mindegy, hogy a CIB-nél volt előtte, vagy a Raiffeisen-nél, ez ugyanis nincs hatással a movlw PORTD eredményére... Már ha ez eredménynek nevezhető! 
Hali!
Nincs valakinek egy one wire kommunikációs rutinja a ds1820-as hőmérőhöz c-ben? Potyónak találtam valami hasonlót ami a b0-t használta (én a b2-őt) de nem megy és nem is értem mitől kéne menni, mert az írás és olvasás között nem váltja a port irányát így nem is értem hogy tudna enélkül írni is meg olvasni is róla, szóval az teljesen rossz (nem is megy), a read folyamatos 0-át olvas (ha ugyan olvas egyáltalán, lásd az irányváltást)
Talán asm-ben van, nemrég raktam össze egy kis szösszenetet 628-cal, ami soros portról működik és egy terminállal lehet vele kommunikálni. A progi a terminálon egy egyszerű menüs felületet ad, és az a funkciója, hogy DS1820 és DS1821 egyvezetékesekkel kommunikálni tudjon. A 1821-nek a riasztási szintjeit és módjait lehet pl. beállítani vele, a 1820-nak meg az azonosítóit lekérdezni.
Belinkelnéd, hogy hol láttál tőlem olyat, ami a B2-t használta? Ami az oldalamon asm példa van, az az RA4 lábat használja, ami nyitott kollektoros (a legtöbb chipnél), így nincs irányváltás. Az kipróbálás után került fel az oldalamra. De van ott C kód is felrakva, ami nem tőlem származik. De ötletnek jó, aztán meg az adatlapok alapján már meg lehet csinálni.
Itt a cucc a progival, nem egy nagy szám, de hátha érdekel mást is. A programban sincs túlspilázva a kommunikáció, biztos lehetne még szépíteni rajta, de a működőképesség és a gyors elkészülés volt az elsődleges szempont.
Igazad van a nyitott kollektorral, bár ha Én írtam volna, akkor biztos teszek bele irányváltást, mert úgy hordozhatóbb lenne.
Közben hajnali 3-ra jó sok böngészés után már ott tartottam hogy megírom magamnak a rutinokat mikor is szemembe ötlött, hogy a ccs examplek között van egy 1920-as hoz megírt példa változtatható lábbal, a lényege ez: while (TRUE) { if(touch_present()) { touch_write_byte(0xCC); touch_write_byte (0x44); output_high(TOUCH_PIN); delay_ms(2000); touch_present(); touch_write_byte(0xCC); touch_write_byte (0xBE); buffer[0] = touch_read_byte(); buffer[1] = touch_read_byte(); printf ("\r\nTemperature: %c%3.1f C", (buffer[1])?'-':' ', (float)buffer[0]/2); delay_ms (1000); } Ahogy elnézem a vezérlő kódok kompatibilisek a 1820-assal, gyorsan be is raktam, viszont permanensen 0.25-öt ír ki az lcd-re ami még akkor is rossz ha buffer-ből rosszul alakítja ki a hőfokot, mert változnia kéne akkor ha lehelgetem közben, vagy megfogom. A touch.c is ccs része a drivers-ben van, ott már általános dallas-t ír csak, az időzítésekben van némi eltérés meg abban, hogy az eredeti kódban 20MHz-s quartz van, az enyémben meg csak 4MHz-s. Most ott tartok, hogy lehet, hogy a szenzor megpusztult, bár a touch_present-re végül is válaszol a szenzor meg ad is vissza valami értéket. Szerencsére a kazánkeringetőn is ilyen van, ha nem jutok el ma a chipcad-be, akkor este 6 forrasztással kipróbálom a másik szenzort, mert az tuti jó. (3 le 3 fel) A hivatkozott file-okat mellékelem hátha valakinek még jól jön.
A DS1820 adatlapja szerint, ha parazita módban használod, a "convert T (0x44)" parancs kiadása után "the master must enable a strong pullup on the 1-Wire bus during temperature
conversions", vagyis a hőmérés idejére erős felhúzás kell neki (tkp. tápfeszültség, hogy működni tudjon). Azaz ha egy OC kimeneten van a DS1820, és csak egy 4k7-tel van felhúzva, az neki nem elég. A C kódban is ott az output_high a "convert T" kiküldése után. Nálad hogy van a hardver zen része összerakva?
Ide is beteszem, tegnap írtam az [ OFF ] topicba, de eddig senki nem jelentkezett. A gép már átvehető az üzletben, ha nem kell senkinek, visszamondom a rendelést.
Bővebben: Link
Egy 4k7-el van a tápon a 2-es láb, a GND a GND-n a vsd meg az 5V-on. A kazánhőmérőn is így van, onnan szedtem a bekötést.
Akkor ezek szerint nem parazita módban van. Viszont én meg azt nem értem, hogy hogyan írhat ki egy egész érték kettővel történő osztása után 0.25-öt. Lehet, mégis valami típuskeveredés van ott?
Elképzelhető, de hajnali fél négykor már beszédültem az ágyba főleg hogy hatkor kelés (lett volna, de 7-ig durmoltam)
Majd megnézem debuggal mi van a buffer-ben, de veszek egy szenzort, mert van mégy egy hely ahova kell majd, és akkor többet tudok majd mondani.
Üdv a PIC-es szakértőknek!
A segítségeteket szeretném kérni: MPLAB IDE 8.02-ben beírtam egy programba pár BCF/BSF utasítást (saját változóra vonatkoztatva), és mikor a kilencedik BCF-et is beírtam, egyszer csak a fordító ezt adta ki: Error[126] D:\...XYZ.ASM 1920 : Argument out of range (FF7E not between FF80 and 007F) Programozni nem ma kezdtem, de ilyen hibajelzést azzal az előzménnyel, hogy csak új utasításokat írok...még nem kaptam... Mi lehet ez? (PIC18F1320 I/P)
Valszeg van egy relatív ugrás a programban (ami csak -128 és 127 közötti offsettel képes módosítani a PC-t), és a 9. beszúrt utasítással már túl messzire került az a címke, ahová ugrania kellene. A hibaüzenetnél legközelebb azt is nézd meg, hogy a forrás melyik sorára vonatkozik, mert biztos nem a bcf/bsf utasításokra ír ki ilyet!
Na a vadi új ds1820-al is ugyan azt csinálja, az érdekes az, hogy először a buffer feltöltődik mindenféle értékkel és a második meghívástól kezdve jön csak pár kósza byte (0c, meg 02, meg az utolsó az valami 0x84) amiből persze egyik sem lehet hőfok.
Meg kell néznem az időzítéseket, szóval nem a szenzor rossz (annak jobban örültem volna, mert most 470Ft volt a ds1820-as az Elektro Konthában, annyit megért volna bőven, hogy kidobom a rosszat beteszem az újat és minden megy flottul. Esetleg ha van más ötlet akkor szívesen várom, a kódokat mellékeltem már, elég rövid, ha valaki veszi a fáradságot és belenéz azt megköszönöm Idézet: „ha valaki veszi a fáradságot és belenéz azt megköszönöm” Hiába nézem, attól nem leszünk okosabbak. De ha CCS és DS1820, akkor megnézted már pl. ezt a mintaprogramot?
Sziasztok!
Tudna valaki segíteni abban, hogy C-ben hogy kell megvalósítani futófényt? Amit majd PIC-re kellene tölteni.... Előre is köszi Csaba
Köszönöm, ez lesz az...
 na akkor ez szép menet lesz átírni  |
Bejelentkezés
Hirdetés |
