ucip-devel — uC/IP Developers Discussion list (heavy)

[Ucip-devel] Enrico: devio.c

[enrico <enr...@fa...>]

hi guys,

 since I wanna make some tests, I implemented a small portion of the file:

                                                      devio.c

 that should contain the code to access the serial ports of the PC or the
embedded device.
 Please, could someone take a look at the code and let me know whether  I'm on
the right track or not?
 In order not have blocking I/O read/write I'm gonna use 2 ring buffer per serial
port.
 Yet, I alread implemented  read/write on WIN32, using two threads: one for
automatic
 byte writing and one for reading.

 bye
 Enrico


The following file successfully compileable with VC++ 5.0

 /************************************************************************/
#include <string.h>
// #include "NetTypes.h"
#include "devio.h"



typedef struct DevCB_s {
 const char * name;
    unsigned char flag;
    unsigned char accessFlag;
    unsigned char openFlag;

} DevCB;

#define MAXDEV 2

static DevCB devcbs[MAXDEV];


/* Input output control */

int ioctl(int fid, int cmd, void *arg) {

 DevCB *devCB;
    int st;

 st = 0;
 devCB = &devcbs[fid];

 if (fid >= MAXDEV ) {

  st = errno = EBADF;
 }

 else if (!devCB){
        return -1;
 }
 else {

      switch(cmd) {

        case SETBAUD:      /* Set the baud rate */
            if (arg) {
    switch (*(int *)arg) {
        case B9600:
                        devCB->flag &= (0xf0 + B9600);
      break;
     default:
      devCB->flag &= (0xf0 + B9600);
      break;
    }

   }
            else {
                st = -1;
   }
            break;


        default:
            st = -1;
            break;
      }
    }
 return st;

}


/* Find a free session descriptor. */
int open(const char *name, const int access, ... ) { /* Open fid on name */

    int fid;

 // OS_ENTER_CRITICAL();

    for (fid = 0; (fid < MAXDEV) && (devcbs[fid].openFlag != 0) &&
(strcmp(name,devcbs[fid].name) != 0); fid++ );

 if (fid >= MAXDEV) {
     return fid = -1;
 }

 devcbs[fid].openFlag = 0x01;                            /* Open device */
    devcbs[fid].accessFlag = (unsigned char) access;        /* Set access flag */

 // OS_EXIT_CRITICAL();

 /* Set UART or SCI registers or call Comm functions on WIN32 */
}

/* read n char from device */
int read(int fid, void *s, int n) {


    /* Looking for fid */

 for (fid = 0; (fid < MAXDEV) && (devcbs[fid].openFlag != 0) ; fid++ );

 if (fid >= MAXDEV) {
  return fid = -1;
 }
 else if (devcbs[fid].accessFlag & O_RDWR > 0) {
        errno = EBADF;
  return -1;
 }

    /* Fase 1: effettuo la lettura */
}

/* write n char to device */
int write(int fid, const void *s, int n) {

    /* Fase 1: scorro in avanti finche' trovo un devcbs */

 for (fid = 0; (fid < MAXDEV) && (devcbs[fid].openFlag != 0) ; fid++ );

 if (fid >= MAXDEV) {
  return fid = -1;
 }
 else if (devcbs[fid].accessFlag & O_RDWR > 0) {
        errno = EBADF;
  return -1;
 }

    /* write to UART, SCI or use Comm functions */
}

/* Close a device */

int close(int fid) {

 // OS_ENTER_CRITICAL();
 if ((fid < 0) || (fid > MAXDEV)) {
  return -1;
 }
    else if (devcbs[fid].openFlag != 0x00) {
        devcbs[fid].openFlag = 0x00;
  devcbs[fid].accessFlag = 0x00;        /* Clear access flag */
 }

 // OS_EXIT_CRITICAL();

}

[Ucip-devel] API documentation and echotest

[enrico <enr...@fa...>]

