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
Angehängte Dateien:
-
Dsc_9876.png
170 KB
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.
Georg G. schrieb: > Zoll und Einfuhrumsatzsteuer Ich dachte, "ea" sitzt in London ("Royal Mail" ^^). Fällt da auch Zoll an?
Sorry, war automatisch auf China gepolt. Aus GB ist die Einfuhr frei.
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
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?
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
@Basti: Welchen Controller setzt du ein? Einfach mal ein paar Links: http://processors.wiki.ti.com/index.php/CC3000 http://processors.wiki.ti.com/index.php/CC3000_Logger http://processors.wiki.ti.com/index.php/CC3000_Flashing_Guide Forum von TI (TI E2E Community zum SimpleLink™ Wi-Fi®): http://e2e.ti.com/support/low_power_rf/f/851.aspx
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
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/
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.
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
@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?
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.
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.
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."
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?
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.
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. :-)
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.
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.
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)); } } ... }
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
1 | Content-type: application/json; charset=utf-8 |
? GET oder POST ist doch egal: Schreibe die Daten in die URL.
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
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.
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
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.
Lothar schrieb: > Dieser Stack unterstützt ein Filesystem PS: Wo ist das eigentlich gespeichert? Im RAM? Oder im Flash?
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
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.
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
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
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)
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.
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
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".
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 ...
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?
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
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
Axel Schwenke schrieb: > An der Stelle noch eine Erläuterung. Danke. 100% Ack! :-) Ein Client entspricht auch nur ein paar Zeilen "C" über Telnet.
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
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.
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?
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.
Lothar schrieb: > bei URL-GET/POST sieht jeder mit Wireshark was requested wird Auch mit Wi-Fi security WEP WPA WPA2 / EAP?
1 | HCI_COMMAND_WLAN_CONNECT, uns32 Security Type: |
2 | 0=Unsecured |
3 | 1=WEP |
4 | 2=WPA |
5 | 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. :-)
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
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
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) ...
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.
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.
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.
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
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
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
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
Läuft noch irgendwas in Richtung Sammelbestellung? LG, Sebastian
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.
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) :-)
@Lothar: Hast du den Source Code schon irgendwo gefunden? Auf Github scheint es derzeit nur Beispiel-Programme zu geben...
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/
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.
Nein, ich weiss auch nicht was da los ist. Das ging leider nicht über paypal. Ich muss wohl mal per Mail nachfragen.
Angehängte Dateien:
-
temp.png
14 KB
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).
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.
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
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 ....
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?
Und schon erste Erfahrung mit den Modulen gesammelt? Sind sie empfehlenswert? Wie sieht es so in etwa mit der Reichweite aus?
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.
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
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
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)?
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
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
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
Wie schauts mit der Reichweite aus? Hat jemand das mal getestet?
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
@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...
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
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
Angehängte Dateien:
-
RAK410-Varianten.png
2,5 KB
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
@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
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.
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?
Damn it, hab's grad im China SUPER Bauteile-Schnäppchen Thread entdeckt
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
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...
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?
@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?
@Basti Zum Board: Schaut nett aus! Prozessor ist ein STM32? Für was setzt du das Board ein? Kommerziell oder Hobby?
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
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.
CC3000, SmartConfig & 802.11n mit MIMO: http://depletionregion.blogspot.de/2013/10/the-cc3000-80211n-and-mimo.html http://e2e.ti.com/support/low_power_rf/f/851/p/305780/1072910.aspx#1072910
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.