Forum: Compiler & IDEs nRF52 Entwicklungsumgebung


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 Markus (Gast)


Lesenswert?

Welche Entwicklungsumgebung nimmt man am besten für eine Nordic NRF52xxx 
MCU?

Ich würde gerne debuggen können und wenig Probleme bei der Installation.

Ist die Segger-Umgebung geeignet?

: Verschoben durch Moderator
von Markus (Gast)


Lesenswert?


von Testi (Gast)


Lesenswert?

Markus schrieb:
> Ist die Segger-Umgebung geeignet?

Die Segger Umgebung funktioniert sehr gut! (ich nutze mittlerweile aber 
GCC, was aber mehr Kenntnisse mit Make, usw. braucht)

von Markus (Gast)


Lesenswert?

>ich nutze mittlerweile aber GCC,

Liegt unter dem Segger-Studio nicht auch der GCC?

von testi (Gast)


Lesenswert?

Markus schrieb:
>>ich nutze mittlerweile aber GCC,
>
> Liegt unter dem Segger-Studio nicht auch der GCC?

Doch (soweit ich weis), aber sie nutzen ihr eigenes Linker-Script Format 
und keine Makefiles sondern *.emProject

Beitrag #6581967 wurde von einem Moderator gelöscht.
von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Markus schrieb:
> Liegt unter dem Segger-Studio nicht auch der GCC?

Ja, aber auch Clang/LLVM bzw. darauf basierend seit einiger Zeit unser 
eigener Compiler.

testi schrieb:
> Doch (soweit ich weis), aber sie nutzen ihr eigenes Linker-Script Format
> und keine Makefiles sondern *.emProject

Korrekt, das kommt durch unseren eigenen Linker.

Markus schrieb:
> Ist die Segger-Umgebung geeignet?

Ja, es gibt eine Version von Nordic, die für Nordic Device kostenlos 
ist:
https://www.nordicsemi.com/Software-and-tools/Development-Tools/Segger-Embedded-Studio

von Markus (Gast)


Lesenswert?

>Ja, es gibt eine Version von Nordic, die für Nordic Device kostenlos
ist:

Mittlerweile habe ich mir Segger Studio mal installiert. Ich habe ein 
nRF52..DK Development Kit Entwicklungsboard und damit läuft der Segger 
Debugger.
Was mir sehr gut daran gefällt: Wenn man debugt, sieht man gleich den 
Assembler-Code und alle Register. Wenn ich es richtig sehe, geht das 
Debuggen mit nur 4 Leitungen seriell, was praktisch für eigene Boards 
ist.

Allerdings habe ich noch nie so lange bei einem System gebraucht, das 
Board zum Blinken zu bekommen. Ich bewerte die Qualität einer 
Entwicklungsumgebung anhand der TTB: Time To Blink oder kurz: wie lange 
braucht man bei der Inbetriebnahme eines Boards, bis die LED blinkt.

Der größte Anteil daran hat wohl Nordic selber. Das Blink-Beispiel ist 
soweit abstrahiert, dass man kaum noch die Pinzuordnung des Boards 
findet.

Das Nordic-Wiki verlinkt nicht einmal auf den Basiscode und man muss 
ewig das richtige Development Kit suchen:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.3.0%2Findex.html

In meinem Fall war das Problem, dass die Development-Boards mit z.B. 
PCA10040 durchnummeriert sind und man erst mal wissen muss, dass die 
Pin-Zuordnung unsichtbar nur mit der Auswahl der Board Nummer passend 
compiliert wird.

Da helfen dann nur noch GitHub Blink-Beispiele, in denen direkt auf die 
Peripherieadressen zugegriffen wird:
https://github.com/sAlexander/nrf52-minimal-c/blob/master/main.c

Das zweite Problem war, dass es verschiedene Nordic-SDK Versione gibt 
und in meinem Projekt die Version 14 eingestellt war, dass SDK auf der 
Platte aber 15.

In Segger-Studio konnte ich nicht heraus kriegen, wie man das dort in 
der GUI ändert und habe deshalb manuell den Text des Projekt-Files 
angepasst, weil ich nach längerer Suche in den Menues keinen anderen Weg 
gefunden habe.

