Svenska ElektronikForumet

Du menar de två prio nivåer som finns i PIC18 arkitekturen ?

Väldigt sällan som man behöver använda det, och det strular till
interrupt hanteringen en hel del. Nyckel till en bra interrupt hantering
är att interrupt-rutinerna är så korta/snabba som möjligt.

Som du säger, om du ändå inte kör med MB's inbyggda funktioner
så är steget til asm inte så stort.

Kul att du fick det att funka Hur många gånger samplar du knapparna med AD-omvandlaren?

sodjan:
"Du menar de två prio nivåer som finns i PIC18 arkitekturen ?"

Japp.

"Väldigt sällan som man behöver använda det, och det strular till
interrupt hanteringen en hel del."

Aha! Men då gör det alltså inget att det saknas.


RasmusB:
Jag kör med Tosc/16 för tillfället. (Kör PIC'en med 8MHz.)


Kan passa på att fråga om "Acquisition Time" (ADCON2 ACQT2:ACQT0)
Jag har läst Section 17.3 några gånger, men jag hänger inte riktigt med på vad det är.

When the GO/DONE bit is set, the selected channel is sampled for the programmed acquisition time before a conversion is actually started. This removes the firmware overhead that may have been required to allow for an acquisition (sampling) period (see Register 17-3 and Section 17.3 Selecting and Configuring Automatic Acquisition.

Vad innebär "This removes the firmware overhead..." ?

Att du inte behöver vänta i din kod ?

Ja kanske det.

Alltså,

*Utan* "Automatic Acquisition" måste du själv vänta "acquisition time"
efter ett kanalbyte innan du startar en omvandling (via GO). Alltså
"firmware overhead"...

*Med* "Automatic Acquisition" så kommer processorn själv att vänta ut
"acquisition time" efter att GO är satt och innan omvandligen startar.
Bara att välja ADC-kanal och sätta GO direkt.

(Jag orkade inte öppna databladet, men så måste det vara... )

Aha! Då förstår jag.

JimmyAndersson skrev: RasmusB:
Jag kör med Tosc/16 för tillfället. (Kör PIC'en med 8MHz.)

Inte så jag menade, jag undrar om det räcker med att göra en en AD-omvandling? Eller måste du göra flera för att vara säker på vilken knapp som är nertryckt?

Oj, jag läste lite dåligt.
Det räcker med att göra en läsning eftersom jag kollar om värdet ligger inom ett område. T.ex så ger en av knapparna 511 eller 512, men eftersom jag kör med if (knapp >=506) AND (knapp <= 516) then... så stämmer det alltid.

Men jag har märkt att IF-raderna tar ganska mycket processortid. De ligger visserligen inte i interrupt-delen längre, men det är ju trevligt om allt flyter på så bra som möjligt, så jag funderar på att testa med flera omvandlingar och göra en medelvärdesberäkning istället.

En enda värde = avläsning1 + avläsning2 osv / antal borde väl ta mindre processorkraft/tid än 6st IF-rader där varje dessutom innehåller en AND.

Du skulle kunna göra så att du bara använder de högsta 8 bitarna, då
slipper Basic kompilatorn att generera 16-bitars operationer för dina
IF satser och det bör bli betydligt mer kompakt.

Bra idé! Det blev mycket bättre. Dessutom minskade hex-filens storlek med 0,5kB.

Nu känner jag mig nöjd med den här delen. Knapparna kan läsas av tillräckligt snabbt trots att en timer ger interrupt 3,815 gånger i sekunden. Nu är det dags för knapparna att få lite uppgifter. Men först en backup av koden.

Hmm... vad är det du bygger förresten?

Om man korsar en TFT-skärm med en UV-box och en halv scanner så får man mitt projekt.

Det blir en pryl som exponerar kretskort utan att man behöver skriva ut kretskortslayouten. Några funktioner: Tidstyrd belysning, mätning av UV-ljuset, mm. Sedan finns några små roliga finesser som jag inte vill avslöja än.

Det "materiella" är 95% klart. Nu återstår bara 20% programmering och ett kretskort. Det blir nog en projekt-tråd i slutet av veckan.

Coolt! Ska hålla ögonen öppna...

0,5 kB !!
uj uj, ingen bra kompilator.