A Hi-Tech C Lite változatát is használhatnád az Eclipse alapú HI-TIDE-vel (Win/Linux/Mac OSX)

Ez jó hír, főleg az, hogy ilyen gyorsan sikerült megoldani a kérdést! További sok sikert! Ha elakadsz, szólj...

A távirányítók elég változatos jelsorozaokat használnak, így korántsem biztos, hogy egy bit mindig ugyanolyan hosszú. Ha nem ismered fel a _pontos_ kódolási módszert, akkor nem is fogod tudni megmondani, hogy az adott jelsorozat milyen értéket képviselt kódolás előtt. Tehát könnyen lehet, hogy a külünböző PC-s progik is csak "hozzáképzelnek" valami értéket, és az korántsem az, ami valójában az eredeti rendszerben volt.

Ámde ez teljesen felesleges is, mivel Neked nem megfejteni kell a kódot, csak felismerni, vagy "visszaböfögni". Ha Te akarsz kiadni ilyen kódot programmal, akkor pont elég a "lerajzolt" jelalak alapján egy táblázatot felállítani, ami a jelváltások közötti időket tartalmazza, és ezt egy borzasztó primitív progival "lejátszani". Általában ezek az idők uniformizálhatók, és csak 3-4 különböző idő létezik a jelváltások között.

Kód felismerésekor is hasonló a módszer, a jelváltások közti időket kell mérni és egy bizonyos tűréssel illeszteni kell a programban eltárolt, felismerendő értéksorozatra.

Anno csináltam hardvert + PC oldali szoftvert, amivel a távirányító jelét lehetett kielemezni, a jelváltások közti időket uniformizálni, valamint a rögzített kódok alapján egy olyan táblázatot felépíttetni, ami alapján egy nem túl bonyolult progi több kódot is fel tudott ismerni. A felépített táblázat egy fa struktúrát reprezentált, magyarul az aktuálisan vett jelváltási hossz alapján lehetett mindig továbblépni, ha lehetett, a fa "levelei" voltak a vett kódok.

A konkrét megvalósítás a mai napig működik, az öcsém PC távirányításra használja, egy 12F683 dolgozik benne, és egy URC1-es távirányító vagy 25 billentyűjét tudja dekódolni és soros porton keresztül küldeni a PC felé. A dekódolás által felismert billentyűk és a PC felé kiadott kódok megváltoztatásához csak a legenerált táblázatot kell feltölteni a 683 EEPROM-jába.

A Hi-Tech lite változata (Pro változat lite módban) olyan borzalmas kódot generál, hogy az már fáj. Nemhogy nem optimalizál, szerintem direkt felesleges utasításokat tesz be. Pl. semmi értelme nincs több MOVLB-t egymás mögé berakni a legegyszerűbb műveletnél is, márpedig én ilyeneket láttam. Még olyankor is, amikor biztos, hogy nem valami alapszintű optimalizálás csapott onnan ki dolgokat, és ez maradt belőle.

Persze, így könnyen lehet azt írni, hogy "vedd meg a pro-t, mert úgy 4x kisebb és 3x gyorsabb lesz a programod"... És a lite verziójú fordítás pont ezt írja is a fordítás végén...

Szóval ezért próbálok valami más megoldást találni. A Microchip C18 preprocesszora egy kalap kaka, már elnézést. Sajnos normális CPP-t meg nem bírtam hozzánöveszteni, mert valami elég érdekes paraméterezéssel hívja meg a C fordító a preprocesszort, kellene írni egy wrapper progit ahhoz, hogy pl. GNU CPP-t lehessen használni vele. Hi-Tech CPP-je jó, de a kódgenerálás lite módban felejtős. SDCC elvileg ingyenes is és jónak is tűnik, bár futottam már bele olyanba, ami mintha fordítói bug lenne, de inkább továbbléptem egy workaround-dal, mert soha nincs semmire időm, és nem elemeztem ki a problémát. Pedig tudom, hogy nem lenne rossz, a fejlesztőknek is segítség, ha a hibát kivesézi az ember.

