Fórum témák
» Több friss téma |
Sziasztok!
Kis segítséget kérnék PIC16f886 4x20 LCD projektben HITECH C fordító. Nem sikerül inicializálnom, gyanítom azért, mert ugyanazon a porton van a data és az en, rs is. Szóval lábkiosztás: LCD4-RB3 LCD5-RB2 LCD6-RB1 LCD7-RB0 LCD_RS-RB7 LCD_EN-RB6 LCD_BL-RB5 Ezek miatt módosítottam a kódomat a következőképpen:
De természetesen nem megy. Valaki tudna segíteni, hol rontottam el? Amúgy a programom ettől eltekintve fut, mert van még rá írva egy MODBUS RTU is és az ragyogóan válaszolgat, csak az LCD nem megy.
Sajna már így lett elkészítve a nyák én se örülök neki, mert természetesen könnyebb lenne bitforgatások nélkül kiírni egy az egybe, de hát ez van.
Szerintem nem jól inicializálod. Valahogy így szoktam:
.. és még az lcd_write -t is átírnám:
lcd_write(unsigned char w) { unsigned char x=0,y=0; if (w & 0x80) x |= 1; if (w & 0x40) x |= 2; if (w & 0x20) x |= 4; if (w & 0x10) x |= 8; if (w & 0x08) y |= 1; if (w & 0x04) y |= 2; if (w & 0x02) y |= 4; if (w & 0x01) y |= 8; vWait_us(40); lcd_data = (lcd_data & 0xF0) | (x); //felső 4 bit lcd_enable(); lcd_data = (lcd_data & 0xF0) | (y); //alsó 4 bit lcd_enable(); }
Igen, de nekem Adat_Ki_LCD nem lehet annyi, amit írtál, mert biteket kell forgatni.
Hogy az adat ki-ben mi van(hívhatjuk lcd_write-nak is), azt neked kell megoldanod a bitkiosztásnak megfelelően. A lényeg, az időzítések és az ismétlések az elején, hogy az inicializálás biztos legyen (lásd LCD driver adatlapja).
A hozzászólás módosítva: Feb 5, 2014
A bitforgatás és inicializálásom biztos hogy jó ugyanis van egy pár ilyen panelem, ahol az lcd lábkiosztás ez volt (adatlábak) csak olyan még nem volt hogy az rs és en is azon a porton lett volna. Vagyis valószínű hogy adatírás közben megváltozik az rs, en láb állapota. Ezt kellene orvosolnom valahogy. Ezt onnan gondolom, hogy az lcd_init legvégén bekapcsolom a backlightot, de a legelső lcd parancs kiadásnál ki is kapcsol. Valahogy azt kellene megoldani hogy ne változzanak meg a bitek.
A hozzászólás módosítva: Feb 5, 2014
Nem vitatom, ez lehet a fő baj(RMW gond lehet), de ettől még nem kellően gondos az inicializálás, ha a gyári ajánlásokat nézem. Próbáld másképpen maszkolni. Hp41C is adott egy más megoldást erre. Szimulációban jók a műveletek?
Hi watt...sajnos rossz az MPLAB szimulátor.
10 éve gyúrom a PIC-eket. Nem egyszer használtam a timer-eket. Tudom hogyan működnek. Most tértem át K procira, ugyanis árban nagyon nem mindegy és tudásban sem. Ennél a ha timer1 rd16-ot beállítom egyszerűen leáll a timer az MPLAB SIM-ben. Próbáld ki !!!! Mindez MPLABX-ben csont nélkül működik. Azonkívül a Hi-Tec PICC18 9.65-el nem lehet a config bit-eket állítani kódból, csak az mplab-al. Lecseréltem 9.80-ra azzal működik. Az MPLABX-ben viszont nem tudom a project-hez állítani config-et csak, ha kódból. Viszont a kódot legalább legenerálja...csak ellenőrizni kell, mert olykor téved. Hp41C-nek igaza van! Rendkívül gusztustalannak tartom amit a Microchip csinál. 2 db ICD2 van a fiókban...rosszak...+ egy harmadik amit Ők küldtek...az sosem volt jó nálam. Amikor megvettem (irreálisan drágán) örök garanciát ígértek, most meg az MPLABX már nem is támogatja....vegyél újra ICD3-at...jó pénzért. ARM Discovery fejlesztőpanel 2500 Ft és van rajta egy programozó debugger ami önállóan is használható....az ARM procik egyébként olcsóbbak mint a PIC-ek.
Az ICD2->ICD3 csere jelképes összegért ment, ráadásul egy marék rizsért adtak hozzá PICKIT3-at is. Sok minden miatt lehet szidni őket, de ez a váltás korrekt volt.
Megnézem amit mondasz!...
Sajnos az ARM felvetésed igaz és többi is fájdalmas, de igaz. A fejlesztő kártyák ára is irreális. Nézz meg egy Arduino mega klónt! háromezeröccá... A hozzászólás módosítva: Feb 6, 2014
Pontosan ezek a define-ok oldanák meg a RMW-t:
Csak valamit mégsem jól csinálok. A hozzászólás módosítva: Feb 6, 2014
"Tanulság: Nem érdemes az előre definiált makrókat és könyvtári függvényeket használni..."
Ezt megerősítem : Most a Hi-Tech 9.80-ast kezdtem használni...mit ad isten az EEPROM makrók és függvények nem mennek. Nem nagy gond, mert a plib-ben benne vannak korrektül eltekintve az olyan dolgoktól, hogy 256 byte-os EEPROM esetén is a címet 16 biten adja át. Van memória bőven, majd veszünk nagyobb pic-et. Visszatérve a fenti timer RD16 bit-re. A fordító mindenképpen byte-san olvas és ír. Futó timer esetén, amikor mehet az akár Tosc-ról, a PC meg Tosc/4...több mint gáz. A plib sem foglakozik ilyesmivel... jó az úgy ahogy van....használd és szívj, mert néha hibázik egy időzítő. Legutoljára a Nuvoton kínai cég szoftverében találtam ilyen borzasztóan bosszantó hibákat... Egy barátom reklamált a kínai beszállítónál. Válasz : Maga nem tudta, hogy kínai árut vesz? Miért nem vett németet, ha minőséget akar ! De ez amerikai...ők fújják a passzát szelet! Ez nem politikai, hanem szakmai vélemény !
A proc órajelet nem írtad !
Az 50 Hz (20msec) általában elég alacsonynak számít ! Kérdés milyen felbontást akarsz ? Ha 1 ms körül elég ajánlom a következő módszert. Gondold át mennyit fog a program ISR-ben tölteni ! Állíts be valamelyik timert, hogy 1 ms-enként adjon egy interrupt-ot. Ebben az ISR rutinban, növelj egy számlálót. Figyeld a számlálót és ennek megfeleően kapcsold a pin-t. Ehhez hasonlóan :
Idézet: „De ez amerikai...ők fújják a passzát szelet!” Nekünk van egy folyamatban levő fejlesztésünk a Unicoi cégtől származó InstaVoip modullal. Hát az is egy szemétdomb, ami stack-eket adnak hozzá, ahhoz képest, hogy pénzt kérnek érte, ráadásul nemis keveset. Plusz a support is fizetős, szintén nem olcsó, viszont sajnos szükség is van rá, mert a dokumentációjuk sok helyen hibás, igencsak hiányos, alapvető dolgokra nincsen bennük példa, stb. Hozzávaló VisualDSP++ IDE néha gondol egyet, hibás kódot fordít, vagy épp kihagy kódrészletet, aztán meg pislogunk, hogy miért nem megy valami, amikor az előbb még ment. Elejében azt hittem, én csinálok valamit rosszul, de később rájöttem, hogy nem. Bezárás-megnyitás, debugger lehúzás-visszadugás, és ismét normális lesz egy darabig. Ehhez képest a Microchip dolgai még egész jól működnek.
Közben ránéztem a szervókra.
A timer ISR biztosan jó lesz ! Kell egy időzítés a be időre és a ki időre. Ezeket felváltva állítgasd ISR -ben.
Óriási BUG a 9.80 hi-tech (már Microchip-et ír ki ) plib softwer spi funkcióban !
MODE1 MODE2 esetén :
Akkor most az SW_SCK_PIN clear vagy set ? Náluk attól függ optamlizál-e a fordító ? Ez se semmi :
Egy kicsi glitch softveresen sosem árt ! Miért nem lepődök meg ? A hozzászólás módosítva: Feb 13, 2014
Egyre inkább úgy érzem, hogy nem rossz dolog, hogy nem használom a beépített függvényeket, makrókat. Elég a fordító hibáival szívni, nem hiányzik még ezekkel is...
Maximálisan egyetértek. Már az elején kiakadtam, milyen szerencsétleg függvényeket írnak perifériákhoz. Persze ehhez az kell, hogy assemblerben tanulja meg az ember a műfajt és utána váltson C-re...
Hogyan lehet c ben egy float változónak közvetlenül a szám 4 byte -os hexadecimális reprezentációját megadni? Milyen szintaktika kell hozzá?
Vagy csinálsz egy a float-ra mutató unsigned char pointert...
float x;
((unsigned char *)&x)[0]=0x12; ((unsigned char *)&x)[1]=0x34; ((unsigned char *)&x)[2]=0x56; ((unsigned char *)&x)[3]=0x78;
Sziasztok!
MPLAB 8.92 C30 Sosem voltam jó fejszámolásban, de ez mintha pont a kétszerese lenne mint kéne.. elég nehéz volt megtalálni hogy miért nem azt csinálja a függvényem amit szeretnék, de már teljesen elvesztetten a fonalat. Én csinálok rosszul valamit?
Ennyit találtam:
http://www.microchip.com/forums/m653902.aspx Kipróbáltam egy másik projectemben, ahol 24HJ van, ott rendben van. De a fenti 24EP512GU814 esetén mindig ez az eredmény... EErata-ban sem találok erről semmit.. Valaki kipróbálná ezzel a kontollerrel MPLAB X- ben?
Muszáj a volatile ?
double a float helyett ? Estleg variáld : (float) c = (float) a * (float) b; c = 1.0 * a * 1.0 * b; Még sok jó ötletem lenne.... Sajnos ( vagy inkább szerencsére pont ilyen szívások miatt ) megálltam a PIC18-nál. Most barátkozom az ARM procikkal. A 9.65 és 9.80 fordítóban a 18f45k80 ill. 18f46k80 procinál mostohagyerek az RB0 és RB1. Kifelejtették ! A világ csak az RB2-től kezdődik !!!
Sziasztok!
Én éppen most Hitech-c 9.83 PRO móddal szívok, mert egyszerűen nem értem miért, de nem fordít jól. Van egy függvényem, melynek visszatérési értéke float. Ha átírom int-re, akkor egyszerűen nem működik, de hibátlanul lefordul. Ha megnézem a fordítás után a memóriát, akkor azt veszem észre, hogy le sem foglalja. Mitől lehet? íme a függvény:
Már megnéztem ezt a változatot is:
Erre a fordítás után a bank2 üres, mindegy mekkora változót deklarálok. Most mi van?
Próbáld ki üres függvényként mi történik ha csak 1 db return van.
|
Bejelentkezés
Hirdetés |