Messages

46

µTasker general / Re: Request: please complete proper TCP/IP API documents :)

« on: January 20, 2010, 07:46:30 AM »

Yes, I am definitely sticking with simple sockets. Having started the design from uIP which has no buffering, its a lot easier (and anyway suits the kind of thing we are doing).

47

µTasker general / Re: Request: please complete proper TCP/IP API documents :)

« on: January 19, 2010, 12:03:33 AM »

Next question.
I presume that fnTCPSend will complain if I already sent some data that is unacked? Or, will it just allow me to send again?

48

µTasker general / Re: Request: please complete proper TCP/IP API documents :)

« on: January 15, 2010, 04:02:12 AM »

Hello Mark, just so you know you're getting something out of this, we bought a project license It's under Vicki Toon, our administrator/CC holder ..

49

µTasker general / Re: Request: please complete proper TCP/IP API documents :)

« on: January 15, 2010, 03:42:58 AM »

Hm OK lots of interesting notes in the TCP Close docs .. thanks, I will absorb these...

I'm still a bit confused with this section:

The event TCP_EVENT_CLOSED is sent to the application although the socket state is TIME WAIT - the socket has not fully closed, even though the TCP partner has completely acknowledged the close sequence. The TIME WAIT generally lasts for a period of 2 minutes (specified as 2MSL - twice the Maximum Seqment Lifetime).

This seems to be saying that reusing the socket by doing a fnTCP_listen is a bad idea (at least for a socket going across the internet). Or, does fnTCP_listen still respect the WAIT TIME?

Perhaps this is what I'm experiencing, although it only seems to last a few seconds?

On Windows, the FD_CLOSE is sent once the FIN is completed, it doesn't wait for 2MSL; so in this respect your event seems the same.

Where is SOCKET_STATE_INVALID defined?
Is fnGetTCP_Socket the same as fnTCP_Connect?

50

µTasker general / Re: Request: please complete proper TCP/IP API documents :)

« on: January 14, 2010, 06:20:24 AM »

(separated this from the rest of the general comments)

fnTCP_close() : are there any conditions on this? I am wanting to use it to close a server socket after a timeout - so not inside a call from the TCP stack. I could see that if I wanted to close inside a callback, I would use APP_REQUEST_CLOSE...
I ask because I basically copied out of one of the examples, first using fnTCP_Close, then fnTCP_Listen after getting the CLOSE event; and the client doesn't seem to be able to connect again.

Code: [Select]

fnTCP_close( g_ControlSocket );
...
static int fnControlListener( USOCKET Socket,  ... ) {
    switch (ucEvent) {
...
    case TCP_EVENT_ABORT:
    case TCP_EVENT_CLOSED:
fnTCP_Listen( Socket, CONTROL_PORT, 0 );                    // go back to listening state

Edit: Now I have this working, although there is a period of a few seconds after close when new connections are refused (get a Windows socket error 10061). Is that expected? Does it mean I'm not doing a proper graceful shutdown? The Windows side is doing shutdown, waiting for FD_CLOSE, then closesocket...

Is there a general way to find out if a socket is connected? fnGetTCP_State looking for TCP_STATE_ESTABLISHED?? Seems overly reliant on internal details. I'd rather not have to have another variable of my own ...

51

µTasker general / Re: General comments as new user

« on: January 13, 2010, 06:42:25 AM »

Thank for the tips. Yes I know the IDE could be better, but Visual Studio doesn't offer integrated debugging on ARM does it?
In retrospect Eclipse might have been better than Rowley Crossworks but someone else went thru the selection process...

I've now deleted a lot of the code out of my project and its getting more managable.

52

µTasker general / Re: Request: please complete proper TCP/IP API documents :)

« on: January 13, 2010, 06:40:37 AM »

Hello Mark,

Thanks that is looking helpful. The section on fnGetTCP_Socket is good.
Observations:
- it would be better if it didn't use browser Frames because it makes it difficult to link to a page within the docs.
- seems odd to categorise it by the implementation file - as an API I wouldn't expect to have to know which source file to use Only a nit.
- a search or index function to look up functions by name is useful.

An observation on the API: the function naming seems a bit inconsistent.  For example some TCP functions
fnHandleTCP
fnTCP_Listen
fnGetTCP_state
sometimes the TCP is at the start with an underscore after, sometimes in the middle, sometimes at the end. Sometimes the part after the underscore is capitalised (_Listen) , sometimes not (_state).
This is only minor but makes the API a little bit harder to use because the names of the functions are harder to remember and/or determine.

53

µTasker general / Re: Request: please complete proper TCP/IP API documents :)

