PIC16F690 AD problem

[jfri]

> inga andra pinnar förutom Vcc och GND används

OK. Du bör genrellt inte ha oanslutna pinnar som ingångar.
Inte säkert (eller end sannolikt) att det är problemet, men
gör det til en vana. "Open CMOS inputs" är en no-no.

> Poten är på 100 k men AD ser väl 2.2K motståndet så spelar dess värde någon roll?

Osäker på hur impedanser beräknas i det fallet. Men jag tror inte att det är det.

> Så +5V och +12V är helt separata.

Men med gemensan GND hoppas jag.

> Då jag har en PICkit 2 med ett demo kort (Low Pin Count Demo) som använder AN0 och
> som också har ett bifogat demo exempel för att visa ADC. Jag körde helt enkelt detta
> demo program som läser AD0 och även här sker ett signifikant spänningsfall över 1 k resistorn.

OK. Nu börjar det likna något!
Vilket av demo programmen var det ?
Jag kan köra samma på kontoret så får vi se...

> Så är verkligen spänningsfallet över motståndet som kopplas till ADC onormalt?

Ja, jag tycker nog det. ADC-ingången ska inte dra någon större ström. Och om det
sitter ett 1 k motstånd även på PICkit2 kortet så, tja...

En fråga, är det samma 16F690 som du kör både i din egen koppling
och på PICkit2 kortet ? Och i så fall, har du någon extra 16F690 ?

Ja gemensam GND. Demoprogrammet ifråga är LPC Demo board Lesson 4 Analog to Digital. Det är två helt olika PIC16F690 (har köpt en extra för att slippa byta). En annan sak jag glömde angånde använda stift. Mit prototyp kort är kopplat till PICkit 2 på precis samma sätt som på Low Pin Count Demo kortet. Denna är ju ansluten till AD0 (RA0). Kan detta orsaka spänningsfallet över 1 k motståndet? (nej det är inget 1M motstånd utan brun svart svart brun brun).
Nu har jag gjort ytterligare ett test. Modifierade Lesson 4 demoprogrammet genom att lägga till kod för att skriva ut erhållet ADC värde. Och nu verkar avläst ADC värde stämma bättre med teoretiskt förväntat. Men det flukturerar fortfarande en del (betydligt mer än med Low Pin Demo kortet). Det blev lite bättre när jag kopplade in en 0.1 uF kondensator före 1 k motståndet.
Slutligen en bild på hur prototyp uppkopplingen ser ut
[img]

prototyp.JPG

[/img]

[sodjan]

Det är alltså Demo 4 (ADC.ASM) som du menar ?
Jag körde just den också och får också oväntat stort spänningsfall över det 1k ohm
motstånd som sitter på labbkortet (med 16F690). Jag gjorde lite justeringer i koden
men kom inte runt det. Det är väldigt märkligt, en ADC ingång borde dra marginelt
med ström, det enda som är specat i databladet är läckströmmen på ett par uA...

Jag har just lagt en fråga till PICLIST så får vi se om det är något fundamentalt
hjärnsläpp det handlar om...

[ghu]

Problemet är att AN0/RA0 också används vid ICSP av PICKIT2. Om man tittar på schemat för PICKIT2 så ser man att det på ICSPDATA utgången sitter ett 4.7 kohms motstånd till jord vilket ger upphov till en ström på lite under 1 mA då man vrider labkortets potentiometer mot 5V sidan. Konstruktören av Low Pin Count Demo Board måste ha haft hjärnsläpp då han använt AN0 som analog ingång eftersom AN0/RA0 samt AN1/RA1 används av PICKIT2 vid programmeringen.

Göran

[sodjan]

ARGH !!!!

Jäkla röra på databladen hos Microchip...
Det jag tittade på var ett annat "demo kort".

Självklart är det så att AN0 på 16F690 delar pinne med ICSPDAT !
Och eftersom ICSPDAT har en pulldown på 4.7 kohm internt i PICkit2
så får man detta fel. Demokortet behöver kopplas bort från PICkit2
och ha en separat 5V matning.

Och självklart blir det samma problem om man bygger ett separat kort
där man också har PICkit2 kvar inkopplad...

> Konstruktören av Low Pin Count Demo Board måste ha haft hjärnsläpp

Absolut...

[ghu]

jfri skrev:
> Ett kommersiellt demo kort med tillhörande demo program borde väl rimligen inte innehålla fel särskilt inte fundamentala?

Att kommersiella produkter skulle vara befriade från fundamentala fel är ett önsketänkande.
I fallet med Low Pin Count Demo Board så finns det ett verkligt fundamentalt fel som gör att programmeringen från PICKIT2 kan vara mycket osäker.
Det fundamentala felet är att om man vrider potentiometern till ändläget som ger ca 5 V till AN0 så är det mycket osäkert att PICKIT2 klarar att leverera en säker "nolla" till 16F690 under programmeringen. Skälet är att internt i PICKIT2 finns det ett 100 ohms motstånd i serie med ICSPDAT utgången. Då PICKIT2 skickar ut en "Nolla" kommer det att ligga ca 0.5 V över detta motstånd p g a 1 kohms motståndet på Demo board som i detta läge är kopplat till +5 V. Dessa 0.5 V adderas till spänningen över utgångstransistorn i processorn i PICKIT2 (Kan vara upptill 0.3 V i värsta fall) vilket gör att spänningen in till RA0 på 16F690 är nästan 0.8 V. Då RA0 använder TTL nivåer så är störmarginalen obefintlig eller mycket liten vilket gör att programmeringen blir osäker.
Slutsatsen är att om man vill att Low Pin Count Demo Board ska fungera på ett säkert sätt så bör man flytta utsignalen från potentiometern till en annan ingång än AN0/AN1!

Hälsningar
Göran

[sodjan]

> ...så bör man flytta utsignalen från potentiometern till en annan ingång än AN0/AN1!

Eller vrida poten i ett annat läge...

Jag hade faktiskt förbisett denna miss i konstruktionen av just det labb-kortet.
Ber om ursäkt eftersom tråden fick några inlägg i onödan, så att säga...

Sen så är det sannolikt så att det inte hade blivit så här om just kortet med
16F690 hade varit det första labb-kortet till PICkit2. Nu fanns det tidigare ett
kort med 16F886 som är väldigt likt och där poten också sitter till AN0 men som
har ICSPDAT/CLK till RB6/7. Det verkar som att de help enkelt missade denna detalj
när de "portade" konstruktionen till 16F690. En jäkla miss likafullt, så klart...

[jfri]

jfri skrev:
> Ett kommersiellt demo kort med tillhörande demo program borde väl rimligen inte innehålla fel särskilt inte fundamentala?

Att kommersiella produkter skulle vara befriade från fundamentala fel är ett önsketänkande.
Hälsningar
Göran

Ja faktiskt. Jag hittade ett klart fel i assembler koden för demo programmet ifråga. Så här testar de om ADC är klar

Kod: Markera allt

     bsf       ADCON0,GO      ; start conversion
     btfss     ADCON0,GO      ; this bit will change to zero when the conversion is complete
     goto      $-1

[sodjan]

Jag har faktiskt haft som tanke att gå igenom de 11 demoprogrammen och "snygga till" dom en del.

Jag förstår t.ex inte varför man t.ex använder BCF/BSF direkt mot RP0/1 i STATUS istället för
att använda BANKSEL. Visst, det kan vara bra att veta hur det igentligen fungerar och vad
BANKSEL igentligen gör "under the hood", men det kan man fixa på annan sätt t.ex via
tydliga referensen i dokumentationsdelen av koden (högst upp) till manualerna och vilka
kapitel som ska/bör studeras i samband med att man tester den aktuella koden.

En annan sak är varför de använder konstruktioner med "$" i GOTO istället för att den
snyggare lösningen med labels. $ är inte bara otydligt, det är även en dold bugg
i det fall att man vill porta kod från PIC16 till PIC18.

Det finns fler saker som är onödigt opedagogiska för att vara i en demo program/utbildnings kod
(t.ex att sätta oanvända/öppna pinnar som ingångar).

Eftersom dessa koder ofta är det första som en nybörjare kommer i kontakt med så är det väldigt
lätt att man plockar med sig dåliga vanor in i sina egna koder senare, vilket är lite onödigt...

[Variosboy]

För att inte tala om all bortkomenterad kod som fortfarande finns kvar i övningarna..
Sen är ju strukturen rent språkmässigt ganska dålig, tex inkonsekvens i användning av olika ord för samma sak, gramatik osv.

[sodjan]

Är det en svensk som har skrivit det ?

Kod: Markera allt

     bcf       STATUS,RP0     ; address Register Page 2
     bsf       STATUS,RP1     
     movlw     0xFF           ; we want all Port A pins Analoga
     movwf     ANSEL

[jfri]

Nu tycks bara ett problem återstå. Fortfarande så får jag avlästa värden som avviker en del från det teoretiskt beräknade. Detta får jag inte om jag kör demoprogrammet från lektion 4 på mitt prototyp kort. Men mitt eget C program uppvisar detta fel vilket jag inte begriper. Mitt C program fn

Kod: Markera allt

#include <htc.h>
#include "variabler.h"
#include <stdlib.h>
#include <stdio.h>
#include <stdarg.h>
#include <ctype.h>
#include "usart.h"


