Forum: Mikrocontroller und Digitale Elektronik nRF51 TWI-Sensor auslesen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von damichl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Um ehrlich zu sein habe ich darüber keine Info gefunden. Ich hab eben 
mal den Support von VisualGDB angeschrieben, vielleicht können dir mir 
sagen, wo ich Infos darüber finde.

VisualGDB stellt mit VisualStudio eine alternative Entwicklungsumgebung 
dar. Ich hab mal ein paar Screenshots zu den möglichen Einstellungen 
gemacht:

http://www.digitalinventions.de/pics/visualgdb/screenshot_01.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_02.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_03.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_04.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_05.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_06.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_07.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_08.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_09.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_10.jpg
http://www.digitalinventions.de/pics/visualgdb/screenshot_11.jpg

Vielleicht habe ich etwas übersehen.
Da der Weg über VisualGDB nicht das Gängigste ist, gibt das vielleicht 
auch den nötigen Einblick in meine Toolchain.



//Edit: Beim Erstellen der Screenshots ist mir grade aufgefallen, dass 
da ne Option "Load image into memory" aktiviert ist. Das erklärt 
vielleicht, warum mein Code nur mit aktiviertem VS läuft :D

: Bearbeitet durch User
von Jim M. (turboj)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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

von damichl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von damichl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schau mal in den jew. /arm5_no_packs Ordner, da liegt das Projekt für 
Keil µVision5 (.uvprojx).

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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 
:/

: Bearbeitet durch User
von damichl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Würde es Sinn machen das nRF51 Developement Toolkit 
http://www.mouser.de/ProductDetail/Nordic-Semiconductor/nRF51-DK/?qs=4PbAv7ewtYzcFV5T1iMmMg== 
zu kaufen?
Soweit ich weiß, ist da ein Segger jLink verbaut.

Im Datenblatt steht, dass ich den Debug-Out nutzen kann, um externe 3V 
Boards zu debuggen. Meine Platine läuft auf 3,3V. Stellt das ein Problem 
dar?

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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...

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,
2x5 auf Kabel kann ich auch nicht finden.
Scheint es als Buchse nur in SMD zu geben.
Was hat der Hersteller des DK dafür vorgesehen?

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das wüsste, hätte ich es schon irgendwo gefunden und bestellt.

Das Board ist dieses hier:
http://www.mouser.de/ProductDetail/Nordic-Semiconductor/nRF51-DK/?qs=sGAEpiMZZMvQbgrkdfEa0llNT2KXyRh4IfnQqjiSV9g%3d

Nordic PCA10028

Ich habe bisher auch noch nicht das Pinout gefunden. Im schlimmsten Fall 
löte ich mir selbst nen Adapter fix an die Pins ran, wenn es irgendwie 
vermeidbar ist, würde ich das jedoch gerne lassen.. Steckverbindungen 
sind was tolles ;)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Als was hat sich das Board vorher gemeldet?
War es "embed" und ist jetzt "bootload"?

http://learn.linksprite.com/project/get-started-with-nordic-nrf51-dk-with-mbed/

Soll ja "mbed enabled" sein.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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?

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wird wohl ein J-Link Treiber fehlen.

von Micha W. (cysign)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke nicht, dass da ein Treiber fehlt - aber letztendlich weiß ich 
es nicht. Ich hab mal einen Screenshot vom Gerätemanager angehangen.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Ah, sehr schön. Kaum hab ich den Treiber gewechselt, hat uVision n 
Firmwareupdate am Segger durchgeführt ;)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Musst Du.
Bei uVision muss ich passen.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

: Bearbeitet durch User
von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Da hatte ich tatsächlich schon reingeschaut - in ein paar andere Folgen 
;)
Aber vielleich thilft mir das ja endlich mit dem nRF loszulegen.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ist zwar für Linux beschrieben, aber die Programme gibt es auch für Win.
Und dem nRF Quellcode ist das egal :-)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Problem?
Steht doch eigentlich alles für Win drin.

Dann bist Du doch sicher auf:
http://gnuarmeclipse.github.io/windows-build-tools/

