Forum: Mikrocontroller und Digitale Elektronik WLAN / WIFI Modul für µC - Erfahrungen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe zwar einige Beiträge gefunden, wo es darum ging, einen 
Mikrocontroller mit dem heimischen WLAN zu verbinden, aber keiner hat 
bisher über eine einfache preiswerte Lösung berichtet.

Hat von Euch schon Jemand Erfahrung mit dem WRL-3000 von embedded 
adventures? Oder gibt es bessere Alternativen?

"No stack is required on the side of the microcontroller." :-)

http://www.embeddedadventures.com/cc3000_wifi_module_wrl-3000.html

Preis: € 19,37 + Versandkosten

Die Versandkosten:  €8.74 für "Royal Mail (tracked)". Hier könnten wir 
im Forum "Markt" eine Sammelbestellung organisteren, falls Interesse 
besteht.

Das BTM-222 kostet zwar nur rund die Hälfte, aber für viele 
Anwendungen ist WLAN besser geeignet als Bluetooth.

Die Idee mit dem Zusatzmodul finde ich deshalb gut, weil man seine 
Systeme preiswert hält, falls WLAN optional ist. Wer WLAN will, bestückt 
einfach ein solches Modul.

Wenn mir niemand davon abrät, bestellei ich in den nächsten Tagen 2 
Module zum testen.

VG Torsten

von Georg G. (df2au)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Hier könnten wir
> im Forum "Markt" eine Sammelbestellung organisteren, falls Interesse
> besteht.

Der Schuss kann nach hinten rausgehen. Bei einem Exemplar und etwas 
Wohlwollen des Zollbeamten kommst du ohne Abgaben davon. Bei mehreren 
Exemplaren hast du Zoll und Einfuhrumsatzsteuer sicher.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Georg G. schrieb:
> Zoll und Einfuhrumsatzsteuer

Ich dachte, "ea" sitzt in London ("Royal Mail" ^^). Fällt da auch Zoll 
an?

von Georg G. (df2au)


Bewertung
0 lesenswert
nicht lesenswert
Sorry, war automatisch auf China gepolt. Aus GB ist die Einfuhr frei.

von Bassti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Aha, du ließt die Produktbeschreibung des Modulherstellers und das wars?

"No stack is required on the side of the microcontroller."

Ja, jedenfalls kein TCP/IP Stack... aber da gibts viele Module...

Das CC3000 ist jedenfalls nen heißes Eisen (seit dem TI die Firmware 
endlich halbwegs Bugfrei hat)... aber mit dem Einsatz wirst du es nicht 
zum laufen bringen...

Grüße

Basti

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bassti schrieb:
> mit dem Einsatz wirst du es nicht zum laufen bringen
Wie meist Du das?

Zu meiner Frage^^: Hast Du denn schon Erfahrung mit dem WRL-3000?

Hast Du's hinbekommen, so wie Du wolltest?

Mir geht es um den Erfahrungsaustausch in diesem Forum.

Sollte man mit der Bestellung noch warten, bis weitere Bugs beseitigt 
sind?

von Basti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ich meinte: wenn du so viel Energie in die Produktauswahl wie in das 
anschließende Programmieren steckst, wird es nix...

Such mal im Forum oder überhaupt nach CC3000, ich hab hier schon mal was 
geschrieben... Mein Durchbruch ist nah... das schwieirge is mit der 
sauigen TI beschreibung den Treiber portieren. Die haben ja kein 
besonderes Interesse daran, dass du TI fremde Kontroller benutzt... Das 
Softwareupdaten ohne das es meist nicht gut zu gebrauchen ist, wir 
schierigkeit nr. 2

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt übrigens 1 bis 2 Breakout-Board(s) von TI, ähnlich dem WRL-3000:
CC3000EM (2mm Raster der Anschlüsse)
https://estore.ti.com/CC3000EM-CC3000-Evaluation-Module-P4257.aspx
CC3000BOOST (Anschluesse und deren Abstand unbekannt)
https://estore.ti.com/CC3000BOOST-CC3000-BoosterPack-P4258.aspx

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> ich habe zwar einige Beiträge gefunden, wo es darum ging, einen
> Mikrocontroller mit dem heimischen WLAN zu verbinden, aber keiner hat
> bisher über eine einfache preiswerte Lösung berichtet.

Verstehe ich auch nicht, den eigentlich ist es ganz einfach:

1) Ein WLAN-seriell-Modul ist einfach anzubinden und zu konfigurieren, 
aber nicht flexibel (kein JavaScript) z.B.:

http://www.rovingnetworks.com/products/RN_131_PICtail

Ist mit PIC-Rabatt, läuft aber auch mit NXP ARM ohne Änderungen.

2) Ein "echtes" WLAN-Modul ist ohne API vom Hersteller kaum zum Laufen 
zu bringen, es gibt aber mit API und Demo-Webserver (mit JavaScript, 
AJAX POST), z.B. für Atmel ARM:

http://www.redpinesignals.com/Modules_&_M2M_systems/M2M_Systems/Wi-Fi_Starter_Kits/Atmel/rs-sam3s.php

Und der Port auf NXP ARM:

http://www.lpc4350.com/lpc43xx/Examples/WIFI/

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Verstehe ich auch nicht, den eigentlich ist es ganz einfach

Für Bluetooth gib's ja einen schönen Artikel: BTM-222. Darin steht:

  "Es gibt am Markt eine Reihe verschiedener Module, welche verschiedene
   Kriterien erfüllen, die je nach Anwendung relevant sein können. … Aus
   der Vielzahl an Angeboten sticht vor allem das Modul … hervor, da es
   bei kleinen Abmessungen leistungsfähig ist, relativ einfach in eigene
   Schaltungen integriert werden kann und zu einem relativ günstigen
   Preis frei verfügbar ist."

Ich würde (mit Eurer Unterstützung) gern so einen Artikel für ein 
WLAN-Modul im Wiki anlegen.

Basti schrieb:
> wenn du so viel Energie in die Produktauswahl wie in das
> anschließende Programmieren steckst, wird es nix...

Eins nach dem anderen. Ich möchte nicht erst alle ausprobieren, bevor 
ich mich entscheide. Es wär' doch blöd, sich auf Datenblätter und 
Werbeaussagen allein zu verlassen, wenn es hier im Forum schon 
Erfahrungswerte gibt.

Die Aussagen klingen ja alle ganz nett: "The development board is 
updated and controlled with a simple ASCII command language." oder 
"Comprehensive module documentation."

Der Preisunterschied ist eher nicht das Argument:

RN-131-PICtail: ab ca. 35€
WRL-3000:       ab ca. 22€

Für welches Modul würde so eine Aussage wie "Aus der Vielzahl an 
Angeboten sticht vor allem das Modul … hervor." ^^ denn am ehesten 
gelten?

Das BTM-222 kann ja z.B. nur einen "virtuellen seriellen Port". Für 
einfache WLAN-Anwendungen reichen  m.E. die Funktionen "access point 
finden", ..., "authentifizieren", ..., DHCP und Telnet.

HTTP z.B. kann man einfach selbst programmieren, wenn man es braucht, 
Code-Beispiele gibt's dafür genug. Und JavaScript wäre aus meiner Sicht 
"overkill". Das wäre m.E. eher was für einen Raspberry Pi.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Ich würde (mit Eurer Unterstützung) gern so einen Artikel für ein
> WLAN-Modul im Wiki anlegen.
> ...
> Für welches Modul würde so eine Aussage wie "Aus der Vielzahl an
> Angeboten sticht vor allem das Modul … hervor." ^^ denn am ehesten
> gelten?

Nur, weil ein Wiki ein Wiki ist, hat es noch keine magischen Kräfte, und 
drei Wünsche erfüllt es auch nicht. Die Grundregel, daß man wissen muß, 
über was man schreibt, wenn man was schreiben will, gilt auch dort. 
Klingt blöd, ist aber so.

Aber du bist ja auf einem guten Weg. Kauf die Module, bring sie zum 
laufen, und dann schreib dein dadurch erworbenes Wissen ins Wiki. Alle 
anderen haben das auch so gemacht.

Oliver

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Thorsten:
Kannst Du C programmieren oder zumindest verstehen?
Die TI Software ist in C geschrieben.
Welchen uC planst du für das WRL-3000 einzusetzen?
Hast du vorher schon mal was mit dem uC gemacht?
Bist du Schüler oder hast du beruflich etwas mit Elektronik zu tun?
Wie viel Erfahrung bringst du mit?
Hast du einen Logic Analyzer, der SPI (evt. auch I2C) versteht?
Hattest du mit SPI schon mal was gemacht?

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Kauf die Module …

Zu zwei Modulen würde ich mich noch breitschlagen lassen, wenn es zwei 
sind, die das o.g. Attribut "… sticht hervor, da …" verdienen könnten. 
Mehr ist mir in meiner knappen Freizeit zu aufendig. Meine Hoffnung ist, 
dass Ihr helfen könnt, welches Modul oder welche zwei Module das sein 
könnten.

Martin schrieb:
> Kannst Du … Hast du … Bist du … Hattest du …

Ich verstehe, dass es "Perlen vor die Säue" wäre, hier mit einem "Troll" 
zu diskutieren. Aber unabhängig vom Wiki-Artilel und meiner Person wäre 
es doch schön, wenn diejenigen, die bereits mit verschiedenen Modulen 
Erfahrungen sammeln konnten, einen Hinweis geben könnten, in welche 
Richtung der geneigte Forums-Leser gehen sollte, wenn z.B. Telnet 
reicht.

Ich arbeite seit 17 Jahren in der Elektronik-Entwicklung. Meine 
embedded-Erfahrungen stammen aber vornehmlich aus meinen 
Hobby-Aktivitäten. In der Firma muss ich eher mit Powerpoint und Matlab 
arbeiten. ;-)

> Welchen uC planst du für das WRL-3000 einzusetzen?

Ein wichtiger Punkt für "… sticht hervor …" ist, dass sich die Frage 
möglichst gar nicht stellt. Weniger ist hier m.E. mehr. Das BTM-222 
kommt z.B. mit 'nem AT-Befehlssatz aus. Da stellt sich die Frage nicht. 
Und wenn es nur eine Handvoll Befehle gibt, um einen Telnet-Kanal mit 
einem Port an einer IP-Adresse (von mir aus ohne Root-Nameserver) 
aufzubauen, reicht das für die meisten.