A Hi-Tech Lite fordítója tényleg tesz bónusz utasításokat, nekem úgy tűnt, hogy minden C sor közé betesz kettőt. 16F-es kódot néztem, ott nem MOVLB-t rakott, hanem valami mást, de két asm utasítás ott volt mindenhol pluszban. Mondjuk egy olyannál, mint az autó belső világítás vezérlőm, annál nem számított, de pl. ha EEPROM-ba akar az ember írni, akkor azt meghiúsítja, mert nem az íráshoz szükséges pontos utasítássor fut le.

Amúgy én is találtam SDCC-ben hibát, kb. egy évvel ezelőtt. Úgy rémlik, hogy valamelyik TMR regisztert akartam átmásolni az EEDAT regiszterbe, és nem váltott bankot a TMR-hez. Talán a TMR2 lehetett, mert a 12F683-nál annak a címén az 1-es bankban nincs regiszter és ezért írt nekem folyton nullát az EEPROM-ba. Aztán végülis nem próbáltam megkerülni, mert ez úgyis csak azért kellett volna, hogy lássam, valós körülmények között legrosszabb esetben mennyi idő alatt fut le egy utasításblokk, hogy minimális órajelen futhasson a kontroller. De végül úgy voltam vele, hogy a blokkon kívül úgyis sleep-ben, akkor mehet magasabb órajelről is, az össz fogyasztás ugyanaz marad.

Igen, a multkor volt itt egy problema, hogy fill-el fel akart valaki tolteni egy teruletet, de mivel a ket terulet nem egy szegmensben volt ezert nem lehetett kitalalni a cimet (marmint a relokacios cimet ami miatt meg cimaritmetika nem is mukodhetett).

Ennek ellenere sokkal jobb megoldasnak tartom a relokativ kodolast mint az abszolutot, mivel pl abszolutban meg RAM terulet kiosztas sem megoldott -- marad a CBLOCK-os "magad uram ha Isten nem segit", amivel lehetnek azert problemak.

Bizonyitani sajnos nem lehet, hogy vajon tenyleg szant szandekkal szaporitanak az utasitasokat, mindenesetre valoban nagyon vacak a binaris ami keletkezik. Mindenesetre ha megnezed a GCC-AVR-t pl, akkor ott is optimalizalas nelkul eszetlen kodot general, pedig ott aztan nincs erdeke senkinek sem, hogy extra utasitasokkal gyarapitsa a kodmeretet...

Azért ez elég meredek összeesküvés elmélet. Plusz utasításokat nem fog belerakni szerintem egy fordító sem. Valamekkora verseny csak van a fordítók között, ezért szerintem nem engedhetik meg ezt maguknak. Az lehet hogy nem optimalizál agyon, pl mindig bevált egy bankba, még ha nem lenne épp szükséges, akkor is. De azért nem kell elriasztani senkit a fordítók használatától, én még nem találkoztam olyannal hogy valamit rosszul fordított volna le, bár igyekszem mindig a legutolsó változatot használni. Hi-Tech nél meg az a fura hogy a pro változat sem eredményez kisebb kódot, sőt van mikor nagyobb lesz a simához képest. (a sima nem a lite hanem a standard) De ezt nyilván kódja válogatja.

Igen, ezt en is igy gondolnam, hogy nincs gonosz ero a hatterben (ezert irtam a GCC-s peldat). Gyanitom, hogy mikor mi egy "normalis" compilernel "kikapcsoljuk" az optimalizalast akkor azert abban meg van valami optimalizalas, ami ezeket a nagy marhasagokat kikapkodja, felgfeljebb azok az optimalizalasok kapcsolodnak ki amit a debuggolast nehezitenek illetve ami esetleg architekturalisan befolyasolhatja a kod futtatasat. A Hi-Tech es hasonlo forditoknal pedig az optimalizacio kikapcsolasan valoban az optimalizalo algoritmus kikapcsolasat erthetik -- csak egy tipp.

