I've made a modified version of the original PropellerLoader object, that uses a counter to generate the 1T and 2T pulses. This seems to work also with the internal RCfast oscillator. So we are back to no crystal and the code of the first post, only with the modified PropellerLoader object:
Any idea why some propeller chips work and some do not? I get about a 50% propeller chip failure rate and have to pick and choose the prop to find a good one. It's not about the number of props or layout, it's just that some don't work..
I'm running this simple code, with 5 props and LED on pin 15.
OBJ loader : "RC_PropellerLoader" ' Modified PropellerLoader by Andy
PUB LoadPropeller ' Prog to load props in parallel
dira[15] := 1 ' Pin 15 output
repeat ' Loop below
outa[15] := 1 ' LED on
waitcnt(clkfreq+cnt) ' Wait a second
outa[15]:=0 ' LED off
loader.Connect(0, 1, 2, 1, loader#LoadRun, 0) ' Loads the props
I think the fact that some props just don't work is based on marginal timing. I'm not familiar with setting a variance to RC_fast. I looked at RC_PropellerLoader and saw the 1T 2T pulse on pin 30, however after prop1 and prop2 it's pin 31 that gets propagated to all the remaining props. Any ideas on what to modify?
I think the fact that some props just don't work is based on marginal timing. I'm not familiar with setting a variance to RC_fast. I looked at RC_PropellerLoader and saw the 1T 2T pulse on pin 30, however after prop1 and prop2 it's pin 31 that gets propagated to all the remaining props. Any ideas on what to modify?
Yes .i may be that if one Prop is lower than 12 MHz and the other higher then the timing is not suitable. Normally only the receiving Prop runs with RCfast and the source that loads the Prop has a crystal based timing. If the Prop that loads the other one also runs with RCfast then the failure can be twice as high, in worst case.
Yes .i may be that if one Prop is lower than 12 MHz and the other higher then the timing is not suitable. Normally only the receiving Prop runs with RCfast and the source that loads the Prop has a crystal based timing. If the Prop that loads the other one also runs with RCfast then the failure can be twice as high, in worst case. Andy
Is there a solution to this by applying a crystal to prop1 and setting its code to a more stable timing to match an average of RC clock timing expected with the other props?
Is there a solution to this by applying a crystal to prop1 and setting its code to a more stable timing to match an average of RC clock timing expected with the other props?
Yes, this was suggestet since post #4 of this thread. If you have one Propeller that loads a lot of others in parallel then only the first Propeller needs a crystal-clock.
I really don't know what you will do with this. Several Propellers with the same code makes not much sense. If it is for processor power then running 1 Propeller with a 6 MHz crystal is the same power as 8 Propellers with RCfast. If you need a lot IO pins then there are better solutions. Only if you need a lot of cogs the more than one Propellers is useful, but for what?
Yes, this was suggestet since post #4 of this thread. If you have one Propeller that loads a lot of others in parallel then only the first Propeller needs a crystal-clock.
I really don't know what you will do with this. Several Propellers with the same code makes not much sense. If it is for processor power then running 1 Propeller with a 6 MHz crystal is the same power as 8 Propellers with RCfast. If you need a lot IO pins then there are better solutions. Only if you need a lot of cogs the more than one Propellers is useful, but for what? Andy
Post#4: Humanoido I've tried it with 2 Propellers (first programs the second, no loop) and found that the PropellerLoader works not with the internal 12MHz RCfast oscillator. But if you connect a crystal to every Propeller chip and set PLL mode x 4 or higher - it seems to work! Andy
Originally Posted by Humanoido: Is there a solution to this by applying a crystal to prop1 and setting its code to a more stable timing to match an average of RC clock timing expected with the other props?
Andy, thank you, I will put a crystal on the first prop and test the code this weekend. The purpose of parallel loading all props with the same program is for a Propeller brain. The programs will deliver evolving neurons to all the props. It is not about speed, or I/O pins, but about more cogs and getting the highest number of neurons loaded.
The first Prop loads its own Program to the others and this Program expects a crystal. If you load a Program that works with RCfast to the connected Props, you need no crystals.
CON _clkmode = xtal1 + pll8x
_xinfreq = 5_000_000
OBJ loader : "PropellerLoader"
DAT
theCode file "BinaryForRC_Props.binary" '<-- set your file here
PUB LoadPropeller
dira[15] := 1
repeat
outa[15] := 1
waitcnt(clkfreq+cnt)
outa[15]:=0
loader.Connect(0, 1, 2, 1, loader#LoadRun, @theCode)
First you make youre Program for the RC Props, compile it and save it as binary. The you set the name of this binary in the DAT section. Then you start the code above on the first Prop.
Andy, thank you for the explanation which enabled the system to work perfectly. I added more props to the machine - it's working with 26. When I get more breadboards, I think this number could increase. It was interesting to see the wide differences between RC timing from one prop to the next, when running independently, even though they were loaded at the same time. I'm happy this works! It opens the door to many new things. Thanks Andy!
Sorry to bring up an old thread, but I have a question. Chip's comments say to tie BOEn high. I want to use this with the Propeller Platform which ties BOEn low. Will this loader work as is, or do I need to modify all of my Platform boards?
It worked. And I did not need any pullup on the reset input. I tested it with a direct connection from P0 to /reset. I probably should add a current limiting resistor.
Since both of the Platform boards have crystals, I had to use Andy's RC_PropellerLoader.Spin. (Thanks, Andy)
My last step was figuring out the constant change to write the loaded program to EEPROM (RTSC - read the source code).
Comments
Any idea why some propeller chips work and some do not? I get about a 50% propeller chip failure rate and have to pick and choose the prop to find a good one. It's not about the number of props or layout, it's just that some don't work..
I'm running this simple code, with 5 props and LED on pin 15.
Yes .i may be that if one Prop is lower than 12 MHz and the other higher then the timing is not suitable. Normally only the receiving Prop runs with RCfast and the source that loads the Prop has a crystal based timing. If the Prop that loads the other one also runs with RCfast then the failure can be twice as high, in worst case.
Andy
Yes, this was suggestet since post #4 of this thread. If you have one Propeller that loads a lot of others in parallel then only the first Propeller needs a crystal-clock.
I really don't know what you will do with this. Several Propellers with the same code makes not much sense. If it is for processor power then running 1 Propeller with a 6 MHz crystal is the same power as 8 Propellers with RCfast. If you need a lot IO pins then there are better solutions. Only if you need a lot of cogs the more than one Propellers is useful, but for what?
Andy
CON _clkmode = xtal1 + pll8x _xinfreq = 5_000_000 OBJ loader : "PropellerLoader" PUB LoadPropeller dira[15] := 1 outa[15] := 1 waitcnt(clkfreq+cnt) loader.Connect(0, 1, 2, 1, loader#LoadRun, 0)Originally Posted by Humanoido: Is there a solution to this by applying a crystal to prop1 and setting its code to a more stable timing to match an average of RC clock timing expected with the other props?Andy, thank you, I will put a crystal on the first prop and test the code this weekend. The purpose of parallel loading all props with the same program is for a Propeller brain. The programs will deliver evolving neurons to all the props. It is not about speed, or I/O pins, but about more cogs and getting the highest number of neurons loaded.
CON _clkmode = xtal1 + pll8x _xinfreq = 5_000_000 OBJ loader : "PropellerLoader" PUB LoadPropeller dira[15] := 1 repeat outa[15] := 1 waitcnt(clkfreq+cnt) outa[15]:=0 loader.Connect(0, 1, 2, 1, loader#LoadRun, 0)It should load the program, turn the LED on a second, then off, and repeat.However, prop 2 and prop 4 were strange. The LED blinked on/off two times
for every one time of the other prop LEDs.
So I put a crystal on prop 2 and prop 4 and the blinking went to normal.
I can't explain why some needed the crystal and some did not.
My next step is to try this with 21 props, but I will probably run out of crystals.
The first Prop loads its own Program to the others and this Program expects a crystal. If you load a Program that works with RCfast to the connected Props, you need no crystals.
CON _clkmode = xtal1 + pll8x _xinfreq = 5_000_000 OBJ loader : "PropellerLoader" DAT theCode file "BinaryForRC_Props.binary" '<-- set your file here PUB LoadPropeller dira[15] := 1 repeat outa[15] := 1 waitcnt(clkfreq+cnt) outa[15]:=0 loader.Connect(0, 1, 2, 1, loader#LoadRun, @theCode)First you make youre Program for the RC Props, compile it and save it as binary. The you set the name of this binary in the DAT section. Then you start the code above on the first Prop.Andy
Al
Andy
Al
Since both of the Platform boards have crystals, I had to use Andy's RC_PropellerLoader.Spin. (Thanks, Andy)
My last step was figuring out the constant change to write the loaded program to EEPROM (RTSC - read the source code).
Al