Now tcpip_output() is a function pointer that is supposed to be set via the macro tcpip_set_outputfunc(). Packet drivers do so on process startup.
Thus if there are several packet drivers in a Contiki system the one started last is the one actually used. This behaviour is especially useful for the 'IP forwarding' "meta" packet driver.
Now tcpip_output() is a function pointer that is supposed to be set via the macro tcpip_set_outputfunc(). Packet drivers do so on process startup.
Thus if there are several packet drivers in a Contiki system the one started last is the one actually used. This behaviour is especially useful for the 'IP forwarding' "meta" packet driver.
Now tcpip_output() is a function pointer that is supposed to be set via the macro tcpip_set_outputfunc(). Packet drivers do so on process startup.
Thus if there are several packet drivers in a Contiki system the one started last is the one actually used. This behaviour is especially useful for the 'IP forwarding' "meta" packet driver.
Now tcpip_output() is a function pointer that is supposed to be set via the macro tcpip_set_outputfunc(). Packet drivers do so on process startup.
Thus if there are several packet drivers in a Contiki system the one started last is the one actually used. This behaviour is especially useful for the 'IP forwarding' "meta" packet driver.
This change means that one needs to select _ONE_ cfs implementation at Contiki library link time. But this doesn't appear to be an issue as all platforms have their "favorite" implementation anyway.
This change means that one needs to select _ONE_ cfs implementation at Contiki library link time. But this doesn't appear to be an issue as all platforms have their "favorite" implementation anyway.
This change means that one needs to select _ONE_ cfs implementation at Contiki library link time. But this doesn't appear to be an issue as all platforms have their "favorite" implementation anyway.
- All compilers used support the -I option for setting an include search directory.
- The Contiki source tree follows the (common) approach of placing declarations (in headerf iles) in the same directory as definitions (in source files).
As a result it makes sense to use the -I compiler option for just the same set of directories used for the vpath gnumake directive.
Note: I checked several builds but nevertheless one or the other might need some additional adjustsments. Sorry for the inconvenience.
- Search target specific directories before CPU specific directories.
- Search CPU specific directories before generic directories.
Note: I checked several builds but nevertheless one or the other might need some additional adjustsments. Sorry for the inconvenience.
- Workarounded the following CTK glitch:
ctk.c calls ctk_arch_keyavail() and ctk_arch_getkey() and needs therefore appropriate declarations (or macros) but it doesn't include a ctk_arch.h or alike to bring those in. So it's necessary to bring those declarations in via contiki-conf.h.
But ctk_arch_getkey() is supposed to return a ctk_arch_key_t - and this typedef'ed in ctk.h which means that ctk.h would need to be included in contiki-conf.h before declaring ctk_arch_getkey().
This IS rather undesirable so the current workaround is to declare ctk_arch_getkey() as returning a char - this is btw done similiar in platform/gtk as well. See ctk/ctk-gtksim.h:
guint ctk_arch_getkey(void);
Therefore I replaced that hack with a clean CONF macro, which by the way really removes the run() and exec() functionality instead of just implementing it empty.
