Pkwarn0003, går ej att lösa meha av andra trådar (PIC prog)

[TomasL]

He he, blev nog lite upphetsad.
Nåväl, när jag kör "bredboard-layout" så använder jag alltid 1 k mot jord (i möjligaste mån, ibland finns inte den möjligheten tyvärr), när design och kod är fixerad, så blir det direkt mot jord (sparar lite komponenter).

[fireas]

hehe kommer tillbaka för att se att tråden spårat ur:) Love it hehe:)

jag bytte an0 till an2 där avst mätaren nu sitter.

Fungerar dessvärre ej

Ska prova programmera en ny PIC för att se om det är PICen men jag tror verkligen inte det.

detta var ju inte kul:(

[TomasL]

Alltid skojjigt.
Ett förslag, koppla en LED via motstånd, typ 470ohm eller så mellan alla pinnar och Vdd (inte PGC/PGD/MCLR) naturligtvis.
Börja blinka lysdioder på alla portar med olika frekvens, läs och åter läs om avsnittet kring konfigurationen, får du inte den rätt så är det stor chans att inget funkar.

Är det nått du inte förstår, klipp, klistra in och posta det här.

Dock, vad som är viktigt posta ALLT, inte enbart det du tror är intressant.
Dessutom kanske du bör överväga ett annat utvecklingsverktyg än det du har.

Grunden är, alltid processorkonfigurationen i programfilerna, samma gäller inklude-filerna, kompilatorer gör ofta fel, och du måste ha kontroll över vad som ingår i programmet och inte.
Skriver du i C så är det alltid ett antal inklude-filer som finns med, om inget annat för att definiera processorn.

Ett program skrivet i MCC18 till exempel, börjar alklt id i fölrsta filen, och även de flesta andra med till exempel:
#include <p18fFFxx.h>

Vilket talar om för kompilatorn (och dig) vilken processorfamilj som är vald ("FF" talar om vilken familj inom 18F det är).

Därefter inkluderar man alla andra bibliotek, till exempel stdio.h osv samt konfigurationen för samtliga konfigurationsord.

[Pajn]

@ThomasL
Jag sa att jag höll med dig om att det är bättre att göra de till ingångar och dra de till jord med motstånd, jag sa även att man bör göra så på ett kretskort. I produktion använder man kretskort och bör därför dra ingångarna till jord. Men på ett breadboard i experiemtsyfte är det fullt tillräckligt att ha de som lösa utgångar. Det viktiga är att de inte är lösa ingångar.

Visst man kan tappa en tamp som då kan komma åt en pinne men men i värsta fall har man förstört en krets för 50kr, ofta händer dock ingenting.
Vissa av mina PICar har blivit väldigt misshandlade med kortslutna pinnar, 12V in på nån ingång osv. och ingen har dött eller börjar bete sig konstigt vad jag märkt. Självklart skulle jag inte lite på de och har de vid sidan om för mindre viktiga saker. Jag hade kanske kunnat undvika detta ett par gånger om jag gjorde "rätt", men å andra sidan hade det kostat tid, ork och gjort även en relativt enkel koppling ganska svår att hålla koll på pga. alla motstånd.

@fireas
Testa att stänga av alla analoga funktioner och sätt ADC_niva till ett fast värde, då kan du se om det funkar så långt.
Kolla gärna med en simulator för att se om det funkar på den.

I mikroC behöver du inte inkludera något om du inte ska använda något av deras libarys för lcder och liknande så det borde inte vara problemet här.

[sodjan]

Du kan ju ta ett av de "lessons" som finns till PICkit2 och köra mot
din labbplatta. De ska fungera lika bra där, det är inget krav att
man har det speciella experimentkortet. Ta t.ex den som heter "blink".

D.v.s (som vid all felsökning) verifiera *en* sak i taget. Just nu vet vi inte
om det är problem i kopplingen eller i (MikroC) koden.

Om/när din uppkoppling fungerar med ett exempelprogram så kan du gå
vidare med ditt eget program.

När allt är oklart så har man mer kontroll genom att testa uppkopplingen
med ett enkelt ASM program, det utesluter ett antal felkällor och osäkerheter.

[fireas]

Har testat ett självskrivet blinkprogram som fungerat bra men ska testa igen efter allt jag gjort sedan förra testet. Om inte så testar jag att sätta ADC_niva = 1500 och se vad som händer.

återkommer lite senare

[fireas]

Jag testade mitt blinkprogram, fungerade ej.....

Bytte processor, fungerar klockrent!!



Det här med PIC-programmering var inte riktigt min starka sida men ju mer man förstår (väääääldigt lite!) desto roligare blev det så kanske blir någon PIC kurs i skolan:)



Tack så jätte mycket för er hjälp och jag återkommer med mer resultat!

[Pajn]

Vad bra att det löst sig!

Troligtvis har inte PICen gått sänder, de är ganska tåliga saker. Mer troligt är avkoppling eller någon configbit, men det behöver vi inte grunna i nu. För mycket strul på en gång blir bara jobbigt

Ursäkta att vi spårade ur tråden, det händer ibland

Att det är kul och bara blir roligare ju mer man kan håller jag med om, det är ju det som är så bra. Så även om vi är lite gnälliga ibland så är alla här för att det ska bli bättre för alla

[fireas]

Tror också det är felkoppling MEN (!!)

Min PIC fungerar inte med bara extern spänning och den fungerar inte med bara Programmeraren inkopplad utan båda måste vara inkopplade:S

Uppkoppling:

[sodjan]

> Min PIC fungerar inte med bara extern spänning...

Pullup (normalt 10 kohm) på MCLR ?
Notera att med PICkit2 anslutten så sköter den om MCLR.

> ...och den fungerar inte med bara Programmeraren inkopplad

Du har väl sagt till PICkit2's preogramvara att den ska "köra" processorn.
Jag tror att default är att PICkit2 håller kvar processorn i reset efter programmering.

[fireas]

Där förlorade du mig lite, hur menar du pullup på mclr?

Typ koppla Vdd till MCLR?

[Pajn]

Pullupen ser till att MCLR inte går låg och processorn resettas. En flytande (ej inkopplad) ingång svänger runt lite och kan få alla möjliga och omöjliga värden och därför behöver du en pullup som håller pinnen hög.

Pulllupen är ett motstånd på ~10k mellan pinnen och VCC

[fireas]

Ah, vcc ok, ska ta och prova det när jag kommer till skolan imorrn.

Varför "flyter" den förresten, av någon särskild anledning?

[sodjan]

> Där förlorade du mig lite, hur menar du pullup på mclr?

Jag menar inget mer än vad databladet redan bör ha talat om för dig.
Sidan 201 "FIGURE 14-2: RECOMMENDED MCLR CIRCUIT".

> Varför "flyter" den förresten, av någon särskild anledning?

Ingen annan anledning än att det beter sig om alla andra
CMOS ingångar på alla CMOS kretsar.

[Pajn]

Ska jag vara helt ärlig är jag inte 100% säker men jag har fått för mig att det beror på den enormt höga ingångsresistansen i en CMOS krets. Det gör att minsta lilla störning kan få de att ändra värde om de inte är anslutna till någon spänning. Det är också därför du Aldrig får lämna en ingång oansluten.