Prop over Prop piggyback

Newzed · 2007-01-13 00:54

The Stamp over Stamp piggyback turned out pretty well so I was thinking of a Prop over Prop piggyback.· The two Props would share Vdd and Vss, the top Prop (Slave) would have its own EEPROM, and each prop would be programmable via a Prop Plug.· They would share two pins for serin/serout communication.· Is anyone interested in such a piggyback?

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?

Newzed@aol.com
·

Newzed · 2007-01-14 15:23

After giving it some thought, I have come up with the final design for the Prop PB.· I have no control over the board circuitry for the Master - the bottom Prop - so I concentrated on the Slave - the top Prop.

Vdd, Vss and Pins P0-P7 will be brought to the top board. but P0-P7 will not be connected to the top Prop.· They will terminate in an 8-pos female header.· The user may select any two pins for serin/serout by jumpering from the Slave P0-P7 to the Master P0-P7.

The Slave will have a 5.00mHz 20pf SMD crystal and a 24LC512 SMD EEPROM.· Programming for the Slave will be via a Prop Plug.· Both the bottom and top boards will be 1.400 wide.· Depending on the Master board's layout there may be some interference between the bottom board and existing components on the Master board.· This can be overcome by plugging in one or two Prop DIP sockets before the piggyback is plugged in.· All 40 of the Slave pins are brought to two 20-pos females headers on each side of the Prop sockets.

I still have to complete the etch program, but pictures will be posted when the piggyback is completed.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?

Newzed@aol.com
·

Newzed · 2007-02-17 15:46

For Mike Green

Mike, I finally got my Prop piggyback working.· Because of interference from board components, I had to nest two Prop sockets underneath the piggyback.· Ordered from Jameco - they wouldn't work.· Ordered from Mouser and they wouldn't nest.· Finally ordered from Digikey and they work fine.

The bottom Prop is loaded with my regular program, modified slightly so it can talk to the top Prop.· The two Props share Vdd, Vss and Pins 0-7.· Pins 6 and 7 are used for serin/serout.· If I select the S option - Establish communication with Slave - the bottom Prop - Master - sends a "C" to the Slave.· If the Slave receives the "C", it sends back a message to the Master - "You are clear to send" -· than waits for the next instruction from the Master.

The Slave has a 512K EEPOM which apparently works fine.· I loaded both programs into their respective EEPROMs, turned the piggyback off, then back on, and both programs work just fine.

That is all I have done with it so far.· If you would like to have the piggyback for a few days to play around with , I can send it to you with two DIP Props installed.· It's quite a powerhouse - 15 free pins on the Master and 30 free pins on the Slave, all in about the same real estate used by one Prop.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Cyberbound · 2007-02-17 16:34

Is it possible to sync more than one prop to a single external clock source to allow multiple cogs running in parallel? Envision the power of a quad-prop board with shared RAM. Thoughts?

Mike Green · 2007-02-17 16:51

If you use an external clock, you can drive several Propellers off the same clock source. You can also have one Propeller as a master and several as slaves with an I/O pin on one Propeller connected to the clock-in pins on the slaves. The master does need to be initialized so that one of the cog counters works as a clock source for the other Propellers.

Cyberbound · 2007-02-17 17:36

So the idea of a quad-prop board isn't out of the question. I understand there would still be the need for a master/slave arrangement. But, is there a way to address the individual cogs across multiple props within a single program?

Lawson · 2007-02-18 03:45

I haven't seen anything like that yet. I think it'd require a way to network all the cogs. This network would also need full send/receive handshaking. (Handshaking for more than a point to point link is the part i don't have any good ideas for) I think it'd be fairly simple to make a I2C-like point to point bi-directional network driver for the prop in 32 asm instructions or less and two pins. (with handshaking of course) I wouldn't expect it to do much, just send 32bits at a time from point to point. (no addressing, error checking, re-sending, packets, etc) Another method would be to dedicate one cog per propeller to act as a network controller. This controller could then be used to allow memory in remote hubs to be addressed. (I wouldn't expect this to be very fast though)

my 2 cents,
Marty

