Blinkande LED, med C

Torsten · Inlägg av **Torsten** » 21 augusti 2009, 23:48:06

Hej.
Jag har försökt koda blinkande LED, alla fyra, från mitt demokort köpt på kjell. Har en PIC 16f690, plus kortet naturligtvis.
Jag använder MPLAB för att skriva och kompilerar med HI-Tech's C compilator.
Problemet jag har är att lamporna bara lyser (eller blinkar väldigt fort). Har jag gjort något fel? Om jag använder en simulator (http://www.oshonsoft.com/pic.html ser allting ut att fungera som det ska (PORTC växlar mellan hög och låg).

Jag har testat med olika typer av delays, både for-loopar, _delay-funktionen och andra "färdigbyggda" som jag hittat på nätet, men LEDsen lyser konstant (vad det ser ut som iaf). Jag har även testat att PORTC = 0; verkligen slår av LED, eller rättare sagt inte slår på.

Följande är min kod:

Kod: Markera allt

#include <htc.h>

main(void)
{
		int i;
		TRISC = 0;      //Output
		
	   while(1) {      //Loop

	      PORTC = 0xff;
	      _delay(100);
	      PORTC = 0;
	      _delay(100);
	  			}
}

Det känns som om jag gjort något enkelt misstag, någon som ser vad? Tacksam för hjälp.
En annan fråga, det ska tydligen finnas en funktion som heter delay_ms(); men som kräver delay.c, är det en klass jag skriver själv? (mindre viktig fråga).
Tack på förhand!

sodjan · Inlägg av **sodjan** » 21 augusti 2009, 23:59:07

Vad gör funktionen _delay() mer specifikt ?
Vad betyder t.ex parametern ("100" i ditt exempel) ?

Om du undrar vad som blev av C koden så är det bara att kolla
i assembler listningen. Då ser du svart på vitt vad koden gör igentligen.

> men som kräver delay.c, är det en klass jag skriver själv? (mindre viktig fråga).

Vad är en "klass" ?
(Jag vet var en "klass" är i objektorienterade språk, men det har ju ingenting med C att göra
så det borde vara något annat du menar...)

Hittade du ingen delay.c ?
Om du gör det så borde den läggas till till projektet.

E85 · Inlägg av **E85** » 22 augusti 2009, 00:29:28

_delay(100) väntar 100 cykler, så det går alldeles för snabbt för att du ska se det. Prova __delay_ms(100) istället.

watti · Inlägg av **watti** » 22 augusti 2009, 01:06:52

Nu kan jag inte massor om detta, men är de inte så att du glömt att definera allt, hur snabbt klockan ska gå osv?
Typ:

Kod: Markera allt

#include <htc.h>
__CONFIG(INTIO & WDTDIS & PWRTEN & MCLREN & UNPROTECT & UNPROTECT & BORDIS & IESODIS & FCMDIS);
#define FOSC 8000000L
#define   delay_us(x) { unsigned char us; us = (x)/(12000000/FOSC)|1; while(--us != 0) continue; }

/////////////////////////////////////////////////////////////////////////////////////////

void delay_ms(unsigned int ms)
{
	unsigned char i;
	do 
	{
		i = 4;
		do 
		{
			delay_us( 164 );
		} while( --i );
	} while( --ms );
}

/////////////////////////////////////////////////////////////////////////////////////////

void init(void) 
{
	// OSCILLATOR
	OSCCON = 0x70;         // Select 8 Mhz internal clock
	// UNUSED FEATURE DISABLE
	ADON = 0;
	ANSEL = 0;
	ANSELH = 0;
	// PORT I/O STATES

	TRISC = 0b00000000;
}


/////////////////////////////////////////////////////////////////////////////////////////

void delay_ms(unsigned int ms)
{
	unsigned char i;
	do 
	{
		i = 4;
		do 
		{
			delay_us( 164 );
		} while( --i );
	} while( --ms );
}

/////////////////////////////////////////////////////////////////////////////////////////

void main(void)
{

	init();
	
	for( ;; )
	{
	PORTC = 0b11111111;
	delay_ms(200);
	PORTA = 0b11111111;
	delay_ms(200);
	PORTC = 0b00000000;
	delay_ms(200);
	PORTA = 0b00000000;
	delay_ms(200);
	}
	 
} // Slut

/////////////////////////////////////////////////////////////////////////////////////////

Detta fungerar i alla fall på min, exakt likadan

Torsten · Inlägg av **Torsten** » 22 augusti 2009, 10:19:57

Tack för svaren. Jag löste det genom följande:

Kod: Markera allt

#define _XTAL_FREQ  4000000
#include <htc.h>
void main(void) {

   OSCCON  = 0x60; 
   ANSEL   = 0;

   TRISC = 0;      //Output
   while(1) {       //Loop

      PORTC = 0xff;
      __delay_ms(197);

      PORTC = 0;
      __delay_ms(197);
  }
}

Fick dock inte den delay.c jag hittade att fungera. Hur lägger jag till så att kopilatorn hittar biblioteket automatiskt?

bos · Inlägg av **bos** » 22 augusti 2009, 12:32:43

Hitech C har inga delay-funktioner. Du får skriva dem själv.

Och jag förstår inte varför ingen hittills kommenterat det uppenbara grovfelet med din kod. Du har inte angett några config-bitar över huvudtaget. Räkna inte med att få förutsägbart beteende på processorn efter omprogrammering!

Config-bitarna anger du med makrot __CONFIG(), och för att ta reda på vilka flaggor du ska använda läser du header-filen för den processor du valt. I ditt fall är det filen pic16f685.h.

Glenn · Inlägg av **Glenn** » 23 augusti 2009, 01:59:42

beror ju på vilken programmerare man har iofs, nu gissar jag förvisso på pickit2, men på min multiprogrammer jag körde innan så fick man sätta alla bittarna i programvaran själv, den struntade helt i vad hexfilen sa.

Nu när jag kör pickit2-mjukvaran så "måste" jag ju sätta alla configbittar i koden förstås.

PeterSfa · Inlägg av **PeterSfa** » 29 augusti 2009, 20:42:18

bos skrev:Hitech C har inga delay-funktioner. Du får skriva dem själv.

Nja, enligt Hi-Tech C manualen så finns dessa:
void _delay(unsigned long cycles);
void _delay3(unsigned char cycles);

Men är det inte bättre att trigga detta med en timer?
Iaf i min PC värld så stoppar en delay exekveringen och det är oftast inte det man vill i PC världen iaf.
Jag sitter 8 timmar om dagen med C/C++ på PC därav mitt antagande.

Icecap · Inlägg av **Icecap** » 29 augusti 2009, 20:47:17

Självklart är detta ett fall för en timer-funktion, helst en timer-interrupt. Det är dock inte alla som anser att man ska ta till "tunga" sätt att lösa "blinka LED" när det är mycket nybörjarfrågor.

Men som i så många andra trådar: du får svar som du frågar, personligt tycker jag att det är kass stil att fråga en sak och när svaren börjar komma lägger man in ytterligare information som kan vara vital för att hitta den rätta lösningen för frågaställaren.

bos · Inlägg av **bos** » 29 augusti 2009, 20:51:57

PeterSfa skrev:Jag sitter 8 timmar om dagen med C/C++ på PC därav mitt antagande.

Det där var ett så befängt antagande att det finns inte.

PeterSfa · Inlägg av **PeterSfa** » 29 augusti 2009, 20:55:22

bos skrev:
PeterSfa skrev:Jag sitter 8 timmar om dagen med C/C++ på PC därav mitt antagande.
Det där var ett så befängt antagande att det finns inte.

Ok, nu förstod jag inte ?
Trött kanske.

sodjan · Inlägg av **sodjan** » 29 augusti 2009, 23:39:22

Jag tror att det bos menar är att det skilljer så pass mycket mellan
"PC-programmering" och "PIC-programmering" så att erfarenheter
från det ena inte har så stor rellevans för det andra.

> Iaf i min PC värld så stoppar en delay exekveringen

Det tror jag inte alls att det gör, varken på en PC eller i en PIC.
Om exekveringen *stoppades* så skulle den aldrig komma ur delay
funktionen eftersom det är en programvaru-delay.

*Däremot* så brukar delay funktioner förhindra att man gör något annat
under tiden, men det är ju en helt annan sak...

PeterSfa · Inlägg av **PeterSfa** » 30 augusti 2009, 10:43:22

sodjan skrev:Jag tror att det bos menar är att det skilljer så pass mycket mellan
"PC-programmering" och "PIC-programmering" så att erfarenheter
från det ena inte har så stor rellevans för det andra

Det var därför jag ursäktade mig med att jag normalt sitter med PC programmeringen och mycket väl kan ha missat en rudimentär punkt inom processor programmeringen.
Jag var antagligen för trött att se den vinklingen.

sodjan skrev: > Iaf i min PC värld så stoppar en delay exekveringen
Det tror jag inte alls att det gör, varken på en PC eller i en PIC.
Om exekveringen *stoppades* så skulle den aldrig komma ur delay
funktionen eftersom det är en programvaru-delay.

*Däremot* så brukar delay funktioner förhindra att man gör något annat
under tiden, men det är ju en helt annan sak...

Ja det är en stor skillnad när jag tänker på det ur processor synpunkt. Jag är ju som sagt helt grön på den delen.

På PC så innebär det på den nivån ett exekveringsstopp av min egen programkörning. D.v.s. ingen annan del av min kod kan köras. Om inte jag själv delar upp deley i flera små delar i en loop och kallar på processmessages() i varje loop.
Numera är det ju så sällsynt att man är så processornära att man tänker på exekveringen av deley()

Men min fråga i påståendeform håller iaf även inom pic programmeringen?
deley medför ett stopp i din körning.
Hur hårt?
Medan den sitter i deley(), hindrar den ev interupt? Borde inte göra det, men bäst att fråga er som har erfarenhet.

bos · Inlägg av **bos** » 30 augusti 2009, 10:58:47

PeterSfa skrev:Ja det är en stor skillnad när jag tänker på det ur processor synpunkt. Jag är ju som sagt helt grön på den delen.

Du är helt grön, ändå kommer du med gissningar om saker du inte har en aning om? Det får du allt sluta med. Det är *stor* skillnad på att utveckla OS-applikationer jämfört med att direkt banga på hårdvara.

PeterSfa skrev:Numera är det ju så sällsynt att man är så processornära att man tänker på exekveringen av deley()

Sällsynt? Denna tråd ligger under "Mikroprocessorer". Här hackar vi på mikronivå. Det är så processornära det kan bli.

PeterSfa skrev:deley medför ett stopp i din körning. Hur hårt? Medan den sitter i deley(), hindrar den ev interupt? Borde inte göra det, men bäst att fråga er som har erfarenhet.

Du bestämmer själv hur hårt det ska stoppas. Du bestämmer själv om du ska strunta i interrupts eller inte. Har du globala interrupts påslagna samt det kommer ett interrupt från en enhet som du har maskat, så genomförs givetvis interruptet (under förutsättning att du läser av det, förstås).

Ett generellt tips för att du ska få enklare att lära dig programmera hårdvara (vilket jag antar du vill nån gång i framtiden) är att åsidosätta allt som har med högnivå att göra. Glöm ett OS som städar upp efter dig. Glöm att abstrahera. Glöm OOP. Du själv har kontroll över allt, men det kräver att man tänker på en helt annan nivå än "vanlig" mjukvaruprogrammering.

PeterSfa · Inlägg av **PeterSfa** » 30 augusti 2009, 11:16:49

bos skrev:Sällsynt? Denna tråd ligger under "Mikroprocessorer". Här hackar vi på mikronivå. Det är så processornära det kan bli.

Jo det inser jag, mitt påstående var mot PC progammeringen.

bos skrev:Ett generellt tips för att du ska få enklare att lära dig programmera hårdvara (vilket jag antar du vill nån gång i framtiden) är att åsidosätta allt som har med högnivå att göra. Glöm ett OS som städar upp efter dig. Glöm att abstrahera. Glöm OOP. Du själv har kontroll över allt, men det kräver att man tänker på en helt annan nivå än "vanlig" mjukvaruprogrammering.

Det har jag insett och därför jag hittade hit. Det behövs påminnelser på den sidan.

Och på antagandet om jag vill. Jag lämnade elektroniken för 25 år sedan och har i pricip bara suttit "skyddad" av OS under den tiden på applikatonsprogrammering PC.
För två veckor sedan bestämde jag mig för att ta upp det igen. Hämtade upp min gamla labblåda från källaren.
Och sedan i Onsdags införskaffat programmerare och kretsar.
Så jag är på väg

Jag kan bara tacka för alla hjälp att komma på rätt spår här.

Men nu blev det offtopic tror jag, ledsen.

Edit (onttopic):
Blinkande LED var precis det jag provade det första jag gjorde när jag fick igång min 18F4550 på mitt labbbord. Och följde exemplet från just Hi-Tech C med _delay().

Det som direkt slog mig var att de räknar upp en char i counter och sätter den till PORTB=counter och säger att den får led att blinka. JO det gör den, men med tanke på att ++ också sätter övriga bitar i en char, så påverkar den alla pinnar på port B. Just delay skippade jag omgående till förmån för timerinterrupt som jag hittade i manualen.
Så mitt inhopp var mer för att få bekräftelse att jag tänkte i rätt riktning.
Jag skall ta det från ASM sidan också, det var bara enklare att det från C hållet då jag känner mig mer hemma i det.

Blinkande LED, med C

Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C

Re: Blinkande LED, med C