ADS1115 Initialisierung ADC auslesen ATmega8 Assembler ASM

[Bernhard S. (bernhard)]

Geschätztes Forum,

ein kleines Beispiel, wie ein ADS1115 in Assembler und mit einem
ATmega8 (1MHz) initialisiert und ausgelesen werden kann.

Nach Programmstart werden die beiden Config Register auf ihre
Default-Werte gesetzt und anschließend wieder ausgelesen und 
ausgewertet.

Anzeige: 8385

Wird dieser Wert nicht ausgelesen, dann liegt vermutlich ein I2C/TWI 
Übertragungsfehler vor. (LED gelb + rot blinkt).

Nun erfolgt die eigentliche Initialisierung, MUX, PGA + MODE
und der ADC verrichtet seine Arbeit und zeigt sein Ergebnis im Display 
an.

Vorsicht:

Der ADS1115 verlangt einen SCL-Takt  0.4...3.4 MHz.
Mit einer Taktfrquenz außerhalb dieses Bereiches kommt er nicht zurecht.
Und die Registerwerte stimmen nicht.

Das MUX-Register ist sehr wichtig, hier im Beispiel wird IN0 gegen GND 
gemessen.

Ich habe versucht, den Assembler-Code so gut wie möglich zu 
kommentieren, damit man jeden Schritt nachvollziehen kann.

Für konstruktive Hinweise bin ich sehr dankbar.

Bernhard

[Falk B. (falk)]

Bernhard S. schrieb:
> Der ADS1115 verlangt einen SCL-Takt  0.4...3.4 MHz.
> Mit einer Taktfrquenz außerhalb dieses Bereiches kommt er nicht zurecht.
> Und die Registerwerte stimmen nicht.

Das sind Fake News(tm). Das Ding funktioniert bis runter auf 0,01MHz, 
aka 10kHz.

[Wastl (hartundweichware)]

Bernhard S. schrieb:
> Für konstruktive Hinweise bin ich sehr dankbar.

Die Abblock-Kondensatoren am Spannungsregler sind zu klein.
Beachte (beherzige) die Empfehlungen im Datenblatt des
(unbekannten) Reglers.

An AVcc und Vcc gehören jeweils keramische Abblock-Kondensatoren
mit 100nF bis 1uF. Der Elko dort ist nicht relevant bzw.
deplaziert.

[Bernhard S. (bernhard)]

Falk B. schrieb:
> Das Ding funktioniert bis runter auf 0,01MHz, aka 10kHz.

Falk, ich gebe Dir Recht.

[Falk B. (falk)]

Bernhard S. schrieb:
> Für konstruktive Hinweise bin ich sehr dankbar.

Hallo Bernhard,

grundsätzlich sieht dein Projekt gut aus

- systematisches Konzept mit Unterfunktionen
- Funktionen sinnvoll auf Dateien aufgeteilt
- weitestgehend sinnvolle Namen für Register
- viele gute Kommentare

Hier jetzt ein paar Verbesserungsvorschläge

- keine Papageikommentare; wenn Funktions- und Variablennamen gescheit 
gewählt werden, sind die selbsterklärend
- zuviele überflüssige Kommentare verschlechtern die Lesbarkeit und 
Verständnis
- Kommentare die bei Änderungen übersehen werden sind dann falsch
- man sollte die Parameter der Befehle alle gleich ausrichten, damit die 
einheitlich in einer Spalte stehen, das ist besser lesbar
- ebenso die Kommentare

SRAM_CLEAR_w:
  ST   z+,temp
  cpi  ZH, HIGH(RAMEND)  ; Vergleich?    
  brlo SRAM_CLEAR_w    ; kleiner => SPRUNG  
  cpi  ZL, LOW(RAMEND)  ; Vergleich?    
  brlo SRAM_CLEAR_w    ; kleiner => SPRUNG  
  breq SRAM_CLEAR_w    ; gleich  => SPRUNG

- man läßt den Assembler die Daten anlegen und verwalten, nicht manuell!
- die Vorsilbe adr_ ist Unsinn, denn die Labels sind immer Adressen
- Wenn man viele Variablen mit gleichem Namen und ner Nummer am Ende 
hat, schreit das nach einem Array

; SRAM Daten              
.dseg
.org SRAM_START             
ZEIGER:    .byte 1
DIGITS:    .byte 8
ADS_MSB:  .byte 1
ADS_LSB:  .byte 1

- man braucht hier keine Klammern

; Begrüssung "ADS1115"                    
  ldi temp, ASCII_A
  STS adr_DIGIT7,temp

- wenn man so ein Array füllen will, geht das so einfacher, weniger 
Tipperei und fehleranfällig
- Man sollte wenn möglich die Datenreihenfolge auch logisch von 
vorn/oben nach unten wählen, damit man nicht immer verdreht denken muss

; Begrüssung "ADS 1115"                    
  ldi    ZL, low(DIGITS)
  ldi    ZH, HIGH(DIGITS)
    
    ldi     temp, DISP_A
  st      z+, temp
  ldi     temp, DISP_d
  st      z+, temp
    ldi     temp, DISP_S
  st      z+, temp
    ldi     temp, DISP_AUS
    st      z+, temp
  ldi     temp, DISP_1 
    st      z+, temp 
  ldi     temp, DISP_1 
    st      z+, temp 
  ldi     temp, DISP_1 
    st      z+, temp 
  ldi     temp, DISP_5 
    st      z+, temp
  rcall   WAIT_1000ms

