RP2040: welke ontwikkeltool?

Voor een nieuw projectje is de keuze gevallen op de RP2040 microcontroller. (Veel andere keuze is er niet in deze tijd)

Maar de vraag is nu: wat voor ontwikkeltools zijn er voor beschikbaar? Het werkt in ieder geval al wel met Arduino. De 'blink' sketch doet het alvast.
Maar ik ben bang dat Arduino in de toekomst toch wat te beperkt gaat zijn.
Maar wat zijn er voor alternatieven? Is platformio misschien iets? (eerste impressie: hij kent alleen de 'Arduino Nano RP2040 Connect' en we gebruiken juist het bordje raspberry)

Wat me erg stoort in de officiele documentatie is dat het daar allemaal gaat over linux, linux en nog eens linux. En dan specifiek rpi. Ze willen blijkbaar dat ik een standaard Raspberry Pi als desktop ga gebruiken om voor de rp2040 te ontwikkelen. Sorry, dat gaat hem hier niet worden. We gebruiken hier gewoon Windows 10.

Het kan met Microsoft Visual studio met wat extra tools, of je kunt Ubuntu met development tools in een virtuele machine draaien. Dat laatste zou ook niet perse mijn voorkeur hebben, maar het kan wel.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Als het al werkt op de Arduino-IDE, dan heb je de GCC compiler al draaien.

Die kun je ook buiten de Arduino-IDE om rechtstreeks gebruiken. Dat doe ik hier ook voor Atmel AVR processors.

Dat zijn dan wel command-line tools zonder IDE.

Je kunt een CMake plugin in Eclipse installeren, en dan Eclipse gebruiken. Dat werkt ongeveer.

Maar het is allemaal niet ondersteund. YMMV.

En wat deKees zegt is ook waar. Het is uiteindelijk gewoon een ARM Cortex CPU, en GCC kan daar gewoon code voor bakken.

Dan moet je nog een beetje loodgieten om de juiste header voor de RP2040 ROM-bootloader voor je binairy te zetten maar dat is allemaal geen rocket-science: De C-code die dat doet zit in de SDK (en is de reden dat je Microsoft C moet installeren om het op windows te gebruiken :-O)

Plug and Play op Windows is het echter niet. Misschien als je een forse donatie aan de RPi foundation doet?

Ik gebruik gewoon de Pico-SDK. Op een Raspberry pi 4.
Ik gebruik de RPI-4 headless. Dus ik werk gewoon op m'n PC werkstation (met ubuntu).

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

OK,

Hoe zit het met debuggen? Dat bordje heeft een handige swd debug poort.
Maar hoe debug ik in de praktijk? Ik wil graag kunnen 'steppen' en dingen in de 'watch' zetten.

Misschien ben ik verwend, maar de microcontrollers die ik tt nu toe heb gebruikt hadden allemaal een eigen dedicated ontwikkelomgeving. Voor de PIC32 was er MpLab-X, voor atmel was er AtmelMicrochip Studio. Dat mis ik nu een beetje.

daarom zijn ze ook zo goedkoop :p het maken van goede tooling kost ook tonnen/miljoenen

Ik gebruik gewoon Eclipse als debug-gebruiks-interface, maar ik heb ook een J-link liggen die ik aan de SWD poort kan hangen. J-Link praat het GDB protocol (of tenminste, er zit een driver bij die dat kan) en Eclipse snapt dat.

Maar het is absoluut niet zo simpel als MPLab of AtmelStudio installeren.

De "officiele" methode via een R-Pi (zal ook wel kunnen op een willekeurig Ubuntu of Debian installatie) is waarschijnlijk het makkelijkst om aan de praat te krijgen.

Het kostte mij een dag prutsen om het met Eclipse op Windows 10 werkend te krijgen. Toen kwam er weer ander (betalend!) werk tussendoor, dus ben ik er weer mee gestopt.

Ik verwacht dat iedere professionele embedded ontwikkelaar dit binnen een paar dagen aan de praat kan krijgen. Maar ik verwacht ook dat een professionele embedded ontwikkelaar er geen probleem mee heeft om een ubuntu installatie ernaast te hebben. YMMV.

Mijn ervaring is dat met een debugger kan je "rauwe" variabelen bekijken. Tegen de tijd dat je software iets ingewikkelder wordt, dan wil je iets meer "cooked" dingen hebben.

Simpel voorbeeld zijn de settings van de registers. Die kan je in de debugger vast wel bekijken als hex getallen. Ik heb in mijn software:

code:


gpio0: HIGH(LOW ) :  f2(UART) IN slew0 drive1
gpio1: HIGH(LOW ) :  f2(UART) IN slew0 drive1
gpio2: HIGH(LOW ) :  f5(SIO) IN slew0 drive1
gpio3: HIGH(LOW ) :  f5(SIO) IN slew0 drive1
gpio4: LOW (LOW ) :  f31(<nothing>) IN slew0 drive1
gpio5: LOW (LOW ) :  f31(<nothing>) IN slew0 drive1
...

Nu zou het best kunnen dat iemand de moeite heeft genomen om deze dingen van de GPIO poorten toch in de debugger te stoppen zodat je ze beter kan bekijken dan als hex getallen, maaar ook in je eigen software kan zoiets gaan voorkomen. Dan heb ik dus liever dat ik een "dump mijn datastructuur" ding maak die de voor mij relevante info dumpt op een manier dat ik het kan lezen.

