Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
CCS fordító estén az alábbi sorokat kell beiktatni a program elejére:
Ha olyan meleg volt a PIC, hogy nem tudtad megfogni, akkor az tönkrement. De az is lehet, hogy nem jól vannak beállítva a vonalak. Végigcsekkoltad? (keress rá erre a szóra, mert már rengeteg alkalommal leírtuk hogy kell ezt csinálni.) Kábelhosszakat is tartsd be(ez a oldalon le van írva..)!
Köszi mindenkinek a segítséget,megnézem a comparátor letiltását is +ba,szerintem úgy jó lessz.
Végre a B6,B7 működik,a data sheet alapján nincs rajta egyéb funkció.
 ,majd kipróbálom a többi lábat is ha az adott funkcióját letiltom.
Picit meg kell védenem a C-t, ugyanis egy normális fordító nem csinál semmi ilyesmit, ugyanúgy be kell állítani a TRIS regisztereket, komparátorokat, stb mintha assemblyben tennéd. Tehát emiatt ne utáld.
A kulcsszó a normális. A CCS ugyanis csinál olyasmit is, amire nem utasítjuk direkt, és a példaprogramjaikban meg ezekre a "mellékhatásokra" is előszeretettel építenek. Csak aztán ha nem működik, akkor lehet vakarózni. Vagy aki hallgat a jótanácsra, és megismerkedik az asm nyelvvel, az belenéz a listing fájlba...
Amúgy szerintem szilva tisztában van azzal, hogy mi a helyzet a C fordítókkal.
Köszönöm a pontosítást. Valóban azon van a hangsúly, hogy éppen milyen az a C fordító. Jobb helyeken ezt le is szokták írni, hogy a startup miket készít elő, miket állít be, de még akkor is hasznos lehet a fordító által előállított assembly kód megvizsgálása, hogy tényleg az történik-e, amire számítunk.
Nemrég egy 16F946-ra írtam C-ben progit, és igencsak sűrűn kellett néznem a disassembly listing-et, hogy rájöjjek, melyik direktíva pontosan mit eredményez pl. a portkezelésben. Ja, és szerintem fogtam egy hibát az LCD-kezelésében. Nem a HD-típusú modulról van szó, hanem az LCD üveglapról, amihez a 946-ban hardveres támogatás is van. Annak az init-jénél szerintem rossz bankon ír az egyik regiszterbe (abba a regiszterbe, amibe ír, semmi értelme LCD init kapcsán írni, viszont egy másik bankon, ugyanazon a címen lévőbe lenne) és ezt elég következetesen csinálta. Szóval az ilyenek miatt néha kicsit meginog a bizalmam ezekben a PIC-es C-csodákban.
Múltkor én is találtam már az SDCC-ben ilyen bankkezelési hibát, nem a Timer regiszterét olvasta, hanem a másik bankban ugyanazon a címen levőt. Egy rutin valós körülmények közötti lefutási idejének a vizsgálatára használtam, hogy a minimális órajelen járathassam a kontrollert, és gyanús volt, hogy túl kis értéket tárol le az eepromban.
Ezekből is látszik, hogy muszáj ismerni a kontroller asm nyelvét is ahhoz, hogy tudjunk vele komolyabb dolgokat csinálni.
Epp ilyenek miatt szokas egyetlen fejleszto eszkozre raallni, mert akkor annak minden nyugjet / bajat egy ido utan ki lehet ismerni. Ugralni a kulonbozo rendszerek kozott nem egeszseges. Viszont ebbol adodik, hogy egyszer raallsz pl a CCS-re vagy az SDCC-re es kesz, onnantol kezdve szinte egesz eleted vegeig azt fogod hasznalni - ahhoz, hogy valts valami nagyon nagy dolognak kell tortennie, pl mar nem fejlesztik egyiket masikat es mar nem kaphatok olyan PIC-ek amikre meg a regi rendszer mukodik... Es nyilvan ezekutan az atallas ismet akar evekbe is bele tellhet mire ujra ugyanolyan produktiv leszel benne.
Hello mindenki!
Én most kezdenék el foglalkozni a PIC-ekkel és vonzataival. Egy-két ötletet várnék, hogy hol kezdjem el? Előre is köszi.  
1. Van egy cikk a Nullatol a robotokig cimmel, olvasd el
2. Kezdd el olvasgatni ezt a hosszu temat, es talalsz rengeteg linket kozben ingyenesen olvashato PIC-rol szolo konyvek, ill Tutorialok-rol - meg magyar site-ot is fogsz talalni ezek kozott.
Köszönöm a válaszod!
Igazából csak egyenlőséget kell megvizsgálnom. Az XOR az tényleg a legjobb ötlet, csak mivel nem tudtam mi a kizáró-vagy igazságtáblája, ezért nem is gondoltam végig. Tehát ha jól értem, akkor az egymással összehasonlítandó két érték, azonos helyiértéken lévő bitjei megegyeznek akkor az eredmény nulla lesz. Innetől meg már tudok is vele mit kezdeni. Kössz mégegyszer.
Tulajdonkepp ugy kell felfogni, hogy vagy egy A input amivel a muveletet elvegzed, es van egy B konstans amivel a hasonlitast vegzed. Ha megnezed a tablat, ott ahol a B konstans 1 erteket vesz fel, ott az A erteket megforditja, mindenhol mashol az ertek valtozatlan marad. Magyaran ha az A-ban epp ugyanott vannak a bitek 1-sben ill 0-ban ahol a B-nel, akkor az eredmeny csupa 0 bit lesz, minden mas esetben 0-tol eltero...
Én nem hibát találta, hanem nem tudtam úgy bekonfigolni a C-s eszközökkel az USART-ot, ahogy nekem kellett volna(8bites vétel, 9bites adás, vagy fordítva). Egyszerűen erre C-ben nincs lehetőség. Természetesen a megfelelő regiszterek kellő értékkel való direkt feltöltésével a dolog megoldódott, de az OPEN nem volt erre alkalmas.
Aztán használni sem lehetett egyszerűen, mert a 9.bit kiviteléhez teljesen bele kellett túrnom a h-ba, hogy megtaláljam mit állítsak be neki, hogy az usart könyvtárakat használni tudjam, ha már egyszer C. Asm betétből a TX9 beállítása nem volt elég neki, egy belső változót kellett nyektetni(már nem emlékszem pontosan a részletekre, de ha érdekel megnézhetem.) Lényeg, hogy asm nélkül a C egy vakrepülés! Olyan, mint ha valakit úgy tanítanának repülőt vezetni, hogy nem mondják el melyik kapcsoló mire való, csak az automata pilótát ismertetnék. Ja és persze rögtön a levegőben kezdődnének az órák! Gondolom addig nem is lenne gond, amíg az automata jól működne... 
Egy kicsit haragszom rád, mert nem olyan régen egy franciaországban tanuló sráccal végigveséztük az egész témát, amiről most kérdezel. Te is itt voltál a fórumon, biztosan emlékszem!
Az a baj, hogy nem marad meg bennem minden, mert nem használom, vagy éppen ki sem próbálom.
Bocsánatosságom! Idézet: „asm nélkül a C egy vakrepülés! Olyan, mint ha valakit úgy tanítanának repülőt vezetni, hogy nem mondják el melyik kapcsoló mire való, csak az automata pilótát ismertetnék” Erről a repülőszimulátorokba beleszerelmesedett kollegám jut eszembe, aki csakazértis TU154-gyel és hasonló "ócskaságokkal" repöl, mondván, hogy ott tényleg tudni kell, hogy mit csinál az ember. Szerinte egy Boeing már semmire nem való, mert mindent az automatika intéz. Valahol amúgy igazat adok neki, és a hasonlatod is tökéletes! Idézet: „Én nem hibát találta, hanem nem tudtam úgy bekonfigolni a C-s eszközökkel az USART-ot, ahogy nekem kellett volna(8bites vétel, 9bites adás, vagy fordítva). Egyszerűen erre C-ben nincs lehetőség.” Ehhez mi köze a C-nek? Különösen azután, hogy magad is azt mondod, hogy "a megfelelő regiszterek kellő értékkel való direkt feltöltésével a dolog megoldódott"? Valójában arról van szó, hogy az adott C fordító mellé nem kaptál olyan kész könyvtári függvényt, amire a speciális céljaidhoz szükséged lett volna. Ez bizony kellemetlen, de minden programnyelvnél előfordulhat, csak pl.az assembly-nél már fel sem tűnik... Általában minden nyelv bővíthető külső függvényekkel,így pl. a CCS-hez is vannak külön "driverek": RS485, CAN, USB és egyéb perifériák kezeléséhez.
[OFF]
Idézet: „Erről a repülőszimulátorokba beleszerelmesedett kollegám jut eszembe, aki csakazértis TU154-gyel és hasonló "ócskaságokkal" repöl, mondván, hogy ott tényleg tudni kell, hogy mit csinál az ember. Szerinte egy Boeing már semmire nem való, mert mindent az automatika intéz. Valahol amúgy igazat adok neki, és a hasonlatod is tökéletes!” Na igen, amugy a hasonlat nagyon jo, mert gondolj bele, hogy mi a kulonbseg egy modern legijarat es egy sportrepulogep kozott. Mar reg nem az a cel, hogy a pilota a repulest elvezze, hanem hogy biztonsagban eljuttassak az utasokat egyik helyrol a masikra. Megnezed az Airbust ott mar csak egy joystick van, automatan allit minden kormany es trimmer feluletet, ugyhogy a pilotanak mar csak annyi a dolga, hogy a szamitogep tudtara adja merrefele akar menni. Ugyanez megfigyelheto a PIC programozasanal is: Amig megunknak hobbybol programozunk tokeletesen megfelel ha tobb idot eltoltunk valamivel, ha bele preseljuk a firmwareunket egy kisebb chipbe ill egyeb szep megoldasokat hozunk ki. Abban a pillanatban azonban, hogy atlepunk az uzletszeru teruletre ezek a sempontok semmisse valnak. Az egyetlen ami erdekes, hogy minel kisebb idoraforditassal minel nagyobb projecteket veghez tudjunk vinni lehetoleg minimalis hibalehetoseggel. Es minel nagyobb szeletekkel gondolkodunk annal gyorsabban haladunk. Pl ha meg kell irnunk az LCD modult ill. egy matematikai konyvtarat, vagy ha csak el kell gondolkodnunk azon hogyan lehet egy switch-case agat megvalositani assemblyben akkor maris idot veszitettunk es ugye megvan a lehetoseg, hogy hibas megoldast hozunk ki. Ezzel szemben a C-ben ott van egy csomo dolog amit mar nem kell letesztelnunk, csak berantjuk es kesz - ha ki akarunk valamit irni az LCD-re nem kell gondolkodnunk azon milyen idoziteseket kell hasznalnunk... Es most a kommercionalis reszerol beszelek, azaz ha kiderulne, hogy az LCD modul nem jo, akkor csak felhivom a CCS technikai supportjat es megmondom nekik mi a problema, ok majd kijavitjak a modult nekem. Es nyilvan mivel sokan hasznaljak a CCS-t (de beszelhetnenk mas ismert C fejleszto eszkozrol is akar) ezert eleg nagy az esely arra, hogy a problemat amibe bele utkozom azt mar valaki mas jelezte a CCS fejlesztoinek igy nekem mar nem is kell szembesulnom vele, avagy ha bele is utkoznek mar le is toltheto a javitas.
Ráadásul c-vel egy másik típusú pic-re átrakni a programot meglátásom szerint könnyebb, főleg ha a hw megvalósítás nagyjából ugyan az marad, pl. az lcd-nél maradva az ember figyel arra, hogy a megfelelő portokat használja. Ha pl. én a 16f726-nál a b portra kötöttem volna az lcd-t, akkor az lcd.c-ben csak egy define kérdése, hogy a d, vagy a b portot használja e a könyvtári rutin.
Abban viszont teljesen igazat kell hogy adjak, hogy ha valaki rááll valamelyik C fejlesztő eszközre, akkor annak bizony annál kell maradni, mert míg a pic asm állandó utasításkészlettel rendelkezik, addig a pic specifikus c utasítások akár a legegyszerűbb port írása, olvasása függvényekben is el tud térni. Persze a sima ANSI C része az nem változik, de itt ugye azért egy speciális esetről van szó, a program vezérlési logika, csak egy kis hányadát teszi ki a forrásnak, ezért elveszik valamennyire a C azon előnyéből, hogy C forrás könnyen hordozható akár fordítók között is. Ha a C fordító gyártók megegyeztek volna egy szabvány utasításkészletben, akkor lenne igazán szép világ. Ugye asm-nél a gyártó definiálta az utasításkészletet, és mivel az mblab ingyenes, és korrekt fejlesztői debug felületet ad, nagyon konkurencia nincs is. Összefoglalva igaza van azoknak akik szerint az igazi pic programozás asm-ben folyik, itt látod csak igazán melyik bit mire való, és itt tudod pontosan szabályozni, hogy a kód pontosan azt és akkora méretben csinálja mint amit a programozó akar, azonban ennek nagy ára van mint a portolhatóság, mind a fejlesztés sebessége terén, mint későbbi olvashatóság és megértés terén, és ma amikor a chipek egyre gyorsabbak, egyre nagyobb program és tárterülettel rendelkeznek ennek a bitfaragásnak sok esélye nincs C-vel szemben. Csak nézzétek meg, a 18-tól fölfelé az mplab saját c fejlesztőt gyártott, és kevés olyan könyvet találni a neten (legalábbis én nem láttam), hogy hogyan programozzuk a a 24 vagy 32-es sorozatú piceket asm nyelven, míg csak én két ilyen könyvet is ismerek ami ezen sorozatok C nyelvű programozását írja le. Bizony emlékszem mikor az amiga megjelent, egy irtó jó asm-et csinált a motorolla a 68000-esben, és mégis az amiga multitaszking oprendszere nagyrészt C-ben lett megírva. Grafikus volt, multitaszkos akkor mikor a PC még a dos-al meg a cga kártyákkal veszkődött, mindez 2 800k körüli floppyn. Ez van. Tudomásul kell venni, hogy nagyobb projekteket ma már nem egy ember ír ipari környezetben. Minap szembe jött velem a microbasic, a ds1820-as hőmérő kezelése a komplett one wire kezelővel együtt 120 sor tele üres sorokkal! És olvasható sor! A végén persze ez is az mplab asm fordítóját hívja meg, de tény hogy minden asm-nél magasabb fejlesztési környezetben nagyságrenddel nő a hatékonyság (és persze a kód mérete és a kód futási ideje is). Minden tiszteletem a pic asm-et kenő vágó emberek előtt és le a kalappal, de mint ahogy a windows a directx10-el (szintén c) agyontiporta a többi fejlesztési elképzeléseket (opengl) úgy a piceket is egyre inkább c-ben vagy valami más magasabb szintű nyelven fogják programozni, ahogy nő hw sebessége és a szabad memória mérete, és a bitfaragást el fogja tiporni a hatékony kód fejlesztés. Ez szerencsére a pic-eknél még évek kérdése, de míg 10-15 éve még sok embernek tanították az egyetem és főiskolán az asm programozást pc-re addig ma már szinte sehol nem látsz asm programozót, ha van az is api hívásokkal operál. Egy kollégám volt aki ennyire asm párti volt, az ARM processzorokba ásta be magát, gyakorlatilag a programja api hívás hegyekből állt, ami ugye megint ki tudja mit csinál háttérben hány bit és hány órajelciklus amíg lefut, és fel is adta, mert még így is iszonyat lassan haladt egy c-hez képest. Ja és még egy gondolat. A c-ben a #asm direktíva után simán beszúrhatsz asm kódot amivel azután úgy faragod a bitet ahogy akarod, míg az asm-ben soha nem lesz #C direktíva ahova c kódoz szúrhatsz be a programírás felgyorsítása érdekében. Ez persze szigorúan az én magánvéleményem, és a saját megfigyeléseimen alapul, de mivel lassan 25 éve gyúrom a szakmát pc programozás vonalon, ezért szerintem a haladásra így 25 év távlatából van némi rálátásom.
Nekifeküdtem jobban az égetés kérdésének. Elolvastam jópár cikket és fórumot, többek között ennek a fórumnak is a 70%-án átrágtm magam. A vonalak beállításait is elolvastam és megértettem. Lemértem a feszültségeket, minden rendben van. A ledek is akkor világítanak amikor kell. Bocsánat, ha az agyatokra megyek, de még nem működik a szúrkapaneles verzió. Mivel másnak működik a kapcsolás, kizárásos alapon az "ön készülékében van a hiba", vagyis az enyémben. 3 Kérdésem van már csak, ez alapján mérlegelek a továbbiakról.
Ugyebár megépítettem szúrkapanelen újra a wpb-t, vagyis a felépítmény maradt, de most a kábel mindössze 24cm. Amikor olvasok a PIC-ből(az oshonnak az égetőprogramját használom) 3FFF értéket kapok minden cellába. Ez legjobb ismereteim szerint azt jelenti, hogy beolvasta a PIC-et és az üres. Ha lehúzom akármelyik vezetéket a PIC-ről, akkor minden cellába 0000 értéket kapok, jelezvén, hogy hiba van. Amikor égetni akarok, próba céljából csak egy cellába beírok x értéket(amég nem működik nem akarok programot írni) Be is égeti, és amikor visszaolvasom akkor újra 3FFF van minden cellában. A kérdés pedig úgy szól, hogy a 24cm még mindig sok lenne? Második kérdésem, hogy olyan létezhet e, hogy a PIC-nek csak a MCLR lába halódik meg? Szóval, hogy olvasni tudom, de írni nem. A harmadik kérdés pedig akkor él, ha a másodikra igen a válasz. Van a PIC-nek a /PGM lába, ami ugyebár alacsonyfeszültségű programozóláb. Tudom, hogy a dokumentációba le van minden írva, de érdemes e nekem ezzel foglalkzni? Vagy egyszerűbb, ha egy másik PIC-el folytatom eddig nem túl sikeres pályafutásomat. Előre is köszönöm a segítséget, és elnézést az idegesítően egyszerű kérdésekért.
Idézet: „Második kérdésem, hogy olyan létezhet e, hogy a PIC-nek csak a MCLR lába halódik meg? Szóval, hogy olvasni tudom, de írni nem.” Nem, ahhoz, hogy kiolvasd ugyanugy kell az MCLR-re a Vpp feszultseg... Idézet: „A harmadik kérdés pedig akkor él, ha a másodikra igen a válasz. Van a PIC-nek a /PGM lába, ami ugyebár alacsonyfeszültségű programozóláb.” A PGM lab az NEM az alacsony feszultsegu programozo lab! Az csupan egy fizikai kapcsolo ha ugy tetszik, hogy az alacsony feszultsegu programozas engedelyezve van-e, de ettol fuggetlenul ugyanugy az MCLR labra kell a Vpp feszultseget adni, csak legfeljebb nem 12-13V-ot, hanem 5-ot. Hogyan kototted be a programozando aramkort? PGM-et akkor lehuztad a foldre egy ellenallason keresztul? Mekkoraval csinaltad? Hidegito kondik vannak? Mekkorak es hol? (Kapcsolasi rajz ertekekkel lenne a legjobb, akkor Te is es mi is latnank mit csinaltal - meg idealisabb lenne ha a meresi eredmenyeket is feltuntetned vagy leirnad).
Az alacsonyfeszültségű égetést még nem próbáltam, ez csak egy felvetés. Ezt az égetőt építettem meg.
A következő különbségekkel: a germániumdióda helyett is 1n4148-ast használtam. Külső 15V-os tápról csinálok 13,8V és 5V-ot. Egyébb adatok, amik érdekesek lehetnek: A MCLR lábra menő dióda a 13,8V-ból levágja a saját részét, ami 13,2V lenne, a valóságban 13,3V. A Vdd lábra a mérés szerint 5,02V megy. Puffernek 7407-et használok. Kábelnek a régi mátrixnyomtatóm  kábelét alakítottam át, ami jelenleg 24cm.
Sziasztok!
Szerintetek működhetne ez a kapcsolás mint digital-analóg konverter?
Idézet: „vagyis a felépítmény maradt, de most a kábel mindössze 24cm.” Az egyik(mint a következő hozzászólásodból kiderült, az LPT kábeled) 24cm hosszú, de milyen hosszú a másik(ICSP) kábeled és miből van? Idézet: „Ha lehúzom akármelyik vezetéket a PIC-ről, akkor minden cellába 0000 értéket kapok, jelezvén, hogy hiba van.” Ez nem hiba, ez az áramkörből következő jelenség. Idézet: „Be is égeti, és amikor visszaolvasom akkor újra 3FFF van minden cellában.” Tehát nem égeti be! Idézet: „A kérdés pedig úgy szól, hogy a 24cm még mindig sok lenne?” Ha a kábel jó, akkor nem sok. Idézet: „Második kérdésem, hogy olyan létezhet e, hogy a PIC-nek csak a MCLR lába halódik meg? Szóval, hogy olvasni tudom, de írni nem.” Nem, az MCLR lábra adott Vpp feszültség kapcsolja a PIC-et programozói üzemmódba. A kiolvasás is programozói üzemmódban történik, nincs különbség ebből a szempontból. Idézet: „Van a PIC-nek a /PGM lába, ami ugyebár alacsonyfeszültségű programozóláb.” Úgyvan, ez az alacsony feszültségű programozói láb. Csak és csakis akkor működik, ha az LVP bit a PIC konfigurációs bitjei közül engedélyezve van. Ha ez így van, akkor a PGM lábra adott 5V bekapcsolja az alacsony feszültségű programozási üzemmódot. De! Ha Vpp-t adsz az MCLR lábra, akkor tök mindegy, hogy a PGM-en mi van! Akkor is, ha az LVP bitet kikapcsolod, amit tegyél is meg, a konfigurációban! Idézet: „Egyébb adatok, amik érdekesek lehetnek: A MCLR lábra menő dióda a 13,8V-ból levágja a saját részét, ami 13,2V lenne, a valóságban 13,3V. A Vdd lábra a mérés szerint 5,02V megy. Puffernek 7407-et használok. Kábelnek a régi mátrixnyomtatóm kábelét alakítottam át, ami jelenleg 24cm.” A Vpp feszültségének elég a 12V. Nem kell kihegyezni 13,5-re, mert az újabb PIC-ek nem nagyon szeretik. Ezt módosítani is fogom az oldalamon, bár ne nagyon tudok róla, hogy gondot okozott volna ez valahol is, mivel nálam is 13,5V a Vpp, de jobb ha az új PIC-ek adatlapja szerint állítjuk be. (Egyébként a maximum értékeknél 14V szokottt lenni, de ez mindegy) Ha elektronikailag minden rendben, akkor szerintem a szúrka paneled okozza a bajt. Túl sok párhuzamos vezeték, nagy felület, hosszú átvezető kábelek. Esetleg valóban rossz a PIC.
Megnéztem a publikált írást, és ott eddig is 12,5V Vpp volt. Javaslom ezt használni.
A rajzot módosítottam, mert ott 13V volt eddig. Garantálom, hogy ettől egy PIC sem ment eddig tönkre. Csatoltam, mert a régi gif nem jelent meg jól nálam...
Köszi majd elolvasgatom őket aztán okulok.
Az rendben van, hogy azt az egetot kototted be, de magat a PIC-et amit programozni szeretnel milyen aramkorrel kapcsoltad ra a programozora? Rajzold le es tedd be csatolmanynak.
Idézet: „De! Ha Vpp-t adsz az MCLR lábra, akkor tök mindegy, hogy a PGM-en mi van! Akkor is, ha az LVP bitet kikapcsolod, amit tegyél is meg, a konfigurációban!” Igy van, de ha lebeg neki az LVP es kozben kapja az 5V Vpp-t az MCLR-en, akkor akar veletlenszeruen torlodhet is vagy mas veletlenszammal felul is irodhatna a program memoriaja. Programozas ill tesztelgetes idejere mindenkepp lehuznam a foldre kb 10k -val. |
Bejelentkezés
Hirdetés |
