Raspberry Pi Pico

[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.

     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 

Yup. That was slow as it used the UART in self-clocking mode. There were 3rd party adaptors that used the same phone cable wiring for 1 Mbps by having actual active circuitry that supplied an external clock to the serial port.

Still, it was 2005 before I had home internet that was faster than 230.4 kbps.

x86 PCs in the late 80s didn't tend to have networking at all. Novell Netware existed from 1983 but that wasn't a peer-to-peer network in the current sense. You got a 68000-based central server and every PC had its own cable to the server with just a simple 1:1 protocol running over that. The server provided file sharing and printing. I don't recall PC to PC messages being possible. Novell introduced a completely different peer to peer networking product in 1991.

[exe]

According to [1] there is newer version of the chip. Also, availability of bare ICs seems to be Q2.

[1] https://www.tomshardware.com/news/raspberry-pi-pico-silicon-heading-to-partners

[westfw]

You must be young.

Well, I go back further, but I'm specifically referencing about ~1984 at Stanford, which is about when they were deploying "diskless" Sun-2 Pizza-boxes, expected to do all their file access over the Ethernet.  (16MB RAM seems to be later, according to wikipedia.  The SmallTalk folks needed it.)I guess the price of small disks went down fast enough that "diskless" was a pretty short-lived philosophy.

[PCB.Wiz]

PL2303HXD is 12Mbps 20 years old FS USB device.

Did you test throughput on that ?

Another thread on here, says this,
"IIRC, PL2303 could transmit well over 2Mb/s and bitrates above 3Mb/s made pretty much no difference to throughput."
which suggests the 12M BAUD setting is nominal (char only), with firmware not able to get anywhere close to sustained speeds.

There is a new PL2303GS family, I'd like to get my hands on to test, but so far, sourcing is not easy. One hopes they improved something on the re-spin.

[westfw]

I found something to complain about!

The RP2040 doesn't use the standard core_m0plus.h CMSIS definitions.  Instead, they've got their own names and values for the m0 core pieces.
For example "systick_hw->csr" instead of "SysTick->CTRL"

There's an "issue" open, but they seem oddly resistant: https://github.com/raspberrypi/pico-sdk/issues/21

Out of curiosity, has anyone run into ANY other CM0 vendor that doesn't use the ARM-provided CMSIS-CORE files?

[SiliconWizard]

I found something to complain about!

The RP2040 doesn't use the standard core_m0plus.h CMSIS definitions.  Instead, they've got their own names and values for the m0 core pieces.
For example "systick_hw->csr" instead of "SysTick->CTRL"

There's an "issue" open, but they seem oddly resistant: https://github.com/raspberrypi/pico-sdk/issues/21

Out of curiosity, has anyone run into ANY other CM0 vendor that doesn't use the ARM-provided CMSIS-CORE files?

This is odd. I wonder what's RPi's rationale for not using CMSIS.

And no, I've never run into another vendor doing this.

[westfw]

I wonder what's RPi's rationale for not using CMSIS.

They seems to have been unaware of its significance?    That's a little odd, but somewhat understandable in the "python computer company builds its first microcontroller" context.
It did make me wonder how Atmel (for example) extracts their symbol definitions EXCEPT FOR the stuff already in the core from their SVD/ATDF/whatever "master" files.

[SiliconWizard]

I wonder what's RPi's rationale for not using CMSIS.

They seems to have been unaware of its significance?    That's a little odd, but somewhat understandable in the "python computer company builds its first microcontroller" context.

Well, the fact they went for an ARM core means they have paid (likely a fair amount) and have gotten support from ARM. I've never directly worked with ARM myself, but I would actually expect to get from ARM a minimal set of CMSIS files for the core I was buying. So choosing not to use those and rewrite my own base support would be odd. Now I'd be curious to have feedback from people who have actually worked with ARM, licensed some ARM core and tell us what kind of support they got.

[techman-001]

I found something to complain about!

The RP2040 doesn't use the standard core_m0plus.h CMSIS definitions.  Instead, they've got their own names and values for the m0 core pieces.
For example "systick_hw->csr" instead of "SysTick->CTRL"

There's an "issue" open, but they seem oddly resistant: https://github.com/raspberrypi/pico-sdk/issues/21

Out of curiosity, has anyone run into ANY other CM0 vendor that doesn't use the ARM-provided CMSIS-CORE files?

This is odd. I wonder what's RPi's rationale for not using CMSIS.

And no, I've never run into another vendor doing this.

I transform STM32 SVD's for many Cortex-M's supported by Mecrisp-Stellaris Forth so I have some experience here, especially now that Mecrisp-Stellaris has been ported to the RP2040 by Matthias Koch and Jan Bramkamp.

Nordic vary slightly in that unlike STM who give their bitfield offsets like so:

Code: [Select]

<bitOffset>1</bitOffset>
<bitWidth>1</bitWidth>
Nordic do it this way:

 

Code: [Select]

<lsb>7</lsb>
 <msb>7</msb>
Which meant a little extra computing in the XSLT parser.

However the RP2040 Pico SVD is so different that I had to start again from scratch  writing a totally different set of XLST recipes.

Because of this I have only made a rough and incomplete assembly .equ file for it  so far:

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

There is a TON of information in the RP2040 SVD but it looks to me as though the RPI engineers didn't look at the STM or Nordic SVD's and did their own from scratch . The description fields seem very well done apart from a ton of "\n".

At first I wasn't that impressed by the RP2040, and I still have no use case for it myself, but as I have been talking to the Forth guys using it, and reading the SVD data, I have become very impressed with this chip.

Very clever and inventive minds have worked on the RP2040 and it shows, imho. I now think that it may become a classic in its own right.

Those using it tell me it feels more like a M4 than a M0.

[SiliconWizard]

I dunno again how the team wrote the support files, but SVD itself is part of the CMSIS spec: https://arm-software.github.io/CMSIS_5/SVD/html/index.html
You can check whether RPi's approach is conforming.

[exe]

I tried to use PIO modules as SPI. Here are some results.

1. I connected "nokia monochrome lcd" display, created SPIPIO instance, it doesn't work . Figuring out why, hooked an oscilloscope.

2. The gap between transmissions of each byte is drastically different. If I use machine.SPI, the pause between bytes is 2us. With PIOSPI class it's 40us. The data rate appears to be the same, 1us per bit. Perhaps, that's because feeding buffer in Python loop byte-by-byte is inefficient. The good news is, it probably can be optimized with a bit of C code or something.

3. The example code provided in the datasheet is incorrect, python methods are missing "self" argument: https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py .

[exe]

I did a bit of more testing and I found the problem: there is no data from MOSI pin. I had to add `mode=Pin.OUT` to initialization code to MOSI (into PIOSPI class initialization), but it helped only partially: the pin is simply held low when transmitting. That was with state machine' id=0. If I change it to 1 without rebooting device, then it seems I see an interaction of two state machines: I see somewhat interleaved data. Still nothing like SPI output. Hmm...

[NorthGuy]

Perhaps, that's because feeding buffer in Python loop byte-by-byte is inefficient. The good news is, it probably can be optimized with a bit of C code or something.

PIO has FIFOs which I think can be fed with DMA. Thus, you should be able to set everything up without any CPU involvement (except for reloading DMA).

PIO can run much faster than 1 MHz, so there shouldn't be any problem eliminating gaps between bytes with 1 MHz SPI.

[exe]

Oh boy, I think their PIO SPI example for micropython is non-functional. I can't wrap my head what's wrong with it, but I suspect the code expects to automatically lower SS pin, but that was only partially implemented (SS pin is not passed to state machine, but somehow it starts toggling MOSI pin instead). This is the code that I wrote after studying examples for C api. Last two lines are actually the implementation, rest is some initialization code.

@rp2.asm_pio(
    out_shiftdir=0,
    autopull=True,
    pull_thresh=8,
    autopush=True,
    push_thresh=8,
    sideset_init=rp2.PIO.OUT_LOW,
    out_init=rp2.PIO.OUT_LOW)
def spi_cpha0():
    out(pins, 1)             .side(0x0)
    in_(pins, 1)             .side(0x1) [1]

The code I took "for inspiration" is this: https://github.com/raspberrypi/pico-examples/blob/master/pio/spi/spi.pio .

EDIT the code is not checked for correctness, use at your own risk. I only checked with an oscilloscope that it produces some wiggly lines looking like SPI.

[newbrain]

Just two little notes:

1. There's one thing they really got right with the Pico board: Pin numbering and GNDs!
Most dev boards have very few GNDs and in awkward places, and GPIO pins are often all over the place, the pinout of Pico really nails it.

2. If you like to live on the edge, there is now preliminary support for both RP2040 and the Picoprobe debugger in a feature fork of pyOCD. I'm guilty for the Picoprobe part. It seems to work well inside VS Code. Picoprobe requires libusb (I use libusb0 (v1.2.6.0) as provided by Zadig) under Windows.

[EasyGoing1]

1. There's one thing they really got right with the Pico board: Pin numbering and GNDs!

Interesting because I felt that the number of ground pins was a bit excessive and what's up with all the replication of I2C channels?

And Python as the touted language of choice for development? Really? Now to be fair, this Pico is my first experience with anything Python, I'm a Java / C++ person myself, but I've already gotten some experience with multithreading using Micropython and I'm still not impressed with this language as a microcontroller development language. I cut my teeth on scripted languages back in the 1980s when I was just a pup and Python has that 80's scripted feel to it ... but I'm still going to keep an open mind and see if I encounter the moment where it all makes sense. I have to believe that it would not be as popular as it is without a good reason, I just need to see what that reason is.

[newbrain]

Interesting because I felt that the number of ground pins was a bit excessive and what's up with all the replication of I2C channels?

Ah well, what I usually experience with other boards is that I need to bodge something up to multiply the very limited GND options.
It can also help with signal integrity.

As for the replication, it's just more freedom to use the pins one finds more convenient, so definitely a plus wrt to a stricter pin/function mapping.

I've not yet used python on the Pico (only for the Pico), after all the C toolchain is perfectly fine, though I wonder why they had to go with MS compilers/nmake for their utilities rather than freer alternatives (e.g. ninja/make/gcc).
MC command line compilers + nmake are freely available, but the licensing is not really Ok, unless you are either an hobbyist or own a licensed copy of VS.

[SiliconWizard]

I've not yet used python on the Pico (only for the Pico), after all the C toolchain is perfectly fine, though I wonder why they had to go with MS compilers/nmake for their utilities rather than freer alternatives (e.g. ninja/make/gcc).
MC command line compilers + nmake are freely available, but the licensing is not really Ok, unless you are either an hobbyist or own a licensed copy of VS.

I haven't used the Pico so far, so I'm probably missing a lot of details here, but the C Pico SDK is all designed to use CMake and GCC: https://github.com/raspberrypi/pico-sdk

So what would you need MS tools for?

[newbrain]

I haven't used the Pico so far, so I'm probably missing a lot of details here, but the C Pico SDK is all designed to use CMake and GCC: https://github.com/raspberrypi/pico-sdk

So what would you need MS tools for?

If you are on Windows, their recommended way is to download the MS command line compiler set, and they use by default the nmake backend for Cmake.
The MS C compiler is used for the u2f utility (maybe some others?).

If one switches the Cmake backend to ninja, you are free from nmake, at least (tried, no problems).

Then, still on Windows, they propose a modified version of OpenOCD to support their Picoprobe - build it yourself (yet another toolchain, msys) or download a binary.

This is the major reason I extended pyOCD to support the Picoprobe...and the Picoprobe itself (added target HW reset, PR just merged), so I could have a better portable toolchain and project settings.

I found their recommendation quite weird, especially for licensing issues.

[Nominal Animal]

I found their recommendation quite weird, especially for licensing issues.

If you accept the claim that the Pi Foundation has a deep dislike of everything F/OSS, it makes perfect sense.

[SiliconWizard]

You can absolutely use CMake directly. They probably just recommend tools on top of that to make life a bit easier, but for a reasonably seasoned engineer, I can't see a single reason for not using the SDK directly with just CMake and GCC. Heck, you can even use Make if you don't like CMake (which would be my case.) You just need to extract the proper compilation flags and preprocessor macros from the SDK's CMake files. It's relatively straightforward if you're familiar with ARM Cortex development.

I don't know what the u2f utility is. What does it do? Can't you do without it?

As for OpenOCD, that's a minor issue. As you said, either build it from source or download their binary - I doubt the binary was built with anything else than a open source toolchain. Here they really didn't have a choice. The time to get their Pico support to the mainline OpenOCD could be months, so they don't have a choice but maintain a fork in the meantime.

Using 100% open source tools may take a bit more effort but it definitely looks like a minor deal to me. The why they themselves used MS tools, I don't know. Probably just to make their own life easier. As I noted for the RPi itself, the RPi foundation doesn't seem to care that much about open source, we can't say that any of their products actually are. They care about ease of use and low price, something that, contrary to common misconception, is harder to achieve with a 100% open source approach, depending on the context.

[lucazader]

From what i can see int heir guides, for windows you still have to use gcc to compile.

But you do have to install the Visual studio build tools. And as far as i can see they are only using nmake out of the parts that are installed.
I think because installing standard make or ninja in windows isn't quite as straight forward or as seemingly trustworthy (here have this random binary that you dont install and just plop in some directory"
Compared to installing the official VS tools.

As others have previously mentioned, because the project uses cmake, you can just build with gcc and ninja and not install any of the MS tools they suggest.

[hamster_nz]

From what i can see int heir guides, for windows you still have to use gcc to compile.

But you do have to install the Visual studio build tools. And as far as i can see they are only using nmake out of the parts that are installed.
I think because installing standard make or ninja in windows isn't quite as straight forward or as seemingly trustworthy (here have this random binary that you dont install and just plop in some directory"
Compared to installing the official VS tools.

As others have previously mentioned, because the project uses cmake, you can just build with gcc and ninja and not install any of the MS tools they suggest.

Oh my... I just opened up Ubuntu under WSL2, and followed the Ubuntu instructions. The resulting binary file can just be copied from the \\WSL$\Ubuntu\home\ to the USB Mass Storage device presented by the Piico... 

[newbrain]

I think because installing standard make or ninja in windows isn't quite as straight forward or as seemingly trustworthy (here have this random binary that you dont install and just plop in some directory"

make, ninja, etc: I use chocolatey.

Code: [Select]

~\Git\pyOCD [LinuxLibUSB ≡]> choco list --local-only
Chocolatey v0.10.15
chocolatey 0.10.15
cmake 3.19.3
cmake.install 3.19.3
make 4.3
ninja 1.10.2
5 packages installed.

Oh my... I just opened up Ubuntu under WSL2, and followed the Ubuntu instructions. The resulting binary file can just be copied from the \\WSL$\Ubuntu\home\ to the USB Mass Storage device presented by the Piico... 

D&D is something that any Nucleo or mBed board supports (with a bonus real debugger thrown in, too), the convenience is undeniable.
No difference here between Windows and Linux, my main objection is that they use the MS C compiler under Windows to compile the utility that transforms the elf or bin file into the u2f format (that you must use for the D&D programming) and nmake when all the rest of the chain is based on gcc and other FOSS tools.
I like, use, contribute and also work with Open Source but I'm not an RMS cultist (I'm really happy that Apache is now the most common FOSS license), but I have nothing in principle against proprietary SW (which I buy, use and send bug reports about).
The inclusion of a toolchain with a non-free license makes the whole more difficult to handle in a context outside hobbyist/enthusiast - nothing more (and as a user of Visual Studio Community, does not really affect me anyway).

