RCFast and serial to Prop Tool?
prof_braino
Posts: 4,313
I don't if I have this thought out correctly. I want to know if I can run the prop with no external crystal, thus saving the cost of a part for a little while, and still program the prop's EEPROM, and talk to it using 57600 baud terminal program. This is my guess:
For EEPROM: Both RCFast and RCSlow, we can program the EEPROM, because the EEPROM is controlled by the prop, so it doesn't really care how slow it is.
For serial terminal communications: RCFast at 12Mhz should be fine. RCSlow at 20Khz is too slow for 57,600 baud. The terminal baud rate would have to be less than 20Khz, so 19,200 or 9600 would be OK.
Have I got this right?
For EEPROM: Both RCFast and RCSlow, we can program the EEPROM, because the EEPROM is controlled by the prop, so it doesn't really care how slow it is.
For serial terminal communications: RCFast at 12Mhz should be fine. RCSlow at 20Khz is too slow for 57,600 baud. The terminal baud rate would have to be less than 20Khz, so 19,200 or 9600 would be OK.
Have I got this right?
Comments
Another alternative would be to accurately measure the rcfast or rcslow and use the measurement to compute the appropriate baud rate.
I think you want the baud rate to be much slower than the clock speed. At 80MHz I think the baud is limited to around 1Mbps. So if rcslow is 20KHz then you'd probably want a target baud of 300bps.
Duane
So by this, I think you mean Table 1-10 of the propeller manual; and it shows that the values for RCFast and RCSlow can vary a large amount. (from temperature?). So the prop won't necessarily know what speed its running at, and would have to determine some appropriate relative baud rate value based on the remote.
I have this Harris RTX2000 board that does nifty autobaud detection. Type a character and by the end of the character is has already set the baud to the terminal speed. Period "." works well. I think I remember something about counting and timing the transistions allows it to detect allows it to determine all the serial settings in one character. If it doesn't figure out the setting, hit reset and try another character.
Yes, this is what I'm looking at. But there a LOT of boy scouts, so it could mean a pile of dollars. And they can always buy one later when it becomes a requirement for an application.
I think RTX2000 did something like this. To keep things simple, it was only done at start up. If it ever does drift to the point communications get messy, we just hit reset. I never noticed it get lost and need a reset, but I tend to reset often during development anyway.
So the answer is: The issue is variance in prop's internal clock. It might be possible for a prop running from RCFast or RCSlow to talk to a serial terminal, but the software would have to do autobaud detection, and the communications might get garbled due to internal clock drift. Running in this fashion may require reseting the prop if temperature changes the internal clock speed after detection.
Thanks guys! I think I have a handle on this now.
The eeprom could be added later provided the space for t/hole is made. Alternately, 32KB could be provided which reduces cost.
An idea how slow ovrer how much time? For example, with ambient temp 20C, after 2 hours the prop reaches 24C?
An idea of how much of a change in temperature is needed to cause a measureable change in clock speed?
I think during development, I'll be reloading or reseting the prop several times and hour, and after development the temp will be stable itf the ambient is stable.