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.
Coole Sache Michael! Gefällt mir werd ich bei nächster Gelegenheit ausprobieren !!
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
Hallo Ronnie, na dann viel Glück und berichte bitte mal. Bitte beachte: MCU = atmega8 F_CPU = 4000000
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.