Jetzt habe ich das Problem, ein Beispielprojekt von Github gezogen zu 
haben, bei dem aber nicht alle Verzeichnisse und Treiber des SDK 
eingebunden sind und ich noch nicht heraus gefunden habe, wie man in 
Segger-Studio die Dateien einbindet.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Markus schrieb:
> Ich bewerte die Qualität einer
> Entwicklungsumgebung anhand der TTB: Time To Blink

He he, finde ich gut :-).
Aber wie du schon sagtest, die Kritikpunkte sind eher durch Nordic 
verschuldet als durch Embedded Studio.

Markus schrieb:
> In Segger-Studio konnte ich nicht heraus kriegen, wie man das dort in
> der GUI ändert und habe deshalb manuell den Text des Projekt-Files
> angepasst, weil ich nach längerer Suche in den Menues keinen anderen Weg
> gefunden habe.
Ich bin mir auch nicht sicher, ob das geht. Die IDE weiß ja erst einmal 
nichts von irgendwelchen SDK Versionen. Aber wenn du sagst, du konntest 
das in der Projektdatei einstellen, dann muss es ja eine Option geben. 
Wie heißt denn die Option oder war das nur ein Define?

Markus schrieb:
> Jetzt habe ich das Problem, ein Beispielprojekt von Github gezogen zu
> haben, bei dem aber nicht alle Verzeichnisse und Treiber des SDK
> eingebunden sind und ich noch nicht heraus gefunden habe, wie man in
> Segger-Studio die Dateien einbindet.
Sind das nicht einfach C Dateien oder Libraries, die du zu dem Projekt 
per Drag&Drop hinzufügen kannst? Evtl. musst du noch Include Pfade 
setzen.

von chris_ (Gast)


Lesenswert?

von Til S. (Firma: SEGGER) (til_s)
15.02.2021 08:28
>He he, finde ich gut :-).
>Aber wie du schon sagtest, die Kritikpunkte sind eher durch Nordic
>verschuldet als durch Embedded Studio.

Ja, Nordic scheint auf seiner Webseite nicht aktuell zu sein, das läuft 
wohl ein wenig auseinander.

Ich muss euch jetzt mal wirklich loben: Ich habe Segger Studio nämlich 
jetzt auch auf Ubuntu installiert und das ging wirklich einwandfrei.
Selbst die udev-Rules wurden anstandslos so gesetzt, dass der Debugger 
auf dem nRF-Board ohne Probleme ansprechbar war.
Man findet es wirklich selten, dass eine Mikrocontrollerumgebung so 
reibungslos auf Linux läuft.

>Sind das nicht einfach C Dateien oder Libraries, die du zu dem Projekt
>per Drag&Drop hinzufügen kannst? Evtl. musst du noch Include Pfade
>setzen

Drag&Drop? ... dass es so einfach geht, auf die Idee bin ich noch nicht 
gekommen ... ich werde es probieren ....

von Martin (Gast)


Lesenswert?

Ich wollte mir demnächst auch den nRF52xxx anschauen. Wie sieht es denn 
mit Visual Code und PlatformIO aus?

von nRF52 Coder (Gast)


Lesenswert?

Hallo,

Das nRF Connect SDK basiert ja auf zephyr. Ich hab da aktuell nur an der 
oberfläche gekratzt. Aber das ding scheint mächtig zu sein (West / 
devicetree / ... ). Das Blinky beispiel versteckt sich im Zephyr und 
nicht bei nrf und läuft mit gleichem c-code auf vermutlich allen der 200 
demobards mit mindestens einer LED die Zephyr unterstützt.

Zum EmbeddedStudio:
Ich bin noch nicht richtig warm geworden damit. Aktuell gibt es ein paar 
punkte die mich extremst stören:
1. keine einfache möglichkeit h-Files zu bearbeiten bei einem C-Make 
Projekt. Aktuell find ich die nur über die Dependencies, ... nur da 
sieht man den Wald vor lauter Bäumen nicht.
2. Breakpoints: Ich hab es immer wieder, das ich Breakpoints nicht 
setzen kann bzw vorher gesetzte Breakpoints ignoriert werden. Lösung ist 
alle breakpoints raus, neu übersetzen und debugging erneut starten.
- Debuggen
- Breakpoints setzten (bis hir alles OK)
- Debugger beenden
- Datei mit den breakpints bearbeiten
- Neu übersetzen
- erneut debuggen
- mögliche Haltepunkte in der bearbeiteten datei werden nicht angezeigt.
3. Code vervollständigung ist für mich als e-clips user extrem 
ungewohnt.
- Ansprechzeit für mich viel zu schnell. Und das kann nerfig werden. 
(nur weil ich eine buchstaben korrigiere muss das vorschlgasfenster 
nicht gleich aufgehen. Up down tasten sind dann erstmal blokiert. raus 
mit esc, erst dann gehts weiter ... )

