Oof, it’s been a long night here, sitting in front of this shiny new Pico DV base I got in the mail today. Running HDMI video on my Pi Pico? Yeah, that sounded pretty amazing. As soon as I opened the package, I went looking for some demo code to set up and flash over to the Pico.
While there is a basic link on the Pico DV page to what seems like an AV player, in fact it’s just part of a fork that has yet to be rolled into the main PicoDVI branch, so cloning with git doesn’t pull down the part of the repository that actually contains the files needed to build as shown on the page linked from the Pico DV product page.
After finally realizing that, I was able to pull and build the uf2 file for the raw_av_player, and then…nothing. Flashed the Pico, encoded my video and audio as shown, connected my monitor, and…nothing. Build was successful, flash was successful, followed all the instructions, and nothing.
So, went back to the main PicoDVI repository and tried each of the “main” examples just to see if I could get something-- anything-- to work. None of them work. They all build correctly, they all flash correctly, and nothing shows up on my monitor.
I realize the Pico DV is a “new” product, but it seems to have been tossed over the wall with precious little in the way of help for customers to get something up and running.
Honestly, I don’t know what more to say at this point other than “HELP”. Quite disappointed in this purchase, as I expected more in the way of ready-to-use demos and examples.
@robbok: My sentiments exactly . . . I totally concur with you, as I too have had a similar experience with a lot of frustration trying to get the Pimoroni Pico DV Demo Base up and running. I’m really disappointed with the quality of user documentation and demo software supplied by Pimoroni for this product - as you say it appears that this design had been “tossed over the wall”.
I was able to write and flash some code of my own that monitors the three ‘user switches’ on the DV base to at least prove that the Pico was functioning properly. Could you please post step-by-step info on how exactly you were able to “pull and build the uf2 file for the raw_av_player”? Thanks
@Pimoroni Support: This product is not the cheapest, so could you please respond and provide full user documentation and demo software for the Pico DV Demo Base which has been reviewed for clarity, completeness and accuracy. Thank you.
The step-by-step instructions are on the pull-request, however I realized a couple of omissions from these in an email exchange and they’ve been updated recently-ish and tested again. I’ve also added the correct command to git-clone the code.
Of note to @robblok will be: -DDVI_DEFAULT_SERIAL_CONFIG=pimoroni_demo_hdmi_cfg - ie: the code supports multiple boards and needs to be told which board config to use. I missed this from the details in the PR!
This board uses third party software (that we don’t maintain nor fully understand), so it’s rather difficult to support up to our usual high standard. I don’t think that should exclude us from making and selling it, though! I’ve requested the store page be updated to better reflect this.
I’ve also added a note about HDMI timings, since these need to be supported by your display and may need changing accordingly.
Thanks for the update. I appreciate it, and after spending time with it this weekend, realized the board supported was not correct. Here’s the thing: it seems Pimoroni (and far too many others in the industry) assume everyone is using Linux, or MacOS. Many of us are using Windows. I’m building on Windows using Cmake and MinGW to build, which works great for all of the other examples, but I can’t pass command-line arguments to the build system. So I don’t think I have the ability to pass that DDVI_DEFAULT_SERIAL_CONFIG parameter. Any chance you could let us comment/un-comment it directly in the code so no build-time parameters need to be passed?
Also, since we’re all just building for the same board, can you please also include a fully-compiled .uf2 file in the repository, so we can just run a quick test without needing to compile? I know things like the movie filename will change, but we can just use whatever is hard-coded into the .uf2 for a test, just to make sure things are working. It would help a lot.
I still can’t get the raw_av_player to build, because it assumes it was cloned into a very specific filesystem hierarchy, without mentioning exactly what that hierarchy needs to be. So my compiles keep failing when trying to find a hard-coded path to the i2s audio library. After spending 4+ hours with this yesterday, I put it all in a box again and had to walk away. Last month I ordered more than $200 in parts and boards from Pimoroni, all to work with the Pi Pico, and to date either none of them work (Audio Pack, etc.) or if they work, the demos provided are so basic as to be useless (Display Pack). Everything is sitting in the same box, unused. It was a huge waste of money, in the end.
You should install and use WSL (Windows Subsystem for Linux)
It’s not so much that we assume everyone is using Linux or macOS, but that trying to build any of this stuff using native-Windows or MinGW approaches is like pulling teeth and is utterly futile to try and support.
As you - rightfully - point out, guides, code examples, instructions and most resources around the Pico are very Linux centric. The existence of WSL, and just how broken the not-quite-native Windows environments can be means nobody is really incentivized to change this. In fact Microsoft have pretty much conceded the fight by creating and pushing WSL in the first place.
Getting to grip with the Linux way - which is inevitably what WSL is - will take a little time initially, but it’s going to save you from a whole world of frustration in the long term.
It looks like we could probably stand to have a “Setting up Raspberry Pi Pico SDK in WSL” guide, though, I’ll see if I can get that in motion.
Thanks, having a guide like that would be most helpful. And while I might agree with you about the Pi community historically inheriting from Linux, once Rpi moved into the 2040 platform, they are squarely in microcontroller territory, and that’s mostly Windows folks who grew up using the Arduino IDE on Windows. And that’s never going to change. My strong advice would be for Pimoroni and companies like it, who hope to make inroads with the Pico/2040-based ecosystem, to meet your customers where they live instead of tossing out “just install WSL”. I’ve done that, and I’ve taught myself Raspian as well, but I can promise you most other potential customers of yours won’t put up with the hassle.
@gadgetoid,
I’m using Linux (on the Pi) to do all my builds. I have cloned all the files as instructed and run the ‘cmake’ command and the build seems to successfully complete.
I have also FAT-32 formatted the SD card, converted the video and audio files and saved them to the SD card.
But when run the ‘make raw_av_player -j’ command, I get lots of errors, including Errors 1 & 2 . . . what do these errors mean?
I still do not know how to generate the .uf2 that will be used to flash the Pico. I have reviewed the instructions in the pull request as you previously suggested and I’m none the wiser. Could you please explain clearly and precisely how the .uf2 file for this particular application is generated . . . which command is supposed to do this?
It would be very helpful also, if you could as previously requested by @robbok upload please a fully compiled .uf2 “test file” to the repository.
Thank you.
I’ve just published a basic guide on getting going with the Pico SDK and WSL - posting it here in case it assists folks who are stuck - Pico C/C++ Development Using Windows
I used this setup to run through @gadgetoid 's instructions for the DV Demo example and it worked OK for me, changing dvi_timing_800x480p_60hz to dvi_timing_640x480p_60hz as suggested. I got video output on one of our 8" screens and on a big 4k monitor.
@Blackbeard - it sounds like something is going awry in your build process if you’re getting a lot of errors - do you have all the required repos cloned into directories that are side by side? If you’re new to working with the Pico SDK/toolchain then building the official Raspberry Pi examples first to familiarise yourself with the build process is probably a good idea - lots of details on how to do that from a Pi in the Getting Started guide.
I’ve had mixed results with the examples, particularly AV player example. All uf2 examples built using WSL as instructed, and builds apparently successful.
In Windows (10) Explorer I’m dropping ‘raw_av_player.uf2’ onto my RPI-RPI2 device. I am getting HDMI output, but it’s only a white screen
For video/audio sample:
Encoded using ffmpeg with ffmpeg command provided in repo
FAT32 formatted SD card (tried two different ones (1gb/8gb))
dropped ‘rickastley.pcm’ and ‘rickastley.rgb’ on sd card and inserted
Help appreciated!
Observations for others trying to get this working:
Ensuring sub modules for each repo are activated will contribute to successful build process
(go into relevant repo, run ‘sudo git submodule update --init’)
I managed to get HDMI output from the board by changing the line: ‘#define DVI_TIMING dvi_timing_800x480p_60hz’ to ‘dvi_timing_640x480p_60hz’ in ‘main.cpp’ and recompiling. AV example doesnt work though, among others
Ok so an update - I managed to get it to play Big Buck Bunny (video but no audio). Not sure why the audio isn’t working as I followed the example to the letter.
One thing I noticed: the SD card still reads even though I have cut the traces on the board between GP21 + SDD2 and GP20 + SDD1. I’ve soldered headers over the top but the pins aren’t shorted.
I am trying to install the toolchain on macOS - getting stuck because Apple doesn’t like installing the arm compiler directly. I am on OS Big Sur (old iMac) and can’t download Xcode command tools… Seems like this nice idea is just impossible. Arduino IDE supports RP2040 but can’t get VSCode setup… Any help?
I don’t have much macOS experience, but you may have more luck in a VirtualBox virtual machine running Linux. It may even work with USB, assuming you need a USB connection to the board.
It would certainly nice to have seamless Mac and Windows support, but I would guess that the dev teams that create this stuff would be Linux-native, and thus that will be the best supported platform.