Willi, As pointed out by others, the optimizer from GCC will optimize a lot to 32bit operations. I'm using the latest GCC compiler from GNUARM.org for the LPC ARM series and I've seen it doing some nifty optimisations.
At this moment I'm running uIP on a Windows PC as a test environment. The ping time depends on time interval between calling the uIP run loop. I have a 10ms delay between calls and I see an average delay of about 10ms between pin responses. Nico Coesel -----Oorspronkelijk bericht----- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Willi Schulte Verzonden: dinsdag 6 maart 2007 10:02 Aan: uip-users@sics.se Onderwerp: 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
