Skip to main content

Topics

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

Topics - bonybrown

1
Web platform / New uIP code features
Hi all,

Just dropped another update to the uIP stack project to svn/trunk/web-platform/firmware/uIPStack.
Some notable changes are:
  • The code runs 3 "tasks" that it multitasks between. One for the IP stack, one for the serial port (debugging help) and another for a handler for telnet (port 23). The point of the multitasker is to make it simpler to code stuff without worrying about blocking other things that need to happen (particularly, the network stack, or other tasks)
  • The telnet server task is pretty easily extendable ( just add the name of the command, and a pointer to the function that implements it to telnettask.c)
  • To find out what commands it supports, enter "help"
  • It should be reasonably easy to write a web server task now, but without the ability to read files, you can't serve much (maybe dump all the memory to a html response??)

Some FYIs:
The IP address is fixed in code as 10.0.0.251. You'll need to change as desired.
Lots of debug stuff still being printed to the serial port at 115200 (8/1/none)

Good luck!
Tony.
2
Web platform / uip tcp/ip port... working!
I've finally got the uip tcp/ip stack working on the web platform. What a learning curve!
This (attached) is based on the code in the uIP_Pic33_port_k project in the google code svn. There's lots of commented out blocks, code comments that are not longer correct, debug code and it's a bit all over the place, but at least demonstrates the code works.

The project attached here will setup the IP address of the web platform as 10.0.0.251 and listen on port 23 (telnet ) for a max of 10 simultaneous connections.
 You should be able to ping it, and telnet to it. It will echo back messages sent to it.

You should also know that it will output a lot of debugging stuff on the usb serial port ( at 115200 ). The code always enables the UART, so the usual warnings about backpowering the usb chip apply (ie, make sure you have the usb cable connected )

I'm getting ping times of around 0.680 mS. The SPI bus is operating at SPRE 1:1 and PPRE 4:1, which seems to be as fast as the datasheet suggests is possible @ 40MHz Fcy (so that's 10MHz SPI, although the ENC28J60 says it will work up to 20MHz. I haven't tried that... seem to recall some other thread having problems going that high? )

Next steps I'd like to try are to replace the polling loop with an interrupt from the ENC28J60 when packets arrive, and to try using DMA to get the packets into and out of the ENC28J60.

Regards,
Tony.
3
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.