>pbreed@netburner.com writes:
>> A part with similar capabilites is availbile Today from FreeScale.
>> 32 Bits, 64K Ram, 512K flash 10/100 Mac, CAN,I2C, 3 Uarts, SPI 8 Timers,
>> 80Mhz etc.. etc...
>
>How does an 80 MHz Coldfire perform compared to an 80 MHz ARM7?
I would expect the performance to be almost identical.
Both are single cycle flash access, both a risk like.
The Motorola site has some MIPS benchmarks for the 5282
I think it's about 78 Mips for the 80 Mhz 5282.
>Not that we know the rated speed of unannounced Atmel parts, but it
>could perhaps reasonable be expected to compare to the AT91SAM7A3,
>which is stated to offer 54 MIPS at 60 MHz.
>If I want to use GDB hosted on Linux to debug a 5282 through the BDM
>port, do I have to buy an expensive interface box, or is there a cheap
>box or a free design I can use?
There are a number of low cost BDM's (BDM is Freescales version f JTAG debugging) for the coldfire.
Both Linux and Windows hosted.
Out (Netburner's) 5282 product uses the Network to upload/download code and
a non maskible serial routine running as a GDB stub.
If you have to have the BDM interface companies that have low cost ColdFire BDMs are
http://www.pemicro.com/http://www.cybertec.com.au/http://www.macraigor.com/wiggler.htm
Paul
Reply by Stephen Pelc●March 4, 20052005-03-04
On Wed, 02 Mar 2005 15:39:34 GMT,
stephenXXX@INVALID.mpeltd.demon.co.uk (Stephen Pelc) wrote:
>We have (finally) got round to testing our PowerNet TCP/IP
>stack on an ARM with 120k Flash and 64k RAM. With Telnet,
>multi-threaded HTTP server with CGI and ASP, it all fits
>and runs. Connection is over Ethernet (port-mapped RTL8019AS).
>The limitation is in the number of free buffers and number
>of simultaneous open connections.
>
>We'll know in a day or two what we can fit into 32k of RAM.
Preliminary tests show that the full PowerNet system works
fine in 32kb RAM, and with a few tweaks (in progress) will
work with 16kb RAM.
I'm pleased that a Usenet group discussion has improved
our product. Thank you all!
Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Reply by Markus Zingg●March 4, 20052005-03-04
On Fri, 04 Mar 2005 00:13:00 GMT, Darin Johnson <darin_@_usa_._net>
wrote:
>Markus Zingg <m.zingg@nct.ch> writes:
>
>> I would be carefull when it comes to the tricks mentioned by some
>> posters here. Don't forget that there are SYN flood attacks, tear drop
>> attacks and other malicious activity out there in the internet waiting
>> to hit your implementation. You must handle these kind of things
>> reasonably well in a comercial product or otherwise you will have
>> lot's of problems.
>
>For reference, what sorts of things should an ethernet implementation
>test for in general? For instance, if there's a product that works
>great in the lab, but turns out to be less robust when put into a
>customer's intranet? Not just things to test the software, but
>stressing the hardware too. Is there a nice checklist out there
>somewhere?
I haven't found a checklist, but out of my experience the timely order
of network events is something that is hard to test. In my project,
most of the bug's that ocured after lab testing were in this area.
To give you an example, one time our implementation ran into problems
if the answer to a second ARP query arrived before the first one. Was
a stupid typo, but it got undiscoverd in the lab.
What you SHOULD do under all circumstances is visit some "hacker"
sites, collect the latest attack tools and bomb your implementation
with it. If you don't do it, you can bet that someone else will.
Another thing you can do is to use a second device of yours and
programm it to generate all these ugly situations you fear most in
your implementation. I.e. make sure to generate out of order pakets,
fragmented pakets and so on. It's a matter of fact that you can
generate the most exotic pakets with your own hardware the easiest way
since even the raw socket interface does not allow to generate all
kind of ugly things. Such a test device of yours then can also be used
to verify future releases of your software.
Markus
Reply by Stephen Pelc●March 4, 20052005-03-04
On Thu, 3 Mar 2005 07:44:23 +0100, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:
>I am trying to figure out if we need more than 64 kB in the part or not.
>My conclusion so far is that 64 kB is OK for small systems, but not
>for "fullblown" systems.
From our experience, the RAM hogs in PowerNet are:
1) buffers for TCP packets, retries, windows ...
2) servers
64k RAM is enough. PowerNet can run in 32k RAM, but other
application demands for RAM may make it preferable to support
only one connection for the Telnet and HTTP servers.
Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Reply by ●March 3, 20052005-03-03
pbreed@netburner.com writes:
> A part with similar capabilites is availbile Today from FreeScale.
> 32 Bits, 64K Ram, 512K flash 10/100 Mac, CAN,I2C, 3 Uarts, SPI 8 Timers,
> 80Mhz etc.. etc...
How does an 80 MHz Coldfire perform compared to an 80 MHz ARM7?
Not that we know the rated speed of unannounced Atmel parts, but it
could perhaps reasonable be expected to compare to the AT91SAM7A3,
which is stated to offer 54 MIPS at 60 MHz.
If I want to use GDB hosted on Linux to debug a 5282 through the BDM
port, do I have to buy an expensive interface box, or is there a cheap
box or a free design I can use?
Thanks,
Eric
> I would be carefull when it comes to the tricks mentioned by some
> posters here. Don't forget that there are SYN flood attacks, tear drop
> attacks and other malicious activity out there in the internet waiting
> to hit your implementation. You must handle these kind of things
> reasonably well in a comercial product or otherwise you will have
> lot's of problems.
For reference, what sorts of things should an ethernet implementation
test for in general? For instance, if there's a product that works
great in the lab, but turns out to be less robust when put into a
customer's intranet? Not just things to test the software, but
stressing the hardware too. Is there a nice checklist out there
somewhere?
--
Darin Johnson
Support your right to own gnus.
Reply by Markus Zingg●March 3, 20052005-03-03
On Thu, 03 Mar 2005 07:53:40 -0700, "Richard H." <rh86@no.spam> wrote:
>Markus Zingg wrote:
>> Especially the SYN flood thing requieres implementing SYN cookies or
>> other kind of counter measures or else the limitted resources of an
>> embedded system are eaten up instantly.
>
>Markus,
>
>What approach did you implement for SYN cookies?
>
>I've seen a couple schemes - one crypto-based, the other a scheme for
>encoding the setup vars in the ISN. Both seem to have challenges, not
>the least of which is the limited field size of the Seq# to work with
>(never mind that it violates the requirement for ISN randomization).
We encode the setup vars and then create an MD5 hash out of this which
is used as the ISN. The hash key is varied randomly and only valid for
a certain duration. The SYN/ACK therefore must arrive within this time
window to be acepted.
>For example, did you sacrifice the options header / certain MSS
>increments in the process? IIRC, this is the one big point of
>compromise to fit in the available field space, with the being 0 RAM
>used until the reply SYN-ACK arrives (i.e., fairly impervious to SYN
>flooding).
The compromise is in reality not that big in that almost all TCP
implementations use some popular MSS value. Then you can't trust the
anounced MSS value anyways since there are implementations which
anounce a bigger MSS than what they actually accept. Sometimes there
are also gateways along the way which drop segments above a certain
size but fail to send the propper ICMP anouncements. Often this is the
case because a sysop firewalls everything but uses a router behind the
firewall showing this behaviour. In such scenarios it's often
impossible to tell wether the TCP implementation of the oponent is
broken or if it's just a configuration issue. This is just one area
where strict RFC compliance of your impelmenation alone does not
guarnatee seamless operation in the field. I do agree that such
situatins are rare, but they DO exist. So it's wise to have a TCP
implementation which is able to adapt the anounced MSS value
acordingly or else you will have interoperabilty issues. The problem
with these kind of things are that they ocure at the point in time
your product is in the market. It's even nastier that although your
product may follows the RFC's, the customer will point at you since
it's Windows PC's TCP implementation does adapt the anounced MSS and
therefore work. It's quite difficult to discuss such issues with end
users.... So you better prepare right from the start.
Obviousely solving these kind of issues also uses code space and
eventually also RAM. That's why I thought it's a good idea to bring
this point to Ulf's attention.
Markus
Reply by Markus Zingg●March 3, 20052005-03-03
>> I would be carefull when it comes to the tricks mentioned by some posters
>> here. Don't forget that there are SYN flood attacks, tear drop attacks and
>> other malicious activity out there in the internet waiting to hit your
>> implementation. You must handle these kind of things reasonably well in a
>> comercial product or otherwise you will have lot's of problems.
>
>I'm not sure what you mean with "the tricks mentioned by some posters"
>(perhaps you could be a little more specific?) but I would also like to
>stress the importance of doing heavy testing of a TCP/IP stack. Send as
>much "bad" packets to your stack as possible - others surely will.
I started my implementation about two years ago and back then all
small TCP stack's I looked at could not resist SYN flood attacks not
to mention more complicated attacks that are reality also. I do not
say that they necesairly crash the device, but there are no counter
measures at all in place. SYN flood attacks are nasty in that the
attacker can easily hide origin by randomly varying the sender IP
address. In normal day to day's live it's not feasable to track the
source of an attack since it would requiere cooperation of sysadmins
all across the way back to the attacker. In other words, such attacks
can go on for hours thereby rendering an embedded device using this
kind of unsecure TCP implementation useless. This CAN be a very
important issue if the device is used in a productive envireonement.
With "tricks" I mostly refered those implementations which try to keep
state in the NIC's buffer, useing specially crafted sequence numbers
et all. The randomness of initial sequence numbers is extremly
important to avoid other kind of attacks (i.e. man in the middle) . If
however bit's from the sequence number are used for other purposes as
sugested, the randomness of the numbers can't be guaranteed to a high
degree enough. I do see the obvious advantages that such tricks might
have to save RAM et all, but not also considering security issues in
todays times is probably only ok for hobby projects..
>> Another issue is how many systems out there simply do not play by the
>> standards. We see systems anouncing MSS but then do not accept segments
>> of this size etc. etc. So again, if this is for a heavily comercial kind
>> of application you must consider these things too.
>
>Failure to adhere to the size of the MSS seems to be the most common way
>to diverge from the RFC standards. This may work fine when talking to a
>PC, but may result in communication failure when trying to talk to a small
>embedded device. Lacking support for IP fragment reassembly also seems
>quite common. Some stacks also leave out TCP's congestion control, which
>may even lead to network overload. I fully agree with you: compliance with
>RFCs is important.
I actually was refering to some Linux TCP versions which in fact
anounce an MSS of say 1460 byte, but silently drop every segment
bigger than 1420 bytes. So, the embedded TCP stack must implement a
technique to slowly increase the MSS and maybe lower it if it sees
that segments are lost. Not that this would be a problem, but it must
be implemented and it uses code space and can't be ignored. Ignoreing
these kind of issues leads to hard to explain interoperabilty
problems.
>For a more thorough discussion of RFC compliance of small TCP/IP
>implementations, please refer to my MOBISYS'2003 paper "Full TCP/IP for
>8-bit architectures", available at
>http://www.sics.se/~adam/mobisys2003.pdf
I currently don't have the time to read this document but surely will
do so. I have no idea wether your implementation suffers in any of the
points I put my finger to. What I can say here though is that out of
my experience RFC compliance alone is often not enough. The stack also
must be able to deal with non complying implementations - at least to
some degree.
Markus
Reply by Ulf Samuelsson●March 3, 20052005-03-03
Eric Smith wrote:
> If you haven't yet decided the memory sizes, it's obviously quite
> a way out yet.
>
> Or if you have already taped out a part with 64KB and are trying to
> decide whether to introduce it as a product, the answer is yes. :-)
>
> Eric
I dont make decisions like this in Atmel,
but sometimes I can make people reverse decisions by good arguments.
If anyone has anything to complain about the Watchdog in the
SAM7S series then I am the guy to talk to.
Just wanted to know if the SRAM size was worthy of another crusade.
It looks like we can live with 64KB of SRAM for a substantial part
of the market.
--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB