RaspberryPi Pico support

[Peter Jakacki]

I looked at my code after my morning coffee and noticed I wasn't separating and mixing the colors correctly due to one tiny typo. Now that I've fixed that the skin tones are much better.

btw, this is not VGA, it is a 1.3" SPI bus LCD with 240x240 resolution - great for smooth hires fonts
@John Gay - and all I need is my x10 magnifier too :)

[Leonard Reinhart]

That looks very nice. Do you plan on sharing the code soon?

[Peter Jakacki]

all my tachyon code is bleeding edge live on Dropbox and every so often when it is stable i update sf and pcloud. look for the rp2040 forth folder.
I'm on my phone and don't have a link handy.

EDIT: Tachyon Dropbox folder

[John Gay]

So, if I'm reading your code correctly, Peter,
I should be able to copy SDFAT.FTH onto a stock mecrisp install and play around with it, right?
I just need to change the pin numbers for the SD Card reader to match where I connected my card reader.
And then I can make sure I can access a good SD Card. If MOUNT works, then everything below it should be good as well, right?
Work keeps getting in the way of me playing with your code as much as I'd like right now.

Cheers,

John Gay

[John Gay]

Just for a test, I tried opening my font file with WordPad instead of Notepad and tried copying several lines.
In Notepad, I can only copy 4-6 lines before the Pico starts missing characters.
So first I copied 4 lines from WordPad, and they copied correctly.
Then I tried 8 lines and they also copied correctly.
So then I tried 20 lines. The first 8 lines copied correctly, but the rest of the lines were missing random characters.
Each line is 56 characters. The copy operation includes a newline character at the end of each line because the Pico echoes an ok. at the end of each line.
I just retested with Notepad, and it seems to have the same 8 line limit?
But I also updated Mecrisp to 2.6.1 over the weekend.
Unfortunately, I cannot find anywhere to add and delays into PuTTY and I am not allowed to use any other terminal program as this is my work computer. So I am just testing what it going wrong with copy and paste on Windows10 and PuTTY.

At home I generally use Linux with CuteCom, a nice GUI-based terminal. It lets me choose a file directly to upload. And I can set a 1ms character delay and so far it can copy files larger than the Pico's RAM without problem.
The down side is I cannot copy just a few lines of code to CuteCom. For that I change to minicom instead. I haven't actually tried to copy large chunks of text over minicom at home yet. Since I do most of my poking here at work where I am sitting at a computer all day anyway.

Cheers,

John Gay

[Peter Jakacki]

I might move some of those individual files into a folder called "hacking" or something like that. The full up-to-date working version is integrated into RP2040.FTH (which I might also rename) and I just edit and copy and paste this file each time. The hacking files might not work properly with the current software nor will they be up-to-date.

The ST7789.FTH file is one of those prototypes that haven't been incorporated directly into the main file and perhaps I will leave it separate since it is a very device specific driver anyway. I will do the same with any substantial driver and keep them separate but the common essentials will be built into the core Tachyon extensions.

The trouble is that all this is meant to be temporary and I should be writing my Tachyon kernel etc but I keep getting sidetracked and playing 😄

There may be some tidying up of the play room to do.......

As for your terminal woes, I will check the serial coms this morning to see what can be done to improve pasting source code. At present I use minicom and never use character delays as that is way way too slow. But line delays depend upon the terminal detecting a CR, yet Mecrisp is peculiar because it wants LF terminated files and even makes the CR word output LF instead of CR etc.

But if we do a standard CR+LF line ending in our files then Mecrisp jumps two lines instead of one on every CR+LF and I find that annoying because it's dumb and I wish that everybody and everything just leave CR as CR and LF as LF and have none of this "translation" rot.

BTW, while I don't ever use character delays and I wasn't using any line delays before either, I have made the line delays 5ms now that the main RP2040.FTH has grown and probably has lots of numbers which slow down Forth compilation and leads to coms buffer overflow. When I get my Tachyon kernel running it of course will not suffer this problem since it always handles numbers as numbers and only search the dictionary if it can't recognize it as a number.

In the meantime I might make the MECRISP source mode word enable a large secondary coms buffer. So all my large source code files start with MECRISP (in the case of Mecrisp) to both differentiate the embedded target and also to invoke the source code load mode. The source code load mode is terminated by the END keyword and returns back to normal console echo and prompt etc.

.

[Leonard Reinhart]

Peter, I think you should work on getting Tachyon running native first, a nice package of tools for mecrisp second, and just with what I have downloaded to play with and checking in on Tachyon I am feeling quite good. I am finding the bit bashed versions informative and am eager to see how fast it runs when it is compiled as it is stored.

