mikrocontroller.net

Forum: Projekte & Code Terminal / TWI-Adapter für Mega8 in C


Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pier S. (bigpier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Coole Sache Michael!

Gefällt mir werd ich bei nächster Gelegenheit ausprobieren !!

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ronald P. (ronald_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe S. (de0508)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ronnie,

na dann viel Glück und berichte bitte mal.

Bitte beachte:

MCU = atmega8
F_CPU =  4000000

Autor: Ronald P. (ronald_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ronald P. (ronald_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ronald P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ronald P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank X. (matrixx200x)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ast reine Arbeit läuft super vielen dank...

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.