Booting two Props from one EEPROM?
ManAtWork
Posts: 2,178
Hello,
I just started a new project where I need two propeller chips. They will run different code but it seems that both programs fit in one 24C256. I'd like to save a second EEPROM because...
a) it costs money and board space
b) programming is easier and faster if I only have one of it
I think, sharing the EEPRPOM directly is not possible but the first prop could boot from the first half of the EEPROM and the "feed" the second prop with the remaining half. Is there an example how to do that? The projected volume is 500 to 1000 units per year so that could save up to 1000 EEPROMs and programming procedures.
I just started a new project where I need two propeller chips. They will run different code but it seems that both programs fit in one 24C256. I'd like to save a second EEPROM because...
a) it costs money and board space
b) programming is easier and faster if I only have one of it
I think, sharing the EEPRPOM directly is not possible but the first prop could boot from the first half of the EEPROM and the "feed" the second prop with the remaining half. Is there an example how to do that? The projected volume is 500 to 1000 units per year so that could save up to 1000 EEPROMs and programming procedures.
Comments
Happened to see your thread & if you wait a little longer, there are members that could offer great suggestions. I'll drop my 2-cents worth.
There are a number of drivers in OBEX you could use, primarily, I think LoadPropeller might suit your needs: http://obex.parallax.com/objects/61/
How about connecting both props to the SCL+SDA lines one shared EEPROM. The first prop boots normally while the second is held in reset state. When the first finishes it releases reset of the second which then boots the same code from the same EEPROM, again. Both props can then poll a pin pulled low or high to determine if they are "master" or "slave" and execute different parts of code based on that condition.
If it works it would be simpler than writing a software bootloader. It also has the advantage that the shared code could use common subroutines without having to repeat them in different memory spaces. Are there any objections against this method?
It also has the BIG advantage that I don't need to postprocess hex files an could use one single source during development.
If you are able to load two spin binary's into one EEPROM and share it with two Props then what you originally suggested is very possible also the loader is very compact.
Testing so far has been rudimentary but looks good , I have a better version than the one I reference and can post the latest version with example here later if you are interested , just let me know.
Jeff T.
if I understood correctly I have to load your bootloader first to load the real code, so that doesn't work for me (egg+chicken problem).
I think I'll try out the method I mentioned in post #3 with the shared SCL+SDA and reset daisy chain. I'll also add some jumpers so that I could connect RX+TX of the two props for the case it doesn't work. So I could download code with the "first prop emulates PC to download code to the second" method. The LoadPropeller OBEX should be fine for this. Thanks MacTuxLin.
The difference is that the Props own bootloader, when reading from EEPROM, always loads the binary contained at start address zero whereas the modified bootloader , which admittedly requires the extra step ,launches from any valid predefined address.
The "predefined" address can be a conditional choice of address's , the pre condition being pin state , keyboard input , serial input etc.
Therefore if the modified bootloader is contained at address zero and a pre condition is set,such as a certain pin pulled high,then a Prop reset could enable one of several programs to be launched from the same EEPROM, the program dependent on pin value.
Of course , like I said , right now its just a bit of fun I have a few ideas about and really needs looking at further.
Good luck with your project
Jeff T.
1) Master Prop loads a specialized bootloader from the base 32k of 64k EEPROM normally; Slave Prop sits in reset.
2) Master Prop runs bootloader code that pulls slave out of reset and loads it with a program from a specified section of the 64k EEPROM (could be in upper 32k or in unused area of base 32k)
3) Slave prop runs its code and waits for master prop to be ready
3) Master Prop loads it's runtime program from another specified section of the upper 32k of the 64k EEPROM
4) Master Prop continues with its runtime program and signals the slave prop as needed.
Another idea is simpler:
1) Master prop code (from base 32k) includes an initial routine that checks for a running slave prop. If the slave prop is not responding, the master prop loads code to it from the upper 32k of the 64k EEPROM.
2) Slave prop runs its code and sits idle waiting for communication from the Master prop
3) Master prop checks for the slave prop, it responds, and the code proceeds normally.
Yipeee, it works! :thumb: At least I have proof of live signals from both propellers, blinking LEDs at different frequencies. Now I can start developping real code.
The schematic is relatively simple (only EEPROM and RESET signals are relevant):
This is the hardware:
And the software
PUB startup if INA[14] mainIC1 else OUTA[4]:= 0 DIRA[4]:= 1 ' release IC1 reset mainIC2 PUB mainIC1 | time, tick DIRA[1]:= 1 time:= CNT repeat OUTA[1]:= (tick++ & $40)>0 waitcnt(time+= tickSpin) PUB mainIC2 | time, tick DIRA[25]:= 1 time:= CNT repeat OUTA[25]:= (tick++ & $40)>0 waitcnt(time+= tickSpin)BTW that looks like a nice set-up - what is it?
it's a five axis stepper motor controller for CNC machines.