gelandet, oder?

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
von hp-freund (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst auch die zip laden und manuell in eclipse installieren:

https://sourceforge.net/projects/gnuarmeclipse/files/Eclipse/updates/

Natürlich den gcc für ARM nicht vergessen:

https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update/+download/gcc-arm-none-eabi-5_4-2016q3-20160926-win32.exe

Hab das mal unter Win7 probiert, sieht gut aus, obwohl ich kein J-Link 
habe.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

: Bearbeitet durch User
von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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...

von damichl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Micha W. schrieb:
> Hmmm....hat denn jemand von euch schonmal unter Windoofs die Gnu ARM
> Eclipse-Geschichte genutzt?

Nein.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Irgendwie komme ich nicht weiter was den lis2dh12 anbelangt.

Ich hab mir einige Beispiele des SDK mit anderen Sensoren angeschaut.
ST AN5005 
(http://www.st.com/resource/en/application_note/dm00365457.pdf):
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:
4
1. Write CTRL_REG1
5
2. Write CTRL_REG2
6
3. Write CTRL_REG3
7
4. Write CTRL_REG4
8
5. Write CTRL_REG5
9
6. Write CTRL_REG6
10
7. Write REFERENCE
11
8. Write INTx_THS
12
9. Write INTx_DUR
13
10. Write INTx_CFG
14
11. Write CTRL_REG5


Ich weiß einfach nicht, wie ich an die Sensordaten rankomme.

Laut 
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v10.0.0%2Fgroup__app__twi.html 
:
1
#define   APP_TWI_READ(address, p_data, length, flags)   APP_TWI_TRANSFER(APP_TWI_READ_OP(address), p_data, length, flags)
2
   Macro for creating a read transfer. More...
1
  
2
#define   APP_TWI_WRITE(address, p_data, length, flags)   APP_TWI_TRANSFER(APP_TWI_WRITE_OP(address), p_data, length, flags)
3
   Macro for creating a write transfer.

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.

: Bearbeitet durch User
von hp-freund (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Wow, danke!
Super Hinweis ;)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ehrlich?

Du hättest dir zum Anfang einen einfacheren Sensor aussuchen sollen...

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Ja, das stimmt wohl. Hinterher ist man immer schlauer ;)
Aber jetzt heißt es Zähne zusammenbeißen und durch...

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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:
4
1. Write CTRL_REG1
5
2. Write CTRL_REG2
6
3. Write CTRL_REG3
7
4. Write CTRL_REG4
8
5. Write CTRL_REG5
9
6. Write CTRL_REG6
10
7. Write REFERENCE
11
8. Write INTx_THS
12
9. Write INTx_DUR
13
10. Write INTx_CFG
14
11. Write CTRL_REG5

Unter 
https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v8.x.x/doc/8.1.0/s110/html/a00967.html#ga3e733713f6fa09a0a490620c5ab94544 
ansehe, werden beim nrf_drv_twi_tx()
gibts ne kurze Beschreibung des TWI-Treibers.



Laut Datenblatt des LIS2DH12 
(http://www.st.com/content/ccc/resource/technical/document/datasheet/12/c0/5c/36/b9/58/46/f2/DM00091513.pdf/files/DM00091513.pdf/jcr:content/translations/en.DM00091513.pdf 
ab Seite 34)

1
CTRL_REG1 (20h)
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.



1
CTRL_REG3 (22h)
2
I1_CLICK I1_IA1 I1_IA2 I1_ZYXDA 0 I1_WTM I1_OVERRUN
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

1
0 0 0 0 0 0 0 0

von D1l (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
1
CTRL_REG5 (24h)
2
BOOT FIFO_EN -- -- LIR_INT1 D4D_INT1 LIR_INT2 D4D_INT2

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
1
0 0 ? ? 0 ? 0 ?






1
CTRL_REG6 (25h)
2
I2_CLICK I2_IA1 I2_IA2 I2_BOOT I2_ACT -- INT_POLARITY -

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.

: Bearbeitet durch User
von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

von D1l (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von D1l (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von D1l (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von D1l (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von D1l (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Appnote habe ich heute morgen auch bekommen, da gehen einem gleich 
Lichter auf :-)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Hast du denn inzwischen Sensorwerte abrufen können?

Meine Register-Map sieht nun wie folgt aus:
1
// setup registers
2
#define LIS2DH12_CTRL_REG1        0x20
3
#define LIS2DH12_CTRL_REG2        0x21
4
#define LIS2DH12_CTRL_REG3        0x22
5
#define LIS2DH12_CTRL_REG4        0x23
6
#define LIS2DH12_CTRL_REG5        0x24
7
#define LIS2DH12_CTRL_REG6        0x25
8
#define LIS2DH12_REFERENCE_REG    0x26
9
#define LIS2DH12_INT1_THS         0x32
10
#define LIS2DH12_INT1_DURATION    0x33
11
#define LIS2DH12_INT1_CFG         0x30
12
#define LIS2DH12_INT2_THS         0x36
13
#define LIS2DH12_INT2_DURATION    0x37
14
#define LIS2DH12_INT2_CFG         0x34
15
16
// setup register values
17
#define LIS2DH12_CTRL_REG1_VALUE 0x27;  // 00100111 - 10Hz, enable all axis
18
#define LIS2DH12_CTRL_REG2_VALUE 0x00;  // 00000000 - high-pass-filter disabled
19
#define LIS2DH12_CTRL_REG3_VALUE 0x00;  // 00000000 - disabled interrupts
20
#define LIS2DH12_CTRL_REG4_VALUE 0x00;  // 00000000 - blockdad / bil-little-endian / full scale selection / high resolution / self-test: disabled
21
#define LIS2DH12_CTRL_REG5_VALUE 0x00;      // 00000000 - boot memory content / FIFO / INT1/2 / 4D orientation mode: disabled
22
#define LIS2DH12_CTRL_REG6_VALUE 0x00;  // 00000000 - click-feature / INT1/2: disabled
23
#define LIS2DH12_REFERENCE_REG_VALUE 0x00; // 00000000 - data overrun settings / new data flags
24
#define LIS2DH12_INT1_THS_VALUE 0x00;  // 00000000 - threshold settings
25
#define LIS2DH12_INT1_DURATION_VALUE 0x00; // 00000000 - duration for interrupt event
26
#define LIS2DH12_INT1_CFG_VALUE 0x00;  // 00000000 - INT config
27
#define lis2dh12_INT2_THS 0x00;  // 00000000 -  - threshold settings
28
#define lis2dh12_INT2_DUR 0x00;  // 00000000 -  - duration for interrupt event
29
#define lis2dh12_INT2_CFG 0x00;  // 00000000 - INT config
30
31
// x/y/z data registers
32
#define OUT_X_L 0x28
33
#define OUT_X_H 0x29
34
#define OUT_Y_L 0x2A
35
#define OUT_Y_H 0x2B
36
#define OUT_Z_L 0x2C
37
#define OUT_Z_H 0x2D

: Bearbeitet durch User
von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

: Bearbeitet durch User
von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ah, editiert :)

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Micha W. schrieb:
> was ich durch das #define für einen Datentyp habe

es wird nur der Text ersetzt, hat also keinen Datentyp.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von D1l (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
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
1
#define LIS2DH12_CTRL_REG4_VALUE 0x80  // BDU enabled

Hattest du inzwischen Erfolg?

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Hast du denn auch das Status-Register abgefragt?
1
The device is provided with a STATUS_REG which should be polled to check when a new set 
2
of data is available. The reading procedure should be the following:
3
4
1. Read STATUS_REG
5
2. If STATUS_REG(3) = 0, then go to 1
6
3. If STATUS_REG(7) = 1, then some data have been overwritten
7
4. Read OUTX_L
8
5. Read OUTX_H
9
6. Read OUTY_L
10
7. Read OUTY_H
11
8. Read OUTZ_L
12
9. Read OUTZ_H
13
10. Data processing
14
11. Go to 1

Ich könnte mir vorstellen, dass der LIS2DH12 erst Daten liefert, sobald 
das Statusregister abgefragt wird...

: Bearbeitet durch User
von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Ich stolper noch immer am APP_TWI_WRITE.

In der main.c werden folgende Funktionen aufgerufen:
twi_config();
twi_sensor_setup();


1
void twi_config(void)
2
{
3
4
    uint32_t err_code;
5
6
    nrf_drv_twi_config_t const config = {
7
       .scl                = TWI_PIN_SCL,
8
       .sda                = TWI_PIN_SDA,
9
       .frequency          = NRF_TWI_FREQ_100K,
10
       .interrupt_priority = APP_IRQ_PRIORITY_LOWEST,
11
       .clear_bus_init     = false
12
    };
13
14
    APP_TWI_INIT(&m_app_twi, &config, MAX_PENDING_TRANSACTIONS, err_code);
15
    APP_ERROR_CHECK(err_code);
16
    NRF_LOG_INFO("TWI Enabled.\r\n");
17
    NRF_LOG_FLUSH();
18
}

1
void twi_sensor_setup()
2
{
3
    NRF_LOG_INFO("Sensor Setup: \r\n");
4
    NRF_LOG_FLUSH();
5
    APP_ERROR_CHECK(app_twi_perform(&m_app_twi, alpha_init, 13, NULL));
6
    NRF_LOG_INFO("LIS2DH12 finished\r\n");
7
    NRF_LOG_FLUSH();
8
}
1
const app_twi_transfer_t alpha_init[13] =
2
{    
3
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[0], sizeof(REGISTER_SETUP[0]), 0),
4
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[1], sizeof(REGISTER_SETUP[1]), 0),
5
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[2], sizeof(REGISTER_SETUP[2]), 0),
6
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[3], sizeof(REGISTER_SETUP[3]), 0),
7
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[4], sizeof(REGISTER_SETUP[4]), 0),
8
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[5], sizeof(REGISTER_SETUP[5]), 0),
9
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[6], sizeof(REGISTER_SETUP[6]), 0),
10
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[7], sizeof(REGISTER_SETUP[7]), 0),
11
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[8], sizeof(REGISTER_SETUP[8]), 0),
12
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[9], sizeof(REGISTER_SETUP[9]), 0),
13
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[10], sizeof(REGISTER_SETUP[10]), 0),
14
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[11], sizeof(REGISTER_SETUP[11]), 0),
15
    APP_TWI_WRITE(SENSOR_ALPHA_ADDRESS, REGISTER_SETUP[12], sizeof(REGISTER_SETUP[12]), 0)
