Shop OBEX P1 Docs P2 Docs Learn Events
Sharing I/O pins 28&29 with EEPROM and 30&31 with PropPlug — Parallax Forums

Sharing I/O pins 28&29 with EEPROM and 30&31 with PropPlug

agsags Posts: 386
edited 2013-09-07 01:33 in Propeller 1
From review of specs and some schematics, I've concluded that I can share I/O pins 28 & 29 with the EEPROM that contains program data that is loaded on reset (if a host is not detected on pins 30 & 31). I'd appreciate confirmation of what I've deduced:

1) Pins 28 & 29 can be shared with another I2C device
2) The I2C device can be any device as long as it uses 7-bit slave address (some use 10-bit) and is not assigned address $00.

Are there any other limitations?

I'm also considering re-purposing pins 30 & 31. I would need to support ISP using the PropPlug. If the PropPlug is present at reset (or forcing a reset) my program won't be running (yet) so I see no issue/conflict. What's not clear to me is what happens after the programming is complete, my program is loaded and executed. If it is using pins 30/31, with the PropPlug connected, will there be an issue? I suppose I could just always expect that "bad things" happen after reboot when the PropPlug is connected; I would disconnect the PropPlug and reset again, now without any conflict. That seems just messy though. When the PropPlug is connected, but not actively programming, is PropPlug TX (Propeller RX) floating? When the PropPlug is connected by not actively programming, is the PropPlug RX (Propeller TX) ignored?

