Question about the RESn and BOEn Pins
Hi... I noticed that the Propeller IDE won't recognize or download software to the Propeller if the RESn (RESET) pin is not connected to the Propeller Plug's RST pin, I know this pin is used for resetting the Propeller, but it seems it is also used by the IDE in order to recognize the Propeller Chip and download the code... My issue is that I am thinking about using a wireless module to communicate with the Propeller using the serialfullduplex.spin through the same Pins 30 and 31 used by the Propeller Plug, so I can initially download the code and then use the serialfullduplex.spin to communicate with the Propeller, but the wireless module can only make Tx and Rx wireless, I have no way to tranmit the RST through the wireless module... Is there any way to trick/modify/disable this behavior???.. I would really appreciate if somebody can explain in detail how the RESn/RST pins are involved in the "Identify Hardware" (F7) and the code download process...
Thanks !!!!!!!!....
Thanks !!!!!!!!....
Comments
When the Propeller Tool loads a program into the Propeller's Ram and/or EEPROM, What baud rate does it communicate at?
Just a matter of curiosity more than a need to know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
Mike
http://forums.parallax.com/showthread.php?p=591445
Another requirement for your wireless hardware is that it must be able to generate a BREAK condition its tx line during the reset pulse and hold it for 0.05 to 0.1 second after. Conceivably on the receiving end, you could put a little circuit that generates a reset pulse when it detects a BREAK at around 10 milliseconds, and then holds p30 high (BREAK) for an additional period to get the prop into programming mode.
After that there is an exchange of codes that involves the time-ratiometric scheme Mike described, where a 1 is represented as a pulse of duration t and a 0 is a pulse of duration 2t. That can be done using the standard UART, but it has to take into account the start bit as part of the 1t:2t scheme, but not stop bits or other time between the pulses. The preamble after the reset/BREAK, but before the actual program code, involves a key based on a psuedorandom sequence seeded with the letter "P" (that is something Chip _would_ think of!). That is followed by a check of the target Prop version number, and then a command for the operation to be performed, and then the number of bytes to be transmitted, and then finally the actual bytes and a checksum. I am probably mixing it up somehow. Study Chip's program, which is written in propeller assembly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Just thinking 'on the hoof' here, but you _may_ be able to have your wireless connection talk (using your own protocol?) to a 2nd PChip on your app' -- that's running Chip's loader object. This could then bootload the applications PChip.
Just a thought; hope it helps...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
A wireless programming scheme would be awesome.
~~Brian
The ealier posts in this thread lay out other issues that have to be addressed to make it work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
could someone outline the connections that would need to be made wirelessly in order to perform the programming?
from what i see on my current USB2SER, all i really need is RESn (on propeller) to be connected to the USB2SER's RES and the TX and RX pins connected to their respective counterparts.
if i had a wireless setup that simply had each other's pins mimicked (the states are the same on both wireless units), could i simply connect the three pins from the USB2SER to one wireless unit, and then connect the corresponding pins on the other unit to RESn, TX, and RX?
sorry if this is confusing...
~~Brian
Now... more difficult is the fact that the during the initial process of downloading the code to the Prop... the IDE sends an initial short combination of pulses that won't form a complete 8 bit + Start and Stop bits.... and more sofisticated transmitters like the ZigBee or the Wi232DTS need a complete word (Start Bit + 8 Bits of Data + Stop Bit) in order to package it and transmit that byte over the air.... I imagine these initial combination of short pulses will be simply ignored by these modules... but there is still hope... if you use a simpler transmitter/receiver combo based on ASK/FSK/OSK Modulation like for example:
http://www.laipac.com/easy_434a_eng.htm#down
These kind of modules just blindly take the Tx pulses and convert them into an RF signal... no Start/Stop bit or anything gets buffered, checked, etc... so whatever kind of strange pulse you input gets mirrored at the receiver end.... then again... they are awfully slow.... and you need four modules... a transmitter and a receiver at each end and four antennas... quite irritating since it ends up being more expensive than a Wi232DTS or ZigBee solution.... they are usually so slow (usually no more than 9600 bps) that I am not sure they will be able to transmit the code since, if I am not mistaken, after the initial handshake the code gets downloaded at 115200 Bps (I don't know if the download speed can be reconfigured)......these modules are also prone to be affected by interference...· :-(
BTW... I was playing with my Prop... and I connected a pull-up resistor to RESn (I disconnected it from the RST pin on the Prop Plug) and then a typical press-and-release Reset switch from the RESn pin to GND... then I manually initiated a Reset by clicking and releasing the switch just before I started downloading the program... funny enough, with a little practice a was able to simulate the IDE generated Reset command without the need of the RST pin on the Prop Plug.... this can be an alternative for eliminating the need to transmit the RESn pulse wirelessly...
Talk to you soon....
Post Edited (Joe "Bot" Red) : 1/9/2007 3:04:43 PM GMT
just an idea. that way it could be sent through a normal chip. perhaps there could a corresponding device on the propeller side of the connection.
here:
IDE sends request for propeller ID, hardware detects this and sends spoofing signal back to the IDE.
IDE sends program code out on very fast connection, hardware stores this into some form of memory.
TX/RX hardware transmits code to other side of connection.
there, the Prop programmer pulls the RESn pin low and sends/recieves the usual IDE code. then it could send the program to the prop.
wow that's pretty complicated... with my extremely limited knowledge of programming (for example PICs would would probably be used) i'd be of little use actually making code for this kind of setup.
perhaps one of the gurus could think of some other way...
~~Brian
BTW... I am using a Prop Plug, and then I connect it to the Wi232DTS module... the Propeller has a Wi232DTS connected to it of course..... for now I am using a direct cable connectiion for the RESn pin... but the idea is to make it wireless also .....
Talking about the wireless modules... I have no experience with the ZigBee modules... only the Wi232DTS, I went through the manual of the new Radiotronix ZigBee module... it looks like a great module, 250Kbps and fully configurable.. however... it doesn't transparently transmit the data... when you transmit... the data gets encapsulated and presented in the Data out pin with a packet format (0x01 + originator ID + payload size + payload + CRC)... this sounds great for control of retrasmissions and data validation since it has CRC error check.. but too fancy for our purposes... now.. somebody on the CNC machine thread proposed another ZigBee module, that one transmits the data transparently like the Wi232DTS.... but I believe the data rate is slower .... since I only got results with the Wi232DTS, I can only recommend this module as an alternative... the Wi232DTS I am using transmits at 115200, but according to their forum it can go up to 152Kbps... well.. I will now focus my energy on how to transmit the RESn pulse wirelessly... but so far it is good news....
~~Brian
Two Wi232DTS Transceiver modules for data Tx/Rx: 2 x $30.32 = 60.64
http://www.mouser.com/search/ProductDetail.aspx?R=WI.232DTSvirtualkey50930000virtualkey509-WI232DTS
One Transmitter module for the RESn Pin = $4.10
http://www.mouser.com/search/ProductDetail.aspx?R=RCT-433-ASvirtualkey50930000virtualkey509-RCT-433-AS
One Receiver module for the RESn = $4.95
http://www.mouser.com/search/ProductDetail.aspx?R=RCR-433-RPvirtualkey50930000virtualkey509-RCR-433-RP
Two Half Wave Antennas: 2 x $9.85 each = $ 19.70
http://www.mouser.com/search/refine.aspx?Ntt=509-ANT-915-06A
Two Connectors for the Antennas: 2 x $3.10 each = $6.20
http://www.mouser.com/search/refine.aspx?Ntt=509-CON-RPSMA-ST
Also... data encoder/decoders would be required (Holtek HT12-E and HT12-D or similar) in order to encode/decode the pulses before/after transmission, otherwise, any source of RF in that range (433Mhz) including other remote control devices can trigger the RESn pin... thus resetting the Prop... not good..
Here is a example circuit using the encoder/decoders and the proposed simple RF tranmitters:
http://www.mouser.com/search/ProductDetail.aspx?R=WI.232DTSvirtualkey50930000virtualkey509-WI232DTS
Soo... the total so far is around $95.00 ..... you can go cheaper by eliminating the antennas and the antenna connectors and using simple cable as a replacement... it depends on the distance and if you are planning to go through walls or noisy environments.. I recommend using the antennas... particularly the Half Wave type I recommended and not the Quarter Wave type since the later require a ground plane to operate properly... well... I am planning on ordering the simple transmitters to try the wireless RESn idea... if you are willing to wait.. I will try and let you know the results of the test before you buy.... (maybe next week??) ok.. I hope this helps... I have to say it will be exciting to download the Prop code wirelessly and then use the fullduplexserial.spin module to transmit/receive data.... so much fun.. so little time!!!!
~~~Jose
Post Edited (Joe "Bot" Red) : 1/11/2007 3:59:39 PM GMT
Post Edited (Joe "Bot" Red) : 1/11/2007 4:36:28 PM GMT