Meine Antwort: Das ist mir fast Egal, so lange es kein "Exot" ist. 
MSP430Gxxxx, STM32F4… und LPC1347 hätte ich griffbereit, mit 
installierter Toolchain. Meinen AVR-Dragon habe ich noch nicht 
ausprobiert, der ist erst letzt Woche gekommen.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Und JavaScript wäre aus meiner Sicht
> "overkill". Das wäre m.E. eher was für einen Raspberry Pi.

Keineswegs, das braucht man, wenn der MC Messdaten an PC oder Smartphone 
senden soll. Anstatt jedesmal die ganze HTML-Seite neu zu senden, wird 
per POST nur der geänderte Messwert gesendet. Das geht schon mit uIP und 
ATmega, per Ethernet. Aber für WLAN braucht es dann eben kein serielles 
Modul sondern SPI-Modul und API, um selbst den TCP-Stack zu machen. Und 
da würde ich ein Modul mit offenem API und Webserver-Demo nehmen.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Anstatt jedesmal die ganze HTML-Seite neu zu senden, wird
> per POST nur der geänderte Messwert gesendet.

Es geht doch nur ein paar Zeilen, die per Telnet gesendet werden müssen. 
Wo nutzt Du da Javascript? Ob Du nun GET oder POST in die erste Zeile 
schreibst, ist doch egal.

Lothar schrieb:
> um selbst den TCP-Stack zu machen

Wie ist denn der Satz "No stack is required on the side of the 
microcontroller." ^^ gemeint?

Bei 40€ erwarte ich, dass einem das Modul die meißte Arbeit abnimmt. So 
war das gemeint,
als ich schrieb:
> Die Idee mit dem Zusatzmodul finde ich deshalb gut, weil man seine
> Systeme preiswert hält, falls WLAN optional ist. Wer WLAN will, bestückt
> einfach ein solches Modul.

Torsten C. schrieb:
> Martin schrieb:
>> Welchen uC planst du für das WRL-3000 einzusetzen?
> Das ist mir fast Egal, so lange es kein "Exot" ist.

"Universell einsetzbar" sollte das Modul aber sein, z.B. auch auf'nem 
MSP430G…. Es gibt zwar z.B. den MSP430 uIP Port, aber: "Der 
RAM-Bedarf ist schon eher schmerzhaft."

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> das braucht man, wenn der MC Messdaten an … Smartphone
> senden soll.

PS: Gibt's denn Web-Server für Smartphones? Oder sprichst Du von 
Java-Script auf dem Browser auf dem Client?

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
>> Kannst Du … Hast du … Bist du … Hattest du …
> Ich verstehe, dass es "Perlen vor die Säue" wäre,
> hier mit einem "Troll" zu diskutieren.

Mir ging es eigentlich mehr darum, ob du mit SPI zurecht kommst.
Wenn du noch nie etwas mit SPI gemacht hast und
auch keine passenden Messgeräte hast,
dann würde ich dir vom WRL-3000 abraten.
Selbst bei einem CC3000 kompatiblen Modul mit TI Software,
bei dem man eigentlich nicht mit dem SPI in Berührung kommen sollte,
ist es immer wieder mal notwendig, den SPI zu tracen um zu sehen,
was jetzt eigentlich schief läuft und warum.

Der CC3000 ist ein netter Chip, aber er ist auch nicht ganz einfach.

Er braucht außen zwingend einen uC, der ihn steuert.
Er ist nicht wie manches Bluetooth-Modul,
welches man konfiguriert und es dann transparent einen Telnet
auf einen RS232 umsetzt. Du kannst aber mit dem uC den CC3000
so bedienen, dass er eine Telnet-Verbindung annehmen kann
oder auch selbst aufbaut. Der uC nimmt dann Datenpakete an
und leitet sie an die serielle Schnittstelle weiter und umgekehrt.

Falls du trotzdem einen CC3000 Chip einsetzen willst,
dann würde ich mich erst einmal in SPI einarbeiten.
Mal nur 1 Byte senden, schauen ob Clk aus dem Chip kommt,
ob Daten aus dem Chip kommen.
Dann mal 1 Byte empfangen, die Leitung fest auf 0 oder 1 legen,
damit man sieht, ob man 0x00 und 0xFF empfangen kann usw.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> Falls du trotzdem einen CC3000 Chip einsetzen willst,
> dann würde ich mich erst einmal in SPI einarbeiten.

Achso. Also das sehe ich eher als "Pipifax". Vor einen TCP-IP-Stack 
hätte ich schon mehr Respekt.

Torsten C. schrieb:
> Wenn mir niemand davon abrät, bestelle ich in den nächsten Tagen 2
> Module zum testen.

Das ist dann wohl der nächste Schritt. :-)

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Es geht doch nur ein paar Zeilen, die per Telnet gesendet werden müssen.
> Wo nutzt Du da Javascript? Ob Du nun GET oder POST in die erste Zeile
> schreibst, ist doch egal.

Für Telnet reicht natürlich ein WLAN-seriell-Modul, und man braucht gar 
kein GET/POST.

Torsten C. schrieb:
> Wie ist denn der Satz "No stack is required on the side of the
> microcontroller." ^^ gemeint?

Das der Stack auf einem internen MC im WLAN-seriell-Modul läuft und man 
nicht ran kommt. Dieser Stack unterstützt ein Filesystem, in das vom 
externen MC HTML-Dateien abgelegt werden können (index.html etc). Aber 
man kann sonst nichts machen (C-Funktionen die Datenfelder bestücken, 
UDP-Messages, und eben GET/POST Requests).

Mit POST per JavaScript kann man HTML-Seiten dynamisch updaten (z.B. 
Diagramme), nennt sich JSON/AJAX.

Torsten C. schrieb:
> PS: Gibt's denn Web-Server für Smartphones? Oder sprichst Du von
> Java-Script auf dem Browser auf dem Client?

Gibt es (jetty), aber ich meinte schon JavaScript im Client, nur muss 
der MC-Webserver ja das JavaScript hin senden, und die GET/POST handeln.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Da das WRL-3000 am billigsten ist, fange ich damit an, ohne 
Sammelbestellung. Ich habe hier noch 4 Launchpads rumliegen, also 
probiere ich dann dieses Beispiel aus und melde mich dann wieder:

http://processors.wiki.ti.com/index.php/CC3000_Basic_Wi-Fi_example_application_for_Launchpad

Lothar schrieb:
> Für Telnet reicht natürlich ein WLAN-seriell-Modul, und man braucht gar
> kein GET/POST.

Nein, braucht man nicht notwendig. Aber selbst meine "Zeitschaltuhr" hat 
einen Webserver drin. Und falls man sowas machen will, reichen Telnet 
und ein paar Zeilen C-Code.

Habe ich das richtig gesehen? Das RN-131 sendet am Anfang jeder 
Telnet-Session ersmal ein "*HELLO*"? Wie soll man denn damit einen 
http-Server erstellen.

Lothar schrieb:
> aber ich meinte schon JavaScript im Client
Wenn das so ist, dann habe ich Deinen Satz:
> Ein WLAN-seriell-Modul ist … nicht flexibel (kein JavaScript)
nicht verstanden.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
>> aber ich meinte schon JavaScript im Client
> Wenn das so ist, dann habe ich Deinen Satz:
>> Ein WLAN-seriell-Modul ist … nicht flexibel (kein JavaScript)
> nicht verstanden.

Man lege auf dem WLAN-seriell-Modul eine HTML-Datei mit JavaScript ab, 
in dem ein POST Request ist:

http.open(POST, URL, true);

Der Browser lädt das, und der POST Request wird an den Server gesendet. 
Der TCP-Stack im WLAN-seriell-Modul unterstützt aber kein POST, es 
passiert also gar nichts.

Wenn der TCP-Stack auf dem MC läuft, kann man das POST abfangen und z.B. 
einen Messwert als Text an den Socket zurücksenden, und der Callback im 
JavaScript liest den ein (Auf einem PC-Server würde das z.B. Apache/PHP 
machen). Um aber den TCP-Stack auf dem MC zu haben braucht es ein 
"echtes" WLAN-Modul mit API das die Netzwerkfunktionen anbietet (Socket 
öffnen, schliessen etc).

Hier z.B. würde meine Funktion http_reply_create() den Messwert abholen:

THREAD(handle_input(struct httpd_state *s))
{
  PSOCK_BEGIN(&s->sin);
  ...
  if (strncmp(s->inputbuf, http_post, 5) != 0)
  ...
  if(s->inputbuf[1] == ISO_space) {
    strncpy(s->filename, http_index_html, sizeof(s->filename));
  } else {
    if (reply_shmtl)
    { http_reply_create(&s->inputbuf[0]);
      strncpy(s->filename, http_reply_shtml, sizeof(s->filename)); }
      else {
      s->inputbuf[PSOCK_DATALEN(&s->sin) - 1] = 0;
      strncpy(s->filename, &s->inputbuf[0], sizeof(s->filename));
    }
  }
  ...
}

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Der TCP-Stack im WLAN-seriell-Modul unterstützt aber kein POST

Ach sooo, nun habe ich Dich verstanden. Danke.

Ich hoffe, ich war nicht der einzige hier im Thread, der so lange 
gebraucht hat, bis der Groschen fällt.

Ich wäre gar nicht auf die Idee gekommen, das WLAN-seriell-Modul 
HTTP-Requests bearbeiten zu lassen. Im Prinzip ist HTTP ja nichts 
anderes, als ein paar Zeichen per Telnet auszutauschen.

Kann man nicht einfach 'ne JSON-Datei im Filesystem regelmäßig 
überschreiben? Oder kann das WLAN-seriell-Modul im Header kein
Content-type: application/json; charset=utf-8
?

