ZG2100 Wifi und AVR

Andy H. schrieb:
> Habe mir heute einen ZG2100 mitbestellt, um mal zu gucken, was das Teil
> so kann. Hat jemand das eventuell schon mal mit einem AVR
> zusammengeschaltet und ein paar Tips oder Softwarefragmente?

Andy,

hast Du inzwischen schon etwas damit gemacht ? Habe heute auch eins zum 
testen bestellt daher würden deine erfahrungen interessant sein.

kaum verfügbar schon NRND, der nachfolger ist "schon da" MRF24WB0MA aber 
natürlich nicht lieferbar.

Vorhergehender Beitrag auf Wunsch des Verfassers gelöscht:

> bitte mein posting löschen
>
> Beitrag "ZG2100 Wifi und AVR"
>
> Mouser hat sich gerade entschuldigt, interessant zu sehen
> das die auch mitlesen

Hallo Dirk,

Leider gibt es im Internet anscheinend keine Datenblätter ausser einer 
generellen Beschreibung. Von Microchip gibt es einenfrei verfügbaren 
TCP/IP Stack für PIC-Controller. Da ist auch gut dokumentierter 
Quelltext für einen ZG2100 Treiber dabei, asserdem ein Schaltplan für 
das "PIC Tail Plus" Board.

Ausserdem gibt es für den Arduino einen "WiShield", bei dem auch der 
ZG2100 bzw. dessen Nachfolger eingesetzt wird. Die Firma Asynclabs 
bietet dafür einen TCP/IP Stack inklusive Treiber zum Download an: 
https://github.com/asynclabs/WiShield.

Mit dem Treiber aus der WiShield Software lässt sich der ZG2100 auch 
prima für eigene AVR-Projekte verwenden. Nur Multicast wird 
offensichtlich nicht vom ZG2100 unterstützt; Broadcast oder Unicast ist 
aber kein Problem.

Ich habe damit eine Wireless RGB-Lampe gebaut. Ich stelle gerade die 
Doku inklusive Schaltplan und C-Quelltext dafür zusammen und werde 
dieses dann in den nächsten Tagen veröffentlichen.

Gruss aus der Schweiz,
Stefan

Hallo zusammen,

Sourcecode, Schaltplan und Windows-Client zum Fernsteuern der RGB-Lampe 
über das WLAN sind nun auf meiner Homepage veröffentlicht: 
http://www.heesch.net/wireless-rgb.aspx.

Ausserdem habe ich den Quelltext und das Schaltbild diesem Posting 
angehängt.

Gruss aus der Schweiz
Stefan

Hallo,

Hier noch ein kleines Update des Source-Codes für den ATMega 8:

- Bugfix für Initialisierung der IP-Adresse
- Zusätzliche Log-Statements zur Ablaufverfolgung über Serial-Port
- Patch für den ZG2100 Treiber um Buffer-Overflows zu vermeiden

Windows-Client und Hardware sind unverändert.

Gruss aus der Schweiz
Stefan

Hallo Holger,

Für den ZG2100 gibt es keine öffentlich zugänglichen Datenblätter. Im 
Internet wirst Du ausser ein paar Marketing-Informationen nichts finden. 
Brad Rex von Asynclab meinte, seit der Übernahme von ZeroG durch 
Microchip bräuchte man sich keine Hoffnungen auf Informationen von 
Microchip mache, wenn man eine Software für andere Microcontroller als 
PICs schreiben möchte.

Habe daher den Treiber von Asynclabs verwendet, den Brad vor der 
Microchip Übernahme mit Informationen und Unterstützung von ZeroG 
programmiert hatte.

Ich nehme an, der WRF24WBOMA ist ein Nachfolgechip des ZG2100M. Der wird 
vorraussichtlich aufwärtskompatibel sein und evtl. neue Features 
unterstützen. Wenn man in die Sourcen des IP-Stack von Microchip schaut, 
könnte man so etwas vermuten.

Viele Grüsse,
Stefan

