Loading ...
Sorry, an error occurred while loading the content.

MMC interface update

Expand Messages
  • MigraineMan
    First, I d like to express my appreciation to all the folks participating in the Zipit effort. Without the autopsy photos and the helpful comments in this
    Message 1 of 1 , Oct 22 8:10 PM
    • 0 Attachment
      First, I'd like to express my appreciation to all the folks
      participating in the Zipit effort. Without the autopsy photos and the
      helpful comments in this forum, I'd be dead in the water.

      That said, I've gotten the physical portion of an MMC interface
      tied-in to the Zipit CPU. There are four unused pins on the CPU, and
      I'm using all of them. "Unused pins? Where ??!?!?" There are three
      pins in Port E that are unused, and one external interrupt pin. Port
      pins PE[2..0] are responsible for configuring the CPU's boot mode at
      power up, but revert to GPIO duties after the nPOR reset signal
      latches them. The nEXTFIQ fast-interrupt input is simply connected to
      a pull-up resistor.

      Being careful not to break the power-up configuration, I connected the
      four pins to an MMC receptacle. They are connected as follows:
      MMC nCS <-- PE[1] (connect to R9)
      MMC CLK <-- PE[0] (connect to R23)
      MMC DO --> nEXTFIQ (connect to R26)
      MMC DI <-- PE[2] (connect to R27)

      The pin assignments are fairly critical. When the CPU powers up, it
      samples the state of PE[2..0] to determine the boot flash interface as
      well as the clock speed. The pull up/down resistors on these pins
      need to perform their original duties, as well as disable the MMC
      card. R9 is a pull-up, so that will take care of disabling the MMC
      when the SPI bus isn't being driven. Another important item - the MMC
      pins aren't multiplexed with other funcitons like I2C. There
      shouldn't be any complications like shared non-blocking drivers, or
      rate limitations due to other devices sharing pins.

      I'm sure some folks are scratching their heads about the use of the
      External Fast Interrupt as the input pin. We're not going to use it
      as an interrupt, but rather as a GPIO-type input. The interrupt
      function is masked in the INTMR1 mask register, but the status bit in
      the INTSR1 register still actively reflects the input pin state
      (albeit inverted.)

      Sounds nice, but will it work? I'm glad you asked. I've modified my
      personal Zipit with this change - I'll sacrifice my own unit before
      I'd suggest that someone do the same. 30AWG solid wire connects the
      resistors to an MMC socket. Power and ground are tapped off a
      convenient capacitor. Power up with a card installed shows no ill
      effects. I've compiled and run the devmem2.c program that allows
      command-line memory/port manipulation. I have manually changed the
      Port E Direction Register (PEDDR) to configure the pins as outputs. I
      have manually poked the Port E Data Register (PEDR) to both set and
      clear each pin individually. Port E responds as advertised, with no
      ill effects on the other Zipit operations. The nEXTFIQ input bit is
      Bit 0 in the INTSR1 register. When the pin is held logic-high, the
      bit reads 0 in the register (i.e. the interrupt is inactive.) When
      the pin is held at a logic-low, the bit in the register reads 1. The
      7312 User Manual indicated that the nEXTFIQ interrupt input is not
      sampled on an internal clock like other interrupts (a deglitching
      measure,) so there shouldn't be any issue with running that input at
      SPI speeds.

      What *haven't* I done? I haven't modified and compiled the mmc.c
      driver routine - it needs to know about the pin assignments and the
      input bit inversion. I haven't tried the insmod method of installing
      a driver. I'll need to make sure the driver, when running at speed,
      doesn't exceed the MMC SPI bus timing. And the big one - I haven't
      communicated with the card yet. It looks like I have all the
      necessary signals in place, so I've feeling pretty confident now.

      In all my testing, I've had the Zipit on my local wireless link
      (WEP-128 encrypted) with my SuSE linux box mounted as an NFS mount,
      and my main operational console has been running over a wireless
      Telnet session (I get tired of fussing with the teeny keyboard while
      the unit is disassembled on my bench.)

      Mechanically, there are two schools of thought on the mounting of the
      MMC Card. Some folks want external access; others want hidden
      internal access. My card is mounted in the bottom plastic cover with
      no external access - I'm intending to treat it like a local hard drive
      in a laptop. There's ample opportunity to mount the MMC card any
      number of places, though I'd recommend staying away from the antenna
      trace on the PCB where the coax cable heads for the hinge access (yes,
      that funny looking trace that's away from everyone else is an antenna.)

      I'll provide more information when I have it. I intend to provide a
      better writeup that includes photos, part numbers and diagrams of wire
      attachments. If you want to jump in early, be prepared to need a good
      soldering iron (I use a Metcal with the 1/32" hook tip) and a
      magnifier of some sort (I've got a boom mounted 10-40x zoom stereo
      microscope, though a swingarm magnifier/lamp combo may be good enough
      if your eyes are better than mine.) Good tweezers are a must too.
      The four resistors mentioned are of the 0402 variety, so 30AWG-solid
      is about the largest wire you'll want to use. I used 28AWG-stranded
      for the power connections.

    Your message has been successfully submitted and would be delivered to recipients shortly.