hi guys,

 the job of documenting the project is going on. In the mean time, I'd like
 to make some tests. I imported the echotest workspace in VC5.0, successfully
 compiled and noticed some interesting features:

 1. UCOS and the CS8900 adapter are emulated by a thread
 2. The memory subsytem allocation of network buffers  is done statically

 The echotest executable need the file packet.dll, where could I find it?

 thanks
 Enrico

[Ucip-devel] UC/IP (READ THIS ROBERT)

[Mads C. <MC...@vo...>]

Hi Tobias!

In Roberts CS89xx driver he doesn't update the chainLen which is an ERROR =
(as I wrote to you in the first email).
If this is not corrected you will not have the stack up and running =
correctly.

The stack functions very well with 128 bytes NBufs. The error is in the =
driver!!!

Have you tried this ?!?

  NBuf *nbufChain;
  NBuf *lastBufferInChain;
  u_short newWord;

  // This will reserve room for the first nbuf in the cain
  nGET(nBufChain);

  lastBufferInChain =3D nBufChain;

  while (data to read from the NIC ?)
  {
     newWord =3D read word from NIC;
     lastBufferInChain =3D NBufPutW(newWord, lastBufferInChain);
  }
=20
  AT LAST YOU MUST BY YOUR SELF UPDATE THE CHAINLEN OR IT WILL NOT WORK.

Best wishes,
Mads.
 =20


>>> Tobias F=F6ll <tf...@je...> 12/03 12:28  >>>
Hi Mads,

thank you for inquiry.
1) I increased the NBUFSZ from 128 to 512 this solves some problems.
But i started again to understand why this solves my problems. On the =
moment
i can not explain why ???
2) Aftwer this change i found following problem:
Netudp.c line 731

i removed following if statement, because chainlen was always 0.

//tftf	if (inBuf->chainLen <=3D (sizeof(IPHdr) + sizeof(UDPHdr))) {
		// Free "memory"
//tftf		nFreeChain(inBuf);
//tftf		return;
//tftf	}

Ping is working, but i can not send an udp answer with the stack. ????


Tobias


-----Urspr=FCngliche Nachricht-----
Von: Mads Christiansen [mailto:MC...@vo...]=20
Gesendet: Montag, 3. Dezember 2001 12:08
An: tf...@je...=20
Betreff: Videresendt: Fw: UC/IP (take a look at this Robert)


Hi Tobias.

How is it going ?
Did this help you ?

Best wishes,
Mads.

>>> Mads Christiansen 11/21 8:13  >>>

----- Original Message -----
From: "Tobias F=F6ll" <tf...@je...>
To: <ma...@mo...>
Sent: Tuesday, November 20, 2001 10:00 AM
Subject: UC/IP

Hi Tobias!

And welcome aboard.

After a very quick look at the if_cs89d.c driver file it looks as if there
might be a bug in this driver file.
I personally use the NE2000 driver and haven't used the cs89xx driver.
Now if we take a closer look at the source....
(I have removed any comments for clearence and added some line numbers)

NBuf* NBufPutW(u_short w, NBuf* nb)
{
	NBuf* tb =3D nb;

1)	if (nb && (&nb->body[NBUFSZ] - (nb->data + nb->len)) < 2) {
        OS_ENTER_CRITICAL();
2)		nGET(tb);
        OS_EXIT_CRITICAL();
3)		if (tb) {
4)			nb->nextBuf =3D tb;
5)			tb->len =3D 0;
		}
6)		nb =3D tb;
	}
7)	if (nb) {
8)		*(u_short*)(nb->data + nb->len) =3D w;
9)                            nb->len +=3D 2;
	}
10)	return tb;
}


1) Robert (the writer of this driver) checks if we should create a new =
nBuf
(because the current one hasn't room enough)
2) We allocate another nBuf
3) If allocation succeeded
4) Append this new nBuf to the end of nb   (THIS MIGHT CAUSE A PROBLEM)
5) Zero set length of allocated nBuf
6) Set nb =3D tb
7) If any Nbuf (nb)
8) Copy word into nBuf
9) Adjust length of nBuf (+2)
10) Return pointer to last nBuf
There is also one more problem (se further down).

