Hallo,
Für den TWI-Bastler hier ein nützliches Tool/Adapter zum Testen von
TWI-Geräten vom PC aus (das gibt’s natürlich schon in ähnlicher Form,
aber manchmal macht es eben auch Spaß, das Rad neu zu erfinden).
Via Terminal-Programm und RS232 werden Tastatureingaben an einen Mega8
geschickt, der interpretiert den Datenstrom und leitet das Ergebnis an
den TWI-Bus weiter (das Terminal liefert ja nur Ziffernfolgen, die der
Adapter zu Zahlen zurückbauen muss).
Ein Echo wird an das Terminal zurückgeschickt.
Wird ein Slave befragt, so wird auch seine Antwort ans Terminal
geleitet.
Als Terminal-Programm arbeite ich mit HTerm.
Compiliert wurde zuletzt mit AVR-GCC 4.3.0.
Verwendet wird die Bibliothek nach AVR315 (Using TWI-module as i2c
master).
Erforderliche Hardware:
Ein Mega8 mit Quarz (4MHz reichen für einen TWI-Takt von 100KHz, für
400KHz sind 16 MHz angesagt), ein MAX232 zur Pegelwandlung für die
PC-Verbindung und ggf. 2 Pullups für den TWI-Bus reichen aus.
Der mc sollte möglichst 512 .. 1024 Byte SRAM besitzen, damit
ausreichend Platz für die interne Datenpufferung vorhanden ist.
Bedienung/Eingabe:
Erfolgt in der gleichen Form/Reihenfolge wie die Transaktionen am
TWI-Bus erwartet werden, zuerst die Eingabe der TWI-Adresse, dann die
Eingabe von Daten/Parametern.
z.B.: 64,255 sendet an das Device 64 das Byte 255
160,1,128,Test\ (alternativ 160,0w384\Test\)
schreibt an das Eeprom mit TWI-Adresse 160
an der Eeprom-Adresse 0x01F0 den String "Test" mit
abschließendem ASCII 0.
65 holt vom Device 65 ein Byte ab,
das gelesene Byte wird am Terminal ausgegeben
65,10 holt vom Device 65 10 Bytes ab und sendet sie ans Terminal
Auf diesem Wege kann man alle TWI-Geräte 'manuell' konfigurieren,
beschreiben und auslesen.
Am Terminal erfolgt die Ausgabe in der Form:
RxD 64:Data,Data,.. Empfangen von Device 64: Data, Data, etc.
TxD 65:Data, ...... Gesendet an Device 65: Data, etc.
oder im Fehlerfalle
Adr 66 TWI-Error 0x20: SLA+W has been transmitted and NACK received
Zusätzlich sind einige Schnörkel eingebaut:
- TWI-Takt veränderbar
- Tastatur-Echo abschaltbar
- Absuchen des TWI-Bus nach Geräten (die mit ACK antworten)
- Auslesen eines TSL2550 (Helligkeitssensors mit fester Adresse)
- Eingabe beliebig: dezimal, hexadezimal, binär,
als Wort (2 Byte, Eingabe dezimal)
- Ausgabe alternativ: dezimal, hexadezimal, binär
- der Sendepuffer bleibt erhalten, mit '+' können einzelne Bytes der
letzten Eingaben wiederholt werden
- bei Untätigkeit (und er ist fast immer untätig) fällt der mc in den
Idle-Modus zurück
Wenn man eine vorbereitete Textdatei an den Adapter schickt, dann lassen
sich auf diesem Wege auch TWI-Eeproms beschreiben.
Weitere Erläuterungen in der Datei "rs232_2_twi.txt".
Michael S.
Hallo allerseits,
dieses Projekt ist schon uralt und da es immer aber ohne Murren seine
Aufgabe erfüllte, gab es nie Anlass zu grundlegender Veränderung.
Nun habe ich mir einen neuen Adapter zusammengelötet, der mittels
USB-RS232 Konverter mit dem Netbook (ohne V24) zusammenarbeitet.
Bei der Gelegenheit habe ich die Dokumentation auf den aktuellen Stand
des Projektes gebracht.
Die Neuerung ist:
Das Programm horcht nun - während der Phasen des untätigen Wartens - als
TWI-Slave am TWI-Bus und gibt alle Daten, die der TWI-Master an seine
Adresse schickt,
über die serielle Schnittstelle an den PC weiter.
Das ist immer dann nützlich, wenn der zu programmierende Controller über
keine serielle Schnittstelle verfügt - aber eine ausführliche
Debugging-Ausgabe erforderlich ist.
Oder wenn die serielle Schnittstelle des Controllers bereits benutzt
wird.
Ausserdem benutze ich einen Datenlogger, der seine Daten via TWI
erhälten und auf einem USB-Stick ablegen.
Anstatt die Daten erst auf den Stick zu schreiben, den Stick dann vom
Logger zu trennen, am PC anzustöpseln, einen Editor anzuwerfen, die
Daten zu betrachten, den Stick wieder abzumelden kann ich so wesentlich
bequemer und ohne Zeitverzögerung die Daten am Terminal sehen.
Weitere Erläuterungen gibt es in der readme.pdf.
mfg
Michael S.
Hallo allerseits,
am Wochenende wollte ich seit langem mal wieder Tabellen in ein
serielles Eeprom übertragen.
Und - das Versenden von Dateien funktionierte nicht mehr.
Zugegeben, ich hatte es auch nicht getestet.
Zur Problembehebung waren einige Umstellungen im Programmablauf
erforderlich.
Empfang und Versenden von Daten über Serielle Schnittstelle und TWI wird
nun vollständig über Interrupts abgewickelt.
Dadurch sollen sich die Programmteile nicht mehr gegenseitig behindern
können.
Das "Tastaturecho" (bei der Dateiausgabe wird das zum "Dateiecho") wird
automatisch unterdrückt, wenn der Sender noch busy ist.
Als Hinweis für den Benutzer wird lediglich '+' am Terminal ausgegeben.
mfg
Michael S.
Hallo Leute,
muss diesen alten Beitrag mal aus der Versenkung holen, da das genau das
ist was ich brauche.
Könnte mir Bitte mal jemand den Aktuellen C-Code durch seinen Compiler
jagen und HEX File posten?
Bin ein reiner ASM'ler und hab kein C..
wäre echt toll..
Danke schön
Ronnie
Dank Dir UWE,
super.. werd mich die Feiertage dranmachen...
Merci auch für die F_CPU Info.. hätte bestimmt nen 16ner reingemacht...
gg
Und das Du das .lss mitgepostet hast.. genial
Werd mich melden wenn's funkt..
Schöne Feiertage
grüssle
Ronnie
Ich konnt's doch nicht erwarten.
Das Teil funktioniert einwandfrei.
Schade das es kein 'Restart' in der gleichen Zeile gibt..
würde einiges leichter von der Hand gehen..
Gewöhnung ist alles, in diesen sinne.. passt!
Ronnie
Hallo Forum,
jetzt muss doch nochmal nachfragen, weil ich mir grad nicht sicher bin
ob ich doof bin, oder der Code eine Macke hat..
Folgender Käfer macht Ärger PCF8583 (UHR) an Adresse 0xA0
folgendes passiert:
Sende: 0xa1,0xf --- (lese ab Adresse 0x00 15 Byte)
Antwort:
RxD a1: 0,3,86,43,1,0,1,1,0,0,ff,ef,ff,df,cf, --- plausibel
Sende: 0xa1,0xf --- (sollte ja eigentlich das gleiche wieder tun)
Antwort:
RxD a1: fe,ff,0,0,0,0,0,0,0,0,0,0,0,0,0,
opps...
sieht so aus als würde beim zweiten lesen nicht wieder von vorne
angfangen werden sondern die nächsten 15 Byte geschickt werden..
Schon mal jemanden aufgefallen...
Seltsam ist, wenn ein 8574 gelesen wird also immer wieder nur ein Byte
funktioniert es. bekommt dann jede Änderung am Port mit..
Hmm...
grüssle
Ronald P. schrieb:> sieht so aus als würde beim zweiten lesen nicht wieder von vorne> angefangen werden sondern die nächsten 15 Byte geschickt werden..>> Schon mal jemanden aufgefallen...>> Seltsam ist, wenn ein 8574 gelesen wird also immer wieder nur ein Byte> funktioniert es. bekommt dann jede Änderung am Port mit..
Der PCF8574 hat sozusagen nur ein Byte, das ausgelesen werden kann.
Daher muss kein internes Register adressiert werden.
Der PCF8583 dagegen verfügt über 256 Register.
Welches soll nun ausgelesen werden ??
Darum muss ihm zuerst die Startadresse mitgeteilt werden, anschließend
incrementiert er die Adresse automatisch.
Das beobachte Verhalten ist also korrekt.
Alles klar ?
Michael S.
Servus Michael,
ja, klar!
ich muss ihm ja immer wieder sagen wo er anfangen soll.
Sorry, hab schon länger nichts mehr mit I2C gemacht.
Dank Dir für's stubsen..
grüssle
Ronnie
Es gibt übrigens einen Nachfolger für das Projekt:
Beitrag "ATMega88 als "Rasp"-Mega Pi IO""
Der Unterschied ist unter anderem:
Die Kommunikation mit dem Gateway erfolgt binär.
Ich benutze heute fast nur noch diese Variante, indem ich mir mit Python
und Tkinter eine kleine Oberfläche bastle und dann relativ komfortabel
TWI-Geräte konfigurieren oder auslesen kann.
mfg
Michael S.