Kortom, ik debug met een USB-verbinding waar ik relevante info kan dumpen. Maar goed. Niet iedereen is het met deze strategie eens.... Het visueel (met een GUI) debuggen heeft ook z'n nut.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

@rew: met een debugger kun je ook breakpoints zetten, zodat je code precies op het juiste moment stopt en je kunt kijken wat er eigenlijk precies gebeurd.

Dat kan niet met een USB/serieel data-dump.

Mijn ervaring is dat ik beiden gebruik, door elkaar en afhankelijk van welk probleem ik wil oplossen.

Soms zijn breakpoints nuttig, en soms wil je juist zien wat er gebeurd zonder de CPU te stoppen, omdat die iets aan het besturen is. Om live mee te kijken heeft CAN nog altijd mijn voorkeur, daarmee kun je gewoon elke cycle van een control loop data versturen en live plotten in een grafiekje.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Op 6 juli 2022 13:39:32 schreef hneel:
OK,

Hoe zit het met debuggen? Dat bordje heeft een handige swd debug poort.
Maar hoe debug ik in de praktijk? Ik wil graag kunnen 'steppen' en dingen in de 'watch' zetten.

Misschien ben ik verwend, maar de microcontrollers die ik tt nu toe heb gebruikt hadden allemaal een eigen dedicated ontwikkelomgeving. Voor de PIC32 was er MpLab-X, voor atmel was er AtmelMicrochip Studio. Dat mis ik nu een beetje.

Ik heb er geen ervaring mee maar vlgs mij kun je hier misschien iets mee https://blog.adafruit.com/2021/02/05/pico-debug-a-built-in-cmsis-dap-d…

Verder zou ik deze IDE's gewoon installeren en proberen;
PlatformIO,Netbeans en Eclips.

Eclpise aan de praat krijgen viel niet mee, maar het is nu wel gelukt.
Belangrijk is dat je het path in Eclipse kan aanpassen. Dat moet je maar net even weten...
Standaard kopieert hij het path uit windows, en dan gaat compileren 99% kans fout. De meeste ontwikkelaars zullen immers meerdere make.exe bestanden op hun computer hebben staan, en dan zal waarschijnlijk een verkeerde worden gekozen. Maar je kan dus in de project properties het path aanpassen en alles wat overbodig is schrappen.

Onlangs even naar Segger EmbeddedStudio gekeken. Dat werkt toch wel een heel stuk makkelijker dan dat Eclipse. Wat een wereld van verschil! Alles intuitief en de voorbeelden werkten meteen goed.

Er zit helaas alleen wel een pittig prijskaartje aan.

trix

Golden Member

even voort borduren hierop,
zijn er nog mogelijkheden bij gekomen sinds de laatste post ?

ik ben zelf bezig om een raspberry pi pico te programeren met "visual studio code" gewoon onder windows.
ik heb de pico-examples al geïmplementeerd.
en ben aan het kijken naar de blink.c, het lukt alleen nog niet om dit op de raspberry pico te krijgen.
hij weet dat er een pico aanhangt en dat GCC de compiler is (zie onderaan in de blauwe balk). maar als ik: run -> start debuging doe krijg ik foutmeldingen.
blijkbaar heeft het wat te maken met CMake, waarvan ik niet goed weet wat dat doet.

eigenwijs = ook wijs

Kan je de boel compileren? Krijg je een .UF2 file ?

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
trix

Golden Member

compileren doe ik toch met:
run -> start debugging

waar zou ik die .UF2 file kunnen zien ?

is het niet zo dat visual studio code automatiscg de Gcc compiler gebruikt om te debuggen ?

edit:
debug icoontje gevonden: rechsboven in de licht grijze balk dat schuine driehoekje.

"cannot build and debugge because the active file a is not a c or c++ source file"

de pop-up melding rechts onder op mijn plaatje (met het rode kruisje in rondje er voor) zegt voluit:
Bad CMake executable: "". Check to make sure it is installed or the value of the "cmake.cmakePath" setting contains the correct path

[Bericht gewijzigd door trix op 7 april 2023 08:50:38 (25%)

eigenwijs = ook wijs

Ja, kijk. Ik ken jou onwikkelomgeving niet.

Maar d'r zijn een paar dingen die ik wel weet. Die processor kan jou code niet runnen. Die runt een gecompileerde versie van het "blink.c" progamma.

Dat gecompileerde programma moet naar je "target" gestuurd worden. Daar kan je dan een debugger voor gebruiken. Heb je die? Nee? Goh, dat zou wel eens een probleem kunnen zijn om "start debugging" te laten werken.

In de arduino omgeving heb je aparte knoppen om te compileren en om te compileren en de boel naar de target te sturen. Dat zal hier ook wel zo zijn. Dan zou je de .elf en .uf2 moeten krijgen...

Ik dacht dat je zei dat gcc gewerkt had. Maar bij nader inzien is dat niet zo. Sorry.

Tja, de examples werken veel met "cmake" files. En die zitten goed in mekaar en ze werken. Bij mij in ieder geval wel. Dus je hebt kennelijk dat visual studio ding niet goed naar de juiste Cmake file gestuurd. Of hij verwacht van jou dat JIJ met de hand "cmake" intikt. Ik weet het niet.

Als je had gezegd: "Ja er is wel een UF2" dan had ik gezegd: "Druk op het knopje op de pico, steek de USB er in en copieer dat uf2 bestand naar de USB schijf die je krijgt". Maar helaas zo ver is het nog niet.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/