[Bascom] ATMega328 und Software I2C steuern

[Bernard B. (bernard_b)]

[Intro]
Kürzlich habe ich ein PCB für ein Atmega328 (mlf-Paket) gebastelt, das 
AD-Konvertierungen durchführen soll und ein SSD1306 128x32 OLED (I2C) 
-Display verwenden soll. Standard-AD-Konvertierungen erfolgt über C0 bis 
C7, während für Hardware-I2C, C5 (SCL) und C4 (SDA) reserviert sind.

Dies bedeutet, dass ein Konflikt auftreten wird (ADC und I2C an 
denselben Pins). Dennoch ist es möglich, die I2C-Pins mit Software-I2C 
umzuleiten mit Bascom.

[Problem]
Es hat mich dazu gebracht, D2 (SDA) und D1 (SCL) am Atmega328 
auszuwählen und folglich Software-I2C zu verwenden. Allerdings bekomme 
ich diese I2C OLED nicht mit diesen alternativen Pins an einem Atmega328 
zu arbeiten. In den letzten Tagen habe ich viele Dinge wie Hardware und 
Quellcode überprüft und verifiziert. Ich konnte keinen Fehler finden.

[Alternatieve]
Da ich es nicht in Betrieb bekomme, versuchte ich es an einem ATmega128 
mit der gleichen OLED zu überprüfen, der auch mit einer internen 
8MHz-Takt lief. Zunächst habe ich die OLED an offiziellen I2C-Pins 
getestet: funktionierte sofort.
Der nächste Schritt war, andere Pins auszuwählen und Software-I2C zu 
verwenden: Wieder kein Problem, die OLED funktioniert wie erwartet (ein 
Countdown - updated pro Sekunde - sollte sichtbar sein).

Mein (fast) letzter Schritt war, den I2C-Prozess zwischen ATmega328 und 
ATmega128 mit einem Scope zu vergleichen. Und schließlich konnte ich ein 
mysteriöses Problem (für mich) feststellen. Es scheint, dass der 
ATMega128 klar / sauber I2C erzeugt, während der ATmega328 sowohl bei 
SDA als auch bei SCL Rauschen erzeugt.

Als Referenz habe ich Screenshots beigefügt.

Der nächste Schritt war, die SDA- und SCL-Pins erneut zu routen 
(Atmega328). Diesmal habe ich B4 (SDA) und B5 (SCL) benutzt. B4 wird 
standardmäßig als MISO und B5 als SCK für die ISP-Programmierung 
verwendet. Und zu meiner Überraschung wurde die OLED immer noch nicht 
lebendig. Diesmal zeigen beide Pins ein anhaltendes High-Level-Signal.

[Und was jetzt ?]
Gibt es etwas Spezielles (einen Fehler) bezüglich Software-I2C oder 
Hardware eines ATmega328 ? Bisher konnte ich es nicht in einem Bascom 
Handbuch / Hilfe, noch in einem ATMega328 Datenblatt finden.

P.S. Quellcode kann für Atmega328 leicht geändert werden. Ändern Sie 
einfach die Pinbelegung und die $regfile = "M128def.dat" nach $regfile 
"m328def.dat"

[Christian S. (roehrenvorheizer)]

Hallo,

hast Du SS als Ausgang eingestellt?

"SS: Slave Select input. When the SPI is enabled as a Slave, this pin is 
configured as an input regardless of the setting of DDB2. As a Slave, 
the SPI is activated when this pin is driven low. When the SPI is 
enabled as a Master, the data direction of this pin is controlled by 
DDB2. When the pin is forced by the SPI to be an input, the pull-up can 
still be controlled by the PORTB2 bit."

MfG

[Bernard B. (bernard_b)]

Ja, genau, SS (B2) wurde als OUTPUT geplant. Wenn jedoch ein 
Reset-Signal gegeben wird, kann der Atmega328 über ISP programmiert 
werden.

Anbei : Original Schaltplan (D1 / D2 fuer I2C)

P.S. Ich entschuldige mich für die Verwendung von Google Translate. Ich 
spreche ein wenig Deutsch, also modifiziere ich die Übersetzung so weit 
ich glaube das es geht. ;)

[Fred R. (fredylich)]

Hallo,

wenn du die Fuse nicht geändert hast, würde ich nicht B4 (SDA) und B5 
(SCL) benutzen.
Auch nicht D0 und D1. Im Code nutzt Du D6 u. D7 das sollte doch 
funktionieren.
 Config Scl = Portd.6                  'Software I2C address
 Config Sda = Portd.7                  'Software I2C address
 Config Twi = 100000                   'Com-speed I2C 100 KHz
 I2cinit                               'Initialise I2C bus
 Waitms 5

Nach  Schaltplan aber D1 und D2. Da stimmt was nicht.
Mit freundlichen Grüßen

[Bernard B. (bernard_b)]

@fredylich :
Im Wesentlichen hast du Recht. Der beigefügte Quellcode wurde mit dem 
ATmega128 verwendet. Schau in die Kopfzeile:

$regfile = "M128def.dat" 'benutzter Chip

Beim Atmega128 habe ich D6 / D7 als alternative Pins benutzt. Beim 
Atmega328 habe ich diese Pins in D1 / D2 geändert. Später B4 / B5.

Ich hätte den Quellcode aller Tests hier einfügen können, aber es schien 
bequemer, es einfach zu halten, mit nur einer.

Wie auch immer, das Problem bleibt, dass es unklar ist, warum mit 
Software I2C :
- D1 / D2 des Atmega328 erzeugt eine Art 10-Hz-Störsignal
- B4 / B5 des Atmega328 tut gar nichts

und mit einem atmega128 gut funktioniert...

[Bernard B. (bernard_b)]

Oder vielleicht sollte ich eine andere Frage stellen: Ist es möglich, 
I2C (Software) auf einem Atmega328 zu betreiben und gleichzeitig einen 
ADC in Bascom durchzuführen?

[M. K. (sylaina)]

Bernard B. schrieb:
> Oder vielleicht sollte ich eine andere Frage stellen: Ist es möglich,
> I2C (Software) auf einem Atmega328 zu betreiben und gleichzeitig einen
> ADC in Bascom durchzuführen?

Na klar geht das, warum sollte das nicht gehen?

[Fred R. (fredylich)]

Hallo Bernard,

Hatte doch geschrieben meide beim Atmega328 D0/D1/B4 und B5 wenn möglich 
für I²C.
Für ADC ist doch direkt das Port A vorgesehen und I²C Hardware an Pin 
C.1 (SDA) und Pin C.0 (SCL). Dann musst Du nichts umleiten und es 
funktioniert mit Sicherheit(ADC und I²C soeben getestet)
Gruß

[Bernard B. (bernard_b)]

_@sylaina:_
Der Grund, warum ich die Frage stelle, ist wie folgt: ADC ist als 
Eingang und an den Pins C0 bis C7. I2C (Hardware) ist über C4 und C5.
Ich denke, die ADC-Umwandlung wird kontinuierlich an den Pins abgetastet 
und die Werte intern in einem Puffer gespeichert. Sobald ein Getadc(x) 
ausgeführt wird, wird der Puffer gelesen.

Wenn es gleichzeitige I2C-Kommunikation und AD-Umwandlung gibt, kann ich 
mir vorstellen, dass es ein Problem für die Pins C4 und C5 gibt (I2C), 
wenn immer ein ADC an diesen Pins durchgeführt wird.
Und deshalb habe ich andere Pins für I2C gewählt (und damit 
softwarebasierte Steuerung).

_@fredylich:_
Bitte beachte, dass ich die OLED mit einem Atmega328 steuern möchte. Es 
hat eine Reihe von ADC-Pins, aber das ist der C-Port.

Weil es fehlschlägte, habe ich es mit einem Atmega128 getestet.

[Fred R. (fredylich)]

Bernard B. schrieb:
> _@fredylich:_
> Bitte beachte, dass ich die OLED mit einem Atmega328 steuern möchte. Es
> hat eine Reihe von ADC-Pins, aber das ist der C-Port.
>
> Weil es fehlschlägte, habe ich es mit einem Atmega128 getestet.

