Fórum témák
» Több friss téma |
A main függvényből ne lépj ki, hanem egy végtelen ciklust készíts az alábbi utasításokból:
Betettem egy végtelen whileba, de ígyse, nemértem. A PIC lábán 1,6V-ot mérek, de más kódrésszel rendesen 0-5V van más lábon. Nem tudom mit nem veszek észre...
UI: Azért a C2-t próbálom most váltogatni, mert az terheletlen, ki tudom deríteni rajta hogy elindul -e , ha elindulna akkor már tudnék továbbmenni, de így csak toporgok :/
Milyen tokozású a kontroller? DIP? Ha igen, lehetséges, hogy egyszer fordítva beült a foglalatba és a Vdd kilőtte a lábat. Más típussal de nekem sikerült már ilyet csinálnom.
DIP de most tettem be és nem került be fordítva, ez nem jöhet szóba. Egy saját tervezésű panelbe került, van cserekontroller, de ha a panellel lenne gond azt ki akarom deríteni, de tényleg az az érdekes, hogy más lábak meg "mocorognak" rendesen, de nem mind.
Keresgélés közben belefutottam árnyékregiszteres megoldásba (shadow register), ez mennyire jöhet szóba?
De tényleg a C2 lábon semmi sincs, szóval nem értem 
Tudtommal az árnyékregiszterekhez a felhasználó nem fér hozzá semmilyen formában.
Valami ideiglenes regiszter megoldást mondanak. Hogy a felhasználó egy másik regiszterbe dolgozik mint a láb saját regisztere, de mégis odakerül valahogy. Közös címre van állítva vagy valami hasonló, nem teljesen értettem.
Ha jól tudom (messze nem biztos), a kontroller árnyékregisztereket használ bizonyos beállításokhoz. A regisztert lemásolja magának az árnyékregiszterbe és innentől kezdve te hiába módosítod az általad hozzáférhető részen, hatása nem lesz semmire, mert az árnyékregiszterből dolgozik.
Amit te találtál, az valószínűleg programozástechnikai dolog. A hozzáférhető regiszter tartalmát gyakorlatilag lemásolod magadnak egy általad létrehozott változóba majd később összehasonlítod az eredeti regiszterrel, hogy változott-e. Remélhetőleg valamelyik feketeöves PIC programozó benéz ide és helyre rakja a dolgokat. 
Betettem közben a cserekontrollert és ugyanezt a jelenséget csinálja ugyanezzel a kóddal.
Azt sikerült, hogy MPLAB-os debuggolással rájöttem arra, hogy az A port szépen működik, de a C port nem akarja az igazat. Nem minden állapotot tesz ki, és van ahol ez a 1,5-1,7V van állandóan.
Üdv!
Ezeknél az új fajta 16-osoknál nem olyan egyszerű a dolog mint régen, egy csomó mindent be kell állítani, mert kismillió modult pakoltak bele. Ez egy 16F18324-re írt progi részlete:
Érdekesség, hogy a progi csak egy ledet villogtatott, a feladatot a hardverek összekapcsolásával oldottam meg IC-n belül. A hozzászólás módosítva: Okt 28, 2018
Komparátor van még rajta, azt is tiltsd le.
Próbáld másik biten, esetleg az összes bitre írva. A PORTA-n működik?
Letiltom azt is, de most összeraktam próbapanelen egy alap környezetet és ott teljesen másképpen viselkedik (elvárt módon) mint a panelen a helyén, szóval kezdem azt érezni, hogy vakvágány volt a kód átnézése, mert lehet a panelen lesz a hiba...
 A lábak kimenetein egy ilyen van. Ez leterhelheti annyira, hogy tiltson a kimenet?
