HTTP server for the Propeller Chip

Patrick1ab · 2009-12-01 23:41

I'm currently working on an HTTP server based on the Propeller Chip and I would like to let you be part of this project.
It uses the TCP/IP stack PropTCP by Harrison Pham and fsrw version 2.4 by Tomas Rokicki and Jonathan Dummer.
Both objects are already included in the package.

Basically the server is doing these things right now:

- waiting for a get, post or head request

- if the request contains a filename, then check the sd card whether this file is available, send an HTTP header ("head" would stop here) and then send the file
or
- if no filename is specified, send back a list of files found on the sd card

So, you will see that there is a lot of space for improvements / extensions:

- speed improvements: currently the maximum bandwidth you can get is 850 kBit/s while overclocking the Propeller to 100 MHz
- PHP ?!?
- access to I/O-ports via web interface
- stability improvements, as there are some known bugs:

1. streaming music works fine with Windows Mediaplayer and Quicktime, but it won't work properly with the VLC mediaplayer or a portable device like the iPhone
2. if you try to save a file, the computer waits for the transmission to begin, but the server already started transmitting before you specified the location for the file to be saved

- compatibility improvements: currently I'm just testing this with Firefox, but I know that the Microsoft Internet Explorer has problems displaying the list of files

I'm trying to fix some bugs / add some new features aswell (for example: webpage access control, creating log files, etc.), but my studies are keeping me busy at the moment and I don't want to fail my exams

localroger · 2009-12-01 23:49

Looks like a useful project. You might want to check out my slightly modified version that fixes a couple of lock-up bugs:

http://forums.parallax.com/forums/default.aspx?f=25&m=385830

Right now I am rewriting the TCP stack to use the Spin object structure more effectively, which I think will save 1 to 2 K
of Hub RAM. I will also MIT license it when I'm done so it can go in the obex.

Cluso99 · 2009-12-02 01:58

WOW - another nice prop feature - great work guys!

Once running properly in spin, it could be sped up in pasm. Yes, not enough room! But, overlays are fast - I have done a fast loader - and a mix of LMM as well could improve that speed many times over. But, best to get the code running nicely first up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Rayman · 2009-12-02 02:01

localroger said...
I will also MIT license it when I'm done so it can go in the obex.

That would be great!· I'm a big fan of MIT license (even though I rarely use it myself·

··)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Rayman · 2009-12-02 02:01

I like the streaming music!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

localroger · 2009-12-02 03:23

@Rayman -- yes, the MIT license is necessary for Parallax so that people like me can kludge and use the stuff there for commercial purposes, because if we can't it's like it's not there for us and the chip isn't viable for commercial purposes. Fortunately, my employers understand my position that it's in our interests to donate certain portions of our work to make the platform more viable. It doesn't benefit us if we're the only people able to use ENC28J60 based extensions and as a result they fade from the market. Of course our application code is another thing, and we don't want to have to make it public just because we used Harrison's TCP driver.

Marcello · 2009-12-02 11:16

I am also very interested !

I·want·to build a Web server based Home Automation unit.

http://forums.parallax.com/showthread.php?p=858942

The Home Automation will communicate via radio (RFM12) with actuators and sensors.#

ciao

Marcello

MagIO2 · 2009-12-02 13:31

PHP ... good that you put some question marks behind that. Even if you'd only implement a subsubsubset of PHP it would be a callenge.

I think the most practical way would be:
1. If the URL ends with ..../cgi/SomeCommand it could be interpreted as a function call of a function that has to be implemented in SPIN. Simply make a hash value out of SomeCommand and have a case statement that calls the right function if the hash value is recognized.
2. If the URL ends with AnotherCommand.cog you can load the AnotherCommand PASM image from SD card and execute that.
3. If the URL ends with YAC.col you'd run a LMM image named YAC from SD card. (COL = COG in LMM format)

For 1. and 2. there is already code available : FemtoBasic, my COGOs ...

Some other suggestions:
You most likely want to have input fields. Rather than using any kind of name, the memory adress could be used where to store the value. Then a simple parser can scan the GET string and convert longs to long ... copy strings to the right buffer with adding string end byte. To avoid that any memory location can be overwritten, a simple range check should do.

Patrick1ab · 2009-12-03 00:23

Cluso99 said...
...Once running properly in spin, it could be sped up in pasm. ...

At the moment I don't think that there will be much difference in terms of speed, because
I took another approach (which didn't work out):

I tried to use two buffers instead of one, with one cog writing the data from the sd card to the first buffer and another one sending the data of the second buffer and vice versa. To respect the different execution times of the two objects involved, I added a status byte, which showed each cog whether the data can be overwritten / can be send.

The problem was that this parallel processing was even slower than the sequential one.

So I guess you'll have to rewrite the included objects in pasm first.

As long as the data read from the sd card fills the webBuffer completely, the main part of the data transmission is actually very fast, because it can handle 4096 Bytes (or even more) with one loop:

repeat                                                                 
       h:=sdfat.pread(@webBuffer,BufferSize)            ' now we are reading the first BufferSize (4096 default) bytes                         
        if h=<0                                         ' if there are no bytes to read then exit the loop                    
          quit                                                             
        else                                                                                                 
          if h<BufferSize                               ' if the bytes read are less than BufferSize...                                                                     
           repeat n from h to (BufferSize-1)            ' ...then empty the rest of the webBuffer by overwriting it with " " ...                            
            webBuffer[noparse][[/noparse]n]:=32
          webBuffer[noparse][[/noparse]BufferSize]:=0                      ' last element of the webBuffer has to be zero
          web.txdata(@webBuffer,h)                      ' send the number of bytes read

___________________________________________________________________________________________

In the attachments you'll find a slightly modified version of the webserver:
- changed the list of files to html: it's now displayed correctly in the Microsoft Internet Explorer

Patrick1ab · 2009-12-03 00:33

MagIO2 said...
PHP ... good that you put some question marks behind that. Even if you'd only implement a subsubsubset of PHP it would be a callenge.

This is what I almost expected...

MagIO2 said...

I think the most practical way would be:
1. If the URL ends with ..../cgi/SomeCommand it could be interpreted as a function call of a function that has to be implemented in SPIN. Simply make a hash value out of SomeCommand and have a case statement that calls the right function if the hash value is recognized.
2. If the URL ends with AnotherCommand.cog you can load the AnotherCommand PASM image from SD card and execute that.
3. If the URL ends with YAC.col you'd run a LMM image named YAC from SD card. (COL = COG in LMM format)

For 1. and 2. there is already code available : FemtoBasic, my COGOs ...

Some other suggestions:
You most likely want to have input fields. Rather than using any kind of name, the memory adress could be used where to store the value. Then a simple parser can scan the GET string and convert longs to long ... copy strings to the right buffer with adding string end byte. To avoid that any memory location can be overwritten, a simple range check should do.

I'm trying to use this in the webpage access control I'm working on. Reading the password which is contained in the body of the request, checking if it's right and then directing to another page (which would be "403 forbidden", if somebody tried to open it directly)

KPR · 2010-12-16 07:58

Any new updates to this.. or has it been superseded by the spinneret?

HTTP server for the Propeller Chip

Comments