I'm experimenting with an ArmMite H7 setup. I have a DevEBox plugged into carrier that also plugs into a 7 inch 800x480 LCD panel. Both the DevEBox and the LCD panel have SD card sockets, and both work with the appropriate OPTION SDCARD setting. But alas, only one can be used at a time. Is there any way to use both?

Ideally, I'd like to store program resources, such as graphic images, on the DevEBox uSD card. This will be inaccessible to the user. The SD card socket on the LCD panel will be user accessible and would allow the user to load data files. This way, the program will display correctly even if the user removes the SD card or the user's card doesn't contain the required support files.

Thoughts?

---

Visit Vegipete's *Mite Library for cool programs.

Electronically it's easy. Unfortunately MMBasic only supports a single CS line for a SD card. You can, in theory, use external logic to gate this to one of two different sockets but MMBasic will see both of them as B:/.

Although I have no need, ATM, I was recently musing about this very thing.

It might be possible to do this. Would need a change to firmware.
The inbuilt SDCARD is always CS=79 and is bitbanged using the pins that are wired to the SDCARD.These pins are never available to MMBasic other than this internal bitbanging.

If CS<>79 then its just a standard SPI SDCARD using the nominated CS pin.

At start up either the SPI is opened or the Bitbang pins are configured in InitFileIO() function depending on value of the CS pin.
An extra parameter or even a -ve CS pin no could be used to tell it to initialise both SDCARD modes i.e. SPI and bitbang. It would default to the SPI SDCARD but the Bitbang pins would be configured as well.
i.e.
OPTION SDCARD [-]CS-Pin[,CD-Pin [,WP-Pin][,1]
(possibly the bitbang pins can be configure in any case without any adverse issues.)

OPTION SDCARD_CS would be allowed in a program and would changed the memory copy of Option.SDCard_CS so file operations would point to the desired card.(These are already sensitive to the value of Option.SDCARD_CS)
The SDCARDs would always be A:/ and programmer would be responsible for manipulating OPTION SDCARD_CS and keeping track of what SDCARD was being accessed.

Would this be useful.

Gerry
Edited 2026-01-31 20:07 by disco4now

  Quote  

Electronically it's easy. Unfortunately MMBasic only supports a single CS line for a SD card. You can, in theory, use external logic to gate this to one of two different sockets but MMBasic will see both of them as B:/.

Not the whole story. The firmware uses the SDcard in SPI mode. It initialises the card and sets it into this mode the first time it is used. With a second card the firmware wouldn't know that it hadn't been initialised. Also, the firmware uses read and write buffering, so the buffers have to be flushed before changing card.

The only way I can think to make it work is as follows:

LOOP:
Disable both CS pins electrically for 2 seconds.
The firmware will then decide there is no sdcard and will "eject" it.
Then enable the CS for the card you want to use.
As the firmware knows there is no initialised card it will do the init and then can use the card.
To switch card goto loop

The disable and enable could be done with two tri-state buffers controlled by two extra GPIO pins

Thank you for the ideas and details.

I was aware of the initialization code to prep an SD card. How long does the initialization remain in effect? I was pondering a small MCU to initialize the secondary SD card - then both would be available depending on the active CS. (Active low, right?)

[Edit]
This is probably pointless if the different SD cards are on different busses - ie one is bitbanged, the other is on an SPI port. Maybe I have to add an SD card on my carrier that uses the same pins as the one on the LCD.
[/Edit]

I wasn't aware of the buffering. What action flushes the buffers? If writing a file, is  'CLOSE' enough to do it?

---------
With regards firmware changes, the most amazing solution would be A: and B: drives but that's asking a heck of a lot. The OPTION SDCARD already has a bunch of parameters so adding even more gets confusing. Perhaps a second OPTION SDCARD2 could set up the second one? Are the CS pins available to MMBasic? Or would a special CHDIR "DriveID" make this easier?

I don't see a need to copy files between cards, but the FileManager authors might have different ideas.  ;-)

Thanks!
Edited 2026-02-01 04:25 by vegipete

I've lost touch with the ArmMite. The PicoMite has a A:/ drive in flash but I don't know if that's available here.

  vegipete said  

I'm experimenting with an ArmMite H7 setup. I have a DevEBox plugged into carrier that also plugs into a 7 inch 800x480 LCD panel. Both the DevEBox and the LCD panel have SD card sockets, and both work with the appropriate OPTION SDCARD setting. But alas, only one can be used at a time. Is there any way to use both?

Ideally, I'd like to store program resources, such as graphic images, on the DevEBox uSD card. This will be inaccessible to the user. The SD card socket on the LCD panel will be user accessible and would allow the user to load data files. This way, the program will display correctly even if the user removes the SD card or the user's card doesn't contain the required support files.

Thoughts?

See if this works.
It is specifically for the scenario above. It lets you swap the active SDCARD within in a program or at the commandline without a restart. You have no B:/ drive. You cannot directly copy between them, only one is available at a time. Works with the DevEBox and WeACT 100 pin built in bitbanged SDCARD and the System SPI SDCARD on the LCD. It should also work with two SDCards on the System SPI.
The Options below are modified/added to support this.

ArmmiteH743.zip

OPTION SDCARD CS-Pin[,CD-Pin [,WP-Pin]][,CS2-Pin]
CS2-Pin is the CS pin for the second SDCARD. (CD-Pin and WP-Pin not supported)

OPTION SDCARD1    - Switch to the first SDCARD   (allowed in program)
PAUSE 500
OPTION SDCARD2    - Switch to the second SDCARD  (allowed in program)
PAUSE 500

You must add the PAUSE if used in a program.
You would need to ensure all files are closed before swapping to the other SDCARD.
You can only use one at a time, and it will always be the  A:/ drive.

> option list
ARMmite H7 MMBasic Version 5.08.00b1
OPTION LCDPANEL SSD1963_7_16, RLANDSCAPE
BACKLIGHT 50,DEFAULT
OPTION SDCARD 78,,, 79


> run
SDCARD1 Active
Ready
SD1.BAS Size:    19
I am from SDCARD1
SDCARD2 Active
Ready
SD2.BAS Size:    19
I am from SDCARD2

Wow, looks promising. Thank you!

I had a quick test (mostly from the command prompt) with mixed results, but I must test more.

I used the same OPTION SDCARD 78,,,79  (same OPTION LCDPANEL too, and OPTION TOUCH 67,77)

An SD card (from a CMM2) inserted in the LCD wasn't recognized - maybe too small?
Switching to card 2, a uSD on the DevEBox, worked fine. Switching back to the first one, FILES kept displaying what was on the second card. Eventually it quit working with a "Not enough memory" (~ish) error. I will test more to see what I learn.

I had not tested with Touch enabled, but on testing with touch enabled I am not getting the issues you see.

It handles the SDCARD not being inserted on the LCDPanel. I see no memory leak using ? MM.info(HEAP).
This is code I ran.
The first thing is probably to ensure the SDCARD on the LCDPanel works reliably when it is configured normally.