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
Nordic selbst empfiehlt wohl Segger-Embedded-Studio: https://www.nordicsemi.com/Software-and-tools/Development-Tools/Segger-Embedded-Studio
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)
>ich nutze mittlerweile aber GCC,
Liegt unter dem Segger-Studio nicht auch der GCC?
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.
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
>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.
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 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 ....
Ich wollte mir demnächst auch den nRF52xxx anschauen. Wie sieht es denn mit Visual Code und PlatformIO aus?
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
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.
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.
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.
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.
Das Problem lässt sich z.T. mittels "Monitor Mode Debugging" lößen https://github.com/NordicPlayground/j-link-monitoring-mode-debugging/#monitor-mode-debugging-in-keil-%C2%B5vision5-and-segger-embedded-studio
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.