#define	_XTAL_FREQ	4000000L

#define	TRUE	1
#define	FALSE	0

void  ReadSensors();

__CONFIG(INTIO & WDTDIS & PWRTDIS & BORDIS & UNPROTECT);

void init(void)
{
// port directions: 1=input, 0=output
TRISA = 	0b11111111;
TRISC = 	0b10010000;
IOCA	=	0b00100000;
PIE1 = 		0b00000001;
INTCON = 	0b01001000;
OPTION = 	0b10000000;
T1CON = 	0b00110101;
ANSEL=	0b11111111;
ANSELH=   0b11110111;
ADCON0  =0b10000001;				//result right adj ADC on (CH=0)
ADCON1 = 0b00010000;				//fosc/8 X101XXXX
init_comms();
}

void main(void)
{
	int	Ubak,Ibak;

	init();
	ReadSensors();
	Ubak=senvalues.Uadcraw;
	Ibak=senvalues.Iadcraw;	
	printf("U=%d I=%d\n\r",senvalues.Uadcraw,senvalues.Iadcraw);

	do
	{
	ReadSensors();
	if (Ubak!=senvalues.Uadcraw || Ibak!=senvalues.Iadcraw)
		{
		printf("U=%d I=%d\n\r",senvalues.Uadcraw,senvalues.Iadcraw);
		Ubak=senvalues.Uadcraw;
		Ibak=senvalues.Iadcraw;
		}
	} while (TRUE);
}

readmeters.c
#include <htc.h>
#include "variabler.h"
#define	_XTAL_FREQ	4000000L

int		read_adc(unsigned char channel)
{
ADCON0 &= 0b11000001;
ADCON0  |= (channel<<2);
__delay_us(5);
GODONE=1;								// initiate conversion on the selected channel
while(GODONE)continue;
return	(ADRESL | (ADRESH<<8));
}

void	ReadSensors()
{
	char	i;

	for (i=0;i<16;i++)
	{
	senvalues.Uadcraw += read_adc(0);
	senvalues.Iadcraw  += read_adc(1);
	}
	senvalues.Uadcraw = senvalues.Uadcraw>>4;
	senvalues.Iadcraw  = senvalues.Iadcraw>>4;	
}	
variabler.h
char	PRINTOUT=0;
char	SWITCH	=0;

struct	sendata
{
	int		Uadcraw;
	int		Iadcraw;
}	senvalues;	

[sodjan]

> Fortfarande så får jag avlästa värden som avviker en del...

Och vad exakt betyder "en del" i din värld ?
Var gärna exakt i dina beskrivningar och undvik rellativa begrepp som
"mycket", "lite", "en del" o.s.v.

Dessutom är det intressant att veta vilken felsökning du har gjort själv.
T.ex om du har provkört med enbart en ADC kanal ?
Får du då fortfarande samma fel ? D.v.s att det "avviker en del" ?

Om du har samma spänning på båda kanalerna, får du då fortfarande samma fel ?

Tar "read_adc()" hänsyn till "acquisition time" vid byte av ADC-kanal ?
(Min *gissning* just nu är att svaret är "nej" och att det är det som du ser,
men det måste testas praktiskt i din kod och koppling.)

[jfri]

Erhållet värde 479 och teoretiskt beräknat 448. Ja samma fel om bara en kanal läses

[sodjan]

> Erhållet värde 479 och teoretiskt beräknat 448.

Hur stabilt är det erhållna värdet ?
Slår det några enheter upp och ner ?
Det är helt normalt, vill bara kolla så att det verkligen kommer
från ADC modulen. Är det däremot helt stabilt på 479 så skulle
jag bli misstänksam.

OK, men du får (ungefär) 448 om du kör med demo programmet ?
På samma hårdvara som du kör ditt eget program på ?
I så fall skulle jag studera de två programmen och se vad de
gör olika.

Det hela handlar bara om att fokusera på skillnanderna mellan
programmen för att till slut hitta varför de ger olika resultat.

Prova med att bara göra en direkt C-översättning av demo programmet
och se vad *det* ger. O.s.v...

Ah, såg nu att read_adc() ju finns med i C koden...
Har du provat med att öka "__delay_us(5);" till något längre ?
Det är alltså det som ska hantera "acquisition time" ? Jag har inte
kollat att just 5 us är tillräckligt, men det är det kanske.

[jfri]

Hittade problemet. Genom att lägga till nedanstående två rader före for loopen så får jag förväntade värden +-1. Istället för att addera 16 värden så adderade 16 + det sista
tidigare erhållna värdet medelvärdet dvs totalt 17. Klart att värdena blir något för höga

Kod: Markera allt

	senvalues.Uadcraw=0;
	senvalues.Iadcraw=0;