Shop OBEX P1 Docs P2 Docs Learn Events
Lantronix Xport Pro - Propeller Tool UpLoads ? — Parallax Forums

Lantronix Xport Pro - Propeller Tool UpLoads ?

Greg PGreg P Posts: 58
edited 2011-05-08 13:37 in Propeller 1
I've recent acquired a Lantronix "XPort Pro" module. This small device provides an Ethernet receptacle, operates from a +3.3v supply (220mA!), contains 16MB of flash, 8MB of ram, utilizes a 32-bit Coldfire processor, and provides three GPIO pins in addition to its TX & RX lines for interfacing with other hardware.

I have the foolish idea that I would like to have the Propeller Tool upload firmware remotely to the Propeller via the XPort Pro over our local network. For this to work, as I understand it, the Propeller needs to be reset just prior to the Propeller Tool software's attempt to communicate with the device. The reset by default is normally handled with the DTR line, but I believe the RTS line is also an option in later Tool versions.

I'm currently running (as I understand it) using a default "serial tunneling" TCP connection. This behaves to the best of my understanding (I'm not a network expert by any means) in a manner such that data bytes are transferred "raw" with no special control characters utilized. In this mode, control of the DTR or RTS lines is not available. Another mode, telnet, permits special commands using control characters to toggle the DTR and RTS lines. This mode however seems to required that all normal communication to and from the Propeller be in printable ASCII characters (at least special control characters must be avoided). This is problematic if image data or raw ADC/DAC values are to be transmitted as it is possible a binary value may correspond to one of the special control characters. Perhaps someone has written code which duplicates the upload operation of the Propeller Tool, and this code could be modified to handle the telnet protocol also. I'm assuming the uploaded firmware would also be binary in nature and subject to the same potential to appear as an unwanted telnet control command.

I was wondering if anyone out there in the Propeller community has had experience with attempts to remotely upload firmware to a Propeller over the network ? Perhaps this is a foolish idea. Comments and potential solutions would be most welcome.

Comments

  • stefstef Posts: 173
    edited 2011-05-05 13:12
    Hi

    I recently had a project where I used a prop and an xport in it. I also wanted to upload new spin code using the tcp/ip conection from the xport because then I could update the functionality without going on site and connect to the print itself. I searched on it and found a solution to upload the binary file to it. I used then hyperterminal to send the new file. It work slow (took about 5 min) but it worked. I 'm not at home now but if you are interested let me know and I will search back the information I have on it.
    Perhaps it will help you to find a solution. I can't post you the sin code itserlf because it became a comercial product (I have now 100 dev running on the www). The only thing i have not yet finisched is to develp myserl in visual studeo the way to send the binary file. Now I need to stop the service I created in .net to capture the information of the devices that they are sending mee. Use hyperterminal to send the binary and then start back again the service. It is Not the nicesed way of doing that but I don't update the devices daily. Better to work 5 min then to drive 200KM.

    When I get home I will serache the info.

    Best reguards.

    Stef
  • Greg PGreg P Posts: 58
    edited 2011-05-05 13:35
    Stef,

    This is great news ! Yes, I would be most interested in learning more regarding your successful technique.

    I will be acquiring Real Studio Professional soon, to replace our current dependency on Visual Basic 6 (I never quite made the transition to .NET for concern regarding reliable serial communication). If the advertisement is the reality, software developed on Windows should port directly to Linux and Mac as well. The language syntax seems very VB6 like. It appears to offer much better support for TCP/IP sockets and the like. Hope to utilize it to communicate with Xport Pro & Propeller.

    I would like to develop code using Real Studio which incorporates your Xport upload technique.
  • Greg PGreg P Posts: 58
    edited 2011-05-05 18:50
    I just discovered the "soft loading" app note (AN007) which provides a technique to utilize a cog as both a serial data handler AND a bootloader. A unique 16-byte string following a period of data input inactivity, is the trigger to activate the bootloader. Only the available serial TX & RX lines of the XBee transceivers are required to upload new firmware. The "reset" is triggered via a cog instruction following uploading of new firmware to RAM and EEPROM.

    The Xport could be temporarily configured for "serial tunneling" via TCP connection, in order to channel the new firmware through the Xport to the Propeller-based cog bootloader. Afterwards the Xport browser-based control panel could be used to reconfigure the Xport for user-specified behaviors (I'm thinking primitive web server like activities with custom c language code).

    The idea combination would be to utilize the large 8 MB of RAM available with the Xport to temporarily store data acquired via the Propeller for later PC browser display on a web page.
  • MGreimMGreim Posts: 114
    edited 2011-05-08 01:45
    I have uploaded yeserday a small tool booting the Propeller from an ARM (OMAP 35xx) maybe this should work similar for the Coldfire
    There is a freepascal version for the 68k family.
    Is the Lantronix running on Linux or OSless ?

    http://forums.parallax.com/showthread.php?131535-SPIN-loader-command-line-tool-for-ARM-processors

    Regards

    Markus
  • stefstef Posts: 173
    edited 2011-05-08 13:37
    Hi Greg

    Sorry for my late reaktion but I was traveling. I can provide you with some information I used on the project with the xport.
    I used "Kermit EEPROM Console" from Eric Ratliff that I modified a bit. (you can find it in the obex)My modules are sending me information over the internet on port 3001. I periodicly look for returned characters. If a certain combination is send to the module then the reception is going in a loop waiting for the kermit connection sending the binary file. It stores it in the eerprom and reboots the module. This way I can update all my modules true the internet without pysicly being in front of the module.
    This is a part of the code where i see te reception of the character and wait for the kermit transmission. If I don't send the binary It continu it execution after a while.

    'look fo character "t" and wait for binary
    if rx == 116
    wachtteller := 0
    pc.str(string("start sending Binary file with Kermit terminal in 2 sec"))
    waitcnt((clkfreq)+cnt)
    pc.stop
    repeat
    ProcessorResultFlags := ConsoleSerialDriver.Process
    if wachtteller > 360 ' = 3 min wachten
    reboot
    ' Als we bezig zijn aan een file transfer.
    if (LastProcessorResultFlags & ConsoleSerialDriver#KEC_ISM_KermitPacketDetected)
    ' did Kermit process end?
    if not ProcessorResultFlags & ConsoleSerialDriver#KEC_ISM_KermitPacketDetected
    ' does file size equal declared or assumed size?
    if ProcessorResultFlags & ConsoleSerialDriver#KEC_ISM_KermitCompleted
    ConsoleSerialDriver.str(string("File Receive Finished"))
    waitcnt((clkfreq)+cnt)
    REBOOT ' let propeller start from program stored in EEPROM
    else
    ConsoleSerialDriver.str(string("File Receive Stopped"))
    ' Prompt ' let user know that program is ready to accept a command

    LastProcessorResultFlags := ProcessorResultFlags ' record present status for next loop

    It is working like a charm on multiple modules.
    Hope this helps a bit for you

    Best reguards

    Stef
Sign In or Register to comment.