design advice

Hi,

Until now I only used microchip controler for project like IO device serial
control,
RF transmitter decoder software with sampling and CRC correction.
Paging decoder for POCSAG and FLEX, modem control software and other small
projects.

At this moment I'm designing a new "universal" controler board with the next
IO / options.

microchip 18F6525 controler TQFP64 housing
dual spi flash device 4 atmel Mbit
dual serial rs232 port or rs485 port or combination
5 serial shift registers 74hc597 for 40 digital IO input
serial shift registers 74hc595 with uln 2803 for digital IO output
clock chip DS1307
switching regulator
etc.

sub-board with rtl8019 controler for ethernet option
sub-board with LCD display, key input, rotory encoder and USB chip FT232BM
sub-board with modem for telecom aplications

some combinations are posible display board with or modem or ethernet.

For now the microchip has done the job for me, but i now need TCP/IP control
for my
next project. resonably simple tcp/ip and web project with low speed data
connection (< 100kBit).


I have been following the arm philips LCP new group as an interesting
controler.

Could some one advice me why I sould or shouldend use the microchip
controler
and should switch to an other device for some reason.

Any advice is welcome and appresiated  ( I now can still change controler
for my new PCB design),
also if I start (you advice) with new controler where to find newsgroup or
tools to do debugging, compiling etc.



Regards,


Gerrit Faas

> For now the microchip has done the job for me, but i now need TCP/IP control
> for my
> next project. resonably simple tcp/ip and web project with low speed data
> connection (< 100kBit).
> 
> 
> I have been following the arm philips LCP new group as an interesting
> controler.
> 
> Could some one advice me why I sould or shouldend use the microchip
> controler
> and should switch to an other device for some reason.
> 
> Any advice is welcome and appresiated  ( I now can still change controler
> for my new PCB design),
> also if I start (you advice) with new controler where to find newsgroup or
> tools to do debugging, compiling etc.