If this function is used wrongly you might very well always overwrite data
in the second buffer in the chain.
I think Robert wants you to used the function like this (else it will
FAIL!).

  NBuf *nbufChain;
  NBuf *lastBufferInChain;
  u_short newWord;

  // This will reserve room for the first nbuf in the cain
  nGET(nBufChain);

  lastBufferInChain =3D nBufChain;

  while (data to read from the NIC ?)
  {
     newWord =3D read word from NIC;
     lastBufferInChain =3D NBufPutW(newWord, lastBufferInChain);
  }

First I save the original nBuf in the chain, because this is the one you
want to pass to netether.
If you doesn't use the NBufPutW function as above you will always (when =
the
first NBuf is full)
allocate a new NBuf and add a word to it plus throwing the original =
chained
NBuf away!

The other problem I mentioned is that the first NBuf in a chain has a =
member
(they all do) named
chainLen. This should be updated for the number of bytes in the total =
chain.
If this is not
updated it will probably cause problems later.

You might want to talk with Robert about this.

Hope this helps,
please feel free to ask for help again,

Best wishes,
Mads.


>
> Hi Mads,
>
> Sorry to boring you.
> I saw that you changed something in the UC/IP project.
>
> i checked the tcp/ip stack with an ping command.
> It is working on my embeeded system, very fine.
>
> Then i checked with an UDP packet.
> But i find out that an CRC error occured. I checked also the data in the
> receive buffer of the stack.
> I find out that the UDP packet has 128 byte, and the receive routine =
adds
an
> second buffer.
> An this caused the error:
> It overwrites data in the buffer
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> My embedded system has the advantage to trigger on a special adress.
Because
> of this i find that in the file
> : if_cs89d.c in Line 145  if(nb && (&nb->body[NBUFSZ] -(nb->data +
nb->len))
> < 2) {
>
> the error occured.
>
> I used revision 2 of the software, is this an known bug ?
> I can try to solve it, but how to integrate into the project ?
> Or is this error solved in the newest version ?
>
>
> Regards
>
> Tobias
>
> ----------------------------------------
> Jetter AG
> Tobias F=F6ll
> Phone:  +49 7141 2550 446
> Fax:    +49 7141 2550 556
> mailto:tf...@je...=20
> web: http://www.jetter.de=20
>

[Ucip-devel] Fw: UC/IP (take a look at this Robert)

[Mads C. <MC...@vo...>]

----- Original Message -----
From: "Tobias F=F6ll" <tf...@je...>
To: <ma...@mo...>
Sent: Tuesday, November 20, 2001 10:00 AM
Subject: UC/IP

Hi Tobias!

And welcome aboard.

After a very quick look at the if_cs89d.c driver file it looks as if there =
might be a bug in this driver file.
I personally use the NE2000 driver and haven't used the cs89xx driver.
Now if we take a closer look at the source....
(I have removed any comments for clearence and added some line numbers)

NBuf* NBufPutW(u_short w, NBuf* nb)
{
	NBuf* tb =3D nb;
=09
1)	if (nb && (&nb->body[NBUFSZ] - (nb->data + nb->len)) < 2) {
        OS_ENTER_CRITICAL();
2)		nGET(tb);
        OS_EXIT_CRITICAL();
3)		if (tb) {
4)			nb->nextBuf =3D tb;
5)			tb->len =3D 0;
		}
6)		nb =3D tb;
	}
7)	if (nb) {
8)		*(u_short*)(nb->data + nb->len) =3D w;
9)                            nb->len +=3D 2;
	}
10)	return tb;
}


1) Robert (the writer of this driver) checks if we should create a new =
nBuf (because the current one hasn't room enough)
2) We allocate another nBuf
3) If allocation succeeded
4) Append this new nBuf to the end of nb   (THIS MIGHT CAUSE A PROBLEM)
5) Zero set length of allocated nBuf
6) Set nb =3D tb=20
7) If any Nbuf (nb)
8) Copy word into nBuf
9) Adjust length of nBuf (+2)
10) Return pointer to last nBuf=20
There is also one more problem (se further down).

