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

[TomasL]

Och om man då tittar på din bild:
Såsom det ser ut så är VPP (röd sladd) (lite otydligt på bilden) kopplad till RA4/OSCOUT och inte till MCLR/VPP, då funkar det naturligtvis inte.
Nu har jag inte brytt mig om att kontrollera om programmeraren värkligen är rätt kopplad, men uppenbarligen är MCLR/VPP felkopplade

[fireas]

Ska sitta ikväll med att läsa igenom config manualen. Trodde det var standard att den valde en intern klocka bara:S

När det gäller dioderna: Varför är det så dåligt att inte ha ett motstånd?

Varför är en diod och ett motstånd att föredra? kan dioden brännas av för mycket ström?

[fireas]

Och om man då tittar på din bild:
Såsom det ser ut så är VPP (röd sladd) (lite otydligt på bilden) kopplad till RA4/OSCOUT och inte till MCLR/VPP, då funkar det naturligtvis inte.
Nu har jag inte brytt mig om att kontrollera om programmeraren värkligen är rätt kopplad, men uppenbarligen är MCLR/VPP felkopplade

Oj vad dålig bilden blev. Detär sladden som böjs och inte syns, den sitter rätt:)

Som sagt, ska läsa på configen och återkommer imorgon då jag kommer läsa på i 1-2 timmar.

[Borre]

En lysdiod behöver alltid strömbegränsas. En lysdiod har ett specificerat spänningsfall som varierar en aning mellan lysdioder (av samma typ), med temperatur osv. Bara något högre matningsspänning än spänningsfallet för lysdioden ger en mycket för hög ström genom den som mycket väl kan förstöra den och det som driver den, PICen i detta fall.

Har dina lysdioder ett spänningsfall på 2.8V är det bara använda ohmslag för att räkna ut lämpligt motstånd med vald ström, 20mA är en vanlig specifikation på små lysdioder, men det kanske inte behövs så mycket för att lysa tillräckligt såklart.

[sodjan]

> När det gäller dioderna: Varför är det så dåligt att inte ha ett motstånd?

Det här är ju grundkurs 1A, finns ingen anledning att upprepa sådant även i denna tråd.
Se istället t.ex : http://elektronikforumet.com/wiki/index.php/Lysdiod.
Här kommer jag bara att säga, lyssna, lär och gör rätt.

> Trodde det var standard att den valde en intern klocka bara:S

Jag vet ju inte varför du trodde det. Dessutom finns det lite olika
"default" här. Dels har processorn sitt eget default (d.v.s efter en "Erase All"
då hela CONFIG registret har 1'or och oscillatorvalet är "111 = RC oscillator"), dels
så kan ju MikroC ha *sitt* eget default (vilket ju verkar vara "010 = HS oscillator"
enligt din screen-shoot, om du inte har ändrat det).

Generellt så kan det vara en bra idé att inte "tro" allt för mycket...

Allmänt gäller för CONFIG för alla processorer, att man går igenom alla val och
sätter det så som man själv vill och behöver ha det i den aktuella applikationen.

I fallet på din bild så är ju den interna oscillatorn lämplig, t.ex "100 = INTOSCIO"
eller vad deet nu heter i MikroC's dialogbild.

Men, som sagt, detta med oscillatorvalet har inget med "device not detected"
att göra. Det beror på något annat, *kanske* avsaknaden av avkoppling, men
det kan även beror på rena felkopplingar, glappkontakt o.s.v.

Det en så pass enkel koppling så jag skulle prova att riva den helt och koppla
upp det på nytt, gärna på en annan del av labbplattan (för att utesluta glapp
i plattan). Kopplingen PICkit2<->PIC ser dock OK ut...

Så för att sammanfatta :

- Fixa avkopplingskonding.
- Fixa CONFIG inställningarna.
- Koppla bort sensorn.
- Bygg eventuellt om själva uppkopplingen.

Jag ska koppla upp en 16F690 i morgon på kontoret och köra på samma sätt
så får vi se hur det går.

Sedan en liten kosmetisk parentes...
Vänd gärna processorn på labbplattan åt samma håll som bilden i databladet.
Det blir mycket enklare att verifiera kopplingen mot databladet på så sätt...

Lite OT (vilket bara visar varför jag är kritisk till Mikroelektronikas prylar...).

På din bild av CONFIG inställningarna finns ett val som heter "MCLR pin function"
vilket har värdet "enabled". Frågan är då om "pin funktion" syftar på själva
reset-funktionen eller på I/O funktionen ! D.v.s vad betyder "enabled" egentligen?

Av värdet 0x0FF2 på samma bild, kan man utläsa (genom att kontrollera mot databladet)
att det bör betyda att pinnen är MCLR (vilket är bra). De kunde ju ha haft "MCLR" resp
"Input" som val på bilden istället för "enable"/"disable"...

[fireas]

Då lade jag till en kondning på 100nF och nu fungerar det att skriva till PICen.

När det gäller configen så är jag lite lost, fastän jag läser manualen.

Jag förstår att den inte är inställd på den interna klockan , därför lade jag den på INTOSC.

Men resten, förstår inte varför jag skulle behöva dem och därför har jag de som de är?

Sedan märkte jag att i programmet läser jag med rader : ADC_read(2) vilket bör innebära AN2.. Jag själv hade kopplat till AN0
Kanske det du menade sodjan med kommentaren innan?


Till att avsluta detta inlägg: Programmet verkar inte fungera och eftersom jag tror min kod är rätt så antar jag att det beror på det ni säger : Configen.

Men manualen ger inte så mycket, jag förstar inte varför vissa grejer skulle behövas i mitt program?

[sodjan]

> Då lade jag till en kondning på 100nF och nu fungerar det att skriva till PICen.

HA!

> När det gäller configen så är jag lite lost, fastän jag läser manualen.

Fråga om det som är oklart, bara säga *att* det är oklart är lite meningslöst...

> Jag förstår att den inte är inställd på den interna klockan , därför lade jag den på INTOSC.

Ja, det verkar vettigt (utan att veta alla alternativ). Har du kollat värdet som kommer upp
i samma dialogfönster och matchat det mot databladet för att verifiera ? Det finns ett
par olika varianter på INTOSC. Kolla alltså bitarna FOSC0-2, databladet sidan 199.

> Men resten, förstår inte varför jag skulle behöva dem och därför har jag de som de är?

Behöva och behöva. De finns där och används av processorn oavssett vad du tycker.
Se bara till att de står som du vill ha dom. Om vi utgår från din tidigare postade bild så:
- Osc ändrat, OK.
- De 5 nästa är OK som de är.
- De 3 sista skulle jag sätta som "disabled", du behöver inte de funktionerna just nu.

> Sedan märkte jag att i programmet läser jag med rader : ADC_read(2) vilket bör innebära AN2..
> Jag själv hade kopplat till AN0 Kanske det du menade sodjan med kommentaren innan?

Ja, det verkar ju vara en felkoppling. Jag vet inte vilken kommentar du syftar på.
Alltså med ett antagande att parametern i anropet syftar på AN-numret !

> Till att avsluta detta inlägg: Programmet verkar inte fungera och eftersom jag tror min kod är
> rätt...

Varför tror du det ? Vi har ingen aktuell version så det går inte att kommentera vidare.

> så antar jag att det beror på det ni säger : Configen.

Configen styr mer att processorn kör över huvudtagt. Om programmet sedan inte gör
precis det som du förväntade så beror det troligare på att koden inte gör det du tror.

[fireas]

Kod: Markera allt

void main() {
     unsigned long ADC_niva;
     TRISA = 0xFF; // PortA - input
     TRISB = 0x00; // PortB - output
     TRISC = 0x00; // PortC - output

     ANSEL = 1;    // AN pinnarna görs analoga
     ANSELH = 1;
     C1ON_bit = 0; // Avaktivera comparatorerna 
     C2ON_bit = 0;



     while (1) {
          ADC_niva = ADC_Read(2);          //Läser värde från 'AN2'
          ADC_niva = (488*ADC_niva)/100;      //Får spänning i mV

           if (ADC_niva >= 1000) {
              PORTB = 0xFF; // PortB - LEDs light up
              PORTC = 0x00; // PortC - LEDs off

           } else if (ADC_niva <= 5000) {
             PORTB = 0x00; // PortB - LEDs light up
             PORTC = 0x00; // PortC - LEDs light up

           }
      }
}

Där är koden som jag använder mig av nu, när jag testar så gör jag så att jag får ut av avståndsmätaren: 1.7V minst (dubbelkollar med multimeter).

Enda jag kunde se var om ADC_read(2) kanske innebar AN3 (då den kanske börjar på 0) men nope.

[Pajn]

Först och främst sätter du hela PORTA till ingång men du har bara kopplat in en pinne (eller tre om pickit har pullup/down på PGC och PGD när de inte används och du har flyttat mätaren till AN2). Du bör aldrig sätta mer pinnar än de som faktiskt används till ingång.

Nu orkar jag inte kolla databladet, men är du säker på att

Kod: Markera allt

     ANSEL = 1;    // AN pinnarna görs analoga
     ANSELH = 1;
     C1ON_bit = 0; // Avaktivera comparatorerna C2ON_bit = 0;

Ger det resultat du önskar?

Om du inte har flyttat avståndsmätaren till en pinne som inte används av programmeraren, gör det, det kommer spara dig en massa bekymmer.

Om jag inte minns helt fel läser ADC_read från den AN du anger som argument så ADC_read(2) borde läsa från AN2.

[fireas]

ANSEL gör så att porten/portarna blir analoga
ANSELH gör så att de andra blir digitala om man skriver ANSELH=0; nu skrev jag 1 för att ha alla analoga for now.

Komparatorerna vet jag inte varrför de måste stängas av men eftersom jag inte behöver de så stänger jag av de och har sett flera program använda sig av detta.

Har bytt till en som inte används, AN2 används ej. bara jag som kopplade fel innan:$

[sodjan]

"ANSEL=1" kanske fungerar men även om det gör det så är det helt galet
sätt att skriva på det sättet. Har du alls kollat på ANSLx registren i databladet ?
"ANSEL = 1" är sannolikt samma sak som "ANSEL = b'00000001', vilket
nog inte är det önskade resultatet.

Sätt alltid register där de olika bitarna har individuella funktioner
(och alltså inte bara är del av ett "registervärde") *binärt* !
Exakt hur du skriver binära värden vet jag inte, RTFM.

För att göra det ändå tydligare och lättläst, så skulle jag först cleara hela
ANSEL/ANSELH och sedan använda bit-funktioner mot de aktuella ANSx bitarna,
hur man nu skriver det. T.ex först ANSEL = 0 och sedan ANSEL.ANS2 = 1.
Det blir väldigt tydligt, du sätter bara samma ANSx bit/bitar som den/de ANx
pinne/pinnar som du vill använda.

Instämmer om "öppna oanslutna CMOS ingångar". Det är alltid
en absolut NO-NO, oavsett vad det är för CMOS kretsar.

> Om du inte har flyttat avståndsmätaren till en pinne som inte används
> av programmeraren, gör det, det kommer spara dig en massa bekymmer.

Ja, det har jag kommenterat 2 eller 3 gånger redan, men det verkar ha varit
så viktigt att läsa just de delarna av tipsen...

> Varför komparatorerna skulle behövas avaktiveras vet jag inte,...

Jo, det vet du. Det framgår av databladet.

> ...fick det sagt till mig för ett bra tag sedan...

Jag tror inte att det gällde just 16F690. T.ex en 16F628A (som var en populär modell och som
många tips-på-nätet gäller för) så finns ingen ADC utan enbart komparatorer, och då blir
det mer rellevant att tala om att "stänga av komparatorerna". På en 16F690 så räcker det
med att stänga av (alla) analoga funktioner via ANSEL/ANSELH (förrutom den pinne man ska
använda så klart). Jag tror inte att komparatorerna är på efter en reset.

Notera att det inte är *fel* att ändå sätta komparator konfigurationen så som man vill
ha det, även om det är samma som reset-värdet. Det visar bl.a att man i alla fall
har tänkt på den delen!

[fireas]

Så du anser att det är bättre att skriva ( jag kommer att använda avst.mätare men vi säger en för tillfället) :

Kod: Markera allt

ANSEL = 0;        // "Clear"
ANSEL = 0x04;   // AN2 analog
ANSELH = 0;     // Resten digitala

Det är mer korrekt att skriva så men kan det vara det som får mitt program att inte fungera som det ska. PICen får in värdet 1.7 V vilket är mer än 1000mV i programmet men får ingenting ut på porten till dioderna

[sodjan]

Nja, i just det där exempel så är ju första raden helt onödig.
Tanken var att du sätter enbart bit ANS2 i ANSEL med en bit-operation.

Och som sagt, det blir tydligare om du anger värdet binärt istället för i HEX.

[fireas]

ah du menar

ANSEL.ANS2 = 1; eller typ ANSEL = b'00000100'?

[sodjan]

Ja, om det nu är så man skriver i MikroC.
Antingen

ANSEL=0;
ANSEL.ANS2 = 1;

eller bara
ANSEL = b'00000100';

Och igen, med reservation för hur det skrivs i MikroC...

Men nu så talar vi ju inte längre om funktion utan om sätt
att skriva det hela. Allt ger ju samma slutresultat.

Hur gick det med AN0/AN2 förväxlingen ?
Har det hoppas igång ?