Shop OBEX P1 Docs P2 Docs Learn Events
XBee Prop Programming — Parallax Forums

XBee Prop Programming

bee_manbee_man Posts: 109
edited 2013-10-26 10:30 in Propeller 1
I was thinking I would like to program my S2 thru an XBee adapter that I made here. http://forums.parallax.com/showthread.php/148314-S2-XBee-adapter-for-Tiny-Logo-and-more

So I did a little searching and discovered this link for Arduino. http://www.ladyada.net/make/xbee/arduino.html

Has anyone tried this? I bet it will work since I use my prop plug to program my RepRap board (ATMEGA644 based) all the time, so the timing should be close.

This is exactly the course of action that I had in mind, use one of the data lines from the XBee to trip the reset line.
I may have some reset timing issues that should be easily overcome.

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-10-25 21:26
    It's been done. See this application note:

    -Phil
  • bee_manbee_man Posts: 109
    edited 2013-10-25 21:33
    Is that not a soft load solution and takes processor space? This is totally transparent to the prop or any processor. This is just an extension of the programming cable.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-10-25 22:05
    bee_man wrote:
    Is that not a soft load solution and takes processor space?
    Yes. Is that a probelm?

    BTW, you will not find an XBee solution that uses the internal ROM loader, due to timing contraints.

    -Phil
  • bee_manbee_man Posts: 109
    edited 2013-10-26 07:15
    Sorry, I'm a long time hardware guy. Soft solutions are ways to hide hardware mistakes.

    The Arduino had a similar soft solution to yours that this mod seems to correct.

    The prop manual is very vague on the boot loader timing
    The Boot Loader performs one or more of the following tasks, in order:

    a. Detects communication from a host, such as a PC, on pins P30 and P31. If communication from a host is detected, the Boot Loader converses with the host to identify the Propeller chip and possibly download a program into Main RAM and optionally into an external 32 KB EEPROM.

    what's the baud rate?
  • Mike GreenMike Green Posts: 23,101
    edited 2013-10-26 07:34
    The timing constraints are in software that's stored in masked ROM in the Propeller chip (the bootstrap loader). It was a reasonable decision at the time the Propeller was designed, not a mistake.
  • bee_manbee_man Posts: 109
    edited 2013-10-26 07:48
    Did not mean to imply that the boot loader was a mistake. The XBee should be able to transparently transmit the 3 lines (TX, RX, /RST) needed to program the micro controller.
  • Mike GreenMike Green Posts: 23,101
    edited 2013-10-26 07:57
    The xBee does transparently transmit the 3 lines, just not with faithful timing which it cannot do because of the delays in the packetizing of the information and the error checking and retransmission that can occur in a noisy environment. The packetizing and potential retransmission are features that make possible the addressability and reliability of xBee.
  • bee_manbee_man Posts: 109
    edited 2013-10-26 09:44
    Mike Green wrote: »
    The xBee does transparently transmit the 3 lines, just not with faithful timing which it cannot do because of the delays in the packetizing of the information and the error checking and retransmission that can occur in a noisy environment.

    Would not the Arduino be subject to these same restraints? Apparently they have it working over there. I am going to try this mod and I will share the results with both the Arduino and the Prop.

    This question of XBee direct programming comes up a lot and yes Phil has a soft work around, but I came across that Ladyada page and it appears to be feasible. I don't really need rock solid reliability.

    I still can not find the baud rate the prop is looking for during the 100ms delay after reset.
  • Mike GreenMike Green Posts: 23,101
    edited 2013-10-26 10:08
    There's no fixed Baud used by the Propeller itself. The Propeller Tool I believe uses 115200 Baud for the PC's serial port, but uses that to embed a self-clocking protocol that encodes either 1 bit or 3 bits per character cell depending on what's being sent and the Propeller synchronizes to that. The reason for this is that the Propeller may not have a crystal attached and has to use its internal clock which is not accurate enough to use for Baud timing.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-10-26 10:11
    bee_man wrote:
    I still can not find the baud rate the prop is looking for during the 100ms delay after reset.
    That's because there isn't one. The Prop comes out of reset in RC mode, since there's no way of knowing a priori what kind of external timing reference might be attached, if any. So it does not have an accurately predictable clock rate. The serial data sent to the Prop for loading is not your usual asynchronous stuff but serial data made to look like a pulse-width-encoded bitstream, which is much more tolerant of timing errors. For this to work, the bytes have to be cheek-to-jowel without gaps, because it takes more than one serial byte to represent one data byte. And that's the reason the XBee will not work with the ROM loader.

    -Phil
  • bee_manbee_man Posts: 109
    edited 2013-10-26 10:13
    Thanks Mike that gives me a place to start. The XBee can handle 115200 so maybe.
  • bee_manbee_man Posts: 109
    edited 2013-10-26 10:28
    Phil Pilgrim (PhiPi) wrote: »
    ...the bytes have to be cheek-to-jowel without gaps, because it takes more than one serial byte to represent one data byte...

    -Phil

    Now that does not sound encouraging !
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-10-26 10:30
    It is what it is, and it was done that way for a very good reason: reliability under unknowable clock conditions.

    -Phil
Sign In or Register to comment.