Raspberry Pi Pico
Been busy and haven't had much of a chance to do more work with the pico, but managed to whip out a small PCB with KiCad and it seems to work just fine. For those interested in the files, you can have them here. If you decide to build it, let me know how it goes.
The Raspberry Pi Foundation came out with a new processor a couple of days ago and I picked up a couple of them to play with. These things are only $4 each and were not that hard to get. I ordered 5 from Sparkfun. It really didn't take that long to get their example code of blinking the LED up and running. Getting just my code to run took a few more hours.
I have a Pi 4 running on my desk with the experimental Raspian 64 os on it. I find it really stable and I use it for code development. I installed the Pico SDK on it. This machine runs headless so everything is done with command line. I just used the script provided and it installed everything in my normal user space. I just left it there.
I setup another directory in my normal code tree structures and played with enough to make it compile the blink code to start with.
The Pico boards come without header pins soldered in so I was a bit limited in how I could program the device. The simple way to get started is to unplug and re-plug in the USB while holding the BOOTSEL buttton. This causes the Pico to look like a thumb drive to the system. You only need to copy the blink.uf2 file over, sync, and unmount it. It is really simple, but a pain to keep plugging and unplugging the USB interface. After I get pins soldered in, I can use normal debugging modes. You can even use one Pico to program another.
I got the USB interface up and running without issue and it by default supports printf(). Took me a bit to get the clock system to do what I wanted, but I managed. the get_time() function returns a 64 bit integer that started at power up and is counting micro seconds. It would overflow in 500,000 years so I guess it will be fine. I also discovered that the printf function does not deal with 64 bit integers with %lu. I didn't try %llu so I should try that before I say it is broken.
On normal laptops and other full computer systems I have always run a speedt benchmark that I put together many years ago and have run it on just about everything. It is basically a matrix inversion speed test. Fill the matrix with random values and invert it. The RP2040 does have way more memory than other micros, but this does push the limit. I could only run the full test with single precision floats. The double precision was limited to 50x50. The early versions of the test were only in double, and there isn't a floating point processor on the RP2040. Still it could keep up with a 33Mhz 486 processor.
memory free 0 memory free 0 size of float = 4 size of int = 4 size of FP_TYPE = 4 size of pointer = 4 size of FP_TYPE * = 4 loop = 1000 sze= 40 0.137000 e= 7.0873647930e-06 sze= 50 0.266000 e= 2.3663043630e-05 sze= 60 0.460000 e= 8.4508210420e-06 sze= 70 0.730000 e= 1.4501157940e-05 sze= 80 1.091000 e= 4.1194259520e-05 sze= 90 1.554000 e= 4.8605724460e-05 sze= 100 2.131000 e= 2.8647481980e-05 memory free 0 memory free 0 size of float = 4 size of int = 4 size of FP_TYPE = 8 size of pointer = 4 size of FP_TYPE * = 4 loop = 1000 sze= 40 0.235000 e= 2.7311486220e-14 sze= 50 0.458000 e= 2.3647750260e-14
This machine does have dual cores, but I haven't attempted to run the other half yet, but I have only had the part for less than 48 hours.