Holnap lerövidítem a kábelt és kipróbálom.

Először csináltam egy új projektet és mindent beállítottam. Majd csatlakoztattam a Pk3-at, de a PIC nem volt rajt. Utána azt is csatlakoztattam, de ekkor sem ismerte fel, mert ugye alapból nem a Pk3 adja a tápot. Akkor beállítottam a kívánt feszültséget(3,5 V-nál többet nem is enged), majd újra konektálás a Pk3-hoz és akkor írta ki amit írtam. De működik a programozás, mint írtam és fut a led villogtatás, csak nem működik pár dolog és a Pk3 meg ilyen hibákat dob, debug módban meg semmi, nem ír és nem lehet semmit csinálni, de ezt is írtam. A lényeg, hogy 5V-ot sosem kapott és működik a kontroller csak valamiért a Pk3 nem akarja az igazságot.

Szia!

Láthatnánk a programod elejét. Itt írtam arról, hogy probléma lehet, ha a programozási lábakat kimenetnek használjuk fel és túl hamar be is állítja a program.

A debuggoláshoz az MpLab -ban a bedug módot kell beállítani az ablak közepén felül.

A config bitekre vonatkozó kérdésedre az adatlap 3-1 blokkvázlata megadja a magyarázatot.
pl: PLLDIV - A külső oszcillátor / kvarc frekvenciójából az USB órajel előállításához 4MHz-es jelet kell előállítani a PLL bemenetére. A leosztást lehet a PLLDIV értékével állítani. Ha pl. 20MHz kvarcot alkalmaznál, 5 -ös leosztás kellene.

Én most az MPLAB-al együtt frissítettem. Egyébként régebben automatikusan frissítette ha a programmer-> settings->configuration-nál az auto download firmware be volt pipálva. Persze ehhez az kell hogy internet legyen a gépen. A másik verizó hogy megkeresed az új firmware-t és a manual download-ra kattintva feltöltöd neki.

Olvastam amit írtál. Tettem is bele egy szoftveres várakozást, de ettől még sajnos nem változott semmi. A debug módot tudom, hogy ott kell átváltani. Olvastam az adatlapot, csak mivel sosem tanultam angolul elég nehéz megérteni és ezen a google fordító sem segített sokat.

Átállítottam auto downloadra már kb 3 órája, azóta többször is megnyitottam az MPLAB-ot, de nekem nem frissítette. Próbáltam megkeresni az fw-t, de nem találtam semmit a Microchip oldalán, se googleban sem.

Nem láttam még PICkit3-at közelről, de úgy gondolom (vagy legalábbis az volna a logikus...), hogy itt nincs szükség arra a felismerésre, amit a PICkit2 csinál a saját kezelőprogramjával. Elvégre az MPLAB tudja, hogy milyen mikrovezérlőt állított be a felhasználó, tehát tudnia kell, hogy az mekkora feszültséget bír. Nem gondolnám tehát, hogy az 5V megjelenhetett a kimenetén.

Arról nem is beszélve, hogy az MPLAB üzenetekből kiderül, hogy a 18FJ firmware van éppen az eszközben, és az tudja, hogy mit szabad csinálni ezekkel a chipekkel. Igaz, még én sem láttam PK3-at közelről.

Sziasztok!
Az alábbi késlelető csak akkor jár pontosan ha a változó unsigned long, mihelyst átírom pl. unsigned int -re elromlik. Valaki tudja hogy miért? Spórolni szeretnék a memóriával, mert a híváskori max érték 48 felesleges a long.

delay10us(48);

Rossz a koncepció! A szubrutinhívás, a paraméterátadás és a for ciklus szervezése összemérhető a 10 TCY késleltetéssel (szerintem jóval több is annál), így a késleltetés idejét az szabja meg, hogy hány utasításciklusba telik a késleltető eljárás meghívása - ami az optimalizációs paraméterek és az átadott változó hosszának is függvénye.

Ehelyett a Delay10TCYx(n), vagy Delay100TCYx(n) eljárást kellene használni, utasításciklusokban számolva.

Ha ragaszkodsz az eleganciához (hogy 10us egységben legyen megadva a késleltetés), akkor pedig makróként kellene definiálni. Pl. Fosc = 40 MHz-en, Fcy = Fosc/4 = 10 MHz, tehát 10 us = 100 TCY, ekkor

Igen ez jó ötlet, lehet át is alakítom így. De attól hogy a változó típusát megváltoztatom miért borul fel az egész?

Az int (fordítótól függően) általában 4 byte-os.
A long (fordítótól függően) általában 8 byte-os.

Ha megnézed a lefordított asm-et meglátod, hogy a long léptetése/vizsgálata a ciklusodban több utasításból áll ergo lassabban fut le.

Az MPLAB debug módban van? PK3 eszerint állítja be a DEBUG bitet. Plusz tölt is le valami saját kódot a programod végére talán.

Próbáld ki különböző firmware-ekkel! Én 16F818, 16F819-cel jártam úgy, hogy csak akkor tudtam debuggolni, ha régebbi firmware (1.25.10) volt a PK3-ban.
Ide tettem fel néhány firmware-t

Próbáld kis egy pár soros assembly progival is, mert már úgy is jártam, hogy a HI-Tech fordított baromságot.

Ja, és minden letöltés előtt fordíts. Ha több file-ból áll a forrásod akkor teljeset (rebuild).

Szervusz!
Mindkét változó módosítottad? T és t
Ha nincs szükség 255 nél nagyob értékre akkor használj Char típust

És hol látom az .asm-et? Mert a project könyvtárában nincsen.

