Mike G's WebServer modified to run in a separate cog?
Has anyone modified Mike G's Multi-socket WebServer code to run in a Cog? I have a hardware-control project that needs (I think) to have the WebServer launched in a cog by the core control code, rather than the WebServer launching the control code in a cog or including the control code in the WebServer's event-loop.
I've done quite a bit, and have some workable results to show for it, but I'm having problems sending out debug-print over the serial line using Parallax Serial Terminal from the WebServer when it's running in a cog.
The impasse I've hit upon at the moment is that the main program can use the serial port just fine, but when the cog-loaded WebServer (actually only the "Main" routine is in a cog) tries to send characters I get cool crashes that stream endless random data out the serial port. I know I'm clobbering the stack, and basically have moved around the WebServer code without understanding some of the basics when moving spin code into cogs - like perhaps needing semaphores and/or exclusivity when accessing the serial port.
The hardware is a Spinneret piggybacked on a board full of DIPSwitches, relays, leds, motor-drivers...all sorts of stuff controlled via SPI and directly connected.
My initial thought was to modify the Server to accept a telnet connection on one of the sockets, and stream the debug-print out that way, so I could at least get a clue what's happening.
Any help appreciated, and of course excuse me for not finding any existing answer or existing code already on the forums - I looked for quite a while before posting.
I've done quite a bit, and have some workable results to show for it, but I'm having problems sending out debug-print over the serial line using Parallax Serial Terminal from the WebServer when it's running in a cog.
The impasse I've hit upon at the moment is that the main program can use the serial port just fine, but when the cog-loaded WebServer (actually only the "Main" routine is in a cog) tries to send characters I get cool crashes that stream endless random data out the serial port. I know I'm clobbering the stack, and basically have moved around the WebServer code without understanding some of the basics when moving spin code into cogs - like perhaps needing semaphores and/or exclusivity when accessing the serial port.
The hardware is a Spinneret piggybacked on a board full of DIPSwitches, relays, leds, motor-drivers...all sorts of stuff controlled via SPI and directly connected.
My initial thought was to modify the Server to accept a telnet connection on one of the sockets, and stream the debug-print out that way, so I could at least get a clue what's happening.
Any help appreciated, and of course excuse me for not finding any existing answer or existing code already on the forums - I looked for quite a while before posting.
Comments
Greg
HTTPServer is already running in a COG and globally available. The Main method just processes queued sockets. Replace the Main method with your core control code or roll the core control code into it's own COG process.
So...I've made HTTPServer run in *two* cogs? Talk about contention! Although all I really did was make HTTPServer's "Main" run in a cog.
I must be using HTTPServer incorrectly. Let's say I have my own top-level .spin file. How would I launch the HTTPServer?
But...the Initialize spin code never returns to my code. Right? It jumps to Main. So...my code never gets to "cognew".
Feeling a bit dumb here.
So, let me back up and make sure where I am: Is the latest version of the HTTPServer the one in the Google code repository? That's the version I'm using. I think.
I have a feeling maybe I'm not using the latest version. The one I am using starts the W5100 Driver in a cog, then starts the W5100 StatusMonitor in a cog, and then loops in Main (actually executes "Main", which then Jumps to "GotoMain", which then Jumps to "Main") - "HTTPServer.spin", I believe.
I see that my SVN checkout of spinneret-web-server-read-only also contains HTTPServerBase.spin and HTTPServerMinimal.spin. I have to examine those two again - maybe I'm using the wrong starting point.
Forgive me for not figuring this out quicker - I'm still a little confused from flailing at it for the last few nights....
If you have a process to run, then do so in the HTTPServer application.
Here's how I've currently got it arranged - I modified the HTTPServer application into HTTPServerClass "module" (wrong terminology, but you get the idea) by adding methods that launch the Main routine in it's own cog from within HTTPServerClass - a "Start" routine and a "Stop" routine.
"Initialize" is modified so that it doesn't call "Main" at the end of initialization. "Main" is modified to repeat infinitely, rather than call GotoMain. The rest of the code is largely unchanged.
To fire up the Webserver, the Top-level spin file ("SwitchBoard") does
And it works - my pages get served out, and my added Dispatcher routines work as expected. I just can't send debug data out the serial line.
But...none of the pst.str statements produce any serial output.
I'll try to restructure the code of my top-level file ("Switchboard") into HTTPServer as you suggested and see if that fixes the problem with serial output...
Consider keeping the PST object in the top level object. Use the AppendLog method for debug trace in the server.
Nice work! Looking forward to the finished product.
What's the right way for a SubObject to use a parent object's PST object - if there is one? e.g. if "SwitchBoard" inits the PST object, how can HTTPServerClass use it? Do I pass in the address of the PST object and use it indirect, or is there another way?
That would solve the immediate problem of no realtime debug output within the WebServer. In the meantime I'll add more AppendLogs before doing the rewrite to see if there's something obvious tripping me up.
Thanks for taking the time to address this - I'll post again when I figure out the immediate error, or execute the rewrite..
I'll say this one more time. Why not simply use the HTTPServer top level object to start the control code? Then you have access to all resources. Rename HTTPSErver to whatever you like.
I realize the urge to encapsulate the web server but 1) HTTPServer is an application not an object. 2) Spin is not like a high level OOP language.