search

RC2014Z80 / picoterm

Pi Pico VGA Terminal Emulator For RC2014
BSD 3-Clause "New" or "Revised" License
64 stars 19 forks source link

SDCard mounting #35

Closed mchobby closed 1 year ago

mchobby commented 1 year ago

Adding SDCard support on PicoTerm.

Base work on no-OS-FatFS-SD-SPI . See the following ressource:

Currently under progress ...

abaffa commented 1 year ago

Is it already using the GPIO expander or the sdcard module is connected directly to the rp2040? Could u send a pic of showing the connections?

mchobby commented 1 year ago

I do use the recommandation of Steven documented here:

PicoTerm connector

As soon I do read the FAT, I will update documentation with wiring and "compiling" documentation with the task to do.

Dominique

RFC2795 commented 1 year ago

I received the PCBs for the SD Card Backpack over the Christmas holidays, as you can see from the photos attached.

I feel like this is probably already out of date without the buzzer or IO expansion, so I think it might be best for me to redesign the whole module to include the various updates discussed here.

(In the meantime, would you like me to send you both one of these for your own use?)

What do you guys think?

Thanks

Spencer

IMG_20221230_150346 IMG_20221230_150356 IMG_20221230_150451 IMG_20221230_150456 IMG_20221230_150753

mchobby commented 1 year ago

This is very kind... Thanks. I like the placement behind the board.

In your new design, could foreseen a footprint for the PCA GPIO expander (as optionnal) ?

Dominique

mchobby commented 1 year ago

BAD NEWs for the first attempt.

I was really expecting good progressing with the no-OS-FatFS-SD-SPI-RPi-Pico library. Unfortunately that library requires a SPI bus to work properly... unfortunately, we don't have a complete bus available :-( ... just starting the SPI0 do hang software on the Pico. For tonight, I will revert the work.

I will tray another approach based on pico_sd_card and its sd_test code Apparently this can work in 1bit mode but required 3 consecutives GPIO (since it uses PIO). So I'm not very optimistic but "one thing at the time".

abaffa commented 1 year ago

@RFC2795 Thanks, This is very kind and would help with development :)

@mchobby is right. It would be nice to add a GPIO for future expansions.

mchobby commented 1 year ago

@RFC2795 Thanks, This is very kind and would help with development :)

@mchobby is right. It would be nice to add a GPIO for future expansions.

There are still two GPIOs remaining available on the PCA9536 schematic if you are using it. And you can still add another GPIO expansion as needed (PCA9354 bit 8bit or MCP23017 with 16 bits). So we are relax with this. The only concerns about that is the relatively low speed of I2C (400 KBits/sec).

Note: when reading the Pico-Implementation guide, I noticed that demo schematics requires 5 contiguous PIN block (for PIO). GP18 to GP22 which are used for other activities.

Sélection_150

Next week-end, I will made additional check/elaboration to:

mchobby commented 1 year ago

@RFC2795 @abaffa Here is the result of additional check/elaboration around SDCard in the current situation: picoterm-sd-options

Option 1: 4 bits data bus = Reject

It is the solution proposed in the "RP2040 Hardware Design" as followed by @RFC2795 (Spencer). As seen on the Wiring, I2C bus and UART1 must be deinit before starting PIO engine to access the SD and vice-versa. I'm not comfortable with such approach. UART1 deinit also means stopping communication with the retro-computer (no buffering on the RX in such case).

Option 2: 1 bits data bus = Reject

The "RP2040 Hardware Design" also mentioned the ability of using 1 bit data bus. This requires 3 consecutive GPIO for PIO the SDCard with a state machine as stated in the documentation (or the demonstrating code). Unfortunately we don't have such without deinit the UART1. So this is also a failure.

Option 3: Accessing SDCard in SPI mode = Reject

To get an hardware SPI, we have to wire the DAT0 to GPIO 16 which is also VGAVS (VGA Vertical Sync). This would also requires to validate or create a library for accessing the SDCard. So when talking to SD, we must stop the VGA rendering thread, stop StateMachine of VGA, init SPI, dial the SD, deinit SPI, reinit GP16, restart VGA statemachine & VGA rendering thread. For sure, this will be quite glitchy and maybe difficult to synchronize.

Option 4: I2C-to-SPI bridge (to explore)

Some research lead me to the NXP SC18IS602B which allows to bring a SPI bus over an existing I2C bus. Sélection_174 I also find this instructive document http://www.dejazzer.com/ee379/lecture_notes/lec12_sd_card.pdf about accessing a SD in SPI mode. This is still a very low level access and library must be coded for FAT access (maybe reusing the FatSD of Arduino Lib?).

[EDIT] ordered an evaluation board for quick testing

Option 5: TinyUSB - flash drive reader = REJECT

Fev 2023: Using USB based storage is not really compatible with config file storage.

TinyUSB can support USB Hub (read it somewhere but not yet supported in the PicoTerm code). Among the peripheral supported by TinyUSB, can it read an USB Stick (USB Flash drive) when plugged ? In such case... no need for SDCard support.

[EDIT] after some research, I did locate the tinyusb/examples/host/msc_file_explorer/src/msc_app.c example where TinyUSB do mount a USB Storage and make IO access to him. The example also includes following functions:

void cli_cmd_cat(EmbeddedCli *cli, char *args, void *context);
void cli_cmd_cd(EmbeddedCli *cli, char *args, void *context);
void cli_cmd_cp(EmbeddedCli *cli, char *args, void *context);
void cli_cmd_ls(EmbeddedCli *cli, char *args, void *context);
void cli_cmd_pwd(EmbeddedCli *cli, char *args, void *context);
void cli_cmd_mkdir(EmbeddedCli *cli, char *args, void *context);
void cli_cmd_mv(EmbeddedCli *cli, char *args, void *context);
void cli_cmd_rm(EmbeddedCli *cli, char *args, void *context);

Option 6: reducing VGA bit, relocating UART (to explore)

As suggested by RFC2795 (freb 2023), LSB bit (and buttons) can be removed from VGA generator. Still providing with 4096 colors (12 bits). Then UART can be relocated to free-up GP20 & GP21 for SD card (SPI mode).

RFC2795 commented 1 year ago

The way I envisage a SD card being used is to hold things like fonts and sprites, and maybe user definable macros that can be called with function keys, or config data. So although a USB drive could be used the same, it will be messier.

If both Option 1 and Option 2 need the UART pins, then maybe the colour depth could be reduced to free up some pins to allow the UART to be moved elsewhere. The hardware design from Raspberry Pi has 15 bits (and 15 pins) of data, which gives 32768 colours available on the screen at one time. Whilst this is great, and can be used for demo scene stuff, most CP/M software that uses colours will only use a few primary colours. The LSB for each colour is currently shared with the A/B/C buttons, but if the LSB each colour was dropped, it would still be a 12 bit colour depth, which gives 4096 colours and frees up 3 pins to move the UART around.

How does that sound?

I am currently looking in to a new hardware design for this, to incorporate all the modifications which have been discussed here, and it would be nice to put everything together on a single PCB.

mchobby commented 1 year ago

@RFC2795 1) The LSB and buttons could, indeed be removed. I will check feasibility of Pin assignment based on your suggestion and give additional feedback.

2) I ordered the NXP SC18IS602B I2C-to-SPI bridge (for option 4). Currently waiting for delivery here in Belgium.

dquadros commented 1 year ago

Not sure if you want to make this big change, but if you are thinking of reducing the number of bits per pixel there is the picovga project (https://breatharian.eu/hw/picovga/index_en.html). It uses only 8 bits per pixel but supports 80 columns color text. This should release enough pins for connecting the SD card to one of the two SPI ports.

Enviado do Yahoo Mail no Android

Em seg., 6 6e fev. 6e 2023 às 18:32, @.***> escreveu:

The way I envisage a SD card being used is to hold things like fonts and sprites, and maybe user definable macros that can be called with function keys, or config data. So although a USB drive could be used the same, it will be messier.

If both Option 1 and Option 2 need the UART pins, then maybe the colour depth could be reduced to free up some pins to allow the UART to be moved elsewhere. The hardware design from Raspberry Pi has 15 bits (and 15 pins) of data, which gives 32768 colours available on the screen at one time. Whilst this is great, and can be used for demo scene stuff, most CP/M software that uses colours will only use a few primary colours. The LSB for each colour is currently shared with the A/B/C buttons, but if the LSB each colour was dropped, it would still be a 12 bit colour depth, which gives 4096 colours and frees up 3 pins to move the UART around.

How does that sound?

I am currently looking in to a new hardware design for this, to incorporate all the modifications which have been discussed here, and it would be nice to put everything together on a single PCB.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

dylanhall commented 1 year ago

If you're considering more radical changes to the board then one option is to use one of the other RP2040 boards that expose more pins. For example the PGA2040 (https://shop.pimoroni.com/products/pga2040) or the RP2040 Stamp (https://www.tindie.com/products/arturo182/rp2040-stamp/). I think they make an extra 3 or 4 pins available.

mchobby commented 1 year ago

@RFC2795

1. The LSB and buttons could, indeed be removed. I will check feasibility of Pin assignment based on your suggestion and give additional feedback.

2. I ordered the [NXP SC18IS602B](https://www.nxp.com/products/peripherals-and-logic/signal-chain/bridges/ic-bus-to-spi-bridge:SC18IS602B) I2C-to-SPI bridge (for option 4). Currently waiting for delivery here in Belgium.

@RFC2795 I identified the PIXEL_RSHIFT, COLOR_PIN_BASE, COLOR_PIN_COUNT in the PICO_EXTRA/scanVideo . I will order a new PicoTerm board to test 12 bit rendering from pin 3. So uart_0 will be released on pin 0 & 1 and we would release GP20 & GP21 for SDCard access.

RFC2795 commented 1 year ago

@mchobby Send me an email (spencer at z80kits dot com) with your address and I'll post a PicoTerm board out to you

mchobby commented 1 year ago

@mchobby Send me an email (spencer at z80kits dot com) with your address and I'll post a PicoTerm board out to you

Hi Spencer, I just send an email because of shipping issue to Belgium :-/ Dominique

mchobby commented 1 year ago

This issue is now solved in version 1.6.0.20! Here some details about the solution.

The connector GPIOs have been reallocated in a different way! Sélection_143 With consecutive GPIO 26,27,28 we can bring a PIO_SPI bus. CS/ChipSelect signal is managed with GPIO 5.

Because of SPI bus, the I2C bus (as well as extra buzzer+USB_Power) have been relocated on GPIO 18 & 19. As GPIOs 18 & 19 also support harware I2C (as I2C1) then the code change is minimal.

Finally, FatFs lib has been included and modified to support PIO_SPI instead of hardware SPI.

See:

Dom