Macke in SetADCfixed?

Harald_K

Subject:

Macke in SetADCfixed?

· Posted: 18.12.2015 - 13:12 · #1

Hallo, Leute

hier mal ein Auszug aus dem Kompilat - Compiler 3.98 und 5.05 liefern dasselbe.

SYSTEM.SETADCFIXED:
LDS _ACCB, _ADCBUFF +006h
LDD _ACCA, Y+001h
TST _ACCA
BRNE SYSTEM._L0088
ANDI _ACCB, 0FEh
RJMP SYSTEM._L0089
SYSTEM._L0088:
ORI _ACCB, 01h
LDD _ACCA, Y+000h
CPI _ACCA, 004h
BRCS SYSTEM._L0090
CPI _ACCA, 007h
BRCC SYSTEM._L0090
DEC _ACCA
CLI
MOV _ACCCLO, _ACCA
ANDI _ACCA, 15
ANDI _ACCCLO, 8
IN _ACCCHI, admux
CBR _ACCCHI, 15
OR _ACCA, _ACCCHI
OUT admux, _ACCA
IN _ACCCHI, adcsrb
CBR _ACCCHI, 8
OR _ACCCHI, _ACCCLO
OUT adcsrb, _ACCCHI
SBRC Flags, IntFlag
SEI
SYSTEM._L0089:
STS _ADCBUFF +007h, _ACCB
SYSTEM._L0090:
RET

was mich wundert: -
es wird ein Flag von _ADCBUFF+06h gelesen, das auch in der Inerruptroutine ausgewertet wird um ggf. das MUXer-Umschalten zu umgehen.
Diese Flag wird aber beim Verlassen der Routine nach _ADCBUFF+07h zurückgeschrieben.

keine Ahnung ob diese Speicherstelle vom System reserviert ist.

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Macke in SetADCfixed?

· Posted: 18.12.2015 - 13:57 · #2

Hallo Harald,

ich kann das momentan nicht nachvollziehen.
Aber gibt es da irgendwelche Probleme mit der Speicherstelle Buffer+7 ??

rolf

Harald_K

Subject:

Re: Macke in SetADCfixed?

· Posted: 18.12.2015 - 16:52 · #3

nein - ich seh das eher so, daß setadcfixed nichts bringt.

ADCBUFF+6h wird nur einmal im RESET geschrieben, mit dem Variablenbereich auf Null gesetzt

im SYSTICK-Interrupt wird ADCBUFF+6h geprüft und damit entschieden, ob der admux/adcsrb neu gesetzt werden muß oder unverändert bleibt

in setadcfixed wird ADCBUFF+6h gelesen und je nach Übergabewert true oder false ADCBUFF+7h gesetzt oder zurückgesetzt, außerdem noch im true-Fall der admux/adcsrb auf den fixen Kanal gesetzt.

beim nächsten SYSTICK wird - da ja ADCBUFF+7 nicht ausgewertet wird, sondern das genullte ADCBUFF+6h - der admux/adcsrb weitergezählt

Ob ADCBUFF+7h vom System für den AD-Wandler reserviert wird oder nicht weiß ich nicht - für ein Flag tuts normal ein byte, und sonst finde ich nix zu ADCBUFF+7h im ASM-Code

RESULTAT:
es wird einmal der fixe Kanal gewandelt, dann gehts munter weiter im Kreis rum ... .

gemerkt hab ich das, weil ich - bislang noch keine Ahnung warum - am tiny861 die Kanale 4..6 genutzt habe, und wegen schneller Regelschleife nur den 6er Kanal gewandelt haben wollte - also schön SetADCfixed (true,6) gemacht, Regelschleife 500mal, dann wieder SetADCfixed auf false und einmal alle Kanäle gescannt (Akkuspannung ab und zu prüfen, Ausgangsspannung dauernd regeln).
Fehler war, daß mit den beiden setadcfixed-Aufrufen die Regelung nicht funktioniert (Ausgangsspannung sinkt auf Eingangsspannung ab beim Step-Up-Wandler), wenn ich die beiden setadcfixed-Aufrufe auskommentiere funktioniert es gut, sprich regelt die Spannung je nach Last aus.

16 MHz Clock, Systick steht dabei auf 0,3 ms, und es ist nur der ADC als Systemfunktion drin. gibt so etwa 10% Systemlast durch den INT.

NACHTRAG:

Das Ganze passiert nur, wenn man die AD-Kanäle nicht einfach mit der Anzahl, sondern als Bereich angibt.

sprich:
mit ADChans = 3, iData geht es (wird immer ADCBUFF+6h behandelt)

mit ADChans = [1..3], iData geht es nicht.
Bei ner Probecomplierung mit dem mega128 wird +6h gelesen, aber +4h geschrieben - das ist mitten im AD-Puffer!!!
Mein obigens Problem beim tiny861 ist mit ADChans = [4..6], iData übersetzt

betrifft immer nur SETADCfixed

Noch ein NACHTRAG:
_ADCBUFF+7h ist eine Variable der nächsten Libraryfunktion, keine Ahnung welche ...

FAZIT:
SetADCFixed knallt irgendwo in den Variablenbereich wenn man die AD-Kanäle mit [a..b] festlegt. Es wird jeweils Bit0 gelöscht bzw. gesetzt.
Der Adressoffset zu _ADCBUFF scheint sich aus dem letzen gewählten AD-Kanal+1 zu ergeben
Wenn man nur einen oder zwei Kanäle mit Abstand dazwischen ([a], [a,b]) nutzt klappt es.