Hát, az összeesküvés-elméleteknek én sem vagyok híve, de szerintem előbb inkább nézz meg egy Hi-Tech Pro-val lite módban fordított kódot. Nem hiszem, hogy bármiféle optimalizálás előtt szabad olyannak lennie a kialakult kódnak...

Egyébként mintha a Hi-Tech fordítójánál is lett volna valami furcsaság, ami lefordítva nem teljesen azt csinálta, mint amire a forrás alapján az ember gondolt volna, de nem emlékszem pontosan, és nem akarok hülyeségeket beszélni. Több dimenziós konstans tömbök indexelésénél tolt el valamit, a végén ott is megkerülő megoldást használtam: egydimenziósra alakítottam a tömböket és az indexet számította két paraméterből a progi.

Annak idején a CCS C-vel történő első próbálkozásom során (LCD-s óra 16F946-tal) szintén belefutottam olyanba, hogy egy regisztert rossz bankban piszkált, de ez nem fordítási hiba, hanem a hozzá adott gyári lib-ben lévő bug.

Az SDCC meg a múlt héten okozott fejtörést, két, szerintem helytelen dolgot is találtam, bár lehet, hogy a kettő összefügg. Az egyik, hogy a ?-es kifejezések mintha nem úgy működnének, ahogy kellene, a másik pedig a bit típusú változónak történő értékadásnál jött elő. Valami olyasmi történit, hogy össze-vissza forgatta meg gyömöszölte az operandusokat, ki is jött neki egy nulla vagy nemnulla érték, aztán a bitbe meg mindig a ennek legalsó bitjét akarta betölteni, holott volt, hogy valamelyik fentebbi bit jelezte a nemnullaságot. A "!=0" behelyezése a forrásba semmit sem változtatott a lefordított kódon, szerintem kioptimalizálta. Szóval ez biztos, hogy bug, csak pontosan le kellene írni, reprodukálható kóddal szemléltetni. Lehet, hogy a ?-es kifejezéseket is emiatt rontja el.

A baj ezzel csak az, hogy ez egy minimális progiban, rögtön az eleje táján jött elő, és akkor ki tudja, hány ilyen hülyeségbe szalad bele az ember egy komolyabb projekt során. És persze nem érti, hogy miért csinál hülyeségeket a progi, aztán jöhet a lefordított kód asm szinten történő bogarászása, debugolása. Sokszor úgy érzem, hogy ha asm-ben állnék neki, már előrébb lennék. Aztán amikor meg nincs ilyen, akkor meg persze százszor gyorsabb C-ben haladni. Pl. egy printf, még ha csak a lite verzió, ami max int-et tud kiírni, de akkor is nagy segítség.

Most éppen egy FM rádiótunert építgetek, már szól Szóval a tuner egy klasszikus szuperheterodin, varikapis hangolással. Annyival van a rádiós rész kiegészítve, hogy a helyi oszcillátor jele egy 64-es, nagyfrekis előosztón és utána kötött jelformálón keresztül TTL szinttel ki van csatolva. Ez a jel érkezik a PIC-be, ami PWM-mel állítja elő a hangolófeszültséget (pontosabban kettőt: egy hangolófeszültséget és egy AFC-t), a PIC-ben futó program meg egy szabályozási hurkot alkot: méri a frekvenciát és a kívánt vételi frekvenciához igazítva szabályozza a hangolófesz(eke)t. Úgy néz ki, hogy +/-10kHz-en belül tudom tartani a vételi frekit, ami szerintem elég jónak mondható. Extraként a KF/FM demodulátor egységből kinyerhető, jelerősség-jelet A/D-zem és egy oszlopdiagramon kijelzem az LCD-n a kívánt és a valós vételi frekik mellett. Mivel a PIC egy 18F4550 (ez volt kéznél), így még az is lehet, hogy a végén USB-ről lehet majd a rádiót macerálni

Sziasztok !

