using pins P31 and P30

dr hydra

I have a project that is running out of pins on the propeller. I am looking at using P31 and P30 as needed extra pins. First, is that possible? Second, how does programming the chip effect those two pins usage. And does it matter if they are input or output pins after resets/programming?

JonnyMac

It's possible, but I don't think a very good idea -- you have to ensure that what you connect to these pins will not interfere with programming or debugging.

Pins 28 and 29 are the I2C buss and you can easily expand (low-speed) IO with a variety of devices that can share these pins.

hatallica

In a recent project, I used the "TX" pin (P30, I believe) as an output to the Parallax serial LCD module. So, I kept its native function.

During testing, writing code to the Propeller would result in some goofy characters on the LCD. I could live with this interference, as it was harmless and would be almost immediately cleared when the code ran.

For anything more consequential, I would first heed Jon's suggestion to look for opportunities to expand use of existing busses (I2C, SPI ... maybe even a shift register if practical). In a real pinch, I suppose that a jumper or switch could isolate program/run functions for these pins, but that becomes quite cumbersome.

dr hydra

Thanks for the replies. It looks like I will be one pin short, therefore, I might try using just the "tx" pin (P30) as suggested. My project is going to include a NES type controller (3 pins), so I'm going to try using the p30 for the latch. I'm guessing that should be the least likely item to conflict with the propeller operation. Any thoughts/additional concerns??

Peter Jakacki

Plenty of thoughts but very low on actual information in regards to pin usage and how you are using them so that this could be optimized. Care to share?

dr hydra

It's a game system with NTSC video out (3 pins) P24,P25 and P26. It's going to include a 128x8 SRAM. I only need 16K of the SRAM, so 14 pins (P0-P13). The SRAM control circuit has 4 connections, however, three of them can be tied Vcc or Vss and one controlled (write/read) by the propeller (P14). Then 8 data lines p15 -p22. That leave p23, p27 and ??? for the NES controller clock, data, and latch lines.

Peter Jakacki

Here's a thought:

Since clock and data are always validated by an enable or latch signal then it doesn't matter if they are hooked up elsewhere, such as address line. Despite the "junk" that may seem to on these lines it is only the last valid bits that are latched anyway.

btw, I normally dual-purpose the EEPROM I2C bus pins as clock and data out so perhaps you could use P28 as your clock then P27 for your data in from the NES and P23 for the latch.

dr hydra

Peter,

Great ideas! thank you for your help

Peter Jakacki

The latch signal is non-critical so you could even connect it to one of the SRAM address lines and then you have a spare I/O.

Cluso99

In my RamBlade circuits (RamBlade3 is best), I use P0..P18 for SRAM address 512KB, P19..P26 for Data, P27 is /CE, P28..P29 is also used as /WE & /RD (cannot recall order), then P30..P31 for SO & SI (can reuse as 1pin video out & 1pin Keyboard PS2 in).
BTW I also have an SD card connected.

The point is you can reuse the CLK (IIRC P28) if you are not toggling SDA (P29) and it will not upset EEPROM. Use P24..P26 as your Video.
This leaves you plenty of pins free for what you need.

dr hydra

@Cluso99

Thank you for the reply...what type of chip is U3 on the RamBlade??

Cluso99

74LVC1G11DBV (RamBlade)
74LVC1G97DBV (RamBlade3)

Clock Loop

Depending on the device you are connecting, you can simulate having more than 32 pins also...

I actually use ALL pins on the prop to light up 16 RGB leds.
If you do the math...
Each Led has 3 colors, and one common.
3 colors - 3 pins X 16 leds = 48 pins.
Then add 16 common legs on each led...
This equals 64 pins required.

I was able to light all 16 rgb leds using pwm.
The limit is that some of the leds cannot be lit simultaneously.

I did it by pairing up a leg on each led with another leg on a separate led, thus only requiring 32 i/o.
(64 i/o divided by 2)
Because the leds have a common, this enables you to disable any set of leds while doing work with a device on those same pins.
This device HAS an eeprom, and was programmed with all leds in circuit, using p30 and p31 with PropTool and a prop plug. This is possible because the programming procedure uses reset to start the programming process before the prop chip runs the program in eeprom.
And because my commons are tied to an I/O , they float until the program tells them not to.

Video demo:

It all really depends on WHAT devices you have connected to the pins.
Simply controlling a peripheral's VCC power supply using a prop pin, might let you reuse the rest of the peripheral's i/o for a second peripheral. Parasite power could be an issue, but if the VCC line of a peripheral is tied to gnd, using the prop i/o, i would guess the parasite power might get sucked outta the peripheral chip, letting you use the second peripheral chip as you need, powering the second peripheral chip with yet another prop i/o. Total engineering hack, dont do it if you are making a pacemaker.

jac_goudsmit

I know I'm late to the party, but I'd like to mention that if you keep the SDA pin (29) high, you can use the SCL pin (28) for pretty much any output without fear of triggering the EEPROM.

In my projects, I use pin 28 as a 1MHz clock output for a 6502. The 6502 gets a lot of clocks while the Propeller is booting from the EEPROM of course, but that's not a big deal because the 6502 needs to be reset after the Propeller is running anyway.

(See https://hackaday.io/project/3620 for more info)

===Jac

Toby Seckshund

A long time back I put a CD4053 chip on the I2C lines. At startup the gates would naturally switch through to the EEPROM so boot was normal - then HSYNC activity would diode pump the select pin(s) up and allowing those two lines to be switched for other things, allbeit via the internal resistance of the cmos. I has the I2C pull up resistors on the EEPROM side of the switches just to keep the EEPROM happy(ish).

I also only used single RGB pins so that grabed back a few more.

Alan