I use Geany and TeraTerm and no character delays, but line delays that Peter recommended of 35ms. This is on a Windows 10 pro system. Before the pictures I didn't need a line delay.

[Peter Jakacki]

I have done some tests and found that when I paste source into minicom that it paces characters about one per 200us. However when I use my send script using ascii-xfr then there is no pacing and there are errors. So I dropped the baud rate down and found 38400 the highest baud rate that Mecrisp can handle source code without any delays or pacing. Now I am looking at Mecrisp sources to see if I can patch that into the kernel itself.

In the meantime I made my INIT set the baud to 38400 after flushing the receive buffers and then tried sending ST7789.FTH without any kind of delay or pacing. This worked despite the large font tables and everything. So far, so good.

So by going at a slower baud we can skip all those delays and then it only takes seconds to load source.

[John Gay]

I tried just copying SDFAT.FTH, but I found it failed for several missing words.
I tried copying those words from RP2040.FTH, only to find they relied on other missing words.
Got about 10 levels deep when I realized I'd just be better off using RP2040.FTH directly.

So now I need to swap out my Pico with the Pimoroni 2.0 display for my Maker Pi RP2040 robot with the SD Card, servo, range sensor and motors and see what I can figure out.
Obviously I'll need to move the comment block between MAKER PI PICO and MAKER PI RP2040
as well as update the SD Card pinout for my setup.
One thing I'm interested in is monitoring the Lipo battery. I believe it's on ADC3. See Page one of the schematic https://drive.google.com/file/d/1Zp8GYO8x7ThObB1G8RIZx2YdqrXtdUc0/view

So now I guess I need to start figuring out your Tachyon language just as I'm getting used to Mecrisp Forth.

Cheers,

John Gay

[Peter Jakacki]

Hi John,
Yes, as mentioned, the SD FAT32 layer is integrated into RP2040 and I will clean up my old hacking files into another folder.

The A/D words are there including converting to mV and there is .VSYS which reads A/D channel 3, scales it, and prints the result, but of course you can see that in the startup prompt, so it is already done.

I also have also hacked the Mecrisp uf2 file directly to change the default baud rate to 38400 since I have found that Mecrisp keeps up with loading large source files without the need for character delays, and only a 15ms line delay. This works even with ascii-xfr which transmits the file without any gaps between characters.

BTW, the procedure to load RP2040.FTH on a clean Mecrisp uf2 load is this:
1) Backup the Mecrisp kernel in case we need to do a clean start 1 SAVE#
2) Set terminal to 15ms line delay and 0 character delay (if you use the Tachyon/RP2040/UF2/mecrisp-2.6.1-38400bd.uf2 file that is)
3. after RP2040 has loaded successfully type SAVE and reset (or ^C)

[John Gay]

Testing RP2040.FTH on my Maker Pi RP2040:
I made the following changes to suit my set-up:

    ( MAKER PI RP2040 )
\ uncomment the Maker Pi RP2040 setup
18  constant NEOPIXEL
8   constant M1A
9   constant M1B
20  constant BTN1
21  constant BTN2
22  constant BUZZER


    ( MAKER PI PICO )
{ comment out the Maker Pi Pico setup
28 constant NEOPIXEL
25 constant PICOLED
23 constant PS      \ Pico pwm/pfm regulaotr mode
18 constant BUZZER
18 constant LA
19 constant RA
20 constant SW20
21 constant SW21
22 constant SW22
}
 ( microSD SPI mode )
\ Change the SD Pins
2 constant SDCK \ SD CLK
3 constant SDDI \ SD MOSI
4 constant SDDO \ SD MISO
5 constant SDCS \ SD CS

Yet, for some reason, This code:

0 variable ~sdpins

pub SDCK    ~sdpins C@ ;
pub SDDI    ~sdpins 1+ C@ ;
pub SDDO    ~sdpins 2+ C@ ;
pub SDCS    ~sdpins 3 + C@ ;

Redefines the pins to 10,11,12 and 15?
so
0 0 cmd .
returns 0 and dir prints a screen full of garbage. and turns on pin 11, which is connected M2B?

I also found it a little difficult copying the code after Tachyon started hiding the word definitions so I couldn't be sure if the words were being properly defined. There were a few words that failed and I had to try to re-paste them fewer lines at a time to get then correct.
It seems once the buffer overflows, that it gets much shorter and overflows quicker from that point on. Some lines had to be copied over a single line at a time to prevent dropped characters.
I also learned the hard way that using CNTR-C resets mecrisp if I forget to highlight the Notepad window before copying a block of text. But reset and learn.

