Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Hibás a kapcsolásod. De mi lenne, ha nem offolnál tovább?
Idézet: „Hogy még a LED-eket is párba kell válogatni...” Ugye nem kotottel ket LED-et parhuzamosan 'kozos' ellenallassal?  Amugy igaza van watt mesternek, kellene kapcsolasi rajz, de nem ebben a forumban, hanem pl a PIC kezdokben...
Az igazság kedvéért megjegyzem, hogy egy multiplexelt kapcsolásnál minden sort nem szoktunk egy időben bekapcsolni és csodálkozni rajta, hogy nem ég minden LED!
Ezért is komolytalan ez az egész itt...
Idézet: Pedig nem oszloponként, hanem ledenként kellett volna! Így egy oszlop felkapcsolásakor 4 db LED párhuzamosan kapcsolódik. De ez az Elektronika kezdő-ben is gyenge kérdés... „Az oszlopok bemenetére 1-1 db 180 Ωos ellenállás van kapcsolva” Mellesleg az is nonszensz, hogy amikor minden bitet '1'-be kapcsolsz, akkor a sorokat ugyan tranzisztorral húzod le, az oszlopoknál viszont egy kimenetre 4 ledet is rákapcsolsz párhuzamosan. Szerinted ott nem ugyanaz az áram folyik ki, amit az alsó oldalon a tranzisztorok elnyelnek?
Tipp 1: Kicsit olvass utána egy témának mielőtt nekiugrasz. A LED nél nem a feszültséget változtatjuk, hanem a kitöltési tényezőt, ezzel az áram középértékét.
Tipp 2: Még a tapasztaltabbak se esnek neki semminek "mint tót az anyjának" rajzolás nélkül. Tipp 3: Ha viszont ennek ellenére segítséget vársz, nem várhatod el hogy szöveges formátumból kihámozzuk, azt, hogy mit kötöttél rossz helyre.
Első pillanatban az jutott eszembe, hogy itt mindenki ledorongolt. Aztán végiggondoltam, és rájöttem, hogy most itt ebből a pár hozzászólásból nagyon sokat tanultam.
Bocsássatok meg az offolásért, ígérem ez az utolsó. A magyarázat az, hogy igazság szerint én a PIC programozását tanulom, nem az építést. Ám az általam írt programok kipróbálásához "hevenyésztem" össze egy kis panelt, ami többféle célú algoritmus kipróbálását teszi lehetővé. Természetesen ebben a mátrixban sosem fog egyszerre világítani minden, csak az építés után úgy gondoltam, a leggyorsabb, és legegyszerűbb módja a kipróbálásnak, ha mindet egyszerre kapcsolom be. Belátom, tévedtem. Viszont megtudtam a magyarázatát az általam érdekesnek talált jelenségnek.  Ez az oka annak is, hogy ide került a kérdés. Tehettem volna a PIC kezdőbe is, de annál azért többnek gondolom a tudásom. (bár ez nagyon szubjektív.) Köszönöm.
Segiteni probalunk, megha neha kicsit ravezetos modszerrel is
 Amugy ezt irtad korabban (mivel nem a Valasz gombra kattintgatsz, ezert ezt is nehez volt vissza kovetni...) Idézet: „Nincs rajz, mert fejből csináltam. Ezért nem is fogok neki rajzolni.” Ez rendben van, hogy neked nem kell, de nekunk kellene, hogy lassuk mit csinaltal meg fejbol, es azzal mik az esetleges problemak  pl: Idézet: „Az oszlopok bemenetére 1-1 db 180 Ωos ellenállás van kapcsolva,” Hogy vannak bekotve a LED-ek? Hogy akar ez mukodni? Az oszlopot kivalasztod (magasra emeled), majd a sorokat egyesevel aktiv magasbol aktiv alacsonyra huzod ahol a LED-nek vilagitania kell? Magyaran az egesz matrixot multiplexalod? Vagy a sorok parhzamosan lennenek vezerelbe es csak az oszlopok vannak multiplexalva? Idézet: „a bázisra pedig 4,7k-n keresztül jut. Több alkatrész nincs. A PORT a C, vagy D. Esetleg kevés az áram? Egyébként nagy fényerejű fehér LED-ek. A portok jók.” Itt is megint csak kellene latni mirol beszelsz -- 1 kep feler 1000 szoval... es nem egy nagy ordongosseg ezeket lerajzolni, es akkor mar reg tullennenk az egesz ugyon, mar vigan mukodne a kijelzod
