Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Első körben használd a PICKit2 saját programját. Ha az sem ismeri fel a PIC-et, akkor lehet gyanítani, hogy az égető tönkrement, vagy a firmware sérült meg benne, de az MPLAB hibaüzenetéből nem ez derül ki, mert az ezt írja: PICKit 2 Ready !
A PICKit2 programjával az első dolgod egy törlés legyen, utána jöhet a próba. A trudnai által felsorolt dolgokat mind(100n kondi a táplábra, ha lehet SMD-t közvetlenül a lábra, low voltage programming tiltása, stb. ) meg kell tenni!
Piros gombos és a saját progija nincs nálam suliból kértem kölcsön a vizsgamunkám programozásához...de leszedem a programot és kipróbálom vele! Amiket tanácsoltatok (kondi, vezetékezés, ellenállások,config bitek) mind beraktam az áramkörbe de úgysem akar menni írok ahogy feltettem a progit!
Köszi!
Kipróbáltam a PICKIT saját programjával amit a microchip oldaláról szedtem le...felismeri a PIC-et de törölni nem tudja a program memóriát...és amikor próbáltam a hex fájlt feltölteni és a 0x18-as címre hivatkozva hibát jelent...meg az ellenőrzésnél is...
 szóval esélyes hogy a PICKIT adta meg magát...vagy lehet még más is?
