Sida 3 av 7

Re: PIC, varför inte... går det....?

Postat: 5 april 2015, 16:20:09
av sodjan
> Som att standard för en port är att vara analog, på ett digitalt microchip.

Det är ganska självklart. Det känns dock lite tidigt att gå in på detaljerna.
Tills vidare kan du var lugn med att det är helt naturligt...

När det gäller bankningen så är det en design kompromiss. En avvägning
mellan utrymme i (och storlek på) instruktionerna och minnesutrymme.
Men det är inget större problem, BANKSEL sätter bankerna rätt. Dessutom
är det ett mindre problem på de moderna PIC16F1xxx modellerna, den 690
som du använder är i och för sig en populär modell och mycket PICkit2
material använder den, men den är inte helt modern.

> Om de två första bitarna användes för det, istället för ingenting(?!)...

De används! Dock inte som adressbitar.

Re: PIC, varför inte... går det....?

Postat: 5 april 2015, 17:13:52
av Nerre
Banker använder man väl (idag) främst för att enkelt kunna använda kortare adresser? Förr använde man det även för att adressbitarna inte räckte till för att adressera allt minne.

Om vi enkelt säger att du har en processor med 8-bitars adressbuss så innebär det att varje instruktion som jobbar mot minnet behöver innehålla 8 bitar för att peka ut adressen. Men om du istället delar in minnet i banker (vi kan för enkelhets skull säga 16 banker om 16 adresser) så räcker det med 4 adressbitar i instruktionen för att peka ut vilken adress inom banken som ska adresseras. Nackdelen blir såklart att man innan access måste välja rätt bank med en separat instruktion med 4 ytterligare adressbitar. Men eftersom man i program väldigt ofta bara jobbar mot en liten del av minnet i taget så blir det effektivare att välja bank före en grupp operationer istället för att behöva ha dubbelt så många adressbitar i instruktionerna.

Det blir oftast rätt tydligt om man tittar just på hur instruktionernas OP-koder ser ut. För absolut adressering måste varje OP-kod innehålla så många adressbitar som adressbussen är bred. Med relativ adressering (som kan vara relativt en bank eller ett indexregister eller liknande) kan OP-koderna göras kortare, dock med nackdelen att de inte kan adressera lika stort adressomfång.

Re: PIC, varför inte... går det....?

Postat: 5 april 2015, 19:26:01
av SeniorLemuren
Sedan kan man väl tillägga att det vanligtvis är i Assemblerprogrammering man måste bolla med banker. Vid C och andra högre nivåer håller kompilatorn rätt på det hela.

Re: PIC, varför inte... går det....?

Postat: 12 april 2015, 12:41:01
av Erik M
OK, jag hänger med. Om än chassiet balken, för dragkroken, sitter i inte kommer gå genom nästa besiktning...


Nästa fråga...

Det finns en extern pinne för interna räknesnurran.
Helt fattbart, annars blir det svårt korrelera med externa enheter etc.

Men...!

Om räknesnurran endast används internt - kan då pinnen i sig användas till någon av dess andra funktioner?

Re: PIC, varför inte... går det....?

Postat: 12 april 2015, 12:45:24
av sodjan
Pinnarna har namn, vilken menar du?
Vad enar du med "räknesnurra".
Använd rätt namn för att undvika missförstånd.

Re: PIC, varför inte... går det....?

Postat: 12 april 2015, 13:58:06
av Erik M
OK, jag ska försöka.

Om man vill ha någon form av tidsreferens finns dels den enkla räknesnurran...

Kod: Markera allt

counter equ 0x20
...
delay:
    decfsz    counter
    goto      delay
...
    [do something]
    goto    delay
[/c]
...som gör 256 varv mellan vad annars som ska göras, korrekt?
(Åtminstone i exemplet ovan.)