If this function is used wrongly you might very well always overwrite data =
in the second buffer in the chain.
I think Robert wants you to used the function like this (else it will =
FAIL!).

  NBuf *nbufChain;
  NBuf *lastBufferInChain;
  u_short newWord;

  // This will reserve room for the first nbuf in the cain
  nGET(nBufChain);

  lastBufferInChain =3D nBufChain;
 =20
  while (data to read from the NIC ?)
  {
     newWord =3D read word from NIC;
     lastBufferInChain =3D NBufPutW(newWord, lastBufferInChain);
  }

First I save the original nBuf in the chain, because this is the one you =
want to pass to netether.
If you doesn't use the NBufPutW function as above you will always (when =
the first NBuf is full)
allocate a new NBuf and add a word to it plus throwing the original =
chained NBuf away!

The other problem I mentioned is that the first NBuf in a chain has a =
member (they all do) named
chainLen. This should be updated for the number of bytes in the total =
chain. If this is not
updated it will probably cause problems later.=20

You might want to talk with Robert about this.

Hope this helps,
please feel free to ask for help again,

Best wishes,
Mads.


>
> Hi Mads,
>
> Sorry to boring you.
> I saw that you changed something in the UC/IP project.
>
> i checked the tcp/ip stack with an ping command.
> It is working on my embeeded system, very fine.
>
> Then i checked with an UDP packet.
> But i find out that an CRC error occured. I checked also the data in the
> receive buffer of the stack.
> I find out that the UDP packet has 128 byte, and the receive routine =
adds
an
> second buffer.
> An this caused the error:
> It overwrites data in the buffer
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> My embedded system has the advantage to trigger on a special adress.
Because
> of this i find that in the file
> : if_cs89d.c in Line 145  if(nb && (&nb->body[NBUFSZ] -(nb->data +
nb->len))
> < 2) {
>
> the error occured.
>
> I used revision 2 of the software, is this an known bug ?
> I can try to solve it, but how to integrate into the project ?
> Or is this error solved in the newest version ?
>
>
> Regards
>
> Tobias
>
> ----------------------------------------
> Jetter AG
> Tobias F=F6ll
> Phone:  +49 7141 2550 446
> Fax:    +49 7141 2550 556
> mailto:tf...@je...=20
> web: http://www.jetter.de=20
>

[Ucip-devel] i have run the ucip under win2000(using VC6.0)

[wangc <wa...@se...>]

SnVzdCB0aGUgdWRwIHBhcnQhQW5kIG5vdyBpIGFtIGRlYWxpbmcgd2l0aCB0aGUgdGNwIHBhcnQh
SXQgc2VlbXMgdGhhdCB0aGVyZSBpcyANCnNvbWV0aGluZyB3aXRoIHRoZSBUQ1AgdGltZXIhDQo=

[Ucip-devel] API documentaion: new file added

[enrico <enr...@fa...>]

hi guys,
 here I'am back on Eearth...
 The job of documenting the project files is going on: I just added a
new file.
 I've completed a third of the job so far.

 Enrico

[Ucip-devel] UCIP

[<tf...@je...>]

Hi,

i ported the stack to my embeeded system.
ucos-ii is running in 32 Bit flat memory model. Great....
the ping is working... Great !!!!!!!!!!!!!!!!!!!

But until now, i was not able to run the echotest program.
I started the task :
....

void UdpEchoTask(void* dummy)
{
    int bytes;
    int socket;
    struct sockaddr_in sockAddr;
    char buffer[512];

//tftf    TRACE("UdpEchoTask Started\n");

    sockAddr.ipAddr = INADDR_ANY;
    sockAddr.sin_port = htons(2010);
    sockAddr.sin_family = AF_INET;

    socket = udpOpen();
    udpBind(socket, &sockAddr);
    do {
        bytes = udpRead(socket, &buffer, sizeof(buffer));
        if (bytes > 0) {
            udpWrite(socket, buffer, bytes);
        }
        delay(50);

    } while (repeat);

    udpClose(socket);

//tftf    TRACE("UdpEchoTask Exiting\n");
}

The pc send to the port(2010).
ARP is working.
But ucip will not send back....

Are there known errors... ?

Regards

Tobias

----------------------------------------
Jetter AG
Tobias Föll
Phone:  +49 7141 2550 446
Fax:    +49 7141 2550 556
mailto:tf...@je...
web: http://www.jetter.de

[Ucip-devel] UCIP with Ethernet Interface AM 79C973 PCI

[<tf...@je...>]

Hi developers,

I think i find something suspicious.

> void ethInit(Interface* pInterface)
> {
>     pDefaultInterface = pInterface;
>     pInterface->pSemIF = OSSemCreate(0x0034);
>     OSTaskCreate(EthTask, pInterface, NULL, 12);
> .....

 Why is the tird parameter NULL ?
 If i use ucos-ii, then this task has no stack ????


Regards

Tobias


----------------------------------------
Jetter AG
Tobias Föll
Phone:  +49 7141 2550 446
Fax:    +49 7141 2550 556
mailto:tf...@je...
web: http://www.jetter.de

[Ucip-devel] Welcome developer Silvio Rizzi

[Guy L. <lan...@ac...>]

  Silvio Rizzi (cabecha) has just joined the ranks as a
developer on the uC/IP project.  He's in Mendoza,
Argentina and is working on adapting uC/IP for 8 bit
micros.  Welcome aboard Silvio.

            Guy

[Ucip-devel] lightweight TCP/IP stack for 8-bit devices

[Enrico M. <enr...@fa...>]

Hi Guy,

 there are really no limits to imagination...

 I won't ever commit to production a TCP/IP stack
 that requires 28 bytes of RAM as stated in the article:

 "...TCP/IP stack occupies 2,100
 bytes of ROM with an additional 28 bytes of RAM 
 required..."

 A stack like that can be used as an academic tool...

 Enrico


  
>   Here's an interesting article on what's coming in
> TCP/IP support for smaller microcontrollers.
> 
> http://www.edtn.com/story/OEG20011031S0056
> 
>   So what thoughts do we have on getting a version of
> uC/IP working on 8 bit micros?  Already Jean Fernandes
> has started work on a version for 8051 class processors
> (I've invited him to join this list).  Can a single
> code base support the range from this up to powerful
> multiprocessor systems like Craig Graham works with or
> should there be some level of separation?
> 
>   I suspect that at least some modules would/should be
> split into heavy and light versions although it would
> be nice to have common APIs.  Other modules could be
> adapted using compile time switches.
> 
>   Your thoughts?
> 
>           Guy

[Ucip-devel] uC/IP on 8 bit micros

[Guy L. <lan...@ac...>]

  Here's an interesting article on what's coming in
TCP/IP support for smaller microcontrollers.

http://www.edtn.com/story/OEG20011031S0056

  So what thoughts do we have on getting a version of
uC/IP working on 8 bit micros?  Already Jean Fernandes
has started work on a version for 8051 class processors
(I've invited him to join this list).  Can a single
code base support the range from this up to powerful
multiprocessor systems like Craig Graham works with or
should there be some level of separation?

  I suspect that at least some modules would/should be
split into heavy and light versions although it would
be nice to have common APIs.  Other modules could be
adapted using compile time switches.

  Your thoughts?

          Guy

[Ucip-devel] Re: uC/IP Project...

[Robert D. <od...@pn...>]

G'day Tobias,

<please see reply inline>

At 05:07 PM 15/10/2001 +0200, you wrote:
>
>
>Dear Mr. Robert Dickenson,
>
>i search for an embedded system TCP/IP stack with an HTTP Server, SMTP
>(e-mail) and a file system.

uCIP provides the TCP/IP stack. Anybody who would like to write or port=20
such things as HTTP server, SMTP services etc would be most welcome on=20
the project. Do a search on sourceforge and google for these (include=20
ANSI C in your search to narrow it down).

>The hardware i made used an AMD AM 79C973 ethernet MAC, on the PCI bus.
>

Looks like this is a fast ethernet chipset, cool.


>I found the source from you on:
>http://sourceforge.net/projects/ucip/
>

Just last night I imported an archive containing a snapshot the latest=20
source tree in CVS.

https://sourceforge.net/project/showfiles.php?group_id=3D12500&release_id=3D=
57123


>My question now:
>
>- 1) Can i use your software for the TCP/IP level ?

Yes, this is exactly what the project provides.

>- 2) How much i have to pay for this software ?

Nothing, it is free.


>- 3) What is with the license ?

BSD license, which says it is free for everybody to do what they wish with.


>- 4) Is it easy to implement another ethernet MAC, in my case an AMD=
 79C973?