es betrifft nur die Erzeugung der letzten Codezeile vor dem RET in SetADCFixed
SYSTEM._L0089:
STS _ADCBUFF +007h, _ACCB <<<<<<da die +007h
SYSTEM._L0090:
RET

So - nun hab ichs viermal editiert ... nu isses gut hoffe ich

einstweilen noch Frohe Weihnachten

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Macke in SetADCfixed?

· Posted: 18.12.2015 - 19:54 · #4

Hallo Harald,

bitte ein kleines Test Programm schicken, sonst suche ich mir einen Wolf....

rolf

Harald_K

Subject:

Re: Macke in SetADCfixed?

· Posted: 19.12.2015 - 01:20 · #5

So, hier ein Beispiel:
-------schnipp---------

program Blinker;

{$NOSHADOW}
{ $WG} {global Warnings off}

Device = mega128, VCC=5;

Define_Fuses
Override_Fuses;
NoteBook = A;
COMport = COMauto;
Supply = 5, 100;
LockBits0 = [LOCKBIT1, LOCKBIT2];
FuseBits0 = [CKSEL0];

ProgMode = SPI;

Import SysTick, ADCPort;

Define
ProcClock = 9600000; {Hertz}
SysTick = 10; {msec}
StackSize = $0020, iData;
FrameSize = $0020, iData;
ADCchans = [4..6], iData;
ADCpresc = 64;

Implementation

{$IDATA}

type

begin
enableints;
setadcfixed(true, 6);
loop

endloop;
end Blinker.

-----schnapp---------

je nach Endzahl der AD-Kanaldefinition im define ADChans =[4..6] wird am Ende der SetADCFixed-Routine der Offset auf den _ADCBUFF falsch ausgerechnet. (STS _ADCBUFF+xxx, _ACCB)

an Anfang der SetADCfixed-Routine wird aber der Offset fürs Lesen immer richtig ausgerechnet (SETADCFIXED: LDS _ACCB, _ADCBUFF+006h)

Also einfach die Offsetberechnung vom Routinenanfang auch am Ende einsetzen und alles ist paletti

Nebeninfo:
bei meinem Problem des Ausfalls der Spannungsregelung führt das dazu, daß eine Hälfte des Sollwertes der Ausgangsspannung auf 01 geschrieben wird beim Fixieren des AD-Kanals und auf 00 beim Entfixieren

Harald_K

Subject:

Re: Macke in SetADCfixed?

· Posted: 04.05.2016 - 11:44 · #6

So - muß dieses Thema nochmal aufwärmen:

es gibt noch ne kleine Macke in setadcfixed

tritt auf, wenn man 2 Kanäle die nicht aufeinanderfolgende Nummern haben nutzt.

also sowas wie

ADCchans = [4,6], iData;
ADCpresc = 64;

im define-Bereich

produziert wird dieser code:

SYSTEM.SETADCFIXED:
CLI
LDS _ACCB, _ADCBUFF +4
LDD _ACCA, Y+001h
TST _ACCA
BRNE SYSTEM._L0089 <<<<<hier falsche Sprungmarke!!
ANDI _ACCB, 0FEh
RJMP SYSTEM._L0090
ORI _ACCB, 01h <<<<<das wird NIE angesprungen ???
LDD _ACCA, Y+000h
CPI _ACCA, 004h
BREQ SYSTEM._L0089
LDI _ACCA, 006h
SYSTEM._L0089:
DEC _ACCA
MOV _ACCCLO, _ACCA
ANDI _ACCA, 15
ANDI _ACCCLO, 8
IN _ACCCHI, admux
CBR _ACCCHI, 15
OR _ACCA, _ACCCHI
OUT admux, _ACCA
IN _ACCCHI, adcsrb
CBR _ACCCHI, 8
OR _ACCCHI, _ACCCLO
OUT adcsrb, _ACCCHI
SYSTEM._L0090:
STS _ADCBUFF +4, _ACCB
SBRC Flags, IntFlag
SEI
RET

aussehen müßte das aber wohl so:

SYSTEM.SETADCFIXED:
CLI
LDS _ACCB, _ADCBUFF +4
LDD _ACCA, Y+001h
TST _ACCA
BRNE SYSTEM._L0088 <<<hier wird dann auf das 088er-Label gehüpft
ANDI _ACCB, 0FEh
RJMP SYSTEM._L0090
SYSTEM._L0088: <<<dieses Label wird sonst immer erzeugt
ORI _ACCB, 01h
LDD _ACCA, Y+000h
CPI _ACCA, 004h
BREQ SYSTEM._L0089
LDI _ACCA, 006h
SYSTEM._L0089:
DEC _ACCA
MOV _ACCCLO, _ACCA
ANDI _ACCA, 15
ANDI _ACCCLO, 8
IN _ACCCHI, admux
CBR _ACCCHI, 15
OR _ACCA, _ACCCHI
OUT admux, _ACCA
IN _ACCCHI, adcsrb
CBR _ACCCHI, 8
OR _ACCCHI, _ACCCLO
OUT adcsrb, _ACCCHI
SYSTEM._L0090:
STS _ADCBUFF +4, _ACCB
SBRC Flags, IntFlag
SEI
RET

ist in Compiler3.98 und 5.0X gleich.

führt dazu, daß beim Aufruf nicht der AD-Kanal, sondern der Ein/Aus-Boolean als Kanal in den MUXer eingetragen wird ..... gibt ganz komische Reaktionen.

ansonsten noch schönes Wochenende ....

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Macke in SetADCfixed?

· Posted: 04.05.2016 - 17:56 · #7

Hallo Harald,

das sollte im nächsten Update behoben sein.

rolf

Macke in SetADCfixed?

Registered users in this topic