Kann jemand vielleicht Erfahrungen teilen zu dem RP2040 Chip. Der scheint ja sehr verfügbar und günstig zu sein. Insbesondere interessiert mich wie schnell man eine Toolchain aufgesetzt hat und wie leicht man da einsteigt. Könnte man einen vorhandenen ST-Link Programmer benutzen?
:
Wiederhergestellt durch Admin
Nils H. schrieb: > Insbesondere interessiert > mich wie schnell man eine Toolchain aufgesetzt hat Je nach Internet-Speed, und was schon vorher installiert war, so eine Minute vielleicht? platformio-Projektdatei anlegen, "pio pkg install" und fertig. Oder halt ein paar Mausklicks im VS-Code. > und wie leicht man da > einsteigt. Kommt darauf an. Wenn du schonmal Arduino "gemacht" hast, gehts dort nahtlos weiter. Selbst "Multi-Core" kriegst du damit sofort ans laufen, einfach eine "void loop2() {...}" implementieren.
:
Wiederhergestellt durch Admin
Sorry, aber die Frage ist viel zu allgemein um die richtig beantworten zu können. Deshalb nur oberflächlich: Nils H. schrieb: > Insbesondere interessiert mich wie schnell man eine Toolchain aufgesetzt > hat So schnell wie dein Rechner die Arduino IDE oder Visual Studio Code mit PlattformIO installiert hat. Nils H. schrieb: > und wie leicht man da einsteigt Gewünschte Programmiersprache? Was kannst du? Für mich wären es 5 Minuten. Möchtest du die fertige HAL und Arduino Libs benutzen oder komplett neu aufsetzen und alles selbst schreiben? Nils H. schrieb: > Könnte man einen vorhandenen ST-Link Programmer benutzen? Ich würde auf jedenfall einen externen Debugger verwenden. Die Geschichte mit dem Bootloader und dem vergessenen Reset Button ist pain in the ass! Beim Segger kommt es scheinbar auf den HW Stand an, die alten können kein Dual-Core. Zum ST Link kann ich nichts sagen.
:
Wiederhergestellt durch Admin
> Kann jemand vielleicht Erfahrungen teilen zu dem RP2040 Chip. Ist gibt dazu bereits 1-2 andere Threads. > Insbesondere interessiert mich wie schnell man eine Toolchain aufgesetzt > hat und wie leicht man da einsteigt. Kommt drauf ob du Cmake magst oder nicht und ob du so ein Arduinoabschreiber bist oder unter Toolchain was eigenes verstehst. Die vom Hersteller mitgelieferten Libaries und includes sind ein echter Schmerz im Arsch. Aber bilde dir da ruhig deine eigene Meinung. .-) > Könnte man einen vorhandenen ST-Link Programmer benutzen? Was veranlasst dich zu glauben das dies gehen koennte? Sind doch zwei unabhaengige Firmen. Du kannst einen JLink verwenden wenn die Hardware nicht zu alt ist weil der RP2040 wegen dualcore irgendwie speziell ist und das Segger nicht in alte Hardware einbauen konnte. Ansonsten kannst du natuerlich jedesmal deine Bins ueber USB auf die Kiste kippen, aber das nervt einem natuerlich spaetestens nach dem dritten mal. Abgesehen davon das ernsthafte Entwicklung ohne Debugger eh nicht moeglich ist. Olaf
:
Wiederhergestellt durch Admin
Εrnst B. schrieb: > platformio-Projektdatei anlegen, "pio pkg install" und fertig. Das tippt man einfach so in den WIN10 Rechner ein? > Kommt darauf an. Wenn du schonmal Arduino "gemacht" hast, gehts dort > nahtlos weiter. > Selbst "Multi-Core" kriegst du damit sofort ans laufen, einfach eine > "void loop2() {...}" implementieren. Wenn man den Arduino-Krempel wegläßt, braucht man keinen 2. Kern ;-) Nils H. schrieb: > Könnte man einen vorhandenen ST-Link Programmer benutzen? Nein. ST-Link ist nur für STM-Controller. Jlink EDU (mini) von Segger geht dagegen schon. Wenn Du in Python programmieren möchtest: https://thonny.org/ N. M. schrieb: > Ich würde auf jedenfall einen externen Debugger verwenden. Die > Geschichte mit dem Bootloader und dem vergessenen Reset Button ist pain > in the ass! Geschickt ist es, neben den drei Pins für SWD auch noch Vcc und "Run" (für Reset) anzuschließen. Das erspart manuelles Rücksetzen.
:
Wiederhergestellt durch Admin
> Wenn man den Arduino-Krempel wegläßt, braucht man keinen 2. Kern ;-) Fuehlt sie aber schon cool an. :-p > Geschickt ist es, neben den drei Pins für SWD auch noch Vcc und "Run" > (für Reset) anzuschließen. Das erspart manuelles Rücksetzen. Ich glaube das ich auch Reset verbunden habe, rein aus alter Gewohnheit. Aber Segger nutzt per default eine andere Resetstrategie wenn man das nicht umstellt. Vcc braucht man sowieso weil Segger sonst meckert und ich vermute mal das sie die Spannung auch brauchen um ihre Treiber auf die IO-Spannung einzustellen. Olaf
:
Wiederhergestellt durch Admin
habe mir auch wegen der Verfügbarkeit einen RP2040 mitbestellt. Unter arduino einfach https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json hinzufügen, Beispiel "blinky" anschauen und los gehts. Wollte dann aber den rp2040 mit einem Raspberry Pi 400 unter Raspberry OS programmieren. Einrichtung der cmake Umgebung nach Anleitung der Raspberry Foundation gemacht und nichts funktioniert, selbst die Beispielprojekte, die man bei der Einrichtung mit herunterläd kompilieren nicht und spucken diverse Fehler aus. cmake findet sich nicht zurecht. Hatte keine Lust, die offizielle Anleitung zu debuggen. Bleibe also bei Arduino als IDE für den rp2040, der erste Eindruck ist gemischt.
:
Wiederhergestellt durch Admin
m.n. schrieb: > Das tippt man einfach so in den WIN10 Rechner ein? Wenn plattformio installiert und im Pfad ist, ja. Aber für Tastatur-Allergiker gehts auch nur mit der Maus... VSCode installieren, Platformio-Plugin installieren, dort im framework-Browser zum PiPico durchblättern, "install" klicken. Wobei man den letzten Schritt auch weglassen kann. Beim ersten Compile werden fehlende Sachen eh nachinstalliert.
:
Wiederhergestellt durch Admin
m.n. schrieb: > Das tippt man einfach so in den WIN10 Rechner ein? Bei Win gibt es einen Button :-p In PlatformIO, unter unterstützten Plattformen oder so ähnlich. Drauf klicken und er zieht sich das. Aber evtl geht das command sogar über die Konsole des VSC. Das weiß ich allerdings nicht. m.n. schrieb: > Geschickt ist es, neben den drei Pins für SWD auch noch Vcc und "Run" > (für Reset) anzuschließen. Das erspart manuelles Rücksetzen. Für den Debugger definitiv. Die Aussage bezogen auf den Reset meinerseits war, weil der USB Bootloader nur über ab/anstecken des USB Kabel funktioniert. Auch in diesem Fall würde ich mindestens einen Button auf das Board löten wo man den Reset mit bedienen kann. Dann spart man sich das an/anstecken.
:
Wiederhergestellt durch Admin
> OS programmieren. Einrichtung der cmake Umgebung nach Anleitung der > Raspberry Foundation gemacht und nichts funktioniert, selbst die > Beispielprojekte, die man bei der Einrichtung mit herunterläd Das liegt an cmake. Das ist naemlich eine hoellenueberkomplexe Umgebung wo alles perfekt zusammenpassen muss und natuerlich immer in der richtige Revision. Schau mal hier: https://github.com/dwelch67/raspberrypi-pico#readme Das ist erstmal makefile nach altem Schrott&Korn. Aber kannst du natuerlich dann auch so in Eclipse, Emacs oder sonstwas einbinden je nach Geschmack. Olaf
:
Wiederhergestellt durch Admin
>Das liegt an cmake. Das ist naemlich eine hoellenueberkomplexe Umgebung
ich weiss, cmake Anleitung liegt schon in Google Books in der
Warteschleife.
Aber bei der Raspberry Foundation, die die Entwicklungsumgebung komplett
liefert (OS, Arbeitsplattform R-PI 400 und Zielplattform Pico 2040), da
hätte ich einen besseren Start erwartet. Besonders wenn man Einsteigern
das Programmieren beibringen will.
Das dann die Fremdplatform arduino einen besseren Start hinlegt
hinterlässt bei mir einen recht faden Geschmack.
Da kann ich auch bei dem ESP32 bleiben wo ich schon mehr Erfahrung habe.
Der Umstieg bietet da keinen Vorteil außer viel Mehrarbeit für die
Einarbeitung.
:
Wiederhergestellt durch Admin
Hm, ich habe das SDK auf Ubuntu 18.04 installiert und da lief es auf Anhieb. Ist schon merkwürdig, wenn das auf dem eigenen Linux der Raspberry Foundation nicht funktioniert.
:
Wiederhergestellt durch Admin
Nils H. schrieb: > Könnte man einen vorhandenen ST-Link Programmer benutzen? Im Prinzip ja... aber: Die Original ST-Link-Firmware kannst Du nicht benutzen, da diese kein multi-drop SWD unterstützt. Du kannst Dir aber die BlackMagic Probe Firmware auf den ST-Link laden, dann funzt das: 1. Repository https://github.com/blackmagic-debug/blackmagic clonen 2. Ins Verzeichnis wechseln und Firmware bauen:
1 | make PROBE_HOST=stlink ST_BOOTLOADER=1 |
3. Firmware auf den Stick laden:
1 | stlink-tool src/blackmagic.bin |
Danach solltest Du zwei neue serielle Schnittstellen haben. Im Normalfall ist die erste davon die, die du brauchst. Also gdb starten und sowas wie
1 | target ext /dev/ttyACM0 |
in den gdb eingeben und mittels
1 | mon s |
schauen, ob der RP2040 gefunden wird. Ach ja, NRST nicht verbinden. Gruss
:
Wiederhergestellt durch Admin
> ich weiss, cmake Anleitung liegt schon in Google Books in der > Warteschleife. Das lesen einer dicken Anleitung wird nicht viel helfen. Ich will da uebrigens auch make nicht in den Himmel loben, das hat auch eine dicke Anleitung. Aber cmake hat eine Menge Abhaengigkeiten im System und zu sich selber. Es kann dir da schnell passieren das du eine falsche oder zu alte Version hast und du willst vielleicht auch nicht updaten weil du auf deinem System noch eine Menge anderer Projekte hast die du dann erstmal ueberarbeiten darfst. Diese Ueberkomplexizitaet heutiger Umgebungen sind letztlich ja der Naehrboden aus dem Arduino gewachsen ist. > hätte ich einen besseren Start erwartet. Besonders wenn man Einsteigern > das Programmieren beibringen will. Ja, das wundert mich auch. Die Umgebung des RP2040 sieht nach Informatikstudium aus. :) Besonders wenn man mal die ganzen Libaries wirklich liesst, wie verschachtelt die sind, was da fuer bizarre Abhaengigkeiten und includes drin sind. Das ist einfach nur noch absurd. Source war eigentlich mal gedacht damit Menschen den lesen konnten. Das ist da nicht mehr gegeben. > Das dann die Fremdplatform arduino einen besseren Start hinlegt > hinterlässt bei mir einen recht faden Geschmack. Das ist IMHO keine wirklich Alternative. Das ist die maximale Vereinfachung, aber man kann damit schlecht wachsen. Alleine schon das fehlen eines Debuggers ist fuer Anfaenger ein unding. Wie sollen die da effizient lernen? > Hm, ich habe das SDK auf Ubuntu 18.04 installiert und da lief es auf > Anhieb. Und ich wuerde darauf wetten das es auf meinem Centos nicht einfach so funktioniert. > Die Original ST-Link-Firmware kannst Du nicht benutzen, da diese kein > multi-drop SWD unterstützt. Das wird schon allein deshalb nicht gehen weil ST kaum ein Interesse hat Controller anderer Hersteller zu unterstuetzen. .-) Selbst von den J-Links gab es mal Versionen die nur bestimmte Hersteller unterstuetzt haben weil vermutlich im Hintergrund Kohle geflossen ist. > Du kannst Dir aber die BlackMagic Probe Interessant. Sozusagen Gehirnwaesche. :-) Olaf
Olaf schrieb: > Die > vom Hersteller mitgelieferten Libaries und includes sind ein echter > Schmerz im Arsch. Das ist leider wahr. Insbesondere sind sie "nicht gut" dafür geeignet, mit einer anderen Toolchain als der von der Foundation vorgesehenen benutzt zu werden. Insofern fährt man also ziemlich gut damit, eben diese zu verwenden. Kompliziert wird es durch das CMake-Geraffel und die fehlende GUI-Unterstützung dafür, wie man sie bei richtigen IDEs erwarten könnte. Man kommt durch das Fehlen dieses Komforts nicht darum herum, sich gleich zu Beginn auch mit diesem CMake-Kram zu beschäftigen. Allein schon dazu, ein neues Projekt aufzusetzen, braucht man das. Das sind die zwei Hauptkritikpunkte. Es fehlt ein Projekt-Template (das wäre nun wirklich ganz einfach umzusetzen gewesen) und es fehlt das automatische Einbinden der Libs durch Auftauchen entsprechender Include-Zeilen in den Quelltexten oder wenigstens eine brauchbare GUI-Unterstützung für das manuelle Einbinden. Wären diese beiden Sachen vorhanden, wäre das Pico-SDK erstmal genauso einfach zu benutzen wie Arduino, aber auf lange Sicht eben viel flexibler als Arduino. Wer also vorhat, auf Arduino-Niveau zu bleiben, der sollte Arduino verwenden. Wer potentiell mehr machen will, der sollte auf die Pico-Toolchain setzen und in Kauf nehmen, sich erstmal zumindest rudimentär mit CMake vertraut machen zu müssen.
> mit einer anderen Toolchain als der von der Foundation vorgesehenen > benutzt zu werden. Hab das von dwelch bei github abgelegte als Basis genutzt und was eigenes gemacht. Das geht super. Olaf
Beitrag #7158232 wurde von einem Moderator gelöscht.
@Olaf @c-hater Auch meine Einschätzung ist so, daß die cmake & Co Lösung für einen Anfänger sehr fragwürdig ist. Am ehesten sehe ich noch Anfängererfolge mit Python (Thonny) oder Arduino, wobei Python als Interpreter langsam ist. Arduino als eierlegende Wollmilchsau versteckt die wesentlichen Eigenschaften des RP2040; jede Neuübersetzung des Quellcodes ist zudem a....langsam. Das macht absolut keinen Spaß. Aber vielleicht ist es auch ein Bedienfehler und man muß Programmieren als Zusammenklicken von Libs sehen. Olaf schrieb: > Hab das von dwelch bei github abgelegte als Basis genutzt und was > eigenes > gemacht. Das geht super. Du meinst dies hier? https://github.com/dwelch67/raspberrypi-pico Unkommentierten Programmcode liebe ich :-( Für meinen Start hatte ich mir Demo-IDEs von Segger und IAR angesehen, wo man praktisch bei Null beginnen muß. Bin dann zunächst bei IAR geblieben, da für erste Erfahrungen die 32 KB Grenze nicht stört. Mangels Unterstützung habe ich die Bootroutinen aus anderen Quellen verwendet und die U2F-Convertierung selber geschrieben. Das ist aber auch nicht gerade anfängertypisch. Den 2. Kern hatte ich noch nie verwendet bzw. gebraucht. Tief in den Pico-SCK-Quellen findet man etwas, wie man das anstellen könnte. Eine Dokumentation zum Aktivieren des 2. Kerns habe in den Datenblättern zum RP2040 nicht gefunden. Da liegen schon 'float'- und 'double'-Routinen im Bootrom und man hätte auch noch eine zum Start des 2. Kerns dazupacken können mit Stackpointer + Startadresse als Parameter. Oder gibt es die vielleicht schon? Auch wenn ich genau wußte, was ich machen will, Dokumentation war meist spärlich oder zwischen den Zeilen zu finden. Bis man mit dem RP2040 etwas Sinnvolles anstellen kann, muß man sich zunächst einigen Frust reinziehen. Für "geheime" Anwendungen ist der RP2040 wegen seines externen Flash nicht geeignet.
Olaf schrieb: > > Du kannst einen JLink verwenden wenn die Hardware nicht zu alt ist weil > der RP2040 wegen dualcore irgendwie speziell ist und das Segger nicht in > alte Hardware einbauen konnte. Wie schon an anderer Stelle erwähnt: Das ist relativ sicher eine willkürliche Beschränkung, auch ein J-Link Hardware V8.00 kann mit dem RP2040 umgehen wenn man die Beschränkung in der J-Link Windows Software entfernt.
Dieter schrieb: > Wie schon an anderer Stelle erwähnt: Das würde ich gerne selber überprüfen. Ein Link würde weiter helfen.
m.n. schrieb: > > Das würde ich gerne selber überprüfen. Ein Link würde weiter helfen. Ich hatte das hier schon erwähnt: Beitrag "Re: RP2040 + Segger IDE Probleme" Ich habe nicht vor den Patch zu veröffentlichen aber mit etwas Erfahrung ist das in weniger als einer halben Stunde erledigt. Mir geht es darum dass es beim J-Link willkürliche Beschränkungen gibt die keine technische Beschränkung darstellen. Die technischen Beschränkungen gibt es zwar auch, die willkürliche Beschränkungen sollen vermutlich den Verkauf der J-Link Hardware fördern.
m.n. schrieb: > Den 2. Kern hatte ich noch nie verwendet bzw. gebraucht. Tief in den > Pico-SCK-Quellen findet man etwas, wie man das anstellen könnte. Eine > Dokumentation zum Aktivieren des 2. Kerns habe in den Datenblättern zum > RP2040 nicht gefunden. Naja, das ist halt eine der vielen Sachen, die nur durch Benutzung der hauseigenen Toolchain einfach wird. Und um die zu nutzen, mußt du in die SDK-Doku schauen, nicht in die des RP2040. Letzteres ist Zusatzwissen, oft sehr nützlich, aber meist nicht zwingend erforderlich, wenn man mit den SDK-Feature auskommt. Die Schritte mit der hauseigenen Toolchain sind ziemlich einfach: 1) in der CMakeLists.txt bei target_link_libraries(<projektname> <list_of_libs_to_use>) den Eintrag pico_multicore hinzufügen. 2) Im Quelltext hinzufügen #include "pico/multicore" Das war schon alles, was nötig ist, um das Multicore-API benutzen zu können. Also insbesondere natürlich: multicore_launch_core1(<address_of_core1_entry>); Schick wäre halt gewesen, wenn diese armselige IDE den Eintrag in der CMakeLists.txt automatisch erzeugen würde, sobald sie in irgendeinem Quelltext auf die Include-Zeile trifft. Oder halt wenigstens ein GUI bereitstellen würde, mit der man verfügbare Libs manuell einbinden kann. > Da liegen schon 'float'- und 'double'-Routinen im > Bootrom und man hätte auch noch eine zum Start des 2. Kerns dazupacken Passiert automagisch, wenn die Plattform halt Pico ist, sobald die Multicore-Lib eingebunden wird. > Auch wenn ich genau wußte, was ich machen will, Dokumentation war meist > spärlich oder zwischen den Zeilen zu finden. Das stimmt leider. Die Libs selber sind recht ordentlich dokumentiert, deren Einbindung und Zusammenwirken aber allenfalls lausig. Das allerdings ist bei Arduino noch viel schlimmer! Da fällt es nur nicht so auf, weil halt die IDE praktisch alles "im Hintergrund" erledigt.
> Den 2. Kern hatte ich noch nie verwendet bzw. gebraucht. Deshalb hab ich auch im anderen Thread gefragt wofuer man den verwenden sollte. Ist aber cool und sollte man haben. .-) > Tief in den Pico-SCK-Quellen findet man etwas, wie man das > anstellen könnte. Keine grosse Sache. Ich weiss warum ich ueber die Originalumgebung laestere, ich hab sie gelesen und auch teilweise importiert. Hier mal ein Beispiel das mir immer mein Oled updated:
1 | /*************************************************************************/
|
2 | /* main vom core1 */
|
3 | /*************************************************************************/
|
4 | void main_core1(void) |
5 | {
|
6 | do
|
7 | {
|
8 | |
9 | //braucht mindestens 45*4 = 180Byte Stack
|
10 | ssd1306_copyblock(); //braucht 1.3ms! |
11 | |
12 | }
|
13 | while(1); |
14 | }
|
1 | //Das hier ist der Stack des zweiten Cores in 32Bit-Worten
|
2 | #define CORE1_STACKSIZE_LEVEL 100
|
3 | __attribute__((aligned(4))) uint32_t core1_stack[CORE1_STACKSIZE_LEVEL]; |
4 | |
5 | //Das hier muss passieren bevor ein IRQ installiert wird
|
6 | core1_reset(); //Core Reseten und anhalten |
7 | //core1-main-funktion, begin des stackspeichers, stacksize in byte
|
8 | core1_start(main_core1, core1_stack, CORE1_STACKSIZE_LEVEL*4); |
Dabei sind dann core1_reset und core1_start Kopien aus der Library. Olaf
c-hater schrieb: > 2) Im Quelltext hinzufügen > #include "pico/multicore" Oops. Das müßte natürlich eigentlich heißen: > #include "pico/multicore.h" Sorry.
Olaf schrieb: > void main_core1(void) > { > do > { > > //braucht mindestens 45*4 = 180Byte Stack > ssd1306_copyblock(); //braucht 1.3ms! > } > while(1); > } Du aktualisierst also Dein Display im Millisekundentakt???
> Du aktualisierst also Dein Display im Millisekundentakt???
Das war ein Experiment! Ausserdem wird dort keineswegs jedesmal
alles upgedatet. Es wird lediglich geprueft ob eines seiner 32Segmente
dirty ist.
Der Spass den man mit so einem Dualcore hat, besteht darin
das man ernsthaft darueber nachdenken muss welcher Core wann auf
welche Daten zugreifen kann/sollte. .-)
Olaf
Olaf schrieb: >> Du aktualisierst also Dein Display im Millisekundentakt??? > > Das war ein Experiment! Ausserdem wird dort keineswegs jedesmal > alles upgedatet. Es wird lediglich geprueft ob eines seiner 32Segmente > dirty ist. Ach so. Und wie kommst Du nach dem Aufruf der Funktion da wieder raus?
Lutz schrieb: > Ach so. Und wie kommst Du nach dem Aufruf der Funktion da wieder raus? Gar nicht! Das ist die Dauerlast für die 2. CPU!
> Gar nicht! Das ist die Dauerlast für die 2. CPU!
Der Microcontroller muss ja schon irgendwas machen auch wenn
er nichts machen muss. :-D
Ich glaube auch irgendwo gelesen zu haben das er beim starten von der
Bootfirmware auch in einer Endlosschleife gehalten wird. Bin mir da
jetzt aber nicht sicher.
Olaf
Der RP2040 Mikrocontroller ist ja was tolles besonders wegen des Preises für eine Platine wie die RPiPico. Ich hab mir ein paar zugelegt und wollte umbedingt mit dem Segger IDE weil, der IDE ist schon toll, hat viele nutzliche Optionen. Aber meinem jlink (V9) unterstützt den RP2040 nicht (na ja). Ich hab mir eine jlink edu mini gekauft, dann ging alles gut, die integration mit dem SDK braucht CMake !!! Genial :(. Kürze Geschichte: Ich hab den CMake installiert, ein paar Beispiele durch gemacht und geflashed via eine uf2 Datei, no jlink. Vor kürze habe ich gedacht das das zu einfach ist, wie wäre wenn ich Ada probiere... eine schöne anleitung gibt es hier: https://pico-doc.synack.me/ für Linux, ops, ich hab hier nur Windoze. Es soll gehen... man kann doch Alire in windows installieren, nach eine Weile habe ich lubuntu auf VBox installiert und nochmals versucht, es ging, keine Toolchain Probleme mehr. Man kann mit openocd auch flashen und debuggen, habe ich es kompiliert mit alle interfaces, jlink auch. Und geht überhaupt meinem jlink V9 ? ... bestimmt nicht, oder ? Falsch !, es geht:
1 | pacito@ale-virtualbox:/usr/local/share/openocd/scripts$ sudo openocd -f interface/jlink.cfg -f target/rp2040.cfg |
2 | Open On-Chip Debugger 0.11.0-g228ede43d-dirty (2022-08-17-09:27) |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.org/doc/doxygen/bugs.html |
6 | adapter speed: 1000 kHz |
7 | |
8 | Info : Hardware thread awareness created |
9 | Info : Hardware thread awareness created |
10 | Info : RP2040 Flash Bank Command |
11 | Info : Listening on port 6666 for tcl connections |
12 | Info : Listening on port 4444 for telnet connections |
13 | Info : J-Link V9 compiled Dec 13 2019 11:14:50 |
14 | Info : Hardware version: 9.30 |
15 | Info : VTarget = 3.293 V |
16 | Info : clock speed 1000 kHz |
17 | Info : SWD DPIDR 0x0bc12477 |
18 | Info : SWD DLPIDR 0x00000001 |
19 | Info : SWD DPIDR 0x0bc12477 |
20 | Info : SWD DLPIDR 0x10000001 |
21 | Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints |
22 | Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints |
23 | Info : starting gdb server for rp2040.core0 on 3333 |
24 | Info : Listening on port 3333 for gdb connections |
mit dem Edu mini sieht es so aus:
1 | acito@ale-virtualbox:/usr/local/share/openocd/scripts$ sudo openocd -f interface/jlink.cfg -f target/rp2040.cfg |
2 | Open On-Chip Debugger 0.11.0-g228ede43d-dirty (2022-08-17-09:27) |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.org/doc/doxygen/bugs.html |
6 | adapter speed: 1000 kHz |
7 | |
8 | Info : Hardware thread awareness created |
9 | Info : Hardware thread awareness created |
10 | Info : RP2040 Flash Bank Command |
11 | Info : Listening on port 6666 for tcl connections |
12 | Info : Listening on port 4444 for telnet connections |
13 | Info : J-Link V9 compiled Dec 13 2019 11:14:50 |
14 | Info : Hardware version: 9.30 |
15 | Info : VTarget = 0.000 V |
16 | Info : clock speed 1000 kHz |
17 | Info : DAP init failed |
Das Projekt was ich mit dem RP2040 machen wollte, habe ich mit CMake/Nmake compiliert, no segger ide. Naja, es fehlt es in VSCode zu integrieren und dann...
> Vor kürze habe ich gedacht das das zu einfach ist, wie wäre wenn ich Ada > probiere... Welchen Grund gibt es sich das Leben noch weiter schwer zu machen indem man sich mit so einer Exotensprache abgibt solange man nicht vom Verteidigungsministerium bezahlt wird? :) Olaf
In meinem Fall ?... Neugier ! Ich weiß noch nicht was alles mit kompiliert wird aber der Blinky (auf Ada) sind > 68 kBytes für die .text Section ! ;-)
Olaf schrieb: >> Vor kürze habe ich gedacht das das zu einfach ist, wie wäre wenn >> ich Ada probiere... > > Welchen Grund gibt es sich das Leben noch weiter schwer zu machen > indem man sich mit so einer Exotensprache abgibt solange man > nicht vom Verteidigungsministerium bezahlt wird? :) > > Olaf Na ja, die Tage hatten wir Jemanden der ein Relais (mit einem µC) schalten wollte. Aber so ganz hatte er dem Braten nicht getraut. Vielleicht wären ja seine Bedenken durch den Einsatz von Ada zerstreut worden. ;-) Aber mal im Ernst, eine mögliche Antwort lautet zB. »Weil's Spaß macht«
Ale schrieb: > mit dem Edu mini sieht es so aus: > ... > Info : J-Link V9 compiled Dec 13 2019 11:14:50 > Info : Hardware version: 9.30 > Info : VTarget = 0.000 V > ... Wohl eher nicht...
Lutz schrieb: >> Das war ein Experiment! Ausserdem wird dort keineswegs jedesmal >> alles upgedatet. Es wird lediglich geprueft ob eines seiner 32Segmente >> dirty ist. > > Ach so. Und wie kommst Du nach dem Aufruf der Funktion da wieder raus? Falk B. schrieb: > Gar nicht! Das ist die Dauerlast für die 2. CPU! Daher die Frage, da keineswegs jedesmal alles upgedatet werden soll.
Olaf schrieb: > Ich glaube auch irgendwo gelesen zu haben das er beim starten von der > Bootfirmware auch in einer Endlosschleife gehalten wird. Bin mir da > jetzt aber nicht sicher. Dann schau in den Bootcode. Da steht, was passiert. Ooops, ist Asm. Was für'n Scheiß aber auch. Asm braucht doch heute absolut niemand mahr... Sagen jedenfalls alle diese C/C++-only Frickler und die müssen es ja wirklich wissen... LOL
Welchen Opfergaben möchte unser aller Forum Assembler Gott haben? Wir huldigen Dir mit allem was möglich ist.
ich sag euch copy and paste ist die Quelle des Bösen !
1 | pacito@ale-virtualbox:/usr/local/share/openocd/scripts$ sudo openocd -f interface/jlink.cfg -f target/rp2040.cfg |
2 | [sudo] password for pacito: |
3 | Open On-Chip Debugger 0.11.0-g228ede43d-dirty (2022-08-17-09:27) |
4 | Licensed under GNU GPL v2 |
5 | For bug reports, read |
6 | http://openocd.org/doc/doxygen/bugs.html |
7 | adapter speed: 1000 kHz |
8 | |
9 | Info : Hardware thread awareness created |
10 | Info : Hardware thread awareness created |
11 | Info : RP2040 Flash Bank Command |
12 | Info : Listening on port 6666 for tcl connections |
13 | Info : Listening on port 4444 for telnet connections |
14 | Info : J-Link EDU Mini V1 compiled Sep 24 2021 16:44:11 |
15 | Info : Hardware version: 1.00 |
16 | Info : VTarget = 3.283 V |
17 | Info : clock speed 1000 kHz |
18 | Info : SWD DPIDR 0x0bc12477 |
19 | Info : SWD DLPIDR 0x00000001 |
20 | Info : SWD DPIDR 0x0bc12477 |
21 | Info : SWD DLPIDR 0x10000001 |
22 | Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints |
23 | Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints |
24 | Info : starting gdb server for rp2040.core0 on 3333 |
25 | Info : Listening on port 3333 for gdb connections |
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.