Na wenn Du das ganze C-Port zwingend für OLED nutzen möchtest, was mir 
ein Rätsel ist, dann entschuldige mein Kommentar.
Bin wohl nicht mehr auf den neusten Stand OLDE- Display mit ADC 
ansteuern muss was neues sein.

[Bernard B. (bernard_b)]

_@fredylich:_
Tut mir leid, vielleicht habe ich es falsch erklärt.
Was ich meine, ist, dass ADC Umwandlung, aber auch die Kontrolle einer 
I2C OLED benötigt wird. Leider sind die Hardware-Pins (SCL und SCK) am 
selben Port vorhanden, nämlich C4 und C5 als ADC bei Atmega328.
Deshalb vermute ich, dass ein Konflikt auftreten wird, also habe ich 
andere Pins für I2C ausgewählt. Der Nachteil ist, dass es dann per 
Software-I2C kontrolliert werden muss.

Und mit Software-I2C bekomme ich es nicht zum laufen (atmega328). Das 
Seltsame ist, dass es kein Problem gibt, wenn ich es auf einem Atmega128 
(als Test) exportiere.

[Fred R. (fredylich)]

Bernard B. schrieb:
> Tut mir leid, vielleicht habe ich es falsch erklärt.

Nein, Nein Du magst nicht zu lesen.
Bin raus.

[Bernard B. (bernard_b)]

Ein Bild sagt mehr als eine Beschreibung. Ich habe ein Bild von der 
entworfenen Platine gemacht (mit Atmega328). Auch vom Testaufbau mit 
einer Atmega128 Platine.

Vielleicht wird das Problem jetzt klarer.

[c-hater (Gast)]

Bernard B. schrieb:

> Ein Bild sagt mehr als eine Beschreibung. Ich habe ein Bild von der
> entworfenen Platine gemacht (mit Atmega328).
[...]
> Vielleicht wird das Problem jetzt klarer.

Nicht wirklich. Erst, wenn du auch noch das Programm postest, was du 
tatsächlich für diese Platine verwendest (und zwar vollständig), dann 
könnte das Problem eventuell klarer werden.

[c-hater (Gast)]

c-hater schrieb:

> Nicht wirklich. Erst, wenn du auch noch das Programm postest, was du
> tatsächlich für diese Platine verwendest (und zwar vollständig), dann
> könnte das Problem eventuell klarer werden.

Und nicht vergessen: einen Schaltplan, der exakt zur gezeigten Platine 
paßt. Das spart nämlich den Leuten Arbeit, die eventuell geneigt sind, 
ihre wertvolle Zeit zur Lösung deiner Probleme zu verwenden.

[Bernard B. (bernard_b)]

_@c-hater:_
Die anderen Pins werden nicht benutzt oder eingestellt, weil ich 
versuche, das Problem zu isolieren. Dies scheint sich auf die 
softwarebasierte Steuerung von I2C zu konzentrieren. Die beigefügte 
OLED.bas ist was ich benutze. Mit kleinen Anpassungen benutze ich es auf 
beiden Atmega-ICs.
Ich beschreibe auch, welche Anpassungen ich anwende, damit es auch für 
andere getestet werden kann, wenn man will / kann.

[c-hater (Gast)]

Bernard B. schrieb:

> Die beigefügte
> OLED.bas ist was ich benutze.

Dann kann sie definitiv nicht funktionieren. Weder target device noch 
pinning passen.

> Mit kleinen Anpassungen benutze ich es auf
> beiden Atmega-ICs.

Auch bei "kleinen Anpassungen" kann es zu idiotischen Fehlern kommen. 
Genau deswegen fordere ich dich auf, exakt das zu posten, was du 
tatsächlich verwendest.

> Ich beschreibe auch, welche Anpassungen ich anwende

Kein Mensch hat Zeit und Lust, sich durch längliche Prosa in schlechtem 
Deutsch zu kämpfen und darin nach den Schusselfehlern anderer zu suchen.

[Bernard B. (bernard_b)]

_@c-hater:_

> Kein Mensch hat Zeit und Lust, sich durch längliche Prosa in
> schlechtem Deutsch zu kämpfen und darin nach den Schusselfehlern
> anderer zu suchen.

Ich nehme an, du meinst das als Kompliment :(

Anbei sind die Quellcodes, mit denen ich alles getestet habe.

[Stefan F. (Gast)]

Wo sind die I²C Pull-Up Widerstände?

[M. K. (sylaina)]

Bernard B. schrieb:
> Ich denke, die ADC-Umwandlung wird kontinuierlich an den Pins abgetastet
> und die Werte intern in einem Puffer gespeichert. Sobald ein Getadc(x)
> ausgeführt wird, wird der Puffer gelesen.

Öhm, nö. Eigentlich nicht. Also der ADC tastet nicht ständig alle 
ADC-Eingänge ab sondern nur den ADC-Eingang, den man mit GETADC() 
angibt.

[Bernard B. (bernard_b)]

_@stefanus:_
Das war auch das erste woran ich dachte. Als Vorsichtsmaßnahme hatte ich 
sie auch extra gelötet (siehe Schaltplan Atmega328 : R3 / R4, 
links-oben). Das hat nicht geholfen.
Aber es stellt sich heraus, dass die mit der OLED integriert an Bord 
gibt. Ich habe das herausgefunden, als ich einen Schaltplan davon auf 
Internet gefunden habe (siehe angehängtes PDF).

_@sylaina:_
Danke ! Das ist eine interessante Information.
Wenn ich nicht irgendwann herauskomme und deshalb eine neue Platine 
entwerfen muss, dann werde ich das im Hinterkopf behalten. Dan wird es 
tatsächlich Hardware-I2C und werde die ADC-Eingänge anpassen.

Aufmerckung: Ich verstehe, dass einige Leute von meinem Deutsch hier 
gestört werden können. Auf Wunsch kann ich mühelos auf Englisch 
umstellen. Ich brauche definitiv keinen Google Übersetzer dafür.
Ich habe Deutsch gewählt, weil es hier ein deutsches Forum ist. Aber 
wenn das so mies ist ...

[Manfred (Gast)]

Bernard B. schrieb:
> Aufmerckung: Ich verstehe, dass einige Leute von meinem Deutsch hier gestört 
werden können.

Ich eher nicht: Hier gibt es hinreichend viele Threads von 
Deutsch-Muttersprachlern, die erheblich mehr Fehler aufweisen. Ich 
meckere gerne, aber mit Deinen Texten habe ich kein Problem!

Entschuldige: "Aufmerckung" gibt es nicht, "Anmerkung" wäre richtig.

Unklar ist mir der Grund Deiner Probleme: Der AT328 hat einige Pins für 
bestimmte Funktionen reserviert, z.b für I2C. Mir ist es bisher 
gelungen, diese zu akzeptieren und meine Ports passend zu belegen. In 
einem Projekt hatte ich Ärger mit einem SPI-PIN, anstatt lange in der 
Software zu stochern, habe ich mit dem Lötkolben umverdrahtet. Kannst Du 
Deine Hardware nicht anpassen?

[Bernard B. (bernard_b)]

_@Manfred:_
Danke für dein Kompliment, aber auch für deine Sprachkorrektur.

> Kannst Du Deine Hardware nicht anpassen?
Mit der aktuellen Platine ist dies nicht mehr möglich. Es würde 
bedeuten, dass ich wahrscheinlich entwerfen und eine neue Leiterplatte 
herstellen lassen müsste. Das ist etwas, was ich jetzt in Betracht 
ziehe.

Gerade habe ich ein paar Screenshots des Oszi gemacht. Ich denke, es 
kann eine wichtige Unterstützung sein, um auf die störende Quelle 
hinweisen zu können.

Gelb : SCL
Blau : SDA

Sie steigen von 10us/div bis auf 1s/div.

=====
_@Manfred:_
Thank you for your compliment and the correction.

> Kannst Du Deine Hardware nicht anpassen?
It's not possible with current PCB. It would mean I need to create a new 
layout and get it manufactured. On the other hand, I already got this 
option in mind.

I just took some scope-screenshots. I think they might be a good support 
to analyse, where the problem may occur.

Yellow : SCL
Blue : SDA

The screenshots are taken from 10us / divider, upto 1s / divider.

[c-hater (Gast)]

Bernard B. schrieb:

> Anbei sind die Quellcodes, mit denen ich alles getestet habe.

> Config Scl = Portd.1                                       'Software I2C address

Das ist der TX-Pin der USART. Die USART ist standardmäßig aktiv. Damit 
läßt sich der Pin nicht als GPIO verwenden, jedenfalls nicht ohne 
weitere Maßnahmen, nämlich sowas:

Ucsr0b.txen0 = 0

Bitte beachten: sowohl Registername als auch Bitname variieren je nach 
target device. Die korrekten Namen kann man der Definitionsdatei für das 
jeweilige target device entnehmen.

[M. K. (sylaina)]

Bernard B. schrieb:
> Gerade habe ich ein paar Screenshots des Oszi gemacht.

Am SCL-Verlauf sieht man, dass deine Pull-ups zwar nicht ideal sind aber 
völlig OK.
Was mich aber stört sind die Spikes auf dem SDA-Signal, das sieht aus 
als würde da etwas einkoppeln. Korreliert das ggf. mit einer anderen 
Schaltfunktion deines Mikrocontrollers?

[Bernard B. (bernard_b)]

_@c-hater:_
Vielen Dank für deine Unterstützung und deine Vorschlag. Es hat jedoch 
keine Lösung gebracht.

Das Problem ist wahrscheinlich mit Hlife eines Oszilloskops gefunden.

Zuerst habe ich die Adresse jede Sekunde an die OLED geschickt :

I2cstart
i2cwbyte &H78
I2cstop

Sehe Bild 007a_I2CAddress.jpg

Als das gut aussah, schrieb ich den Code um, indem ich ihn pro Sekunde 
in einen "cls" -Befehl umwandelte.
Sehe Bild 008_I2C_cls.jpg

Auch das seht gut aus.

Dann habe ich "Cls" in folgendes eingefügt:

cls
lcdat 1, 1, text

"Text" ist eine String-Variable, die einen Zählerwert (jede Sekunde) 
enthält.
Bild : 100KHz_1S.jpg

Wie man sehen kan, sind die Signale (sehr) nahe beieinander.
Und das war der Grund, dass alle 2 Sekunden ein Update durchgeführt 
wurde.
Bild : 100KHz_2S.jpg

Das hat mir die Idee gegeben, die Geschwindigkeit von 100KHz auf 400KHz 
einzustellen.
Bild : 400KHz_1S.jpg

Nun, das ergibt kein anderes Bild.

Anmerkung : "Config TWI = 100000" ist ein Teil von "i2c_twi.lbx". Genau, 
das ist eine Library für Hardware I2C, die nicht verwendet wird....

Trotzdem wundere ich mich immer noch etwas. Im Prinzip werden Daten an 
das OLED gesendet. Bei einem Update, pro 2 Sekunden sollte jedoch etwas 
auf dem Bildschirm zu sehen sein ...

Ich habe die Idee, dass ein Atmega128 besser mit Software I2C umgehen 
kann als ein Atmega328. Aber warum ? Keine Ahnung.

[Bernard B. (bernard_b)]

_@sylaina:_
Nein, ich habe nichts anderes, was ich an den Pins kontrolliere. Die 
anderen Komponenten sind Bit-Shifter (4094) und Komparatoren. Solange 
die Bit-Shifter nichts zu tun haben, wird nichts passieren.

[Bernard B. (bernard_b)]

Letzte Nacht habe ich eine neue Platine entworfen und heute Nachmittag 
verschickt, um es herzustellen lassen.
Ich möchte nicht mehr mit der aktuellen Platine herumbasteln. Es braucht 
mich zu viel Zeit und hat bisher viel Ärger verursacht. Außerdem 
befindet sich die OLED mit der neuen Platine nun tatsächlich auf den 
I2C-Pins.

Also vielen Dank für die Hilfe.