Shop OBEX P1 Docs P2 Docs Learn Events
Using EEPROM pins for other things — Parallax Forums

Using EEPROM pins for other things

Vega256Vega256 Posts: 197
edited 2012-12-22 11:44 in Propeller 1
Hey guys,

I have been searching for, at least, a general solution to the problem of using the EEPROM pins for other things besides EEPROMs.

The closest thing I found was this:
http://forums.parallax.com/showthread.php?141512-Using-eeprom-pins-for-a-keyboard

My problem, though, is that I need those pins for an EEPROM and something else after initialization. I thought that maybe a data line selector or multiplexer would work, but then I saw some simpler proposed solutions in the aforementioned post.

Thoughts anyone?

Comments

  • MagIO2MagIO2 Posts: 2,243
    edited 2012-12-22 06:27
    Do you need the EEPROM for booting only, or do you also need it later for storage? What other hardware would you like to attach?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-12-22 06:44
    Vega256 wrote: »
    Hey guys,

    I have been searching for, at least, a general solution to the problem of using the EEPROM pins for other things besides EEPROMs.

    The closest thing I found was this:
    http://forums.parallax.com/showthread.php?141512-Using-eeprom-pins-for-a-keyboard

    My problem, though, is that I need those pins for an EEPROM and something else after initialization. I thought that maybe a data line selector or multiplexer would work, but then I saw some simpler proposed solutions in the aforementioned post.

    Thoughts anyone?
    If the Prop had 2 more I/O or 32 more then the same question would probably still be asked. It has more to do with the way you go about implementing your interfaces and the choices your make. There's also a lot of optimization that tends to be missed. I've seen I/O consumed because someone thinks they should have DIP switches for instance, and lots of them. Or a bunch of LEDs are hanging off I/O when it's just as easy to drive them off a 30 cent shift register, and so on.

    So, how are you using your I/O at present, I'm sure there is something you can do as I would recommend leaving the EEPROM lines alone and use them as an I2C bus to other chips or even as the clock and data to SPI devices. These functions don't interfere with the EEPROM or booting.
  • Vega256Vega256 Posts: 197
    edited 2012-12-22 06:44
    MagIO2 wrote: »
    Do you need the EEPROM for booting only, or do you also need it later for storage? What other hardware would you like to attach?
    Yes, the EEPROM is for booting only. I'm trying to attach a microprocessor. More specifically, I need to connect the processor's interrupt request signal to one of the EEPROM pins. The interrupt signal is active low.
  • Vega256Vega256 Posts: 197
    edited 2012-12-22 07:02
    Peter Jakacki wrote: »
    If the Prop had 2 more I/O or 32 more then the same question would probably still be asked. It has more to do with the way you go about implementing your interfaces and the choices your make. There's also a lot of optimization that tends to be missed. I've seen I/O consumed because someone thinks they should have DIP switches for instance, and lots of them. Or a bunch of LEDs are hanging off I/O when it's just as easy to drive them off a 30 cent shift register, and so on.

    So, how are you using your I/O at present, I'm sure there is something you can do as I would recommend leaving the EEPROM lines alone and use them as an I2C bus to other chips or even as the clock and data to SPI devices. These functions don't interfere with the EEPROM or booting.
    I understand what you are saying; I've been thinking that I might not be using I/O as effectively as possible, but I'm not sure that there is a way around this.

    I'm trying to implement an address and data bus, as well as some control signals. Essentially, the Prop is a memory device on my circuit.

    32 I/O pins - 2 EEPROM pins - 15 address lines - 8 data lines - 3 control signals - 3 video pins - 1 sound pin = 0 pins
  • Mike GMike G Posts: 2,702
    edited 2012-12-22 08:29
    What about a MCP23008 - i2c 8 input/output port expander? Plus multiplex the data/address bus?
  • Vega256Vega256 Posts: 197
    edited 2012-12-22 08:49
    Mike G wrote: »
    What about a MCP23008 - i2c 8 input/output port expander?
    Very cool. I'll put some serious thought into getting some of these for future applications.
    Mike G wrote: »
    Plus multiplex the data/address bus?
    That's a good idea too.
  • Mike GMike G Posts: 2,702
    edited 2012-12-22 08:58
    Vega256, you realize the EEPROM is using an I2C bus, correct? The port expander will give you the the ability to read the active low interrupt using the "EEPROM Pins".
  • Vega256Vega256 Posts: 197
    edited 2012-12-22 09:30
    Mike G wrote: »
    Vega256, you realize the EEPROM is using an I2C bus, correct? The port expander will give you the the ability to read the active low interrupt using the "EEPROM Pins".
    Yeah. I was just thinking about another quick solution until I can actually get to one of those I/O expanders.

    The extra output I need for the Prop is supposed to be a vsync signal for video refreshing; it goes low every time a vsync occurs. This is to be connected to the uP's non-maskable interrupt line, because the uP has to do stuff while vsyc is happening. Instead of the Prop informing the uP, I'll just set up a 555 timer circuit set at 60 Hz, and feed that to the uP.
  • kwinnkwinn Posts: 8,697
    edited 2012-12-22 11:44
    Vega256 wrote: »
    Yeah. I was just thinking about another quick solution until I can actually get to one of those I/O expanders.

    The extra output I need for the Prop is supposed to be a vsync signal for video refreshing; it goes low every time a vsync occurs. This is to be connected to the uP's non-maskable interrupt line, because the uP has to do stuff while vsyc is happening. Instead of the Prop informing the uP, I'll just set up a 555 timer circuit set at 60 Hz, and feed that to the uP.

    Isn't one of the 3 video signals already a Vsync?
Sign In or Register to comment.