Shop OBEX P1 Docs P2 Docs Learn Events
Using pins 28-31 after boot — Parallax Forums

Using pins 28-31 after boot

KallikakKallikak Posts: 8
in Propeller 1
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

  • Peter JakackiPeter Jakacki Posts: 10,193
    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?
  • Hal AlbachHal Albach Posts: 747
    edited 2018-09-10 14:57
    Probably a quad bilateral switch.
    Muxes are usually unidirectional and may interfere with I2C at bootup.
  • JonnyMacJonnyMac Posts: 9,103
    edited 2018-09-10 16:32
    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.
  • KallikakKallikak Posts: 8
    Peter Jakacki wrote: »
    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: 9,103
    edited 2018-09-11 14:12
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-09-10 22:33
    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.
  • RaymanRayman Posts: 14,644
    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...
  • MIchael_MichalskiMIchael_Michalski Posts: 138
    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.
  • Cluso99Cluso99 Posts: 18,069
    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.
  • Mark_TMark_T Posts: 1,981
    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.

  • Toby SeckshundToby Seckshund Posts: 2,027
    I did this, using 4053 bi-latteral C/O switches (only about 100 Ohms (@3.3V, added to the data path).

    As I was using it on a DracBlade circuit I used the start up of the Horz syncs to drive a diode and capacitor to raise the DC to do the switching of the I2C lines. That made sure that all of the transfer to the Prop had finished before anything got disconnected.

    I made sure that there were a couple of pull up resistors on the "eeprom" side to keep things happy.
  • Toby SeckshundToby Seckshund Posts: 2,027
    I forgot to comment on the SR latch approach - I tries that and fell out of love with it very quickly - I could never get it to hold in the "bypassed mode" - I seem to recall that ther was a couple of transitions that came either too early, or too late to be reliable as a switch. I was looking at the Prop boot code ... never did anything with it as I then used the H Sync as a definite "I have finished ... long ago ..." and as that pin was being useful - it wasn't as if I had handed back one of the pins .

    All that was a few years ago ...
Sign In or Register to comment.