PIC18f4550 ADC problem

[thepirateboy]

Finns nog många funktioner på nätet om hur man omvandlar en integer till ett ascii array. Här är en liten snutt jag brukar använda för att omvandla en uint till ascii

void ConvertUintToAscii(unsigned char *array, unsigned int data)
{
array[0] = data/10000 + '0';
data %= 10000;
array[1] = data/1000 + '0';
data %= 1000;
array[2] = data/100 + '0';
data %= 100;
array[3] = data/10 + '0';
array[4] = data%10 + '0';
}

[sodjan]

> Efter mycket sökande i mikroc:s forum och här så hittar jag inget om hur
> jag kan omvandla exempelvis en integer till ett ascii array.

Jag tycker att det är väldigt märkligt att du inte nämner manualen !
För du måste väl ha kollat där, det är ju första stället att kolla, eller hur ?

T.ex under "Conversion Library" -> "Library Routines".
Inget där som passar ? "IntToStr" t.ex ??

[[ALV]]

tack för svaren!

>> Efter mycket sökande i mikroc:s forum och här så hittar jag inget om hur
>> jag kan omvandla exempelvis en integer till ett ascii array.
>
>Jag tycker att det är väldigt märkligt att du inte nämner manualen !
>För du måste väl ha kollat där, det är ju första stället att kolla, eller hur ?
>
>T.ex under "Conversion Library" -> "Library Routines".
>Inget där som passar ? "IntToStr" t.ex ??

sodjan självklart har jag tittat i manualen
det betyder dock inte att det är solklart för det, jag undrar vad skillnaden mellan ByteToStr och IntToStr är, eller snarare vad är skillnaden mellan byte och int?
[EDIT] insåg det självklara att en byte är betydligt mindre än en integer, därmed så fick jag mina konstiga resultat när jag använde ByteToStr, med intToStr så får jag ett värde mellan 0-1023 =)

>> det har nog med att göra att jag inte skickar resultatet som ascii.
>
>Varför spekulera? Det är rätt uppenbart varför det blir fel: Din USART_Write() som du inte har källkod till tar med stor sannolikhet emot en char som parameter, medan >ditt ADC-värde ligger i en int. Varför du får fel värde i överföringen kan du nog lista ut själv.

point taken, jag skickar med min kod så ser ni vad jag har gjort, men jag tror mig inte skicka en integer till Usart_write() som enligt manualen SKA klara en int om jag förstår sidan 331 i manualen http://www.mikroe.com/pdf/mikroc/mikroc_manual.pdf

min kod:

Kod: Markera allt

unsigned int i = 0;
unsigned int adc_res = 0;
unsigned char msg[15];

int my_adc_read() {
		ADCON0.F1 = 1;      // start adc
		while(ADCON0.F1) {
		}
	//return (ADRESH * 256) + ADRESL;
	return (ADRESH << 8) | ADRESL;
}

void main() {
	Usart_Init(9600);
	TRISA  = 0xFF;     // PORTA is input
	ADCON1 = 0b00001101;    // Use vss vdd as vref, set an0, an1 to analog input
	ADCON0 = 0b00000001;    // Use an0 for adc
	ADCON2 = 0b10111110;	// Right just

	PORTD = 0;
	TRISD = 0;
	PORTD.F2 = 1;
	Delay_ms(2000);
	Usart_Write(101);   // startup message

	while(1) {
		adc_res = my_adc_read();

		intToStr(adc_res,msg);
		for(i = 0; i < 15; i++) {
			if(msg[i] != 32) {
				Usart_Write(msg[i]);
			}
		}
		Usart_Write(10);	// LF
		Usart_Write(13);	// CR

		PORTD.F2 = 1;       // Blink a led
		Delay_ms(100);
		PORTD.F2 = 0;
		Delay_ms(100);
	}
}

Problemet var alltså att jag gjorde om en int till en str med hjälp a byteToStr som orsakade problemet, med detta åtgärdat så fungerar det perfekt!
Stort tack till alla som svarat!


Nästa sak jag tänkte försöka göra är att få min Ultrasonic range finder att fungera korrekt, men detta börjar gå off topic så jag antar att jag får starta en ny tråd om jag behöver hjälp?

(PS: finns det något roligare än att sitta och labba på midsommarafton? hehe )

[jojje]

Jag för min del förstår inte att du inte ens provade med IntToStr på egen hand.
Du hade det ju under näsan hela tiden, så...

Det börjar inte ryka så lätt.

[bos]

men jag tror mig inte skicka en integer till Usart_write()

Får jag föreslå att du slutar tro och gissa saker och ting? Tidigare hade du i = (ADRESH << 8) | ADRESL; Usart_write(i);, du visade aldrig någon kod där du använde byteToStr();. Om du faktiskt använde den funktionen vet ju inte vi. Du kan inte köra en kod och fråga om hjälp för en annan, det blir bara pannkaka av allt då.

som enligt manualen SKA klara en int

Sid 331 som du hänvisar skriver att prototypen för funktionen är "char Usart_write(char data);", och förklaringen är "Function transmits a byte (data)". Hur du tolkar detta som att funktionen klarar en int får stå för dig själv. Kolla på sid 76 för storleken på de olika datatyperna.