Comments

  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-09-05 10:15
    I think that a conservative approach to repurposing these two groups is best.

    Pins 30 and 31 can be easily use for RS232 communications, other purposes might require a hard reset to get back to serial communications. I use these for an active Forth dumb terminal communications up to 3Mbaub via USB.

    Pins 28 and 29 can be shared with other i2C devides if addressing is followed or chips are toggled as active or not. But the easiest exploit is a larger than normal EEPROM. Other exploits may begin to require Propeller i/o to operated a chip enable scheme.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-09-05 11:02
    ags wrote: »
    From review of specs and some schematics, I've concluded that I can share I/O pins 28 & 29 with the EEPROM that contains program data that is loaded on reset (if a host is not detected on pins 30 & 31). I'd appreciate confirmation of what I've deduced:

    1) Pins 28 & 29 can be shared with another I2C device
    2) The I2C device can be any device as long as it uses 7-bit slave address (some use 10-bit) and is not assigned address $00.

    You can pretty much use any I2C device as long as it doesn't have the same address as the EEPROM. Different types of I2C devices have a different bits set as address bits in the higher bits. I don't think the EEPROM address is $00. (I don't recall what it is off hand.)
    ags wrote: »
    I'm also considering re-purposing pins 30 & 31. I would need to support ISP using the PropPlug. If the PropPlug is present at reset (or forcing a reset) my program won't be running (yet) so I see no issue/conflict. What's not clear to me is what happens after the programming is complete, my program is loaded and executed. If it is using pins 30/31, with the PropPlug connected, will there be an issue? I suppose I could just always expect that "bad things" happen after reboot when the PropPlug is connected; I would disconnect the PropPlug and reset again, now without any conflict. That seems just messy though. When the PropPlug is connected, but not actively programming, is PropPlug TX (Propeller RX) floating? When the PropPlug is connected by not actively programming, is the PropPlug RX (Propeller TX) ignored?

    The PropPlug will only cause a reset if the Prop is transmitting data. Otherwise it shouldn't cause a problem. At least this has been my experience.
  • agsags Posts: 386
    edited 2013-09-05 11:30
    Duane Degn wrote: »
    You can pretty much use any I2C device as long as it doesn't have the same address as the EEPROM. Different types of I2C devices have a different bits set as address bits in the higher bits. I don't think the EEPROM address is $00. (I don't recall what it is off hand.)
    You may be correct. I checked the schematic in the Propeller Manual and assumed that since all three address pins were tied low that set the address to $00, but it may well just be setting the lower bits. I'd have to look at the datasheet to be sure.

    Edit: Confirmed with 24LC256 datasheet that the device I2C address is 1010xxx, where xxx is set by the three pins A0:A2. This means that the Propeller Loader/Monitor is hardcoded to use address 1010000, I suppose. I never stopped to think that this needs to be taken into account when considering any replacement for the "standard" EEPROM used. The address, and address length (7 bits) must be the same.
    The PropPlug will only cause a reset if the Prop is transmitting data. Otherwise it shouldn't cause a problem. At least this has been my experience.
    Is the PropPlug Tx line (Propeller Rx pin) tri-stated when the PropPlug is not actively programming?
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-09-05 11:45
    ags wrote: »
    Is the PropPlug Tx line (Propeller Rx pin) tri-stated when the PropPlug is not actively programming?

    I don't know what the PropPlug's Tx line is doing. I'd think it would be off since the PropPlug wouldn't have any power. The reset issues arise because the Prop's Tx line provides enough current to power the PropPlug when data is being sent to the PropPlug. As long as the Tx (P30) stays an input or low, the PropPlug shouldn't be getting any power.
  • agsags Posts: 386
    edited 2013-09-05 12:50
    Duane Degn wrote: »
    I don't know what the PropPlug's Tx line is doing. I'd think it would be off since the PropPlug wouldn't have any power. The reset issues arise because the Prop's Tx line provides enough current to power the PropPlug when data is being sent to the PropPlug. As long as the Tx (P30) stays an input or low, the PropPlug shouldn't be getting any power.
    Once the PropPlug is disconnected I presume there is not issue (unless whatever else I connect to these pins would actively drive the lines, which during startup the Propeller could mistake for a connected host. I can prevent that from happening).

    I'm considering the one-time-per-programming situation where the PropPlug is connected and downloads a new image to the EEPROM (or RAM). When complete, the Propeller will reboot, and the PropPlug will still be connected - but not actively programming. It's not clear to me that the power to the PropPlug will be removed immediately after programming is complete.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-09-05 13:01
    ags wrote: »
    I'm considering the one-time-per-programming situation where the PropPlug is connected and downloads a new image to the EEPROM (or RAM). When complete, the Propeller will reboot, and the PropPlug will still be connected - but not actively programming. It's not clear to me that the power to the PropPlug will be removed immediately after programming is complete.

    You mean when it's still connected to an active USB line? If so then even if the Prop outputs on P30 it shouldn't reset.

    Plugging a USB in to a PropPlug connected to a Propeller will likely cause a reset. It seems like whenever I plug a Prop board in to a PC, it usually resets.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-09-05 13:06
    If the PropPlug is disconnected from the USB cable, outputting on P30 will cause a reset. It's always best to unplug the PropPlug, rather than just the USB cable.

    -Phil
  • agsags Posts: 386
    edited 2013-09-05 17:43
    This question is in the context of a PropPlug connected to a PC through a USB cable to flash a new program to EEPROM. I will disconnect the PropPlug after programming. However, immediately after the programming is complete, the Propeller is automatically reset and will boot the newly loaded program - before I can remove the PropPlug. I'm asking about that one-time-per-reprogramming situation.

    I found a schematic for the PropPlug. The 150 ohm series resistors on Rx/Tx means that even if I were driving the Propeller pin connected to the PropPlug Tx pin, the worst case would be 33mA if there is contention, so that's OK. If I had that Propeller pin configured as an input, it will be high/low, or tristated but constant if the programming is complete, so that's OK. If I have the Propeller pin connected to the PropPlug Rx pin configured as an input, it will just float, so that's OK. I suppose it's possible that if I had that Propeller pin configured as an output, using it for signaling, if I had just the correct bad luck I could cause the PropPlug to think it was receiving some valid communication meant for it - but I guess that is unlikely, and I'm not even sure if there anything listening in that case. The Propeller Serial Tool listens, but that wouldn't be running.

    Is this analysis correct?
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-09-07 01:33
    One-time re-programming is done by loading directly to RAM and not rewritting the EEPROM. Do not flast the new program to EEPROM.

    There are some I2C devices that just conflict with eachother and require a separate bus. This is not inherently a Propeller problem, but some builders get overly ambitious and try to put all and everything on P28 and P29. There may also be a reasonalbe limit to the number devices will share the bus.

    As a rule of thumb, carefully adding one or two devices can work. But one has to verify that the addressing scheme and chip enable scheme are going to play nice.

    I have experienced the reset from unpluging the USB first rather than the Prop Plug to board interface.. rather annoying. But if you do follow the right proceedure, you don't trigger a reset.
Sign In or Register to comment.