GET oder POST ist doch egal: Schreibe die Daten in die URL.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Torsten C. schrieb:
>> Und JavaScript wäre aus meiner Sicht
>> "overkill". Das wäre m.E. eher was für einen Raspberry Pi.
>
> Keineswegs, das braucht man, wenn der MC Messdaten an PC oder Smartphone
> senden soll. Anstatt jedesmal die ganze HTML-Seite neu zu senden, wird
> per POST nur der geänderte Messwert gesendet.

Wie höchst unsinnig. Warum sollte man für sowas ausgerechnet HTTP 
verwenden wollen? Ist das ein Fall von "Wenn man als einziges Werkzeug 
einen Hammer hat, sieht jedes Problem aus wie ein Nagel" ?

Und selbst wenn: wieso braucht man zum Senden eines simplen GET oder 
POST Requests mit ein paar angehängten Daten JavaScript? Warum sollte 
der µC irgend etwas außer dem HTTP Statuscode vom Webserver lesen, 
geschweige denn interpretieren?


XL

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Warum sollte
> der µC irgend etwas außer dem HTTP Statuscode vom Webserver lesen,
> geschweige denn interpretieren?

Es geht darum, dass ein Webserver oder ein Client Messdaten vom µC 
ausliest.

Mit JavaScript kann man dafür auf einem Client einen Webbrowser 
vergewaltigen. Es geht dann aber nur um statischen JavaScript-Code, der 
als <script> in der HTML-Datei liegt.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Wie höchst unsinnig. Warum sollte man für sowas ausgerechnet HTTP
> verwenden wollen? Ist das ein Fall von "Wenn man als einziges Werkzeug
> einen Hammer hat, sieht jedes Problem aus wie ein Nagel" ?
>
> Und selbst wenn: wieso braucht man zum Senden eines simplen GET oder
> POST Requests mit ein paar angehängten Daten JavaScript? Warum sollte
> der µC irgend etwas außer dem HTTP Statuscode vom Webserver lesen,
> geschweige denn interpretieren?

??? Der MC ist doch der Webserver ???

Was GET/POST betrifft, vielleicht mal in Wikipedia nachsehen:

http://en.wikipedia.org/wiki/Ajax_%28programming%29

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Der MC ist doch der Webserver

Der MC-Webserver muss aber kein JavaScript können. Das hatte ich bei Dir 
auch erst nicht verstanden.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Dieser Stack unterstützt ein Filesystem

PS: Wo ist das eigentlich gespeichert? Im RAM? Oder im Flash?

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Für Bluetooth gib's ja einen schönen Artikel: BTM-222.
...
> Ich würde (mit Eurer Unterstützung) gern so einen Artikel für ein
> WLAN-Modul im Wiki anlegen.

Oliver S. schrieb:
> du bist ja auf einem guten Weg. Kauf die Module, bring sie zum
> laufen, und dann schreib dein dadurch erworbenes Wissen ins Wiki. Alle
> anderen haben das auch so gemacht.

Torsten C. schrieb:
> Zu zwei Modulen würde ich mich noch breitschlagen lassen, wenn es zwei
> sind, die das o.g. Attribut "… sticht hervor, da …" verdienen könnten.
> Mehr ist mir in meiner knappen Freizeit zu aufendig. Meine Hoffnung ist,
> dass Ihr helfen könnt, welches Modul oder welche zwei Module das sein
> könnten.

Dann fang einfach an. Schreib einfach einen Artikel zu einem Modul 
mit dem du praktische Erfahrung hast. Das reicht doch für den Anfang.

Wenn dann jemand anders ein anderes Modul getestet hat, schreibt er 
seinen eigenen Artikel dazu. Die Einzelartikel faßt man in einer 
gemeinsamen Kategorie zusammen. Und wenn irgendwann mal genug Artikel da 
sind macht man entweder einen Übersichtsartikel oder faßt die 
vorhandenen Artikel in einem summarischen Artikel "Erfahrungen mit 
WLAN-Modulen" zusammen.

Das wesentliche an einem Wiki ist doch, daß es einem einfach macht, 
schnell anzufangen ("wiki" heißt "schnell"). Denn wie immer ist der 
Anfang das Schwerste. Der andere wesentliche Punkt ist Kollaboration. 
Mach deinen Teil. Mach ihn ordentlich. Und laß andere ihren Teil 
beitragen. Du mußt die Welt nicht alleine retten.


XL

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Schreib einfach einen Artikel zu einem Modul

Ich bin kein Computer, der Befehle interpretiert und ausführt. ;-) 
Begründung s.o., ich habe auch noch einen Job und 'ne Familie.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Axel Schwenke schrieb:
>> Warum sollte
>> der µC irgend etwas außer dem HTTP Statuscode vom Webserver lesen,
>> geschweige denn interpretieren?
>
> Es geht darum, dass ein Webserver oder ein Client Messdaten vom µC
> ausliest.

Wie herum denn nun? Soll der µC Webserver sein oder Client?

Wenn er Server ist, dann muß er Javascript nicht ausführen, sondern nur 
als Teil der ausgelieferten HTML-Seite senden.

Wenn er Client ist, dann kann er doch einfach immer dann wenn er neue 
Daten hat (ersatzweise alle N Sekunden) einen HTTP-Request mit den 
aktuellen Daten absetzen. Und auch dann braucht er kein Javascript zu 
können. Auch AJAX kommt hier überhaupt nicht ins Spiel. Der µC muß kein 
bisschen HTML parsen können. Er muß nur einen standardgemäßen GET- oder 
POST-Request absetzen und vielleicht der Höflichkeit halber den 
HTTP-Statuscode im Response überprüfen (damit er z.B. bei 404 oder 500 
nicht sinnlos weitersendet).

Diese Art der Verwendung (ließ: Mißbrauch) des HTTP-Protokolls ist recht 
weit verbreitet. Das heißt aber nicht, daß es eine besonders brilliante 
Idee wäre. Es ist eher etwas für gehandicapte Heimwerker - die eben 
ausschließlich einen Hammer besitzen und deswegen auch Schrauben damit 
einschlagen.


XL

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Axel Schwenke schrieb:
>> Schreib einfach einen Artikel zu einem Modul
>
> Ich bin kein Computer, der Befehle interpretiert und ausführt. ;-)
> Begründung s.o., ich habe auch noch einen Job und 'ne Familie.

Wenn ich dich nochmal zitieren darf:

Torsten C. schrieb:
> Ich würde (mit Eurer Unterstützung) gern so einen Artikel für ein
> WLAN-Modul im Wiki anlegen.

Und meine Antwort hat sich nicht geändert: Machs halt
Nicht labern. Machen!


XL

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Wenn er Server ist, dann muß er Javascript nicht ausführen, sondern nur
> als Teil der ausgelieferten HTML-Seite senden.

Erst lesenn dann schreiben.
Genau das ich schrieb:
> Der MC-Webserver muss aber kein JavaScript können.

(So spricht der kleine grüne in Star Wars)

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Nicht labern. Machen!

Jetzt muss ich erstmal die Zeit überbrücken, bis das bestellte ^^ 
WRL-3000 da ist. Abgeraten hat mir ja niemand.

Das RN-131 ist aktuell nicht direkt lieferbar. Bei Mouser müsste ich auf 
die nächste Sammelbestellung warten, sonst wird's zu teuer.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Axel Schwenke schrieb:
>> Wenn er Server ist, dann muß er Javascript nicht ausführen, sondern nur
>> als Teil der ausgelieferten HTML-Seite senden.
>
> Erst lesenn dann schreiben.
> Genau das ich schrieb:

Das ist mir klar. ich antworte aber nicht dir allein (Tip: das ist ein 
Forum, keine EMail-Korrespondenz). Und Lothar (Gast) hängt irgendwie auf 
dem Trip fest, daß der µC der HTTP-Client sein soll. Daß der gar eine 
AJAXisierte Seite von seinem Gegenpart laden soll, um dann asynchron 
GET/POST Requests mit seinen Daten abzusetzen. Anscheinend ist er ein 
Zimmermann ;)


XL

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Und Lothar (Gast) hängt irgendwie auf
> dem Trip fest, daß der µC der HTTP-Client sein soll.

@Lothar: Stimmt das? Ich dachte gerade, ich hatte Dich verstanden.

BTW: Der Preis für das WRL-3000 ^^ war netto zzgl. VAT.

Axel Schwenke schrieb:
> Wenn dann jemand anders ein anderes Modul getestet hat, schreibt er
> seinen eigenen Artikel dazu.

Gibt es mehr als einen Artikel zu Bluetooth-Modulen? Ich arbeite in 
meiner knappen Freizeit nicht gern für den "Papierkorb".

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Und Lothar (Gast) hängt irgendwie auf
> dem Trip fest, daß der µC der HTTP-Client sein soll. Daß der gar eine
> AJAXisierte Seite von seinem Gegenpart laden soll, um dann asynchron
> GET/POST Requests mit seinen Daten abzusetzen.

Quatsch: Browser ist Client und MC ist Server. Steht so da:

Lothar schrieb:
> Der Browser lädt das, und der POST Request wird an den Server

Der Browser wird wohl kaum auf dem MC laufen ...

> Wenn der TCP-Stack auf dem MC läuft, kann man das POST abfangen und z.B.
> einen Messwert als Text

Der MC bekommt den POST, ist also Server ...

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Der MC bekommt den POST, ist also Server ...

Wieviel Parameter-Kombinationen können denn im POST auftauchen?

Wenn du für jede denkbare Parameter-Kombination eine Datei anlegst, geht 
das auch per GET.

Wie gesagt: Direkt die GET-Requests über Telnet in C auswerten, dann 
muss man sich nicht über dämliche Webserver-Firmware ärgern.

Wo ist das eigentlich das "Filesystem" ^^ gespeichert? Im RAM? Oder im 
Flash?

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Axel Schwenke schrieb:
>> Und Lothar (Gast) hängt irgendwie auf
>> dem Trip fest, daß der µC der HTTP-Client sein soll.
>
> @Lothar: Stimmt das? Ich dachte gerade, ich hatte Dich verstanden.

An der Stelle noch eine Erläuterung. Wenn man sich auf HTTP festlegt, 
dann ist es prinzipiell korrekt, den µC Client sein zu lassen. Zumindest 
immer dann, wenn neue Daten asynchron (also nicht in einem festen 
Zeitraster) anfallen.

