Ich habe eine Betty von Swisscom.
Der Ladevorgang mit lpctool in Debian scheint funktioniert zu haben.
Es erscheint das Bild von Betty.
Aber die Fernbedienung reagiert nicht mehr auf Tasten.
Meine Wunsch-Betty sollte alle Funktionen der Betty über das Lan ansteuern und auslesen können (z.B. Port 5060 über den TAE an einem SIP-Adapter), sowie einen einfachen über das Lan programmierbaren Timer besitzen, um einfache Funktionen automatisch auszulösen.
Folgende Funktionen sollten auf das Lan übertragen sein (ansteuern/auslesen):
- Tasten
- Bildschirm
- IR (in/out)
- Funk
- eventuell Sound
So könnte die Betty als Radio/Fernseh/Stereo-Wecker dienen und Geräte ein und ausschalten.
Sie könnte Video- und Audio-Aufnahmen ein und ausschalten. Über das Scart-Signal könnte sie sogar Werbung überspringen, oder zeitliche Verschiebungen von Sendungen berücksichtigen.
Sie könnte als kleines Terminal dienen, für meinen Linux-Router, auf dem ich vielerlei Spiele programmieren könnte, die auf der Betty angezeigt würden und mit den Tasten der Betty gesteuert würden.
Sogar ein kleines Display zu einem Webbrowser könnte man so realisieren. Der Webbrowser liefe auf dem Router, die Anzeige und Steuerung auf der Betty.
So könnte ich mit der Betty das ganze Haus mittels Webinterface steuern.
Ganz toll wäre, wenn sie Funksteckdosen ein und ausschalten könnte und damit beim Stromsparen behilflich sein.
Und was davon hast du schon angefangen zu programmieren?
Leider habe ich die Betty-Swisscom
Seit dem Firmware update auf Boop ist sie lahm.
Wenn sie bei mir läuft werde ich mit dem Programmieren loslegen.
Kann ich mit Hilfe rechnen?
(Ich bin gerade daran mir eine Programmierumgebung für die Betty einzurichten. Hat jemand eine Idee, warum die Betty-Swisscom aufhängt?)
Hi ist das den die gleiche REV. ? also 1.8 das kann gut sein Das die Swiscom Bettys anders aufgebaut sind
Die Swisscom Betty
IST anders, siehe: http://bettyhacks.com/forum/index.php?topic=113.0 (http://bettyhacks.com/forum/index.php?topic=128.0) und http://bettyhacks.com/forum/index.php?topic=128.0 (http://bettyhacks.com/forum/index.php?topic=113.0)...
Zwei massive Unterschiede gibt es:
- Andere Tastenmatrix
- Kleineres Flash mit sehr unterschiedlicher Sektorbelegung
Angepasst werden müssten also zumindest die Dateien flash.c und so ziemlich alles in keyboard/*.*
Gruß
JimBeam
Bei der Swisscom erscheint das Bild der Boop.
lpctool gab auch keine Fehlermeldung.
Vielleicht hat das Rom doch irgendwie Platz.
Hat mir jemand einen Tipp, wie ich vorübergehend das Rom kompilieren kann, damit ich statt dem Bild wertvolle Informationen über die Tastaturbelegung erhalte?
Die Betty, die Swisscom verteilt hat sind etwas anders. Vor allem ist die Tastatur nicht gleich angeschlossen. Nebenbei sind auch die Flash-Speicher kleiner. Such im Forum nach Swisscom Betty. Da findest Du Infos dazu.
Gruss famos
Der Platz im Flash ist noch nicht das Problem. Wie Du selbst auch festgestellt hast, läuft ja auch was. Die Betty wartet jetzt auf einen Keyboard Eingabe und die wird über einen Interrupt ausgelöst.
Da aber die Verdrahtung nicht stimmt passiert bei Dir nichts.
Danke für Deinen famosen Beitrag!
Ich habe eine laufende Entwicklungumgebung in Debian.
Boop_rom.bin liess sich kompilieren
Da ist eine Datei irq.c /irq.h /lpc2220.h /keyirq.c /keyirq.h
Du arbeitest schon ein Jahr daran.
Was soll ich machen?
(Ich hätte zu Testzwecken auf meiner Betty am liebsten die 32 Bit von FIOPIN0 [aus keyirq.c] , statt dem Bild der Boop in "0" und "1". Dann hätte ich gerne die Bits der Resultate von Key[0] und Key[1]).
Steht zu diesem Zeitpunkt schon eine einfache Ausgabefunktion zur Vefügung?
(Vor dem Bild der Boop wird ja bereits Text angezeigt.)
Bit 30 scheint bei einer Tasteneingabe auf 0 zu gehen.
(Sonst könnte man einfach einmal zu Testzwecken die Bedingung: "Bit30=0" [Taste gedrückt] herausnehmen.)
Es kann nicht alleine daran liegen, dass die Betty auf Eingabe wartet.
Ich habe den KeyScanner in meiner Testfirmware so modifiziert, dass er bei jedem Duchgang (auch ohne Tastendruck) etwas ausgibt.
Trotzdem bleibt die Betty beim Bild regungslos stehen.
Sie muss auf tiefergehende Weise abgestürzt sein, so dass sie gar nicht mehr auf Tastendücke wartet.
(Es würde mich sehr freuen, wenn jemand meine modifizierte Test-Firmware auf einer nicht-Swisscom Betty testen könnte.)
Du arbeitest schon ein Jahr daran.
Was soll ich machen?
Ich habe seit einem Jahr nichts mehr gemacht. Das letzte was ich versucht habe war einen JTAG Debugger zum laufen zu bringen. Debugen via serieller Schnittstelle und printf hat es nicht gebracht.
Auch war ich der Einzige, der sich mit einer Swisscom Betty abgab.
Das Lesen der Tastatur hat in der Testroutine funktioniert, aber eingebunden in boop war der Interrupt-Pin immer aktiv.
Ich hatte dann keine Zeit mehr. Ich schaue zwar ab und zu in das Forum rein ob's was neues gibt.
Ich habe am Anfang noch nicht gewuss warum boop auf meiner Betty nicht läuft. Ich habe dann versucht die ganze Entwicklung zu verstehen und habe mit boop Rev. 01 angefangen. Bis Version 03 hat es noch funktioniert. So bin ich auf die Tastatur als Ursache gestossen. Die unterschiedlichen Mappings findet man im Forum.
Hol dir mal die vier Files von http://svn.mamalala.org/listing.php?repname=boop&path=%2F&rev=3&sc=1 (http://svn.mamalala.org/listing.php?repname=boop&path=%2F&rev=3&sc=1) und lade das Compilat mal auf die Betty, das sollte noch laufen und der Code ist noch leicht zu verstehen. Ob der Interrupt auch auf Pin P0.30 reinkommt müsste ich nachschauen, habe aber die Unterlagen verräumt und müsste erst suchen.
Gruss famos
Die Uhr läuft doch noch?
Du müsstes den Interrupt auch auslösen. Als Idee kommt mir grade in den Sinn:
- Serialport aktivieren
- Keyinterrupt = Serialport Interrupt
- Scancode = Serialport data
dann könntest Du mit dem PC alles bedienen. So eine Testversion wäre dann auf allen Bettys lauffähig.
Das deine Betty regungslos stehen bleibt könnte daran liegen, daß sie nicht mehr aus dem Power Down Modus aufwacht. Dazu wird nämlich der Interrupt von P0.30 genutzt. Der Keyboardscanner selber läuft in einem Timer Interrupt. Um das Schlafengehen zu verhindern, kommentier den gesamten Inhalt der Funktion cpu_idle() in main.c aus.
Danke!
Deine famose Antwort hat geholfen.
Offensichtlich hatten meine Eingriffe die Betty selbst blockiert, denn die Uhr lief tatsächlich nicht.
Jetzt habe ich auf meinem Bildschirm den Inhalt von FIOPIN0.
Eine Hoffnung hat sich leider zerstreut. Ich dachte, dass die Tastatur bei der Swisscom im Gegensatz zur anderen Betty NICHT auf Bit 30 reagiert. Beim drücken der Taste geht jedoch Bit 30 auf 0, genau so wie ich es für die andere Betty erwartet hatte.
Also muss der Unterschied ein anderer sein.
Immerhin kann man jetzt schon morsen. (Sie erkennt Taste gedrückt oder nicht.)
Kannst du mir Tips geben, wie mit dem TAE von der Betty aus kommuniziere?
Vielleicht können auch Telekatz oder Famos mir helfen?
Die Tastatur der Swisscom reagiert auf Bit 30 von FIOPIN0.
Die Tastatur der Swisscom reagiert auf IOPIN1 statt IOPIN3!!!
Diese beiden muss man vertauschen!!!! (In keyirq.c)
Da bei der DE Betty die Keymatrix auf Port P3 und P0 verteilt ist und bei der Swisscom Betty nicht, da ist alles auf P1, kannst Du den
keys[0] |= FIOPIN0>> 5;
keys[0] |= (IOPIN3 & MASK3) >> 18;
vereinfachen, da kommen alle Rows auf IOPIN1 rein. Die Positionen und Belegung ist aber anderst.
Die Mask und Shift Operationen haben den Zweck die 42 Tasten auf zwei Wörter zu verteilen. Jeder Taste ist also ein Bit im keys[0] oder keys[1] zugeordnet.
Übrigens die Mask Funktion wird bei FIOPIN0 über die Hardware gemacht. Das geht aber, soweit ich mich noch erinnern kann, mit Port 1 nicht. Ich suche bei Gelegenheit mal das was ich habe zusammen. Überigens nicht vergessen die Port Initialisierungen anzupassen.
Gruss famos
Famose Informationen!
Bisher bekomme ich auf IOPIN1 nur die Spalten der Tastenmatrix aus einem anderen Beitrag.
Vielleicht hat das mit der Port-Initialisierung zu tun.
Was soll ich da tun?
Einfach 0 nach IODIR1 schreiben? (Alles Eingabe)
Wo soll ich das tun? (In main.c vor der Eingabeschleife?)
(Übrigens:
In
lpc2220.h steht bei FIODIR0 0x3FFFC000
Stimmt die Adresse?
Ich würde eher 0x3FFFC020 erwarten.)
IOPIN2 habe ich nicht so recht verstanden.
Was soll das, dass in regelmässigen Abständen ein einzelnes Bit verschoben wird?
Wer fragt danach?
Die Mask und Shift Operationen haben den Zweck die 42 Tasten auf zwei Wörter zu verteilen. Jeder Taste ist also ein Bit im keys[0] oder keys[1] zugeordnet.
Das habe ich aus dem Quelltext bereits verstanden. Die Tastenbelegung ist in keyboard.h.
Ich glaube, dass ich kurz davor stehe, die Tastatur von Swisscom mit Boop zum laufen zu bringen.
Ich kann bereits:
- überprüfen, ob eine Taste gedrückt ist (FIOPIN0 Bit 30)
- die Spalte der Tastenmatrix angeben (IOPIN1), zu einer gedückten Taste.
Nun möchte ich die Zeile der Matrix der gedrückten Taste.
Stimmt es, dass diese Zeilen bei der Swisscom ebenfalls in IOPIN1 gespeichert sind?
Warum erscheinen sie nicht bei mir?
Muss ich eine PINSEL-Einstellung einfügen?
Danke für jede Hilfe.
P2.18-24 werden als Ausgang konfiguriert (Zeile), P1.16,17,18,19,21 und 22 als Eingang (Spalte).
Um herauszufinden welche Taste gedrückt ist wird eine der Zeilen auf Low Pegel gelassen und die anderen Zeilen auf High Pegel gelegt. Anhand des Bitmusters der Spalten kannst du nun sehen, welche Taste dieser Zeile gedrückt ist.
Dasselbe wiederholst du nun mit den Restlichen Zeilen. Zum Schluss des Tastaturscanns nicht vergessen alle Zeilen wieder auf Low zu legen.
Wow!
Vielen Dank!
Jetzt glaube ich habe ich es verstanden.
Das ist also der Grund warum IOPIN2 bitweise von 18-24 läuft!
Oder?
Am Montag werde ich es gleich ausprobieren.
Ich bin voller Hoffnung!!!
Hallo Gerdi,
Du moechtest Betty fuer Hausautomatisierung via LAN einsetzen? Das will ich auch.
Ich arbeite derzeit an einem Empfaenger auf Basis von CUL (http://busware.de), der als Ethernet-Adapter fungiert, und von der Betty via CC1101 empfangene Ethernet-Frames weiterleitet (Software: CULeth, siehe http://developer.berlios.de/projects/culeth/).
Grundidee: auf dem PC laeuft ein Server, der via CULeth per UDP oder TCP/IP mit den Bettys kommuniziert. Kommandos von der Betty werden vom Server angenommen und an die Hausautomatisierungskomponenten weitergereicht. Die Zustaende des Hauses koennen vom Server abgefragt und auf der Betty visualisiert werden.
Gesucht wird jemand, der Adam Dunkels' IP-Stack auf der Betty implementiert, damit man eine Kommunikationsschicht zwischen PC und Betty hat.
Gruesse,
bn
Du jagst mir hier einen grossen Schrecken ein!!!
Ich hoffe, dass es nicht notwendig wird auf der kleinen, armen Betty Swisscom einen IP Stack zu implementieren, um mit dem Netzwerk zu kommunizieren.
Ich dachte an eine Art Funk-Null-Modem Lösung.
Die Betty schickt per Funk über ein serielles Protokoll Daten an den TAE-Adapter.
Ich habe einen Voip-Telefon-Adapter (Zyxel 2002L AOL, legal gecrackt zum Debranding).
Den habe ich vor Jahren für 4 Euro ersteigert. Seitdem ersetzt das Internet meinen Telefonanschluss zuverlässig.
Dieser Voip-Adapter hat noch einen Anschluss frei.
Dort kommt der TAE hinein (eigentlich RJ-xx bei der Swisscom).
Der Voip-Adapter übernimmt selbständig den Lan Verbindungsufbau.
Der Voip-Adapter bestimmt die IP-Adresse.
Der Voip-Adapter bestimmt den Port.
Der Voip-Adapter bestimmt die IP-Adresse des VOIP-Anbieters (Das werde ich kurzschliessen auf meinen eigenen Domainnamen.)
Ich hoffe, dass die Funkverbindung zwischen Betty und TAE programmtechnisch eine gewöhnliche serielle Verbindung ist.
Hoffentlich erhalte ich von Dir oder Famos oder Telekatz weitere Details.
Um die Ethernet/Lan-Verbindung soll sich meine Betty nicht kümmern.
Den Browser möchte ich nicht direkt auf der Betty laufen lassen, sondern auf dem Server. Die Betty soll nur seriell Eingaben und Ausgaben des Servers auf einfache Weise steuern und anzeigen.
Hallo,
an irgendeiner Stelle muss die Verpackung der von/an Betty gesendeten applikationsspezifischen Daten in ein Netzwerkprotokoll (TCP oder UDP) ja erfolgen. Ich lese heraus, dass Du das via TAE-Adapter in Deinem VOIP-Adapter machen willst. Um das hinzubekommen, musst Du wahrscheinlich mindestens noch ein Reverse Engineering des TAE-Adapters angehen - weiss nicht, ob das schon jemand gemacht hat.
Ich habe mich aus mehreren Gruenden fuer IP entschieden:
- TCP/IP oder UDP stellen paketorientierte Standardprotokolle dar, ueber die jegliche Applikation auf der Betty mit jeglicher Applikation auf jedem beliebigen PC in meinem Heimnetzwerk sprechen kann.
- Ich habe drei Bettys (fuer jedes Stockwerk eine), die so gesondert angesprochen werden koennen (jede Betty eine IP-Adresse in derselben Collision Domain on air).
- Es gibt einen fertigen freien IP-Stack fuer ARM (von Adam Dunkels), den man nur auf eine geeignete Implementierung des OSI Layer 2 (Data Link-Schicht) aufsetzen muss. Die Data Link-Schicht waere hierbei die Paketkommunikation "on air" des CC1101.
Die Implementierung der Gegenseite im CUL habe ich bis auf die Funkverbindung fertig.
Bettyseitig wuerde dann z.B. ein kleines Menue genuegen (z.B. eine Liste der Funkschaltsteckdosen mit an/aus-Knopf). Die Befehle des Menues wuerden in das anwendungsspezifische Protokoll verpackt und dann via UDP oder TCP/IP an die IP-Adresse des Heimservers geschickt. Der wertet sie aus und initiiert dann die jeweiligen Aktionen bzgl. Funkschaltsteckdosen. Ist die IP-Verbindung ersteinmal implementiert, sind der Fantasie keine Grenzen mehr gesetzt.
Gruesse,
bn
Ich hatte eigentlich vor den TAE-Adapter im Orginal zu lassen.
Er sendet Daten an eine Telefonnummer.
Ich bin selber der Telefonserver.
Wenn die Daten bei mir ankommen werfe ich die Telefonnummer weg und nehme nur die Daten.
Auf der Serverseite werde ich nur ein Telnet ansetzen. Dann werde ich schon sehen, was ankommt.
Das einzige Problem ist die Kommunikation zwischen der Betty und dem TAE.
Kannst du mir einen Tip geben,wie ich mit dem TAE von der Betty aus kommuniziere?
Vielleicht könnten mir Telekatz oder Famos helfen?
Ich fürchte, so einfach wird das nicht sein... Die Betty hat sich ja ursprünglich mit dem TAE Adapter über ein (meines Wissens) nicht bekanntes Protokoll unterhalten - dort wurden Daten bzgl. irgendwelcher Spielstände, Quizzes etc. übermittelt. Der TAE Adapter hat dann eine Verbindung zu einem Server aufgebaut und wieder mittels eines "Geheimcodes" mit diesem kommuniziert. Das letztgenannte Protokoll könntest Du Dir in der Tat über Deinen Telefonserver anschauen - vorausgesetzt, Du kennst das erstgenannte Protokoll zwischen Betty und TAE um diesen Vorgang anzustoßen...!
Ich fürchte noch viel weniger wird es Dir ohne Kenntnis dieses Protokolls gelingen, den TAE Adapter dazu zu bewegen einfach irgendwelche von Betty geschickten Daten auf die Telefonleitung zu schicken - wenn das überhaupt vorgesehen ist!
Das meinte bn damit, daß es wohl nötig sei, den TAE Adapter oder die entsprechenden Routinen in der Original-Betty-Software "reverse-zu-engineeren" .
Allerdings soll Dich das nicht abhalten, es trotzdem zu versuchen - denn die Idee dahinter finde ich durchaus gut!
JimBeam
War die RF-Kommunikation verschlüsselt?
Hatte jedes Gerät einen eigenen Schlüssel?(Kann man einen TAE nur für eine feste Betty verwenden?)
Ich dachte, Grundlage würde ein serielles Protokoll wie SLIP oder PPP sein? Ist das falsch?
Auf diesem Protokoll muss noch ein höheres liegen.
Ist jemand hier im Forum hardwaremässig in der Lage die RF-Kommunikation zwischen einer Standard-Betty und dem TAE-Adapter zu belauschen?
("Seriell" habe ich korrigiert, als ich meinen Fehler in einem Zitat entdeckte.)
War die RF-Kommunikation verschlüsselt?
Nein, für die Übertragung selbst bietet der CC1100 ein paketorientiertes Protokoll.
Hatte jedes Gerät einen eigenen Schlüssel?(Kann man einen TAE nur für eine feste Betty verwenden?)
Ich denke schon, denn es wäre ja denkbar, daß in der Nachbarwohnung ebenfalls jemand eine Betty hat - und die dürfen sich ja schließlich nicht gegenseitig beeinflussen.
Ich dachte, Grundlage würde ein Netzwerkprotokoll wie SLIP oder PPP sein? Ist das falsch?
Ich fürchte ja...
Auf diesem Protokoll muss noch ein höheres liegen.
Oder das Ganze ist rund um ein komplett anderes aufgebaut - was sehr wahrscheinlich ist, denn es ging ja bei den Betty-Games auch um Geld! Da hat man sicher Vorkehrungen getroffen, daß nicht jeder die Daten lesen/manipulieren kann.
Ist jemand hier im Forum hardwaremässig in der Lage die RF-Kommunikation zwischen einer Standard-Betty und dem TAE-Adapter zu belauschen?
Wie gesagt - es ist nicht das Problem, die RF-Kommunikation zu belauschen, das wurde meines Wissens bereits getan. Zum heutigen Stand ist nicht mal das mehr möglich, denn der Betty-Server existiert ja nicht mehr, also wird das Protokoll (bis auf den Versuch eines Verbindungsaufbaus) auch nicht aktiv werden.
Nochmal: das Problem ist, entweder
a) auf der Betty eine Software zu implementieren, die die bestehende Software im TAE Adapter dazu zu bewegt, Deine - wie auch immer gearteten - Daten über die Telefonleitung zu jagen...
oder
b) eine Software für den TAE Adapters zu schreiben, die das tut.
JimBeam