Gruss

von Jim M. (turboj)


Lesenswert?

nRF52 Coder schrieb:
> 2. Breakpoints:

Breakpoints kann man bei NRF52x vergessen sobald Bluetooth läuft. Denn 
man muss nach dem Anhalten immer das Programm neu starten (Reset).

Ursache: BT LE ist zeitkritisch.

von nRF52 Coder (Gast)


Lesenswert?

zu 2. Das sobald BLE läut Breakpoint nur genau einmal funktioniert ist 
mir mitlerweile auch klar geworden. Da läuft vermutlich ein Watchdog im 
Hintergrund der dann das System resettet. Hat mich auch schon tirisch 
angenerft, ... aber dazu sind Watchdogs ja da, ...

Hat aber nichts mit dem von mir beschriebenen SES Problem der nicht mehr 
funktionierenden Breakpoints zu tun. In dem zustand hab ich keine 
kleinen dreiecke mehr in der Datei. Auch die vorher gesetzten Breakpints 
sind durchgestrichen. obwohl sie vorher funktioniert haben, ...

ggf könnte man den Watchdog nach der BLE initallisierung wieder 
deaktivieren, ... ggf steht da auch irgendwo im nrf forum was dazu, ... 
Welche HW einheit das ist sollte ja bekannt sein.

von Schorschi (Gast)


Lesenswert?

Das wird nicht klappen. Die nRF52 haben nur EIN core, welcher den 
zeitkritischen BLE-Stack (SoftDevice) aber auch die Applikation 
abarbeiten muss. Wenn du den core anhältst, hälst du automatisch auch 
das Handling des BLE ab, was die Kommunikation mit ziemlicher Sicherheit 
abstürzen lässt.

von Jim M. (turboj)


Lesenswert?

nRF52 Coder schrieb:
> ggf könnte man den Watchdog nach der BLE initallisierung wieder
> deaktivieren,

Nicht wirklich.

Das Zephyr Zeuchs habe ich hier noch nicht ernsthaft benutzt, beim 
klassischen SDK mit SoftDevice bekommt man immer einen Fault 
(app_error_fault IIRC) wenn wegen Interrupts oder Breakpoint das Radio 
Timing schief ging.

Ich empfehler daher lieber printf()-style Debugging mit Segger RTT zu 
benutzen. Allerdings ist auch dessen Puffer begrenzt, man sollte also 
nicht zuviel gleichzeitig loggen.

Mitunter fängt hier der GDB Server (Jlink GDB Server) aus heiterem 
Himmal an zu spinnen, dann muss man den einfach nur neu starten. Ich 
habe den hier im Startmenü als Kachel hinterlegt.

von fritz (Gast)


Lesenswert?


von nRF52 Coder (Gast)


Lesenswert?

Hallo,

Danke für die ganzen Iden und Hinweise.

Das der BT Stack dannach krasht, damit könnte ich je leben, ... wenn man 
zumindest danach noch etwas im eigenen code debuggen könnte.

MMD von Segger muss ich mir mal anschauen, so wie es aber aussieht gilt 
das nur fürs Softdevice. Die frage ist wie viel vom BLE Stack vom Noric 
Connect SDK im IRQ context läuft und wie viel im OS Context. Aber ggf 
für andere sachen interresant.

Hab grad gesehen das Zephyr einen GDB Server als module anbietet, mal 
schauen was der kann.

von Adib (Gast)


Lesenswert?

Ich hatte beim spielen mit der Segger IDE nicht gefunden, wie man die 
SDK include mit einer Umgebungsvariable macht.
Da wird immer ein absoluter Pfad benötigt.
Das macht das Wechseln der SDKs oder das sharen des Projekts mit 
verschiedenen Programmieren und verschiedenen Vorlieben für den SDK Pfad 
"schwierig".

Hat sich das geändert?

Danke und Grüße, Adib.

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.

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