Denn bei HTTP bestimmt der Client den Zeitpunkt, zu dem eine Übertragung 
stattfindet. Der Server antwortet dann immer "nur" mit den angeforderten 
Daten.

Wenn der µC der Server wäre, dann wüßte der Client ja nicht, wann neue 
Daten bereit stehen. Er müßte den µC sozusagen pollen. Und auch dann 
bestünde eine reelle Chance, Daten zu verpassen.

Wenn man eine Komplizierung des Protokolls in Kauf nimmt, kann man 
dieses Problem natürlich umschiffen. Z.B. könnte der µC als Webserver 
die letzten N Datenpunkte intern puffern (wobei N irgendwie mit dem 
verfügbaren Speicher korreliert). Immer wenn Daten abgeholt werden, 
löscht der µC sie aus dem Puffer. So kann man zumindest das Verschlucken 
von Daten verhindern.

Auch in der Gegenrichtung - wenn der µC Client ist - läßt sich dieses 
Verfahren anwenden. Der µC würde dann neue Daten z.B. per POST absetzen. 
Aber wenn er nicht innerhalb des Timeouts ein "200 OK" zurück bekommt, 
würde er die Daten puffern und die Übertragung später erneut versuchen.

Man sieht: auch wenn man das Problem wie einen Nagel ansieht, kann es 
sein daß ein einzelner Schlag mit dem Hammer nicht ausreicht. Zumindest 
dann nicht, wenn man es gut machen will.


XL

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Axel Schwenke schrieb:
>> Und Lothar (Gast) hängt irgendwie auf
>> dem Trip fest, daß der µC der HTTP-Client sein soll. Daß der gar eine
>> AJAXisierte Seite von seinem Gegenpart laden soll, um dann asynchron
>> GET/POST Requests mit seinen Daten abzusetzen.
>
> Quatsch: Browser ist Client und MC ist Server. Steht so da:
>
> Lothar schrieb:
>> Der Browser lädt das, und der POST Request wird an den Server
>
> Der Browser wird wohl kaum auf dem MC laufen ...
>
>> Wenn der TCP-Stack auf dem MC läuft, kann man das POST abfangen und z.B.
>> einen Messwert als Text
>
> Der MC bekommt den POST, ist also Server ...

Magst du dann mal erläutern, warum der µC Javascript ausführen können 
soll? Denn genau das hast du geschrieben:

Lothar schrieb:
> Torsten C. schrieb:
>> Und JavaScript wäre aus meiner Sicht
>> "overkill". Das wäre m.E. eher was für einen Raspberry Pi.
>
> Keineswegs, das braucht man, wenn der MC Messdaten an PC oder Smartphone
> senden soll. Anstatt jedesmal die ganze HTML-Seite neu zu senden, wird
> per POST nur der geänderte Messwert gesendet.

Der Knackpunkt ist vielmehr, daß dann auf dem µC ein Webserver laufen 
muß (denn genau da und nicht im TCP-Stack schlägt ein POST Request auf). 
Ja, das ist wohl offensichtlich, oder? Wenn der µC Server sein soll, 
dann muß da ein Server laufen. Überraschung!


XL

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> An der Stelle noch eine Erläuterung.

Danke. 100% Ack! :-)

Ein Client entspricht auch nur ein paar Zeilen "C" über Telnet.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Ein Client entspricht auch nur ein paar Zeilen "C" über Telnet.

Sogar noch weniger. Der Client öffnet einfach eine TCP-Verbindung mit 
socket(), schickt den HTTP-Request mit send() und macht dann so lange 
read() bis er EOF bekommt. Anschließend close()d er den Socket. Soviel 
API sollte auch das simpelste WLAN-Modul in Richtung µC exportieren.

Und wenn man bereit ist, auf der Server-Seite mehr als ein PHP-Skript zu 
investieren, dann packt man einen Daemon auf einen TCP-Port seiner Wahl 
und implementiert ein simples zeilenbasiertes Protokoll. Viel mehr als

Kennwort:variable1=wert1:variable2=wert2:...\n

und als Antwort

"OK" oder "FAIL"

braucht man da nicht. Optional als UDP und ganz ohne Antwort.

Den Daemon-Code findet man als Trivialbeispiel im Stevens "UNIX Network 
Programming" oder notfalls in 'perldoc Net::Daemon'


XL

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
>> Torsten C. schrieb:
>>> Und JavaScript wäre aus meiner Sicht
>>> "overkill". Das wäre m.E. eher was für einen Raspberry Pi.
>>
>> Keineswegs, das braucht man, wenn der MC Messdaten an PC oder Smartphone
>> senden soll. Anstatt jedesmal die ganze HTML-Seite neu zu senden, wird
>> per POST nur der geänderte Messwert gesendet.

Ein Missverständnis. Ich dachte er meint, wenn der Client JavaScript 
nutzt, braucht er keinen MC sondern einen Raspberry Pi, auf dem dann 
Apache/PHP läuft. Daher habe ich geantwortet, selbst wenn der Client 
JavaScript nutzt, reicht ein MC als Server, weil der ja nur die 
nötigsten Requests bedienen muss.

Axel Schwenke schrieb:
> Wenn der µC der Server wäre, dann wüßte der Client ja nicht, wann neue
> Daten bereit stehen. Er müßte den µC sozusagen pollen. Und auch dann
> bestünde eine reelle Chance, Daten zu verpassen.

Richtig. Aber bei meinen Anwendungen, z.B. Maschine mit Smartphone 
steuern, hängt der MC am CAN-Bus und auf dem Smartphone läuft eine 
Browser-APP (mit JavaScript), wo z.B. ein Diagramm gezeigt wird, und 
Knöpfe und Regler. Da ist natürlich der MC Server. Und URL-GET/POST kann 
nicht verwendet werden, weil das sichtbar und nicht verschlüsselbar ist. 
Daher AJAX/POST. Und daher WLAN und TCP-Stack separat.

Wenn es bei Euren Anwendungen um synchrone schnelle Datenübertragung 
geht, braucht es gar kein HTTP, nicht mal TCP, es würde schon UDP 
reichen. Dafür haben WLAN-seriell-Module AT-Befehle.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Ein WLAN-seriell-Modul ist … nicht flexibel (kein JavaScript)

Daraus hatte (nur?) ich geschlossen, dass ein WLAN-Modul Deiner Meinung 
nach JavaScript können muss. Aber das hat sich ja nun wohl als 
Missverständnis entpuppt.

Lothar schrieb:
> Ich dachte er meint, wenn der Client JavaScript
> nutzt, braucht er keinen MC sondern einen Raspberry Pi

Bin ich ich mit "er" gemeint?

Ich hatte schon sowas vermutet,
daher ich schrieb:
> Oder sprichst Du von Java-Script auf dem Browser auf dem Client?

Als Du das bejaht hast, war mir alles klar.

Lothar schrieb:
> und nicht verschlüsselbar ist.

Oha, das finde ich "oversized". Solange man nicht die Haustür damit 
auf macht, reicht mir_persönlich "Security through obscurity". Aber 
das muss natürlich jeder selbst wissen.

Lothar schrieb:
> UDP … Dafür haben WLAN-seriell-Module AT-Befehle

Das hilt mir, die Module untereinander besser einzuschätzen. Danke.

Wo ist das eigentlich das "Filesystem" ^^ gespeichert? Im RAM? Oder im
Flash?

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Oha, das finde ich "oversized". Solange man nicht die Haustür damit
> auf macht, reicht mir_persönlich "Security through obscurity". Aber
> das muss natürlich jeder selbst wissen.

Mit Maschine meinte ich Industrieanlage (Fertigungsstrasse, Kraftwerk). 
Ich mache das nicht als Hobby :-)

Aber selbst wenn es nur fürs Hobby ist, bei URL-GET/POST sieht jeder mit 
Wireshark was requested wird, und kann dem MC dann Anweisungen geben, 
ohne dass Du das merkst. Selbst wenn es nur LED ein/aus ist, ist das 
blöd.

Torsten C. schrieb:
> Wo ist das eigentlich das "Filesystem" ^^ gespeichert? Im RAM? Oder im
> Flash?

Also wenn der MC Server ist und ein WLAN-seriell-Modul dran hängt, ist 
das Filesystem zunächst im MC-Flash oder in einer SD-Karte am MC. Das 
wird dann bei Power-Up je nach Bedarf in das Modul geladen. Ich hatte 
noch kein Modul, dass das Filesystem selbst permanent speichern konnte, 
es soll aber was mit FRAM geben.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> bei URL-GET/POST sieht jeder mit Wireshark was requested wird

Auch mit Wi-Fi security WEP  WPA  WPA2 / EAP?
HCI_COMMAND_WLAN_CONNECT, uns32 Security Type:
0=Unsecured
1=WEP
2=WPA
3=WPA2

Der Hintergrund meiner Frage
ist, was ich schrieb:
> Die Idee mit dem Zusatzmodul finde ich deshalb gut, weil man seine
> Systeme preiswert hält, falls WLAN optional ist. Wer WLAN will, bestückt
> einfach ein solches Modul.

Lothar schrieb:
> wenn der MC Server ist und ein WLAN-seriell-Modul dran hängt, ist
> das Filesystem zunächst im MC-Flash …

Dann kann man die Web-Ressouren (GIFs und Templates mit %%parameter%% 
usw.) auf dem Modul speichern und kann das Basis-System (ohne WLAN) 
klein halten? Cool. :-)

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> URL-GET/POST kann
> nicht verwendet werden, weil das sichtbar und nicht verschlüsselbar ist.
> Daher AJAX/POST.

Inwiefern ist das besser? Weil die URL nicht in der Statuszeile des 
Browsers angezeigt wird?

Lothar schrieb:
> Mit Maschine meinte ich Industrieanlage (Fertigungsstrasse, Kraftwerk).
> Ich mache das nicht als Hobby :-)
>
> Aber selbst wenn es nur fürs Hobby ist, bei URL-GET/POST sieht jeder mit
> Wireshark was requested wird, und kann dem MC dann Anweisungen geben,
> ohne dass Du das merkst. Selbst wenn es nur LED ein/aus ist, ist das
> blöd.