Idézet: „igazság szerint én a PIC programozását tanulom, nem az építést.” Ez kizáró ellentét és ide vezet ahová jutottál. Javaslom még is a kezdők topicját, mert ha nem tudod hogyan kell vezérelni egy mátrixot, akkor oda valóak a kérdéseid. Nem is beszélve arról, hogy ha nem vagy hajlandó elektronikával foglalkozni, akkor ez nem fog menni.
Sziasztok újra.
Itt egy kódrészlet az LCD kezeléséből. Valahonnan letöltöttem, de van amit nem értek belőle. A leírás szerint a PORTE vezérli, a PORTD pedig az adatbusz. org 0 ;=============================== ; Port beállítás ; clrf PORTD clrf PORTE Start bcf STATUS,RP1 bsf STATUS,RP0 ; bank1 kiválasztás movlw D'14' movwf ANSEL ; RA0 analóg bemenet movlw B'11111111' ; PORTA bemenet movwf TRISA clrf TRISD ; PORTD kimenet clrf TRISE ; PORTE kimenet bcf STATUS,RP0 ; bank0 kiválasztás ;---- ; LCD kijelző inicializálása ; call Kesl bcf PORTE,RS ; LCD parancs következik movlw D'56' ; 38h, 8 bit interface set call Write call Kesl ; Busy flag olvasását "helyettesíti" movlw D'56' call Write movlw D'6' ; 06h, Entry mode set: increment call Write movlw D'13' ; 0dh, Display on, cursor/blink on call Write movlw D'16' ; 10h, Display/cursor shift: cursor call Write movlw D'1' ; 01h, Display clear call Write call Kesl2 ; Busy flag olvasását "helyettesíti" ;------------ A kérdések: 1. Feltétlen szükséges a PORTA beállítása, és ha igen, miért kell a 0-nak analógnak lenni? 2. A kijelző inicializálása részben kétszer küldi ki az D'56'-ot, nem tudom miért.
Ha valaki haladó, akkor nem letölti az LCD vezérlő programot, hanem megírja maga, miután ez egy egyszerű dolog, főleg egy haladónak!
Üdv !
A következő problémára várnék segítséget: A microchip féle webserverrel akadt problémám, mégpedig egy weblapról szerettem volna egy mezőbe beírt értéket feldolgozni a pic-ben. Ez addig nagyon jól működik, míg a HTML-be be nem teszem a következőt:
A pic ben ez a rutin dolgozza fel a kérést:
Szóval egyszerűen ezt a kérést eldobja a pic és nem értem miért, a kód a ConfigFailure -re ugrik, ha az ominózus adat érkezik. Ezt vagy a HTTPReadPostName, vagy a HTTPReadPostValue váltja ki szerintem, de nem tudom, hogy itt mi a hiba. Más adatokat is így dolgozok fel, pl RemoteIP és azt meg elfogadja. Válaszokat előre is köszönöm.
A mai "szupermodern" világban, sokan azt gondolják, hogy előkapja az androidos okoskodóját, letölt rá egy két valamit, meg fog egynéhány kimustrált CD/DVD motort, egy webkamerát, némi "vasat", forraszt kettőt, s már kész is a távirányítású MSR-je (Mega Super Robot). Sajnos, a mai rohanó világban már mindent azonnal akarunk. Bemegyek a boltba, kötök egy TV előfizetést, kezembe nyomják az aktivált beltérit, a parabolaantennát. Hazamegyek, felszerelem, összedugom, s már nézem is a BL-t. Ha értek hozzá, különben várhatok 2-3 hetet, mire kijön a szerelő. Hát nem felháborító milyen sok idő?
Kevesen emlékeznek már arra, hogy nem is oly régen, hónapokat kellett várni, hogy a megrendelt szuperkolor TV-t átvehessem az áruházban.Egy szónak is száz a vége, ne rohanjunk ennyire. A tudást nem lehet megvásárolni. Lépésről lépésre, az alapoktól indulva lehet mindent elsajátítani. Ne várjuk a sült galambot. A tapasztaltabbak tanácsait pedig fogadjuk meg, ne kritizáljuk, ne durcáskodjunk. Nem csak itt a fórumon, de az életben sem fog ez jóra vezetni. Köszönöm a megértést! Idézet: „Kevesen emlékeznek már arra, hogy nem is oly régen, hónapokat kellett várni, hogy a megrendelt szuperkolor TV-t átvehessem az áruházban.” No meg eveket egy-egy telefon elofizetesre Idézet: „
Ezzel az a gond, hogy ez html szempontból nem megfelelő. Az a ott nagyon nemjó helyen van. De ez inkább csak a böngésző számára jelent problémát. | A konkrét problémához: nincs debuggered? Ha nincs, tegyél pár ledet a pic lábaira, és mindegyik goto Configfailure előtt bekapcsolod az egyiket. Így legalább látod, hogy melyik gotora futott rá.
Az a baj, a debuggerem nem ott áll meg ahol kellene(néha csinálja, meg sokszor nem tud debug módba lépni).
Kipróbálom ledekkel, bár ha megvan, hogy hol vérzik el, akkor sem sokat érek vele, mert nem tudom, hogy mit csináljak. Mert a többi mező ugyanígy működik és azok meg jók. Gondolom a HTTPReadPostName-ben kellene lennie az "rport"-nak, a HTTPReadPostValue-ben meg a beírt értéknek?
Akkor előszöris derítsd ki, hogy miért nem megy a debugger rendesen.
Az régebben volt, hogy nem ott állt meg debuggoláskor, ahová a breakpointot tette az ember, hanem egy sorral lejjebb, de úgy vettem észre, hogy az újabb mplabokban ez javítva lett. De mindenesetre beszúrsz néhány Nop(); utasítást a BYTE i; sor után, ezekre teszel breakpointot, akkor utána léptetheted F8-al, hogy lásd, mibe megy bele és mibe nem. Valamint az optimalizálásokat kapcsold ki, mert egyes optimalizálások használatával az mplab nem tudja forráskódszinten követni, hogy hol tart épp a kontroller.
Ok, jó ötlet, az optimalizálásra nem is gondoltam, az be van kapcsolva. Hátha anélkül megy!
Közben próbálom a microchippel kicseréltetni a tönkrement ICD2-t. A chipcad, ajánlotta a PICKIT3-at, állítólag ugyanazt meg tudom csinálni vele mint az ICD2-vel, még talán többet is és állítólag jobb is. Bár akkor nem értem, hogy miért az ICD2 a drágább. :nemtudom:
Ez sajnos nem igaz - az ICD2 egy kifutott termek, ICD3 az igazi. A PicKit2 es 3 egyreszt nem produktiv termek (hobbi celokra lett kitalalva), masreszt ez abban is megnyilvanul, hogy nem tud az eszkozzel megbizhato modon konnektalni -- egy ICD3-am pl sokkal kevesebb gondod lehet, mint egy PicKit3-al. Ez utobbirol jot meg senkitol sem hallottam, csak panaszt, en szerintem kidobott penz... Ha nagyon nincs penzed akkor PicKit2-t vegyel, az is hobbi celokra van, de eleg kiforrott es nagyobb a tudasa, mint a Pk3-nak (kiveve az ujabb chipeket amiket lehet az mar nem ismer).
Kösz a véleményt, gyanús is volt az árából, hogy valami nem stimmel vele. Meglátom mi lesz az ICD2-vel, leadtam a microchip-nek a hibajelentést.Addig használom az utángyártottat.
Erről majd számolj be, hogy mit válaszolnak.
Az a baj, hogy én is gondban vagyok az égetőkkel. Ugye van egy utángyártott ICD2-m, ami jó, viszont kifutott. Most vettem egy PIC32MX795F512L-t, amit már nem tudok vele használni. Pickit2 hivatalosan nem tudja kezelni (égetés még megoldható, ha jól emlékszem, icserny számolt be róla), de debuggolás nem. Emiatt marad ICD3/Pickit2. Előbbi drága, 50000Ft körül van a chipcadnél, ennyit nekem nem ér, mivel csak hobbi célra használom. Marad a Pickit3, 12500Ft körül, viszont ez meg ugye problémás...
Írom amint van valami válasz.
A debuggolás megy optimalizálás nélkül. a curHTTP.data = "rpor" ez kevés, de nem tudom, hogy hová tünik a többi, mert ezt elvileg a TCP csatornából nyeri közvetlen.
Közben az rport-ot átneveztem remp-re a html-ben és a pic-ben is és így működik.
 Pont az ilyen hibákat nem szeretem. mert nem tudom mi okozza és később is előjöhet. 
