Question about the RESn and BOEn Pins

Joe "Bot" Red · 2007-01-04 03:39

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 !!!!!!!!....

Mike Green · 2007-01-04 03:51

The RST pin is triggered by the edge of DTR when using any of the Prop boards with a serial connection. The Propeller's bootloader negotiates with the PC running the Propeller Tool to prove that it's a Propeller. There are some stringent timing requirement for this that the wireless link may not be able to handle. The wireless link may be able to provide a "connected" type signal that can be used to provide the RST edge. Look at the schematic for the Prop Demo Board for the circuit.

parts-man73 · 2007-01-04 04:29

Here's a somewhat related question that I have been wondering about....

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 Green · 2007-01-04 04:37

It uses a special communications protocol that's speed independent. The Propeller Tool sends out a synchronization packet with a short pulse and a long pulse (about twice as long). The Propeller bootloader looks for these and uses them to set up its timers (since it's running off its built-in high speed clock which can drift and whose speed is not exactly known). The PC uses 115KBaud, but sends at most 3 bits of data per byte giving an effective Baud of about 38KBaud.
Mike

Tracy Allen · 2007-01-04 08:15

Here is the link to the program where Chip demonstrated how to invoke the native programming procedure.
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

simonl · 2007-01-04 13:00

Hi Joe,

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 ;-)

Joe "Bot" Red · 2007-01-04 16:06

Hi!.. thanks Mike, Tracy and Simon for all your input!!.. I will go through the program and the information.. thanks again for all your help!!... Simon... I thought about using Chip's loader object.. definitely a good idea.. Exciting stuff....

Litefire · 2007-01-08 20:42

Hey, i'm trying to get a wireless programming setup functioning. PC <-> Propeller. Would spin be accurate enough to send out the 1T:2T pulses well enough for the IDE to accept them? would making the length of T help this issue?

A wireless programming scheme would be awesome.

~~Brian

Tracy Allen · 2007-01-08 21:56

Sure, the program that Chip posted, spinloader.spin, is 100% spin code.

forums.parallax.com/forums/default.aspx?f=25&m=130452

The ealier posts in this thread lay out other issues that have to be addressed to make it work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Litefire · 2007-01-08 22:27

actually, i just realized that this program is kind of irrelevant. i'm only trying to program from another computer, not from a propeller. the IDE and the chip should handle the communication on their own, correct? as long as the hardware is set up correctly.

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

Joe "Bot" Red · 2007-01-09 07:21

Hey Brian.. the main issue with making a wireless connection to the Propeller is the transmission of the RESn over the air... since a transmitter module like the Wi232DTS or the ZigBee only transmit/receive the Rx and Tx signals... there is no provision for transmitting the RESn pin pulses ..... so... in order to transmit the RESn signal I am thinking of maybe a cheap solution based on the Holtek HT-12E / HT12A receiver/transmitter combo... these are commonly used in Garage Door/Alarm Keychains in order to transmit simple bits to activate relays and stuff... you can go here for more info: http://www.holtek.com/english/products/remote_1.htm

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

Litefire · 2007-01-09 19:36

hmm... could perhaps the signal that a propeller is on the chip be spoofed by some hardware in between the IDE and the propeller. so that the IDE thinks that the chip is there when it really isn't.

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

Joe "Bot" Red · 2007-01-10 08:12

Hey Brian !!... I was experimenting with a couple Wi232DTS modules to wirelessly connect the Tx and Rx pins to the Propeller.... and it worked!!!!!.... however..... there still the issue of making the RESn Pulse wireless.. but I am certain I can get it working with some cheap garage door/alarm module type since that would be a simple reset pulse that can be transmited through one of those cheap modules...

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....

Litefire · 2007-01-10 19:44

any word on pricing for these components? this sounds awesome, and would be so useful if we could get it working!

~~Brian

Joe "Bot" Red · 2007-01-10 22:14

Hey Brian, here is an almost complete list of the main components required:

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..

I believe www.jameco has those ICs or similar Holtek versions for cheap.. probably no more than $ 2.00 each... And the RESn pin must be inverted at each end of the transmitters to avoid resetting the Prop in case a loss of signal occours.

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

Mike Green · 2007-01-10 22:30

You might be able to encode the reset with the transceiver modules. The data line from the PC normally rests at logic 1 and goes to logic 0 for brief periods only. A "break" signal is usually a long period of logic 0, typically several character times. If DTR is false, you could force the data line to logic 0 at the PC end. At the Propeller end, you could detect a "break" of a specific length (approximately) by using a timer IC or something similar to detect the zero to one edge of a logic low pulse at least 2-3 character times in length. I don't know whether the transceivers have a carrier detection capability. You'd prefer to not generate a reset with a total loss of signal.

Joe "Bot" Red · 2007-01-10 22:42

That sounds like a great idea!!.. now I understand the logic of the "Break" signal.... I remember Tracy Mentioned the "Break" condition earlier in this post, but I totally forgot about it until you refreshed the post.. ... I understand what you said with the Reset with a total loss of signal... I forgot to mention that the RESn must be inverted at each end to avoid that situation... but now I am going to rethink the idea based on the Break Condition... I knew that your brilliance was coming to the rescue any minute!!.... thanks everybody, Mike and Tracy for the Break condition idea.... uhmm... another sleepless night breaking my brain with the "Break" Condition....

Post Edited (Joe "Bot" Red) : 1/11/2007 4:36:28 PM GMT

Question about the RESn and BOEn Pins

Comments