Nochmal: was läßt dich glauben, das wäre mit AJAX anders? Es sind nach 
wie vor HTTP-Requests die da über die Leitung (oder den Äther) gehen. 
Gegen das Mithören hilft SSL/TLS. Client-Authentifizierung kann man im 
Prinzip auch mit SSL machen (man gibt dem Client ein spezifisches 
Zertifikat und testet das auf der Serverseite). Sonst halt klassisches 
Login.

Aber gut, eigentlich liegt bei "Industrieanlage" und "mit Smartphone 
steuern"  das Kind schon im Brunnen. Es sei denn natürlich man glaubt, 
Smartphones gingen nie verloren oder würden nie gehackt oder von Malware 
befallen.


XL

von Kelvin S. (Firma: Keine) (dtx)


Bewertung
0 lesenswert
nicht lesenswert
Sorry für den OT Beitrag. Habe etwas ähnliches vor daher die kurze 
Zwischenfrage.

JavaScript wird doch Clientseitig ausgeführt.
Wie bitte hängt das mit dem WLAN zusammen? Bzw. was genau meint ihr im 
zusammenhang WLAN/JavaScript?

LG

DTX

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> was läßt dich glauben, das wäre mit AJAX anders? Es sind nach
> wie vor HTTP-Requests die da über die Leitung

Genau, deswegen werden auch die Kommandos verschlüsselt, die per POST an 
den MC gehen. Und nicht im Smartphone, sondern mit SecurID (ist wie ein 
Chip-TAN-Generator).

Axel Schwenke schrieb:
> eigentlich liegt bei "Industrieanlage" und "mit Smartphone
> steuern"  das Kind schon im Brunnen

Weil ja SPS so viel sicherer ist (Stuxnet) ...

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Kelvin S. schrieb:
> Wie bitte hängt das mit dem WLAN zusammen?

Gar_nicht! Die ganze JavaScript-Diskussion ist hier OT.

Aber was soll´s.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kelvin S. schrieb:
> JavaScript wird doch Clientseitig ausgeführt.
> Wie bitte hängt das mit dem WLAN zusammen?

Wurde zwar jetzt schon viel hin und her diskutiert, trotzdem nochmal 
zusammengefasst:

Der Server erzeugt die HTML/JavaScript Seite und sendet sie an den 
Client. Der Client interpretiert das JavaScript, und erzeugt Requests 
für den Server, die dieser wiederum interpretieren muss. Bei MC Server 
üblicherweise mit Textsuche und Textantwort, bei PC Server mit einer 
anderen Skriptsprache (meist PHP, kann aber auch Python sein, und 
JavaScript ginge genau so, nur wird das nicht gemacht).

Wenn der MC über Ethernet am Internet hängt, ist meist der MAC im MC, 
oder der MAC ist im PHY, kann aber über Register per MII (wie SPI) 
gesteuert werden. Somit kann der komplette Server im MC laufen. Bei WLAN 
hingegen gibt es zwei verschiedenen Modul-Arten. Mit SPI angebundene, 
die direkt vom MC kontrolliert werden, hier ist alles wie mit Ethernet. 
Oder WLAN-seriell-Module. Hier ist im Prinzip der Server im Modul 
gekapselt und nicht veränderbar. Meist ist die "Firmware" auch "geheim" 
und es gibt keine Doku dazu. Der MC kann nur noch die HTML/JavaScript 
Seite an das Modul schieben, oder mit AT Kommandos Daten 
senden/empfangen. Der Server im Modul implementiert aber die meisten 
Requests nicht, und der MC kann somit auf Requests aus JavaScript nicht 
reagieren.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> … und der MC kann somit auf Requests aus JavaScript nicht
> reagieren.

Das ist Quatsch! Die ständige Wiederholung dieser Aussage ich doch der 
Grund für dieses Off-Topic-Intermezzo.

Der MC kann nicht direkt auf Requests reagieren. Das stimmt.

Mit JavaScript hat das erstmal nix zu tun.

@Lothar: Du hast nun detailliert Deine Industrieanlagen-Anwendung 
beschrieben. Und wenn die Parameter bei Dir nicht (verschlüsselt) in der 
URL (im Dateinamen) stehen können oder sollen oder sonstwas, dann ist 
das eben so. Dafür gib's ja 1000 gute theoretische Gründe, die wir hier 
nicht alle diskutieren müssen.

Danke für das detaillierte Aufzeigen der Unterschiede der Modul-Typen. 
:-) Ich habe viel gelernt.

PS: Die WLAN-seriell-Module können doch sicher alle Telnet, oder?

Dann muss man Zustandsbehaftete Kommunikation halt damit machen.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Der MC kann nicht direkt auf Requests reagieren.

Wenn auf dem MC ein Open-Source Server läuft, kann ich dort mit ein paar 
Code-Zeilen auf jeden Client-Request reagieren, den ich will 
(JavaScript, CGI, HTTPS). Wenn der Server auf dem WLAN-seriell-Modul 
läuft, das am MC hängt (oder auf einer Ethernet-seriell-Bridge, ist 
dasselbe), dann werden eben nur wenige Requests weitergeleitet, und nur 
auf die kann dann der MC reagieren.

Hier ich hab für meine Anwendung den uIP Code dort raus genommen: 
http://www.freertos.org/embeddedtcp.html

von Kelvin S. (Firma: Keine) (dtx)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Kelvin S. schrieb:
>> JavaScript wird doch Clientseitig ausgeführt.
>> Wie bitte hängt das mit dem WLAN zusammen?
>
> Wurde zwar jetzt schon viel hin und her diskutiert, trotzdem nochmal
> zusammengefasst:
>
> Der Server erzeugt die HTML/JavaScript Seite und sendet sie an den
> Client. Der Client interpretiert das JavaScript, und erzeugt Requests
> für den Server, die dieser wiederum interpretieren muss. Bei MC Server
> üblicherweise mit Textsuche und Textantwort, bei PC Server mit einer
> anderen Skriptsprache (meist PHP, kann aber auch Python sein, und
> JavaScript ginge genau so, nur wird das nicht gemacht).
> <-SNIP->
> Der Server im Modul implementiert aber die meisten
> Requests nicht, und der MC kann somit auf Requests aus JavaScript nicht
> reagieren.

Gut logisch das der request nicht beantwortet werden kann wenn der 
interpreter fehlt.

Also gehts bei der JavaScript geschichte rein um hin/her-schieben von 
daten bzw. deren auswertung wenn ich das nun richtig versteh.

Lothar schrieb:
> Weil ja SPS so viel sicherer ist (Stuxnet) ...

Jede Art Hardware/Software ist Angreifbar! Ob nun Kabel/Funk spielt die 
geringste rolle! Ja sogar eure Autos (Modorsteuergerät ect.) sind mit 
der richtigen Hardware Auslesbar/Steuerbar/Modifizierbar.

Torsten C. schrieb:
> Auch mit Wi-Fi security WEP  WPA  WPA2 / EAP?

Ich hab mich recht lange und ausgiebig mit Wlan sicherheit Beschäftigt.
WEP = 4-10 Minuten bis es Geknackt ist. (Je nach signal)
WPA/TKIP = 50/50 Chance es schnell zu knacken durch einen Fehler in TKIP
WPA/PSK = Weniger als 50% Chance es schnell zu knacken 
(Wörterbuchangriff)
WPA2/TKIP = Weniger als 50% Chance es schnell zu knacken 
(Wörterbuchangriff) trotz des Fehlers in TKIP
WPA2/PSK = Weniger als 50% Chance es schnell zu knacken 
(Wörterbuchangriff)

Da sind aber die Daten zu fehlerhaft Implementiertem WPS nicht dabei.
WPS Sofern angreifbar zwischen 4 und 10 Stunden zur Auslieferung eines 
WPA/WPA2 Schlüssels im Klartext!

EAP kommt hier selten vor übrigens. Ist meines Wissens nach aber auch 
sicher. Also weniger als 50% Chance es schnell zu knacken.

Noch sicherer sind RADIUS Server aber im privaten Bereich sicher nicht 
notwendig. Es sei denn man hat gerade erst eine neue Ladung 
Staatsgeheimnisse auf dem Rechner/NAS dann sollte man RADIUS in Betracht 
ziehen grins

Also Torsten C. grundsätzlich sollte es nach der Verschlüsselung 
schwerer sein etwas lesbares aus den Paketen zu extrahieren, aber 
unmöglich ist es nicht. Je nach verfügbarer Hardware sehr zeitaufwendig 
aber nicht unmöglich! Mit WEP sogar problemlos in wenigen Minuten wenn 
man so ca. 30.000 Pakete hat.

Axel Schwenke schrieb:
> Nochmal: was läßt dich glauben, das wäre mit AJAX anders? Es sind nach
> wie vor HTTP-Requests die da über die Leitung (oder den Äther) gehen.
> Gegen das Mithören hilft SSL/TLS. Client-Authentifizierung kann man im
> Prinzip auch mit SSL machen (man gibt dem Client ein spezifisches
> Zertifikat und testet das auf der Serverseite). Sonst halt klassisches
> Login.
>
> Aber gut, eigentlich liegt bei "Industrieanlage" und "mit Smartphone
> steuern"  das Kind schon im Brunnen. Es sei denn natürlich man glaubt,
> Smartphones gingen nie verloren oder würden nie gehackt oder von Malware
> befallen.

SSL/TLS Sind nur sicher wenn der Schlüssel der Funkübertragung sicher 
ist.
Sonst kann jede Art Zertifikatbasierende "Sicherung" des Datenstroms 
durch abfangen des Zertifikat "Umgangen" werden. Gutes Beispiel ist 
SSLStrip

http://www.thoughtcrime.org/software/sslstrip/