Kicsit OFF ,de PIC-es ....


Van a linktárban egy "hangfelvevő és lejátszó PIC16f877-el ...." című link ,de nem megy.Nagyon érdekelne ,nincs valakinek elmentve esetleg a weblap ?



Előre is köszi !

Sziasztok!

PIC-et még nem használtam, most viszont szükségem van rá. Az a gondom, hogy sok típus van, és nehéz rövid idő alatt a legjobbat kiválasztani.

Ami kell: 4db GPIO, és soros port (TxD, RxD), és olyan 8-10MHz-es kvarcról működne. 5V-os tápfeszültségről.

Tehát nincsen semmilyen különleges igényem.

Ti, profi PIC-esek, mit javasolnátok?

Ezeket mind teljesíti egy 16F628A is, az pedig egy eléggé ismert, közkedvelt típus.

Sziasztok!

Nincs véletlen valakinek eladó pickit2 klónja ? vagy esetleg a hozzávaló alkatrészek (persze felprogolt pic-el)?

köszi!

A saját verziómból van csomag, igény esetén élesztve-szerelve is. Ha érdekel, keress meg!

Bár a képen nem látszik, és az eredeti oldalt sem sikerült megtalálnom, de ez vagy egy külső eepromba rögzít, vagy számítógépről adja/veszi az adatokat soros porton.
Vagy még esetleg vannak ilyen analog hangtároló chipek, lehet hogy azt vezérli piccel.

Találtam ilyet, talán ez segít:
eepromos visszajátszó project

Sziasztok!
Már régóta gondolkozok azon, hogy meg kéne tanuljak PIC-et programozni, de mindig is túl nagy feladatnak láttam, és nem volt elég bátorságom elkezdeni. Hébe-hóba töltöttem pár anyagot, de mindig csak jól összegabajodtam, és letettem. Analóg elektronikában már lassan otthon vagyok, de a programozás terén még a kezdő szintet se érem el. Azt kell tudni, hogy iskolában pascalt tanítanak, de ez engem annyira nem érdekel, és C+ -ban látom a jövőt, mivel jövőben megyek egyetemre és ott is az lesz. Valakit megkérek szépen, hogy igazítson útba e téren. Bármi segítség újdonság lesz. Teljesen előlről, honnan kell kezdeni a programozás világát? Semmit nem tudok. Ok, pascalban megírok egy programot, ami működik, na de ez hogyan ültetődik át nekem utána hardwares formába, meg stb kérdések. Nagyon hálás lennék ha valaki valami anyagot tudna adni teljesen 0-ról kezdve. Ha lehet magyar legyen, mivel teljesen kezdő vagyok és nem biztos, hogy így számomra még magyarul is minden érthető lenne. Nem látok abba sok értelmet, hogy egy megírt programot beviszek egy pic-be, amit nem is értek. Szóval inkább egy egyszerű led villogtatáson pic-el kinlódnék fél évig, de én valósítsam meg teljesen. Tényleng megkérlek, hogy valami bő anyagot és telejsen a legelejétől küldjetek, mert amiket kaptam az már vagy haladóbb fázisban levő volt vagy nagyon röviden és átfogóan tárgyalt. Megismertem az analóg áramkörök világát, mert az eddigi évek alatt csak azzal foglalkoztam, de most kedvem van még egyetem előtt ha csak egy morzsányi betekintést is nyerni a digitális világba. Köszönöm előre is Lehet elég OFF ez a kezdőségem itt, de mégis csak ebben a topikban vagytok a legtapasztaltabbak e téren.

Könyvtárban próbáld meg megszerezni elolvasásra Kónya László legelső PIC-es könyvét. Ha kiolvastad és megértetted a tartalmát, a lényegét, utána jöhet ugyanezen szerző legújabb kiadású, idei könyve. Én ezt ajánlanám kezdésnek. Ha valami új dologgal, fogalommal találkozol az említett könyvekben, ne legyél rest utánanézni, utánaolvasni a Google-ban, vagy itt a HE keretein belül rákeresni a Keresővel!