- im Interrupt macht man zu 99% kein sei, das braucht keiner und ist 
eher gefährlich
- nur in Sonderfällen wenn man WIRKLICH weiß was man tut!

TIM0_OVF:
;  sei          ; interrupts freigeben, NEIN, DAS MACHT MAN EHER NICHT!          
  push TEMP        ; Sichern von "TEMP" im Stack      
  in   TEMP,SREG    ; Einlesen des SREG           
  push TEMP        ; Schreiben von  SREG  im Stack (KOPIE)  
  push TEMP1      ; Sichern von "TEMP1" im Stack      

  rcall ANZEIGE

  pop TEMP1      ; Wiederherstellen von "TEMP1"       
  pop  TEMP      ; LESEN von SREG vom STACK (KOPIE)    
  out  SREG,TEMP    ; Wiederherstellen von SREG        
  pop  TEMP      ; Wiederherstellen von "TEMP"       
    reti

- deine Funktion zum Multiplexen der Anzeige ist lustig ;-)
- das macht man DEUTLICH einfacher, kürzer und übersichtlicher mit einer 
Schleife
- die Funktion ist besser in Anzeige.asm aufgehoben, hab ich verschoben
- ret bzw reti gehören wie alle anderen Befehle in die 2. Spalte, nicht 
an den Zeilenanfang

Welche Anzeige ist das? Die hier?

https://www.pollin.de/p/daypower-digitalanzeige-modul-led-display-dig-2r-810568

- In deinen ADS115 Funktionen sind viele Dinge drin, die dort nicht 
reingehören, z.B. ADS_READ_2_BYTES
- Dort gehören nur Funktionen rein, die den ADC ansprechen und 
Ergebnisse liefern!
- Die Weiterverarbeitung und Anzeige gehört dort NICHT REIN!
- Eine Funktion sollte nur das machen, was der Name aussagt
- auch in ADS_CONFIG_READ, dort gehört die Eintragung in die 
Anzeigedaten NICHT REIN!
- ultralange Zeilen wie die hier in ADS_INIT sind ungünstig
- vor allem sind die ganzen Null-Bits sinnlos
- der Kommentar ist irreführend, man sollte eher schreiben, was hier 
eingestellt wird, ggf. in eine eigene Zeile darüber

  ldi     temp1, 
0<<ADS_DR2|0<<ADS_DR1|0<<ADS_DR0|0<<ADS_COMP_MODE|0<<ADS_COMP_POL|0<<ADS 
_COMP_LAT|1<<ADS_COMP_QUE1|1<<ADS_COMP_QUE0   ;(default) X83 (MSB)

eher so

  ldi     temp1, 1<<ADS_COMP_QUE1 | 1<<ADS_COMP_QUE0

- in den Funktionen zum Lesen von Registern vom ADC gibt man die 
Registernummer sinnvoll als Dezimalzahl an, binär ist hier eher 
verwirrend
- Funktionsnamen mit FUNKTION_ anfangen ist Unsinn, denn alle 
Funktionsnamen sind Funktionsnamen!
- sinnvollerweise gestaltet man Funktionsnamen so, daß sie 
selbsterklärend sind, meist Verb + Substantiv, z.B. convert_hex_ascii_32
- die Datei zahlen.asm ist sehr aufgeblasen, da kann man viel mit 
Schleifen und Tabellen komprimieren, siehe HEX_ZU_DISPLAY
- BIN_ASC_32 ist in Prinzip OK, aber die Daten sollten man besser im RAM 
als in den Registern speichern, denn das ist eher ein Array
- damit kann man die Daten anschließen deutlich einfacher verarbeiten 
(Schleifen) und hat deutlich weniger Kopier - und Tipparbeit
- Die I2C Sachen hab ich nicht angefaßt, ohne Hardwarwe zum Debuggen ist 
das ungünstig

Schau dir das Projekt mal an und lass es auf dich wirken. Teste mal, ob 
es noch funktioniert. Ich hab ja keine Hardware zum testen.
Siehe auch Strukturierte Programmierung auf Mikrocontrollern

Viel Spaß damit

[Falk B. (falk)]

Ich hab noch ein paar Kleinigkeiten verbessert

Macros für den Schreibzugriff der Displaydaten.
Das halbe Dutzend Funktionen zum Warten durch 2 Kernfunktionen mit 
Parametern und Macros ersetzt (WAIT_MS und WAIT_US)

; Begrüssung "ADS 1115"                                     
    ldi     xl, low(digits)
    ldi     xh, HIGH(digits)    
    WRITE_DISPLAY DISP_A
    WRITE_DISPLAY DISP_d
    WRITE_DISPLAY DISP_s
    WRITE_DISPLAY DISP_AUS
    WRITE_DISPLAY DISP_1
    WRITE_DISPLAY DISP_1
    WRITE_DISPLAY DISP_1
    WRITE_DISPLAY DISP_5
    WAIT_MS 1000
    rcall   ads_init