2

I am using a P8X32A (Parallax "Propeller" microcontroller) in many of my hobby projects. It has no NV RAM internally on the chip so it loads its program code from either a serial port TX/RX pins or from an I2C EEPROM (24LC256) on SDA/SCL pins. This loading is entirely handled by the silicon on the micro and cannot be altered.

It takes no more than about 2 seconds or so for the code loading process to complete, after which time those four pins become fully general purpose IO in the 4 MSBs of a 32bit GPIO port! That's a pretty great feature, but it does mean I need to treat those 4 pins as a special case, which is not ideal.

  • From the P8X32A Manual v1.2 (page 17). The jagged red line indicates the 4 signals I want to redirect after booting has completed. enter image description here

For a future project I'm planning I would like to use all 32 pins of this GPIO port for high speed IO but I do not want to still have the top 4 pins connected to the serial port or the I2C bus.

My question:

What would be a robust, minimal part-count method for automatically severing the I2C and serial port lines from the microcontroller a fixed time after coming out of RESET state?

I can think of a few ways initially, but they have disadvantages...

  1. Have an I2C controlled 4 pole 2 throw digital switch IC that shares a reset line with the microcontroller. At startup the 4 signals are connected by default to the I2C bus and serial and then the first thing that the program code does is to send an I2C command to that switch to toggle away from the I2C bus.

  2. Use an externally generated signal (basically a dumb timer or a cheap secondary microcontroller that can respond to the reset pulse) to toggle a "normal" logic-level activated switch.

  3. Put a second small microcontroller (e.g. ATTiny2313 or similar) in between the Propeller and the EEPROM, then simply have it count the number of bytes that passes through it and then shut down it's own IO completely until the reset pulse.

I don't like (1) because I'd need to implement the small bit of I2C in my program code, which is annoying but doable, but the main problem is finding a suitable I2C switch in a SOIC/SOP package.

I don't like (2) because it adds some potential for glitchiness or timing issues to creep in. Or if I go with a second microcontroller (ATTiny5 for instance) I'd have to have either a programming header on the board or have the chips pre-programmed off board. A hassle either way.

I don't like (3) because it's alot of work and adds a second set of fairly fiddly firmware to the project, which I'd rather avoid.

I suspect I'm over-thinking this, is there a better way to disengage an I2C bus completely after I've finished using it?

The "high speed IO" I want to have all 32 GPIO pins involved with will be 3v3 digital logic running anywhere between 1MHz and 40MHz.

  • (2) does not introduce timing problems when you use a CMOS multiplexer as the 4053. It has transmission gates so the transfer delay is very short. – Janka Nov 25 '16 at 13:12
  • This might be of interest: http://electronics.stackexchange.com/questions/258281/how-to-isolate-i2c-bus-when-master-is-being-programmed – Wesley Lee Nov 25 '16 at 16:30

1 Answers1

2

Here is my suggestion (hope it makes sense):

We have a quad 2-to-1 multiplexer to toggle the signals, as you suggested. A RS latch is used to decide the routing of the multiplexers. On MCU reset, the latch output routes the signals to the "startup" destination (plug/EEPROM). Now, the trick would be to use a fifth port of the MCU to switch from the startup state to the normal state, as soon as your program starts.

schematic

simulate this circuit – Schematic created using CircuitLab

Of course, you'll say: "but then one of my port is dedicated to this task, so I can't use it anymore! I want to be able to use all my ports!" (yes, you'll say that, I can even hear you from where I am).

Well, the thing is, once you are in the normal state, this signal has no effect anymore on the latch (until it is reset, of course). So you can actually use it for anything else at this point. The only drawback is that this signal will be toggled from high to low at startup (you can toggle it back high after). I'm sure you can find a signal in your application that can tolerate this behavior (a LED output, or anything not critical).

dim
  • 15,845
  • 3
  • 39
  • 84
  • Yep, you did literally read my mind :) Your method does look very neat and tidy though, despite the rogue pulse being necessary. Hmm, it's almost like I need a 2-bit shift register to conceal the first pulse from the rest of the circuit. I shall consider this. –  Nov 25 '16 at 19:35
  • The problem with a shift register is that it will delay your signal, even once you switch to normal mode. And what do you feed as the clock, what do you feed at the data input of the shift register? Maybe, instead, to swallow the initial pulse we could imagine a scheme with a D flip flop rather than a RS latch, but before switching my brains back on, I'd like to confirm that, really, there is no GPIO that could tolerate this glitch. What is the use for these 32 GPIO, exactly? – dim Nov 25 '16 at 20:27
  • Long I have had in my mind the desire to create a high frequency, low voltage signal generator, with the ability to become a logic analyser by changing the firmware. Now my specific requirements are extremely narrow and specialised and very likely not really useful to anyone else. As such it woud basically be a piece of test gear and it would be rather nice to avoid sending that rogue pulse to the "device under test". However this SE question need not concern itself with my specific plans because (as you have demonstrated) Propeller users sometimes want to use ALL their IO :) –  Nov 25 '16 at 20:34
  • Ok, I understand. Well, I was just asking so that I can have an idea of where the compromises can be made, eventually. But actually, solving this isn't that easy, then. I'm afraid complexity would make it not worth it. I'm not familiar with propeller, but maybe it would actually be simpler to pick a device with more GPIO, if it exists. – dim Nov 25 '16 at 21:06
  • I can heartily recommend looking into the Propeller if you're interested in exotic microcontrollers. I find it a very interesting platform with some unique features. (I don't work for them by the way, just an enthusiastic customer :)) There is a 10-year long ongoing wait for the Propeller 2 chip which is as close to alien technology as anything I've ever heard of but there seems to be no release date for that yet. If you want some interesting reading, grab the P8X32A's "Manual" and flip to the sections about the Hub, the Cogs and the Counters. –  Nov 25 '16 at 21:13