TCP/IP implementation is RAM hungry.
PICs don't have enough RAM, so if you want to implement TCP/IP without
limitations you will need uC with more RAM (internal or external)

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, and MSP430 
(http://www.olimex.com/dev)

Take a look at the ZiLog Z80...
Zilog provides already software for TCP/IP and a webserver on the Z80.

I'm working with the smaller eZ8, which has already 2 UARTS (with an IrDA),
single SPI, and a lot of other nice stuff. Including On-Chip Debugging...

- Joris

"Tsvetan Usunov" <tusunov@my-deja.com> wrote in message
news:dd52331e.0407180207.776327c9@posting.google.com...
> > For now the microchip has done the job for me, but i now need TCP/IP
control
> > for my
> > next project. resonably simple tcp/ip and web project with low speed
data
> > connection (< 100kBit).
> >
> >
> > I have been following the arm philips LCP new group as an interesting
> > controler.
> >
> > Could some one advice me why I sould or shouldend use the microchip
> > controler
> > and should switch to an other device for some reason.
> >
> > Any advice is welcome and appresiated  ( I now can still change
controler
> > for my new PCB design),
> > also if I start (you advice) with new controler where to find newsgroup
or
> > tools to do debugging, compiling etc.
>
> TCP/IP implementation is RAM hungry.
> PICs don't have enough RAM, so if you want to implement TCP/IP without
> limitations you will need uC with more RAM (internal or external)
>
> Best regards
> Tsvetan
> ---
> PCB prototypes for $26 at http://run.to/pcb
> (http://www.olimex.com/pcb)
> PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
> Development boards for ARM, AVR, PIC, and MSP430
> (http://www.olimex.com/dev)

>Take a look at the ZiLog Z80...
>Zilog provides already software for TCP/IP and a webserver on the Z80.
>

I think yo mean eZ80, not Z80. eZ80 is a 24-bit MCU, while the Z80 is an old
8-bit MCU (which is still used).

"Gary Kato" <garykato@aol.com> wrote in message
news:20040718172617.22984.00001929@mb-m07.aol.com...
> >Take a look at the ZiLog Z80...
> >Zilog provides already software for TCP/IP and a webserver on the Z80.
> >
>
> I think yo mean eZ80, not Z80. eZ80 is a 24-bit MCU, while the Z80 is an
old
> 8-bit MCU (which is still used).
>

Forgot the 'e' indeed ...

All,

 thanks for the advice I will go into the diferent controlers and loop what
would be most applyable.

If there are stille pro and contra's for microchip vs arm please share.


Kind regards,

Gerrit



"Gerrit" <gerrit@waterackers.nl> schreef in bericht
news:10fif4vjnpo0k23@corp.supernews.com...
> Hi,
>
> Until now I only used microchip controler for project like IO device
serial
> control,
> RF transmitter decoder software with sampling and CRC correction.
> Paging decoder for POCSAG and FLEX, modem control software and other small
> projects.
>
> At this moment I'm designing a new "universal" controler board with the
next
> IO / options.
>
> microchip 18F6525 controler TQFP64 housing
> dual spi flash device 4 atmel Mbit
> dual serial rs232 port or rs485 port or combination
> 5 serial shift registers 74hc597 for 40 digital IO input
> serial shift registers 74hc595 with uln 2803 for digital IO output
> clock chip DS1307
> switching regulator
> etc.
>
> sub-board with rtl8019 controler for ethernet option
> sub-board with LCD display, key input, rotory encoder and USB chip FT232BM
> sub-board with modem for telecom aplications
>
> some combinations are posible display board with or modem or ethernet.
>
> For now the microchip has done the job for me, but i now need TCP/IP
control
> for my
> next project. resonably simple tcp/ip and web project with low speed data
> connection (< 100kBit).
>
>
> I have been following the arm philips LCP new group as an interesting
> controler.
>
> Could some one advice me why I sould or shouldend use the microchip
> controler
> and should switch to an other device for some reason.
>
> Any advice is welcome and appresiated  ( I now can still change controler
> for my new PCB design),
> also if I start (you advice) with new controler where to find newsgroup or
> tools to do debugging, compiling etc.
>
>
>
> Regards,
>
>
> Gerrit Faas
>
>

Gerrit wrote:
> All,
> 
>  thanks for the advice I will go into the diferent controlers and loop what
> would be most applyable.
> 
> If there are stille pro and contra's for microchip vs arm please share.
> 
> 

ARM is a 32 bit device, while the other suggested processors have
narrower word width. The TCP/IP arithmetic is also 32 bits, so
there is a native advantage with an ARM. Also, a 32 bit processor
can more easily handle memories over 65 kbytes, which pretty
soon prove necessary with the TCP/IP applications.

Been there - done that (TCP/IP on AT91's).

Tauno Voipio
tauno voipio (at) iki fi

When working with TCP/IP on a device with only few memory, you should be
aware of the send and receive windows used and the optimizations to reduce
network traffic (delayed ACKs).

I've seen an implementation with TCP/IP that had little memory available and
here the window was the limiting factor for communication with a (Windows)
PC.
Basically, the sent window of the device was much smaller than the send
window, so the data send a head was little (only 8 or 16KB, while the PC has
a window of at least 64KB). There is an optimization (turned on by default
in Windows) that only sends ACKs at predefined time intervals (or when the
receive window reaches its capacity). The effect was that the window was
partially filled (embedded device was out of memory) and needed to wait a
long time for the ACKs from the PC (which are sent every 200ms).
So it ran over 100Mbps and, due to memory limitations, only reached 800
kbps! It worked, but ensure you have enough memory...
Of course turning off the optimization on the PC so ACKs are send
immediately helped a bit, speeding it up an order of a magnitude!

Hope this illustrates the memory demands TCP makes to actually get decent
performance...

- Joris


Windows 2000 TCP/IP Configuration Setting affected:
TcpDelAckTicks

Key: Tcpip\Parameters\Interfaces\interface

Value Type: REG_DWORD-number

Valid Range: 0-6

Default: 2 (200 milliseconds)

Description: Specifies the number of 100-millisecond intervals to use for
the delayed-ACK timer on a per-interface basis. By default, the delayed-ACK
timer is 200 milliseconds. Setting this value to 0 disables delayed
acknowledgments, which causes the computer to immediately ACK every packet
it receives. Microsoft does not recommend changing this value from the
default without careful study of the environment.



"Tauno Voipio" <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message
news:PpfMc.379$yH4.352@read3.inet.fi...
> Gerrit wrote:
> > All,
> >
> >  thanks for the advice I will go into the diferent controlers and loop
what
> > would be most applyable.
> >
> > If there are stille pro and contra's for microchip vs arm please share.
> >
> >
>
> ARM is a 32 bit device, while the other suggested processors have
> narrower word width. The TCP/IP arithmetic is also 32 bits, so
> there is a native advantage with an ARM. Also, a 32 bit processor
> can more easily handle memories over 65 kbytes, which pretty
> soon prove necessary with the TCP/IP applications.
>
> Been there - done that (TCP/IP on AT91's).
>
> Tauno Voipio
> tauno voipio (at) iki fi
>

"Joris Dobbelsteen" <none.of@your.business> wrote in message news:<41027803$0$147$18b6e80@news.wanadoo.nl>...
> When working with TCP/IP on a device with only few memory, you should be
> aware of the send and receive windows used and the optimizations to reduce
> network traffic (delayed ACKs).
> 
> I've seen an implementation with TCP/IP that had little memory available and
> here the window was the limiting factor for communication with a (Windows)
> PC.
> Basically, the sent window of the device was much smaller than the send
> window, so the data send a head was little (only 8 or 16KB, while the PC has
> a window of at least 64KB). There is an optimization (turned on by default
> in Windows) that only sends ACKs at predefined time intervals (or when the
> receive window reaches its capacity). The effect was that the window was
> partially filled (embedded device was out of memory) and needed to wait a
> long time for the ACKs from the PC (which are sent every 200ms).
> So it ran over 100Mbps and, due to memory limitations, only reached 800
> kbps! It worked, but ensure you have enough memory...
> Of course turning off the optimization on the PC so ACKs are send
> immediately helped a bit, speeding it up an order of a magnitude!
> 
> Hope this illustrates the memory demands TCP makes to actually get decent
> performance...
> 
> - Joris
> 

Interesting observation. I wonder if sending little packets much smaller
than Ethernet can handle, say 200 octet packets will trigger the 
ACKing mechanism on the receiving side. After all, doesn't telnet
ack every single character?

Will

"Will" <wv9557@yahoo.com> wrote in message
news:4a885870.0407241853.522338cf@posting.google.com...
> "Joris Dobbelsteen" <none.of@your.business> wrote in message
news:<41027803$0$147$18b6e80@news.wanadoo.nl>...
> > When working with TCP/IP on a device with only few memory, you should be
> > aware of the send and receive windows used and the optimizations to
reduce
> > network traffic (delayed ACKs).
> >
> > I've seen an implementation with TCP/IP that had little memory available
and
> > here the window was the limiting factor for communication with a
(Windows)
> > PC.
> > Basically, the sent window of the device was much smaller than the send
> > window, so the data send a head was little (only 8 or 16KB, while the PC
has
> > a window of at least 64KB). There is an optimization (turned on by
default
> > in Windows) that only sends ACKs at predefined time intervals (or when
the
> > receive window reaches its capacity). The effect was that the window was
> > partially filled (embedded device was out of memory) and needed to wait
a
> > long time for the ACKs from the PC (which are sent every 200ms).
> > So it ran over 100Mbps and, due to memory limitations, only reached 800
> > kbps! It worked, but ensure you have enough memory...
> > Of course turning off the optimization on the PC so ACKs are send
> > immediately helped a bit, speeding it up an order of a magnitude!
> >
> > Hope this illustrates the memory demands TCP makes to actually get
decent
> > performance...
> >
> > - Joris
> >
>
> Interesting observation. I wonder if sending little packets much smaller
> than Ethernet can handle, say 200 octet packets will trigger the
> ACKing mechanism on the receiving side. After all, doesn't telnet
> ack every single character?
>
> Will

There is usually an echo with a piggy-back ACK. A single keystroke
generates (if the line mode is off) three segments: the initial character,
the echo with ACK, and the ACk of the echo.

For bulk transfer with small segments, such as Web pages, there can
be a delay before a segment is ACKed, to provide the browser end
the opportunity to piggy-back some data with the ACK. If the sending
end waits for the ACK, this will slow the transfer noticeably. OTOH,
sending without waiting for the ACK makes it necessary to store all
un-ACKed data at the sending end.

Tauno Voipio
tauno voipio (at) iki fi