x# propeller(s) project and wanting a single master propeller to load eeproms

synapse

All,
I am new to the propeller but not new to programming or electronics. I am developing a board for model rocketry to support virtually a limitless number of sensors and accessory boards. the main board or motherboard as I call it currently has 2 propeller chips, 2 64KB EEPROM's, 2 FTDI chips, and 2 usb-b connectors other components of course but are not important to my issue.

The issue is this; I plan on providing this board to teachers in schools for children to operate and use. So simplicity is of the up most importance. I now have a solution to easily update my primary micro-controller's EEPROM via the on board SD card. However I really would like to get rid of my secondary USB connection and any of the USB connections on the daughter sensor/action boards. the SD connection is only to the primary controller but I do have a dual SPI interface between the master propeller and the secondary for communications. The secondary propeller provide a link to 8 possible daughter boards, all of which at this point also have a propeller on them with their individual programming. what I am looking for is a object or some direction on how one propeller could tell another propeller hey I have this version of firmware available to you do you want it and if so stream it over and load up it's EEPROM. This is the big hurdle for my project. This method will reduce the number of USB Connections needed to perform an update or a switch to alter which chip it is talking to. By the way I have setup id's for each type of daughter board to identify not only the type of board but also to aid in the computer side of things when the students can build there firmware using a special tool I am developing that has precoded spin that is altered only by the id connected jack and based on all the variables the board either provides data or performs an action based on an event and the data it is given.

Please anyone help!!!

prof_braino

I'm also making a paskage for kids educaton. The propforth project has a technique to boot the master from EEPROM, and the master resets the slave(s) and emulates slave EEPROM. The slave hardware only needs a three resistors and one or two capacitors. Ulitmately this process can be automatic so that N-slaves can be used; if more cores or slaves are needed, attach more props. At present release, coded exists to boot one more slave; multiple slaves will be in a future release.

This project is centered around forth, in my opinion its easier for kids than other languages, but foes not need to be the ultimate development environment. The forth code can interface (serve as driver) to other environment, or the technique can be recoded in the language of your choice.

PM me if you are interested.

There are a bunch of other options too, look for Clockloop's project, and Humanoido's list of mulit-prop projects

idbruce

I don't know if this is right for you, but I recently created a field programmer using the PropellerLoader object in OBEX. The PropellerLoader object loads a program into the EEPROM of another board, but there doesn't seem to be any type of provision for two way communication. However I do believe this would be possible.

MASTER VSS -> SLAVE VSS
MASTER P0 -> SLAVE RES PIN
MASTER P1 -> 2.2K resistor -> SLAVE P31
MASTER P2 -> 2.2K resistor -> SLAVE P30
MASTER P3(RX) -> 2.2K resistor -> SLAVE P0(TX)
MASTER P4(TX) -> 2.2K resistor -> SLAVE P1(RX)

Master P3 and P4 communicates with Slave P0 and P1 through a serial communication. Through this communication it is determined whether the Slave wants the update, if it does, then have the PropellerLoader object which is in the Master sends the new update to the slave. You may have to provide additional circuitry (such as transistor switches) to keep the Masters P0, P1, and P2 seperated from the Slave until there is update confirmation.

Perhaps there is another option to reduce it to three pins. Since Slave P30 and P31 are communication lines already, you should be able to serially communicate through those pins, but still have the transistor switch on the RES pin. If the update is desired, unload whatever communication object you may be using and load the PropellerLoader object in its place, flip the transitor switch to the Slave RES pin, and update the EEPROM of the slave with the PropellerLoader object. Sounds good in theory anyhow. So the new proposed connections would be as follows:

MASTER VSS -> SLAVE VSS
MASTER P0 ->TRANSISTOR-> SLAVE RES PIN
MASTER P1(TX) -> 2.2K resistor -> SLAVE P31(RX)
MASTER P2(RX) -> 2.2K resistor -> SLAVE P30(TX)

Hope it helps.

Bruce

Cluso99

synapse: Firstly, welcome to this great prop forum.

Now, let me understand a little more. You have Master Prop "M" connected to a Secondary Prop "S" which in turn connects to 8 Daughter Prop pcbs "D1...D8".