Och just denna tar... (om MC'n ger 4MHz och 4/fosc då ger 1µs per PC(?))... 3µs per räknande varv? decfsz är en operation och goto är två, korrekt?

Sedan kan man använda den inbyggda TIMER0 modulen (PIC16F690 sid 81 ff), som ger ett interupt när TMR0 flödar över (overflow at 0xFF -> 0x00), korrekt?

Och man kan koppla TMR0 till pinnen T0CKI, så yttre enheter kan synkroniseras etc, korrekt?


Min fråga är om pinnen T0CKI låses till detta då man aktiverar T0CS i OPTION register...
...eller om den kan användas till ex vanlig I/O pinne (digital, analog etc)?


Det ser ju ut som om TIMER0 ger ett avbrott på T0IF, i INTCON, oavsett om man aktiverat något alls...?
För att använda det hela behöver man, egentligen, bara kolla om T0IF (INTCON,0x5?) är set, eller?


Å pillar man ytterligare har man rent av en 16-bits räknare, som fungerar på ungefär samma vis?
Som man då mest använder till att fånga intervall som är längre än 256µs...?

Jag hoppas jag strukturerade ovan till bgprigeilhet...? :vissla:

Re: PIC, varför inte... går det....?

Postat: 12 april 2015, 14:04:33
av Nerre
Att blanda fördröjningsloppar med interrupt är väl inte riktigt det smartaste man kan göra. Det finns inget som hindrar att en interrupt uppstår medans ditt program är i din loop, vilket gör att den kan ta längre tid än vad du räknat med.

(Sen blir väl 0x20 inte 256?? Det blir 32.)

Re: PIC, varför inte... går det....?

Postat: 12 april 2015, 14:08:46
av sodjan
OK, så det gäller T0CKI pinnen på en 16F690, eller hur?

Se t.ex (har du kollat över huvudtaget !?):

"TABLE 1: PIC16F631 PIN SUMMARY".
"TABLE 1-5: PINOUT DESCRIPTION – PIC16F690"
"4.1 PORTA and the TRISA Registers"
"4.2.5.3 RA2/AN2/T0CKI/INT/C1OUT"

4.2.5.3 säger:

• a general purpose I/O
• an analog input for the ADC (except PIC16F631)
• the clock input for Timer0
• an external edge triggered interrupt
• a digital output from Comparator C1

Frågor på det?

> Min fråga är om pinnen T0CKI låses till detta då man aktiverar T0CS i OPTION register...

Förstår inte frågan. Pinnen blir ju det man sätter den till. Du kan inte konfigurer
en pinne till två olika funktioner samtidigt. Du får välja.

> Det ser ju ut som om TIMER0 ger ett avbrott på T0IF, i INTCON, oavsett om man aktiverat något alls...?

Den sätter T0IF flaggan, ja. Om det blir något avbrott eller inte beror på annat (T0IE och GIE bl.a).

> För att använda det hela behöver man, egentligen, bara kolla om T0IF (INTCON,0x5?) är set, eller?

Ja, det fungerar, om man vill göra så och om det passar den aktuella applikationen.
I andra fall kan det vara mer praktiskt med ett vanligt avbrott/interrupt.

> Å pillar man ytterligare har man rent av en 16-bits räknare, som fungerar på ungefär samma vis?

Det finns också en 16-bitars räknare (Timer1). Men visst, med lite kod man kan
själva skapa räknare med valfi längd.

Som man då mest använder till att fånga intervall som är längre än 256µs...?

Det beror ju även på processorn frekvens och konfigurering av prescaler.

Re: PIC, varför inte... går det....?

Postat: 12 april 2015, 16:55:07
av Erik M
Jag försöker Janne! :humm:

Det som lite ställer till det hela är hur pinnar och register förhåller sig till varandra.
Och ibland behöver man svar som delar upp bitarna, så att det som ser lite ut som inflätade uttryck inte nödvändigtvis är det, i realiteten.

Med en tydligare bild/känsla för hur saker förhåller sig är det enklare förstå vad som kan göras.
Och i dessa första steg är det vad som behövs - veta att något kan göras.
Inte ännu så himla viktigt med hur det måste ordnas för det. Inte i detta läge.

Låt mig ta ett annat exempel....

Cin+ versus Cin- ger normalt sett, på en ordinarie komparator, ett värde som måste läsas på Cout för att bli begripligt.

Och på en MC går det göra så.

Men...!

Värdet som kommer ut på Cout borde först finnas i ett File Register, dvs lagrat som ett värde. Korrekt?
Vilket borde betyda att värdet i sig är oavhängigt pinnen för Cout. Korrekt?
Och då borde denna pinne vara fri att arbeta i någon annan funktion, inklusive som Cout. Korrekt?

Om jag vet att det fungerar så, då är det mycket enklare hitta vad som behöver göras, för just det.

Vilket oxå är anledningen till att jag försöker ställer frågor som besvaras med Ja/Nej.
Utvikningar är väldigt bra och belysande. Och värdefulla!
Den direkta frågan behöver få svar först, för att förklaringar ska få något att ställas i relation till.


Nerre~

"delay equ 0x20" är angivande av adressen för variabeln.
Ofta används "cblock ... endc", men equ är grunden. Typ.

Du har helt rätt i att man ska blanda saker som passar ihop.
Kod-exemplet var en fördröjningsloop, använt som ett exempel.

Re: PIC, varför inte... går det....?

Postat: 12 april 2015, 19:15:02
av sodjan
> Värdet som kommer ut på Cout borde först finnas i ett File Register, dvs lagrat som ett värde. Korrekt?

En komparatorn utgång har bara två värden, "hög" resp "låg".
Komp 1 läses via bit C1OUT i register CM1CON0.

Re: PIC, varför inte... går det....?

Postat: 13 april 2015, 14:41:56
av Erik M
Jo, hög eller låg.

Men värdet finns som File Register och på pinnen för Cout, korrekt?
Och pinnen måste inte användas till detta, korrekt?

Dvs man kan ta ut en representation på pinnen, men måste inte.
Man kan läsa och använda värdet rent internt, korrekt?

Såhär i början är det inte enkelt "se" hur olika FRS, och GPR, fungerar gentemot varandra.

Och helst skulle jag vilka hitta en (Q-uick) BASIC compilator som fungerar med MPLAB.

Det verkade som om Proton Amicus18 Compiler skulle fungera, men det vette tjyven...


Tack för tålmodig hjälp! :tumupp:

/Erik

Re: PIC, varför inte... går det....?

Postat: 13 april 2015, 15:41:30
av sodjan
> Men värdet finns som File Register och på pinnen för Cout, korrekt?
> Och pinnen måste inte användas till detta, korrekt?

Ja, det är också min *tolkning*.
Det går att verifiera genom att kolla lite nogrannare
och också självklart genom att helt enkelt testa...

Re: PIC, varför inte... går det....?

Postat: 13 april 2015, 15:53:43
av Erik M
Bra! :tumupp: Då känner jag att jag är åtminstone i rätt härad! :mrgreen:

Att testa kräver att man är där - annars blir det lätt till att samla ihop röken...
...å försöka få in den i komponenterna igen. :vissla:

Re: PIC, varför inte... går det....?

Postat: 14 april 2015, 00:08:13
av Kaggen
Jag kanske totalt missförstår detta, men CCP1 pinnen används eller används inte beroende på hur du konfigurerar CCP1M bitarna 3-0 i CCP1CON registret enligt det fagra databladet nedan:

1000 = Compare mode, set output on match (CCP1IF bit is set)
1001 = Compare mode, clear output on match (CCP1IF bit is set)
1010 = Compare mode, generate software interrupt on match (CCP1IF bit is set, CCP1 pin is unaffected)
1011 = Compare mode, trigger special event (CCP1IF bit is set; CCP1 resets TMR1 or TMR2, and starts an A/D conversion, if the ADC module is enabled)

Som du ser så det tredje alternativet (1010) genererar enbart ett interrupt *utan* att använda CCP1 pinnen till något (CCP1IF bit is set, CCP1 pin is unaffected). Du kan då använda den pinnen till något annat. I detta fallet istället för att använda pinnen genereras ett interrupt som du kan använda till att i mjukvara göra vad du nu vill göra.

Konfar du CCP1CON registret med något av 1000 eller 1001 alternativen används som du ser CCP1 pinnen till just detta och kan inte användas till något annat.

I fallet 1011 Startar en A/D konvertering bl.a. vilket då påverkar den pinne som för närvarande är vald för A/D omvandling. Vilken pinne det är konfar du i bl.a. ADCONx registren. Det är programmerarens skyldighet att hålla reda på vilken pinne som är vald där innan konverteringen börjar.

Angående din förra fråga:
> Min fråga är om pinnen T0CKI låses till detta då man aktiverar T0CS i OPTION register...
> ...eller om den kan användas till ex vanlig I/O pinne (digital, analog etc)?

Sätter (aktiverar du) bit T0CS i OPTION registret så används T0CKI pinnen som clockingång för räkna upp TMR0. Du kan då inte använda T0CKI pinnen till något annat!!!

Det står i databladet om T0CS "1 = Transition on T0CKI pin" vilket betyder att T0CKI används.

Sätter du T0CS till 0 så kan du använda pinnen till annat, men inte räkna pulser på den samtidigt. Du kan samtidigt använda TMR0 men då triggas klockan från Fosc/4 = frekvensen du kör microcontrollern på delat med 4, istället för från T0CKI.

Många pinnar på dagens microcontrollers kan ha flera olika funktioner *men inte samtidigt*. Du väljer en av dom genom att sätta kontrollregistren rätt.

Om detta nu var din fråga.

Re: PIC, varför inte... går det....?

Postat: 14 april 2015, 00:17:00
av sodjan
Bara för att vara korrekt, och det kan undvika en del missförstånd... :-)

> I detta fallet istället för att använda pinnen genereras ett interrupt...

Ett interrupt genereras bara om även CCP1IE, GIE och PEIE är satta.
Annars är det enda som händer att CCP1IF biten sätts...