Forum Update - Announcement about May 10th, 2018 update and your password.

Using pins 28-31 after boot

Hi,

I am wondering what people here think of the suggestion from this post:

https://electronics.stackexchange.com/questions/271448/microcontrollers-disconnect-i2c-and-serial-lines-after-loading-from-eeprom

Here's the circuit:
aHXJa.png

The idea looks good to me, but I'm wondering in particular whether transients in the S-R latch on powerup will be problematic for the EEPROM loading.

Ken

Comments

  • 10 Comments sorted by Date Added Votes
  • I avoid "trying" to use these pins unless I really needed every last fast I/O pin which fortunately has not happened yet. Usually there is other stuff hanging off on shift registers, I2C, or another micro via serial etc. IF you have leds and switches etc connected to any I/O pins then obviously these can be moved onto I2C which uses the same two pins as the EEPROM. How are you utilizing all your existing pins now?

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • Hal AlbachHal Albach Posts: 722
    edited September 10 Vote Up0Vote Down
    Probably a quad bilateral switch.
    Muxes are usually unidirectional and may interfere with I2C at bootup.
    Florida, between St. Petersburg and the Gulf of Mexico

    Do not look directly into laser with remaining good eye...
  • JonnyMacJonnyMac Posts: 6,084
    edited September 10 Vote Up0Vote Down
    In my world, pins 31 and 30 are used for debugging, and pins 29 and 28 are used for I2C devices. Period. End of story. IMO, attempting to do other things with these pins is inviting trouble.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • I avoid "trying" to use these pins unless I really needed every last fast I/O pin which fortunately has not happened yet. Usually there is other stuff hanging off on shift registers, I2C, or another micro via serial etc. IF you have leds and switches etc connected to any I/O pins then obviously these can be moved onto I2C which uses the same two pins as the EEPROM. How are you utilizing all your existing pins now?
    It's nothing particularly crucial, but I'm trying to combine two projects onto a single board, and it's putting some pressure on pin usage.
    Hal Albach wrote: »
    Probably a quad bilateral switch.
    Muxes are usually unidirectional and may interfere with I2C at bootup.
    Yes. I'm sure he means using an analog switch.
    JonnyMac wrote: »
    In my world, pins 31 and 30 are used for debugging, and pins 29 and 28 are used for I2C devices. Period. End of story. IMO, attempting to do other things with these pins is inviting trouble.
    I understand avoiding when possible, but if the pins are available for general use after boot it seems reasonable to consider using them.

    I think 50ms to boot after transition from low to high on reset will ensure the approach is effective.

    Ken
  • JonnyMacJonnyMac Posts: 6,084
    edited September 11 Vote Up0Vote Down
    I understand avoiding when possible, but if the pins are available for general use after boot it seems reasonable to consider using them.
    Sure -- for the same purposes they serve during the boot process.
    I think 50ms to boot after transition from low to high on reset will ensure the approach is effective.
    Your code cannot run until it is loaded into RAM. Once your code is running, it is free to use the pins -- no timing from reset is required.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • Peter JakackiPeter Jakacki Posts: 7,577
    edited September 10 Vote Up0Vote Down
    I will try again in reasoning with you and I am of the same mind as Jon and many others in that you should treat these pins as reserved for programming, for loading, for debugging, for general-purpose I2C etc, i.e. they are not general purpose for anything. There are so many many ways of accommodating extra I/O without adding switching gates and some hopefully reliable way of controlling them.

    P28,29 are connected to the I2C bus of the EEPROM and as the name implies, it is a bus that is shared with other devices, most commonly RTC chips but also many others such as I/O devices. I also use these pins as clock and data for shift register outputs in which case I just need one other I/O as the strobe and clocking data does not interfere with I2C chips since their "chip select" needs a start condition and device address anyway. Besides my software needs to use EEPROM because it is also general-purpose non-volatile memory and I use the upper 32k or more for driver objects, logging, settings, etc.

    P30,31 I use constantly since I use Tachyon for programming and debugging and on many occasions I also have Bluetooth serial connected to these pins.
    I won't go into the many ways I use and need these pins for communication because the forum software has a limit on the message size and there is no point in listing the many reasons why in much the same way we might not try to explain why we can't just tape our mouth shut between meals, since you might reason that you only use it for eating (uh uh, don't say a word).

    So while we might not even bother to comment on the merits and many pitfalls of your switching scheme, we are happy to comment on making effective use of the I/O that you need to use, if you would like to kindly list them. Obviously if you need it for "almost anything" then maybe you don't need them at all because if you need them at all then you know what you need them for.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • I'm with Jon. In general, it's best not to use these pins for other than I2C and serial.

    BTW: If your I/O is slow, there are plenty of I2C I/O expanders around...
    Prop Info and Apps: http://www.rayslogic.com/
  • The simplest solution for more IO is something like this. http://www.ti.com/product/tca9534

    Assuming that you have some GPIO that dont have to be particularly fast. You can just connect it up alongside the eeprom and your done.
    Particularly patient proactive practice positively predicates practically precise poly-processor Parallax Propeller programming paradigms.

    .
  • I have used these pins after booting for additional purposes such as the lines to SD and/or SRAM.
    You have to treat each design case on the pin requirements.

    So, if you are running out of pins, then you need to list what you are doing. Otherwise we cannot help. ie there isn't a generic solution here.
  • Kallikak wrote: »
    Hi,

    The idea looks good to me, but I'm wondering in particular whether transients in the S-R latch on powerup will be problematic for the EEPROM loading.

    Ken

    You'll need to have pullups on both I2C lines, note, and maybe on the TX pin too to avoid line noise. That should
    avoid any transients I think.

Sign In or Register to comment.