Kört fast med multiplexing av 3st 7-segment display (PIC)

[sodjan]

Det finns en del att säga om koden...
Kör med RES istället för CBLOCK.
Kör med BANKSEL istället för BCF/BSF mot STATUS bitarna.
INCF sätter Z korrekt, finns ingen anledning att nolla Z innan.
Det var de snabba sakererna, det finns kanske mer.

[Spket]

Tack Sodjan å Jesse!
Sodjan: Det tror jag säkert. Tittar man omkring i boken jag har (Mikrocontrollers -Från assembler till RTOS av Lars Bengtsson) och på internet så ser man att folk skriver lite olika kod. Vilken som är rätt eller fel har jag ingen koll på. Så länge det fungerar och jag lär mig!

RES i stället för CBLOCK. Måste man ha en org 0x0?? innan de reserverade bitarna då? Jag provade med en org 0x071 innan mina reserverade bitar man jag får en massa errors när jag compilerar koden. "Overwriting previous adress contents". Antar för att koden sträcker sig in i samma adress som mina reserverade bitar?
Finns det något bra sätt att se hur och var all kod hamnar? Så man kan se vilka adresser som är lediga?
Jag antar också att jag skulle kunna lägga t.ex. Mainloopen på adressen 0xA0, vilket innebär att den hamnar i Bank 1.
Måste jag då välja rätt bank när jag läser/skriver till mina register som är reserverade i bank0? Som exemplet under.

Kod: Markera allt

Main: org 0xA0
banksel   PORTA
clrf   PORTA
goto Main

Att jag nollade Z flaggan va en rest från när jag satt å klurade med Binary to Decimal subrutinen. Glömde att ta bort den.

[AndersG]

RES och ingen ORG så får du relokerbar kod. Be länkaren generera en MAP-fil så ser du vart allt hamnar.

Edit: Jo, du måste använda BANKSEL

[sodjan]

> Mainloopen på adressen 0xA0, vilket innebär att den hamnar i Bank 1.

Nej, *kod* kan aldrig hamn i en bank!
Kolla databladet i kapitlet "memory...", det är skillnad på "pages" och "banks".

> RES i stället för CBLOCK.

