Svenska ElektronikForumet

Det finns en bild i databladet som är ganska tydlig.
Se Fig 2-10 på sidan 45 i databladet.
Den vänstra delen "direct addressing".
Där framgår det hur 7 adressbitar kommer från själva
instruktionen och de resterande 2 from RP0/RP1.

> Programmerar med en PicKit2,

OK, har du kollat det där med "Release MCLR" (eller vad det nu kallades) ?
Kör du PICkit2 programmeringen innifrån MPLAB eller med det fristående
programmet till PICkit2 ?

Har testat både starta och stänga av MCLR i konfigurationen av PIC'en, startat och stängt av MCLR ut från PicKit2an, ingen skillnad.

Programmerar med det fristående programmet.

Edit: Ska testa skriva kod i ASM och kompilera med MPLAB när jag kommer hem, och se om det fungerar som vanligt.

Vad Jodjan menar, är nog kommandot/instruktionen till programmeringsutrustningen (PICKit) att den ska släppa MCLR-signalen och inte fortsätta hålla fast reset-signalen dragen låg. Är den dragen låg så ligger PIC:en i konstant reset utan att ta sig därifrån. Det brukar då finnas en knapp eller ett menyalternativ för att "släppa" den och låta programmet starta.

Ja, det var det jag tolkade att Klas-Kenny hade gjort, tror jag...

En annan sak är at verifiera hur CONFIG är satt. I ASM är det ju enkelt
eftersom det ligger i källkoden. I det som Klas-Kenny har visat har det
i alla fall inte funnits med, kan inte HiTech ange det i C-filen ?

Sen så är det ju inte första gången någon slänger ihop 3-4 rader kod
ock klagar över att det inte fungerar.

> Edit: Ska testa skriva kod i ASM...

Varför inte bara ta den kod som kompilatorn generar och testa ?
Kör den som ett rent ASM projekt och kolla med MPSIM.

En annan sak, kan inte HiTech kod köras genom MPSIM ?

Ang. CONFIG så har jag ju lagt upp bilder på hur det är satt i mitt första Inlägg, men vet inte om man ska skriva det någonstans i koden också? Har inte sett någonstans där man gjort det?
Inte en aning om det fungerar i MPSIM, tål ju att tas reda på.

Men för att enbart sätta några utgångar till bör det räcka med enbart rader kod.

Ska ta och testa kompilera asm-koden som MicroC genererar när jag kommer hem.

Nu var det MikroC som användes... Och PicKit2. I den senares program finns en ruta "/MCLR" som kan bockas i/ur, den ska vara urbockad. Den kontruktion som jag har på bänken här drivs av programmeraren, alltså ska "VDD PICKit2" vara ibockad och spänningen ställd till 5.0V. I övre delen av fönstret finns texten "Configuration", efter den ser man CONFIG, tex som i mitt fall "3FFF 0003".

/MCLR-rutan har jag testat bocka i och ur utan resultat, likaså med VDD, fast jag har extern strömkälla så denna används ej.
Den där rutan har jag aldrig tänkt på, även den ska kollas så fort jag har tillgång till min dator!

Aha, OK. MikroC var det kanske...

Varför kör man det när det redan följer med en C med MPLAB ?
Det är ju bara att kryssa i en ruta så får man HiTech installerat
på samma gång om MPLAB.
Jag är inte speciellt förtjust i MikroElektronikas prylar.
Helt kassa manualer. Flashiga med snygg design men saknar en hel del.
Färdiga libbar som är dåligt dokumenterade och svåra att veta vad de igentligen gör.

> fast jag har extern strömkälla

Varför ? Vad har du mer förrutom labbkortet som inte PICkit2 kan driva ?
Eller har du något annat en det standard 16F690 labbkort som följer med ?

Jag vet faktiskt inte riktigt hur det kommer sig att det blev MicroC, kanske borde skrota det och köra HiTech istället?

>Varför ?
Har egentligen ingenting mer än PIC'en som ska drivas, men av ren vana satte jag dit matning via nätagg och 7805'a (+kondingar), ser inte varför detta skulle kunna vara något problem då det alltid har fungerat tidigare.
Kör inte det labbkortet utan kör direkt på labbdäck, då jag har dåliga erfarenheter av att bryta pinnar på PIC'ar när de tas i och ur (Den enligt mig värdelösa) sockeln på labbkortet.

Ja visst, men för en första C-test med den koden som du visade
så spelar det väl ingen roll var processorn sitter. Jag antog bara att
det var en PICkit2 med ett "istoppat" labbkort... Finns ingen
anledning att flytta något processor.

Hur som helst, det är aldrig någon nackdel att beskriva hela uppkopplingen
*från början*. Att det hela inte startar kan likaväl bero på något du har
gjort på labbplattan (som *vi* ju inte ens visste att den existerade!).

> ...på PIC'ar när de tas i och ur (Den enligt mig värdelösa) sockeln på labbkortet.

Det har nog aldrig varit meningen att man ska göra det !

Vad är det förresten för begränsningar på den fria Hitech? Blev lite sur häromdan när jag slog i MikroC:s demolimit på 2 kilobyte kod...

Mycket möjligt att man inte ska ta ur PIC'en ur kortet, men när man inte har fler än man behöver har man inte så mycket till val Förutom att dra sladdar mellan labbdäck och "labbkort", och det blir rörigt.

Kopplingen på labbplattan är otroligt simpel, 15V matning, en 1µF konding på 15V-sidan och en 1µF konding på 5V-sidan, jord draget till pinne 20 på PIC'en, och +5V draget till pinne 1 på PIC'en, samt en 100nF-konding mellan pinne 1 och 20.

Sen sladdar dragna till programmeraren också, +5v till +5v, gnd till gnd, MCLR till MCLR, DAT till DAT samt CLK till CLK

Pullup på MCLR ?

> Vad är det förresten för begränsningar på den fria Hitech?

http://www.microchip.com/stellent/idcpl ... e=en542849

Sedan en filosofisk fråga? Orsaken att välja HiTec är väl stödet för de "små" PICarna, men är det ngn vits att programmera en så liten PIC i C? Borde man inte slå i tak rätt fort med stacknivåer, variabler etc?

Det beror ju lite på hur man skriver C-koden.
Stackanvändning o.s.v är ju beroende på "call-depth".
Sen så är det roligare att programmera i ASM...