Shop OBEX P1 Docs P2 Docs Learn Events
Propeller web interface - Pink server vs Lantronix Xport Pro — Parallax Forums

Propeller web interface - Pink server vs Lantronix Xport Pro

JufraJufra Posts: 24
edited 2011-08-15 00:33 in Propeller 1
Hi all,

I have a question RE propeller and web-interface/ethernet connectivity. I know there are some posts out there, but I haven't found answers to my questions.
At the moment we are running a prop chip in conjunction with a NEtburner Pink server. All running fine, the idea is that the user can go to a website on the pink,
select some values and hit "submit". The values are stored internally in the Pink variables and the variables are polled and read by the propeller. We are using some cogs of the propeller as a dataloggers, and the setting of the values is used for calibration and other tasks.
In addition, the prop sets some of the pink variables in certain intervals so the user can go to the pink website (which reads and displays the variables) and check some current values from the prop (in our case it is sensor data).

So through the internal vars in the pink server, the prop can communicate with the "outside world" and vice versa. Another thing we use the pink for is for the prop chip to send udp message. Same thing, the prop loads the pink vars, and then "triggers" the udp message to be sent.

It's all running fine, one of the issues is cost and now I've come across the Lantronix Xport Pro and I'm wondering if it can be used to replace the pink in the application I described above. Looking at the Xport docs, they seem very detailed and it looks like a steep learning curve for me. But I'm quite keen to get into it since the Xport Pro seems to be quite versatile and also reasonably priced (compared to the pink).
However, the first thing is to find out whether it is worth going down that road

So in summary I'd like to find out how the prop can communicate with the Xport pro and whether the functionality as described above can be achieved at all...

Any help is much appreciated
Thanks

Frank