[OFF]Na nezd le a Pascalt, az kivalo, hogy elsajatitsd a strukturalt programozas fortelyait (erre talaltak ki eredetileg, valoszinuleg azert ezt tanitjak neked). A programozasban sohasem a szintaktika a lenyeg, hanem a gondolkodasmod, tehat azt kell megtanulnod. Kesobb, hogy C, C++, C#, Java, Ada, Perl, Python -- es meg ket oldalon keresztul sorolhatnam -- szoval hogy melyikben fogsz / akarsz programozni az mindegy lesz, lenyeg, hogy algoritmizalni megtanulj.

Hétfőn megnézem a városi könyvtárban, remélem meglesz mert egy elég kis városkában lakom, és már sokszor néztek meg mikor ilyen jellegű anyagot kértem, ezért mindent netről tanulok és innen a fórumból. Keresőt meg szoktam használni, de még kérdésem se volt, vagyis minden kérdőjel egyelőre. Esetleg net-en van valami anyag erről, elektronikus könyv, honlap bármi, esetleg djvu vagy pdf? Bő anyagot lehet kapni a neten ilyen téren mint pl az említett "Kónya László" könyv? Nagyon gyakran alkalmaztsam már azt, hogy könyveket nyomtattam ki itthon, mert nem volt meg a könyvtárban, és befűzetettem. Köszönöm az elindító anyagot.

Ezeket kaptam a neten, miután regisztráltam egy oldalra. Ezekről lenne szó?

Olvastad már az itteni kezdőknek íródott cikkeket?
Olvastad már ezt a topicot elejétől végig?
Ha ezt megteszed, nem is lesz több kérdésed, mert mindenre van válasz, vagy a válaszra utaló link!
Szánd rá az időt, mert itt senki nem fogja kétnaponta elmondani minden betévedőnek azt, ami már le lett írva.

Rendben. Csak az a baj, hogy úgy sejtem, itt nagyrészt már jóval magasabb szintű eszmecserék vannak mint én amit megértek, de akkor nekifogok. Köszi mindenkinek.

Amiket úgy ítélsz, hogy nem az a szint, azt kihagyod. Keresd azokat a kérdéseket, amik a tiedhez hasonlóak, és találsz egy csomó javaslatot. Ezeket érdemes megfontolni, és megpróbálni levonni a következtetéseket.
A megszólalók oldalait is érdemes megnézni.

Helló

http://fairco.freeweb.hu/ lessz a te segítséged!
Építs egy PIC égetőt (pl. pickit2 klón) és egy próbapanelt melyen legyen ICSP port (lásd watt oldalát). A ChipCAD-tól szerezz be egy 16F84-et, erről egymillió dokumentációt és leírást lehet találni a neten. Tanulmányozd az ezekkel foglalkozó fórumokat na meg mások forrásfájlait!
Mindenki volt kezdő.

Üdv

Sikerült kihozom egy elég érdekes problémát. Csak akkor megy a PIC, ha fogom a próbapanel fém részét, egyébként mintha megállt volna az órajel generálás. Próbáltam külső rezonátorról, belső oszcillátorról, raktam 10 nanos szűrőkondit a Vdd-Vss lábak közé, de semmi. Ha már volt ilyen kérdés, akkor bocs, nekem nem sikerült megtalálom.

Köszi szépen. A ChipCAD tőlem 600 km-re van, de megpróbálom beszerezni ami kell. Az oldalt közbe én is megkaptam és watt oldalát is. Ugyanakkor icserny elküldte nekem a Norbertó által ajánkott könyvet is. Köszönöm mindenkinek

Az mclz láb fel van húzva a + tápra 10kohm al ?

Fel van. Nem resetel, hanem egyszerűen mintha nem menne az órája. Korábban ment rendesen, de tegnap valamiért bekattant, és azóta ezt csinálja.

LVP bit le van tíltva, vagy ha nincs akkor a PGM láb testen van?