Re: [cc65] cc65 + tcp/ip howto and/or example

Hi Dan,

> I am doing a stack for the Atari at the moment. I looked at uIP and IP65
> both. I found uIP too convoluted to use directly. IP65 seemed a lot cleaner
> but I didn't want to have to do it all in ML, as I'm lazy. So I took uIP
> apart and used bits of it to start what I have now. As a starting point, uIP
> was very helpful.

Just some thoughts...

If uIP would be too convoluted would it be then the by far most
popular TCP/IP stack for really small machines? Maybe it is in fact
rather well designed. Probably because the creator implemented already
several other TCP/IP stacks before and put all his experience into
uIP. Possibly this is the reason why i.e. CISCO choose uIP as basis
for their IPv6-for-small-devices investments.

Every non-trivial network application needs to react on theese three things:
1. network traffic
2. user interaction
3. timeout
The only way to do this in a both flexible and efficient manner is
event driven programming. So from this perspective alone it is already
evident that the event based uIP API is the right choice as it allows
for easy integration into any event driven program.

Additionally the event based uIP API allows for a non-buffering
copy-free handling of things like retransmissions. So it is the right
choice even for minimal programs not requiring an event driven
archtecture otherwise.

So I can't follow at all any argumentation saying uIP is "to much".
Rather it is in many/most cases still "to little". And therefore the
uIP creators don't supply uIP standalone anymore but only as part of
Contiki.

The Contiki core is about dispatching events. The event senders and
receivers are called processes. A typical Contiki program hosts
several processes:
1. One process polling the network card for new frames and placing
them in "the" buffer.
2. One process polling the keyboard (and mouse) and broadcasting user
events on user interaction.
3. One process polling the current timme and broadcasting timer events
on timeouts.
4. One process hosting uIP polling "the" buffer and sending events to
the uIP user process.
5. One (or several) process(es) hosting the actual application code
working in a pure event driven way (no polling at all).

So the several "internal" processes basically act as converters
abstracting from different low level inputs to a common uniform event
system.

Interestingly this basic/classic/pure Contiki core is better suited to
cc65 targets then to the targets it is supposed to run on today
(embedded devices, especially wireless sensors). Those devices make
heavy usage of interrupts trying to put the main processor to sleep as
much as possible to save engery. Getting Contiki to work in these
environments requires some additional tricks.

The cc65 C library on the other hand doesn't offer interrupt based
APIs (apart from the mouse cursor handlers) so the classic Contiki is
a perfect fit by calling keypressed() for user interaction polling and
clock() for timeout polling. And regarding the network it happens to
be just the same. The CS8900A chip doesn't support interrupts in 8-bit
I/O mode so Contiki is a perfect fit by polling the chip.

So from my perspective there's no artificial / unnecessary overhead in
any area at all. Rather the cc65 C library, uIP, Contiki and the
CS8900A chip work together perfectly smooth as they all follow the
same paradigm :-)

There's only one minor exception - which I already mentioned in
another thread before: uIP/Contiki put great effort in avoiding to use
the C heap but the cc65 module loader is hardwired to load modules on
the C heap. Allowing to provide the cc65 module loader with an
allocator callback function (in the same way there is a read callback
function) would allow avoid that unncessary linking-in of the C heap
code.

Certainly one can pull together some networking code and have some
packets sent/received but when I see i.e. a blocking function for
getting an IP address via DHCP which then internally calls the C64
kernal keyboard handler now and then in order to allow the user to
interrupt the waiting for a DHCP reply then this at best a hack to me
but certainly no framework to build something real upon.

The Breadbox64 twitter client on the other hand is a perfect example
that Contiki allows to write portable, really usefully, reliable,
interactive and responsive network apps without being a Contiki
insider - and moving Breadbox64 to IPv6 will be a piece of cake :-)

Just my two (quite lenghty) cents,
Oliver

P.S.: I ported Contiki to the Atari in a few days (after understanding
enough of the Atari). It's in the CVS and works out-of-the-box with
the Atari Ethernet solution. So I personally see more need in the
getting that Ethernet solution out to the people than in creating yet
another TCP/IP stack ;-))
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.