« on: January 12, 2010, 02:12:57 AM »

OK, but that sounds some time away...

At least could you add to the forum thread, a description of each function and it's parameters? I know its a lot more work to do it in a pretty document...
Thanks.

54

µTasker general / Request: please complete proper TCP/IP API documents :)

« on: January 12, 2010, 12:02:18 AM »

Hello Mark,
Could you please finalise the TCP/IP API document?
I know about the forum thread, but it is a very clumsy way to read and not very complete.
I would really appreciate some standard API documentation describing the parameters, return codes and usage of each function.
Thanks.

55

µTasker general / Re: General comments as new user

« on: January 11, 2010, 11:58:17 PM »

Just an additional note here, the size of the demo project has also been a problem trying to isolate problems, because there is such a large amount of code. Even though a lot of it is compiled out, this is not obvious when examining the code so it's hard to tell which parts are really being used.

I've worked before on such projects, with massive #ifdef conditionals to handle multiple environments, and they are always painful to maintain.

I intend to delete most of the code from the uTasker sample project to get it down to a maintainable form...

56

NXP^TM LPC2XXX and LPC17XX / Re: Hang assigning EMAC_RxStatus

« on: January 11, 2010, 11:28:01 PM »

It's probably our fault in the hardware somewhere, but we don't know what to look for.
Theres a possibility the 2368 works but the 2366 doesn't, so we'll try the 2368.
We're trying to get help from NXP but their support seems to be non-existent ...

57

NXP^TM LPC2XXX and LPC17XX / Re: LPC2366 Flash size wrong

« on: January 11, 2010, 11:26:30 PM »

Yep, SMSC have screwed up their datasheet majorly. It used to be correct but the currently distributed one on their site seems to have a lot of data left over from the LAN8700. Pretty poor effort.
We've contacted them about this, of course ... :/
http://www.smsc.com/media/Downloads_Public/Data_Sheets/8720.pdf

58

NXP^TM LPC2XXX and LPC17XX / Re: Hard hang in uMallocLAN_Align

« on: January 06, 2010, 05:30:42 AM »

OK Now I have work out it's not in uMallocLAN_Align
Rather the chip is hanging when EMAC_RxStatus is assigned
The address is always the same 0x7fe01800.
which is 8-byte aligned as it's supposed to be (though the datasheet seems slightly confused here, 4 or 8 byte aligned?).

This would seem like a CPU hardware fault to me ...

59

NXP^TM LPC2XXX and LPC17XX / Hang assigning EMAC_RxStatus

« on: January 06, 2010, 04:53:17 AM »

I have an intermittent hang in the second call to uMallocLAN_Align in fnConfigEthernet for LPC23xx.
Interestingly, when this hang happens CrossWorks cannot break into it (cannot stop target).

Sometimes when running the app, the startup works fine and the stack goes on to work fine (as far as I can tell, only have Ping so far). Other times it hangs as noted.

Code: [Select]

   EMAC_RxStatus = (unsigned long)uMallocLAN_Align((unsigned short)(sizeof(LPC23XX_RX_STATUS)*i), 8);    // create a smaller pool of buffer descriptors

Because it's intermittent and unstoppable once hung, I have to do this by trial and error so it's slow to find ...
Tips?

60

NXP^TM LPC2XXX and LPC17XX / Re: NXP project - debug is set to optimise

« on: January 06, 2010, 04:45:13 AM »

IMO this is a basic expectation of a "debug" build, that you can step through it cleanly.
On the 2366 I often had lines of code that plainly were functional that it could not break or step onto (e.g. a function call). This made it almost impossible to debug the ethernet PHY stuff.

Well of course it's your product but this is one customer at least who didn't expect that the debug build would be set to optimise.

I know about the watchdog and have already disabled it. Thanks.