Interesting... The Elektor one is $85, more than 2X the cost of "our" web server. I don't have a subscription to Elektor either. It would be interesting to find out more of the particulars of this device.
The API seems a little more complicated than simple posts / gets... It uses encrypted data (https). As I mentioned, I am not much of a programmer, so to me it seems complicated. You may think it is trivial!!
Sqkybeaver: Why re-invent the wheel? What don't you like about the Dangerous Prototypes web platform that leads you to work on an ARM design? Can the ARM design be competitive with the $40 cost of the web platform?
One of the reasons I became interested in the Web Platform was because it seemed ideally suited for use as a Google Powermeter appliance. For those of you not familiar with this, check out the introductory page here: http://www.google.com/powermeter/about/about.html
The principal is to continuously monitor your home energy usage and thus be able to identify inefficiencies allowing you to reduce consumption in an observable way. There are a couple of different ways to sense energy consumption including optical detection of the spinning wheel in a mechanical power meter, or clamp-on current transformers to sense the main split phase current feeding your home.
Google has defined an API such that you can feed your consumption information through the web for collection and subsequent analysis and graphical display.
It is possible to purchase devices that connect to your home and feed data to Google, but it can be much more rewarding to build and customize your own project.
There are a couple of things that make the Web Platform a very nice choice. First, it's small size, low cost, low power, and ethernet capability facilitate continuous unattended operation. The built-in ADC's can be used to connect the appropriate current sensor. Best of all however, is the fact that Microchip has a Google Powermeter demonstration application that is configured to run on a nearly identical dsPIC33 device. This should greatly reduce software development time.
This reference design comes as part of the Microchip Applications Libraries that are also used as the basis for the Web Platform firmware already familiar to those in this forum.
I have taken the first step by making some alterations to the Microchip reference design, to reflect the hardware configuration of the Web Platform board. Although I managed to get it to build, it does not run, so there is plenty more work to do.
I will continue to hack my way along with this, but I am not really a serious programmer and it will probably take me quite some time to complete this project. I was wondering if there were others in this group who would be interested in collaborating on this project. I have ordered a couple of current sensors, and am still awaiting their arrival. There are two aspects to this - first, the hardware and interface to perform the measurement, and second, the software to interface with the Google API. I have some thoughts as to how I plan to approach the hardware side. The software interface seems more complicated to me but the Microchip reference design seems to go a long way in that direction.
Let me know if anyone has an interest in this project.
Per your suggestion, I made the following changes (to TCPIPConfig.h)...
1. Changed MAX_HTTP_CONNECTIONS from 2 to 4 2. Got rid of 2nd one of these: {TCP_PURPOSE_HTTP_SERVER, TCP_ETH_RAM, 200, 200} 3. Changed MAX_MPFS_HANDLES from 0x07 to 0x09
Same story with a slight twist... It pings, then when I try to access a page it hangs (heartbeat stops). After a LONG time (maybe 20 seconds), a web page from the SD card pops up in the browser. Everything is still hung though (no pings, no further activity with web pages, nothing).
One more time... I tried to build the SD application. Here are my exact steps:
1. Downloaded and installed Microchip Applications Library (MCHP_App_ Lib v2010_02_09_Installer). This contains the 5.20 version of the TCP/IP stack.
2. Made a working copy of the C:Microchip SolutionsTCPIP MDD Demo App directory tree.
3. Took these 6 files: Maindemo.c/.h, HardwareProfile.h, TCPIPConfig.h, TCPIP MDD SD Card Demo App-C30.mcw/.mcp contained here: web-platform-SDcardServer.v0a, and replaced them in the working "TCPIP MDD Demo App" folder 4. Opened the project and "Build All" -- (MPLAB v8.60), no errors
Resulting HEX file runs, pings, but hangs upon receipt of first web request.
5. Added the 9 Nop()'s in the WriteReg function of ENC28J60.c after Dummy = ENC_SSPBUF;
Resulting HEX file runs, pings, but hangs upon receipt of first web request.
My hexfiles are attached (without and with the Nop()'s ). Maybe you could give them a try. This is very frustrating.
Thank you for posting the HEX file... I find the results interesting (although perplexing).
Your hex file at least seems "stable". When I flash it, the heartbeat is perpetually good. I can ping the board just fine. When I attempt to access the http server, I get no response, but the board remains up and running just fine. The heartbeat continues and I can still ping it after an un-responsive web page request. You mentioned the debugging output... This may yield a clue as to where my problem is. If I look at the USB serial port at 115K, it does indeed echo any character that I type. It does NOT however show anything else. When I try to access a web page on the SD card, the browser gets no response and times out. There is nothing shown on the serial port either. It is as though the http request is just not being received. As you mention, the serial port should show the page / file being requested? For some reason it does not.
WAIT --- Something else that was said in passing triggered a thought --- It was mentioned that your server is running on Port 81. Maybe this should have been obvious, but I was just letting the port default. When I try Port 81, your build works fine !!! And, it does indeed echo the file request via USB !!!
Still doesn't explain why I can't seem to get a good build myself, but proves my hardware is OK.
Well, I tried again with the v5.20b stack. Still no luck, in fact it seems worse.
Now, after a reset, the heartbeat only blinks anywhere from 1 to 3 times before it hangs. With the 5.31 stack, the heartbeat (and ping) would run fine until I tried to access a web page. If I try hard enough, I can catch a ping before the board hangs after the 1-3 blinks.
I tried the various fixes including the Nop()'s. No different.
Is there a way you can send me a known good HEX file that works with an SDHC card?
I'm pretty sure the board is OK because it runs perfectly with the non-SD Card build (MPFS files, on-board memory).
I went back to the baseline, with only the "preferred" change adding the 9 NOP's (seems mundane enough)... After a reset, the heartbeat LED is blinking fine, and it pings OK. As soon as I try to access the HTTP server, it hangs and the heartbeat LED stops blinking.
I guess it's time for the debugger... I have an [ancient] homemade PIC programmer (parallel port). I am hoping it is compatible with the ICSP connector (and the modern MPLAB)...
I am having some trouble with the SD demo application. I have the Web Platform 1.1. By following the instructions in the Readme file, I have gotten the web-platform-SDcardServer.v0a to build successfully.
I installed a 4G microSD card (formatted with SDFormatter). When I download my hex file, the server acquires an IP address properly and I can ping it just fine. Unfortunately, I get nothing when I try to access the server from a browser, and then it just seems to hang (I can no longer ping the board).
I saw the remarks here: http://dangerousprototypes.com/docs/SD_ ... erver_demo, where changes to 'enc28j60.c' are discussed to avoid lockups. I mechanized the "more correct" fix by adding the 9 NOP's, but it still behaves the same way.
I am probably doing something dumb... Any recommendations?
