2nd Propeller Chip as additional ram?

Oldbitcollector (Jeff)

The topic of figuring out how to get more ram resurfaces here about every two months.
Some of us have experimented with a few options to give more memory to the Propeller
some of the I2C stuff that can had, but it occurs to me that why don't we just use a 2nd
Propeller running some specialized spin code (something small) and use it's available
memory as additional for the 1st Propeller?

An expensive solution compared to others, but one that might be very easy to implement
using whatever method suits us.

Idea? or Dud?

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS

Mike Green

If all you have is a 2nd Propeller, then it's not a dud. You could write an I2C slave or SPI slave in assembly and load it into a cog thereby freeing up all 32K of the hub ram to serve up. You could even have a multi-ported ram with multiple copies of the server running in separate cogs. If you can figure out some use for the other cogs, like some I/O functions that are memory mapped (video, keyboard, mouse, serial I/O), they could be shared among several other Propellers / Stamps / whatever.· The non-video functions could use cog memory for any buffering, only having the "last" buffer entry in hub memory.

tpw_man

I made a cog memory object, but I cannot find it on the forums, so that gets you an extra ~1.7K of memory per cog. Anyway, I think it would be a good idea. Only snag is figuring out the comms protocol.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!


Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com

Cluso99

The protocol between the props is not difficult but it does depend on how many i/o pins you are willing to sacrifice. Serial is much slower. You could do nibble transfers for 5 or 8 pins.

Back in the dim dark ages, I did a 9 wire interface between 2 single chip micros to seperate 2 time critical tasks. I used an 8 bit (bi-directional bus) and 1 bit to indicate transfers/handshake. This method only allows 255 code transfers, else you require 2 transfer/handshake pins.

Remember though, you now have another 32 pins available, so you could also offload something to the second prop.

Xilinx have some dense serial eeproms for loading their FPGA's. Maybe you could add one of these also??

Now that there is a lot more understanding of the way the prop works (hub layout, etc), hub code could be laid out much better and any cog that needs loading could be loaded from flash directly (with the aid of a new simple loader). This would free up much of the hub ram. "Food for thought.."

John Abshier

An alternitive to loading a cog from flash directly may be as follows: A cog is loaded with PASM. The DAT section is copied to cog memory. Could one not then use the hub memory where the DAT section was for variable storage, say a buffer?

John Abshier

Oldbitcollector (Jeff)

Actually I was thinking of using a more "traditional" type interconnection between each Propeller,
with an 8bit bus and a some control bits. Just unsure how I want to address more than 255 bytes
of memory. Of course there is some trade off of I/O in this method, but returns in speed.

Could just go for wider bus.. [noparse]:)[/noparse]

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS

Mike Green

My earlier suggestion was that there be one or more assembly programs in a DAT section and the main Spin method just starts each one in turn. The last COGINIT overwrites the Spin interpreter in cog 0. At that point, all 32K of hub memory is available for other uses.

Ale

I implemented this using a 4 bit bus with some "commands", 32 bit words that include address and command and an optional byte of data for writes. To speed up the process the command is in fact an address in the slave's COG RAM where the command starts. No jump table, no hassle... supposedly. That way I found that org does not reserve space. What is org good for then ?, nothing, sorry. That was for the 6502 simulator we where talking about some months ago.

Edit: I forgot to mention that I use Beau's 4 bit method.

Post Edited (Ale) : 10/24/2008 10:49:37 AM GMT

hippy

A second Propeller as RAM is an excellent idea. It may not be as cheap as all other possibilities nor as fast to access but certainly viable. Here's my own I2C Slave RAM adventures ...

http://forums.parallax.com/showthread.php?p=721563

I2C, SPI, 'RS232' and parallel bus interfaces can be used. It doesn't have to be RAM, it can be FIFO or LIFO, even ROM, single port or multi-ported. A single Propeller chip can support a mix of interfaces, shared or separate memory compartments.

I2C is perhaps the most useful because access objects exist and are easily written and tailored, clock-stretching can ensure the master runs as fast as it can but doesn't run too fast. It also allows the I2C RAM Propeller to also be used as an I/O expander, even a TV / Video driver, and it can have physical serial or parallel bus RAM added so an entire RAM module is 'abstracted via I2C'.

If one wants a genuinely unlimited erase cycle I2C RAM of large size using a Propeller this way isn't really that expensive. Using the techniques of multi-Propeller daisy-chain booting quite large I2C RAM can be built just by adding more Propeller chips although it will be slow to boot. The Propeller Mk II should allow 256Kx8 I2C RAM.

Using the master to boot the slave Propeller, addition of an extra Propeller requires little more than adding the extra Propeller chip.

SPI is an alternative to I2C and could allow MMC/SD Card emulation.

If I were looking at a parallel bus interface, I'd consider presenting the Propeller as an IDE HDD as a possibility, though that may require additional hardware interfacing for high-speed access.

dMajo

tpw_man said...
I made a cog memory object, but I cannot find it on the forums, so that gets you an extra ~1.7K of memory per cog. Anyway, I think it would be a good idea. Only snag is figuring out the comms protocol.