"Pi Pico 2" - Pre-Development projects discussion

[speccery]

Finally received the letter with a few boards from Pimoroni, and got the blink program running on the RP2350. I guess this means that I will need to get back to work on the picocart board, I haven't worked on that project on a looong while. The nice thing was that I just needed to update the pico SDK and after that I was able to compile and upload the binary code to the RP2350. Also the first benchmarks in YouTube are out, at the stock clock frequency on the RP2350 and RP2040 the new chip is about 2x faster. That's with integer code, with floating point it will be a very different story. I am also interested in comparing this to chip I use in the strangecart (150MHz Cortex-M4 and Cortex-M0+), as well as to my other boards with Cortex-M7 chips at clocks from 280MHz to 450MHz. 

 

[Gary from OPA]

3 minutes ago, speccery said:

Finally received the letter with a few boards from Pimoroni, and got the blink program running on the RP2350. I guess this means that I will need to get back to work on the picocart board, I haven't worked on that project on a looong while. The nice thing was that I just needed to update the pico SDK and after that I was able to compile and upload the binary code to the RP2350. Also the first benchmarks in YouTube are out, at the stock clock frequency on the RP2350 and RP2040 the new chip is about 2x faster. That's with integer code, with floating point it will be a very different story. I am also interested in comparing this to chip I use in the strangecart (150MHz Cortex-M4 and Cortex-M0+), as well as to my other boards with Cortex-M7 chips at clocks from 280MHz to 450MHz. 

 

Looking good... I am still waiting for my Pico2 to arrive.. sadly no tracking from UK to Canada, but it was shipped on August 12th, so hopefully it arrives soon and then I can start to look at designing something with it.

 

Since I have a bare PEB prototype board, most likely I will mount it on there and that will allow me to have full control over everything for testing code. Etc.

 

Going to be learning experience more for me at first as I never played directly before with the Pi chips so it's all noobie technology to me.

 

I am looking forward to seeing what you cook up with, that tiny version looks bad ass, maybe a new grommy2 design using it?

[speccery]

@Gary from OPA I thought mail delivery for me was slow... Hopefully you get the shipment soon enough.

The tiny version is indeed tiny. But for my next design with the RP2040 or RP23250A/B I want to create boards with the chips, not using the pico boards for instance. I have already built three boards with the RP2040 chip, and what I initially thought was pretty much an impossible and experimental build turned out just fine. The RP2350 chips are not yet available though, and I do feel the itch of making a few board designs, so I will see what I will end up using   

[Gary from OPA]

13 minutes ago, speccery said:

@Gary from OPA I thought mail delivery for me was slow... Hopefully you get the shipment soon enough.

The tiny version is indeed tiny. But for my next design with the RP2040 or RP23250A/B I want to create boards with the chips, not using the pico boards for instance. I have already built three boards with the RP2040 chip, and what I initially thought was pretty much an impossible and experimental build turned out just fine. The RP2350 chips are not yet available though, and I do feel the itch of making a few board designs, so I will see what I will end up using   

yes, using the default design is good for prototyping, but for final saleable product designing your own PCBoard to use the RP2040 or 2350 directly is best, like what @visrealm did in the end for his PICO9918.

[+5-11under]

1 hour ago, speccery said:

I have already built three boards with the RP2040 chip, and what I initially thought was pretty much an impossible and experimental build turned out just fine.

Did you do the assembly yourself? Any tips?

[visrealm]

4 hours ago, 5-11under said:

Did you do the assembly yourself? Any tips?

