Just to make things a little more complicated. We also offer a
TCP/IP stack with integrated operating system, a simulator and
project support for GNU and IAR Embedded work bench. It is available
freely to educational establishments and also supported by Email.
Since it is also used for commercial projects, it is presently
restricted to the above mentioned distribution. It is also only
available for Freescale MC9S12NE64 and ATMEL AT91SAM7X projects (as
soon as the new LPC is available it will also get a project)
The operating system and stack include the standard things plus FTP
with FLASH or serial SPI EEPROM file system, Telnet, dynamic HTTP
and fits (when all activated) into about 15k..20k of FLASH and need
about 3k of RAM (depending on the resource defined).
There are a few demos on line at www.mjbc.ch (login always using
user name "anon" and password "anon"). These use the NE64 as
basis
since the ATMEL is still only avilable in limited quantities and so
there are not enough here for permanent demos. The NE64 devices have
limited resources and so do not use transmission windowing.
Apart from the published demos there is also a development device in
a DMZ at 212.254.22.36 which can be (anonymous) FTP'ed to (not PAS
mode) if anyone wants to see it working. On the FTP server are the
individual web page files which can be updated, copied and deleted
(but please don't change anything...). Since the FTP here is
designed for maintenance (web page mods etc.) it supports only a
single connection at a time whereas the web server
(http://212.254.22.36:8084 will do loads in parallel). In fact this
device also supportes software uploads and also debugging via the
internet and is being used for real development whenever there is an
Internet connection available - saves having to carry the hardware
around if on the move...). It can also be Telnet'ed to, but both web
server and Telnet are password protected; I wonder whether someone
can still get in...?
The advantage of this solution (although it presently doesn't have a
wide platform support) is that it includes a simulator which means
that real network traffic can be recorded using Ethereal and played
back through the code. It makes for much improved development and
debug support since it is possible to debug occurances at remote
locations as long as there was an Ethereal recording of the events
which can be supplied - playing back through the code using the
simulator allows all details to be analysed and code improvements
and corrections even to be verified. It is also very helpful when
learning the protocols and code since the frames can be easily
displayed in the debugger and each step analysed - very useful for
educational establishments...
Sorry, my bad, the last one loads fast, the other 3 are pretty slow.
-- Sean
At 04:58 PM 1/16/2006, you wrote: > > Just a "me too", they all work fine
for me (WinXP IE6) but they are
> > sloooowwww...
> >
>
>Even this one?
><http://82.32.114.142:47822/cgi/rtos" target="_blank" rel="nofollow">http://82.32.114.142:47822/cgi/rtos>http://82.32.114.142:47822/cgi/rtos
>
>My contribution to this thread started by saying that uIP could be sped
up
>by sending dynamic data as single buffer rather than lots of small ones -
>using this link as an example compared to the other links. The standard
uIP
>demo from Adam Dunkels site sends each dynamically generated item
>separately - hence lots of delayed acks and a slow connection to Windoze.
>
> From here I find this page loads quickly, but I'm not 30hops away.
>
>Regards,
>Richard.
>
><http://www.FreeRTOS.org" target="_blank" rel="nofollow">http://www.FreeRTOS.org>http://www.FreeRTOS.org
Reply by Marko Pavlin home●January 16, 20062006-01-16
OK, just another "metoo".
lynx 82.32.114.142:47821 works just fine:
Task State Priority Stack #
************************************************
uIP R 3 64 0
PolSEM1 R 0 84 8
PolSEM2 R 0 84 9
IDLE R 0 99 13
SUSP_RX R 0 88 7
C_CTRL R 0 90 5
CNT_INC R 0 91 3
QConsNB B 2 99 1
QProdNB B 2 92 2
BlkSEM1 B 1 84 10
BlkSEM2 B 1 84 11
Check B 4 100 12
SUSP_TX B 0 94 6
LIM_INC S 1 95 4
it shows two frames.
But traceroute gets lost somewhere... over 30 hops (from Slovenia)...
-bash-2.05b$ traceroute -p47821 82.32.114.142 0x40
traceroute to 82.32.114.142 (82.32.114.142), 64 hops max, 64 byte packets
1 BSN-access.dsl.siol.net (213.250.19.90) 38.685 ms 24.747 ms 13.518 ms
2 213.250.19.169 (213.250.19.169) 13.265 ms 12.290 ms 13.234 ms
3 213.250.18.97 (213.250.18.97) 14.052 ms * *
4 kklag1-176-57.net.uta.at (212.152.176.57) 52.157 ms 21.890 ms
47.014 ms
5 C76wmode1-tengigE-4-2.net.uta.at (212.152.192.174) 22.154 ms
36.087 ms 58.871 ms
6 vie3-core.gigabiteth1-0.swip.net (130.244.205.57) 23.852 ms 45.033
ms 24.089 ms
7 fra2-core.pos12-0.swip.net (130.244.193.154) 68.209 ms 73.552 ms
69.963 ms
8 weis-core-1.pos0-0.swip.net (130.244.194.181) 145.105 ms 109.349
ms 92.789 ms
9 some.frankfurt.router.Level3.net (130.244.200.86) 39.166 ms 67.372
ms 60.312 ms
10 ae-0-53.bbr1.Frankfurt1.Level3.net (195.122.136.65) 38.923 ms
70.912 ms ae-0-55.bbr1.Frankfurt1.Level3.net (195.122.136.97) 57.105 ms
11 as-0-0.bbr1.London1.Level3.net (4.68.128.109) 120.925 ms 93.313
ms 75.871 ms
12 ae-0-17.gar1.London1.Level3.net (212.187.131.169) 54.945 ms
ae-0-15.gar1.London1.Level3.net (212.187.131.137) 56.411 ms
ae-0-17.gar1.London1.Level3.net (212.187.131.169) 91.576 ms
13 195.50.91.2 (195.50.91.2) 55.339 ms 195.50.91.6 (195.50.91.6)
55.799 ms 70.178 ms
14 azt-tele1-pos.telewest.net (194.117.136.1) 103.056 ms 73.372 ms
66.472 ms
15 195.188.230.5 (195.188.230.5) 59.610 ms 138.936 ms 223.461 ms
16 195.188.230.58 (195.188.230.58) 86.663 ms 105.322 ms 65.731 ms
17 195.188.230.188 (195.188.230.188) 59.584 ms 93.585 ms 97.788 ms
18 * * *
Sorry for garbage :)
FreeRTOS Info wrote:
> > IE loads them fine on my machine. On the ones
in question, in IE
> there is
> a
> > delayed load between the header and body.
> >
> > It's a curious difference between Firefox and IE.
> >
> > A tracert of 82.32.114.142 results in over 30 network hops. This
> may have
> a
> > bearing on things. Are you in the UK? I'm in California.
> Yep - UK - just a few thousand miles away.
>
> Richard.
>
> http://www.FreeRTOS.org
>
My contribution to this thread started by saying that uIP could be sped up
by sending dynamic data as single buffer rather than lots of small ones -
using this link as an example compared to the other links. The standard uIP
demo from Adam Dunkels site sends each dynamically generated item
separately - hence lots of delayed acks and a slow connection to Windoze.
From here I find this page loads quickly, but I'm not 30hops away.
> IE loads them fine on my machine. On the ones in question, in IE there
is
a > delayed load between the header and body.
>
> It's a curious difference between Firefox and IE.
>
> A tracert of 82.32.114.142 results in over 30 network hops. This may
have a > bearing on things. Are you in the UK? I'm in
California.
IE loads them fine on my machine. On the ones in question, in IE there is
a
delayed load between the header and body.
It's a curious difference between Firefox and IE.
A tracert of 82.32.114.142 results in over 30 network hops. This may have a
bearing on things. Are you in the UK? I'm in California.
Joel
> > > Here too.
> > > Win XP Pro.
> > > Firefox 1.5
> > >
> > > http://82.32.114.142:47821/
> > > http://82.32.114.142:47820/
> > > http://82.32.114.142:47822/cgi/tcp
> > > http://82.32.114.142:47822/cgi/rtos
> > >
> > > all of them works fine.
> >
> >
> > Hmm. First round the second listed was giving me "The document
> contains
> > no data." After multiple tries through the list then the second
worked
> and
> > the first start complaining. Are all of these running uIP I wonder?
> >
> > XP
> > Firefox 1.0.7
> The 47820 port is using a WizNET I2C interface.
>
> The 47821 is Pauls uIP demo bit banging a Crystal LAN running as a task
> under FreeRTOS (LPC).
>
> The 47822 is uIP running with interrupts and DMA on a SAM7X.
>
> The number of simultaneous connections is limited (#define in the code).
> If
> you look at a page that sends lots of small packets then each takes a
> connection. I imagine that posting the addresses here is generating
> several
> simulations hits, so maybe its just running out of connections hence the
> intermittence.
>
> All works fine for me, but the boards are only a few feet away. Also
I'm
> using IE rather than Firefox.
The 47821 is Pauls uIP demo bit banging a Crystal LAN running as a task
under FreeRTOS (LPC).
The 47822 is uIP running with interrupts and DMA on a SAM7X.
The number of simultaneous connections is limited (#define in the code). If
you look at a page that sends lots of small packets then each takes a
connection. I imagine that posting the addresses here is generating several
simulations hits, so maybe its just running out of connections hence the
intermittence.
All works fine for me, but the boards are only a few feet away. Also I'm
using IE rather than Firefox.
Hmm. First round the second listed was giving me "The document contains
no data." After multiple tries through the list then the second worked
and
the first start complaining. Are all of these running uIP I wonder?
