1. Amiket a megjegyzésben írkálsz, az lehetetlen! Ez a programrész semmit nem kapcsol ki!

Ha a rajzon PORTB-re vannak huzalozva az LCD lábai, akkor az lcd_config -ban mit keres PORTD?

Már ne is haragudj, ha nem érted a működését, akkor miért jelentesz ki ilyeneket? Éppen hogy nem mindegy, a PIC-et teljesen a gyári határadatokon túl használod így, ne csodálkozz, ha nem úgy fog viselkedni, ahogy azt elképzelted! Tessék a LED-ekkel sorban ellenállásokat beépíteni!

Hali!

Ha a pic belső osc-ját akarom használni, akkor az osc1 és osc2 lábakat csak szabadon hagyom? Nem kell lehúzni testre, vagy ilyesmi?

Köszi és üdv.

Sőt, nem szabad lehúzni sehová! Használhatod rendes I/O portnak, mint a többi lábat. Ha nem használod, konfigold kimenetnek és ne köss rá semmit.

Köszi!

Szia!

Nem feltétlenül a hibához kapcsolódik, de sokat lehet szívni...
Ha valamit rákötsz a pic-re majdnem minden esetben érdemes áramkorlátot rakni! A másik: Érdemes az adatlapban megnézni, hogy az adott port tud-e arra fele húzni, amire a portot használni szeretnéd, mert előfordulhat, hogy open collector-os, stb....

Oké ez jogos észrevétel. Mondjuk én a saját programomban már port-helyesen írtam ill. kötöttem a dolgokat. Ami a képen van részlet az a user manual-ból van. Egyébként találtam már hibákat a manual-ban, pedig nem vagyok valami nagy PIC guru. Ezért gondolkodom abban, hogy lehet az Lcd_Library eleve hibásan van megírva általuk.

Ezt nehéz elképzelni...

Én egy olyan cégnél dolgozom, ahol egész Európában elismert biztonságtechnikai berendezésket gyártunk, forgalmazunk. A hardver fejlesztő mérnökünk, aki a PIC-es és ATMEL-es eszközeinket találja ki, tervezi meg és programozza fel, Ő mondta, hogy a gyártók képesek hibázni a Library-ban, nemegyszer fordult elő, hogy neki kellett hibát keresni ill. javítani...

Én meg csak próbálkozom tovább, mert mégis inkább én vagyok a zöldfülü, vagy ahogy egyeseknek jobban tetszene: a balfa$z. De amint rájövök már mondom is mit szúrtam el.

Köszönöm a segítő szemekenk és kezeknek! A késleltetésekkel volt gond, mert az LCD adatlapja előírja a minimum késleltetési időt pl a feszültség megjelenése és a funkciós regiszterek beállítása között.
Aztán volt még egy olyan gond, hogy a standard initializálással nem működött az adott kapcsolási rajz.
Fogtam szépen az eddig működö LCD-met és ahhoz konfiguráltam a PIC lábait.

Ugye, hogy ugye!

Namost hogy is mondjam csak.

1. Lattal mar tokeletes szoftvert (vagy akar hardvert)? Persze, hogy elofordulhat...
2. Egy gyari libben egy hiba ennek ellenere sokkal valoszinutlenebb mint egy akarmilyen sajat vagy akar egy netrol innen onnan letoltott libraryban - egyszeruen azert, mert sokan tesztelik es ha a hiba megvan akkor van esely, hogy javitjak es ugye ez az osszes ugyfelnel javitodik...
3. Gyakorlatilag 3 fajta szoftver fejlesztoi licence letezik:

I.) GNU (ertsd onkentesek altal szabad idejukben fejlesztett ingyenes, nyilt forraskodu project): Ha hibat fedez fel a kuncsaft, akkor vagy forumokon alakinek nyog es az kijavitja vagy onmaga javitgat es ha akarja meg meg is osztja masokkal a javitasokat

II.) Olcso fejlesztoi eszkozok, akar ingyenesek (de nem ynilt forraskodu es kozossegek altal fejlesztett); Hiba felfedezodik, nyog az ember a cegnek es azt vagy kijavitjak vagy nem, es ha igen is lehet majd egy ev mulva...

III.) Iszonyat magas aron adott rendszerek: Nyog az ember, es a megfizetett penzert napokon vagy akar orakon belul elkuldik a javitast, de akar tamogatast is adnak ha nem lib hiba hanem user...

Hogy mennyit er meg fizetni az embernek es milyen szolgaltatasokat kap erte az ugye fugg attol, hogy mennyire eri meg a beruhazas, hogy egy-egy kieses vagy keslekedes alkalmaval mennyi veszteseg eri a ceget stb.

Roger!