Först så är det en fundamental skillnad på RES ("Reserv memory" och CBLOCK ("Constant Block").
RES allokerat faktiskt minne ur det minne som den aktuella PIC modellen har tillgängligt.
CBLOCK skapar ett antal symboler med olika numeriska värden. Vad dessa värden står för
är helt upp till programmeraren, ofta är det minnesadresser men inte alltid.

> Måste man ha en org 0x0??

ORG används när man bygger "absolute mode code". Motsvarigheten i "Relocatable mode"
(vilket är det moderna och rekomenderade sättet att skriva kod) är CODE. Slå upp
dessa i MPSAM manualen. Eller se :
http://www.jescab.se/Relocmode.html
http://www.jescab.se/abs_reloc.html

> Antar för att koden sträcker sig in i samma adress som mina reserverade bitar?

Det kan den *aldrig* göra. Läs på om minneshanteringen i databladet!

> Finns det något bra sätt att se hur och var all kod hamnar? Så man kan se vilka adresser som är lediga?

Ja, MAP filen (om man kör relocatable mode) men å andra sidan är det inte så intressant.
Det är just därför man kör relocatable mode, det är inte intressant var koden hamnar.

> Jag antar också att jag skulle kunna lägga t.ex. Mainloopen på adressen 0xA0, vilket innebär att den hamnar i Bank 1.

Nej, "banks" har ingenting alls med *koden* att göra.

[AndersG]

För att förtydliga Sodjans eminenta förklaring så är det skillnad på tex en Intelprocessor som är en Von Neumann och en PIC som är en Harvard-arkitektur:

http://ww1.microchip.com/downloads/en/d ... 31004a.pdf

En Intelprocessor har program och data i samma minnesrymd, en PIC har separata.

Såväl data som programminne kan sedan delas upp i butar för att underlätta adresseringen. För data är det banks och för program pages

[Spket]

Jag får ta å läsa på lite mer helt enkelt

Edit: läste första sidorna i boken som jag nämnde tidigare igen. Kan ju säga att det hade jag glömt bort. Men nu förstår jag skillnaden mellan programminnet och RAMminnet (eller 'dataminnet')

Ska läsa lite mer på länkarna om harvardstrukturen också.

[AndersG]

Jo, det finns en massa bra material på Microchips hemsida.

[sodjan]

Från din kod och inlägg så ser det ut som att du använder en 16F877A. Det
var en under många år populär modell, men idag är den inte speciellt "modern"
och är i princip ersatt av 16F887 eller någon 40-pinnare i 16F1xxx serierna.

> Edit: läste första sidorna i boken som jag nämnde tidigare igen.

Annars så står ju det du letar efter på ett par sidor i databladet.
Här finns också en enkel bild och text kring arkitekturen:
http://www.microchip.com/pagehandler/en ... range.html

[Spket]

Jag hade två stycken 16f877a sen tidigare. Det blev bekvämt att använda dom i stället för att köpa nya.

En ny fundering jag har.
I mitt program har jag lagt till en knapp. Knappen finns med på kopplingsschemat i första posten och är alltså kopplad till RB0/INT.
Tanken med knappen är att pausa/starta uppräkningen av siffrorna. Jag har gjort så här
ISR rutinen kollar om det är en TMR0 interrupt eller en extern interrupt på INT-pinnen genom att bittesta INTCON,INTF och INTCON,TMR0IF. Har knappen blivit nedtryckt så ökar jag ett register StartStop med 1. I mainloopen senare så bittestar jag bit0 i StartStop. Är den 0 så räknar den inte upp siffrorna (Number), är den 1 så räknar vi upp som vanligt.

Problemet jag har stött på är avstutsning på knappen. Normalt skulle jag lösa det med några mS väntetid om knappen blev nedtryckt. Om knappen fortfarande är nedtryckt så väntar den en stund till tills knappen har släppts. Nu krockar det här lite med min TMR0 interrupt som till uppgift har att multiplexa mina displayer. Dvs gör jag det här testet i interrupten så blir den en pause i multiplexingen och bara en siffra visas.

Är det någon som har ett tips på hur man kan göra det utan att man påverkar TMR0 interrupten. Ungefär att TMR0 kan fortsätta sin räkning medans jag avstutsar min knapp.

Enklaste vore att inte göra knapptryckningen till en interrupt utan bara testa den i main-loopen så TMR0 interrupten kan fortsätta som vanligt.

Förlåt om mitt språk blev rörigt.

[sodjan]

Med vilken frekvens multiplexas displeyerna?
D.v.s hur ofta körs din ISR ?

Du kan ju kolla knappen i din ISR och sen se till att det måste ha varit
ett stabilt läge på knappen ett visst antal rundor i ISR'en innan du
signlerar "tryck" (eller "släpp"). Det påverkar knappast ISR'en alls.

Du ska så klart inte ligga och *vänta* på något i själva ISR'en !

[Spket]

Oscillatorn är på 4MHz. En instruktion tar 4 oscillator cykler.
Prescalern är tilldelad TMR0 och har bitvärdet '011' eller 1:16.

Så va 16:e instruktion så ökas TMR0 med 1 tills den när värdet 0 igen (256 * 16) = 4096 instruktioner.
En instruktion tar 1 uS. Så ungefär va 4mS så byter den vilken display som ska visas.

Så när knappen blir nedtryckt så kan man kolla om den förblir nedtryckt över typ 10 TMR0 interrupts och endast därefter öka StartStop med 1?

[sodjan]

Man röknar väl med att en knapp har studsatt färdigt efter kanske
20-50 ms beroende på kvallitet på knappen. Väg detta mot önskad
"respons" i knappen. Sedan är det bara att testa! Men visst, 10
gånger i rad i ISR'en med samma läge på knappen så kan du kanske
anta att knappen är "stilla". Och är det inte samma läge som innan
så har den "bytt läge", så att säga...

[Spket]

Rent praktiskt, är det här ett bra sätt att göra det på?

Jag får en interrupt genom RB0/Int
Den ökar StartStop med 1 (som sedan bittestas för att se om räknaren ska räkna upp eller inte)
Den nollställer INTCON, intF (bcf intcon,intf)
Den nollställer INTCON, intE (bcf intcon,inte)
laddar ett register "Count_TMR0" med värdet 9.

Sen för varje gång TMR0 interrupten utlöser så minskar "Count_TMR0" med 1
När Statusregistrets zeroflagga blir hög så återställer jag INTCON, INTE så att en ny interrupt med knappen kan utföras. (bsf intcon,inte)

Då borde avstudsningen bli ~ 9x4mS = 36mS

[sodjan]

> Sen för varje gång TMR0 interrupten utlöser så minskar "Count_TMR0" med 1

Och varje gång som knappen inte är samma som innan så återställer du "Count_TMR0" till 9.
Du vill ju ha ett stabilt/samma läge under 10 vänder i rad.

Men vänta lite... Var kommer RB0/Int in i bilden?
Menar du alltså att du låter knappen generera interrupt ?
Nej, du *läser av* knappen varje gång du är i TMR0 ISR'en.
Eller också missförstår jag något...