Realistic Dual Propellers

Oldbitcollector (Jeff)

All of the discussion in the Prop Supercomputer thread has had me thinking about what could be done
easily (By a hobbyist like myself) to link two props together. Baggers has demonstrated that a
second Propeller is the ticket for better video. But what if you just had two Protoboards?

Here's a concept I'm working toward.. (See the pic) Using a slightly modified CDaudio cable.
(Great idea Brian!) One could tie a couple protoboards together with a Highspeed serial link.

I've just started on investigating a conversion of graphics.spin to implement FullDuplexSerial.
(I don't think it'll be that tough) A full-featured video driver linked with something like HSS to
create an "output" propeller, leaving the first one for input (Keyboard,etc) and the running software.
I think there's enough room to create drivers that would be backward compatible with existing games/programs.

Does anyone see any holes in this? Or see a bigger picture of where this could go?

Oldbitcollector

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.

— Calvin, of 'Calvin and Hobbes.

Greg P

One approach just occurred to me ....

Could one use the uOLED-96-Prop - with its access to potentially 2GB of storage via its uSD socket - to store multiple 32kbyte EEPROM equivalents ? Using already provided PropellerLoader demo code have the Propeller on the uOLED-96-Prop dish out using 3-wires (Rx,Tx,Reset) 'boot' code for one or more other propellers. To avoid limited general-purpose i/o pin availability on the uOLED-96-Prop use the example of one of our forum members who shows us how an I2C interface can 'talk' to a chip with multiple i/o pins, an pin expander IC.

In this hypothetical case, you read 'boot' data from the SD card, then via an I2C interface, drive MULTIPLE other Propellers. These Propellers would already be wired together much like what Chip has already described... in an array of horizontal and vertical buses.. for data exchange.

Granted, this doesn't address at all what one could then DO with such an array of propellers. But it does provide a rather simple means of configuring so many chips. Presumably high-level parallel processing design software on the PC would decide what code needs to be loaded into propellers 1 thru N, it would then write boot files 1 thru N to a uSD card (via its USB drive adapter). You could then load the SD card into the uOLED-96-Prop and it, in turn, would power up all N propellers with running code.

Just a thought.

Mike Green

GregP,
That's a good idea. You could use I2C I/O Expanders to drive the reset lines of the multiple Propellers and a multiplexor for the receive line. The other Propellers could all hang off the transmit line from the "master" (maybe through a buffer). A single 8-bit I/O Expander and one 8-input multiplexor would be all you'd need to handle 4 other Propellers. If you added an 8 bit decoder (for the reset lines), you'd be able to handle 8 other Propellers with a few I/O pins to spare.

Ym2413a

Jeff, Something like that would have so much power for a PropComp. (Propeller-Computer)
That it would blow everyones mind.

You would get this question a lot: "Is that really a Propeller Based System? No way?"

The trick is to come up with a way to get the data to transfer between the chips fast enough. [noparse]:)[/noparse]

grindel

I probably should refrain from posting in topics I know nothing about, but could you dynamically scale the linking between propellers? Like normally have 2-3 parallel lines of communication, but when the going gets tough, start shutting them down and let the processors crank for a bit and then open up the floodgates with 6-7 parallel lines when they finish up?

Ken Peterson

I've been toying with the concept of dedicating a propeller to doing graphics for some time now. I was also thinking of adapting the graphics object to use commands through the serial port (or perhaps SPI). So I think it's a good idea.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

Peter Jakacki

I have various schemes I am using for multiple props. One design I am using at present for a multichannel high-speed sorter/counter uses 2 props in the head end that handle 6 analog inputs each and communicate with the control end via RS-422 drivers. The RS-422 drivers are little 8-pin chips that transmit and receive over balanced lines at high-speed plus they allow me to directly communicate with each prop for debugging and programming. The control prop also talks to another I/O prop locally plus the control prop implements the serial I/O, RS-485 PLC coms, VGA, keyboard stuff etc. I am using a comport object based upon the original but basci FullDuplex for all the serial coms.

It would have been possible to combine the slave props onto a single RS-485 but this scheme can run them all in parallel as well as allowing central reprogramming.

So all in all I have 4 props in this design and although they run independently the control prop can reload any of the slaves or the slaves can be serially debugged from the master.

By adding a biasing and a current-limit resistor the RS-422 inputs become RS-232 compatible as well.

*Peter*

Baggers

Oldbit, my only advice well two bits of advice,
1. Use more than two pins for IO, as you'll need to get data across quickly, to the other prop.
2. Don't have one prop doing sound and graphics, just dedicate it to graphics, put the sound driver on the main board, as trust me, you'll want most of the ram for graphics on the second prop.

Baggers.

rjo_

Oldbit,

I have two conflicting ideas... ye' old "same data" and "same process" connundrum.

Since this looks like a potential node structure... if you would modify the adapter to the second Prop... so that the same data can flow to a multiple props, then we just need to ask for a handful of abstractions[noparse]:)[/noparse] See jpg.

The alternative would be to two more sets of connectors to second prop... and make a pyramid scheme out of it...there's gold in them thar hills[noparse]:)[/noparse]

Spin Studio SuperComputer Node?

Love it.

Rich

rjo_

OK... I'm tired... and there is another... how again am I supposed to post edit this?

Oldbitcollector (Jeff)

I suppose that we could apply the same theory that Ethernet uses, attach all Props together on the same bus,
every prop listens to all communications, but only acts on the data addressed to it.

Oldbitcollector

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.

— Calvin, of 'Calvin and Hobbes.

rjo_

yep... and just about any problem can be adapted to that structure.

rjo_

there is a limit to what can be done without amplification... not a clue... maybe add a smidge at every turn.