The ping time to my uip system is less than 1 ms. It depends largely on the driving of the uip stack (the "main loop").
/Daniel -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Willi Schulte Sent: den 6 mars 2007 10:02 To: uip-users@sics.se Subject: Re: [uip-users] Byte ordering problem with ARM7 Thank you Alexandre and Patrick, I think you are right that I have alignment problems with uIP Code and the ARM/LPC-architecture. How holy is the code of uIP? I first planned to change nothing inside to have compatibility to later versions ... My feeling is that the ARM7 does not fits really good to uIP because it can not use the 32-bit-power. lwIP should be better but the LPC2132 has not enough SRAM inside. By the way: PING Answering needs 62 ms. That's a lot. It depends on the uIP concept, doesn't it? Regards, Willi > As Patrick pointed out, it's more like an alignment problem, on arm > that's a heavy issue. On arm7, an unaligned access doesn't generate a > trap, instead, it's accepted on a very specific arm way that internally > rotates the bits not in the way one would expect. The compiler assumes > you know what you're doing, and will not try to cope with unaligned > accesses unless the data type (or the attributes, such as packed) > implies that. > I did a fresh port of uip 1.0 to philips lpc series of arm7-based µcs, > all I had to do was to put attribute aligned on the uip buffer (uip_buf > variable if I recall it correctly), but that's because I based my port > on a ppp driver, therefore I had no arp around. With arp, the driver > fills the first 14 bytes with the arp header and the whole thing > misaligns. A possible solution would be to change UIP_BUF (IIRC) macro > to point to index 2 instead of 0 of the matrix, and make sure the > ethernet driver code has that gap. That would wast 2 bytes of the > buffer, but would relieve from the need to sparsely put packed attribute > tags around. > There's a long term debate with some people defending that many of the > theoretical benefits of an architecture requiring aligned access ends up > being purely fictional on the real world due to the complexity it > introduces on higher level code, but for now we have to cope with that. > Just in time: another change I had to do was on the dns resolver code. > If you plan to do that, it also has misalignments. I can read the code > and try to remember where, if that's relevant to you or somebody else... > - Alexandre