Én CCS C-ben a múltkor a 16F946 LCD kezelését használtam, és abban is találtam hibát (egy regiszter bankolását elrontotta, vagy eleve rossz regiszterre hivatkozott a lib, amit hozzálinkel ilyenkor). A fordító által generált asm-et néztem órákig, hogy mit csinál pontosan, tulajdonképpen elég macerás volt így végignézni, hogy hogyan is képzeli el ő a dolgokat. Ha lehet mondani, sokkal macerásabb, mintha az egészet asm-ben megírtam volna.

Igaz, a progi többi részének viszonylagosan kényelmes megvalósítása C-ben kárpótolt ezért a kezdeti szenvedésért. Azt is kell mondjam, hogy ugyan nem túl sok magasabb szintű nyelvből fordított kódot nézegettem, de a CCS C által előállított kód az elképzeléseimhez képest is nagyon kulturált volt.

Létezik még magasabb kategória is, ahol pl. nem kötik ki hogy:

LIFE SUPPORT APPLICATIONS: $$$$$$ SOFTWARE is not designed for use in life support appliances, devices or systems where malfunction of the SOFTWARE can reasonably be expected to result in a personal injury. CMX customers using or selling CMX SOFTWARE for use in such applications do so at their own risk and agree to fully indemnify $$$$$$ for any damages resulting from such improper use or sale.

De hogy milyen esetek fordulnak elő, arra jó példa a Kuwaiti (az első iraki) háború, ahol az irakiak egy programhiba miatt tudtak beletrafálni egy amerikai laktanyába. A Patriot rakétákat vezérlő egységben ugyanis a már hosszú ideje kumulatívan mért idő számábrázolási hibája olyan mértékű lett, hogy rosszul mérte be a közelgő Scud rakéta pályáját. A gyorsjavítás az lett, hogy rendszeresen újraindították a rendszert. A hosszútávú tanulság pedig az, hogy tervezésnél nem kell elfeledni, hogy a számábrázolás hibája annál nagyobb, mennél nagyobb az ábrázolt szám. Két nagy szám különbségének hibája pedig... (ami pl. a v=ds/dt mitt szükséges) no, arról jobb nem is beszélni!

Nem ismerem ennek a lib-nek a használatát, de azt látom, hogy az init-nél megadod a portbitek sorrendjét paraméterként. Azt kellene megnézni elsősorban, hogy ez a sorrend tényleg jó-e. Ha máshogy nem, a lefordított progit disassemblerrel nézegetve, vagy ha keletkezik fordítás közben asm listafile, akkor abban.

Örülök, hogy sikerült, de azért ha van kis szabadidőd, talán érdemes tanulményozgatni azokat a c által fordított asm-eket, lehet belőle sokat tanulni, sőt, olyan következtetéseket is le lehet vonni, hogy milyen programozási fogásokat érdemes alkalmazni a c forrásban.

Sziasztok

Én még kezdő vagyok mikrovezérlők terén, éppen ezért megörültem mikor itt az oldalon közöltek egy AVR-Droper programozót, mi több a HE-store-no meg is lehetett venni nosza,vettem, hozzá procikat is és jó volt, elbajmolódtam a WinAVRel és jó volt. Persze bajlódom azóta is, de megy. Na de miért írom pont ezt és pont ide? Nem elment az eszem, csak:
- tudtok mondani egy egyszerűen megépíthető programozót amit egy kezdő is meg tud építeni?
- Továbbá olyan fejlesztő szoftvert hol találok, ami C alapú, és persze tudja az assembly-t is. Inkább C-s lenne a jó, mert nem akarok asm-el bajlódni.

Azért írtam, le ezt mert ha létezne egy ugyan olyan KIT mint az AVR-Droper+WinAVR az lenne a legideálisabb

Köszöni a segítséget egy lelkes amatőr

Persze, hogy létezik. MPLAB a fejlesztőkörnyezet+ C18 vagy Hi-Tech PICC vagy egyéb C fordító+Pickit2 programozó.

Minek építenél? A ChipCAD-nél október végéig még akciós a PICkit2 starter kit, ami az USB-re köthető PICkit2 programozón kívül a 20 lábú PIC16F690 mikrovezérlővel felszerelt Low Pin Count Demo kártyát is tartalmazza, s két CD-n a PICkit2 szoftverét és az MPLAB fejlesztői környzetet is tartalmazza - 5384 Ft + ÁFA áron?

Melesleg a PICkit2 nem csak programozásra jó, hanem3 csatornás logikai analizátorként (max. 1 MHz mintavételezéssel), debuggerként (ha olyan PIC-hez kötöd, ami alkalmas rá. A PIC16F690 nem olyan...) és kommunikációra. Pl. ha a PIC B5 és B7 lábait rákötöd a PICKIT megfelelő pontjaira, akkora PICkit2 kezelőprogramjának UART eszköze lehetőséget ad, hogy a PIC soros portján keresztül a képernyőre írj.
Például így:

Még egy illusztráció a PICkit2 használhatóságára: A mellékelt ábrákon egy PIC12F675-tel megvalósított konkrét alkalmazás szimulációja és a megépített áramkör "éles" tesztelése látható. Utóbbi esetben a PICkit 3 bemenetére a GP0, GP1 és GP2 jelet kötöttem. A PIC belső órajelről ment, így egy utasítás kb. 1 mikroszekundum.

Üdv!

Ismét egy kis segítség kéne.
Általában mindig rájövök ha valamit elrontok programozás közben de ez most teljesen kész. Nem tudok rájönni. Biztos hogy valami pitiáner dolog , lehet hogy már nem fog az agyam. Hátha a tiétek frissebb:


Egyszerűen a program nem jut el PC2_CIMKE részhez. Már fölcseréltem a két cimkét de semmi. Az első "helyen" álló cimkét szépen végrehajtja CALL UGRIK, de a CALL resetet soha. Csak akkor ha a CALL RESET - et beírom az első cimkébe. Magyarul akár mit csinálok ,bárhogy variálom csak a VETEL utáni cimkét csinája meg. Ilyennel még nem találkoztam. Mi lehet az oka? Hol rossz a kód?

Miért nem működik a code beillesztés?

Működik, csak a {code} nyitó tag-et cseréld le {code=asm}-re. Persze szögletes zárójelekkel.

Miért nem elég neked, ha csak egy fórumban kérdezel? Ott már várom a válaszodat, de ha így ketté szakítod a dolgot, akkor rám ne számíts...

Eloszori is nehany jo tanacs:

1. Cimke utan nem kell kettospont, egyszeruen a sor elejere kell tenni a cimket - es ugye utasitas vagy mas elem sor elejen nem lehet!

2. Cimkevel megyezo sorba soha nem rakunk utasitast!

3. Ehhez hasonlo problemakat gyonyoruen ki lehet debuggolni az MPLAB beepitett szimulatoranak segitsegevel.

Szoval nezzuk csak a mar kisse megszepitett forrast:

Nos, ezzel mar el is szurtad a VETT_KARR valtozodat, kovesd vegig szimulatoron mi is tortenik!

Tehat itt azt szeretted volna, hogy ha '1' -el megegyezik a VETT_KARR valtozoban levo ertek, akkor az UGRIK meghivodik? Ez igy egeszen el van bonyolitva. Helyette pl:

ugye mennyivel egyszerubb?

Ossze foglalva ami tortenik, hogy pl '2' a VETT_KARR erteke, ezt XOR-olod '1'-el, az eredmeny 0x31^0x32 --> 0x03, es ezt szepen eltarolod a VETT_KARR -ban, mert az alapertelmezett tarolas az F-be tortenik. Utana nyilvan a kovetkezo vizsgalat ahol '2' -vel XOR-olsz mar nem lesz eredmenyes... magyaran kell az a ",W" es hat mindig mikor a compilalaskor jonnek a figyelmezteto uzenetek azokat erdemes elolvasni...

Nem tudtam hogy nem lehet több fórumon kérdezni. Úgy gondoltam több szem többet lát.
A te hozzászólásaid is érdekelnek sőt...
Mindenkinek köszönöm a segítséget.
Megoldódott a probléma

PICDEM HPC Explorer kártyát használ valaki? Koolyabb érdeklődés esetén esetleg nyithatunk neki külön topikot.

Eddigi tapasztalatok:

- A J12-vel jelölt pozícióban beforrasztható egy 6 pólusó tüskesor, s akkor PICkit2-vel programozható, debug-olható. Természetesen(?) a kapcsolási rajzon és a szitázásnál hibásan van jelölve a lábszámozás. Ahol az 1-es szám van, oda jön a PICkit2 6-os lába (tehát a PICkit2 "háttal" van a PIC-nek).

- Most szenvedtem egy sort a demo program újrafordításával. Természetesen nem kompatibilis a jelenlegi MCC18-cal. Megoldás: a projektben levő c018i.c állományban a FPFLAGS név elé két aláhúzást kell tenni. Vigyázat! Két helyen is szerepel a fájlban.

Amire nincs megoldás: soros porton kapcsolódva minden jól működik, csak nem írja ki a hőmérsékletet. Debug módban néha ráfutott (ekkor a Hiperterminalban is látszottak az értékek), máskor nem. Elég szeszélyes...

MPLAB C18ban létezik-e egyszerűbb megoldás az alábbira:
rom char *PPR;
PPR=0x1020; //igény
(*((unsigned int *) &PPR))=0x1020; //megoldás