16
};
1
const uint8_t REGISTER_SETUP[13][2] = {
2
          {LIS2DH12_CTRL_REG1, LIS2DH12_CTRL_REG1_VALUE},
3
          {LIS2DH12_CTRL_REG2, LIS2DH12_CTRL_REG2_VALUE},
4
          {LIS2DH12_CTRL_REG3, LIS2DH12_CTRL_REG3_VALUE},
5
          {LIS2DH12_CTRL_REG4, LIS2DH12_CTRL_REG4_VALUE},
6
          {LIS2DH12_CTRL_REG5, LIS2DH12_CTRL_REG5_VALUE},
7
          {LIS2DH12_CTRL_REG6, LIS2DH12_CTRL_REG6_VALUE},
8
          {LIS2DH12_REFERENCE_REG,LIS2DH12_REFERENCE_REG_VALUE},
9
          {LIS2DH12_INT1_THS,LIS2DH12_INT1_THS_VALUE},
10
          {LIS2DH12_INT1_DURATION,LIS2DH12_INT1_DURATION_VALUE},
11
          {LIS2DH12_INT1_CFG,LIS2DH12_INT1_CFG_VALUE},
12
          {LIS2DH12_INT2_THS,LIS2DH12_INT2_THS_VALUE},
13
          {LIS2DH12_INT2_DURATION,LIS2DH12_INT2_DURATION_VALUE},
14
          {LIS2DH12_INT2_CFG,LIS2DH12_INT2_CFG_VALUE},
15
};


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?

: Bearbeitet durch User
von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Segger Embedded Studio wirft noch mit Folgendem um sich:
1
Preparing target for download
2
Executing script TargetInterface.resetAndStop(1000)
3
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.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Micha W. (cysign)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info.
Meinst du hinsichtlich des Nordic SDK, des nRF51 oder des Sensors?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.