Nem volt olyan véletlenül, hogy amikor rport-ra átírtad, akkor nem generáltattad újra a szükséges fájlokat? Nem emlékszem pontosan, de mintha valami ilyesmit kellene csinálni...
Nem már 2 monitoron folyamatosan nézem a fil-okat, ráadásul az új verziójú stack-ben már be lehet állítani, hogy hova tegye a printHTTP.h fájlt és az MPLAB azonnal rámozdul.
Leírásban nem találtam, hogy a HTTPReadPostName milyen hosszú lehet, mert az rport volt a leghosszabb NAME a html-ben a többi mind reövidebb. OK. kipróbáltam ha a HTTPReadPostName hoszabb mint 4 byte akkor elszáll. Mondjuk ha ez le lett volna írva egy kommentbe, vagy a help-ben akkor kb másfél hét szívást meg 3 honlap elkészítést megspóroltam volna. De lehet, hogy én nem voltam elég figyelmes és valahol tényleg leírták. (az apróbetűs részben). Köszönöm a segítségeteket és hogy időt szakítottatok a problémám megoldására! 
Trudnai írta:
Idézet: „mint egy PicKit3-al. Ez utobbirol jot meg senkitol sem hallottam, csak panaszt, en szerintem kidobott penz” Potyo írta: Idézet: „Marad a Pickit3, 12500Ft körül, viszont ez meg ugye problémás...” Mi a baj a PICkit3-al? Én tök jól elvagyok vele... 
Pedig a PK2 után használgatva nekem egy ócskaságnak tűnik. Még jó, hogy csak egy klónt vettem, sokat nem fogom nyüstölni.
Sokat írtunk erről korábban, keress rá, mert rengeteg indok van, még videó is van róla!
Ja hogy a LED-eknek amik rajta vannak mások a funkciói, meg hogy minden mikrovezérlőtípus-váltáskor újraírja a PIC-et benne...
Hát nem tudom, én programozásra, debuggolásra használom, gyakorlatilag ugyan arra mint a PICkit2-t és eddig ugyan olyan jól használhatónak találtam. Mondjuk a 3 nem tud logikai analizátorként működni (még) de ezt a funkciót is csak egyszer próbáltam, akkor se működött a PICkit2-nél mert lefagyott a program egyfolytában. Tudjátok miket készítettem eddig, azokra tapasztalatból állítom hogy ugyan olyan jó a PICkit3 mint a PICkit2. Sőt sokkal jobb, mert az újfajta típusokat is tudja kezelni.
Nekem mindegy, még nem volt szükségem olyan típusra, amit a PK2 nem kezelt.
Nekem azért tetszene, ha az MplabX használná a PICKIT2-t a 16F1938-as vezérlőhöz. Szerencsére csak egy ALT+TAB és parancssorból indítom a pk2cmd-t. De azért jobb lett volna ha csak egy gombnyomásra megy, mint ahogyan megszoktam a PIKlab esetében. Ha az SDCC és a gputils csomagok támogatnák rendesen ezt a vezérlőtípust, nem is váltottam volna az MplabX-re.
Más... és talán hasznos is lehet: Nagyjából egy napja szenvedek a analog rutinom áttételével, ami 16F690-esen meg 16F887-esen szépen működött, no meg még 16F1829-en is, de ezen a 16F1938-ason nem. Úgy néz ki, mintha az ADC menet közben megszűnne létezni. Leegyszerűsítettem a rutint csak az AN0 bemenetre fókuszálva, de így sem tökéletes:
A módszer nagyjából az, hogy mielőtt elkezdeném az AD átalakítást, kikapcsolom az ADC-t. Logikus. Nem? Nem. De eddig ez a megoldás mutatkozik a legmegbízhatóbbnak számomra. A tizedespont villogtatása a "debug" funkció, ez mutatja, hogy a vezérlőprogram működik, csak az AD átalakítás nem hajlandó újabb friss eredményt adni. Elolvastam az ERRATA-t, ami taglalja is a jelenséget. Rögtön meg is nyugodtam, hogy nem én vagyok a ludas a hibajelenségben, ami a leírás szerint 8MHz-es frekvencia felett jelentkezik, ha az ADC számára dedikált ( fenntartott, megépített ) RC oszcillátor üzemel ütemadóként az átalakításhoz. Ilyenkor előfordul, hogy az ADCON0 regiszter ADGO bitje nem törlődik, illetve a PIR1 regiszter ADIF bitje nem billen be és ad ADRES regiszterpár sem frissül. Ha ez bekövetkezik, akkor talán csak egy reset billenti helyre az ADC-t. ( Ezt nem próbálgattam. ) Az ERRATA-ban olvasható háromféle megoldás, mindhárom megmosolyogtatott: 1. Az átalakítás idejére vegyük vissza a rendszer órajelet. 2. Az átalakítás idejére altassuk el a vezérlőt. ( És mi van a többi funkcióval ilyenkor? ) 3. A Tad lejárta előtt szoftverből töröljük az ADGO bitet, mielőtt az átalakítás túlmenne a 11xTad időn és 1/2 Tad idővel az automatikus befejezése előtt. ( Ez is nagyon esélyes, ha belső RC oszcillátort használsz 4xPLL-el. ) Szóval viccesek ezek a fiúk, de igazából elolvashattam volna a doksikat, mielőtt erre a vezérlőre esik a választásom. |
Bejelentkezés
Hirdetés |