Comments

  • Mike GMike G Posts: 2,702
    edited 2011-08-03 06:22
    Have you looked at the Spinneret?
  • JufraJufra Posts: 24
    edited 2011-08-03 06:39
    Hi Mike, I have looked at it briefly a while ago, but at the time there wasn't much code available for it...
    Will it be able to do what I described?
  • Mike GMike G Posts: 2,702
    edited 2011-08-06 15:08
    Will it be able to do what I described?
    Easily... with the the addition of an RTC. IO is limited though.
  • JufraJufra Posts: 24
    edited 2011-08-09 03:06
    Ok, thanks, can you point me to any useable code since whenever I look for off the shelf stuff available for the Spinneret I can't find anything. Or did you imply it can be easily done but needs to be developed from scratch?
  • Mike GMike G Posts: 2,702
    edited 2011-08-09 05:38
    There is a lot of code...
    http://spinneret.servebeer.com:5000/

    Browse the Spinneret forum.

    [Edit]
    The site above is severed up by a Spinneret.

    Web Camera
    http://www.agaverobotics.com/spinneret/controlpanel.htm

    Sample service call
    http://spinneret.servebeer.com:5000/led/25/on (use a second browser instance)
  • JufraJufra Posts: 24
    edited 2011-08-10 06:00
    Thanks again Mike, very helpful stuff there!! Will have a much closer look at it.
    The thing I'm still a bit unclear about is the comms between our existing Prop-based board (that reads the sensors) and the Spinneret. I can roughly see how the external I-net access to/from the Spinneret works using the post and get methods and how that could be manipulated for our purposes, however, how do I get the prop that runs our application to talk to the spinneret and keep it updated with the current sensor data and receive data that the user has posted on the websites?
    Would need to be some sort of serial connection between the 2 props, handshaking and all the rest of it, wouldn't it?
    That is the nice thing about the PINK, this part of it is ready to use out of the box. The pink has the status variables that indicate that there has been a post to the variable, and it's all driven on the prop side by sending in commands to the pink. So the Spinneret would need a similar some sort of (serial) API towards another prop chip that allows for this data transfer. Maybe it's just a matter of having a dedicated cog on the Spinneret using a FullDuplexSerial object that implements this. I'm sort of thinking aloud here...
    Is this maybe already available?

    Sorry for picking your brains here Mike... even though I've worked with the prop for a good 2 years now, I still consider myself a newbie
  • Mike GMike G Posts: 2,702
    edited 2011-08-10 06:35
    What about replacing your existing Propeller rig with the Spinneret? The limiting factor is IO which you have not mentioned in your specs.
    spinneret and keep it updated with the current sensor data and receive data that the user has posted on the websites?
    Did you read the tutorial? Data is posted using HTTP POST or GET.
  • JufraJufra Posts: 24
    edited 2011-08-10 19:04
    Mike G wrote: »
    What about replacing your existing Propeller rig with the Spinneret? The limiting factor is IO which you have not mentioned in your specs.


    Did you read the tutorial? Data is posted using HTTP POST or GET.

    Yes Mike, the number of I/Os is the problem, we have quite a few sensors potentially hooked up to the current board (and other things going on requiring I/Os), so that's not an option really.
    Yes, I had a (brief) read of the tutorial, and as I said I don't see the issue getting/posting the data to/from the server via the web, it is more the communication between the existing prop we have and the Spinneret...
    I do have a Spinneret on my desk at the moment and I'm playing with it
    I'm in the process of exploring some options with FullDuplexSerial as I said below. I might be able to keep the Pink interface on the existing Prop almost unchanged and implement a Pink emulation on the Spinneret.. my plan at least... will see how that one goes.


    Another question, I've seen some udp code for the spinneret, and I also need this to be in there with the HTTP stuff, so am I running into memory issues...?? just noticed the HTTP server only leaves about 500 longs
  • Kevin WoodKevin Wood Posts: 1,266
    edited 2011-08-10 19:42
    Jufra wrote:
    Another question, I've seen some udp code for the spinneret, and I also need this to be in there with the HTTP stuff, so am I running into memory issues...?? just noticed the HTTP server only leaves about 500 longs

    Don't forget that you can contact the "other side" of Parallax, Parallax Semiconductor. This is exactly the type of customer support situation that they're targetting with their field application engineers.

    Here's more info... http://www.parallaxsemiconductor.com/support/engineering
  • JufraJufra Posts: 24
    edited 2011-08-13 03:53
    Thanks Kevin, yes, good point, I'll contact them soon.
    Have had some success with Mike's code, I got the prop to prop comms working, one prop is sending "Pink-like commands" to the spinneret using the FullDuplexSerial object (Like readvar and writevar).
    At the moment I'm working on the file serving part, so that the <NB_var_xy> tags are replaced by the internal variables of the Spinneret that the other prop has written using the Pink-API emulation (as I called it earlier). Using the MatchPattern routine I'm planning to check for any <NB_var> pattern when the website is served by he spinneret and will replace the tags with the actual variable values.
    When a website uses a POST operation, the spinneret will look for NB_var's in the POST and store the value in internal vars that the other prop can request through a readvar call...

    Once this all works, I'll go over to the udp part

    So far, so good...

    CHeers
    Frank
  • Mike GMike G Posts: 2,702
    edited 2011-08-13 06:42
    Reduce the buffers to get a little more RAM
    CON
      _clkmode = xtal1 + pll16x     
      _xinfreq = 5_000_000
    
      MAX_PACKET_SIZE = $5C0 '1472   '$800 = 2048
      RxTx_BUFFER     = $600         '$600 = 1536
      TEMP_BUFFER     = $300         '$5B4 = 1460 
    

    I'll put together a minimal HTTPServer.spin.
  • Mike GMike G Posts: 2,702
    edited 2011-08-13 16:08
    Added HTTPServer base code versions. These guys have a smaller footprint.
    http://forums.parallax.com/showthread.php?133785-Multi-Socket-Base-Code&p=1027011#post1027011
  • JufraJufra Posts: 24
    edited 2011-08-15 00:33
    Great stuff, thanks Mike... I'm making quite a bit of progress here!!

    How do you use the udp part of the http server, ie, how can the spinneret send out a udp message? I'm talking about the full blown http server, not the reduced one you just posted...

    Thanks again
    Cheers
    Frank
Sign In or Register to comment.