>

Relatively, you'll want to get the AMD 79C973 spec, look at the existing=20
NE2000 driver provided by Mads. Look at the BSD and Linux sources, they=
 should
both have a driver for this chip. Copy as much of the BSD one as possible.=
 Use
the Linux one for reference.


>- 5) I buyed the source of the ucos-ii. Your stack use this small operating
>system, or ?
>

I originally did all my work on the stack with UCOS as the target OS.=
 However
the current goal of the stack is to be OS independant. UCOS-II is ideal.


>- 6) What is CVS ? Something like PVCS or Visual Source Save (VSS) ?

Yes, only heaps better.


>- 7) What is the stand of the project ? Can i help ?
>

All help is most welcome. Join the sourceforge project and subscribe to the=
=20
developer lists on sourceforge.

https://sourceforge.net/mail/?group_id=3D12500


>Your answer will be much appreciated.
>
>Regards
>
>Tobias F=F6ll
>

Always welcome. Let us know if you have any further questions.

Best wishes,

Robert Dickenson.

[Ucip-devel] API documentation: little delay

[enrico <enr...@fa...>]

hi guys,

 due to the fact that I got involved in a big project until the 15th of
November, the job of documenting the
 source code may suffer a little delay. I'm sorry about that. After that date,
I'll be documenting at the
 usual rate of 2 source files a week.


 Enrico

