Welches BLE-Modul - für Auswertung einer Waage - würdet Ihr empfehlen,
wenn am AVR die I2C-Pins frei sind? Software-UART statt I2C sollte dort
auch gehen (8bit-Timer frei + 18.4MHz AVR).
Google findet vor allem nRF51822. Ist das das, was man zur Zeit nimmt?
Soweit ich es verstehe, ist das ein SoC, selber zu programmieren. Hört
sich kompliziert an. Oder ist das nur eine Frage von "Jetzt spiele ich
fertige BLE-Firmware vom Hersteller auf und fertig ist es"?
Bei der Waage weiss ich noch nicht, welche ich nehmen werde. Zumindest
bei einer habe ich aber das Protokoll:
"Weight comes in on 0000EF81-0000-1000-8000-00805F9B34FB
Like so:
0x07: length
0xff: manufacture data
0xef: service header byte1
0x81: service header byte2
0x__ weight val byte1
0x__ weight val byte2
0x__ weight val byte3
0x__ weight val byte4
usw."
BLE sagt mir zur Zeit noch nichts. Wenn man kein Protokoll hat: Kann man
die lange Zahl (UUID = Adresse?) herausfinden und dann versuchen, sich
aus den Daten einen Reim zu machen - oder kann man solche Gerät nur
ansprechen, wenn man das Protokoll vorliegen hat?
Frank schrieb:> "Weight comes in on 0000EF81-0000-1000-8000-00805F9B34FB
Das ist die UUID. Du musst das Bluetooth Modul so konfigurieren, dass es
die Daten von dieser UUID empfängt und an dein Programm weiter reicht.
Unter Linux kann man die UUID's damit anzeigen:
https://github.com/pcborenstein/bluezDoc/wiki/hcitool-and-gatttool-example> Bei der Waage weiss ich noch nicht, welche ich nehmen werde> Wenn man kein Protokoll hat ...> kann man solche Gerät nur ansprechen, wenn man das Protokoll vorliegen hat?
Es wäre reine Glückssache. Ich würde nur Produkte kaufen, bei denen das
Protokoll dokumentiert ist.
Google hat noch zu diesem BLE-Modul geführt: RN4871 on Microchip. Hat
jemand eine Meinung dazu?
UART-Befehlsinterface. Schätze das funktioniert so ähnlich wie das
AT-Interface beim BTM222-Modul, das ich mal hatte. Hört sich einfacher
als nRF51 an (?).
Ein Problem damit wäre voraussichtlich, dass dessen Baudrate 115200 ist.
Das werde ich mit Soft-UART nicht schaffen. Aber das lässt sich
anscheinend umschalten (hoffentlich mit Speicherung in
non-volatile-Memory).
> Google findet vor allem nRF51822. Ist das das, was man zur Zeit nimmt?
Die Dinger sind gut eingefuehrt und dokumentiert. Werden aber wohl
gerade duch moderneres ersetzt. Wenn du also basteln willst dann sind
sie optimal.
> Soweit ich es verstehe, ist das ein SoC, selber zu programmieren. Hört> sich kompliziert an.
Haengt von der grauen Masse zwischen deinen Ohren ab. :-)
Ich hab von 0(keine Ahnung von BLE) auf erfolgreiche Uebertragung mit
eigenem Programm auf beiden Seiten etwa 40h gebraucht.
> Oder ist das nur eine Frage von "Jetzt spiele ich> fertige BLE-Firmware vom Hersteller auf und fertig ist es"?
Du musst eine Firmware vom Hersteller aufspielen und dann diese Libary
in deinem eigenen Programm benutzen. Das nimmt dir schon 90% der ARbeit
ab, aber die restlichen 10% sind auch noch Arbeit.
> BLE sagt mir zur Zeit noch nichts. Wenn man kein Protokoll hat: Kann man
Das sind die ersten 8h auf der Strasse zum Erfolg. :-D
> oder kann man solche Gerät nur> ansprechen, wenn man das Protokoll vorliegen hat?
Kann man nicht vorhersagen. Der Hersteller könnte es voll krass
verschluesselt uebertragen und dann bist du erstmal chancenlos. Aber
wahrscheinlich wird er nur ein paar Bytes und vielleicht eine Pruefsumme
uebertragen und dann ist es mit etwas Phantasie kein Problem.
Tip: Es gibt von Nordic ein Testprogramm fuer BLE das auf einem
Androidhandy lauft. Wenn du die Grundlagen von BLE verstanden hast dann
koenntest du mal probieren ob du damit sinnvolle Daten von deiner Waage
auslesen kannst.
Olaf
Frank schrieb:> .. oder kann man solche Gerät nur> ansprechen, wenn man das Protokoll vorliegen hat?
BLE Gerät kann man fragen was sie können.
Viele batteriebetriebene Gerät antworten dann z.B. das sie
"0000180f-0000-1000-8000-00805f9b34fb" unterstützen..
> Du musst eine Firmware vom Hersteller aufspielen und dann diese Libary in deinem
eigenen Programm benutzen. Das nimmt dir schon 90% der Arbeit
ab, aber die restlichen 10% sind auch noch Arbeit.
Danke für die Infos. Man spielt anscheinend erst ein "Soft Device" auf,
das den Bluetooth-Stack bereitstellt, dann eigene Firmware. Es scheint
keine fertige "AT-Firmware" vom Chiphersteller zu geben, aber von
Drittherstellern gibt es Platinen mit diesem Chip und AT-Firmware, z.B.
BlueFruit von https://www.adafruit.com/product/2479. Mit der Firmware
wäre ich vermutlich da, wo das (etwa teurere) RN4871 on Microchip ab
Werk ist: BLE-Modul mit Textbefehlen.
Was ich jetzt noch gerne wissen würde: Wenn man die Beschreibung der
Waage hat (übrigens Modell "skale 2" von
http://skale.cc/en/buyIntl.html), womit eigentlich nur die UUID
angegeben ist, kann man dann davon ausgehen, dass die AT-Firmware die
Waage auch ansprechen kann - oder muss die AT-Firmware bestimmte
"Services" unterstützen, so wie SPP bei klassischen Bluetooth-Modulen?
Bei adafruit steht z.B.
"The following commands allow you to interact with various GATT services
present on Bluefruit LE modules when running in Command Mode"
(https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-uart-friend/ble-services)
Woher weiss ich, auf welchen Service ich bei der Modulauswahl achten
sollte? Ich finde in der kurzen Protokollbeschreibung der Waage keinen
Hinweis auf einen Service. Nur die UUID:
BLE API SPECIFICATION for Skale I and II:
Weight comes in on 0000EF81-0000-1000-8000-00805F9B34FB
Like so:
0x07: length
0xff: manufacture data
0xef: service header byte1
0x81: service header byte2
0x__ weight val byte1
0x__ weight val byte2
0x__ weight val byte3
0x__ weight val byte4
Die UUID ist der Schlüssel zu dem GATT-Service, den Du im Code des
Applikationsprozessors im Modul anlegen musst. Dnach kommen dann noch 8
Bytes, die die Informationen enthalten.
Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege.
Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug
Resourcen dafür.
Nordic ist ein beliebter Hersteller entsprechender Chips.
Die beiden Alternativen wären TI (CC254x und CC264x,
http://www.ti.com/wireless-connectivity/simplelink-solutions/bluetooth-low-energy/overview/overview.html
) und SiLabs (
https://www.silabs.com/products/wireless/bluetooth/bluetooth-low-energy-modules
).
Letztendlich wirst Du es immer mit einem Cortex M3 oder M4
Applikationsprozessor zu tun haben. Schau Dir die Hersteller an, und
starte vielleicht erstmal mit einem Hersteller-Evalboard. Da ist oft
schon ein Debugger, zusätzliche Peripherie und eventuell auch
Strommess-Hardware mit drauf (keine Ahnung, ob das für Dich relevant
ist). Damit kannst Du dann in die Serie gehen.
fchk
Aktuell ist die nRF52 Reihe von Nordic Semiconductor state of the art.
Im allgemeinen sind Anwendungen basierend auf BLE aber (noch) nicht ganz
so einfach umzusetzen. Die nRF52 Reihe löst die nRF51 sowie von TI der
CC2650. Das sind alles SOC, haben also bereits eine MCU integriert.
Wenns kein BLE sein muss, dann würde ich, der einfachheitshalber auf die
HC-05/HC-06 setzen. Die können dann mit einem AVR über UART und AT
commands gesteuert werden.
Frank K. schrieb:> Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege.> Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug> Resourcen dafür.
Jein. Genug Ressourcen schon, aber wenn man z.B. einen Nordic mit
softdevice nutzt, hat das softdevice immer die höchste Priorität und
kann der Applikation (im wahrsten Sinne des Wortes) jederzeit dazwischen
funken. Kommt halt ganz auf die Anwendung an, ob das okay ist.
FK schrieb:> Frank K. schrieb:>> Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege.>> Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug>> Resourcen dafür.>> Jein. Genug Ressourcen schon, aber wenn man z.B. einen Nordic mit> softdevice nutzt, hat das softdevice immer die höchste Priorität und> kann der Applikation (im wahrsten Sinne des Wortes) jederzeit dazwischen> funken. Kommt halt ganz auf die Anwendung an, ob das okay ist.
Wenn das ein Problem sein sollte, wäre z.B. ein TI CC2642R geeigneter.
Da läufen die zeitkritischen Sachen auf einem extra Cortex M0. Wie es
bei SiLabs ist, weiß ich nicht.
fchk
Ich würde hier mal noch u-blox reinwerfen. Sind Recht einfach zu
konfigurierende BLE auf uart Wandler mit nRF52. Da muss man sich nicht
mit dem Bluetooth Stack abmühen.
FK schrieb:> Frank K. schrieb:>> Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege.>> Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug>> Resourcen dafür.>> Jein. Genug Ressourcen schon, aber wenn man z.B. einen Nordic mit> softdevice nutzt, hat das softdevice immer die höchste Priorität und> kann der Applikation (im wahrsten Sinne des Wortes) jederzeit dazwischen> funken. Kommt halt ganz auf die Anwendung an, ob das okay ist.
Die maximale zusätzliche Latenz wird von Nordic aber angegeben, z.B. für
M4/S140:
Open peripheral interrupt: Softdevice enabled: < 3 μs Softdevice
disabled: < 1 μs
Blocked or restricted peripheral interrupt: Softdevice enabled: N/A
Softdevice disabled: < 2 μs
(only forwarded when SoftDevice disabled)
Application SVC interrupt: Softdevice enabled: < 2 μs Softdevice
disabled: < 2 μs
Wenn das für die eigene Applikation passt, ist ja alles OK.
nfet schrieb:> Ich würde hier mal noch u-blox reinwerfen. Sind Recht einfach zu> konfigurierende BLE auf uart Wandler mit nRF52. Da muss man sich nicht> mit dem Bluetooth Stack abmühen.
u-blox hat viele Produkte. Was meinst Du genau?
Hi,
ich möchte hier mal die Cypress Produkte ins Rennen werfen
http://www.cypress.com/products/ez-ble-and-ez-bt-bluetooth-modules
Zum einen hat Cypress vor 2(?) Jahren den Bereich Embedded BLE/WiFi von
Broadcom übernommen, und mit den PSoC BLE auch eigene Produkte.
Es gibt einiges an (fertigen) Beispielen und die Programierung
(zumindest für die PSoCs mir bekannt) ist die einfache IDE, PSoC
Creator.
Ausserdem haben die PSoCs auch noch einiges an Peripherie bis hin zu
eimem mini FPGA/PLD (nennt sich UDBs) auf dem Chip, was auch interessant
sein könnte. Und jeder GPIO lässt sich auch als Kapazitssensor für
Touch-Bedienung (z.B. Button, Slider, etc) verwenden. Alles in allem
bekommst Du damit weit mehr als reines BLE.
Die zertifizierten Module sind teils kleiner als 1cm².
Grüße Mic Roller