P.S. maybe share 4 pins between the Props. Each pin would be a dedicated async-serial line for transmitting to one of the props with a cog in that prop dedicated to receiving data. (so each Prop would have one receive line and 3 transmit lines. So for prop-0: Rx, Tx_1, Tx_2, Tx_3 and for prop-1: Tx_0, Rx, Tx_2, Tx_3 and so on.)

paulmac · 2007-02-18 21:59

How about a 9 Prop setup.
One Prop is a dedicated hub, one cog for each of the other 8 Props, to manage communications between them and to hang shared resources off...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants

Newzed · 2007-02-19 14:58

Here is a picture of my Prop piggyback.· On the left you can see the Prop Plug used for programming both Props.· On the right you can see the keyboard and VGA connectors for the Master.· The yellow and blue wires supply 5 volts and Gnd to the regulator on the little XBEE board I made.· You can just barely see the screw terminal block at the end of the XBEE.· This is what I had to clear - hence the two nested sockets underneath the piggyback.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com

Newzed · 2007-03-03 14:49

For Mike Green:

Mike, I have the piggyback working pretty well. If I press "X" (Send data to Slave for storage), the Slave says "Ready to Receive". I enter 3 digits (temperature) on the keyboard, and the Slave responds with "Received data: XXX". At this point I would like the Slave to store the data (t1, t2 and t3) in EEPROM. The EEPROM is a 24LC512. If we start the storage at address $9C40(40,000), that would be more than enough room. The current EEPROM address could be stored at$FA00 (64,000).

When I press "D", it requests the Slave to accumulate EEPROM data. The Slave responds with:

Accumulating data:··· Standby

I press "E" and the Slave responds with "Here is your data:", then (hopefully) sends all the EEPROM data currently in storage, and finishes with "End of storage".

I have inserted comments at Lines 113 and 130 – which I think is the right place – explaining what I want to do. As usual, your suggestions will override any preconceptions I have on how to achieve the desired results.

File Prop_TileV4.00 Slave is attached.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com

Mike Green · 2007-03-03 15:53

Sid,
The calls to the I/O routines are simple. If you want to write 3 bytes starting at @t1 to EEPROM beginning at the EEPROM address in "a", you do