Töltsd bele fw-t első körben. Utána a pk2 saját programjában van olyan menüpont hogy fast programming. Az elől vedd ki a pipát. Próbáld meg másfajta pic el is. Ha azzal sem megy akkor a pk2 a hibás. Esetleg még újrakalibrálhatnád.(nem tudom hogy van a 18F-sorozatnál a vpp vdd viszony de szerintem a vpp nek nagyobbnak kellene lennie mint a vdd te meg fordítva írtad)
Helló!
A TV-mhez írtam egy Elalvás kapcsoló programot, mivel olyan régi a TV-m hogy nincs benn  A program a szimulátorban tökéletesen működik, gyakorlatban viszont nem igazán stabil. A lényege annyi, hogy van két változó AKT (mint az aktuális állapot) és a VALT ( ami változtatja az AKT-ot). A PORTB 1-6os lábain van 6 LED, amiből alapból világít 3. Ezek szimbolizálják a hátralévő időt. Ha egy bizonyos idő eltelik egy LED kialszik. Ha mind elfogyott, akkor a PORTA 0. bitjét egyre állítja, ezzel lehet kapcsolgatni pl egy relét. Az INT lábbal pedig tudom növelni az időt. Az idő növeléséhez összeraktam egy monostabil áramkört 555-el hogy nehogy az legyen, hogy amikor kapcsolok többször érintkezik. Nos, a probléma az, hogy mikor növelem az idő néha nem megy szépen végig, hanem vmikor kettőt ugrik, vagy végig sem megy hanem újrakezdi, de úgy , hogy 3 LED világít, mint bekapcsoláskor. Ebben szeretnék segítséget kérni. Remélem vkinek van rá egy kis ideje , hogy átfussa amit csináltam
Kérdezném nincs e valakinek olyan terminal programja amin az egyéb vezérlő karakterek is megjeleníthetők? ( LF /CR / stb) vagy ez csak beállítás kérdése pl a hyperterminalon?
Bár ez nem PIC kérdés, de csatoltam a legjobb terminal programot. Hexa beállításban minden bájt látszik.
Ha érdekel egy frisebb verzió itt a honlapja: Bővebben: Link
Szép napot!
Meg építettem Watt-nak a WPB_F18_LTP-os programozóját, a leírásban megtaláltam hogy kell le ellenőrizni a működését(Vpp kipipál MCLR kipipál-megmérni a kimeneti feszültségeket stb) minden megfelelően működik de valami mégsem, ha programozni akarok akkor ki írja hogy( Verify failed at address 0000h ) Topi is azt írta ha kiolvasáskor csak 3FFF jelenik meg akkor valószínűleg jó, nekem ez jelenik meg. Ezt okozhatja valimilyen időzítési gond, vagy a PIC lehet rosz? Köszi
Köszönöm, bocs az OFF ért. Mentségemre szóljon hogy PIC es projectnél akadtam el ezzel, ezért bátorkodtam itt feltenni...
Ránéztem a progira, hirtelen több gondom is van vele:
- az interruptban nem állítgatjuk a GIE-t, azt megteszi a PIC - az interruptban nem csinálsz semmilyen státuszmentést, legalább a W-t és a STATUS-t el kellene menteni és visszaállítani visszatérés előtt - utána kell nézni, hogy a különböző interrupt flag-eket kell-e kézzel törölni (pl. TMR1IF) Ezek mind le vannak írva az adatlapban, tessék azt olvasgatni szorgalmasan!
Köszi
Megszakításban tudom, hogy nem kell a GIE-t állítani, csak végső elkeseredésemben tettem, hátha szerencsével járok A mentések pedig akkor megcsinálom, köszi Egyébként az ilyesmi problémák okozhatják azt, hogy szimulátorban megy, gyakorlatban meg néha megkeveredik?
Igen, főleg a regisztermentések és -visszatöltések elmaradása okozhat gubancot.
Szia Watt !
Az általad írt "SorosPortPelda_16f627" programoddal kapcsolatban merült fel kérdésem. Nevezetesen az "RX_OK" rutinban figyeled az RCIF flag et, ha bebillen akkor lép ki a rutinból a program. Viszont nem látom hogy hol állítod vissza az RCIF et alapállapotba. No ez az amit nem értek...Mert megszakításban a regisztermentések után elvileg a megszakítást okozó flag törlése szokott következni. Ebben a programban nincs megszakítás az esetleg bekövetkező INT egy szimpla retfie al van lekezelve. Akkor hol van visszabillentve az RCIF? Nem megy az istennek sem a soros vétel valamiért az egyik projectemben és ennek kapcsán elővettem ezt a példaprogramot. (A te példa programod természetesen működik, csak nem értem hogyan...) köszi előre is
Az rcif magától vissza áll ha kiolvasod a bufferből az érkezett byte-ot és törlöd a buffert.
Braf jól mondja, ez visszaáll magától a kiolvasáskor. Adatlapban nézd meg!
Csak ez volt, ami miatt nem érted hogyan működik?
Köszönöm a válaszokat!
Igen, a Te programodat illetően. Azt viszont nem értem hogy az én programom miért nem megy. A Te programod rutinjait használom, megszakítás nélkül, az adás megy a vétel nem....A különbség annyi hogy én az RCREG ből a W be, onnét pedig egy általam létrehozott regiszterbe rakom a soroson érkező adatot (egyelőre egy bájtot). Ezek után pedig kivonással összehasonlítanám ezt a tároló regisztert egy másik regiszter tartalmával. Szimulátorban működik de, gyak.ban nem. Valamit elszúrok csak tudnám mit...? Braf válaszában azt irja "az rcif visszaáll ha kiolvasod a tartalmát és törlöd a buffert..." A buffer törlését sem látom a példaprogramban.
A kiolvasáskor törlődik a buffer is(bár ebben nem vagyok biztos), ezt így értette.
Csatold a programot, hátha meglátjuk mi a baj.
Köszönöm előre is, a segítségeteket. Már tényleg mindent kipróbáltam és nem működik.
Köszönöm mindenkinek a segítséget a váltó kijelzővel kapcsolatban. az áramkör Működése 95%-osra javult. A további áramköri javítások folyamatban. Rengeteget számított a 100nF kondi közvetlen a Pic lábaira forrasztva.
Azt nézted már, hogy a W-be mit tesz ilyenkor a program? Eleve minek két 0? A ' ' jelek között lévő karakter ASCII kódját teszi bele a fordító a regiszterbe, ha jól sejtem.
Próbáld meg inkább ezt a formát használni!
Ha karaktert akarsz hasonlítani, akkor meg ezt:
Szia menyus,
Nezegettem a programot, volna par megjegyzesem, ha nem baj. Ezek inkabb programozas stilusbeli megjegyzesek, de segitenek a program gyors attekinteseben es a hibakeresesben. - A BANK0 / BANK1 makrok helyett inkabb a BANKSEL beepitett makrot kellene hasznalni - ettol azt varjuk, hogy mindegy milyen PIC-en megy majd a program jol fogja csinalni a bankvaltast. - Bankot nem utolag kell beallitani, hanem elore. Tehat mikor meghivod a PIC_COMM_SET rutinod akkor ne irdd oda, hogy BANK0-al ter vissza, mert az teljesen mindegy. Igazandibol ketfajta metodus letezik: Az egyik szerint a fuggvenyekben nem szabad bizni es a kontextus mindig elmaszik (W, BANKSEL vagy mas dolgok is akar). Masik szerint a fuggveny mindig csinal kontextus mentest, de ez feleslegesnek tunhet, ezert inkabb az elsot szokas hasznalni. - A szamformatumoknal illene egy fajtat hasznalni. Pl. ORG 0x000 akkor utana ne legyen MOVLW H'00D' ... legyen inkabb ott is MOVLW 0x0D ... de amugy sem kell harom digit mert ezek a dolgok 8 bitesek nem 12... Az ORG-nal meg elegendo a 3 digit. Egyebkent az MPASM-ben az alapertelmezett radix a 16, igy mindenfele hokuszpokusz nelkul meg lehetne adni a hexadecimalis szamokat. Az egyetlen ok ami miatt nem teszik, mert igy a forras kod nem fugg az MPLAB beallitasaitol (ha pl en atallitanam a radixot akkor a program mar maskepp mukodne). Persze meg lehetne adni a forrasban is mit hasznalsz, ez izles kerdese, csak legyen egyertelmu a dolog. - A 0x... megadasi modnal 'nem illik' nagy X-et hasznalni - ettol nehezebben latszik, hogy milyen is a szam - a szem konnyen atsiklik rajta es azt hiheted decimalis szamot szerettel volna megadni. - A #define -okat mindig sor elejen szokas kezdeni, es kis betus. A #define egy C preprocesszor direktiva amit az MPASM 'atorokolt', de emiatt erdemes betartani a C szintaxisnak megfelelo leirast. - A varakozo rutinuknal nincs feltuntetve mennyi a varakozasi ido - igy meg sem lehet mondani, hogy az jo-e. DEL33 nekem nem mond semmit sem. Jobb lenne delay_8us vagy valami hasonlo es akkor egyertelmu a dolog. Amugy nem szeretem a csupa nagybetus cimkeket, mert a csupa nagybetuket konvencionalisan a makro nevekhez szokas hasznalni. Sok C programozonak fajdalmas pontja ez - Javasolnam, hogy a string kuldest ne karakterenkent oldd meg, hanem csinalj string kuldo rutint, es tedd le a kuldendo stringeket DT-vel a program memoriaba. Kesobb joval egyszerubb lesz a programot modositani es valoszinuleg rovidebb is lenne a kod. Most hirtelen ennyi - hogy miert nem mukodik most nincs idom atbogaraszni, majd talan este ha addig nem lenne meg a valaszod - szerencses lenne ha esetleg ezeket a modositasokat meg tudnad csinalni
Megjegyzem, hogy a programot én írtam, menyus próbálja kiegészítgetni(Megszakítás utáni részek, és a felemlített módosítások).
Ami engem illet a tanácsaidból, azok a Bank makrók. Én szeretem magam kiválasztani a Bankot és látni mit választottam. Megyusnak én is a BANKSELT javasolnám!  Az, hogy milyen bankkal tér vissza egy rutin, azért jó tudni, mert nem kell két utasítást elpocsékolni, ha nincs rá szükség a következő lépésekben. Én így spórolok. A kis x nagy X kérdésével kapcsolatban pedig úgy szoktam meg, hogy az ASM programot csupa nagy betűvel írom, így az X és a #DEFINE is nagy lesz. Engem egyébként nem nagyon zavar...
Szia Menyus!
Javaslom én is Watt által említett MOVLW 0x0D formát modem vezérléshez, kicsit körülményesebb így AT parancsokat küldeni, mint ha csak simán ASCII kódot írnál, de így biztos (nekem mind2vel ment..). Ha majd megírod Trudnai által javasolt string küldő algoritmust, vedd majd figyelembe, hogy nem írják, de mikor várod a válaszokat a modemtől azok < CR > < LF >-el kezdődnek és végződnek. Milyen modemet használsz?
Sziasztok!
Ahogy watt is írta, ez a program tulajdonképpen az Ő példaprogramja én csak belekontárkodtam. Ez az általam módosított forrás csak egy piszkozatféle amin próbálgatom a soros vételt, mert az általam írt programban sem működik. Ezért ezzel az egyszerűsített programmal gyakorolok. Ezért ez a sok összevisszaság amiket említettél, persze nem mondom hogy mindent úgy szoktam csinálni egyébként ahogyan leírtad.
Szia Watt!
A csatolt terminál programoddal nem tudtam a COM16-18-os portjaimat beállítani?(usb-soros kábelt használok) Lehet vele COM10-nél nagyobb portot beállítani? Köszi
A W be 0x0D kerül, tehát elvben helyes érték. Azért írtam ebben a formában mert az ASCII "CR" karakterének ez a hex értéke és én ASCII karaktert várok a soroson. (GSM terminal). Egyébként ha nem a soroson érkező (vagy nem...?) karaktert hasonlítom hanem én töltöm fel a k1 regisztert 0x0D vel, akkor működik a program. Olyan mintha vagy nem jönne adat a soros porton, vagy nem az a karakter amit várok. A bray terminal programmal megnéztem mit küld a modul első karakterként, minden választ CR ; LF karakterekkel kezd, tehát az első karakter a CR. De akkor miért nem kezeli le a PIC? A baud rate biztosan jó mert az adás megy... A PIC és a GSM modul RX/TX lábai közé nem kell elvileg semmi? Ellenállás vagy más....? Közös tápról járnak.
Ha majd túl leszek annak a megfejtésén hogy miért nem megy ez soros vétel, a string küldő algoritmus érdekelne...Hogyan működik ez a dolog?
Ha lehet is nem tudom hogyan. Próbáld meg a helpet elolvasni, hátha van benne erről valami. Vagy old meg, hogy ne a 16-18-as portszámra kerüljön a kábeled.
|
Bejelentkezés
Hirdetés |
