Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Tudom buta kerdes de jo program van a Pic-ben?
Legközelebb a hosszú kódokat inkább txt fájlban, vagy az eredeti forráskód kiterjesztésében csatold, különben kilométer hosszú lesz egy oldal és senki sem szeret annyit görgetni.
Kösz!
Ok. Köszi.
Akkor már legalább tudom, hogy hogy került oda egy szöveges file. 
Szia Norberto,
Mi ez a .TXT orulet, ha .ASM vagy .C -kent catol valaki az miert nem jo? Nekem folyton problemaim vannak a .TXT kiterjesztes miatt...
Felőlem lehet akár xkt vagy hbc vagy xyz kiterjesztés is, csak lehetőleg ne az oldal emiatt kilométeresre nyúlt hosszának 70 %-át adja egy szövegként beszúrt akármilyen kód.
[OFF]
Persze, igazad van 100%-ban. nekem a gondom -- vagy kerdesem -- inkabb az lett volna miert nevezi itt mindenki at az eredeti .ASM -et vagy .C -t .TXT-re mielott csatolja. Azt hittem valami technikai akadalya van a dolognak, de nekem ugy tunik mukodik.
Még mindig kevésbé tartom problémásnak a TXT-t, mint amikor valaki DOC fájlban csatolja a tízsoros kódját, vagy a képet úgy csatolja, hogy egy DOC fájlba teszi, és azt csatolja...
De persze én is jobban szeretem, ha a kód az eredeti kiterjesztésével van (akkor a notepad++ felismeri a fájltipust, és az alapján kiszinezi  )Firefox-hoz hasznos a MIME EDIT kiegészítés, mivel a HE szervere olyan headerrel küldi a C fájlt, hogy le akarja a böngésző menteni. Ezzel a kiegészítéssel meg lehet oldani, hogy csak a temp mappába mentse, és mindjárt nyissa meg a hozzá társított programmal.
[OFF] Hehe, teljesen igaz
 Nekem mar a PDF-be csatolt kepektol is felall a szor a hatamon - jo kis exploitalhato formatumot mindenkinek hatha egyszer bekalpjuk a virnyakot mintha egyszerubb lenne mint a GIF vagy a PNG Na mindegy, szerintem tobblet munka TXT-be atpakolni es azt csatolni. Ne tudom mi egyszerubb a drag-and-drop-nal a nep szamara -- gondolom Windows alatt is mukodik ami Gnome alatt, hogy a file nevet bele huzom a browse windows-ba es meg is van oldva a dolog... Bar borzolni sem annyira bonyolult na mindegy.
