Guten Morgen zusammen,
seit etlichen Stunden versuche ich hinter die Magie des nRF51 zu
steigen.
Meine Toolchain sieht folgendermaßen aus:
nRF51422 - Debugger (Distortec JTAG-lock-pick Tiny 2 über SWD) -
VisualGDB - VisualStudio
VisualGDB stellt auf Knopfdruck das S130-Softdevice bereit.
Bisher habe ich einfache high- und low-Pegel mit dem Chip hinbekomme
oder auch ein Beacon-Sample ans laufen gebracht, daher weiß ich, dass
mein Mikrokontroller funktioniert und ich problemlos drauf zugreifen
kann.
Allerdings habe ich festgestellt, dass mein Beispielcode nur in
Verbindung mit VisualStudio läuft.
Womit wir zu meinem ersten Anliegen kommen:
1. Starte ich das Debugging, so kann ich dasn µC nutzen. Beende ich
VisualStudio, so startet mein Code nicht mehr.
Wird hier unterschieden zwischen Debugging in einer Art Live-Modus und
dem eigentlichen Beschrieben des Chips? Anderst kann ich mir das bisher
nicht erklären.
Weiterhin würde ich gerne einen TWI-Sensor auslesen.
Alle mir bekannten Beispiele setzen auf Keil oder sonstigen IDEs auf,
welche seitens Nordic mit Samples versorgt werden.
Auf VisualGDB-Seite hingegen sieht es da etwas mager aus mit
Dokumentationen und den notwendigen Libraries.
Viele Beispiele greifen auf Libs zu, welche ich schlichtweg nicht habe
oder als Download finden kann.
Als Sensor habe ich einen ST Lis2DH12, den ich gerne über TWI ausewrten
würde und anschließend über Bluetooth die Daten versende.
Aber eins nach dem anderen. Zunächst einmal würde ich gerne einen
TWI-Scanner ans Laufen bringen, damit ich wieß, ob die Kommunikation mit
den Sensoren funktioniert.
Bisher habe ich TWI-mäßig nur auf Arduino-Basis 'gespielt', wo einem
alles mit relativ einfachen Libs vorgekaut wird. Einerseits ne tolle
Sache, andererseits macht es mir den Einstieg hiermit etwas schwer.
Ich habe auch schon Bücher hinsichtlich embedded developement gesucht,
jedoch bisher kein Werk gefunden, was aktuelle ARM-Kerne behandelt (von
O'Reilly gibts ein Werk von 2011, aber ob es eine aktuallisierte
Neuauflage geben wird, wurde mir vom Support bisher nicht
beantwortet...).
Also in Kurz nochmal mein Vorhaben:
2. Erster TWI-Scan um zu sehen, ob der Sensor ansprechbar ist (ich habe
gelesen, dass die SDA/SCL-Pegel häufig zu gering sind beim nRF51...daher
habe ich auf meiner Platine schon Pullups vorgesehen, aber noch nicht
eingesetzt, evtl. kann ich morgen ein DSO ausleihen, um mir den Pegel
anzusehen, falls ich heute die Ansprache des Sensors nicht hinbekomme).
3. ST LIS2DH12 ansprechen und Daten über VisualStudio
(printf(<sensordata>);) ausgeben (über die VisualGDB
FastSemihosting-Erweiterung kann ich die Daten dann einsehen).
Soweit ich das verstanden habe, wird hierzu zunächst ein Schreibzugriff
auf ein Sensorregister vorgenommen, um diesen zu aktivieren.
Laut Datenblatt S.54:
(http://www.st.com/resource/en/datasheet/lis2dh12.pdf)
The Slave ADdress (SAD) associated to the LIS2DH12 is 001100xb. The
SDO/SA0 pad canbe used to modify the less significant bit of the device
address. If the SA0 pad is connected to the voltage supply, LSb is ‘1’
(address 0011001b), else if the SA0 pad is connected to ground, the LSb
value is ‘0’ (address 0011000b). This solution permits to connect and
address two different accelerometers to the same I2C lines.
TWI-Adresse: 001100 0 0/1
Die darauffolgende Stelle die Adresse genauer spezifiziert (so dass auch
zwei dieser Sensoren genutzt werden könnten).
Und die allerletztes Stelle 1=read und 0=write bedeuten.
4. Daten über Bluetooth versenden.
Ich habe bisher Erfahrungen mit dem HC-05 und HC-06 sammeln können als
auch mal einigen BLE HM-10 Modulen eine andere Firmware verpasst. Eine
Datenverbindung über Bluetooth 4 habe ich jedoch noch nicht
initialisiert bekommen. Beim HC-05/6 kann ich einfach seriell Daten
übertragen.
Wie gehe ich nun vor, um meine Sensordaten über BLE zu übertragen?
Auf der Smartphoneseite würde ich gerne zunächst die Nordic Tools zum
Empfangen nutzen.
Erwähnenswerd ist noch, dass meine Platine auf dem Dynastream N550M8CC
mit nRF51422-CEAA basiert, wüfor gilt:
The N5 module comes with 50ppm onboard 32 kHz crystal. When initializing
the SoftDevice, it is important to set the crystal accuracy to be 50ppm.
In the preloaded ANT Network Processor code, this line is used:
sd_softdevice_enable(NRF_CLOCK_LFCLKSRC_XTAL_50_PPM,
softdevice_assert_callback)
Leider ist diesbezüglich nicht erwähnt, ob das für ANT und/oder BLE
gilt, als auch nicht die Softdevice-Version.
Bzgl. der Pinauswahl habe ich SCL auf P24 gelegt und SDA auf P21.
Leider ist mir auch unklar, ob ich in den VisualGDB-Einstellungen nun
TWI als Softwaremaster oder Hardwaremaster auswählen muss.
Ich habe gelesen, dass TWI auf dem nRF51 sowieso softwareseitig
umgesetzt ist.
Erstmal etwas Grundsätzliches:
Unabhängig von der IDE verwendest Du hoffentlich das nRF5 SDK in der
aktuellen Version (bzw. die vorletzte, da die neueste den nRF51 nicht
mehr unterstützt).
Das Softdevice wird Dir von Nordic bereitgestellt. Auch dieses hat eine
Versionierung, d.h. z.B. das Softdevice 130 Vx muss zum SDK Vy passen.
Sowohl die Softdevices, als auch das jeweilige SDK sind im Infocenter
von Nordic sehr gut dokumentiert:
http://infocenter.nordicsemi.com/index.jsp
Mit dem Debuggen ist das auch so eine Sache, sobald ein Softdevice im
Spiel ist. Aber das wird erst relevant, wenn die Basics stimmen. Ich
würde zunächst also sicherstellen, dass die Toolchain das aktuelle SDK
verwendet, alles andere macht meiner Meinung nach keinen Sinn.
mfg
Michael
Micha W. schrieb:> 1. Starte ich das Debugging, so kann ich dasn µC nutzen. Beende ich> VisualStudio, so startet mein Code nicht mehr.> Wird hier unterschieden zwischen Debugging in einer Art Live-Modus und> dem eigentlichen Beschrieben des Chips? Anderst kann ich mir das bisher> nicht erklären.
Beim NRF51 ist einer der Debug Pins gleichzeitig auch Reset. Falls der
Debugger den beim Beenden auf Low zieht, bleibt der Chip solange im
Reset wie der Debugger angesteckt bleibt. Bei gewöhnlichem SWD wäre das
egal.
Alledings:
Micha W. schrieb:> 3. ST LIS2DH12 ansprechen und Daten über VisualStudio> (printf(<sensordata>);) ausgeben (über die VisualGDB> FastSemihosting-Erweiterung kann ich die Daten dann einsehen)
Diese Semihosting Option verhindert üblicherweise einen Betrieb ohne
Debugger, da beim Start auf diesen gewartet wird. Ansonsten würden
Messages verloren gehen beim Start.
Micha W. schrieb:> sd_softdevice_enable(NRF_CLOCK_LFCLKSRC_XTAL_50_PPM,> softdevice_assert_callback)>> Leider ist diesbezüglich nicht erwähnt, ob das für ANT und/oder BLE> gilt, als auch nicht die Softdevice-Version.
Mach das einfach bei allen Softdevices. Hier teilst Du dem Sofdevice nur
mit wie genau Dein verbauter Quarz ist.
Micha W. schrieb:> Wie gehe ich nun vor, um meine Sensordaten über BLE zu übertragen?
Dafür muss man i.d.R. ein Profil implementieren. Im NRF SDK sind etliche
Profile als Beispielcode enthalten.
Micha W. schrieb:> 2. Erster TWI-Scan um zu sehen, ob der Sensor ansprechbar ist (ich habe> gelesen, dass die SDA/SCL-Pegel häufig zu gering sind beim nRF51...daher> habe ich auf meiner Platine schon Pullups vorgesehen, aber noch nicht> eingesetzt,
I²C braucht immer externe Pullups. Es gibt praktisch keine relevanten
Ausnahmen von der Regel.
TWI Beispielcode gibts im NRF SDK. Das übrigens auch mit GCC
funktioniert - ich musste im Eclipse nur die gefühlt hundert Include
Pfade eintragen, denn im NRF SDK sind die Header Files leider weit
verstreut.
Ah, okay. Die Info mit den externen Pullups ist gut.
Intern sollen laut Datenblatt S. 65 11-16K als Pullup verbastelt sein.
Welchen Wert sollte ich dann noch extern wählen?
15K sowas um den Dreh?
Mit den SDK-Beispielen tu ich mir ein bisschen schwer.
Ich habe es nicht geschafft diese über VisualGDB zu laden.
Sobald ich die kompilieren möchte, werde ich mit fehlenden Headerdateien
etc. zugebombt :/
Ich denke, wenn ich die fehlerfrei kompilieren könnte, wäre das n guter
Ansatz um mich da durchzuhangeln.
Daher war ich froh, dass ich die in VisualGDB vorhandenen Beispiele
kompilieren konnte und faher weiß, dass ich auf den Chip zugreifen kann.
Hier ist mal ne Übersicht über die Beispiele in VisualGDB:
www.digitalinventions.de/pics/visualgdb/screenshot_12.jpg
Dann fang doch mal mit dem Heart Rate Service an.
Dieser zeigt recht schön die Implementierung eines Services mit einer
Charakteristik, die "Notification" unterstützt.
Für eigene Services, die nicht von der Bluetooth SIG spezifiziert sind,
musst Du allerdings Custom UUIDs verwenden.
Micha W. schrieb:> Welchen Wert sollte ich dann noch extern wählen?> 15K sowas um den Dreh?
I²C Pullps sind unkritisch im Bereich von 1-10k, also würde ich einfach
10k Ohm einsetzen.
> Mit den SDK-Beispielen tu ich mir ein bisschen schwer.
Mein Kommentar mit den 100 Headern war durchaus ernst gemeint,
die Anzahl der benötigten Verzeichnisse ist für die meisten Beispiele
zweistellng.
Aber irgendwas müssen die VisualGDB Leute auch gemacht haben, sonst
würden deren Beispiele nicht laufen. Hier lohnt es sich mit scharfem
Auge hinzusehen - denn das muss ja auch irgendwie auf dem Nordic Krams
basieren, eventuell auf einem älteren SDK.
Genau das hab ich mir auch gedacht.
Ich hab mir mal die Keil µVision installiert, komm da aber auch nicht
weiter (ist ne 5er, das Nordic SDK basiert auf Keil 4 - selbst das ist
also unmöglich).
Ich hab den VisualGDB-Support nochmal angeschrieben. Wenn die sich da
keine Gedanken drum gemacht hätten, wären die Nordic-Samples ja nicht im
App-Data-Ordner mit drin.
Ich denke der geschulte Blick von jemanden der sich damit auskennt würde
da vermutlich mehr bringen als meine rudimentären Grundkenntnisse...ich
fang langsam an zu verzweifeln bei dieser (für mich) Großbaustelle.
Das mit den eigenen Profilen hatte ich schon gelesen.
Ich hatte erstmal auf eine Art UART über BLe gehofft. Das müsste ja
definiert sein. Aber darum kümmere ich mich, sobald ich die Daten vom
Sensor habe.
Danke für den Hinweis. Aber uVision scheint da auch nicht alle
notwengiden Daten zu haben oder laden zu können.
Hab n paar Packs nachgeladen, aber es jemmaert immer noch rum, dass es
mit dem Device nicht klarkommt.
Da war ich mit VisualGDB schon weiter :D
//Edit: Außerdem scheint uVision nicht mit meinem Debugger klarzukommen
:/
Das nötige Pack wird doch im SDK-Zip-File mitgeliefert. Bis ich alleine
die oben gezeigten Einstellungen von VisualGDB durch habe, habe ich mein
Device mit Keil schon im Advertising-Mode :)
Das Nordic SDK ist für uVision4 ausgelegt (zumindest der Installer).
Wie gesagt, beim Öffnen mit uVision5 bekomme ich auch einige Sachen, die
Fehlen, an den Kopf geschmissen:
Error instantiating RTE components
Error #544: Required Software Pack 'ARM.CMSIS.4.5.0' is not installed
Error #544: Required Software Pack
'NordicSemiconductor.nRF_DeviceFamilyPack.8.11.1' is not installed
Error #541: 'ARM::CMSIS:CORE:4.3.0' component is missing, pack
'ARM.CMSIS.4.5.0' is not installed
Error #541: 'NordicSemiconductor::Device:Startup:8.11.1' component is
missing, pack 'NordicSemiconductor.nRF_DeviceFamilyPack.8.11.1' is not
installed
Refresh Pack descriptions
Cannot install Pack(ARM:CMSIS:4.5.0), Pack not foundCannot install
Pack(NordicSemiconductor:nRF_DeviceFamilyPack:8.11.1), Pack not found
Check for updates
Refresh Pack descriptions
Update available for ARM::CMSIS (installed: 5.0.0, available: 5.0.1)
Mit uVision komm ich also auch nicht so ohne Weiteres voran. Auch
uVision4 hab ich nirgends zum Download gefunden.
Micha W. schrieb:> Das Nordic SDK ist für uVision4 ausgelegt (zumindest der Installer).
Die neueren SDKs gibt es als PAcks direkt im Keil, also besser nix
extern installieren.
Ja, das habe ich grade auch schon gefunden. Sogar Alphas von
irgendwelchen Packs.
Aber dennoch habe ich das Problem, dass mein jTag Lock-Pick tiny 2.0
nicht ovn Keil unterstützt wird.
Ich suche grade, ob Keil irgendwie über OpenOCD debuggen kann, denn
OpenOCD kommt mit meinem jTag-Debugger zurecht ;)
Am liebsten wär mir dennoch eine Lösung, dir out-of-the-box direkt
funktioniert, damit ich mich mit dem eigentlichen Problem befassen kann
und nicht noch weitere Stunden in die Toolchain investieren muss.
Gibt es die Nordic-Headerfiles nicht auch als einzelnes Bundle, was ich
einfach irgendwo in Visual Studio / VisualGDB integrieren kann?
Der Support von Sysprogs (VisualGDB) meinte folgendes:
The easiest way to import a project would be to reuse an existing
Makefile. Select "specify a build command line manually", then configure
VisualGDB to launch make.exe in the corresponding directory (e.g.
<SDK>\examples\ble_central\ble_app_hrs_c\pca10028\s130\armgcc).
This won't configure IntelliSense properly and won't import all source
files, but will quickly get the project to a state where you can build
and debug it.
Aber das klingt mir eher nach einer Behelfslösung, dir mir nicht dabei
hilft, mein eigenes Projekt sinnvoll zu erstellen.
So, ich hab mir mal das Dev-Kit bestellt und es ist inzwischen auch
angekommen. Jetzt brauch ich nur noch den passenden Stecker für den
DEbugger-Ausgang.
Ich hab da bisher nichts gefunden und auch mein lokaler Elektronikladen
hat nichts in der Art.
Ich hab jetzt nach Buchsenleiser 2x5 1mm gesucht, aber nichts
gefunden...
Ah, okay. Ich hatte Tomaten auf den Augen. Direkt neben dem
10-Pin-Anschluß ist noch ne 2,54mm Stiftleiste - ich habs aber erst
gesehen, nachdem ich diese Webseite gefunden habe:
http://electronut.in/nrf51-dk-external-programming/
Dann werd ich gleich mal Keil uVision ins Visier nehmen ;)
Allerdings muss ich dazu erst noch herausfinden, wie ich den
OnBoard-Segger des DK in den Debuggermodus schicke - momentan ist das
dieser Speichermodus - man kann mit Windows Dateien wie auf nem
USB-Laufwerk ablegen und er flasht das. Das Problem ist nur, dass ich
ihn so nicht als jLink in meinen IDEs sehen kann :D
Die indische? Seite hatte ich auch gerade gefunden.
Wenn ich das recht versteht, schaltet der Debugger bei anlegen der
Spannung am 8-pol Debug Port um.
User Guide Seite 20
Bist Du noch in der IDE Probe Phase?
Ich habe mir das mit eclipse nach dem youtube Video von pcbflux
eingerichtet.
Der Debug-Port ist 10-polig ;)
Beim Anlegen einer Spannung daran wird von internem nRF51 auf externes
Debugging gewechselt.
Was meinst du mit IDE Probe-Phase?
Ich hab bisher mit VisualStudio und VisualGDB auf meinen nRF51422
zugegriffen. Aber VisualGDB zickt bei den Include-Pathes rum und
integriert nur die LIbs, die für die eigenen Samples genutzt werden.
Ich habs nicht geschafft die restlichen Libs richtig zu implrementieren
und deswegen habe ich mit uVision 5 installiert.
Damit möchte ich gleich versuchen über den Segger jLink OB, der im
Dev-Kit verbaut ist, auf meinen nRF51 zuzugreifen.
Wenn das klappt, würde ich gerne die restlichen Nordic-Samples
kompilieren und testen, damit ich auf dieser Grundlage meine eigene
Platine ans Laufen bringe ;)
Micha W. schrieb:> Der Debug-Port ist 10-polig ;)
Ich meine den P20.
Bei den genannten youtube Videos hat alles mit Makefile am Anfang gut
funktioniert. Mit gedit unter Linux war auch alles gut.
Über github gibt es auch alle Quellen.
Mit eclipse auch keine Problem mit ST-Link V2.
Allerdings habe ich es dann mit den verschiedenen SDK Versionen total
verwurschtelt.
Was noch entscheidender ist: wie mache ich ein BLE Host, falls das so
heißt.
Da ich mehr im STM32 Bereich bin, und demnächst von STM ein BLE bei RS
verfügbar sein sollte, habe ich dann auch nicht weiter gemacht.
Ausser es findet sich noch eine Möglichkeit zum BLE Host.
Oh, ich habe eben das Developement Board mit gedrückter Reset-Taste
gestartet - wollte schauen, ob der Moduswechsel funktioniert.
Hat auch soweit geklappt.
Aber bevor ich das gemacht habe, hatte ich ne schöne grüne LED am
leuchten - jetzt nicht mehr.
Im Bootloader-Mode blinkt die LED. Aber im Ich bin mir nicht sicher, wie
ich den Button nun wieder als Reset für den nRF verwenden kann, bzw. was
da passiert ist.
Im User Guide steht auch nur, wie man den Bootloader-Modus aktiviert -
aber wie man zurückkommt, bzw. was man damit genau ändert, hab ich noch
nicht gefunden :D
Wie es sich vorher angemeldet hat, weiß ich nicht. Hab da leider nicht
drauf geachtet.
Aber jetzt bin ich im Bootloader-Modus.
Ich hab im Bootloader-Modus mal die J-Link OB-SAM3U128-V2-NordicSemi
160212.bin von
https://www.nordicsemi.com/eng/nordic/download_resource/52276/5/42250904
draufgeladen und jetzt gibt er sich als jLink zu erkennen.
In VisualGBD gibt er sich aber nicht als jLink zu erkennen...
Wie müsste ich den denn in uVision sehen/finden?
Jetzt muss ich nur noch rausfinden, wie ich in uVision die
Nordic-Beispiele laden und kompilieren kann.
Unter Projekt-Managa-Pack Installer sehe ich zwar, dass die gewünschten
Samples und Libraries installiert sind, aber ich finde keine Möglichkeit
die Samples zu öffnen oder aus den Packs heraus zu zu verwenden.
Ich bin auch offen für Eclipse mit GCC, wenn ich das zum laufen bringe.
Ich lade grade die Sachen runter und werde da mal mein Glück versuchen.
Ich hangel mich grade hier lang:
https://devzone.nordicsemi.com/tutorials/7/
Bei Keil konnte ich im Keil-Ordner die Nordc-Samples öffnen.
Allerdings wenn ich debuggen möchte, spuckt keil folgendes aus:
Error: Flash Download failed - Could not load file
'C:\Keil_v5\ARM\PACK\NordicSemiconductor\nRF_Examples\10.0.0\peripheral\
twi_sensor\pca10028\arm5\_build\nrf51422_xxac.axf'
Der Ordner ist leer.
Ich denke, dass ich heir vermutlich noch irgend eine simple Einstellung
vornehmen muss. Schließlich soll Keil ja so einfach sein beim Setup ;)
https://www.youtube.com/watch?v=gufM4r_a7Gg
Dann kannst Du dir das ansehen.
Er beschäftigt sich intensiv mit allen Teilen des nRF51822.
Auf Makefile Basis.
Wie gesagt, sein Code liegt auf github.
Ein klick auf "Mehr anzeigen" unter dem Video bringt Klarheit.
Jupp, aber beim Installieren der ARM-GNU-Tools muss ich rm und make
unter Windows zum laufen bringen, vorher gehts wohl nicht weiter.
Der letzte Link von mir beschreibt das Problem.
Na das größte Problem ist die Toolchain so einzurichten ;)
Die Gnu ARm-Tools zu installieren ist easy. Aber momentan finde ich
keinen Weg OpenOCD in Eclipse zu integrieren. Der erwähnte Menüpunkt
existiert einfach nicht - auch wenn ich im Eclipse-Folder nen
OpenOCD-Folder anlege...
Oh man - schon wieder Stunden mit ner Sackgasse verbracht. Die Gnu Arm
Eclipse Tools kann ich über den Eclipse Marketplace nicht installieren,
weil ne XML-Datei auf Sourceforge nicht gefunden werden kann - das
Projekt ist wohl vor ner Weile nach Github umgezogen...
Die Lösung ist gar nicht so kimpliziert:
http://gnuarmeclipse.github.io/blog/2017/01/29/plugins-install-issue/
Man muss die Dateien
local_policy.jar
und
US_export_policy.jar
im Ordner <java-install-folder>/libs/security ersetzen und Eclipse
neustarten, dann funktioniert der Handshake.
Und ab jetzt hab ich auch in Eclipse in den Einstellungen eine
Möglichkeit den Pfad zu OpenOCD anzugeben ;)
Hmmm....hat denn jemand von euch schonmal unter Windoofs die Gnu ARM
Eclipse-Geschichte genutzt?
Ich habe zwar sämtliche Plugins installiert und auch die Pfade zur
Toolchain als auch zu OpenOCD angegeben. Aber mir ist unklar, wie ich
ein neues Projekt erstellen/die Nordic-Samples importieren und richtig
kompilieren kann.
Halte ich mch an das Video von pcbreflux #14 komm ich bei 4:40 an den
Punkt:
Project Properties - C/C++ General => CDT built output parser.
Aber diesen CDT-Menüpunkt habe ich nicht.
Das lässt vermuten, dass ich das falsche Package von Eclipse
runtergeladen habe - eigentlich sollte die C/C++-Version CDT beinhalten,
wenn ich das richtig verstanden habe.
Ich fang dann nochmal von vorne an...
So, nach etlichen weiteren Stunden der Verzewiflung habe ich nun eine
Toolchain, die einigermaßen funktioniert.
Als Basis dient das Segger Embedded Studio mit SDK12.
Ich konnte das Nordic-Beispiel TWI-Scanner nun kompilieren und über das
Nordic Developementboard mit dem Segger jLink OB flashen und die Adresse
des Sensor auslesen (0x18) auslesen.
Somit habe ich endlich nen Startpunkt um an dem Sensor rumzudoktorn und
es geht weiter :)
Once the device is powered up, it automatically downloads the calibration coefficients from the embedded flash to the internal registers. When the boot procedure is completed, i.e. after approximately 5 milliseconds, the device automatically enters power-down mode. To turn on the device and gather acceleration data, select the HR bit in CTRL_REG4 and the LPen bit in CTRL_REG1, enable at least one of the axes and select the preferred ODR
3
The following general-purpose sequence can be used to configure the device:
Mir ist aber nicht klar, welche Header-Dateien ich aus dem SDK brauche
und wie ich den Sensor initiiere.
Auch hab ich mir der pcdreflux-Video #21
https://www.youtube.com/watch?v=4KCqawaN--E angesehen. Leider sind nicht
die Demofiles aus dem Video verlinkt...so dass ich mit da nicht einfach
was umstricken kann.
Micha W. schrieb:> Leider sind nicht> die Demofiles aus dem Video verlinkt.
Wie meinst Du das?
Das si7021 Projekt ist auf github vorhanden.
https://github.com/pcbreflux/nordic
Liess sich sogar in eclipse als:
"Import -> Projects from git" einfügen.
Oh, da hab ich wohl irgendwann den Wald vor lauter Bäumen nicht mehr
gesehen...
Aber wie gehe ich nun am besten hinsichtlich des ST LIS2DH12 vor?
Ich nur eine Library gefunden, die auf den IC zugeschnitten ist - aber
leider nur in Zusammenhang mit Wire.h und Arduino:
https://github.com/DFRobot/DFRobot_LIS2DH12
Als Anfänger fällt es mir schwer zu bewerten, welche der Register des
LIS2DH12 ich nun ansprechen muss, um die ersten Daten zu bekommen.
Macht es denn mehr Sinn auf die Nordic-TWI-Macros (siehe oben) zu setzen
oder den lis2dh12-Treiber zu nutzen?
Auf der Nordic-Seite kann ich ja TWI initialisieren und über die Macros
auf die Register zugreifen.
Andererseits habe ich im lis2dh12-Treiber auf den Chip abgestimmte
Funktionen und fertige Definitionen hinsichtlich der Register.
Du hast die Libs und Doku von ST gelobt, hast du schonmal damit
gearbeitet?
Ich suche grade zum LIS2DH12_ACC_driver.h n Tutorial oder Beispiel -
damit ich überhaupt mal irgendwelche Daten von dem Sensor bekomme und
anfangen kann rumzuspielen ;)
Ich hab den Sensor testweise mal auf nen Nucleo (L053R8) gepackt
(vielleicht hilft mir das zum einfacheren Verständnis, wenn ich erstmal
mit dem Sensor spiele) und würde gerne mit den ST-Dateien nen Output
erzeugen.
Den L052R8 habe ich mit der jLink OB Firmware ausgestattet und kann
somit den Nucleo auch üebr das Segger Embedded Studio ansprechen - das
klappt soweit.
Angeschlossen ist der LIS2DH12 über das IKS01A1 - da sind auch weitere
Sensoren drauf:
-LSM6D0: 3D accelerometer and 3D gyroscope
http://www.st.com/en/mems-and-sensors/lsm6ds0.html
-LIS3MDL: 3-axis magnetometer
http://www.st.com/en/mems-and-sensors/lis3mdl.html
-LPS25HB: 260-1260 hPa absolute digital output barometer
http://www.st.com/en/mems-and-sensors/lps25hb.html
-HTS221: Capacitive digital sensor for relative humidity and temperature
http://www.st.com/en/mems-and-sensors/hts221.html
Vielleicht ist ja einer der anderen Sensoren leichter für das
prinzipielle Verständnis?
Aber prinzipiell möchte ich gerne die Daten vom LIS2DH12 auslesen.
Für den Sensor habe ich mich auf Grund seiner technischen Daten
entschieden.
Das IKS01A1 hatte ich am Nucleo-L476.
Habe mir auch wieder ein neues besorgt, aber noch nicht im Einsatz.
Mein Startpunkt war das Projekt:
Examples/IKS01A1/DataLog
So, der TWI-Zugriff vom nRF51 aus funktioniert jetzt endlich.
Der nRF51 kann endlich in nem eigenen (nicht Demo-Projekt) den LIS2DH12
auf Adresse 18 sehen ;)
Als nächstes:
Schreiben (zum einrichten) und Lesen der Sensordaten ;)
Mit
nrf_drv_twi_rx
nrf_drv_twi_tx
müsste ich nun den Sensor ansprechen können.
Wie oben bereits geschrieben geht das mit
1
Startup sequence
2
Once the device is powered up, it automatically downloads the calibration coefficients from the embedded flash to the internal registers. When the boot procedure is completed, i.e. after approximately 5 milliseconds, the device automatically enters power-down mode. To turn on the device and gather acceleration data, select the HR bit in CTRL_REG4 and the LPen bit in CTRL_REG1, enable at least one of the axes and select the preferred ODR
3
The following general-purpose sequence can be used to configure the device:
ODR3 ODR2 ODR1 ODR0 LPen Zen Yen Xen[/code]
ODR 0-3 beschreiben, wie häufig der Sensor Daten liefert.
LPen = Low-Power-Mode
X/Y/Zen = die jeweiligen Achsen aktivieren.
Somit wäre z.B. für 10Hz, alle Achsen, normal-Mode:
1
0 0 1 0 0 1 1 1
1
CTRL_REG2 (21h)
2
HPM1 HPM0 HPCF2 HPCF1 FDS HPCLICK HP_IA2 HP_IA1
HPMP = High-Pass-Filter
HOCF = Hich Pass Cut-off Frequency
HPCLICK, HP_IA1/2 = Sonderfunktion, brauch ich nicht
1
1 0 ? ? 0 0 0 0
Die Fragezeichen sind die HighPassFilterCutoff-Frequenz. Leider steht da
nicht mehr zu im Datenblatt.
Sonderfunktionen für den Interrupt. Da ich es nicht brauche, bleibt
alles deaktiviert
1
0 0 0 0 0 0 0 0
1
CTRL_REG4 (23h)
2
BDU BLE FS1 FS0 HR ST1 ST0 SIM
BDU: Block data update. Default value: 0
(0: continuous update;
1: output registers not updated until MSB and LSB have been read)
BLE: Big/Little Endian data selection. Default value: 0
(0: data LSb at lower address; 1: data MSb at lower address)
The BLE function can be activated only in high-resolution mode
FS0/1: Full-scale selection. Default value: 00
(00: ±2 g; 01: ±4 g; 10: ±8 g; 11: ±16 g)
HR: Operating mode selection, ich möchte zunächst den Normal-Mode: 0,
allerdings muss dann auch LPen=0
ST0/1: Self-test, brauch ich nicht: 0
SIM: SPI serial interface mode selection, brauch ich nicht: 0
Gute Arbeit Micha!
Funktioniert es denn jetzt bei dir auch mit dem Auslesen von
Beschleunigungswerten?
Falls jemand den Sensor von einem AVR aus per TWI ansteuern will, hier
ist ein Beispiel-Code für ein Eeprom.
Beitrag "Problem mit TWI"
Mit leichten Modifikationen sollte es auch für den Beschleunigungssensor
funktionieren.
BOOT: Reboot Memory Content - ich sag einfach mal nö: 0
FIFO_EN: First In First Out - naja, zum Testen erstmal deaktiviert: 0
--: Keine Ahnung, was ich hier machen soll. Wird hier einfach irgendwas
übertragen? Ich kann ja nicht mitten im Code ne Lücke lassen :D
LIR_INT1: Latch interrupt request, da ich nichts mit den Interrupts
mache: 0
D4D_INT1: 4D enable: 4D detection is enabled on INT1 pin when 6D bit on
INT1_CFG (30h) is set to 1.
Gute Frage. Hier gibts also nichts zu schreiben??
LIR_INT2, D$D_INT2: wie bei INT1
I2_CLICK, I2_IA1, I2_IA2, I2_BOOT: Da ich den Int nicht nutze: 0
--: Keine Ahnung, was hier zu machen ist.
INT_Polarity: irrelevant, da die INTs nicht genutzt werden.
-: gute Frage...
1
0 0 0 0 0 ? 0 ?
1
REFERENCE (26h)
2
Ref7 Ref6 Ref5 Ref4 Ref3 Ref2 Ref1 Ref0
Reference value for interrupt generation, default (da ich keine
Interrupts nutze): 0
1
0 0 0 0 0 0 0 0
Und dann noch für INT1 und INT2 jeweils THS, DUR, CFG
1
INT1_THS (32h)
2
INT2_THS (36h)
3
0 THS6 THS5 THS4 THS3 THS2 THS1 THS0
Da ich keinen Interrupt nutze: 0
1
0 0 0 0 0 0 0 0
1
INT1_DURATION (33h)
2
INT2_DURATION (37h)
3
0 D6 D5 D4 D3 D2 D1 D0
1
0 0 0 0 0 0 0 0
1
INT1_CFG (30h)
2
INT2_CFG (34h)
3
AOI 6D ZHIE/ ZLIE YHIE YLIE XHIE XLIE
1
0 0 0 0 0 0 0 0
Warum danach laut App-Note mochmal "Write CTRL_REG5" ausgeführt werden
soll, ist mir schleierhaft.
Was mit bis hier erstmal unklar ist:
CTRL_REG2: HPCF1/2: Hierzu konnte ich nichts weiter im Datenblatt
finden.
Da der HighPassCutFrequency-Filter aber deaktiviert ist, sollte das
erstmal keine Rolle spielen.
CTRL_REG5: Was mach ich bei -- ? Kann ich hier irgend einen Wert nehmen?
Und wenn ich das richtig verstehe, ist D4D_INT1 eher ein Wert, der sich
aus dem Betriebsmodus ergibt, der also nicht geschrieben werden kann. Da
ich das Register aber beschreiben muss...ist das etwas verwirend.
CTRL_REG6: Wieder zwei nicht angegebene Werte.
Wenn ich nun die offenen Werte geklärt habe und diese Resigter alle
schreibe, müsste ich dann hoffentlich endlich Sensordaten auslesen
können.
Micha W. schrieb:> FIFO_EN: First In First Out - naja, zum Testen erstmal deaktiviert: 0
Aus welchen Registern liest du dann die Daten aus und auf welche Art und
Weise werden sie dann übertragen (also was passiert z.B. mit den
Maximalwerten)?
Ich vermute, dass die Werte aus den Registern
OUT_X_L 28h
OUT_X_H 29h
OUT_Y_L 2Ah
OUT_Y_H 2Bh
OUT_Z_L 2Ch
OUT_Z_H 2Dh
ausgelesen werden. Leider steht im Datenblatt unter den
Registerbeschreibungen hierzu für mich wenig aufschlussreiches.
Welche Revision des Datenblatts nutzt du denn (ich hatte zuerst eine
alte rev.3 - was ich erst gemerkt hatte, als ich mit einem Freund drüber
gesprochen hatte...)?
In rev.5 steht zu OUT_X_L / OUT_X_L:
1
X-axis acceleration data. The value is expressed as two’s complement left-justified.
2
Please refer to Section 3.2.1: High-resolution, normal mode, low-power mode.
Leider bin ich noch nicht so weit, dass ich die Werte auslesen kann.
Ich habe im ST-Forum einen Post geöffnet und die oben beschriebenen
Unklarheiten hinsichtlich der CTRL_REG gestellt.
Ansonsten steht im Datenblatt:
1
NAME TYPE HEX Binary DEFAULT
2
OUT_X_L r 28 010 1000 Output
3
OUT_X_H r 29 010 1001 Output
4
OUT_Y_L r 2A 010 1010 Output
5
OUT_Y_H r 2B 010 1011 Output
6
OUT_Z_L r 2C 010 1100 Output
7
OUT_Z_H r 2D 010 1101 Output
Demnach müsstest du da die Sensordaten her bekommen.
Micha W. schrieb:> Welche Revision des Datenblatts nutzt du denn (ich hatte zuerst eine> alte rev.3 -
Danke für den Tipp!
Wenn du konkrete Zahlen hast, die in die CTRL-Register Reg1 bis 6
geschrieben werden sollen, kann ich es gerne damit testen und sagen, wie
die Out-Register reagieren.
Habe es mal mit diesen Einstellungen probiert:
CTRL_REG1 00101111
CTRL_REG2 00000000
CTRL_REG3 00000000
CTRL_REG4 00000000
CTRL_REG5 00000000
CTRL_REG6 00000000
Habe dann sporadisch einzelne Bits durchprobiert, die mir sinnvoll zu
sein schienen.
Das abgelesene Ergebnis auf den OUT-Registern war immer:
dezimal
OUT_X_L r 28 40
OUT_X_H r 29 0
OUT_Y_L r 2A 41
OUT_Y_H r 2B 0
OUT_Z_L r 2C 45
OUT_Z_H r 2D 0
Die Zahlen um die 40 rum sind wahrscheinlich der werksmäßige
Kalibrierungsoffset!?!
Kein einziger schwankender OUT-Wert beim bei ruckartiger mechanischer
Belastung.
Update:
Die Werte 40, 41 und 45 sind durch LCD-Salat entstanden.
D1l schrieb:> dezimal> OUT_X_L r 28 40> OUT_X_H r 29 0> OUT_Y_L r 2A 41> OUT_Y_H r 2B 0> OUT_Z_L r 2C 45> OUT_Z_H r 2D 0
In den OUT-Registern wird nur 0x00 als Wert ausgegeben, auch bei
Beschleunigungsvorgängen am Sensor:
OUT_X_L r 28: 0x00
OUT_X_H r 29: 0x00
OUT_Y_L r 2A: 0x00
OUT_Y_H r 2B: 0x00
OUT_Z_L r 2C: 0x00
OUT_Z_H r 2D: 0x00
Okay, ich hab grade ne Antwort von ST erhalten.
In ST AN5005 gibts weitere Infos zum HighPass-Filter (Kapitel 3.3.1).
In Kapitel 6 sollten Infos zu der D4D (CTRL_REG5)sein.
Und Bits, die nicht genutzt werden (-- in den Register-Tabellen) können
einfach mit 0 beschrieben werden ;)
Micha W. schrieb:> #define OUT_X_H 29> #define OUT_Y_L 2A
Muss jetzt nichts heissen, aber fiel mir auf:
wird da noch irgendwann ein 0x vor gesetzt?
Sonst ergeben sich sicher nicht die gewünschten Werte.
Ja, das ist mir eben auch aufgefallen. Das mit dem 0x hatte ich zuerst
nirgendwo beachtet. Habs aber inzwischen geändert (auch in dem Beitrag
oben). Danke für den Hinweis ;)
Ich würde gerne nun das Setup durchiterieren... aber mir ist nicht klar,
was ich durch das #define für einen Datentyp habe. Eigentlich wird das
ja im Präprozessor ersetzt.
Mit welchem Typ muss ich denn dann das Array bauen?
// all setup registers
??? LIS2DH12_SETUP_REGISTERS[] = {LIS2DH12_CTRL_REG1,
LIS2DH12_CTRL_REG2, ...}
// all setup register values
??? LIS2DH12_SETUP_REGISTER_VALUES[] = {LIS2DH12_CTRL_REG1_VALUE,
LIS2DH12_CTRL_REG2_VALUE, ...}
Kann ich hier einfach uint8_t nehmen?
Micha W. schrieb:> LIS2DH12_CTRL_REG1_VALUE 0x27;
Du willst also alle genannten Register auf 0x00 lassen, bis auf
CTRL_REG1 (20h) = 00100111?
Diese Einstellung hatte ich schon getestet.
In den OUT-Registern wird dann nur 0x00 als Wert ausgegeben, auch bei
Beschleunigungsvorgängen am Sensor:
OUT_X_L r 28: 0x00
OUT_X_H r 29: 0x00
OUT_Y_L r 2A: 0x00
OUT_Y_H r 2B: 0x00
OUT_Z_L r 2C: 0x00
OUT_Z_H r 2D: 0x00
Entweder, die Beschleunigungswerte werden bei dieser
Registereinstellung*) auf andere Weise ausgelesen, oder es funktioniert
so nicht und es müssen noch Bits in anderen Registern gesetzt werden.
Habe aus der Appnote irgendwas im Hinterkopf, dass der letzte Wert in
den OUT-Registern festgefroren wird, bis irgendwas passiert (FIFO
entsprechend eingestellt wird?)...
*) #define LIS2DH12_CTRL_REG1_VALUE 0x27; // 00100111 - 10Hz, enable
all axis
In der AN5005 unter 3.1.3 steht was zum BDU.
Bei niedrigen Übertragungsraten ist es sinnvoll, das Block Data Update
zu aktivieren - somit wird von allen 3 Achsen zeitgleich der Wert
gespeichert und nicht zu unterschiedlichen Zeiten die Werte der Achsen
übertragen.
Somit wird bein CTRL_REG4 nun zu
Dass ich in der Config lande, weiß ich, da NRF_LOG_INFO("Sensor Setup:
\r\n") ausgegeben wird.
Zu NRF_LOG_INFO("LIS2DH12 finished\r\n") gelange ich jedoch gar nicht.
Gibt es eine Möglichkeit, wie ich hinsichtlich des APP_TWI_WRITE eine
genaue Fehlerausgabe aktivieren kann?
Programming 1.9 KB of addresses 00000000 — 000007bf
4
Programming 103.9 KB of addresses 00001000 — 0001afdf
5
J-Link: Flash download: Flash download skipped. Flash contents already match
6
Programming 26.5 KB of addresses 0001f000 — 00025a0b
7
Programming 0.1 KB of addresses 00025a0c — 00025a87
8
Programming 0.0 KB of addresses 00025a88 — 00025a97
9
J-Link: Flash download: Flash programming performed for 1 range (27648 bytes)
10
J-Link: Flash download: Total time needed: 1.468s (Prepare: 0.121s, Compare: 0.298s, Erase: 0.566s, Program: 0.394s, Verify: 0.001s, Restore: 0.086s)
11
Stopped by vector catch
Und in der LIS2DH2_ACC_driver.h bin ich auf folgende Adressen gestoßen:
// I2C Address
#define LIS2DH12_I2C_ADDRESS_LOW 0x30 // SAD[0] = 0
#define LIS2DH12_I2C_ADDRESS_HIGH 0x32 // SAD[0] = 1
Was mit den von mir mit dem TWI-Scanner-Beispiel ausgelesenen Adressen
18 und 19 nicht übereinstimmt.
Daher gehe ich davon aus, dass ich hier mit dem Bitshifting konfrontiert
werde:
1
18: 0001 1000 (ausgelesener Wert)
2
30: 0011 0000 (Wert aus Treiber - nach links geshiftet?)
3
4
19: 0001 1001 (ausgelesener Wert)
5
31: 0011 0001 (Wert aus Treiber - nach links geshiftet?)
Die Frage wäre jetzt erstmal, welcher Adresswert nun mit der
APP_TWI_WRITE genutzt werden muss.
Micha W. schrieb:> Die Frage wäre jetzt erstmal, welcher Adresswert nun mit der> APP_TWI_WRITE genutzt werden muss.
Er will den nach rechts geshifteten Wert (= der kleinere) haben, das
RW-Bit setzt die Hardware ein.
Schau Dir mal im Reference Manual das ADDRESS Register im TWI genau
an.
Thread beobachten
Seitenaufteilung abschalten