Szeretnék építeni egy PICKITT2-t ,vagy klónt. Átnéztem párat, és rátaláltam a Szilva -féle klónra. Nagyon kicsi, és ügyes szerkezet. Hobby célra kifejezetten megtenné. Szerintetek a hozzá való 18F2550 mennyire nehéz programozni? Az LTP portos pogramozómmal érdemes nekikezdeni? Előre is köszi a hozzászólásokat!

Szia!

Felprogramozható az LPT -s programozókkal. Ld. Watt féle LPT mini.
Egy olyan klón, amin a Vdd-t állítható, jobb lenne - azzal a nem 5V-os kontrollerek is programozhatók, debuggolhatók: 12F1xxx, 16F1xxx, 18FxxJyy, 18FxxKyy, dsPIC30F, dsPIC33F, 24F, stb...(Egyre több lesz belőlük...) A különbség egy 8 lábú erősítő és egy-két fet...

Fordító függő. Lehet, h nem asm a kiterjesztése. Rosszabb esetben nem is szöveges állomány.

A program memóriát viszont meg tudod nézni fordítás után.

Ha a max ertek 48 akkor nyilvan egy 'char' vagy egy 'unsigned char' is megteszi, az csak egy byte-ot fog alfoglalni a memoriaban.

Masik, hogy felesleges ehhez egy argumentum is es egy lokalis valtozo is. En igy csinalnam:



Amugy mit jelent az 'elromlik'? Tobbet var? (Mennyit?) Vagy kevesebbet? (Mennyit?) Vagy vegtelen ciklusba kerul? (Vagy csak nem varsz eleget?) Vagy nem fordul le? (Mi a hibauzenet?)

Nincs külön hibaüzenet. Egy DS1820-al kommunikálna a PIC. A reset jel úgy néz ki hogy 480us-re lehúzza a pic az adatvonalat, majd elengedi és vár 70us-t. Ekkor az érzékelő (ha van) lehúzza földre az adatvonalat. Ezt lesi a pic hogy ez az állapotváltozás bekövetkezik-e. Ha long-ot használok válaszol az érzékelő, ha átállítom int-re akkor nem. Azt nem tudom megmondani hogy akkor siet vagy késik, csak azt tudom hogy nem jó. De most átírtam makróra, így jelentős a spórolás memória terén. Este kipróbálom hogy ezzel válaszol-e.

Ha az idozites kritikus, akkor hasznalj assemblyt vagy assy betetet.
Ha szabadna egy vitatott, de plasztikus hasonlattal elnem: a Porschemmal is hordhatnek tragyat a mezore, megsem arra hasznaljak a legtobben...

Azt azért elárulhatnád, hogy melyik változóról beszélsz (vagy mindkettőről?), mert kettő van a függvényedben és következetesen egyes számban beszélsz a konkrét változó megnevezése nélkül!
Ahhoz hogy segíthessenek neked, ahhoz Neked is több információt kellene megadnod!
Ha megváltoztatod a változok hosszát a kód hossza is változik, ezzel az időzítésed is, és lehet hogy ez elég a sikertelen kommunikációhoz...

Sziasztok!
Lerövidítettem a kábel hosszát kb 6cm-re és így már hiba nélkül megprogramozza és rendesen fel is ismeri a PIC-et. Viszont a debug továbbra sem működik, ezt írja az OUTPUT ablakban:
Running...
PK3Err0040: The target device is not ready for debugging.
Please check your configuration bit settings and program
the device before proceeding.
Természetesen a fenti fül debugra van állítva. Van valakinek valami ötlete? Köszönöm az eddigi segítségeteket!

Szerintem a dugdosós panel szórakozik veled. Ugye jól emlékszem, hogy ilyen próbapanelen van összedobva a kapcsolás?

Jól emlékszel. Kimértem és minden érintkezik rendesen.

Nem erről van szó. A párhuzamosan húzódó, egyenként elég hosszú vezetők kapacitása és induktivitása lehet a baj. Ezt a vezeték rövidítése okozta javulás is megerősíteni látszik.

Hát persze!
1. ötlet: Légy szíves becsatolni a konfigurációs beállításaidat! A program elejére írd be a jelenlegi beállításaidat ebben a formában:

2. ötlet: A lehetséges konfigurációs beállításokat listáztasd ki a fordítóval:

(ide is becsatolhatnád, mert nálam a fordító még nem ismeri ezt a típust)

Igy nehez segiteni. Tudni kellene mi az abra - pl az idozito rutint meghivod 1000x es egy LED segitsegevel lemered siet-e avagy kesik... Vagy leszimulalod.

Mindkettőre értettem a dolgot. De időközben okafogyottá is vált dolog mert Icserny mester javaslata alapján makróként definiáltam a késleltetést, és így remekül működik. Sőt a kód is rövidebb lett. Ezer köszönet érte.
Majd egyszer ha jobban ráérek eljátszom a dologgal, de most inkább haladok a projekttel. Mégegyszer kösz mindenkinek.

Sziasztok!
AN1310 bootloadert használok, asm - programjaimmal működik is szépen, de az mplab c18-at nem tudom rábírni,
hogy csak a 0x400-as címtől kezdődjön a programom.
Próbáltam ezt:




Lefordítom, letöltöm a processzornak, de semmi sem történik. Azt figyeltem még meg, hogy ha megnézem a generált hex fájlt, akkor azt látom, hogy a 0-s címtől a 0x400-as címig is vannak FFFF-től különböző értékek.
Valakinek van ötlete ezzel kapcsolatosan?
Előre is köszönöm.
Üdv!