Örömmel jelentem, hogy a PIC-kwik projekt keretében a "8/16 bites műveletek PIC24 assembly nyelven" c. fejezetet kiegészítettem.
A fejezet tartalma: * Bitenkénti logikai műveletek * Bitműveletek * A STATUS regiszter * Feltételes programvégrehajtás * Programciklusok * Léptetés és bitforgatás * Egyszerű példák a léptetésre * Aritmetikai kifejezések kiértékelése * Típuskonverzió: 8 és 16 bites mennyiségek összeadása Továbbra is várom az érdeklődők jelentkezését a Email címen! Szeretném felhívni a figyelmet arra, hogy sem az eddig kidolgozott két (programozással foglalkozó) fejezethez, sem a soron következő háromhoz nem kell PIC mikrovezérlőt venni. Sokkal kényelmesebb a mintaprogramokat szimulátorban vizsgálni. Majd ha a hardverrel foglalkozó fejezetekig eljutunk, csak akkor lesz érdemes kísérleti áramkört építeni.
Nem védeni akarom őket, de van logikus oka annak, hogy txt-be teszik.
Az ok pedig az, hogy nem akarják az egész forrást megmutatni, csak a kérdéses részt, amiben Ők a hibát sejtik. Ezért csak ezt másolják át egy notepadba. Ha most ezt egyszerűen átneveznék .asm-ba, hogy ne txt legyen, akkor nekiugranánk, hogy hol a konfig, meg ilyenek, mert ugye ezek a részek nem lettek átmásolva, de az .asm kiterjesztés azt sugallná, hogy egész programról van szó. De a dolog visszafelé is elsül, mert a legtöbb esetben nem csak abban a részben van a hiba, amit Ő csatol, lásd éppen az iménti dolgokat, hanem teljesen máshol! Jobban járnának ha az egész asm-ot csatolnák, de hát sokan szégyenlik, amit öszeszenvednek, és nem viselik a pozitív kritikát, amit egyébkén sokszor kicsit túlzásba si viszünk. Egyébként jól bírjátok az "ütéseket" itt oldalakon keresztül, éppen elképzeltem virtuálisan mekkora pofonokat kaptok egyesektől a kérdéseik és az értetlenkedéseik okán. Én türelmetlen vagyok nagyon(és kegyetlen  ), ezért nem is folytam bele, mert csak vita lett volna belőle. Ha azt látom, hogy egy kerek érthető válasz után, amit egy ilyesmivel foglalkozni akaró ember meg kéne értsen, megmagyarázza annak ellenkezőjét, azt nehezen emésztem. Na ennyit rólam...
[OFF]
Idézet: „De a dolog visszafelé is elsül, mert a legtöbb esetben nem csak abban a részben van a hiba, amit Ő csatol, lásd éppen az iménti dolgokat, hanem teljesen máshol! Jobban járnának ha az egész asm-ot csatolnák, de hát sokan szégyenlik, amit öszeszenvednek, és nem viselik a pozitív kritikát, amit egyébkén sokszor kicsit túlzásba si viszünk.” Pontosan! Most fejen talaltad a szoget! Ugyan nem ertem sokszor miert nem akarjak megmutatni a forrast hisze ez egy hobby forum, tehat nyilvan szerzoi jogokkal vedett szuperalgoritmusokkal foglalkozo szakemberek irjak ide problemaikat. De kulonben is a hibat izolalni a kod tobbi reszetol es egy olyan teszt kodot ossze allitani ami a kerdeses hbat produkalja. Es ebbe bizony bele tartoznak a konfig bitek s es a kapcsolasi rajz is. Nyilvan ha ezek a dolgok nem tortennek meg a kerdezo nem is fordit megfelelo energiat a problema kideritesere - akkor pedig ne varja mar el, hogy mi tegyuk ezt meg helyette. Neha persze elegendo egy kis kodreszlet, mert egy egyertelmu baki van benne - pl szintaxis hiba vagy mit tudom en, MOVLW MOVF helyett stb de ha nem akkor csak elindul a talalgatas. Itt ezzel az ADRESH<<256-os dologgal is, megkerdezem mi a teszt adat, a valasz 485. Fel sem merult bennem, hogy meg csak azt sem nezte meg az op, hogy a szam egyaltalan bele kerul-e a valtozojaba. Aztan irja a kod reszletet amiben ott a castolas amivel elmeletben mukodnie kell a shiftelesnek, de, hogy az a kod le sem fordul... -- nekem most romokban hever a gepem, meg csak ki sem tudtam probalni mi a fenet csinal a C18, de abban ott van az integer propagation amit szepen ki-be lehet kapcsolgatni es ha ki van kapcsolva akkor bizony csinal ilyeneket meg meg cifrabbakat is. Ha meg be van kapcsolva akkor esetleg feleslegesen csinal muveleteket -- ezert lehet kikapcsolni. De lenyeg, hogy ha egy hibat felbontanak aprobb muveletekre akkor ra lehet jonni hol a bibi. Az rendben van odaig, hogy valaki nem tudja, hogy ez az integer propagation kikapcsolhato es valoszinuleg alapertelmezesben ki is van kapcsolva, de hogy meg azt sem tudja melyik muveletnel jelentkezik a hiba az mar problema en szerintem. Na mindegy, nem vagyunk egyformak. Nagypapam aki a BME-n volt prof mindig azt mondta: Nem a targy tudasa a lenyeg, hanem hogy meg tudod-e tanulni. Es a masik: Gondolkodni kell megtanulni...
Én, mint azon programozással szenvedő alanyok egyike akikről épp szóvan (
) mindezt csak alátámaszthatom. Én személy szerint valóban nem azért nem rakom fel teljes egészében a forrást mert valami "szupertitkos" projecten dolgozom amit nem akarok megosztani profi programozókkal (akik az én kétoldalas hibákkal teli assembly szenvedésemet két /három soros "C" kóddal hibátlanul megírnák ) Viszont nem egyszer jártam már úgy hogy a kérdésem válasz nélkül maradt, később rájöttem azért mert a forrásban a kérdéses részen kívül még vagy 10 hiba volt. Ezért gondolom ránéztetek és inkább nem reagáltatok mert túl hosszú lett volna megmagyarázni, vagy a " ha még ezt sem tudja a többit minek magyarázzam...?" elvet követve csendben elmentetek a kérdés mellett. Én részemről ezt maximálisan megértem. A programjaim nagy része piszkozat, próbálkozás amin tanulok. Ezért csak az éppen kérdéses részt másolom ki egy jegyzettömbbe amit feltöltök, nincs ebben semmi bonyi. És egyébként a virtuális "pofonokból" is csak tanul az ember, sőt arra ösztökél hogy inkább megpróbáljam kiszenvedni a megoldást.
Nagypapádnak igaza volt, én csak annyival bővíteném, amit szintén nagyobb tudásúaktól hallottam, hogy nem a száraz adatokat kell bemagolni, és mint egy enciklopédia nyomni, hanem azt kell tudni melyik könyvben van az, amit keresünk, és tudni kell mire való, azaz használni kell tudni a képleteket, az adatlapokban található adatokat. Ismerni elég a felépítést és az alapvető működéseket.
Én fejből alig emlékszem néhány sűrűn és nem régen használd konkrét dologra, ezért ha kérdés van, előtte megnézem az adatlapban, mert az kb. 1 perc, mint hogy hülyeséget mondjak. Általános dolgokkal nincs ilyen gondom, de ahhoz meg idő kellet. Ahogy látom itt, pont az idő az, amit nem hajlandó rászánni senki. Ott ülnek egy probléma felett, aminek a gyökerei az általános iskolai anyagoknál kezdőtek és felteszik a legbutább kérdéseket is néha. Attól tudok legjobban kiakadni, ha egy ilyen személy még segítő választ is ad, olyan témából, amit két napja "tanult" itt(még akkor is fura, ha netán jót mond). Jelzem, hogy teljesen személytelen minden megállapításom, nem gondolok ilyenkor senkire konkrétan, ez egy általános jelenség. Abban csak reménykedni tudok, ha esetleg mindez megmozgat valkiben jó irányba valamit.
Te csak a txt ügyben estél bele a szórásba, de szerintem trudnai belátta a dolgot.
A szakmai részben szerintem egész jó utat jársz be, csak így tovább! Most jönnek a megszakításos dolgok megértése és használata. Próbáld meg általánosságan áttekinteni a folyamatot, és első körben ílyen kérdéseket is feltenni. A kódolás ráér, ha a folyamatot átlátod, és a szükséges programozási teendőket is ismered(pl. mentések, flag-ek kezelése, stb.)
A txt-s vitát indítandó poszt meg elsikkasztódott...
Senkinek semmi ötlete, hogy mi lehet a kódban a hiba? Vagy a kód hibátlan, és máshol keressem?
Igen, furatgalvános a nyák.
Mivel ez az első kontrolleres kapcsolásom, amit építek, pont úgy csináltam, ahogy a cikkben volt. És mivel ott nem esett szó arról, hogy melyik lábra kell még kondi, ezért nem is tettem sehova pluszba. Ezek hiánya okozhatja a melegedést? Mert nekem eddig csak akkor melegedett így IC, ha fordítva kapta a tápot... Elsőre tuti nem kapta fordítva. Azóta lehet, hogy sikerült a méregetés közben valamit rövidre zárni. Mert más már nem jut eszembe. Meg tud úgy halni egy PIC, hogy rendes tápnál is csak melegszik? (miután ki tudja, mi történt vele? )Sajna csak a jövő héten tudom megnézni, hogy mennyire halott a kontroller.
A program az oldalon fennlévő hex file.
Amúgy átnéztem az asm fájlt is, meg újra is fordítottam. De kötve hiszem, hogy ettől melegedne. 
Miután nem láttam a nyákot(nem a tervet, az igazit), és nem lehetek benne bizonyos, hogy a bekötés tökéletes, így csak rád támaszkodhatom ,és ha te azt mondod, hogy minden rendben a nyákkal és a bekötésekkel, akkor csak arra tudok gondolni, hogy a táp és-vagy a PIC erősen gerjed, és e miatt melegszik.
Hogy korábban mivel sikerült volna tönkretenni, ezt megint csak nem tudhatom, de az bizonyos, hogy elég nehéz ezt megtenni, ha minden rendben van bekötve! Esetleg egy nagy felbontású jó minőségű képet tudnál feltenni, mindkét oldalról?
Sziasztok!
Átszerveztem a HW-t és így lehetőségem nyílt, hogy hardveres SPI-t használjak. C30-ban dsPIC30F4013-mal. Emlékszem még mikor a 8bites családdal foglalkoztam ez elsőre ment mind hw-ban, mind sw-ben. Ennél viszont egy rémálom. Külső EEPROM-ot akarok elérni , konkrétan 25LC640-et. Lábait így kötöttem be: 1-> RD0, 2->RF2, 3,7,8->Vcc, 4->GND, 5->RF3, 6->RF6. A program meg így néz ki, csatolva! A hiba, hogy minden esetben 0-át kapok vissza. Mi lehet a probléma?
Ajánlom EZEN hozzászólás elolvasását, illetve az ezt követő még néhányat, a jövőre tekintettel!
Megkaptam a képeket levélben. A nyák nagyon jó minőségű, és akárhogy is keresem az eredeti rajzhoz képest nem találtam eltérés. Én nem tudnám a nyákra fogni, hacsak valamelyik furatgalván nem tökéletes! Esetleg ezt érdemes lenne megvizsgálni, annak ellenére, hogy a PIC melegedés nehezen magyarázható egy szakadással, bár ki tudja.
Az is tény, hogy a cikkben sincs elég kondi. Hogy ott miért jó, és neked miért nem, annak egy oka lehet, más a nyák vonalvezetése. Ezzel nem azt akarom mondani hogy a cikkben helyes lenne a kondik kispórolása! Annak önműködően kéne mindig a panelre kerülnie. Én van mikor többet is teszek a nyák tervezésekor, mint a rajzon, ha a nyák vonalvezetése ezt kívánja. Mindazonáltal nem lehet 100%-ig ráfogni a kondikra, de 90%-ot adok neki. A maradék 10%, hogy a PIC eleve rossz volt. Ide nem számolom, hogy mi történt vele a mérések alatt, mert az sokváltozós! Idézet: „Nagypapam aki a BME-n volt prof mindig azt mondta: Nem a targy tudasa a lenyeg, hanem hogy meg tudod-e tanulni. Es a masik: Gondolkodni kell megtanulni...” Nekem volt a BME-n egy villanytan tanárom, aki ZH-kon azt mondta, hogy felőle használhatunk mindent (jegyzet, könyv, számológép, akkoriban még sem mobil, sem laptop nem volt), mert ha valaki nem tudja, hogy hogy kell megoldani a problémát, a ZH alatt úgysem fogja tudni megtanulni a módszereket. Ellenben bonyolultabb képleteket, és ilyesmi jellegű lexikális tudást szerinte nem volt érdemes bemagolni, arra ott a könyv és a jegyzet. Azt vallotta, hogy a problémamegoldás módszertanát kell megtanulnia egy olyan embernek, aki mérnök szeretne lenni, és ebben ő nagyon profin oktatott is minket.
Igen, ezt szerintem jól látod. Én is meg kell, hogy mondjam, lusta vagyok belemélyedni egy sokoldalas programlistába. Ha viszont látom a törekvést arra, hogy a kérdező megpróbálja behatárolni a problémája forrását, ezáltal a "hogyan építsünk atomerőművet PIC-kel" jellegű kérdésből egy konkrét adott "gond" látszik körvonalazódni (mint pl. a minap a 16F690 USART-jával kapcsolatban), akkor igenis előveszem az adatlapot, és megnézem az ide vonatkozó részeket, hátha nekem többet mond, vagy azt olvasgatva felsejlik valami saját emlékem a kérdéssel kapcsolatban.
Én úgy gondolom, ez mindenki részéről egy tanulási folyamat: a kérdezőnek azt kell megtanulnia, hogy milyen információkat kell ahhoz összeszedni, hogy hatékony legyen a kérdése; a válaszolóknak pedig azt, hogy mit és hogyan kell ahhoz elmondaniuk, hogy a kérdező előbbre jusson és megértse, hogy miért úgy kell, vagy ajánlott megoldani. Azt természetesen senki sem szereti, ha olyan kérés érkezik a fórumra, hogy "legyen szíves, csinálja meg valaki nekem ezt és ezt", de ez az esetek döntő többségében szerencsére ez nem is áll fenn. A legtöbb hasznot mindenkinek az hozza, ha a válaszok, segítségek alapján maga a kérdező tér rá a helyes megoldás útjára.
Köszi.
Most a hétvégén már nem foglalkozok vele többet, majd hétfőn, újult erővel. (A zöld lakk sokat dob az esztétikán. )
Én néztem, de most hirtelen nem jut több észrevétel eszembe. Mit jelent a "nem jó"? Azt nem próbáltad, hogy a soros porti init után _nem_ interruptosan tudsz-e olvani az USART-ból bejövő adatokat?
Sziasztok!
- Nem kérdés, inkább meglepő mérési eredmény.... A pic16f628 -ra fejleszek megszakításos soros vonali rutinokat, de elfelejtettem az INTCON regiszter PEIE bitjét 1-be állítani. A mérésnél a neki küldött üzenetekre nem reagált, de a szintén megszakításosan megírt adó rutin a bejelentkező szöveget elküldte. Az adatlap szerint (figure 14-14) az adási és a vételi megszakítást is kapuzza az INTCON PEIE bitje, melynek reset utáni értéke 0. Ezekután hogyan tudta elküldeni az üzenetet? Az elfelejtett bit beállítása után a küldött üzeletekre is reagál. Sziasztok. Idézet: „A pic16f628 -ra fejleszek megszakításos soros vonali rutinokat, de elfelejtettem az INTCON regiszter PEIE bitjét 1-be állítani. A mérésnél a neki küldött üzenetekre nem reagált, de a szintén megszakításosan megírt adó rutin a bejelentkező szöveget elküldte. Az adatlap szerint (figure 14-14) az adási és a vételi megszakítást is kapuzza az INTCON PEIE bitje, melynek reset utáni értéke 0. Ezekután hogyan tudta elküldeni az üzenetet?” Nem latom a kodot, igy csak egy tipp: Egy masik interrupt beesett, de mivel a TXIF mar allt azt kezelte le az ISR-ed.
Kipróbáltam. Egyáltalán nem fogad adatokat.
 |
Bejelentkezés
Hirdetés |
