AVR Wi-Fi und Smartphones

Hallo,

Florian schrieb:
> Meines Erachtens brauche ich hier doch kaum TCP/IP Fähigkeiten bzw.
> Stack am µC da ich ja nur Daten senden möchte, aber keine wirklichen
> Netzwerkzugriffe mache oder?

das kommt denke ich mal auf dein Modul an. Wenn dies den kompletten 
Stack-Kram übernimmt und dir die Daten meinetwegen per SPI/Uart/I²C/USB 
oder sonst irgenteine Schnittstelle bereit stellt, dann brauchste das 
nicht.
Sollte das Modul aber ein reines Sende/Empfangsmodul sein, wo du alles 
"zu Fuß" lösen musst, dann brauchste so ein Stack.

Mal ganz davon abgeseheen: Ist Wi-Fi nicht mit Wlan gleichzusetzen. Weil 
laut google ist das nur ein Marketing-Name für Wlan, der dem User 
irgentetwas suggerieren soll.

Florian schrieb:
> Ich weiß dass es mit Bluetooth einfacher wäre, aber viele Smartphones
> haben selbiges leider nicht.

Wieso sollten sie sowas nicht haben? Was machen denn dann die ganzen 
Chefs mit ihren Headsets? Wichtig ist doch erstmal hat DEIN Smartphone 
BT. Wenn ja kannst du ein BTM-222 modul verwenden, diese stellt dann 
direkt einen Uart auf der anderen Seite bereit und du brauchst nur die 
Daten einlesen.

Grüße
Tobi

Florian schrieb:

> Hat hiervon jemand Erfahrung/Ahnung und kann mir dazu eventuell ein paar
> Informationen geben?

Schau hier:

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2884

Da gibt es kleine WiFi Module, die über SPI angesprochen werden, und es 
gibt einen fertigen TCP/IP-Stack, der diese Module ansteuern kann. Das 
kannst Du so für Dein Projekt verwenden. Häkchen dabei: Du wirst einen 
PIC benutzen müssen, weil der TCP/IP-Stack und der WLAN-Treiber nur 
damit funktioniert und nur dafür lizensiert ist. Das sollte aber auch 
kein großes Problem sein. Du lädst Dir das MPLAB8, den C-Compiler für 
die Architektur, die Du verwenden willst (PIC18, PIC24/dsPIC, PIC32) und 
kaufst ein PICKIT3, und damit hast Du alles beisammen.

fchk

Welches Smartphone hat denn bitteschön kein Bluetooth? Das war ja noch 
vor WLAN Serienausstattung.

Klar geht das über WLAN auch, ist aber um ein vielfaches aufwendiger.

Florian schrieb:

> Welches Protokoll sollte ich da verwenden? UDP oder soetwas? weil HTTP
> Protokoll bräuchte ich ja nur wenn ich eine Web Oberfläche machen
> möchte, aber ich möchte ja rein Daten übertragen.

UDP: Blockorientiert, kein Schutz gegen Paketverlust (das muss die 
Anwendung abkönnen oder selber behandeln)
TCP: Stromorientiert, Schutz gegen Paketverlust

Installiere Dir die Microchip Application Libraries und schaue Dir das 
GenericTCPServer bzw GenericUDPServer Beispiel an. Das kannst Du dann 
nach Deinen Bedürfnissen erweitern.

fchk

Florian schrieb:

> Wäre für mich nicht die UART Funktion interessanter ?

Nein, das ist ein Gateway zwischen dem physikalischen UART und einem 
TCP-Socket. GenericTCPServer ist das passende Beispiel.

fchk

Florian schrieb:

> Ja ich dachte eventuell, dass ich den PIC als eigenständigen UART - WLan
> übersetzer nehme, und den Rest per AVR mache ( Da habe ich schon alles
> Programmiert )

Das ist technisch gesehen Unsinn - der PIC könnte das sicher problemlos 
mitmachen. Außerdem hat das UART-Beispiel kein Handshake.

Aber natürlich kann man das so machen.

fchk

Florian schrieb:

> Ich weiß dass es technisch wirklich schlecht ist, aber ich habe den rest
> eben schon Programmiert am AtMega644 und würde deshalb gerne das ganze
> einfach per UART anschließen.

Du hast das sicher in C programmiert. Dann solltest Du das auch 
einigermaßen einfach portieren können.

> Wie schlecht ist es denn, wenn kein Handshake dabei ist ?

Ziemlich. Außerdem brauchst Du den UART für die initiale Konfiguration, 
wenn Du das Beispiel so 1:1 verwenden willst.

Außerdem weiß Deine Anwendung nicht, ob überhaupt eine Verbindung 
besteht. Du sendest und empfängst also praktisch blind.

> Das ganze wird doch dann per TCP Protokoll gesendet richtig?

Ja.

> Eventuell fehlt mir das Verständnis für TCP/IP aber ist das ganze steht
> doch als Ad-Hoc Netzwerk zur Verfügung. Angenommen ich verbinde mich
> dann darauf mit einem PC, so habe ich dann die IP von meinem Gerät, wie
> kann ich nun die Daten abgreifen die per TCP kommen ? Ich meine jetzt
> zb. ob die wenn ich ein Programm wie Putty starte und das richtige
> Protokoll auswähle einfach so reinpurzeln oder wie das genau
> funktioniert?

Bei TCP muss irgendeine Seite Server und irgendeine Seite Client sein. 
Der Client verbindet sich zum Server, und dann können Daten übertragen 
werden, bis die Verbindung beendet wird. Putty wäre ein möglicher Telnet 
bzw SSH Client.

Bei UDP gibts keine Verbindung. Da kannst Du einfach so senden, und wenn 
einer zuhört, dann empfängt er das auch. Wenn nicht, dann geht das Paket 
verloren.

Dann ist noch die Frage der IP-Adressen. Wie werden die zugeordnet? Wie 
finden sich die beiden Teilnehmer? Da weiß ich nicht, was auf Deinem 
Smartphone konfigurationstechnisch geht.

Möglicherweise wirst Du beides brauchen - UDP Broadcasts zum Finden des 
Gerätes und TCP für die eigentliche Datenübertragung.

Da Du ohnehin auf dem PIC entwickeln werden wirst (die Beispiele sind 
Beispiele, die musst Du noch an Deine eigenen Wünsche anpassen), und 
zwar nicht zu knapp, kannst Du auch gleich das gesamte Projekt dadrauf 
machen.

fchk

Florian schrieb:

> Also am liebsten wäre mit, dass die PIC/Wlan Kombi als Server dient. Ich
> schalte das Smartphone ein, suche nach Wlan, finde es und verbinde mich,
> IP Adressenvergabe wäre natürlich am schönsen per DHCP, damit sollte der
> Default Gateway auch schon feststehen ( PIC/Wlan Kombi )

Ich glaube, einen DHCP-Server und einen DNS-Server in dem Paket gesehen 
zu haben. Ich habe ihn aber noch nicht ausprobiert. Ich denke, Du wirst 
ihn anpassen müssen.

fchk

Florian schrieb:

> Eine Frage bleibt da noch offen, undzwar, wenn das Servermäßig alles
> klappt und ich eine Verbindung zum PC habe, wie kann ich die Daten dann
> bekommen ?

Winsock2 heißt das Stichwort bei der PC-Programmierung.

fchk