I took that plunge, and ran with it for a few years, but now I am all about Propeller. I am a staunch fan of the concept and I just really like using it. My *only* complaint is that it takes a couple seconds to boot up, but beyond that, it is remarkably versatile.
Remarkable even by my standards, which are sometimes unreasonably high.
I do so hardware problems won't stop the Prop from booting.
You seem to know that this is a problem with the Propeller itself I take it? I wouldn't know about that because I have never experienced any problems booting with random resets with all kinds of I2C devices on the bus and busy.
However I ran tests where I would stop in the middle of a zero read byte in different places with clock and data low and hit the reset and despite the repeated attempts and monitoring the I2C lines I have yet to see a problem. Examining the Prop boot code I can see that it anticipates this kind of thing because not only does it attempt to access the EEPROM up to 400 retries but in each and every start and stop condition it will make up to 9 attempts as well which I take it is to clear out a byte and the ack bit.
So give Chip some credit, he has done a good job with the Prop and the booter and so for us rather than blindly "playing it safe" it's better to find out about these things and make sound design decisions based on that knowledge. Otherwise we may end up talking through our hat and unfortunately others may just take our word for it so that a cadre forms around this false notion making it difficult to set matters straight.
However, if you can demonstrate this lockup happening with a single master Prop and it's repeatable then that sets things straight too and I will be glad to know.
Comments
I took that plunge, and ran with it for a few years, but now I am all about Propeller. I am a staunch fan of the concept and I just really like using it. My *only* complaint is that it takes a couple seconds to boot up, but beyond that, it is remarkably versatile.
Remarkable even by my standards, which are sometimes unreasonably high.
You seem to know that this is a problem with the Propeller itself I take it? I wouldn't know about that because I have never experienced any problems booting with random resets with all kinds of I2C devices on the bus and busy.
However I ran tests where I would stop in the middle of a zero read byte in different places with clock and data low and hit the reset and despite the repeated attempts and monitoring the I2C lines I have yet to see a problem. Examining the Prop boot code I can see that it anticipates this kind of thing because not only does it attempt to access the EEPROM up to 400 retries but in each and every start and stop condition it will make up to 9 attempts as well which I take it is to clear out a byte and the ack bit.
So give Chip some credit, he has done a good job with the Prop and the booter and so for us rather than blindly "playing it safe" it's better to find out about these things and make sound design decisions based on that knowledge. Otherwise we may end up talking through our hat and unfortunately others may just take our word for it so that a cadre forms around this false notion making it difficult to set matters straight.
However, if you can demonstrate this lockup happening with a single master Prop and it's repeatable then that sets things straight too and I will be glad to know.
Which is a fair enough approach.
Me, I'd share the I2C pins and live with that risk.