Can't build with sdcard support

[eh]

Now that things seem to be working on my Pico2W I'm trying to make the examples available. I'm running into this when trying to build with sdcard support:

$ TARGET=pico2 BLOCKDEV=sdflash FS=fatfs make flash
tinygo flash -tags=fatfs,sdflash -target=pico2 -serial=uart -scheduler=tasks
# mattwach/rpngo/drivers/tinygo/tinyfs
../../../drivers/tinygo/tinyfs/sdflash.go:18:9: cannot use sd (variable of struct type sdcard.Device) as "tinygo.org/x/tinyfs".BlockDevice value in return statement: sdcard.Device does not implement "tinygo.org/x/tinyfs".BlockDevice (method EraseBlockSize has pointer receiver)
../../../drivers/tinygo/tinyfs/sdflash.go:18:13: undefined: err
make: *** [Makefile:9: flash] Error 1
$ TARGET=pico2 BLOCKDEV=sdflash FS=littlefs make flash
tinygo flash -tags=littlefs,sdflash -target=pico2 -serial=uart -scheduler=tasks
# mattwach/rpngo/drivers/tinygo/tinyfs
../../../drivers/tinygo/tinyfs/sdflash.go:18:9: cannot use sd (variable of struct type sdcard.Device) as "tinygo.org/x/tinyfs".BlockDevice value in return statement: sdcard.Device does not implement "tinygo.org/x/tinyfs".BlockDevice (method EraseBlockSize has pointer receiver)
../../../drivers/tinygo/tinyfs/sdflash.go:18:13: undefined: err
make: *** [Makefile:9: flash] Error 1

[mattwach]

A code regression. I just submitted the fix so it will compile. I think I had a little trouble with SDcard reliability but t's been a while since I tried.

[eh]

Do your releases support sdcards? I'm at a bit of a loss here. fatfs doesn't seem to work, and that's supported by an open TinyGo issue. I can't get a littlefs build to recognize any sdcard I try, down to legit 128MB cards. I'm clearing them and creating only an msdos partition table. It's possible I'm missing a step there. XMODEM transfers aren't working with either screen/sx (lrzsx) or minicom. Not sure how to get code onto it. If I write anything on the PicoCalc itself it doesn't save.

[mattwach]

I was originally using vfat on an sdcard but it would error out after a few commands so I abandoned that path. I'm trying to remember if I did the format from linux or the picocalc - I think it was linux. I'd have to try it again to be sure of the various details of what setup worked.

I tried littlefs on the SD card after vfat (still a while ago) and I could format and read and write data from the PicoCalc. However, when I tried to use the filesystem in linux, it was not able to mount the littlefs partition that the PicoCalc created (the reverse was also true). That is when I decided to just use the Picos internal flash with littlefs, which has been working for me.

I have xmodem working using the instructions in https://github.com/mattwach/rpngo/blob/main/USER_GUIDE.md#xmodem-send-and-receive I copied those directly from the terminal verifying they worked..

I'd say a precursor is that you can type characters in minicom / screen and see them apprear on the picocalc as well as see data come back the other way. If that part is not working, then XMODEM will not work either

[mattwach]

I just reverified that I could send a file from PC to PicoCalc using screen and in instructions in the users guide:

screen /dev/ttyUSB0 115200

type Ctrl-A on the pc, then :

exec !! sx bounce_ball.rpn

on the PC and rx on the picocalc after that.

One thing I got wrong about is what to expect on initial connect. When start screen (before xmodem). I can see characters I type on the picocalc screen as I type them. But nothing except for print output is sent back. (e.g. hello' println will send something from the PicoCalc to the PC)

[eh]

Okay. When littlefs was "working" I put an sdcard with a fat32 partition on it in the PicoCalc, formatted from the PicoCalc and so on, but when I put the sdcard in my linux desktop the old fat32 partition was still there, with all the old data remaining. That's what led me to blanking the cards and getting no where.

I did not realize there was internal flash that could be used. I will try again, hopefully tomorrow if I find some time. I don't think local echo was enabled which sounds like it would be why XMODEM was failing. I have been following the USER_GUIDE over and over, maybe it's not obvious what order things need to happen in. I think all of this is on me and I'll give it another go when I get a chance.

[mattwach]

Oh sorry, I didn't mean that ECHO ON should be enabled (I have it off). I was just talking about what I see in case it's different on your hardware.

Thanks for making the effort. I can try and reproduce my VFAT experience tomorrow if I get some time.

[mattwach]

Hi, I tried compiling with

FS ?= fatfs
BLOCKDEV ?= sdflash
TARGET ?= pico

Then a I dropped a 16GB already-formatted sd card into the pico calc and see that

'ls' sh

Does successfully list the files on the SD card that we put there by the pc. I have no easy way to check the Pico2 right now.

Here is a fdisk dump of the SD card.

$ sudo fdisk /dev/disk/by-id/usb-Generic_MassStorageClass_000000002959-0:0
[sudo] password for mattwach: 

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/disk/by-id/usb-Generic_MassStorageClass_000000002959-0:0: 14.43 GiB, 15489564672 bytes, 30253056 sectors
Disk model: MassStorageClass
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device                                                              Boot Start      End  Sectors  Size Id Type
/dev/disk/by-id/usb-Generic_MassStorageClass_000000002959-0:0-part1       8192 30253055 30244864 14.4G  c W95 FAT32 (LBA)

Command (m for help): q

[eh]

I was referring to the part of the user guide that mentions setting the variable .echo to true.

But that was a red herring. I did a build/flash with only TARGET=pico2 and littlefs is working with the internal flash, as expected.

I solved the XMODEM issue by using lrzsz-sx -X. I think this is a packaging issue on arch because the binary is being renamed to prevent collisions with other packages. It wouldn't be an issue if named lsx or sx as originally intended. minicom calls lrzsz-sx -vv by default which explains the issue there as well.

So data transferring is solved. I can try to get an sdcard build going and see if I run into any stability issues.

[mattwach]

Thanks for getting to the bottom of the sx issue. I updated the docs to include the -X option as it work for me (debian) with or without the option.