[Ucip-devel] API documentation: new file added

[enrico <enr...@li...>]

hi all

 I added another file to the documentation. I hope next week to speed up
 the job a little.

 bye
 Enrico

[Ucip-devel] Sv: [ucos-net] uC/IP NE2K Ethernet

[MOGI.dk <chr...@mo...>]

Hi Craig!

I'm already using the Ne2000 driver. But due to our embedded software =
design I couldn't support the NBuf in the driver design. But it's really =
great that you are updating my source!

Robert Dickinson has been making a lot of changes to the CVS source. =
I've made some changes to let UDP support broadcast etc. but I don't =
know if Robert has posted these changes yet.

Best wishes,
Mads.

----- Original Message -----=20
From: Craig Graham <cg...@ac...>
To: <uco...@ya...>
Sent: Sunday, September 23, 2001 12:04 AM
Subject: [ucos-net] uC/IP NE2K Ethernet


> Just to let folks (esp. Mads & Guy) know, I'm about to start using the =
uC/IP=20
> ethernet support with a Davicom DM9008 (ne2k compatible) chip coupled =
to twin=20
> R3000 processors. I've made a few changes to make the ne2k driver =
relative to=20
> the current CVS version (support for NBuf's in the Rx/Tx, proper =
"Interface"=20
> support, etc). I'll mail the mod's to Mads & Guy when it's stable....
>=20
> Of course, if anyone already has this working, I'll happily accept =
some tips=20
> at this point - but then, if you're using uC/IP with an ne2k already, =
why=20
> aren't the mods already in the CVS version you bad people ;)
>=20
> Laters,
> Craig.
> (the geezer who wrote the dodgy uC/IP UDP code)
>=20
> ------------------------ Yahoo! Groups Sponsor =
---------------------~-->
> Get your FREE VeriSign guide to security solutions for your web site: =
encrypting transactions, securing intranets, and more!
> http://us.click.yahoo.com/XrFcOC/m5_CAA/yigFAA/NhFolB/TM
> =
---------------------------------------------------------------------~->
>=20
> =20
>=20
> Your use of Yahoo! Groups is subject to =
http://docs.yahoo.com/info/terms/=20
>=20
>=20

