Usage of the 8 (or 6?) Special Pins on/after Boot-up, P84-P91 (or P86-P91?)

JRetSapDoog

The Prop 2 Specifications summary on Parallax Semiconductors site mentions, "92 I/O pins total: 84 fully general purpose I/O + 8 additional general purpose I/O available after boot-up."

From one of the Prop 2 module documents that Chip provided, the following pin assignments are detailed:

P91 RX
P90 TX
P89 SPI_CS
P88 SPI_CK
P87 SPI_DI
P86 SPI_DO
P85 ???
P84 ???

I see that P84 and P85 are assigned for the module with the 32MB SDRAM as CLK and LED, respectively (for the SDRAM and an indicator?). But I don't know the usage for these pins if not using the external memory chip. Are they fully general purpose, or is there something special about them on boot-up?

Also, for the module Parallax is planning, P86-P89 connect to an 8MB SPI flash chip. Is this SPI usage fixed in the built-in 2K ROM?

Lastly, even with an SPI flash chip connected as above, I'm wondering if P86-P88 could also be wired (in parallel) to an SD card, providing one of the general purpose Prop 2 pins was used to drive the CS input of the card.

That is, assuming that one doesn't want to access an SPI Flash chip and an SD card at the same time, could P86-P88 pull "double duty" to access the flash chip and the SD card (though not at the same time and assuming proper initialization)?

And, if so, what would the approximate turn-around time be to switch from one to the other. I recall reading that to initialize an SD card, you have to send a lot of clock pulses to it. But I guess there's nothing that says it has to be constantly mounted, or there wouldn't be unmount commands in the SD card objects. Does anyone see any problems having both an SPI flash chip and an SD card in the same system sharing P86-P88, or, at the very least, booting from the flash chip and subsequently using the SD card?

Mike Green

Both SD cards and SPI flash devices are supposed to ignore their other lines whenever their /CS line is high. On the Propeller C3 board, the clock, data in and data out lines are shared among an SD card, SPI flash, 2 SPI SRAMs, and an SPI ADC. The turn-around time is that needed for any current operation going on in any of the devices to be allowed to finish. That depends on the device in use, maybe a block size, etc.

JRetSapDoog

Thanks for the information, Mike. And thanks for citing the example of that C3 board. Even on a P2, pins are precious, so that's good news.

Bill Henning

Another example for you...

On PropCade I use 7 pins to provide for eight SPI devices. Three pins select the SPI device (0-7), then we have the regular /CS,CLK,MOSI,MISO

The devices are: 6 SPI Flash/Ram sockets, MCP23S17 I/O expander and a uSD slot.

JRetSapDoog wrote: »

Thanks for the information, Mike. And thanks for citing the example of that C3 board. Even on a P2, pins are precious, so that's good news.

David Betz

Bill Henning wrote: »

Another example for you...

On PropCade I use 7 pins to provide for eight SPI devices. Three pins select the SPI device (0-7), then we have the regular /CS,CLK,MOSI,MISO

The devices are: 6 SPI Flash/Ram sockets, MCP23S17 I/O expander and a uSD slot.

That sounds like a much better solution than the counter-based approach used by the C3. Is the PropCade shipping?

tonyp12

>could P86-P88 pull "double duty" to access the flash chip and the SD card


Sure, use P83 (or choice of pin) as the SD_Cards CSn and as SD_cards have 50k pull-up you don't have to worry that during boot-up the pin is input.
I would assume you would have to put a 1meg pull-down on this line if you want to use card detect function.


3) At power up this line has a 50KOhm pull up enabled in the card.
This resistor serves two functions Card detection and Mode Selection.
For Mode Selection, the host can drive the line high or let it be pulled high to select SD mode.
If the host wants to select SPI mode it should drive the line low.
For Card detection, the host detects that the line is pulled high.
This pull-up should be disconnected by the user, during regular data transfer, with SET_CLR_CARD_DETECT (ACMD42) command

The SD Card is powered up in the SD mode.
It will enter SPI mode if the CS signal is asserted (negative) during the reception of the reset command (CMD0).

Bill Henning

Thanks!

Yes, PropCade is available - and I am dropping the price of the "Essentials" kit to $29+s/h, and the "128K" kit to $99+s/h (descriptions of kit contents on the product page)

I will be re-calculating my BOM costs, and coming up with some intermediate kit versions for those that don't need the RTC / RS485 / SVideo / IR in+out / Atari joystick ports.

The Microchip 128kx8 SRAM's would work fine on it, as will standard pinout spi flash parts (up to the 64Mbx8 smt parts) - with the six memory sockets, 512KB of ram and 128MB of flash is easy