Wobei du recht hast, die Idee mit dem Smartphone zur Steuerung von 
Industrieanlagen klingt für mich Grausig!
( Betrifft diesen teil->"Smartphones gingen nie verloren oder würden nie 
gehackt oder von Malware befallen.")

Und ich denke da noch nicht mal an die Möglichkeit das irgendwo wie von 
Stuxnet Zentrifugen Übersteuert werden. Spionage, Datenveränderung, 
Datenlöschung, Sabotage oder (Wenn das beispiel AKW hier mal herhalten 
soll) eventuell ein 2'tes Chernobyl? (Okay übertrieben...)

Lg

DTX

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Kelvin S. schrieb:

> SSL/TLS Sind nur sicher wenn der Schlüssel der Funkübertragung sicher
> ist.
> Sonst kann jede Art Zertifikatbasierende "Sicherung" des Datenstroms
> durch abfangen des Zertifikat "Umgangen" werden.

Bei SSL geht aber nicht "das Zertifikat" über den Draht. Im Fall der 
zertifikatbasierten Authentifikation präsentiert der Client seinen 
public key, seine Identität und einen von der CA signierten Hash über 
diese Informationen. Die Gegenseite prüft ob der Hash zu den Daten paßt. 
Und ob die Signatur echt ist.

Ein Angreifer kann alle diese Daten problemlos mitlesen. Solange er 
nicht den private key der CA hat, kommt er damit nicht weiter.

> http://www.thoughtcrime.org/software/sslstrip/

Paßt hier nicht. Das funktioniert überhaupt nur, wenn der Server 
schlampig programmiert ist und Zugriffe auf sensitive URLs über HTTP 
(statt HTTPS) zuläßt. Aber wenn es um Sicherheit geht, dann schickt man 
natürlich alle Zugriffe durch HTTPS. Und kann HTTP auch gleich 
abschalten.


XL

von Kelvin S. (Firma: Keine) (dtx)


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Bei SSL geht aber nicht "das Zertifikat" über den Draht.

Ja der SSL Handshake... Meine Güte ich muss es ja nicht Haarklein und 
ewig lang machen oder?

Axel Schwenke schrieb:
> Paßt hier nicht. Das funktioniert überhaupt nur, wenn der Server
> schlampig programmiert ist und Zugriffe auf sensitive URLs über HTTP
> (statt HTTPS) zuläßt. Aber wenn es um Sicherheit geht, dann schickt man
> natürlich alle Zugriffe durch HTTPS. Und kann HTTP auch gleich
> abschalten.

Gut hast du recht mit. Wobei ich da an das ein oder andere Praktikum 
denken muss bei denen zwar SSL verwendet wurde aber alles über HTTP 
gleich verfügbar war. Ja ja ... Pausenspielereien...

Zumindest bei einer Firma war der Admin nicht so schlampig.

Lg
DTX

von Sebastian W. (sebastian_w29)


Bewertung
0 lesenswert
nicht lesenswert
Läuft noch irgendwas in Richtung Sammelbestellung?

LG, Sebastian

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian W. schrieb:
> Läuft noch irgendwas in Richtung Sammelbestellung?

Sorry, zu spät, ich habe zwei WRL-3000 bestellt.

Das zweite ist in Reserve, aber das möchte ich ungern weggeben, bevor 
nicht alles so funktioniert, wie's soll.

Ich hätte irgendwann gern noch das RN-131 ausprobiert, habe aber derzeit 
keine günstige Quelle gefunden, wo das Modul auch lieferbar ist. Du 
kannst gern mal schauen, falls Dich das RN-131 interessiert. Ich würde 
davon erstmal nur eins nehmen und hoffen, dass es beim basteln nicht 
kaputt geht.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> WRL-3000

Zur Info: Hiervon könnte man bei Bedarf den Sourcecode des CC3000 API 
übernehmen.

http://technical.io/

OT: Ist ein MC als Client, der direkt JavaScript ausführen kann (ohne 
Server) :-)

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Lothar:
Hast du den Source Code schon irgendwo gefunden?
Auf Github scheint es derzeit nur Beispiel-Programme zu geben...

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> Hast du den Source Code schon irgendwo gefunden?

Scheint noch nicht fertig zu sein. Aber ich hatte auch schon mal weiter 
oben ein alternatives Modul genannt, wo es Sourcecode gibt:

http://www.redpinesignals.com/Modules_&_M2M_system...

http://www.lpc4350.com/lpc43xx/Examples/WIFI/

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Scheint noch nicht fertig zu sein. Aber ich hatte auch schon mal weiter
> oben ein alternatives Modul genannt, wo es Sourcecode gibt:

Der Code vom alternativen Modul nützt aber für den CC3000 nichts,
den

http://technical.io/

für ihr Tessel benutzt.

von Herbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast du die WRL-3000 schon bekommen?

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nein, ich weiss auch nicht was da los ist. Das ging leider nicht über 
paypal. Ich muss wohl mal per Mail nachfragen.

von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Ich muss wohl mal per Mail nachfragen.

Die Antwort mit der Tracking-ID kam prompt. Viel schlauer bin ich nun 
auch nicht (Bild).

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Alle,

Es existiert eine arduino-port vllt hilft das einiges. Wenn UDP 
eingesetzt werden sollte ist es zu empfehlen den letzten patch von TI zu 
verwenden. Die TI Software ist dann auf V1.11, wobei der patch fuer das 
CC3000MOD auf 19 kommt. Ich habe da u.a. ein CC3000 Boost auf diesen 
patch laufen. Den UDP listener bekam schon ordentlich was ab. Scheint 
einigermassen zu funzen. Sogar ein webserver und NTP lauft. Bei adafruit 
gibt es auch ein board wobei die S/W mal durch gesucht werden kann. Von 
die WRL-3000 habe ich auch ein paar, der die ich aus der packung habe, 
hat ohne beanstandung gefunzt. Meine ist aber auf patch level 11. 
Weiterhin wird anscheinent der AP mode NICHT unterstuetzt.

Das modul scheint aber viel wind auf zu wirbeln, also (ich hoffe mal) da 
wird es noch einiges in der naehe zukunkft geben. Was sich so al einige 
zum idee gemacht haben ....

Schau mal rein: https://www.sparkdevices.com/

Oder auf: https://github.com/cmagagna/ArduinoCC3000

Oder auf: http://www.adafruit.com/products/1469

Gruss,

Peter.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Die Antwort mit der Tracking-ID kam prompt.

… und gestern kam ein Modul; bestellt und bezahlt hatte ich zwei.

Ich hab' mal Bilder ins Wiki gestellt:

http://www.mikrocontroller.net/articles/Datei:WRL-3000_Front.jpg

http://www.mikrocontroller.net/articles/Datei:WRL-3000_Back.jpg

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Na dann, viel Spaß damit !!

Ich versuche gerade ein multicast packet ueber UDP zu verschicken, 
ankommen tut es aber...

Auf regulaeren PC wird das packet im sniffer erkannt aber nicht ueber 
luft ???

Naja, vllt. ist es auch deswegen ....

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Zu zwei Modulen würde ich mich noch breitschlagen lassen

Hallo zusammen,

das WRL-3000 habe ich zwar noch nicht ausprobiert, aber über 
preiswertere Alternativen habe ich nachgedacht:

Z.B. ebay 320914877812

Allergings stelle ich mir die Kommunikation über USB nicht so einfach 
vor. Mit 'nem raspberry pi vielleicht, aber der wäre für meine Projekte 
oversized.

Was meint Ihr?

von Herbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und schon erste Erfahrung mit den Modulen gesammelt?
Sind sie empfehlenswert?
Wie sieht es so in etwa mit der Reichweite aus?

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> bestellt und bezahlt hatte ich zwei.

Das zweite Modul ist nach Nachfrage per Mail nun auch gekommen. 
Ursprünglich wollte ich das Testprogramm direkt für einen µC 
implementieren, aber das habe ich mir nun anders überlegt. Ich denke, es 
führt schneller zum Ergebnis, wenn ich meine ersten Versuche auf 'nem PC 
starte.

Ich bekomme dieses Wochenende ein "FT4232H Mini Module" mit SPI and I2C 
(vergleiche ebay 151033693963), dann geht's weiter.

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das FT4232H ist leider Defekt; ich habe das WRL-3000 immer noch nicht 
ausprobiert.

Ich habe noch ein YSUMA01-341A bekommen, vielleicht kann ich den 
WRL-3000 damit ansprechen.

Das Hi-Link HLK-RM04 ist noch ganz interessant und kostet mit 10€ nur 
die Hälfte. Gibt's damit schon Erfahrungen?

PS: Und das SEMCO SWB-A31 hat BT und WLAN, auch ganz interessant, aber 
das Datenblatt habe ich noch nicht gefunden.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Allergings stelle ich mir die Kommunikation über USB nicht so einfach
> vor.

Das ist wohl leider auch so:
http://forum.arduino.cc/index.php/topic,113960.0.html

Statt Arbeit in das teure WRL-3000 zu stecken, könnte man auch ein 
"TLG10UA03" für 11€ nehmen:
http://www.aliexpress.com/item//988481350.html

Oder noch billiger, ein "Low Cost SDIO WIFI Module" für 6,50€:
http://www.aliexpress.com/item//734502719.html

Also wenn ich mich schon in ein Modul "einarbeite", dann will ich nicht, 
das morgen ein anderer "um die Ecke kommt" und das gleiche für den 
halben Preis macht.

Auch, wenn wir hier nicht im Forum "Markt" sind: Ich hätte dann zwei 
WRL-3000-Module (neu, unbenutzt) zu verkaufen.

: Bearbeitet durch User
von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> "TLG10UA03"
> "Low Cost SDIO WIFI Module"

Gibt es dafür Datenblätter?

> Ich hätte dann zwei WRL-3000-Module (neu, unbenutzt) zu verkaufen.

Was würdest du dafür wollen (inkl. Porto)?

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich habe die billigen Module heute früh erst entdeckt. Nun geht's in 
diesem Thread ja um die Frage "Hat von Euch schon Jemand Erfahrung?", 
damit nicht jeder erneut "in die gleichen Fallen" läuft.

Martin schrieb:
>> "TLG10UA03"
>> "Low Cost SDIO WIFI Module"
> Gibt es dafür Datenblätter?

Kennt jemand eines dieser Module? Falls nicht, suche ich nachher mal 
nach Datenblättern.

Torsten C. schrieb:
> Ich hätte_dann ...

Ich bin noch unsicher: Was meint Ihr denn? Sollte ich wenigstens ein 
WRL-3000 zum ausprobieren behalten?