Nem szólhat bele, hacsak nem nézted el az 1k ellenállás értékét és valami jóval kisebbet tettél bele.
Van debuggered? Ott mit látsz a port kimeneteken?
Ha zárlatos a tranzisztor, éppen lehetséges.
Épp most estem neki egy PICkit3-al, de elötte kivettem egy tévesen az RA3 hoz tervezett 5V - 12V szintillesztőt (legalábbis kiszedtem a tranzisztort), nem tudom mi köze volt ehhez (a tranzisztor nem volt zárlatos), de megoldódott a probléma.
Egy HV5122-vel kommunikálok, és már szépen beíródik az adat, semmi gond nincs. Viszont továbbra sem értemi miért zavarta be az egész kontrollert az RA3-on lévő tranzisztor bázisa. Az adatlap eleje General purpose I/O ként hivatkozik rá, szóval simán odaterveztem kimenetnek (régebbi adatlapon láttam, hogy akkor csak Inputot írtak, ebből gondoltam akkor ez I/O lesz), viszont nem , nem az, csak bemenet. Mindenesetre mindenkinek nagyon szépen köszönöm a segítséget!
A válasz a kérdésedre:
Idézet: „#pragma config LVP = ON // Low Voltage Programming Enable bit (Low Voltage programming enabled. MCLR/VPP pin function is MCLR. MCLRE configuration bit is ignored.)”
Erre egyáltalán nem figyeltem, köszönöm!
A válasz a kérdésére az amit már megtalált mivel kimenetként akarta használni.
A MCLR láb mindig csak bemenet lehet, legutóbbi tudásom szerint. Egy ideje PIC-ezik már, ezt már tudhatná, de hát mindenki lehet szétszórt. Idézet: „Viszont továbbra sem értemi miért zavarta be az egész kontrollert az RA3-on lévő tranzisztor bázisa.” Ha nem LVP-t használt volna, nem is lett volna baj. Maximum nem csinál semmit az RA3-on lévő tranyó. De így folyton reszetet szedhetett össze.
Milyen volt a RA3 -hoz kapcsolt 5 - 12V szintillesztőt?
Két eset lehetséges: - A RA3 a GND -re került - A MCLRE = OFF nem kapcsolja ki a reset funkciót, mert az LVP aktív (LVP = ON). Így alacsony szint a RA3 -on resetben tartja a kontroller. - A RA3 -ra Vpp szint kerül - A szintillesztő nem jól működik. Ekkor a kontroller programozási módba kerül.
Igen, erre a kérdésre valóban ez a válasz.
 Idézet: „Maximum nem csinál semmit az RA3-on lévő tranyó.” Ezzel kezdte, erre reagáltam.
GND-re került valószínűleg és resetben tartotta. Sok pic-et nem ismerek, csak párat használtam részletesebben. Képen mellékelem mi zavart meg, bár tényleg nyilvánvalónak kellett volna lennie, hogy csak bemenet, hirtelen nem pörgettem le a regiszterekig és már csak használat közben vettem észre.
Sziasztok!
Egy új kérdést intéznék hozzátok: XC8 fordító, használom az eeprom_read() makrót, viszont "Unable to resolve identifier eeprom_read" hibát dob a saját sorában, viszont szépen fordul. Olyan megoldást találtam a neten, hogy egy saját header fájlban megadom a makrók szignatúráját:
Ez megoldja, ellenben ha ez nincs ott akkor is fordul, szóval valahol megtalálja. Ez az IDE hibája? Köszönöm!
Sziasztok,
PIC18F2550-el és egy SIM300-as modullal szeretnék SMS-t küldeni, viszont problémába ütköztem. Az üzenetküldés gond nélkül megy, viszont írtam egy ilyen függvényt:
amit így hívok meg: sendmsg("proba uzenet"); A gond az, hogy ilyenkor mindig 7@¥ és d?o@¥ szövegeket kapok SMS-ben. Ha a puts(kuldeni2);-t kicserélem puts("teszt");-re, akkor jól megkapom a teszt szót. Szerintem a gond a kuldeni2 változó használatában van, debugger jelen esetben luxus, PIC C compiller-rel fordítok és egy MiniPro-val írom fel. Szerintetek mivel lehet a gond? A választ előre is köszönöm!
Első blikkre azt mondanám, hogy a char, mint típus nem jó neked. Hiszen a char az nem más, mint egy 8 bites szám. Mi történik, ha kicseréled mondjuk char[], vagy string típusra?
Melyik fordítót használod?
A pic -es világban kétféle karaktertömböt lehet használni a tárolása szerint: - RAM -ban tárolt karaktertömb: char[] szoveg1 - A program memóriában karaktertömb: const char[] szoveg2 Mindenesetre a paraméter átadáskor a karaktertömbre mutató pointer -t kellene átadni:
és
Továbbá ellenőrizi kell, hogy a puts() melyik memóriából szeretné elővenni az elküldendő karakter sorozatot. A hozzászólás módosítva: Nov 3, 2018
Köszönöm a válaszokat!
Végül ez lett a jó megoldás: a program elejére ezt a sort be kell szúrni ezt a sort: char StrBuffer[20]; // allocate space for char array Majd amikor használni szeretném, ezt a két sort kell lefuttassam: strcpy(StrBuffer,"Hello World"); // copy a string into the array sendmsg(StrBuffer); // pass the pointer to the array to the function Meg ez a függvény/funkció definiciója (szép szavak...): void sendmsg(char *String) További szép bug mentes napot mindenkinek!
Üdv!
Egy kommunikációval kapcsolatos kérdés. A Saleae szoftvere nem tudja a 1-wire-t analizálni? Bináris formátumban lenne jó exportálni, de a hex is megfelel, de nekem csak a reseteket és azoknak idő paramétereit mutatja. Vagy esetleg valamelyik más analizálóval meg lehet oldani? (pl SPI ?) A jel 1:3 arányú NRZ. 1 bit magas 3 alacsony, vagy fordítva.
Szia!
Tudtommal tudja !Idézet: De ez nem 1-wire ( Dallas szabvány!)! „A jel 1:3 arányú NRZ. 1 bit magas 3 alacsony, vagy fordítva.” A hozzászólás módosítva: Nov 4, 2018
|
Bejelentkezés
Hirdetés |