Hallo zusammen,

ich bin heute nach stundenlanger Suche auf das Wireless RGB Projekt 
gestoßen. Ich glaub das ist genau das, was ich suche. Da ich jedoch erst 
vor kurzem in die Mikrocontroller-Welt eingetaucht bin, habe ich noch 
ein paar Fragen.

Es gibt ja verschiedene Apps, mit denen man über WLAN OSC-Befehle 
verschicken kann. Kann ich diese mit dem beschriebenen Projekt ohne 
weiteres empfangen und auswerten? Denn, das Wireless RGB Projekt ist ja 
für das UDP Protokoll ausgelegt...
Wäre es arg aufwendig, das Projekt so umzubauen, dass es OSC Signale 
empfängt, bzw. ist das überhaupt möglich?

Danke schon mal,

Gruß Philipp.

Sorry für den Doppelpost, habe gerade folgendes gefunden:
"Open Sound Control (OSC) messages are essentially specially formatted 
User Datagram Protocols (UDP) transmissions."

Damit wäre nur noch zu klären, ob es ein großer Aufwand ist, die 
empfangenen Signale auszuwerten und bzgl. ihrer OSC-Formatierung zu 
interpretieren, oder?!

Hi Philip,

in dem Wireless RGB Projekt werden Daten per UDP über das WLAN an den 
Mikrocontroller geschickt.

Der Controller behandelt dann ARP messages und erkennt auch UDP 
Datagramme. Du könntest dann einge eigene Routine schreiben, welche die 
per UDP empfangenen Daten decodiert und entsprechend behandelt. Diese 
Routine könne dann für die Auswertung OSC Nachrichten geschrieben 
werden.

Die entsprechenden Quelltextauszüge dazu findest Du auf meiner Homepage 
http://heesch.net/wireless-rgb.aspx im Abschnitt der 
Softwarebeschreibung.

Im Quelltext des Wireless RGB controllers müsstest Du dazu die Funktion 
"void HandleAmbientColorMessage( char* msg )" durch Deine eigene Routine 
ersetzen.

Die OSC Protokolldefinition findest Du übrigens hier: 
http://opensoundcontrol.org/spec-1_0

Viel Erfolg und beste Grüsse aus der Schweiz,
Stefan

Hi Stefan,

vielen Dank für die schnelle Antwort! Super, so hab ich mir das in etwa 
vorgestellt. Dann werd ich mir mal das Wifi-Proto bestellen und 
loslegen.

Übrigens großes Lob an deine Homepage und die übersichtliche 
Dokumentation!

Viele Grüße,

Philipp.

Hallo,

hab mir auch das WIFI Proto gekauft. Versuch es schon seit fast einer 
Woche zum laufen zu bringen. Leider auch etwas schwierig, weil ein 
Datenblatt zum Beschreiben der Register nicht vorhanden ist.

Zur Hardware: Aufgebaut hab ich diese nach dem Schaltplan von Stefan 
Heesch.
Als Treiber hab ich den von Asynclabs in verwendung.

Mein Problem ist nun folgendes:
Wenn ich den Datenaustausch der SPI leitung betrachte, bekomme ich keine
antwort vom Slave (Wifi Proto). Also immer nur 0x00 zurück. Nach 
mehrmaligem Reset meines AVRs bekomme ich manchmal dann aber auch 
"richtige" daten vom WIFI Proto zurück. Noch seltener funktioniert der 
WLAN Aufbau dann aber auch. Verbindung über ADhoc hergestellt, dann ist 
es auch möglich die nachrichten hin und her zu schicken. Nach einem 
Reset des AVR kann aber dann wieder keine verbindung aufgebaut werden. 
Manchmal bekomm ich auch immer nur lauter 0x04 oder 0x80 oder 0xff vom 
WIFI Proto zurück.

Warum antwortet das WIFI Proto nicht richtig? Komisch ist für mich nur 
das es mit der Software und der Hardware schon mal funktioniert hat.