[Ucip-devel] Re: Bugs in UDP (to Robert)

[Robert D. <od...@pn...>]

G'day Mads,

<comments inline>

At 11:58 AM 10/09/2001 +0200, you wrote:
>Hi again Robert!
>
>I haven't had the time to (re)setup my cvs settings and I am still using
an old version of uC/IP
>(you have made several changes to the stack and we are not yet ready to
implement these). 
>
>If you have the time I and can email you the changes (but you will
probably have to do a diff).
>
>Will this be OK ?
>

Yes, please do. I look forward to seeing and trying all the improvements
you have made.


>   I have fixed the checksum problems in UDP and done some other changes
to udpWrite in particular (I prefer using the nBuf functions when possible
instead of manipulating directly with the nBufs).
>
>   I have found a bug in nAppend (when appending data to a non-empty
nBuf), this must be applied or the udpWrite changes won't work!
>
>   I have made changes to the ARP implementation so it can do an IP/UDP
broadcast on the Ethernet.
>
>   I have made changes to the IP implementation so it will accept and
IP/UDP broadcast from the Ethernet.
>

Sounds really good. I was just working on the UCIP build process under
Linux the other day which I have just recently committed.

Please send an archive of your source and i'll integrate all the changes
into the CVS repository asap.

[Ucip-devel] Bugs in UDP (to Robert)

[Mads C. <MC...@vo...>]

Hi again Robert!

I haven't had the time to (re)setup my cvs settings and I am still using =
an old version of uC/IP
(you have made several changes to the stack and we are not yet ready to =
implement these).=20

If you have the time I and can email you the changes (but you will =
probably have to do a diff).

Will this be OK ?

   I have fixed the checksum problems in UDP and done some other changes =
to udpWrite in particular (I prefer using the nBuf functions when possible =
instead of manipulating directly with the nBufs).

   I have found a bug in nAppend (when appending data to a non-empty =
nBuf), this must be applied or the udpWrite changes won't work!

   I have made changes to the ARP implementation so it can do an IP/UDP =
broadcast on the Ethernet.

   I have made changes to the IP implementation so it will accept and =
IP/UDP broadcast from the Ethernet.

Best wishes,

Mads.

[Ucip-devel] API documentation: two new files added

[enrico <enr...@li...>]

hi all,

 I just posted to:

 http://groups.yahoo.com/group/ucos-net/

the latest release of the of the ucip HTML documentation.

Enrico

Re: [Ucip-devel] API documentation: first portion of the job

[Guy L. <gu...@gu...>]

enrico wrote:

>  attached is a tiny portion of the job of documenting the APIs.

  Looking good.

> ... I could e-mail a sketch of Labrosse's diagrams to whom may be interested.

  I'm interested.  And please let me know specifically what you'd like illustrated
and I'll see what I can do.

          Guy

[Ucip-devel] API documentation: first portion of the job

[enrico <enr...@li...>]

hi guys,

 attached is a tiny portion of the job of documenting the APIs.
 Along with this kind of APIs reference documentation I do think that a wannabe
user would need
 some graphics to better understand how to use the various funcions. I like the
diagrams
 adopted by Jean Labrosse in his book  "Embedded Systems Building Blocks": they
explain
 quite easily, in a graphics manner, the internal structure of a device driver
of an embedded system.
 I could e-mail a sketch of Labrosse's diagrams to whom may be interested.