Torsten C. schrieb:
> Preis: € 19,37 + Versandkosten
> Versandkosten:  €8,74 für "Royal Mail (tracked)"

Zwei Stück kosten also 47,48€.

Martin schrieb:
> Was würdest du dafür wollen (inkl. Porto)?

Vielleicht willst Du auch erstmal eins? Falls "Warensendung Kompakt, 
unversichert" geht, würde ich 20€ für eins nehmen. Bei beiden würde ich 
gern was von den €8,74 an den Käufer weiter geben. Bitte per PN, damit 
der Thread nicht zumüllt.

Ein Erfahrungsaustausch interessiert mich allemal.

: Bearbeitet durch User
von Steffen H. (Firma: www.shotech.de) (mc_sho) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
das ist der Hersteller dieser Module. Datenblätter gibt es da auch, 
wobei nicht alle in Engl. sind.

http://rakwireless.com/eng/index.html

Ich habe die Module im Test, bin aber was die Programmierung betrifft, 
nicht ganz zufrieden. Ich hatte vorher Gainspan und die machen das ja 
auch über AT-Kommandos, nur das es da um das konfigurieren geht. Daten 
kommen dann automatisch über ESC-Sequenzen, was bei den Modulen nicht 
geht. Da muss man die Daten extra anfordern, das finde ich eher 
bescheiden. Ist nichts für mich, es sei denn, die haben mal ne neue 
Firmware. Ich habe das hier im Test:

http://www.aliexpress.com/item/UART-SPI-Stamp-2-4G-WIFI-Module-with-Integrated-Antenna-TCP-IP-protocol-embedded/734517967.html

von Star K. (starkeeper)


Bewertung
0 lesenswert
nicht lesenswert
Also ich habe mit letztlich für die Module von HD-Wireless entschieden. 
Dort gibt es z.B. das SPB-104 welches über SPI oder SDIO angesprochen 
werden kann. Die Module gibt es in verschiedenen Shops zu kaufen und 
kosten um die 40Euro.

Mein Grund dafür war gerade die Tatsache das diese Module nicht mit 
einem eigenen TCP-Stack ausgestattet sind! Denn ich will mich nicht für 
WLAN entscheiden und dann doch nur die beschränkten Möglichkeiten eines 
eingebauten Stacks haben.

Für die Module gibt es diverse Softwarebeispiele für Atmel und ST 
Cortex-Controller. Zum Einsatz kommt in den Beispielen z.B. ein lwIP was 
mir sehr entgegen kam, da ich schon einiges mit lwIP umgesetzt hatte.

Anbindung und Umsetzung waren kein Problem mit den Beispielen und dem 
richtigen Controller eine Sache von wenigen Tagen.

: Bearbeitet durch User
von Alex W. (a20q90)


Bewertung
0 lesenswert
nicht lesenswert
Wie schauts mit der Reichweite aus?

Hat jemand das mal getestet?

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das ist mir noch nicht ganz klar. Einerseits habe ich verstanden, dass 
man diese 2€-USB-Dongles selbst dann nicht für "kleine" µCs nehmen kann, 
wenn der µC einen USB-OTG-Port hat (s.o.).

Bei Raspberry & Co (Linux) dürften die Dongles natürlich kein Problem 
sein.

Andererseits, Star Keeper schrieb:
> Mein Grund dafür war gerade die Tatsache das diese Module nicht mit
> einem eigenen TCP-Stack ausgestattet sind!

Wo ist denn da der Unterschied vom Aufwand, im Vergleich zu 
2€-USB-Dongles?

> Die Module … kosten um die 40Euro.

Es ist offensichtlich, dass wir ganz unterschiedliche Anforderungen 
haben. Selbst wenn ich nicht für jeden  Lichtschalter und jede Lampe 
in meinem Eigenheim ein Modul brauche, so sind es doch sicher etwa 10 
Stück, die ich für meine Zwecke benötige. Und weiter oben hatten wir ja 
auch schon den Fall der Industrie-Automatisierung. Da sind 30€ 
Preisunterschied ein "ziemlicher Brocken".

Daher schiele ich ja wegen der Differenz von 10€ auch schon auf die 
China-Module als Alternative zum WRL-3000. Das wären für mich ja schon 
100€.

Ich persönlich brauche nur eine Telnet-Verbindung. Der Code für einen 
Simpel-Webserver z.B. passt auf eine DIN-A4-Seite und ich wäre m.E. 
flexibel.

PS:

Alex W. schrieb:
> Hat jemand das mal getestet?

Ich zumindest noch nicht, ich weiss ja immer noch nicht, mit welchem 
Modul ich das am besten mache. ;)

: Bearbeitet durch User
von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Torsten:
Manche Leute haben sich nach der billigsten Lösung
schon zu Tode gesucht...
Die 10 * 30 Euro, die du sparen willst, hast du durch
deine monatelange Suche nach dem besten Funkmodul
schon lange verloren...
Wenn du dann noch die Zeit rechnest
(€/h, niedrigst möglicher Stundenlohn),
die du für die Umsetzung von 10 Stück deiner Lösung brauchst,
bis sie einiger maßen ordentlich funktioniert, ist es egal,
ob dein Funkmodul 2, 10 oder 40 Euro kostet...

von Torsten C. (torsten_c) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> Gibt es dafür Datenblätter?

RAK410 (mc_sho, ali 734507034: 11,46€):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

http://rakwireless.com/eng/Wi-Fi_RAK410.html

Dazu gibt es das "RAK410-SPI Programming Manual" und das "RAK410-UART 
Programming Manual". Beide scheinen ziemlich vollständig zu sein.

@Steffen: Wie laufen Deine Tests?


RAK310 (Low Cost SDIO^^, ali 734502719: 5,43€):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

http://rakwireless.com/eng/Wi-Fi_RAK310.html

Ich habe keine Datenblätter gefunden, aber habe deshalb mal dort 
angefragt.


TLG10UA03 (ali 988481350: 10,66€):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dazu gibt's einen Erfahrungsbericht:
http://meineweltinmeinemkopf.blogspot.de/2012/05/uart-wifi-server-client-module.html

Peter schrieb:
> Wenn du dann noch die Zeit rechnest

Peter, wir sind ja nicht gezwungen, gleiche Ansprüche an unsere eigene 
Arbeit zu haben; offenbar sind sie unterschiedlich. Nicht 
unterschiedlich "hoch" oder "niedrig", aber eben anders.

In die Suche habe ich bisher in Summe vielleicht 4-6 Stunden gesteckt. 
Ein paar mag ich da noch investieren. Lass mich doch. Wenn´s ein 
Ergebnis gibt, freut es vielleicht den nächsten Leser dieses Threads, 
wenn er nach 2 Stunden schon das richtige für seine Zwecke findet.

Für kommerzielle Zwecke bei 1000er-Stückzahlen rechnet sich fast jeder 
Euro.

Für private Zwecke (Null €/h) ist das ein Stück weit Idealismus und 
lässt sich nicht "verrechnen". Beispiel: Andere stricken Schals und 
Mützen mit Wolle, die teurer ist als 10er-Packs mit fertigen Schals und 
Mützen. Die selbstgestrickten sind aber bis auf den ideellen Wert nicht 
unbedingt besser.

Ich schiele aktuell am meisten auf das RAK310.

: Bearbeitet durch User
von ♪Geist (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat jemand Infos zu dem WLAN Modul der Wanscam WiFi Camera?
Das Wlan Modul ist über vier Pin-Header mit Mainboard verbunden. Nach 
dem Abnehmen vom HF Käfig war der Chip leider mit Harz vergossen :/ 
Abkratzen war leider unmöglich

von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> RAK310 (Low Cost SDIO^^, ali 734502719: 5,43€):
> Ich habe keine Datenblätter gefunden, aber habe deshalb mal dort
> angefragt.

Antwort: ... if you use it in LED control, u'd better select RAK410 
which don't have high requiremnet for host processor. RAK410 integrated 
the TCP/IP protocol inside the module.

Steffen H. schrieb:
> Ich habe das hier im Test:

@Steffen (mc_sho): Kannst Du das RAK410A empfehlen?

Ich würde für mich das RAK410-1A (s. Bild) bevorzugen, aber das sollte 
ja ganau so gut oder schlecht sein, nehme ich an.

: Bearbeitet durch User
von Steffen H. (Firma: www.shotech.de) (mc_sho) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Torsten C.

das RAK410A funktioniert wie erwartet, aber ich bin wie weiter oben 
schnon geschrieben mit dem Handling der Kommunikation nicht ganz 
zufrieden. Die Programmierung über AT-Kommandos kenne ich schon von 
RedPine, Gainspan etc. und das funktioniert soweit. Die Datenübertragung 
nach einem Connect und öffnen einer Socket ist aber eher bescheiden. Ich 
hätte gehofft, das die Datenstreams automatisch über den UART gesendet 
werden. Leider ist das nicht so und man muss immer anfragen, ob was von 
der Gegenstelle gesendet wurde. Das Handling finde ich schlecht. Bei den 
Gainspan, RedPine ist das viel besser, da die STreams automatisch mit 
Socket-Nr. und IP über den UART gesendet werden. Ich werde mich evtl. 
für das RAK310 oder SWB-B23 entscheiden. Hier muss ich zwar den Stack 
und Kommunikation zum WLAN-Chip selbst schreiben, aber da habe ich schon 
einiges an Software da. Weiter brauche ich beim Stack auch noch eine 
Erweiterung auf ZeroConf ( mDNS oder DNS-SD ), die ich schon zu einen 
Teil programmiert habe.

Gruss
Steffen

von Steffen H. (Firma: www.shotech.de) (mc_sho) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
das SWB-A31 ( Mit dem WLAN-Chip)AR6003 und (Bluetooth-Chip)CSR8810 ) ist 
auch noch eine Option. Die Unterlagen habe ich dazu gerade bekommen.
Das SWB-B23 hat ja nur ein IC BCM4329 bei dem WLAN und Bluetooth auf 
einem Chip sind. Ist ein bischen kleiner 8,2mm x 7,3mm x 1,25mm.

