Include für RP2040

Danke, habe ich gemacht.
Es sind viele kleine .h Dateien und nicht eine einzige große. Mal sehen, 
wie sich damit arbeiten läßt.

>Was ich an Beispielen finde, läuft alles auf Arduino-Ebene. Damit kann
>ich nichts anfangen.

Warum nicht? Du solltest lernen, damit umzugehen.
Man kann das System mit VS-Code aufsetzten und mit GDB debuggen. Es sind 
also alle Möglichkeiten vorhanden und zusätzlich gibt es die Möglichkeit 
zur Verwendung 1000er Arduino Bibliotheken.

Oliver S. schrieb:
> Man könnte aber, wie auch schon für pico vorgeschlagen wurde, sich die
> Arduino-Sourcen anschauen. Da sollte ja auch alles gewünschte zu finden
> sein.

In den Quellen vom SDK findet sich zwar alles wieder, aber Dateien 
gleichen Namens in anderen Verzeichnissen haben ganz anderen Inhalt. 
Sehr unübersichtlich und verwirrend. Auch findet sich Quellcode in 
.h-Dateien.

Vielleicht ist es sinnvoll, die vielen kleinen Schnipsel in eine große 
Datei zu kopieren, die dann alles im direkten Zusammenhang enthält. In 
der Segger IDE wäre das sicher transparenter.

RP2040 Anfänger schrieb im Beitrag #6865487:

> In den Quellen vom SDK findet sich zwar alles wieder, aber Dateien
> gleichen Namens in anderen Verzeichnissen haben ganz anderen Inhalt.

Ja, klar. Ein Zweig ist für die Basisadressen der Peripherie-Units und 
die Bitdefinitionen zuständig, der andere für die Offsets der Register, 
bezogen auf die Basisadressen, dargestellt als Struktur-Deklarationen.

Sowas macht immer dann Sinn, wenn es mehr als eine Unit gleicher Art 
gibt (oder zumindest geben könnte). Und von vielen Units gibt es ja 
tatsächlich mehr als nur eine.

> Sehr unübersichtlich und verwirrend. Auch findet sich Quellcode in
> .h-Dateien.

So what? Was anderes als Quelltext sollte denn deiner Meinung nach in 
*.h-Dateien stehen?

Wichtig ist doch nur, dass nur Quelltext mit rein deklarativem Charakter 
sein sollte. Und das ist der Fall (es sei denn, ich hätte was 
übersehen).

Til S. schrieb:
>> Für C-Programmierung suche ich zum RP2040 die Include Datei mit den
>> Registerdefinitionen. Wo kann ich die finden?
>
> Alternativ könntest du dir die benötigten SFRs selber definieren.

Du hättest es eigentlich besser wissen können.
Die .h Dateien sind in der hinterletzten Ecke versteckt. Bei mir zum 
Beispiel:
C:\Users\XYZ\AppData\Local\SEGGER\SEGGER Embedded 
Studio\v3\packages\RP2040_Pico_BSP\pico-sdk\src\rp2040\hardware_structs\ 
include\hardware\structs
oder
C:\Users\XYZ\AppData\Local\SEGGER\SEGGER Embedded 
Studio\v3\packages\RP2040_Pico_BSP\pico-sdk\src\rp2040\hardware_regs\inc 
lude\hardware\regs

Danach kann man sich ja dumm und dämlich suchen :-(

Oliver S. schrieb:
> Dafür hat man einen Editor oder eine IDE. Das darf nicht mehr als einen
> Tastendruck brauchen.

Dann zeigt mir mal den Tastendruck.
Ich würde erwarten, dass, wenn ich ein Projekt für den RP2040 anlege, 
der passende #include-Pfad gelegt wird. Ist nicht.

Und wenn ein Segger Mitarbeiter empfiehlt, seine eigenen .h/.xyz-Dateien 
anzulegen, scheint die Lösung nicht offensichtlich zu sein.

Aber gut, für einen Arduinofan muss sich sowieso alles mit einem 
Tastendruck zusammenklicken zu lassen.

Für Schnellklicker mal ein Beispiel, wie die Dateien "gpio.c" im 
RasPi-SDK und bei Segger aussehen.

Es ist Glückssache, ob man den Müll oder den Eimer erwischt.

>von Oliver S. (oliverso)
>01.11.2021 09:57

>Markus schrieb:
>> Warum nicht? Du solltest lernen, damit umzugehen.

>Wenn man schon laufen kann, warum soll man sich dann ans krabbeln
>gewöhnen?

Der Spruch muss anders heißen: Besser gut gefahren als schlecht 
gelaufen.

Entwickler mit viel Erfahrung wissen, dass man mit großen 
Softwareframeworks  die Ziele schneller erreichen kann als als 
Fußgänger.

>Man könnte aber, wie auch schon für pico vorgeschlagen wurde, sich die
>Arduino-Sourcen anschauen. Da sollte ja auch alles gewünschte zu finden
>sein.

So ist es. Und es macht mehr Sinn, bestehende Umgebungen zu erweitern 
als inkompatible Dinge selbst zu entwickeln.

Der Standard für die Header wird für die meisten Cortex bei ARM in der 
CMSIS gepflegt, nur bei RPi musste man erstmal seine eigene Wurst haben:

https://github.com/raspberrypi/pico-sdk/issues/21

https://github.com/raspberrypi/pico-sdk/pull/384

Da saß wohl erstmal ein Praktikant dran der zum ersten Mal einen CM0 in 
der Hand hatte.

aber auch die genannten haben sich beim Core auf CMSIS geeinigt, obwohl 
die alle gerne eigene Standards durchdrücken wollen.
Bei der Peripherie gibts ja genug Freiheit, die sorgt dann schon noch 
genug für Wettbewerb. Und die weite Verbreitung von z.B. STMs Tools und 
Offenheit zeigt doch wie gut das angenommen wird. Das Lock In hat man 
schon dadurch das keine Prozessoren Herstellerübergreifend gleich sind.

Gefunden habe ich letztlich dies hier
https://gitlab.com/khockuba/cmsis-pi-pico/-/blob/master/CMSIS/Device/Raspberry/RP2XXX/Include/RP2040.h