Can't speak for speccery, but I hand-assembled 9x pico9918 v0.4's and my tips would be to get a solder mask/stencil and use a hot plate (or perhaps an oven - haven't tried). Sometimes they still require some touching up with a soldering iron around the edges, but for the most part, they're reasonably well-behaved.

 

The most issues I had was with DHVQFN packages of the 7400-series logic chips:

 

They should be similar to soldering an RP2040, but they're smaller and I guess lighter, so had issues with some pads not having solid contact.

[speccery]

@visrealm I have the exact same process: use stencil and a hot plate. I got a bigger hot plate recently, the previous one only worked with low temperature solder paste. I use a cheap USB microscope to examine the results and do some rework if needed. Also magnifying glasses and bright lights   and enough solder paste   

 

By the way, are your Gerber files for the pico 9918 available? Great work with this board, it looks really good!

[visrealm]

1 hour ago, speccery said:

@visrealm I have the exact same process: use stencil and a hot plate. I got a bigger hot plate recently, the previous one only worked with low temperature solder paste. I use a cheap USB microscope to examine the results and do some rework if needed. Also magnifying glasses and bright lights   and enough solder paste   

 

By the way, are your Gerber files for the pico 9918 available? Great work with this board, it looks really good!

I'll likely release the v1.0 gerbers and docs in September. I'll PM you.

[JasonACT]

RP2350 Errata E9 - Pull-down lock-up

 

There's some interesting things going on in that thread, the moderator is saying it's a known issue...

Quote

Re: RP2350 Errata E9 - Pull-down lock-up

• Quote

Tue Aug 27, 2024 3:38 pm

We've known about this for a while, it's not "just been found", hence there being an detailed erratum in the datasheet. The change in the datasheet numbering of errata has nothing to do with it being found, the errata were misnumbered in the first datasheet.

AFAIK, it should not affect the ADCs at all in normal usage and the errata should cover all cases, but we will update if anyone find more scenarios in which the GPIO latch up. We are talking with the IP supplier about this, as you might expect.

But users are saying the issue goes further than the erratum suggests...

Quote

Re: RP2350 Errata E9 - Pull-down lock-up

• Quote

Tue Aug 27, 2024 3:58 pm

However, the Dhalbert report says that the pin is sourcing current even with the pull-down turned off, and needs to be pulled down vigorously to return to logic 0. If this is true then the BusPirate 'fix' wouldn't work.

Good discussion, thank you all for documenting this. I found E9 because the button on the Bus Pirate didn't pass the self test. Forever grateful to the contributor who pushed an updated button test that checks Low->High->Low, otherwise it would have slipped past. When I found it, touching it with my multimeter did indeed clear the pin (with pull-down enabled). Also, a 10K resistor bodged to ground also cleared the pin.

I opted for 100K external pull-downs on the IO pins based on the feedback from RPi, and tests **on the button pin**. There wasn't time to do much else and still make FCC/CE testing.

The final production hardware landed in my hands just a few days ago. I believe I can confirm what others have found: the IO pins, even without pull-down enabled, latch up. When we flip the bi-directional buffer to input to the RP2350 pin, then flip the buffer to be an output, the RP2350 pin sticks high. This results in no low state on an open collector bus, despite the 100K external R.

I'm noticing this when using the PIO and haven't confirmed it elsewhere yet. The PIO does reinit with pull-down enabled (I believe, I've seen it in multiple source comments), so I wonder if it is latching up during that process. Disabling pull-downs after PIO config doesn't seem to help (because it's already latched?). I am going to try some of the various fixes in E9 after PIO init. However, based on what you all have found, that might not do the trick.

We're concerned enough that we pulled the next batch back from assembly. It's been a long day of chasing this down and I need some time to think before poking it more. I will do some plain pin tests tomorrow to confirm what is reported here.

I'm following with great interest.

[Duewester]

Interesting. Apparently when dealing with the new Pico, it matters which compiler you use. I know VSCode is popular but when programming the 2350 m33 or RISC v cores it makes sense to consider an alternative.

 

[speccery]

20 hours ago, Duewester said:

Interesting. Apparently when dealing with the new Pico, it matters which compiler you use. I know VSCode is popular but when programming the 2350 m33 or RISC v cores it makes sense to consider an alternative.

 

Thanks for bringing this up. I already commented on this video series in the YT comments. The topics are interesting but quality of work leaves in my opinion much to be desired.

 

Perhaps I should say for background information that I spent 15+ years writing carefully optimized software, among them software video encoders and decoders for H.261, MPEG-2 and MPEG-4 part 2 standards. Also some audio codecs. I wrote the H.261 video decoder using the Pentium 60MHz when that was the fastest game in town (well actually the 66MHz version was faster but the price premium didn't justify the marginal performance improvement) and proceed from there to make MMX, SSE, etc versions. If there's something I learned at this time it is that when you compile something performance critical, you need to look at the compiled output assembler code and analyse it. This is to me super interesting, but that was completely missing from the video series. If you don't analyse it, you have no idea if the compiler was configured properly or if it produces code that "looks right". Back in the day I ended up writing the first versions of a lot of signal processing SIMD code in assembler, since the compilers did not do a good job back then. Hand written assembler was sometimes 10x faster, especially for MMX.

 

Visual Studio Code doesn't have much to do with code quality, it depends on the compilers installed on your system, as well as which compiler flags one enables. I guess what happened in the video was that he installed whatever default compilers came in some plugin for VS code, and it also seems he didn't check the compiler flags - there are a ton of them to play with. It takes time.

 

The video also omitted the DSP instructions which are available on the Cortex-M33. </end of rant>

[+FarmerPotato]

3 hours ago, speccery said:

Perhaps I should say for background information that I spent 15+ years writing carefully optimized software

Here, here! 
 

It seems a vanishing percentage of programmers, nay software engineers, maybe 0.5%, have knowledge of assembly language. 
 

The 4A put assembly into my toolbox. There aren't many "on ramps" these days. Outside of university courses. 
 

I haven't done production code like you have. But I dive into the compiler output.  Mostly when a weird crash is hidden under layers of runtime code, or to understand why code or data doesn't fit into L1 cache.
 

(NSTaggedPointer method dispatch, OMG.)  

[speccery]

@FarmerPotato incidentally it was the lack of assembler programming availability which made me leave the TI for a ZX Spectrum as a kid. Of course it would have been possible on the TI but very expensive, and I think they didn’t even import the disk drives back then. The ZX Spectrum was the machine I first learned machine programming on, and subsequently pretty much all the contemporary microprocessors of the time. At one time I acquired somehow a Dragon 32, probably when they were going out of business, and got the alldream assembler for it as a ROM cartridge. I really loved at the time programming that machine in 6809 assembly since the ROM assembler was great, the workflow was super fast and compared to the Z80 the 6809 just has great flexible and powerful addressing modes.

 

But back to your point, today assembler coding would be in the reach of everyone thanks to the great debuggers and tool chains. Like you mentioned, knowing how to work your view from a crash dump in assembly following stack traces is still very relevant. Often times software can also crash so that the standard tools are unable to decipher the stack frames, and especially then knowledge of assembly coding is very useful. I fixed many very hard to find bugs in the code using crash dumps from customers.

[visrealm]

They have arrived! More fun stuff to play with

 

[Gary from OPA]

30 minutes ago, visrealm said:

They have arrived! More fun stuff to play with

 

I wish someday my pi pico 2 would arrive which I ordered the day they were announced last month, but doubtful.

 

I have seen someone already using this pga2350 design for a new MSX cartridge thingy.

[visrealm]

4 hours ago, Gary from OPA said:

I wish someday my pi pico 2 would arrive which I ordered the day they were announced last month, but doubtful.

My pre-ordered Pi Pico 2's still haven't shipped. Estimated to ship (from Australia) tomorrow.

[Gary from OPA]

8 minutes ago, visrealm said:

My pre-ordered Pi Pico 2's still haven't shipped. Estimated to ship (from Australia) tomorrow.

I only grabbed the Pimoroni Pico Plus 2 as they were in stock and my shipment went out August 12th. So hopefully someday it will appear, sadly there no such thing as tracking between UK and Canada for some reason.

[RickyDean]

I did two orders, 1 from Sparkfun and 1 from Chicago Electric and they have stated, Sparkfun will get in stock in Oct, CE told me on the 30th, that they should get stock early next week, hopefully meaning this week.

[Duewester]

I feel special. I ordered Pico 2's and Pimoroni Pico Plus 2 on day of release and they both got here last Thursday. Across the big pond to SC, USA.

[RickyDean]

34 minutes ago, Duewester said:

I feel special. I ordered Pico 2's and Pimoroni Pico Plus 2 on day of release and they both got here last Thursday. Across the big pond to SC, USA.

Cool, I'll get my CE pico 2's tomorrow or Friday, their coming up from Florida to me.

[speccery]

I just received Pico 2 boards, ordered them about a week and a half ago. So now I have both the Pimoroni boards with 8M PSRAM as well as these regular Picos with no PSRAM. Now all I need is time to do something  

[Gary from OPA]

15 minutes ago, speccery said:

I just received Pico 2 boards, ordered them about a week and a half ago. So now I have both the Pimoroni boards with 8M PSRAM as well as these regular Picos with no PSRAM. Now all I need is time to do something  

Seems like everyone got them but me now.

 

And contacting Pimoroni store about it doesn't help as they don't reply back to my emails.

 

I guess my only option is to somehow do a charge back on my card before September 12th, if nothing appears, because by then it will be month since their last email saying it had now been shipped out to me.

Edited September 5 by Gary from OPA

[Gary from OPA]

At least they finally got back to my not arrived raspberry pi pico 2 stuff. Hopefully next week they will ship out replacements or issue me a refund if they don't arrive by then.

[RickyDean]

I got my Chicago Electric Pico 2's in today, 4 of them. Now to see what wonderful TI things can be done with them, by our wonderful Pico team. On a side note I got my I got my Tang 9k video adapter boards in today too. So I can now get my two Tang 9k's turned into video chips too.

[Gary from OPA]

13 minutes ago, RickyDean said:

On a side note I got my I got my Tang 9k video adapter boards in today too. So I can now get my two Tang 9k's turned into video chips too.

off-topic, but looks good. -- can you send me a PM about these, and tang 9k, what parts are needed and where I can order them from, as I might want to do the Tang 9k on the 99/22, since I got the f18a in one console, the avpc v9938 in another console, and pico9918 in my 3rd console, i should have a tang 9k running as well, for testing purposes of software, etc. -- it can do the 192k (or 128k v9958 right?)