von tronix (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Habt ihr mit den genannten Modulen schon ein paar Erfahrungen gemacht?

Dieses SWB-A31 ist ja bei aliexpress "voll teuer" mit 20$. Hier gibt es 
das für 6,23$ http://easy-taobao.com/taobao/view/id/18633559429
und für 2 Stück sogar schon für 4,37$.
Ein verwendbares Datenblatt konnte ich nicht finden. Steffen H., 
könntest du das bitte posten?

von tronix (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Damn it,
hab's grad im China SUPER Bauteile-Schnäppchen Thread entdeckt

von Basti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hm, dass Module hat aber nur ein HCI Interface oder? Das wird evtl. 
etwas viel Arbeit für einen kleineren MC, dass alles selbst zu rechnen?!

Find leider keine Unterlagen... aber das es WLAN Sticks für nen paar 
Dollar gibt, ist ja nix neues... Was hier gesucht wird, ist aber ein 
Module, welches am besten den IP Stack schon integriert hat...

So kams jedenfalls rüber...

Bin weiterhin sehr zufrieden mit dem CC3000!

Hab ach schon eine Platine mit SD Karte, USB, CC3000, zwei mal RS485, 
eine normale USART mit TTL Pegel, IR Fernbedienung, zwei Buttons und 
LEDs mit nem XMega256A3U am laufen... geht alles sehr gut!

Grüße

Basti

von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Laut Fotos hat das SWB-A31 einen Atheros 6003 on board.
Es scheint zumindest Linux-Treiber dafür zu geben.
Hatte irgendwo SDIO gelesen?
Aber ob es dafür ein (öffentlich verfügbares) Datenblatt gibt,
weiß ich auch nicht.
Gibt es vielleicht bereits jemand, der das mit einem einfacher uC
ohne Linux eingesetzt hat?

Zum CC3000:
Ich bin mit dem CC3000 mittlerweile nicht mehr zu Frieden
und kann ihn auch mit der aktuellen Software (Host/Patches)
nicht mehr empfehlen.
Zu schlechte Software und die Dokumentation ist auch spärlich
und lässt wichtige Details aus.
Um mal nach dem Aufwecken ein paar UDP Pakete auszutauschen,
scheint es noch benutzbar zu sein, mehr aber auch nicht.
Es wurden von mehreren Benutzern Fehler an TI gemeldet
(siehe E2E Forum), aber TI braucht eine Ewigkeit
um Fehler zu beheben bzw. die Fehler sind bis heute
nicht behoben, obwohl mehrere Benutzer scheinbar
das gleiche Problem gemeldet haben und es damit zu
existieren scheint. Oft auch einfach keine Reaktion mehr
vom TI Support auf Anfragen und Probleme.
Anfangs war es eine tolle Idee/ein tolles Produkt...

von Basti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Welche Probleme hast du genau?

War seit Anfang an dran und hab mich auch über die vielen Bugs 
geärgert... Nach einigen Softwareupdates ist es dann aber gut gewesen...

Find es auch sehr schade, dass TI es nicht mal fertig bringt das 
Interface-Protokoll offen zu legen... das muss man sich quasi aus den 
Treibern herausschreiben, wenn man mal auf tieferer Fehlersuche ist...

Ich benutze aktuell nur UDP und bin mit Datenrate und meinem 
umgeschriebenen Treiber sehr zufrieden... Läuft alles sehr gut und das 
SmartConfig tut seine Dienste bisher auch prächtig...

Wo hängt es bei dir Andi? Vielleicht kann ich ja helfen?

von Basti (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Bild, der aktuellen Platine...

von Andi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
@Basti
Danke für dein Angebot!

Zum Interface-Protokoll gibt es etwas Hilfe:
http://www.embeddedadventures.com/datasheets/WRL-3000_hw_v2_doc_v1.pdf
Aber das Dokument ist auch schon wieder 1/2 Jahr alt,
enthält noch Fehler und ist nicht vollständig.

Ich habe mittlerweile die Entwicklung mit dem CC3000 AdActa gelegt,
bis eine stabile Software von TI zur Verfügung steht.
Oder ein neuer Chip...

Um nur ein paar Punkte zu erwähnen (Reihenfolge beliebig,
was mir gerade so einfällt...)

- Die Kommunikation hängt sich immer wieder mal auf.
  Nach E2E Forum scheinen immer wieder mal Situationen aufzutreten,
  bei denen die CC3000 internen Buffer ausgehen.
  (In den Traces war dann meist ein ARP davor zu sehen.
  Ob das generell der Fall ist, oder nur einer der Fälle,
  weiß ich nicht...)

  https://community.spark.io/t/bug-bounty-kill-the-cyan-flash-of-death/1322/364

  Sehr langer Thread, aber siehe die Antwort "Zach"
  2 Einträge (Nr. 366) unter dem Eintrag,
  auf den er beim Aufruf der Seite positioniert.
  (Eintrag ist aktuell 10 Tage alt).
  Update: Das Problem scheint irgendwie gelöst worden zu sein.
  Ich frage gerade nach, wie...oder ob es gar ein nicht CC3000
  Problem war.

- Wenn mehrere Verbindungen zugleich aufgebaut werden,
  und eine Verbindung beendet sich (warum auch immer), dann gibt es
  einen Disconnect Event. Dieses enthält einen Index (1 Byte), aber
  keine Socket Nummer. Man muss diese umrechnen. Der Algo,
  wie die Indizes vergeben werden, scheint aber nicht dokumentiert
  zu sein, kann man scheinbar nur aus den Beispiele
  reverse engineeren....

- Wenn es nicht klappt eine Verbindung aufzubauen,
  dann ist die Reaktion nicht ganz "User-freundlich".
  Beispiele:
  - Falsche SSID
  - Falscher Key
  - AP nicht in der Nähe
  - None/WPA/WPA2 passt nicht
  - CC3000 kann mit nicht mit WLAN AP kommunizieren (warum auch immer)
  und ähnliche Fälle
  Ich würde dem User gerne melden "Key falsch", "AP nicht gefunden",...

- SmartConfig geht bei neueren AP (scheint MIMO 802.11n)
  scheinbar nicht mehr

- CC3000 kann beim Einschalten auch gerne mal kurz 2,8A ziehen...

- Ankommende Daten müssen via Polling abgeholt werden, CC3000
  kann mit aktueller Software keinen Interrupt auslösen,
  wenn Daten empfangen werden. Dies wiederum bedeutet,
  dass man uC nicht ständig schlafen legen kann, wenn eine
  Verbindung besteht, weil man periodisch immer wieder nachschauen
  muss, ob vielleicht Daten gekommen sind.

- CC3000 quittiert immer nur 2. Datenpaket, dann aber beide zusammen.
  Wenn man aber nur eines senden will? Lässt sich nicht konfigurieren.
  Workaround: Zerlegen des Paketes, Dummy-Paket

- Man kann vieles im EEPROM speichern,
  hat aber keine API um das wieder auszulesen oder zu kontrollieren,
  ob es noch drin steht, korrekt ist.
  Workaround: NVMEM Routinen benutzen.
  Nachteil: NVMEM im Detail undokumentiert.

- Bugs sind ok, wenn sie behoben werden. Aber nicht, wenn man
  gar nicht weiß, ob sie irgendwann oder überhaupt behoben werden.
  Wenn ein Kunde drauf wartet, was soll man ihm dann sagen?

von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Basti
Zum Board: Schaut nett aus!
Prozessor ist ein STM32? Für was setzt du das Board ein?
Kommerziell oder Hobby?

von Basti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da hast du in einigen Punkten recht... das meiste, stört mich aber gar 
nicht so sehr...

Wenn SmartConfig auf neueren Routern nicht funktioniert, wäre das schon 
sehr schade...

Das mit dem EEPROM zurück lesen, ist wirklich sehr gruselig gehalten. 
Überhaupt geben bei mir einige Funktionen Fehler zurück obwohl es 
funktioniert hat... da kann man den User nur im unklaren lassen...

Das der Socket geschlossen ist, merke ich, wenn ich ein recv durchführe 
und eine -1 zurück bekomme...  wie du schon sagst, man muss so oder so 
pollen... Stromsparen tu ich mir auch nicht an... mit der Antenne 
braucht das Module im normalen Modus schon 100 mA... da brauch ich den 
µC nicht schlafen lassen...

Ich denke viele Fehler bestehen aber nur darin, dass viele Leute ohne 
ausreichende Dokumentation die Treiber portieren und dann an kniffligen 
Situation hängen bleiben. Das ist def. auch schuld von TI, muss aber 
nicht auf eine schlechte Firmware im Module hindeuten...

Das Board ist mit einem XMega ausgestattet und da finde ich das größte 
Problem. Die Treiber werfen mit 32 Bit Variablen nur so um sich, obwohl 
es nicht nötig wäre. Für 32 Bit CPU sicher egal, aber der 8 Bitter kommt 
schon ins schwitzen... Aber 1 MBit ist bei UDP noch drin... Obwohl mein 
recv Buffer nur 128 Byte groß ist... sonst würde da noch einiges gehen!

Das Board ist Kommerziell und Hobby...

Grüße

Basti

von stefanus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier zig mal "Telnet" gelesen, wo offensichtlich ein einfacher 
IP-Socket gemeint war.

Telnet ist ein Übertragungsprotokoll für Terminals. Das Protokoll dient 
prümär der Ansteuerung eines Text-Displays sowie der Übertragung von 
Tastatureingaben. Da gibt dann so Sachen wie Cursor Bewegungen. 
Bildschirm löschen, Bildschirm-Größe übermitteln und so.

Ihr meint ganz sicher einen IP-Socket, das ist die einfache gesicherte 
Punkt-zu-Punkt Verbindung, über die man beliebige Byte-Ströme in beide 
Richtungen übertragen kann.

von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von stevestrong (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, falls noch jemand Interesse in einem WiFi modul hat, ich verwende 
seit mehreren Wochen erfolgreich so ein modul:
http://www.aliexpress.com/item/serial-uart-wifi-module-HLK-RM04-free-shipping/1351870217.html
Mit einem Arduino (über UART) kann man sehr kostengünstig (unter 15eur) 
und sehr einfach einen kleinen web-server auf die beine stellen.

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.