Cheers,

John Gay

[Leonard Reinhart]

Hi John, near the end there is a definition for INIT

~

INIT
\ UART0 ~baud @ BAUD
bold yellow pen TACHYON CR
blue pen
!PICO !FAULT DATA $400 ERASE !POLLS
--- abort if GP22 low
22 PIN@ 0EXIT
\ $20 RED!
( $A4 i2cdev C! )
5 4 I2CPINS ?RTC
$0F0C0B0A SDPINS SD? IF PRINT" MOUNTING " MOUNT CR THEN
BEEP 3 PICOLED FLASHES
\ $20 GREEN!
.PICO
plain
['] uquery ~query !
['] TACHYON QUIT!
;
~
About 2/3 down is $0F0C0B0A SDPINS SD? IF PRINT" MOUNTING " MOUNT CR THEN
$0F0C0B0A is 15121110 and SDPINS pops that off the stack and assigns that to ~sdpins which peels a character at a time from it and assigns the pin names to them.

That is about the third time I have read and rewritten the above sentence.

[John Gay]

Wow! That is Obscure 0-8
And yet I think INIT failed when I copied it due to some previous definition failing.
But that does seem to make sense in a weird way.
So I'll update that line to $05040302 and see if that corrects it.
I also want to add M2A and M2B as well for my Maker board.
Unfortunately, it's the end of my work day here, so I'll poke some more tomorrow.

Cheers,

John Gay

[Peter Jakacki]

listen up John, let's make this easy for you.
Install the hacked uf2 file that starts up at 38.4kb as that is the one that works without any character delays (zero), only needs a line delay up to 15ms.

Fire it up and now just send/paste the RP2040.FTH file with those delays and it will load perfectly.
If it looks good then type SAVE and reset or ^C.

If you do that and operate at 38.4kb then life will be easier.

EDIT: The INIT file is the place which is meant to be customized otherwise if you change it elsewhere, then you have to do it all over again when I update the source, which I do almost daily. So just specify your pins in INIT.

[John Gay]

Peter, you misunderstand my serial port woes.
The problem is being stuck with a crippled Windows10 and PuTTY for serial port access here at work. They even disable saving files to USB on these work machines for misguided security concerns.
At home I run Linux and it's not an issue at all. It's just that my wife thinks there are much more important things for me to do at home than poke at my computer projects.
Whereas here at work, I'm at the screen for 8 hours, but not always doing work-related stuff.

Also, although I do like your Tachyon project, I'm only just learning Forth since starting to poke at the Pi Pico board. So I would like to work my way up to getting SD Card and other things working.
Of course SDFAT is quite a huge beast all together. But the way to eat an elephant is one byte at a time.

So I'll keep poking with your code. I don't want to slow down mecrisp for my little corner case of stupid Windows serial problems.
But thank you for all your input and replies. I really do learn something new from everyone's comments and code contributions.

Cheers,

John Gay

[Maciek]

John, on the topic of "They even disable saving files to USB on these work machines for misguided security concerns." I hear that said all the time but ...having a company policy on allowed software (PuTTY in that case) and control over what data and how it can be transferred in or out of the company network are actually good practices. These are the basics but just having them in place is not enough. They need to be adequate and only then it makes sense to even have them implemented in the first place. Otherwise you might be right in describing them as "'misguided". The worst thing is to have "something" that actually doesn't work right but gives a false impression the company is "protected". I could tell stories here but this is a mecrisp forum. I feel your pain too as a user but I'm also on the other side of that in my daily job. That's why no forth fun for me at work so consider yourself lucky.

[Pete Foden]

Apologies if this is the wrong place to post this enquiry.
I have installed Mecrisp (plus RP2040.FTH) on a Maker Pi PICO board.
Thank you Matthias and Peter, the combination runs really well together. All the onboard interfaces are working: SD card, sound and Neopixel.

If I connect a DS3231 RTC it is detected and works fine, however if I try connecting any other I2C sensors (e.g. CCS811) the sensor address is intermittently recognised using lsi2c but other addresses pop up too:

R00# lsi2c ---  $B4
R00#  ---  $B4
R00#  ---  $B4
R00#  ---  $B4 $B6
R00#  ---  $B4
R00#  ---  $B4
R00#  ---  $B4 $B6
R00#  ---  $B4 $B6
R00#  ---  $B4

When I try an I2C program that works in Taqoz (modded for Mecrisp/RP) I get random data values back when reading the sensor. Since the RTC works perfectly, I suspect I have a problem initialising the I2C bus properly. I have checked that I have the right pins (SDA-4, SCL-5), use !I2C to initialise the bus and also have pull-up resistors (5k) to 3v3.

Is there something that I have missed?
Cheers
Pete

[Peter Jakacki]

Hi Pete, it may just be my timing when I read back the ack, I may need to validated a bit better perhaps. I have seem this happen when I have connected the DS3231 btw, so I should fix it

I have just checked my board with a RV-3028 plus EFM8UB3 micro on the bus where the clock and data is shared with my SPI LCD and there are no glitches, so it may be something to do with the DS3231. The ones I have tested are fake ebay chips but I do have some genuine chips in soic8 from Mouser I can test.

R00# lsi2c ---  $36 $A4
R00# .FDT --- 2021/11/22 MON 11:00:04

[Pete Foden]

Hi Peter,
I finally looked at the I2C wave forms from the CCS811 chip on the scope - hopefully attached.

Something happens at the end of the I2C! write after the ninth clock pulse, which I assume is the clock stretching effect. The I2C device is holding down the SCL line whilst the master is clocking the SCL line.

I tried to put in some code to detect when SCL went high again but that didn't work.
I redefined I2C with a 100 uS delay at the end and that sort of works, with fewer errors, but not 100%.
Pete

[Peter Jakacki]

Thanks for looking at that Pete, I added a simple ?SCL function before a transfer to float the SCL and wait until it goes high or timeout after 200us. The SCL drive has been changed to a pulse high and immediately float method. This helps drive capacitance and still allow for clock arbitration.

pri ?SCL        cycles BEGIN cycles OVER - ABS 200 > *SCL PIN@ OR UNTIL DROP ;

So ?SCL just gets added to the start of I2CPUT and I2CGET and should work. Perhaps you can grab the Dropbox version and check it first before I release it on SF. I've checked it with my I2C devices but I will have to scour the parts drawer to see if I have an I2C part that requires clock stretching.

[Pete Foden]

Hi Peter, many thanks for getting back to me, I'll test again this morning and report back with the results. Cheers, Pete.

[Matthias Urlichs]

On 29.11.21 03:09, Peter Jakacki wrote:

I added a simple ?SCL function before a transfer to float the SCL and wait until it goes high or timeout after 200us.
So what happens if the clock stretch is longer than that? You just
continue blindly? Why?
The SCL drive has been changed to a pulse high and immediately float method.
This helps drive capacitance and still allow for clock arbitration.

IMHO, driving any wire in both directions simultaneously is not a good
idea. Like, ever.

If your capacitance is too high, lower the bus speed. If that doesn't
work (too slow), use smaller pull-up resistors. If that doesn't work
either (pulldown drivers too weak), use dedicated I²C speed-up hardware;
there are multiple solutions. LTC4311 or P82B715 for instance.

Adafruit sells a small breakout board for the LTC;
https://www.adafruit.com/product/4756 links to a cute demo video.

--
-- Matthias Urlichs

[Peter Jakacki]

A high current pulse before floating up to the pull-up is actually something that I2C hardware does internally. CMOS is very forgiving and as you can see from Pete's scope capture the clock is trying to drive low while the Pico is driving it high, so it ends up half-way. I didn't need to pulse it high but doing so makes sense and costs nothing.

The I2C bus is very simple, no need to complicate it especially in this application.

[Pete Foden]

Hi Peter and Matthias,
Sorry about the delay getting back to you, had to do some snow shovel work today.
After some trouble re-loading RP2040.FTH (kept getting flash full/stack full errors) just reloaded Mecrisp then RP2040.FTH and looked at the I2C wave forms on the scope.

Sorry to say I couldn't get the version with ?SCL to run with the CCS811. There is always a 200 uS gap between groups of bytes and reading any registers returns $FF.

Strangely, if I re-define I2C! with an extra 200 uS delay or put ?SCL at the end of I2CPUT instead of the beginning , it sort of works again but can only read some registers correctly. This leads me to thinking that perhaps we should be checking for the slave device holding the SCL line down after the 9th clock pulse not before?

Cheers Pete

[Matthias Urlichs]

On 29.11.21 21:33, Pete Foden wrote:

This leads me to thinking that perhaps we should be checking for the slave device holding the SCL line down after the 9th clock pulse not before?

Why would it matter which SCL pulse the slave holds down? You simply
wait for SCL to become high after you release it.

Which clock pulse that happens to be is of no regard, as a slave is
allowed to hold onto SCL whenever it needs to do so.

--
-- Matthias Urlichs