A Peripheral I/O bus for the Prop? - Does anyone see the need?

Painless

There has been a lot of activity in the forums lately on software and hardware that add (amongst other things) to the Prop:

- Extended memory
- Operating system based services
- Mass storage
- Better HID (Color LCD's, extended VGA modes)
- Multiple props for task offloading

I was wondering if anyone had given any thought to developing a standardized peripheral I/O bus for the propeller? I've been drawing up some rough schematics and principles for an 8 bit I/O bus system that would allow the connection of up to 8 expansion cards, each with it's own processor, using only 9 pins of the prop.

This bus would feature:

- 8 bit parallel data transfer (unsure of speed until the protocol is finalized).
- Regulated 3.3v and/or 5v feed for each card.
- Bus manager in 1 cog on the host propeller.
- Messaging system between application cogs and bus manager utilizing hub ram.
- Dedicated micro-processor on each card (surface mount prop?) for bus communication and task offloading.

Each peripheral card would use a 15 pin connector for communication with the bus, the pin-out would be something like:

1 through 8 - 8 bit data bus
9 - Attention pin
10 through 12 - 3 bit card address encoded via binary in hardware
13 - 3.3v
14 - Ground
15 - 5v

As I mentioned, this is all pretty much 95% in my head at the moment with some rough schematics and notes. I would like to get an idea of how much interest their would be in such a bus before I devote much more time to it. Is this something in which their would be great interest or a waste of valuable time?

I would intend the bus design to be a fully open source and free offering.

Russ.

Bill Henning

I've played with something similar, except beside the 8 data pins and the request pin, I had an "grant" pin; I was going to leave arbitration to software/external hardware; I also was going to bring out SCA & SDL to it.

Painless said...
There has been a lot of activity in the forums lately on software and hardware that add (amongst other things) to the Prop:

- Extended memory
- Operating system based services
- Mass storage
- Better HID (Color LCD's, extended VGA modes)
- Multiple props for task offloading

I was wondering if anyone had given any thought to developing a standardized peripheral I/O bus for the propeller? I've been drawing up some rough schematics and principles for an 8 bit I/O bus system that would allow the connection of up to 8 expansion cards, each with it's own processor, using only 9 pins of the prop.

This bus would feature:

- 8 bit parallel data transfer (unsure of speed until the protocol is finalized).
- Regulated 3.3v and/or 5v feed for each card.
- Bus manager in 1 cog on the host propeller.
- Messaging system between application cogs and bus manager utilizing hub ram.
- Dedicated micro-processor on each card (surface mount prop?) for bus communication and task offloading.

Each peripheral card would use a 15 pin connector for communication with the bus, the pin-out would be something like:

1 through 8 - 8 bit data bus
9 - Attention pin
10 through 12 - 3 bit card address encoded via binary in hardware
13 - 3.3v
14 - Ground
15 - 5v

As I mentioned, this is all pretty much 95% in my head at the moment with some rough schematics and notes. I would like to get an idea of how much interest their would be in such a bus before I devote much more time to it. Is this something in which their would be great interest or a waste of valuable time?

I would intend the bus design to be a fully open source and free offering.

Russ.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full

photomankc

I was thinking about something similar as a dual chip design where one chip was along the lines of the expanded memory boards people are doing and that being the brains of the two and a second running a similar bus to bring in more GP I/O. Right now I'm happy that I have blinking LEDs so a dual chip design is not something I need to jump into but the I/O expansion sounds like an interesting idea in it's own right. These chips really seem to shine as a way to do lots of small tasks rather than as monolithic GP computers anyway. More I/O might be more useful.

David B

I like the idea in general, but as someone who like to handbuild his own io cards, my preference would be to use a few more propeller pins so that the periferals can be simpler, and not need their own processor.

If the bus is general enough then much of what you might want to connect to the propeller can be connected via the bus, so it may not matter so much that the bus uses maybe 15 pins instead of just 9.

jazzed

One thing that came out of a previously similar discussion is that a hardwired ID is probably not necessary for an intelligent peripheral since an ID could be saved in boot EEPROM. That would allow the use of pin 10+ for signalling such as RD/WR*, REQ*/GNT, ACK, etc .... Using pin 9 for anything other than ATN* is probably a bad idea for performance considerations. I've also found that using high bits for signalling is better for one COG use since a LONG transaction can allow changing bits after the first shift. Reserving a pin for a clock controlled by Propeller would have value for synchronous transfers. For the most part, the simpler the better for a standard, and I would lean heavily in the direction of 11 or less pins if possible. If it "ain't generic" it won't be used.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Cluso99

I have thought long and hard about this and have commented previously.

PARALLEL BUS:
I don't believe a standard is possible because

• There are different requirements as to which pins to place the bus on
  • My RamBlade design requires the sram address pins on P0-P18 and data pins on P24-31
  • This is for speed and shifting but it complicates other things such as conflicts with the eeprom and SI/SO
  • My TriBlade uses a slower mechanism which places the data on P0-7
• Therefore, this is still a problem for me - I cannot standardise within·my own designs

SERIAL·BUS:
This is my preferred option because

• It is only 2 pins...
  • can run at ultra high speeds (Beau's example)
  • can use any bit length - address bits for the prop# plus data bits (8-32)
• To save having to arbitrate
  • could increase the pins used, 1 for each prop to transmit on which goes to every other prop
  • So, pins used = no. of props +1

Just my opinion.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

kwinn

Painless, a standardized simple bus is a pretty good idea. The only suggestion I would make is to use the 8 bit bus for data and addressing. Put out the peripheral address on one edge of the clock and the data on the other edge. You could use individual bits of the address to select one of 8 peripherals or all 8 bits as a binary address, or mix and match them.

Mike Green

I think we're much too early for any kind of standardized I/O bus. People are still doing a lot of thoughtful development of single Prop and multiple Prop systems for a variety of uses. I think that 2 or 3 different bus designs would be a good idea for now, probably with different applications in mind, each with (over time) a set of supported peripherals and base systems.

jazzed

The serial bus is standardized already one way or another [noparse]:)[/noparse]

Whether a parallel standard is necessary is debatable. One thing is certain though: If someone comes up with a proven good working solution and draft specification, others *can* follow if they need a parallel bus solution. Not everyone has the chops necessary to create a good solution.

It's better to stand on a rock than climb a sand dune.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Bill Henning

I agree

Mike Green said...
I think we're much too early for any kind of standardized I/O bus. People are still doing a lot of thoughtful development of single Prop and multiple Prop systems for a variety of uses. I think that 2 or 3 different bus designs would be a good idea for now, probably with different applications in mind, each with (over time) a set of supported peripherals and base systems.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full

Phil Pilgrim (PhiPi)

I agree with Mike. And if any standards emerge in the next few years, it will be because they've evolved on their own in a supportive marketplace, not because someone says, "Let's design a standard that everyone can adhere to," or because a committee gets together and makes up something that looks good on paper.

If you want to set a "standard", design and sell a family of boards that people will want to buy — and imitate. Effective standard-setting works from the bottom up, not from the top down.

-Phil

Painless

Thanks for everyone's input, I definitely agree with Phil that standards emerge from market support.

The main reason for starting this thread was that I wanted to work on this as my next project after my current one has finished. My current project involves using a propeller as a 'piggy back' device between a vehicle ECU and it's sensors, effectively allowing some control over air / fuel mixture and ignition timing while also providing pertinent information to the user. This project has currently been brought to a screaming halt due to my vehicle's ECU breaking and needing replacement, hence robbing me of my test platform., in light of this I thought I would do some basic research into the peripheral bus idea.

Thanks again,

Russ.