M has an SD card, which I gather will hold copies of all "S" and "D1...D8" firmware.

M has a dual SPI connection to S. I presume you do not have a connection to P30, P31 and the Reset line on S ?

You make no mention about the connection of S to D1...D8 boards. Do you have connections to P30, P31 and the Reset line on each of D1...D8 ?

Firstly, you will need to establish a "communication protocol" between M and all the boards where each board replies with its address and firmware version. Then you can determine which boards require updating. You will need to do this programming although it is not complex.

Once you establish which boards require updating, you will need to pass the new firmware to each of the respective props that require updating. There are routines in OBEX that will update the eeprom if you do not have P30, P31 & Reset control. Likewise, there are routines in OBEX for programming a slave prop's eeprom by downloading using P30, P31 & Reset control.

Are you programming in SPIN, PASM or both?

Presuming you do not have P30, P31 & Reset control for a slave... we best leave it here until you reply.

idbruce

Okay, I would like to clarify my response a little. Your circuitry could look similar to this as follows, providing the daughter boards have the available RES, 30, 31 pins and your secondary board has additional pins available:

SECONDARY BOARD VSS -> DAUGHTER #1 VSS
SECONDARY BOARD P0 ->TRANSISTOR-> DAUGHTER #1 RES PIN
SECONDARY BOARD P1(TX) -> 2.2K resistor -> DAUGHTER #1 P31(RX)
SECONDARY BOARD P2(RX) -> 2.2K resistor -> DAUGHTER #1 P30(TX)
SECONDARY BOARD VSS -> DAUGHTER #2 VSS
SECONDARY BOARD P3 ->TRANSISTOR-> DAUGHTER #2 RES PIN
SECONDARY BOARD P4(TX) -> 2.2K resistor -> DAUGHTER #2 P31(RX)
SECONDARY BOARD P5(RX) -> 2.2K resistor -> DAUGHTER #2 P30(TX)
SECONDARY BOARD VSS -> DAUGHTER #3 VSS
SECONDARY BOARD P6 ->TRANSISTOR-> DAUGHTER #3 RES PIN
SECONDARY BOARD P7(TX) -> 2.2K resistor -> DAUGHTER #3 P31(RX)
SECONDARY BOARD P8(RX) -> 2.2K resistor -> DAUGHTER #3 P30(TX)

ETC...

Or you could comunicate from your primary board instead, dependant upon which would be easier. If I read it correctly, you are communicating from the secondary to the daughter boards already.

I am sure Cluso99 could better inform you of your best route to go, perhaps you could communicate with all the daughter boards by just using three pins on the secondary board.

Bruce

synapse

Sorry guys been busy with the holidays. thanks for the welcome. I have actually redesigned my boards and I think it provides a better solution. I now plan to only update the primary and secondary propellers firmware. I have modified my connections and I am using pins 30, 31 and reset between the primary and secondary. as far as the language I am programing in Right now SPIN but I would prefer PASM but not good enough yet to do the whole thing in it. I come from a vb/c# background SPIN is more natural to me. Down the road I would love to rewrite it all in PASM after I finish my first go around on this project. I follow the Make it work then Make it better methodology. However after reading the reply from Cluso99 I may make a few changes to my other boards since I already plan on using 3 pin SPI interfaces to them for their propellers and use pins 30,31 and reset on them as well for their connection to the primary or secondary propeller.

There are routines in OBEX that will update the eeprom if you do not have P30, P31 & Reset control. Likewise, there are routines in OBEX for programming a slave prop's eeprom by downloading using P30, P31 & Reset control.

Can you point me in the right direction search term wise?
Thanks,
Terry

Humanoido

How much of this is working in Spin?

Pence128

If the daughter boards don't have to operate independantly I suggest reducing their firmware to a simple boot loader. They can request firmware from the secondary, which requests it from the master, or they can all be connected directly to the master with a serial bus like i2c. Alternatively, you can omit the propeller from each daughter board. They can simply contain a 128 bit eeprom containing an id which your secondary prop can read, then fetch the associated firmware from the master and execute it itself. The eeprom could even simply contain the filename of the firmware.