I. Build Ethernet drivers individually for each target.
After all the Ethernet cards/carts are different enough to ask for customized drivers. Building the drivers individually opens the option to use .ifdef's to customize them.
II. Removed Ethernet driver I/O base.
So far the base address of the Ethernet chip was a general property of all Ethernet drivers. It served two purposes:
1. Allowing to use a single Ethernet driver for a certain Ethernet chip, no matter what machine was connected to the chip.
2. Allowing use an Ethernet card in all Apple II slots.
However, we now use customized Ethernet drivers for the individual machines so 1.) isn't relevant anymore. In fact one wants to omit the overhead of a runtime-adjustable base address where it isn't needed.
So only the Apple II slots are left. But this should rather be a driver-internal approach then. We should just hand the driver the slot number the user wants to use and have the driver do its thing.
III. With per-target Ethernet drivers we can have per-target MAC addresses.
IV. Added support for RR-Net MK3 unique MAC addresses.
The RR-Net MK3 can be operated in two modes:
- In cartrigde mode it has a startup-ROM that sets the CS8900A MAC address to the unique MAC address.
- In clockport mode the driver has to read the two lowest MAC address bytes from the EEPROM and combine them with 28:CD:4C:FF.
See http://wiki.icomp.de/wiki/RR-Net#Detecting_MK3 for details.
The driver first checks if the current CS8900A MAC address starts with 28:CD:4C:FF. If it does, it overwrites its built in default MAC address with the CS8900A MAC address.
If the CS8900A MAC address didn't start with 28:CD:4C:FF, it checks if there are two valid MAC address bytes in the EEPROM. If they are there, it overwrites its built in default MAC address with a combination of 28:CD:4C:FF and those two bytes.
V. Added support for the upcoming 'Dracarys' Ethernet PBI for the ATARI.
See http://atariage.com/forums/topic/287376-preannouncement-dragon-cart-ii/ for details on Dracarys.
So far there was only one Ethernet solution for the ATARI. Therefore the relevant driver was loaded statically. With now having two solutions we have to load the corresponding driver dynamically (like on the other machines). Fortunately this doesn't mean significant additional overhead as there are several mouse drivers for the ATARI asking for dynamic mouse driver loading. Therefore the dynamic driver loading infrastructure was linked already.
Another aspect of more than one Ethernet solution is that the Ethernet config program becomes necessary on the ATARI to select the correct driver. Although that program is pretty simple and therefore rather small it means that now only one "major" program fits on a 130kB disk. So we need now 5(!) 130kB disk images instead 3 so far.
The cc65 tool chain comes with V.24 drivers so it seems reasonable to use the existing Contiki SLIP driver to implement network access via SLIP as alternative to Ethernet.
Some notes:
- The Ethernet configuration was simplified in order to allow share it with SLIP.
- The Contiki SLIP driver presumes an interrupt driven serial receiver to write into the SLIP buffer. However the cc65 V.24 drivers aren't up to that. Therefore the main loops were extended to pull received data from the V.24 buffers and push it into the SLIP buffer.
- As far as I understand the serial sender is supposed to block until the data is sent. Therefore a loop calls the non-blocking V.24 driver until the data is sent.
On all platforms there's only one V.24 driver available. Therefore V.24 drivers are always loaded statically.
On the Apple][ the mouse driver is now loaded statically - independently from SLIP vs. Ethernet. After all there's only one mouse driver available. However there's a major benefit with SLIP: Here all drivers are loaded statically. Therefore the dynamic module loader isn't necessary at all. And without the loader the heap manager isn't necessary at all. This allows for a reduction in code size roughly compensating for the size of the SLIP buffer.
Adam Dunkels writes on 2/5/2017 on the Contiki mailing list:
[...] the original idea was that the application could just point the uip_appdata pointer to wherever the data was, but we then changed it so that the data actually had to be copied into the uip_aligned_buf buffer. So, yes, the network device driver should only need to read from this buffer. [...]
This change removes comments on the possibility of uip_appdata pointing somewhere outside the uip_aligned_buf. And it removes code in the SLIP drivers not necessary anymore.
Additionally it makes code in a SLIP driver optional that takes care of the Microsoft-specific CLIENT / SERVER / CLIENTSERVER chat.
After all there's no momentum for a W5100-based Ethernet solution on the ATARI. So I revert to static linkage of the CS8900A driver as this improves program load times.
I just tried to compile this platform for my Zigbit mote (AT86RF230) here in a hello-world example, but it didn't work.
I reviewed this makefile and found that the request to compile "frame.c" was not necessary and bring up a missing error:
"make: *** No rule to make target `obj_avr-zigbit/frame.o', needed by `contiki-avr-zigbit.a'. Stop."
Frame.c is already inserted in radio's makefile.
Another problem was the undefined reference created by the missing module "core/net":
"contiki-avr-zigbit.a(sicslowpan.o): In function `input':"
"contiki/examples/hello-world/../../core/net/ipv6/sicslowpan.c:1521: undefined reference to `link_stats_input_callback'"
Both solved now. Hope it helps anyone else.
