RaspberryPi Pico support
Brought to you by:
m-atthias
Menu
▾
▴
Peter, I gave that Pico display code to John to help get him going on the Pico. A lot of it is code from Mecrisp like the h><, and h>< words (only the h>< word is used) - I suspect the $FF00 was there in case there was a value greater than a 16-bit word on the stack (in which case it would not give the correct swap of the lower 16-bits) but in my use it shouldn't be necessary. The spi busy flag is also a good check to avoid odd behaviors in some chips but might not be needed here. I will check that when I get time. Overall, I find it a rather fast display driver for the 7789 LCDs.
I found Jerry’s code was great (It worked) there was some subtleties that escaped me like switching between eight bit and sixteen bit. I am missing something on the I2C and have taken an extended vacation from it hoping it gets better when I get back to it, I’m even thinking of using the PIO for I2C as there is an implementation in their examples and see what I can learn there.
What I would like to see is at least a working implementation of each of the features. The Real Time Clock doesn’t work right because I don’t know how to assign the crystal oscillator to it and after trying a number of approaches it still is hot happening. The clock dividers are not large enough to bring down the system clock. Maxed out it is still about three times too fast.
I am also disappointed in the lack of usable memory on this thing. Maybe a file system on a SD card or a USB memory would help, I picked up a board from Cytron that has a SD card holder on it to try out.
Liking small things, the little Linux Quantum board, sold by Seeed Studio, caught my eye and I just finished a design for a box to include a fan (it runs hot) that I printed with my resin printer. I don’t know how useful it will actually be, but it sure is cute. Also there was a OpenCV demo on the Quantum board so I picked up a Udamy course on image processing with python, and OpenCV using Anaconda that was only about $12, you can’t even buy a good book on the subject for that. I have also been working on a Balsa wood Radio Control model of an A-1 Skyraider from some plans I picked up. My father was a Naval Aviator and it was one of many airplanes he flew. It is about 75% done, but at a state where I don’t need to spend a lot of time on each of the items to finish it up.
Anyway I hope to be back working on the I2C soon, and if someone else gets a version working before that I would not be disappointed. I’ll publish what I have done and the C programs I have been looking at to see how it works in the next few days.
There is a new version of the datasheet out and I want to see if there is anything changed that might explain the problems I have been dealing with. Most likely they are between my ears.
Last edit: Leonard Reinhart 2021-10-15
Jerry,
Thank you immensely for that code. I'd still be bashing my head against this display without it!
I'm just trying to wrap my head around the code in a way that makes sense to me. That was why I re-wrote most of the graphic primitives.
As for the lack of memory, that is hugely down to the Flash being so slow, that they copy the entire Forth into RAM instead. If we could get the Forth to run from Flash, that would free up all the RAM. But I have no idea what the problem is. And people much smarter at programming Forth seem to be puzzled by it, too. So I wouldn't even know where to begin to look into that.
And thanks, Leonard, for mentioning Balsa wood models. I have a very vague recollection of a Balsa wood model Fokker DR1 from my childhood, so I recently bought and built one. When I mentioned this to my brother, who's 9 years older than me, he said that was his model he built before I was born and he was certain he destroyed it before I was 2?
More recently I found detailed plans of the Hindenburg, so I have built the frames and stringers from 1/16th balsa but haven't gotten around to putting the tissue on it yet. At 4 foot long, it's quite daunting and I haven't figured out just how I want to paper it yet.
So I guess I'm not the only one easily distracted from the many, many projects I'm currently working on by new projects to start. Someday I'll get over my Completion Anxiety Disorder. But not today.
Cheers,
How much more SRAM do you need for what? Maybe can make that available for easy use with a <10 line patch.
Sorry. It's not that I have any particular need to more SRAM. I just know that there is some issue trying to get Mecrisp to run from the Flash.
I was commenting on a CircuitPython site about how Forth can run from only 24K of Memory whereas their CircuitPython needed 256K just for CircuitPython before even allowing for user programs.
But I am not a real programmer, I just like playing one on my Pico!
And for that I am extremely grateful for this amazing version of Forth I have on 3 different Picos I love to play with! And soon I hope to load it onto my Maker Pi RP2040 Robot controller board as well!
Cheers,
Forth can actually run from much smaller than 24K of memory and from the flash too, and sometimes even faster than from RAM. Just not on ARM. Check this out and see for yourself :). Or the original Mecrisp for the MSP430 for instance and many more too.
But this was a digression as it's a Pico thread. Sorry for that.
Last edit: Maciek 2021-10-15
I know.
I have actually played with a 6k CamelFORTH on a Z-80 board I also own.
I love the idea of running so close to the silicon because it reminds me of when I had my Original TRaSh-80 and TS-1000.
Jan, I love the Pico version that Matthias gave me with the 128K split for flash but I would really love even more - say 192K flash image that then gets loaded into ram on boot-up - if that is possible.
Leonard, I finally got the I2C working on the Pico after a huge amount of work over the last month. It is still not all that polished and not a nice general use package - I usually have to re-write some words for each new application - but it works. I was hoping to make it more generalized but I'll try to put together a useful version and publish it here soon.
A first ambitious attempt was pared down to just get something working but
when I attempted to transmit, the byte would never leave the buffer. From
what I could read this is the behavior when there is nothing on the bus, or
nothing answering. After that time was spent troubleshooting the hardware
then I got distracted.
Just from looking at three different 12C devices it looks to me like
everything but the very bottom hard ware interface will have to be custom.
From what I can gather, fast mode at 400KHz would work for most devices. I
had planned on a "write" with a length and pointer to the data buffer on the
stack, a "read" with a pointer to a buffer on the stack and A scanner that
tells us what is on the bus to tell that the device is at least
communicating and where it was thought to be in the addressing. I started on
one of those. If you have I2C basically working that would be enough for me
to get the rest done for the two sensors and a display that I was going to
do as examples. I'd do the scanner first. One of the sensors is really three
on a board which should be interesting.
Last edit: Leonard Reinhart 2021-10-17
I don't know if I'm missing something, but I thought when a constant was defined, each use of that constant would fetch the most recent declaration of that constant.
But the mandelbrot program I am using has a few constants declared and I am finding that if I change the constant, I also need to re-define each work that uses that constant?
In other words, it's as if the use of the constant in a word definition inserts that constant value, rather then fetching the constant when that word is executed?
Running from flash is a bit harder on the RP2040 than on almost every other chip. The RP2040 doesn't include internal flash. Instead it includes a 16 kiB BootROM mapped to 0x0000_0000. On reset both cores start from that ROM. The boot code detects which core it's running on and puts the second core into deep sleep. The first core continues by looking if the watchdog registers indicate a that it should perform a warm boot otherwise it continues with the cold boot. Next it configures the QSPI peripheral for maximum compatibility (slow, 1 bit mode, simple 0x03 reads) with all possible SPI polarity and phase combinations. For each combination the boot code attempts to read the first 256 bytes of the external flash. If a valid combination is detected (the CRC32 over the first 252 bytes matches the last 4 bytes) the bootcode executes this second bootloader stage. If no valid combination is detected the boot code falls through into the USB bootloader.
The the 252 byte second bootloader stage is free to execute whatever it wants, but 252 aren't much. The current Mecrisp Stellaris code calls into the BootROM to setup the QSPI peripheral in a slow fallback configuration (high prescaler, 1 bit per clock, etc.) and copies the kernel and flash dictionary to SRAM. Afterward execution from SRAM is fast, but a large chunk of the SRAM is already allocated to the kernel and flash dictionary.
This was my first port of Mecrisp Stellaris to a new chip. Matthias and I decided that this was a good tradeoff to get a working port released quickly. I still like that it avoids the runtime performance penalty of the slow external flash, but the RP2040 is a capable chip that can make better use its SRAM than throwing it away to keep the boot code simpler.
The new Zeptoforth port to the RP2040 released a few days ago includes a second stage bootloader that could be adapted to work with Mecrisp Stellaris. Creating a port treating the RP2040 like any other chip with a cached but slow code flash. This would leave most of the SRAM available for application code and data.
An other possible configuration would be to configure the QSPI controller for DMA instead of (and maybe even in addition to) the normal memory mapped configuration. Streaming through DMA to the SPI or PIO peripherals wouldn't require large buffers if the QSPI flash can keep up with the display.
Last edit: Jan Bramkamp 2021-10-15
Jan,
Thank you again for another excellent explanation of the difficulties of booting this particular chip.
Each time I read another description, I get a better understanding. Although I am still very far away from being able to contribute meaningfully to this. But thank you anyway. After all, I am still only just wrapping my head around coding in Forth in the first place. I just feel that Forth gives a much smaller and closer to the silicon environment than Python with it's 1/4M of type-checking, garbage-collecting and god knows what else it's doing in there!
I've actually read a few complete Forth source-codes in their entirety. In single files. One was actually a bash script that created c source-code and then compiled itself into a Linux Executable Forth interpreter!
I don't even want to think how many files it takes to describe CircuitPython on the RP2040???
Especially considering they claim to include EVERY hardware driver you might want???
It trying to figure out how to control my Nokia display and my Pimoroni display I needed to dig into those driver source files and that became an endless rabbit hole itself.
So thank you again for such a great Forth for me to play with!
Cheers,
Leonard (and others), here is my I2C driver; the scanner (scan word) seems to work fine so try that first. You can see it in action from the video I recently posted in the Forth for the 21st Century group about the Pico Teaching board and the other one about the Featherwing Keyboard.
The Pico documentation was rather sketchy on this interface but I am happy to have it working. There is still a lot of work to be done but this allows me to talk to many devices that I need to, however ugly!
Jerry, Thank you for the driver, I can see some differences between it and
what I had done, the biggest was that somehow I badly miscalculated the
pulse up and down time needed for a 400KHz frequency, but the reason for
this note: I noticed both i2c0 and i2c1 are in to about the halfway point
then it is i2c0 for the rest. Do you think both would be in use for an
implementation or just one of the two? In either case as very little can be
shared, would it be better to have a separate implementation for each? The
approach I am taking is not assuming the huge set of constant declarations
are loaded so it will be a standalone, load it and run. For those who have
the declarations already loaded they can just lop off the ones at the
beginning; they will be clearly delineated. I am concerned with the small
amount of memory we have available and many of the declarations in that huge
set of constants will never be used and just eat up valuable memory. When I
set mine up the declarations were I2C0_ENABLE instead of I2C0_IC_ENABLE. I
changed mine to match, but, worrying about memory again, the shorter version
has it's merit. Neither can you search on in the datasheet, I found it odd
the authors did not take the unique addressing into account for the two in
their naming convention.
Last edit: Leonard Reinhart 2021-10-17
I'm just saying that you can not only borrow that code, but you can also improve it. For starters, just try dummying out the busy checks and see if it still operates etc. RTM to find out more if it does need some kind of a busy check, and maybe it is for one special case.
Hack, tack, and give back.
I know. But first I need to figure out what each part does so I can experiment intelligently.
For instance, the graphics primitives are mostly my work, or borrowed from the mecrisp sources.
But from what I see, a lot of the initialization code is spread out with quite a number of other words scattered around. So I want to clean that up as well.
But I also have a serious case of Completion Anxiety Disorder. So I tend to see something I want to fix, and then avoid fixing it just because???
Hopefully I'll get back to cleaning up this code more. After all, I started this because I seem to be getting a better handle on Forth coding than I ever did for BASIC or c/c++
However, right now speed isn't my main problem.
Cheers,
WOW! Impressive!
I learned Forth in the early 1980's when I found the Rockwell 65F11. This chip was based on the 6502 and was the Pico of it's day as it ran an embedded RSC-Forth (Rockwell) with lots of I/O. You just added some ram and a serial interface and you were away! RSC had inline assembler and interrupts. I still have Brodie's excellent Forth books - the best way to start Forth IMHO. I still have the RSC User Manual and some processor boards which were made by Essex Electronics.
Until I came across Mecrisp I was using Circuitpython on the Pico. It was an easy choice as I use Python on many platforms for my systems. I just installed mecrisp-stellaris-2.5.9a Forth on a Pico and it took me right back to why I have always loved Forth. I need to get my head around how I create a deliverable system on the Pico and I need to sort out interrupt handling for external hardware events. Once I have come back up to speed I will contribute whenever I can. My weird brain loves RPN which is why always had Forth as my favourite language.
Huh. I dimly remember playing with a board based on that chip. It's too bad IMHO that it didn't catch on and we got the Arduino mess instead …
The 65F11 was popular in embedded back in the day. I built hardware using it for a autonomous underwater ship/sub monitoring drone project in the 1980's.
Jerry, You mentioned the Forth for the 21st Century group about the Pico
Teaching board and the other one about the Featherwing Keyboard and videos you posted. I searched for this and came up dry, could you post a link?
Leonard,
I doubt if you would often need support for I2C0 and I2C1 in the same application. I usually just include the one I need in a build. I use the standard (rather wordy) SVD names for the various constants for better compatibility.'
The videos I mentioned are posted in the 'FORTH PROGRAMMING LANGUAGE 21st CENTURY' group and one is also in the 'Forth2020 Users-Group' but I can't seem to make links to them. Let me know if you still can't find them and I'll try to put links here.
Yet another private group to which to gain access you need a facebook account. The same goes for the FORTH2020 group and both groups aim to promote Forth. I do not get the slightest idea how do they intend to succeed.
If I were of an evil mind, I'd say that they don't.
Facebook is really great for in-groups whose members have a psychological need to convince themselves that they have superior knowledge, skillz, or whatever.
But as I am not evil ahem I'll just continue to ignore them.
When Fakebook first started I joined for about a week then unjoined because
I figured out the only way for them to make money was to sell users
information.
Last edit: Leonard Reinhart 2021-10-17