ldr.writeEEPROM(ldr#bootAddr+a,@t1,3)
ldr.writeWait(ldr#bootAddr+a)

The "ldr#bootAddr" tells the I/O routines that the address is on the boot EEPROM I2C bus. The "writeWait" routine simply waits until the write operation is done. In order to read the bytes back in, you do

ldr.readEEPROM(ldr#bootAddr+a,@t1,3)

You mentioned storing the starting address at location $FA00. If "a" is a word, you can do

ldr.writeEEPROM(ldr#bootAddr+$FA00,@a,2)
ldr.writeWait(ldr#bootAddr+$FA00)

Do keep in mind that, if you update this address often, you run the risk of wearing out the EEPROM. If you only update this once every few minutes, it shouldn't be a problem (once every 5 minutes x 100,000 times is over a year of constant use).

rjo_ · 2007-03-04 18:41

Sid,

I'm new here. So, please allow for a stupid question.

First, I know for a fact that I am going to need two props to do anything that I would want to do.

So, when I see something like your piggyback, I'm wondering ... can I wait for a product, or is this something that you would envision that I would have to do for myself?

Rich

Newzed · 2007-03-04 19:28

rjo,the Prop piggyback is my own design and I can make you one if you want.· Please e-mail me at Newzed@aol.com for details.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

rjo_ · 2007-03-05 05:31

NTAY

rjo_ · 2007-03-05 18:32

Sid,

I'm looking to put together something that might interest pure computing machine geeks.
Sort of a micro-mini-supercomputer... where the learning curve is limited by Spin (Of course, if there is any significant interest then of course there would be natural C & Basic "SpinOffs.")

I have a specific application set in mind... doesn't everyone? But I don't think that would change my first pass.
I love the build/rebuild hacker's cycle. The only thing it requires is an adequately documented and discussed piece of hardware or software which does almost what I want... and then all I have to do is add a little functionality here... and a little functionality there... and then cut away everything that I am not using. The prop fits that kind of approach to a "T."

My only concern is that I would like to be able to just replace props when the new version comes out... that's not an important issue right now... just a concern.

I very much appreciate your kind offer.

Rich

Newzed · 2007-03-22 12:20

For Mike Green:

Mike, I finally got the Slave writing to and reading from the 24LC512·EEPROM.· It stores data sent by the Master, and on request, transmits all data stored in EEPROM to the Master.· I have a couple of minor problems - here is one of them:

The starting EEPROM address I am using is 40,000 - $9C40.· When the Master tells the Slave it is going to transmit data for storage, the Slave responds with a READY and tells the Master the next starting EEPROM address.· The only way I could find to send, for example, 40000, was like this:

··· addr := readword($EA60)
··· adr := addr····· · 'starting addr initalized at 40000
··· sendmaster((addr/10000)+48)
··· addr := addr//10000
··· sendmaster((addr/1000)+48)
··· addr := addr//1000
··· sendmaster((addr/100)+48)
··· addr := addr//100
··· sendmaster((addr/10)+48)
··· addr := addr//10
··· sendmaster(addr+48)
··· sendstr(string(13,13,"· Enter 3 bytes",13,13))·····
··· sendmaster(10)

PUB Sendmaster(c)
··· serialOut(so,c,stampBaud,sim#NInv,8)

It works just fine, but I'm sure there is a neater way to do it.

It was not anticipated, but I found that reloading or rebooting has no effect on EEPROM storage above 32K.· I guess the Propeller doesn't know it's there.· I'll have to come up with a method to clear the upper half of the EEPROM· when necessary.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

paulmac · 2007-03-22 12:55

rjo_ said...
NTAY

Pardon?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants

rjo_ · 2007-03-22 14:37

paulmac

Slightly self-deprecating reference to a TV Program, South Park. If you haven't seen it... it is great for family bonding[noparse]:)[/noparse]

Rich

Mike Green · 2007-03-22 14:51

Sid,
Have a look at the "dec", "hex", and "bin" routines in any of the I/O drivers that have them. You'll find that they're written pretty much the same and are really device independent. They all call the single character output routine for the driver. You can take the code and substitute your call to sendmaster for the call to the driver's output routine.

Also have a look at the Extended FullDuplexSerial routines in the Object Exchange. These do the same kind of thing for receiving and, although they're written for use with the FullDuplexSerial driver, can be trivially modified for use with other input sources.

Newzed · 2007-03-23 22:21

Mike, I have no problem with print.dec or any of its relatives.· My problem is I want to send, e.g., 40000.· The Slave has no VGA and in order to display it I have to send it to the Master.· The only option the Slave has is "sendbyte".· If the simulator object had a "sendword" method that would probably work.· The programs for the Master and Slave are quite large, especially the Master, and they are built around the simulator object, so I have no desire to change to full deuplex and have to redo everything.· If it can not be done with simulator then I'll just have to live with what I've got.

I still have to figure out how to get the time from Stamp A,send it to the Slave as a variable, then write it to EEPROM after I have written the temperature.· Sad to say, I can't even see the end of the tunnel yet.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Mike Green · 2007-03-23 22:37

Sid,
Like the word routines in the EEPROM read/write library, it's easy to send or receive words (or longs) when you have a send/receive byte routine. The logic is identical. Just change a couple of names and you have it. In this case:

PRI sendword(w)
   sendbyte(w & $FF)
   sendbyte(w >> 8)

PRI recvword
   result := recvbyte
   result |= recvbyte << 8

Newzed · 2007-03-26 12:15

Mike,the piggyback is working pretty well after three days of programming effort.· If I want to store the Shop temperature, I press X.· The Master gets the Shop temperature from Stamp B and then gets the current time from Stamp A.· The Shop temperature is in VARs T1, T2 and T3.· The current time is in VARs h1, h2, m1 and m2.· The master then sends these VARs to the Slave, which stores them in EEPROM beginning at address
$9C40 (40000).

I have about 20K byes of storage - this is enough for over 2850 entries.· Each morning when I boot up the EEPROM is cleared and starts over at $9C40, although I might change this.

It wasn't until yesterday evening that I realized my basic problem - the Slave takes a finite amunt of time to write to EEPROM and I was not allowing this.· I added a waitcnt of clkfreq/100 ofter each VAR transmission to the Slave and BINGO! - the whole thing fell into place.

I have a little bit of program cleaning up to do but basically everything works great.· Thanks for all of your help.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Prop over Prop piggyback

Comments