Enrico

Re: [Ucip-devel] Bugs in UDP

[Robert D. <od...@pn...>]

G'day Mads,

<comments inline>

At 02:54 PM 31/08/2001 +0200, you wrote:
>Hi Robert!
>
>I can see that you have been removing the malloc dependencies in the UDP
module - GREAT!
>
Yes, don't like having to require a malloc on tiny embedded systems.


>But there seems to be a few bugs... well I have located a couple (checksum) 
>and will also be adding callback functionality to this module.
>
Not surprised, I didn't follow that up with much (any?) testing at the
time. I too had
issues with the checksum which I didn't resolve. Got rather confused at the
time.


>Have you done any new work on this module that has not been posted yet ?
>Else I might be posting some changes within the next week...
>
I don't believe so. I did some work just last night on the build processes.
I am no able
to build a UCIP static library on both Linux and Win32. Echotest still
builds and runs
(ping at least) under Win32.

I'll do some diff'ing now and commit changes ASAP. I don't expect we'll
have any clashes.

Regards, Robert.

[Ucip-devel] Bugs in UDP

[Mads C. <MC...@vo...>]

Hi Robert!

I can see that you have been removing the malloc dependencies in the UDP =
module - GREAT!

But there seems to be a few bugs... well I have located a couple (checksum)=
 and will also be adding callback functionality
to this module.

Have you done any new work on this module that has not been posted yet ?
Else I might be posting some changes within the next week...

Best wishes,
Mads.

[Ucip-devel] API documentation: back on track

[enrico <enr...@li...>]

hi all,

 here I'am back home. I saw that Doxygen has been updated: tomorrow I'll
download
 the latest release and see what has been changed.
 As requested, no IDs will be assigned to functions.

 Enrico

Re: [Ucip-devel] API documentation: functions ID

[Robert D. <od...@pn...>]

Hi Dimitri,

Hope you had a good summer holiday, it's the middle of winter
and blowing a gale here!

I received another advise about doxygen updates,

------------------------------------------------------------------------
I have just released version 1.2.10 of doxygen.

Sources and binaries for Linux and Windows are available from
http://www.doxygen.org/download.html

For a detailed list of what has changed since the last release look at:
http://www.doxygen.org/changelog.html

Enjoy, Dimitri
------------------------------------------------------------------------

Regards, Robert.



At 09:37 AM 10/08/2001 +0200, you wrote:
>Hi all,
> 
> I noticed that some tool chains, Mitsubihi for example,
> assign a unique ID number to each C function. Why is that?
> Do we need to assign an ID to each function of ucip project?
>
> I'll be taking two weeks off (summer's holidays) starting
> from the 10th to the 25th of August. I might not be able
> to get on the web during these two weeks. The job of documenting
> the project is going on; I'll be posting the job done as soon
> as I get back.
>
>
> bye for now
> Enrico
>
>_______________________________________________
>Ucip-devel mailing list
>Uci...@li...
>http://lists.sourceforge.net/lists/listinfo/ucip-devel
>
>

Re: [Ucip-devel] API documentation: functions ID

[Guy L. <gu...@gu...>]

Enrico Migliore wrote:

>  I noticed that some tool chains, Mitsubihi for example,
>  assign a unique ID number to each C function. Why is that?
>  Do we need to assign an ID to each function of ucip project?

  Are the function names possibly not unique?  Just a guess but this
would make sense in a C++ environment where function names are
commonly overloaded.  Again just guessing but I doubt that unique
ID's would help us.

>
>  I'll be taking two weeks off (summer's holidays) starting
>  from the 10th to the 25th of August. I might not be able
>  to get on the web during these two weeks. The job of documenting
>  the project is going on; I'll be posting the job done as soon
>  as I get back.

  Have a nice holiday and thanks for all your work.

           Guy

--
Guy Lancaster, Vancouver, BC, Canada
mailto:gu...@gu...
http://guylancaster.com
phone: 604.264.8627