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

Comments

• Mike Green Posts: 23,101

  2013-08-08 22:15 edited 2013-08-08 22:15

  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 Posts: 954

  2013-08-09 03:46 edited 2013-08-09 03:46

  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 Posts: 6,445

  2013-08-09 07:51 edited 2013-08-09 07:51

  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 Posts: 14,511

  2013-08-09 07:56 edited 2013-08-09 07:56

  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 Posts: 1,950

  2013-08-09 08:01 edited 2013-08-09 08:01

  >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 Posts: 6,445

  2013-08-09 10:02 edited 2013-08-09 10:02

  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 Posts: 954

  2013-08-09 22:58 edited 2013-08-09 22:58

  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 Posts: 2,682

  2013-08-10 18:47 edited 2013-08-10 18:47

  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 Posts: 954

  2013-08-11 07:48 edited 2013-08-11 07:48

  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 Posts: 14,511

  2013-08-11 08:07 edited 2013-08-11 08:07

  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 Posts: 954

  2013-08-12 12:49 edited 2013-08-12 12:49

  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.