Raspberry Pi Pico

[DrG]

Here is where I am at (and if I don't get it solved soon, I should probably make it a separate thread).

I successfully build hello_usb, - you can see the code here https://github.com/raspberrypi/pico-examples/blob/master/hello_world/usb/hello_usb.c it simply prints out "Hello World" repeatedly. Win 7-64.

I drop hello_usb.uf2 into the Pico it shows up in Device manager as Board CDC - and the all-to-common yellow exclamation point of doom.

Working from here, I made an .inf file from the Microchip COM driver by substituting lines as the thread messages discuss https://www.raspberrypi.org/forums/viewtopic.php?t=300633

But, when I try to update the driver manually and point to the directory containing the modified .inf, there is no joy - it simply says it can't install.

I made the changes carefully and did it twice.

I have tried mucking around a bit with the [Strings] section to match Board CDC to no avail. I have forgotten what little I ever knew about the internals of device drivers on win 7.

Presence or absence of usbser.sys in the directory containing the .inf makes no difference.

Turning off av makes no difference.

Not sure what I am missing.

[andersm]

I haven't done much Windows driver work, but IIRC from some version (Vista?) onwards, it will refuse to load unsigned drivers (including .infs), unless it's disabled in the boot options.

[DrG]

I haven't done much Windows driver work, but IIRC from some version (Vista?) onwards, it will refuse to load unsigned drivers (including .infs), unless it's disabled in the boot options.

True and that would have been nice  but alas, no joy (disabled in boot long ago).

[DrG]

Joy!




I ended up selecting the driver from a list of all of them on the drive. Found Microchip's USB serial Port - and it worked.



Not sure why exactly. Maybe the .inf needed a default section to find stuff or some such thing - or maybe I just missed something very basic.

[Cliff Matthews]

Cough.. Mine is working too. Well at least I got the LED working.. But there's no end to the weirdness in device manager..

[PCB.Wiz]

I don't know, I need to do more studying and experimenting, but I appreciate anyone's help on the issues.

google finds this, which maybe of use to you ?
https://github.com/Noltari/pico-uart-bridge


Raspberry Pi Pico USB-UART Bridge
This program bridges the Raspberry Pi Pico HW UARTs to two independent USB CDC serial devices in order to behave like any other USB-to-UART Bridge controllers.

and a thread here
https://www.raspberrypi.org/forums/viewtopic.php?t=302684

However, I do not see mention of any test results, covering tested baud ranges and actual throughputs ?
It would be nice to see a FT232H or FT2232H connected to a Pico, and then things pushed, to see where they break

With only USB-FS speeds, the UARTS are likely to only be good for low-MBd region speeds, but Pico may be nice as a more-flexible-than-FTDI type solution.

 

[tszaboo]

So in the last few days I took it out for a spin and tested the board. I used it to test an I2C sensor, and I used the Circuitpython implementation.
It was super fast to test or debug code. I had the script open in Notepad++ and putty was monitoring the serial port. Every time I saved the notepad++ file, the pi rebooted and run the script and it spit out the result into the terminal. If I wanted some help or run some other command, I just used REPL for it.
Once a code was modified, it was running on the microcontroller in less than a second. Less than a second! In C if you press compile, and upload it takes quite some time to test your code, I guess every code change takes well over a minute. Not to mention I could write statements, like print( "0x34 register: "+ str(readI2C(0x34))) and it would just spit the value to the terminal. No worries about pointers, easy casting of data types. If you ever have to  write code with the itoa function with a buffer created manually, you know what I mean.
I really felt like concentrating on the sensor, and the physical arrangement and the engineering. Instead of writing code, worrying about pointers and looking up ways to solve trivial programming problems.

[brucehoult]

How on earth do you get C program turn-around to be "well over a minute"?

Using, for example, the Arduino IDE with an AVR Arduino, a Hifive1, a Teensy 4.0 ... in every case it's more than a second from hitting "Compiler & Run" to having it running on the board, but for typical sized programs well under 5 seconds. I've never actually thought to time it, because it's just no big deal.

It's the same using command line tools such as gcc and avrdude or openocd -- which, after all, is what the IDE uses under the hood anyway.

[artag]

Maybe he's not using AVR?
ESP devices are painfully slow to compile, and Teensies can be fairly slow (perhaps partially because they can hold a lot of code).

[hamster_nz]

The Pico C/C++ SDK is quite nice, in that through cmake magic it only builds the bits you need, and it does do minimal incremental builds.

Last time I used ESP32's ESP-IDF it was pretty slow for the first build..

I haven't set up the Pico to use a H/W debugger yet. Even without one it takes longer for me to reset the Pico into programming mode than it does to build after a trivial code change.

[DrG]

I don't know, I need to do more studying and experimenting, but I appreciate anyone's help on the issues.

google finds this, which maybe of use to you ?
https://github.com/Noltari/pico-uart-bridge


Raspberry Pi Pico USB-UART Bridge
This program bridges the Raspberry Pi Pico HW UARTs to two independent USB CDC serial devices in order to behave like any other USB-to-UART Bridge controllers.

and a thread here
https://www.raspberrypi.org/forums/viewtopic.php?t=302684

However, I do not see mention of any test results, covering tested baud ranges and actual throughputs ?
It would be nice to see a FT232H or FT2232H connected to a Pico, and then things pushed, to see where they break

With only USB-FS speeds, the UARTS are likely to only be good for low-Md region speeds, but Pico may be nice as a more-flexible-than-FTDI type solution.

Thanks, I took a look, bookmarked it and wandered through the thread. The problem I was having was simply gettimg WIN 7 to load up usbser and eventually I got that to work.

When I get something like this (I have no RPi experience), I like to think about some project that is worthwhile that I can get into. So, basically, I just want the Pico on a board that contains, for example, an I2C sensor. The board with sensor is attached to a PC. A nice, easy to use, program running on the PC allows you to set the sensor's memory/variables. Take, for example, some of the Honeywell T/H sensors where you can set alarm levels- that sort of thing.

You plug the board in (with the sensor in a socket), do whatever you need to do, pop the sensor out, and your done. Once you have a VS program working, they work rather nicely, I think.

The Pico plugs into the PC, communicating as a serial port (with no additional board). User reads and writes settings, which the Pico programs into the sensor using its I2C interface. All you need is the socket and a couple of simple components (a couple of resistors and capacitors).

Makes it pretty attractive for only a few bucks, I think. In fact, at the sale price of US$2, they are about as cheap as any FTDI USB/serial board alone.

That guy's program that you linked to makes multiple USB serial ports, which as mentioned in the thread, has some uses as well.

[exe]

Does anyone have rp2040 as a component that I could use in diptrace? I can surely draw it myself, but I'd prefer not to take risks.

[tszaboo]

How on earth do you get C program turn-around to be "well over a minute"?

Using, for example, the Arduino IDE with an AVR Arduino, a Hifive1, a Teensy 4.0 ... in every case it's more than a second from hitting "Compiler & Run" to having it running on the board, but for typical sized programs well under 5 seconds. I've never actually thought to time it, because it's just no big deal.

It's the same using command line tools such as gcc and avrdude or openocd -- which, after all, is what the IDE uses under the hood anyway.

I took an example project with similar complexity (LIS3DSH Fifoexample) of 10 seconds to compile to an Arduino Due (which is an M0). Upload in my experience takes at least a few seconds. Then you need to manually close the serial terminal and try the upload again, because  before uploading it, open it again, it defaults to 9600 baud, you change the baudrate, and then your code is running.
Maybe not an entire minute, but compare all this with just pressing Ctrl+s -> code is running.

[techman-001]

A very preliminary release of the new Mecrisp-Stellaris-Pico Forth has been released for Forth fans:
https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/Mecrisp-Stellaris-Pico-17feb2001.tar.gz

Plus an Assembly .equ file (transformed from the rp2040 SVD) is here:-
https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/RP2040.svd.equates.s.gz

https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/RP2040.svd.equates-with-descriptions.s.gz

I don't have a Pico myself, so haven't tried it but I believe this runs on one cpu and uses a USART for terminal comms. I expect that terminal comms over SWD won't be long coming.

This release has s31.32 fixed point numbers as with all Mecrisp-Stellaris Forths.

The obligatory Blinky:

Code: [Select]

$40014000 constant IO_BANK0_BASE
$4001c000 constant PADS_BANK0_BASE
$d0000000 constant SIO_BASE

\ Already configured in core for SIO (Software IO), function 5:

\ IO_BANK0_BASE 0 8 * +     constant GPIO_0_STATUS
\ IO_BANK0_BASE 0 8 * + 4 + constant GPIO_0_CTRL
\ IO_BANK0_BASE 1 8 * +     constant GPIO_1_STATUS
\ IO_BANK0_BASE 1 8 * + 4 + constant GPIO_1_CTRL
\ ...

SIO_BASE $004 + constant GPIO_IN       \ Input value for GPIO pins
SIO_BASE $010 + constant GPIO_OUT      \ GPIO output value
SIO_BASE $014 + constant GPIO_OUT_SET  \ GPIO output value set
SIO_BASE $018 + constant GPIO_OUT_CLR  \ GPIO output value clear
SIO_BASE $01c + constant GPIO_OUT_XOR  \ GPIO output value XOR
SIO_BASE $020 + constant GPIO_OE       \ GPIO output enable
SIO_BASE $024 + constant GPIO_OE_SET   \ GPIO output enable set
SIO_BASE $028 + constant GPIO_OE_CLR   \ GPIO output enable clear
SIO_BASE $02c + constant GPIO_OE_XOR   \ GPIO output enable XOR

: blinky ( -- )

  1 25 lshift GPIO_OE !

  begin
    1 25 lshift GPIO_OUT_XOR !
    10000000 0 do loop
  key? until
;

[iMo]

I took an example project with similar complexity (LIS3DSH Fifoexample) of 10 seconds to compile to an Arduino Due (which is an M0)..

M3

[DrG]

Arduino Nano RP2040 Connect

https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-the-world-of-microcontrollers/

Apparently, a few are out there https://www.tomshardware.com/news/first-pi-silicon-arduino-nano-rp2040-connect-spotted

I don't see what the price is/will be, but I wonder how it compares with their Nano 33 IOT https://store.arduino.cc/usa/nano-33-iot

[josip]

However, I do not see mention of any test results, covering tested baud ranges and actual throughputs ?
It would be nice to see a FT232H or FT2232H connected to a Pico, and then things pushed, to see where they break

With only USB-FS speeds, the UARTS are likely to only be good for low-Md region speeds, but Pico may be nice as a more-flexible-than-FTDI type solution.

I made dual CDC UART bridge based on MSP430F5510, that was able to reach 4 Mbps (in parallel). I am not sure that this belong to "low-Md region speeds". And pico with dual 100MHz core can eat 25MHz MSP for breakfast.

And again, USB-FS is not a problem. Bloated code is.

[PCB.Wiz]

I made dual CDC UART bridge based on MSP430F5510, that was able to reach 4 Mbps (in parallel).

Was that sustained 4Mbd in both channels, and both duplex, (impossible, as that's 16M of data flow),  or peak speeds of 4MBd going one way, in one channel (possible) ?

.... And pico with dual 100MHz core can eat 25MHz MSP for breakfast.
And again, USB-FS is not a problem. Bloated code is.

Hmm... not sure how you can so easily ignore a 12MB limit on the FS-USB so easily, Best numbers I've seen/tested for USB bridges on FS-USB come in around 9MBd one way tops, as that's the USB bandwidth limit. 
Even a 1GHz processor, does not make that 12MHz FS-USB ceiling vanish

[westfw]

Quote

not sure how you can so easily ignore a 12MB limit on the FS-USB so easily

When I was a lad... we ran FILESYSTEM STORAGE over 10Mb Ethernet.  And 16MB of RAM was heavenly (and expensive!)

What is it you want to do with your Pico that the 12Mbps ceiling is a problem?  That'd fill up the RAM in 0.2s, and the flash in less than 2s...

[brucehoult]

You must be young.

When I started university the computer 1st year students programmed on was an 11/34 with 256 KB RAM, with 22 VT52 terminals and 2 LA120 printers. And two 5 MB disks.

A couple of years later the main university computer was an 11/780 with 2 MB RAM and up to 50 people logged on during working hours. That sucked, but it went quite well at 2 AM with 10 or fewer people on it.

My first job had a similarly spec'd DG MV10000 with a similar number of users.

As soon as it was possible, I got all my own users (analysts writing research reports on companies) onto Mac Plus with 1 MB and a LaserWriter instead of output going via an IBM DisplayWriter system to a daisywheel printer and then hand pasting graphs and charts from an HP plotter. I got them upgraded to 2.5 MB as soon as 1 MB DIMMs were available, and to 4 MB once the accountant recovered from the heart attack. Custom app development went *much* faster once I was able to do it on a Mac II, even though I only had 4 MB for quite some time -- that machine was a real beast for the time.

I don't think I had anything with as much as 16 MB RAM until either the Quadra 700 in late 1991, or the PowerMac 6100 in 1994 -- I actually can't remember which one now. 4 MB was standard on the Quadra and the 6100  came with 8 MB soldered on the motherboard and 2 empty slots. Both could theoretically upgraded to a lot more -- even 1989's Mac IIx, IIcx, SE/30 could be theoretically upgraded to 128 MB, but that would cost as much as a cheap BMW.

[brucehoult]

Oh and we kept documents on a fileserver with a 230.4 kbps network at first, with 10baseT a very welcome upgrade when it arrived.

[josip]

Was that sustained 4Mbd in both channels, and both duplex, (impossible, as that's 16M of data flow),  or peak speeds of 4MBd going one way, in one channel (possible) ?

Hmm... not sure how you can so easily ignore a 12MB limit on the FS-USB so easily, Best numbers I've seen/tested for USB bridges on FS-USB come in around 9MBd one way tops, as that's the USB bandwidth limit. 
Even a 1GHz processor, does not make that 12MHz FS-USB ceiling vanish

I am using bridges only for fast log from free running micro's. My target was half duplex, from free running micro to PC over my MSP430 bridge. For testing both micros was firing at highest possible speed (4Mbps) ASCII incremented characters, and on PC side there was checking what was received. I left it for more than 10 minutes, and there was no errors. Both bridges active in half duplex.

I don't remember if I test it (on the same way) for full duplex, but I guess that 2Mbps with both active bridges shouldn't be a problem, Because transfer from PC to micro's need less micro power (instruction cycles) with DMA firing 64 byte CDC packet to UART, byte by byte.

PL2303HXD is 12Mbps 20 years old FS USB device.

[guenthert]

Oh and we kept documents on a fileserver with a 230.4 kbps network at first, with 10baseT a very welcome upgrade when it arrived.

     Let me guess, Macs connected via AppleTalk?  That must have been mid to late eighties.  LANs existed earlier, but were uncommon.  Sneakernet across PCs and terminals connected to minis/mainframes more typical then.  But we digress 

     Yeah, I too like to know, what problem the Pico is supposed to solve with USB HS, which it can't with FS.  That we don't get Guinness records breaking bleeding edge technology for $4 shouldn't be much a surprise.

[SiliconWizard]

I'm not as old, but at Uni in the 90's we were still using coax ethernet.

[DrG]