Skip to main content

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - bonybrown

16
Web platform / Re: Problems with MAX_HTTP_CONNECTIONS > 1
After some digging I've managed to get it to serve more than 1 static file concurrently, but dynamic variables and includes are still broken.
The problem seems to be that the STACK_USE_MDD sections in HTTP2_MDD were not written to expect more than 1 http connection at a time; there's lots of static variables in HTTPSendFile() that shouldn't be static; they are state that need to be saved and restored in the HTTP_CONN struct for each connection.

It could be fixed, but using MAX_HTTP_CONNECTIONS = 1 is a simpler workaround. I'm not sure if there's any real downside to only serving one file at a time anyway?

Given that we would all be better off with a truly open source software stack, the effort is probably better invested in porting or implementing a new webserver on top of the uIP port.

Tony.
17
Web platform / Re: Problems with MAX_HTTP_CONNECTIONS > 1
Thanks Markus,

As you're also seeing a problem, I think it's safe to say there is a bug here.

The HTTPSendFile() function is split into two sections: the #ifdef STACK_USE_MDD part and the #else section that uses MPFSGetArray() to get the files to serve.
The latter section ( the EEPROM specfic part ) is much simpler than the MDD section; looking at it, it doesn't seem to have the same bug, so I definately think it's in HTTPSendFile(), not the MDD library.

I'll see what I can do with it.
Tony.
18
Web platform / Re: How to create a new file?
No, haven't tried yet, but writing files to the SD card is something that I will want to do ( when I get to that bit ).

If you've configured UART 1correctly, and are able to send data back to a PC using printf() - that is, you've created an implementation of _mon_putc(char c ), something like so:
Code: [Select]
void _mon_putc(char c){
while(U1STAbits.UTXBF == 1); //if buffer is full, wait
    U1TXREG = c;
}

Then you could log requests to the serial port by simply adding printf() statements in the SM_HTTP_PARSE_REQUEST switch case in HTTP2_MDD.c
Once that's successful, it should be a short jump to writing it to a file instead ( swap printf() from stdio.h to FSvfprintf() from FSIO.h )

Tony.
19
Web platform / Problems with MAX_HTTP_CONNECTIONS > 1
I've built the code for this project successfully and managed to upload it via the bootloader.
It serves out files fine....but...when the browser has > 1 simultaneous requests, the server tends to corrupt the served files (typically, .js files used in a simple html page end up with garbage appended to the end)
Setting MAX_HTTP_CONNECTIONS back to 1 solves the problem, so seems like a bug in the Microchip HTTP2 stack (is this likely? )

A bit more digging (that is, debugging HTTP2_MDD.c with printf() statements... I have no debugger ), it would seem that in the SM_SERVE_TEXT_DATA: case (around line 1566 ) the value for numBytes isn't being switched to the file being read for the packet to be sent for this time around the service loop; that is, there is one numBytes variable, that isn't being reset when HTTPLoadConn() switches the tcp connection (that's mostly a guess - I haven't proven that this function is called at all, but seems that it should be when > 1 HTTP connection is allowed)

So firstly - is anyone else seeing this problem too?

And I don't know if it's just me, but all of the if..else.. cases in SM_SERVE_TEXT_DATA could be replaced simply with
Code: [Select]
			if(availbleTcpBuffSize != 0){
    //count will be the minimum of databuffer size, available TCP buffer and bytes remaining in file being served
WORD count = mMIN( 64, availbleTcpBuffSize ); //64 = buffer size (TODO: change to const WORD buffer_size = ?? or #define and use in declaration of databuffer )
count = mMIN( count , numBytes );
len=FSfread(databuffer, count, 1, curHTTP.file);
TCPPutArray(sktHTTP, databuffer, count);
numBytes -= count;
}

This works for me, anyhow. Doesn't solve the suspected bug though.
Does anyone know what the legality of distibuting patches against the Microchip stack is, given that we can't distribute the stack itself in source form?

Anyhow, looking forward to any feedback,
Tony.