But I agree with Nominal Animal, they don't much care about Open Source.

[Nominal Animal]

To be clear, there is nothing wrong in using proprietary tools or licenses; I do, too.  (The reason I use Tux as my mascot is not because I'm a Linux zealot, it is because I happen to like the whimsy involved, and have chosen to use Tux as a (non-exclusive) "brand" of sorts for myself.  For example, I created and use a (plymouth) bootsplash animation of Tux rotating its eyes in opposite directions on my Linux machines.  Drop me a PM if you want the debian package. )

The problems arise when someone ideologically opposed to libre licensing interfaces with libre communities.  It causes useless friction for all involved.

The worst case scenario is when libre software is mixed with non-libre software in the same project or recommended workflow.  The libre users have issues with the non-libre components, and the users coming from the non-libre, vendor-supported side get frustrated with the perceived hostility of the libre side (because the users do not realize they are not paying customers anymore, just participants, and dislike the loss of customer privileges like having the moral grounds for demanding features and fixes).  It just makes a mess where nobody is happy.

I'm a Help Helper at heart, and just want users to have tools that make them efficient and powerful, and not waste resources and time doing their tasks.  I know and understand the benefits of proprietary/vendor products, and the benefits of libre products.  The two aren't exclusive, but when mixed in a workflow, one must understand and accept both to be able to make it work well; and the Raspberry Pi foundation clearly does not.  Which annoys me, because it causes useless and unnecessary friction in the communities I participate in.