Det som händer i ett fall som detta då en funktion tar en char / 8-bit som argument och man skickar in en int / 16-bit är att kompilatorn castar om parametern. Hur mikroC gör orkar jag inte leta upp i manualen, men de flesta kompilatorer klipper helt enkelt bort de högre 8 bitarna i int:en så att den blir en char, och skickar sen in det återstående i funktionen. Denna klippning kallas för en cast.

Varför mikroE själva använder en int i deras funktionsexempel för Usart_write() är för övrigt ett ytterligare bra bevis på varför man ska undvika allt som har med mikroelektronika att göra...

[[ALV]]

>Varför mikroE själva använder en int i deras funktionsexempel för Usart_write() är för övrigt ett ytterligare bra bevis på varför man ska undvika allt som har med mikroelektronika att göra...
du har helt rätt, jag borde kanske sagt att det var exemplet jag syftade på.

[sodjan]

> till Usart_write() som enligt manualen SKA klara en int om jag förstår sidan 331 i manualen

Men sannolikt så använder den bara den lägste byten i en Int som en char.
Du måste ju läsa hela kodexempelt på 331 så ser du ju det.
Det den sänder tillbaka är ju bara samma som just har lästs från Usart_Read()
och det läser ett tecken. Notera också att kodexemplet på sid 331 *INTE*
använder en Int utan en "unsigned short", vilket är just en byte [0...255].

Deras exempel i tabellen längre upp på sidan är dock lite konstigt, men
det ser mest ut att vara i linje med kvaliten på Mikroelektronikas
dokumentation generellt...
Där säger de "char" i prototypen och "int" i exemplet. Sen har de "short"
i kodexemplet straxt under

Ett problem med Mikroelektronikas dokumentation är att den vid en första
genomläsning verkar fyllig och uttömmande, men om man synar det lite
närmare så är det mycket slarv i detaljerna, t.ex med de tre olika
variabeltyperna på sidan om Usart_write(). För en nybörjare kan detta
bli väldigt förvirrande medan den som har hållit på ett tag ser detta
ganska snabbt.

> därmed så fick jag mina konstiga resultat när jag använde ByteToStr,

ByteToStr ??
Var kommer *det* ifrån ?
Jag minns inte att du har nämnt det alls tidigare !!??

[[ALV]]

bos & sodjan: nej jag har slarvat med att uppdatera med kod om den biten, jag testa en massa saker fram och tillbaka och glömde helt av att jag inte visat det i tidigare kod.

[Icecap]

"short" är faktisk ett 16-bit värde...

"int" är en "slaskvariabel" som har den storlek som processorn jobbar bäst med, kan vara en 8-bit men är oftast 16 bit eller mer.

Men MikroElektronikas produkter är, som många innan har konstaterat, vackra och trevliga - till man kollar ordentligt, då är det strax en lite annan verklighet som visar sig.

[sodjan]

> "short" är faktisk ett 16-bit värde...

Inte i MikroC.

Men du har rätt i att det är olika mellan olika C implemantationer.
Det normala är att i miljöer där en "int" är 16-bitar är en "short" 8 bitar
men i en annan miljö där en "int" är 32 bitar är en "short" oftast 16 bitar...

[Icecap]

Hmmm... läste just min C ref. manual (ISBN 0-13-109802-0) och ja, "short" kan fint vara en byte. "int" kan inte vara mindre än en "short" och inte större än en "long" och en "short" kan inte vara större än en "long" vilket i essens betyder att storleken (antal bytes) faktisk kan vara lika på "short", "int" och "long".

Så portabel kod kan vara skitsvårt att fixa alltså, även i C...

[[ALV]]

Allt detta för att underlätta för nybörjaren

Men men, oavsett hur jobbigt det är så är det klart värt det, att kunna hacka ihop något i java, php eller perl är ju inte riktigt programmering.
hoppas bara ni har tålamod med mina dumma frågor. speciellt du sodjan som alltid varit där och slagit mig på fingrarna när jag glömt självklarheter

nu när vi ändå talar om språk, jag hittade denna sida http://www.mstracey.btinternet.co.uk/pi ... ogtut3.htm och började känna att asm kanske inte är så dumt trotts allt.
Hur gör ni ASM grabbar? kör ni asm rakt igenom oavsett projekt storlek?

[bos]

> Hur gör ni ASM grabbar? kör ni asm rakt igenom oavsett projekt storlek?

Jag använder uteslutande C, och inline-assembler där timing är av största vikt.

[[ALV]]

>> Hur gör ni ASM grabbar? kör ni asm rakt igenom oavsett projekt storlek?
>Jag använder uteslutande C, och inline-assembler där timing är av största vikt.
Vilken kompilator?

MikroC är inte någon favorit verkar det som, vad är allternativen?
Någon med erfarenhet av MPLAB C Compiler eller HI-TECH C Compiler?

[bos]

Hi-Tech PICC, standardversionen. MPC har jag aldrig använt.

Jag rekommenderar dock att inte använda C förrän man vet hur arkitekturen funkar. Går man assemblervägen före C så slipper man alla fallgropar (många av vilka du själv ramlat i i detta projekt).