Pretty much any cheap USB-serial converter works with PropCade (it has an on-board MAX3232 and DB9F) for programming, or for use as a terminal replacement, however if the MAX chip is removed, it also has a PropPlug compatible connector.

Here is the link to the product page:

http://www.mikronauts.com/propcade/

David Betz wrote: »

That sounds like a much better solution than the counter-based approach used by the C3. Is the PropCade shipping?

JRetSapDoog

Thanks, Bill, for that additional example. Nice use of the I/O expander (I see that they have I2C and SPI versions). And nice project!

Thanks, Tony, for those comprehensive details for connecting the SD card. I'll probably have to revisit these later to fully appreciate the details (particularly if there's H/W or S/W differences from standard usage), but I'll know where to look. BTW, so far, I've just used a/the dedicated 4-pin interface and ignored the optional card detection (even if bad form, though I recall Rayman has a clever setup).

Hmm...what am I saying! I don't even think there's an SD object for the P2 at this point (and writing/converting that is above my pay grade). Does anyone know if a conversion/port is in the works? I have no idea how timing-sensitive the code is (and the P2 will be much faster). I know, I know, first things first: chip, loader, Spin and so on. There was a pretty big debate at one time whether to include SD functionality into the firmware, but, ultimately that was decided to not be the best approach.

Lastly, does anyone know the status of P84 & P85 on boot-up (if using a P2 without the SDRAM)? Are there 8 "special" pins on boot-up or just 6? If the answer is 8, I've overlooked or lost track of the usage for those other 2. If just 6, then the summary document could be reworded at some point to reflect that.

Ariba

Chip has released the ROM-Boot code. It starts with the following pin definitions:

CON

  rx_pin = 91
  tx_pin = 90
  spi_cs = 89
  spi_ck = 88
  spi_di = 87
  spi_do = 86

  base = $E80

So only 6 pins are used at boot up. And most of them can be reused after boot up. For an SPI Bus and for PC communication for example. Only spi_cs should be held highif you don't want access the Flash.

There is already a port of Prop GCC for the P2, including SD card driver.

Andy

JRetSapDoog

Thanks, Ariba! That would seem to pretty much settle it. Then perhaps the summary page for the P2 could be reworded, "92 I/O pins total: 86 fully general purpose I/O + 6 additional general purpose I/O available after boot-up." But all in due time, I suppose, as maybe those other 2 pins were being held in reserve, so to speak, just in case. But if the ROM-Boot code is finalized, then it seems like "six...it is." And in the case of designs that don't use the SDRAM, no one's going to complain about having 2 extra pins available. Thanks for quoting the relevant part of the boot code to answer that.

So, there's already a port of Prop GCC for the P2 that includes the SD card driver, huh? That's good (I think that I do recall reading something about one-line of code setting up an SD card driver on the P1 version). I wonder if the SD card portion of the code was ported by someone in the Parallax community from one of the existing P1 PASM drivers, or if the port came from some other (hopefully unencumbered) source out in cyberspace. Either way, if a high-level language is being used, it sounds like the timing doesn't require assembly (i.e., is not so critical/tight). Still, I wonder if a PASM2 version (with a SPIN2 interface) will be released.

David Betz

Weren't those two extra pins being held in case a QuadSPI chip was used as a boot device? Those pins could then be used as additional data pins after boot so that the user program could use 4 bit access to the QuadSPI chip. The ROM loader would only use single bit mode though even if the boot chip supported 4-bit accesses.

JRetSapDoog

Oh, I see. Yeah, maybe that explains it. In my ignorance upon reading that, I thought "Wouldn't QuadSPI take at least 3 more lines, not just 2 more?" But now I see that it's a 6-pin interface: CS, CLK, IO0, IO1, IO2 & IO3. That would maybe double the overall throughput to load/store things. But what things? Fonts/character sets, graphics, interfaces or whatever one wants, I suppose (perhaps things that don't change much, if at all). For example, I can see how being able to get fonts in quickly for video output, like the thousands of Chinese characters, might be a potential use. Anyway, I wonder if QuadSPI usage with the Prop 2 will become common. Thanks for the information/speculation. I was kind of thinking that at least one of those two pins might have had something to do with the possibility of the firmware being able to boot from an SD card directly on power-up (if higher-priority options weren't found), but such support was decided against, such that perhaps those pins would be free. Or, who knows: maybe different versions of the chip could be offered someday with differing ROM firmware, though it seems that Parallax wisely likes to keep things as simple as possible (i.e., not have a lot of potentially confusing versions of things), and multiple versions could up the costs. Anyway, it might be a good idea to keep at least one of those lines free as a potential CS line for an SD card, such that some of the SPI lines could be shared (maybe that will become kind of "standardized"), though on the current board with SDRAM being developed, those pins are already committed (so another pin would need to be used). Well, time will tell.