Bluetooth-to-serial Module gibt es ja anscheinend wie Sand am Meer. Gibt es da besonders empfehlenswerte, ala FTDI bei USB-RS232 oder auch welche, vor denen man warnen sollte. Oder ist das völlig egal und man kann einfach den nächst besten bestellen und macht nichts falsch dabei?
Gegenfrage: - Brauchst Du klassisches Bluetooth oder Bluetooth LE? Das sind zwei völlig verschiedene, nicht zueinander kompatible Protokolle. - Wenn klassisches Bluetooth: Brauchst Du SPP oder HCI? Wenn Wenn Du auf diese Fragen keine Antwort weißt, dann solltest Du Dich erstmal mit den Grundlagen beschäftigen, bevor DU kaufst. fchk
Danke für die Info. Bluetooth habe ich das letzte Mal vielleicht vor 10 Jahren benutzt. Da sich das jetzt nicht gerade nach Plug'n'Play anhört, ich nur 3 Wochen Zeit habe und dazwischen auch noch Weihnachten ist, fange ich da gar nicht erst mit an und sage von vornherein:"Das geht nicht."
Wenn's hilft: Ich verwende hauptsächlich die HC-05 BT Serial Module oft als galvanische Trennung bei der uC Entwicklung. Funktioniert wie ein lokaler COM Port und ist bei uC Mess Projekten hauptsächlich nützlich um Masseschleifen zwischen PC und Messgeräte zu vermeiden. Die HC-05 werden von modernen BS direkt unterstützt und sind innerhalb kürzester Zeit einsatzfähig. Die einzige Einstellung die ich veränderte war die Baud Rate auf 115200 umzustellen. Sobald das Modul mit dem PC gepaart ist, sieht man im Gerätemanager die BT COM Ports.
Und im PC steckt dafür immer so so ein BT-Dongel auf dem USB-Port, zumindest wenn er komplett im Blechkleid abgeschirmt ist oder?
Gerhard O. schrieb: > Wenn's hilft Ich denke eher nicht. Trotzdem Besten Dank. Es geht um eine Anwendung, bei der ein Text auf ein Display in einem Pokal geschrieben werden soll. Frag nicht warum und wieso. Ich weiß es selber nicht. Das ist für eine Werbeagentur. Wenn das im Januar vor ihm steht, wird die erste Frage dazu sein, ob man das auch per Smartphone aktualisieren kann. Das mit dem Pokal kriegen wir hin, das Display auch. Aber zum Aktualisieren muß er ein USB-Kabel in sein Notebook stöpseln. Die Kröte muß er schlucken. Er hat heute angefragt und will das am 09.Januar haben.
Wenn, würde ich es lieber mit Wlan (esp8266) machen. Wenn der Kunde ein Iphone hat, ist es nicht so einfach mit BT. Ich glaube, das HC-05 geht nicht mit Iphone. Mit was willst Du denn das Display ansteuern, wenn es über USB gehen soll? Oder ist es eine fertige Laufschrift, dann wird es echt schwierig mit dem Smartphone.
Brauchst du wirklich den AVR? ESP32 oder NRF52 sind aktuell die bessere Wahl. Ist doch Unsinn erst mal die Daten über UART/SPI/I2C an den Bluetooth Chip zu schaufeln wenn selbiger inzwischen leistungsfähiger als der AVR selbst ist. https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy
Die Krux bei Bluetooth ist: Die meisten aber nicht alle Laptops können Bluetooth. PC's brauchen dazu extra Hardware. Praktisch alle Smartphones können Bluetooth, aber bei manchen geht nur die LE Varianten, bei anderen geht LE wiederum nicht. Damit dein Gerät mit allen mobilen und stationären Computern kompatibel ist, musst du eine Menge Klimmzüge machen. Wenn du es gebaut hast, dann läuft es auch noch unzuverlässig, wenn du Pech hast. Was machst du dann? Man kann nicht so einfach ein BT Modul durch ein anderes austauschen, denn jedes Modell funktioniert anders. Nimm lieber WLAN. Die ESP8266 laufen auch nicht 100% sorgenfrei, aber sie sind nahe dran.
batman schrieb: > Jedesmal in ein WLAN einloggen, um mit dem AVR zu kommunizieren? Ist das > praktikabel? Die Aufgabenstellung (Schrift im Pokal darstellen) liest sich so, als könne das ein ESP8266 o.ä. mit links bewältigen und nebenher den WLan Accesspoint stellen. Da fällt der AVR ganz weg.
Nimm einen Esp8266, den kannst du entweder im AP Mode laufen lassen, oder in ein vorhandenes WLAN einbinden. Darauf lässt du eine simple Webseite laufen, die den Text entgegen nimmt. (Vorteil: du brauchst keine App am Handy) Du kannst an den esp direkt ein i2c Display anschließen und selbst für unerfahrene sollte ein funktionierender Arduino Sketch über die Weihnachtsfeiertage machbar sein. Ein Manko am ESP könnte evtl. der hohe Stromverbrauch von ca 300mA bei aktivem WLAN sein, falls der Pokal mit Akkus betrieben werden sollen. VG Roland
Thomas E. schrieb: > Wenn das im Januar vor ihm steht, wird die erste Frage dazu sein, ob man > das auch per Smartphone aktualisieren kann. Dann scheidet SPP aus, denn das kann man nicht mit iOS-Geräten nutzen (nicht ohne erheblichen finanziellen Aufwand, Teilnahme am MFI-Programm etc.). WLAN ist hier tatsächlich deutlich komfortabler, denn dazu muss keine Software auf dem Smartphone oder PC oder wasauchimmer installiert werden, ein Webbrowser genügt. Und sich mit einem Smartphone in ein von einem ESP8266 zur Verfügung gestelltes WLAN einzuklinken ist keine Raketenwissenschaft. Für die BT-Nutzung aber bräuchte man mindestens eine (passende) App ...
> Jedesmal in ein WLAN einloggen, um mit dem AVR zu kommunizieren? > Ist das praktikabel? Sicher, denn bei den meisten Leuten ist der WLAN Router zumindest tagsüber immer eingeschaltet und sowohl PC als auch Smartphone loggen sich dort automatisch ein. Auch der ESP8266 Chip loggt sich automatisch ein, nachdem man das Passwort einmal eingestellt hat. Der ESP8266 kann selbst auch Access-Point spielen. Aber das finde ich für den Normalbetrieb wiederum unpraktisch, weil du dann deinen PC bzw das Smartphone erst vom "normalen" Netz abmelden must, um mit dem ESP zu kommunizieren. Die beste Infosammlung zum ESP-8266 findest du auf meiner Homepage: http://stefanfrings.de/esp8266/index.html
Stefan U. schrieb: >> Jedesmal in ein WLAN einloggen, um mit dem AVR zu kommunizieren? >> Ist das praktikabel? > > Sicher, denn bei den meisten Leuten ist der WLAN Router zumindest > tagsüber immer eingeschaltet und sowohl PC als auch Smartphone loggen > sich dort automatisch ein. Auch der ESP8266 Chip loggt sich automatisch > ein, nachdem man das Passwort einmal eingestellt hat. > > Der ESP8266 kann selbst auch Access-Point spielen. Aber das finde ich > für den Normalbetrieb wiederum unpraktisch, weil du dann deinen PC bzw > das Smartphone erst vom "normalen" Netz abmelden must, um mit dem ESP zu > kommunizieren. > > Die beste Infosammlung zum ESP-8266 findest du auf meiner Homepage: > http://stefanfrings.de/esp8266/index.html Da ist jemand ja sehr von sich selbst überzeugt. Finde es dann aber etwas enttäuschend wenn auf der besten Seite nicht mal als Standardlösung für die Programmierung die Lösung mit Verwendung von DTR usw. gezeigt ist, diese ist deutlich bequemer als die Pins händisch auf entsprechende Pegel zu legen. Es gibt nämlich eine sehr elegante Lösung für dieses WLAN AP/Client Problem: https://github.com/tzapu/WiFiManager
Zitat von der Webseite, Beschreibung des NodeMCU Boardes: Die Reset Leitung und GPIO0 können durch den USB-UART angesteuert werden. Damit aktiviert die Arduino IDE den Firmware-Upgrade Modus vollautomatisch:
1 | DTR RTS /Reset GPIO0 |
2 | Aus Aus High High |
3 | Ein Ein High High |
4 | Aus Ein Low High |
5 | Ein Aus High Low |
Alternativ kann man den Firmware-Upgrade Modus aktivieren, indem man beide Tasten drückt und dann den Reset-Taster zuerst loslässt. Der Schaltplan dazu wäre natürlich noch hilfreich, das werde ich ergänzen.
Stefan U. schrieb: > Der Schaltplan dazu wäre natürlich noch hilfreich, das werde ich > ergänzen. Dann kannst ja gleich noch den Rest ergänzen Deep Sleep: "Umrüstung": http://www.esp8266.com/viewtopic.php?p=62476 -UART muss ggf. deaktiviert werden, würde sonst automatisch ESP wieder aufwecken Linear Regler Querstrom: -MCP1702T sehr geringer Querstrom und direkt beim Chinesen verfügbar https://www.aliexpress.com/item/20PCS-MCP1702T-3302E-CB-MCP1702T-3302E-MCP1702-SOT23/32656495333.html Ich empfehle Links für die Überschriften wie bei Wikipedia einzurichten. ESP32 kannst ja auch gleich noch dazu nehmen: https://github.com/espressif/arduino-esp32
> UART muss ggf. deaktiviert werden, würde sonst automatisch ESP > wieder aufwecken Die Info ist veraltet. Spätestens ab SDK 1.5.4 ist das nicht mehr nötig. habe ich ausprobiert. > MCP1702T Der ist zu schwach, funktioniert nur in Kombination mit einem dicken Puffer-Elko. Solche Murks-Schaltungen empfehle ich nicht weiter. > Ich empfehle Links für die Überschriften wie bei Wikipedia einzurichten. Habe ich doch. > ESP32 kannst ja auch gleich noch dazu nehmen Nein, mit dem habe ich keine Erfahrung gesammelt. Ich veröffentliche nur gesicherte Informationen, die ich selbst verifiziert habe.
Stefan U. schrieb: >> MCP1702T > Der ist zu schwach, funktioniert nur in Kombination mit einem dicken > Puffer-Elko. Solche Murks-Schaltungen empfehle ich nicht weiter. Das ist falsch. Der MCP1702T kann bis zu 500mA liefern. Das reicht für den ESP8266 locker. Wer natürlich die empfohlene Beschaltung aus dem Datenblatt weglässt und sich dann beschwert, dass das nicht richtig funktioniert macht irgendwas falsch. Denn das Datenblatt schreibt ganz klar Kondensatoren (sogar Elkos) für einen ordnungsgemäßen Betrieb vor.
Wir sollten das ggf in einem separaten Thread klären. Für den TO ist dieses Detail momentan sicher uninteressant.
Thomas E. schrieb: > Es geht um eine Anwendung, bei der ein Text auf ein Display in einem > Pokal geschrieben werden soll. Frag nicht warum und wieso. Ich weiß es > selber nicht. Das ist für eine Werbeagentur. Wenn es dir nur darum geht einen (kurzen?) Text, d.h. wenige Bytes, zu updaten dann könnte das auch auf anderen Wege gehen. Beispiel: Photodiode sieht aus dem Pokalgehäuse, und du hast am Handy/PC eine Anwendung die den Text, in Lichtimpulsen kodiert, über die Photodiode an den µC schickt. Oder du gibst dem µC ein Mikrofon und überträgst dein Textpaket akustisch über ein frequenzmoduliertes Signal.
bla schrieb: > Beispiel: Photodiode sieht aus dem Pokalgehäuse, und du hast am Handy/PC > eine Anwendung die den Text, in Lichtimpulsen kodiert, über die > Photodiode an den µC schickt. An sowas hatte ich auch schon gedacht. Aber wie ich oben schon schrieb, habe ich 3 Wochen Zeit dafür und mittendrin ist auch noch Weihnachten. Deswegen muß das was sein, was ich praktisch fertig in der Schublade habe. Deswegen auch AVR mit einem bestimmten Display usw. Die Idee mit dem Bluetooth war halt, daß ich in einer gewissen Naivität dachte, daß wäre Plug'n'Play wie bei USB-To-Serial. Dann hätte ich eine Schnittstelle dafür vorgesehen und wenn die Frage danach aufkäme, könnte ich sagen, daß ich das noch nachrüsten könne. Dann würden sie fragen, was das kostet und wenn der Preis passt: "Dann bauen sie uns doch noch einen." Man muß auch ans Geschäft denken. Schließlich muß ich meine Brötchen auch bezahlen. Danke für die Anregungen an alle Beteiligten. Werde mir das in nächster Zeit mal durch den Kopf gehen lassen, um meine Bildungslücke auf dem Gebiet zu schließen. Stefan U. schrieb: > Wir sollten das ggf in einem separaten Thread klären. Für den TO ist > dieses Detail momentan sicher uninteressant. Das widerfährt doch vielen Threads über kurz oder lang. Und da ich manchmal auch nicht ganz unbeteiligt daran bin, ist das schon OK.
:
Bearbeitet durch User
Oder mit NFC auf dem Sockelboden.. Ist Standard, kann man das Handy direkt vorhalten oder über einen Chip programmieren. Irgendwie uart/i2c.. Hab ich heute zwar erst selbst gefunden, aber das könnte klappen. Auch bei Reichelt gesehen. http://wiki.seeed.cc/Grove-NFC/
Es gibt auch noch Nfc Module.. Da könnte man 1. Das Handy direkt vorhalten oder B Danish B. schrieb: > afaik kann man NFC unter iOs nicht frei programmieren. Brauch man doch nicht.. Man benutzt ja nur eine vorhandene Standardapp zum Tag lesen und schreiben..
Okay, das ist ja eher hinterweltlich bei Apple.. Das die Handys garkeine Standard Tools von Nfc unterstützen, ist ja überhaupt nicht zeitgemäß und war mir auch nicht bekannt. Ich kenne das als Android-User nur von Android, 100te Apps zum NFC auslesen und beschreiben. Das update soll ja bei Apple im kommen sein.
Thomas E. schrieb: > Die Idee mit dem Bluetooth war halt, daß ich in einer gewissen Naivität > dachte, daß wäre Plug'n'Play wie bei USB-To-Serial. Naja, ganz so abwegig ist das nicht. Es gibt ja BLE-Module, die sowohl Central als auch Peripheral können. Damit wäre ein zweigeteilter Ansatz möglich: Eine Leiterplatte kommt in das Gerät und beinhaltet ein BLE-Modul. Eine weitere Leiterplatte kommt an das Notebook und beinhaltet ein weiteres BLE-Modul, als auch einen USB-Umsetzer (wie z.B. den FT232R). Das ginge sehr schnell, hat aber den Nachteil, dass der Nutzer dann per Terminal arbeiten müsste (BLE-Befehle, Modulkonfiguration). Immerhin müsste er * Nach Geräten scannen * Sich dann mit dem richtigen Verbinden * Dann über die virtuelle Serielle Schnittstelle den Text senden (evt. auch mit übergeordnetem Protokoll; je nach Bedarf) Notfalls könnte man die Software die obiges automatisiert erledigt evtl. nachreichen. Obiges lässt sich u.a. mit dem RN4871/RN4870 realisieren. Kann ich aber nicht empfehlen. Amber Wireless (aka. Würth Elektronik) bietet auch solche Module an, ich weiß aber nicht, ob diese die o.g. Funktionalität voll unterstützen. Mit freundlichen Grüßen danishbelal https://www.amber-wireless.de/de/amb2621.html
Thread beobachten
Seitenaufteilung abschaltenBitte 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.