Hi Yuchen,
Hi, Jan, the first flame in 2005-:)
Good, I would have contacted you tomorrow anyhow to ask for you berlios and (optionally) sourceforge user id. Please create an account (if you haven't yet) and send me a mail.
Today, i made the eth1394 integrated in RTnet-0.8.0 source tree, so now we can configure the RTnet with --enable-firewire, and get the firewire stack for RTnet: rt_ohci1394.o, rt_ieee1394.o, rt_eth1394.o,
Very good news.
rtos_tasklet_scheduler.o. The rtos_tasklet_scheduler is made a seperate
module, so other fieldbus can also use it to get a realtime DSR. Some slight change in the RTnet core:
--- rtnet-0.8.0/stack/include/rtnet_internal.h 2004-12-13
05:04:26.000000000 -0500
+++ RTNetwork/rtnet-0.8.0/stack/include/rtnet_internal.h 2005-01-11
20:36:46.000000000 -0500
@@ -40,7 +40,7 @@
/* some configurables */
-#define RTNET_STACK_PRIORITY RTOS_HIGHEST_RT_PRIORITY +
RTOS_LOWER_PRIORITY
+#define RTNET_STACK_PRIORITY RTOS_HIGHEST_RT_PRIORITY +
RTOS_LOWER_PRIORITY+1
Better use "2*RTOS_LOWER_PRIORITY" to cover both cases (RTOS_LOWER_PRIORITY = 1 / -1).
/*#define RTNET_RTDEV_PRIORITY 5*/ #define DROPPING_RTSKB 20
--- rtnet-0.8.0/tools/rtifconfig.c 2004-12-20 05:08:51.000000000 -0500
+++ RTNetwork/rtnet-0.8.0/tools/rtifconfig.c 2005-01-11
06:54:49.000000000 -0500
@@ -40,6 +40,7 @@
#define PRINT_FLAG_ALL 1
#define PRINT_FLAG_INACTIVE 2
+#define ARPHRD_IEEE1394 24
If this is a constant only used between the RTnet core and rtifconfig, it's best located in rtnet_chrdev.h.
... I orignially planned to add extra MAC on Firewire, like what you have on ethernet, but I have decided not to. The reason is that isochronous of Firewire is already time triggered, with a fixed interval = 125us for each channel. Totally, there can be 64 channels. Besides isochronous transaction, the asynchronou transaction can be used for event triggered communication.
Ok, the more the hardware already does on its own with respect to deterministic MAC the better it is. It's better anyhow to integrate the lower layers first and see how they perform.
As we have discussed for contributing current Firewire extension to RTnet
main development, maybe it is good to have a development branch for RTnet
with Firewire, because I am planning to add the pure Firewrie protocol to
RTnet, bypassing the ethernet emulation, so there will some change and a lot
of extension to the RTnet core code. But of coz, I also need your advice:).
It's a good time to do this at the moment. The SVN will likely be rather calm for the next weeks (besides some potential bug fixes), so you will not have to keep up with significant modifications on the trunk soon. The next major one scheduled so far will be some changes in the stack to allow "dynamic" MTUs of devices.
Are you already a bit familiar with SVN? Do you know how to create a branch there? It's a simple copy operation of the trunk, see svnbook.red-bean.com. Or you may alternatively post your patches and let us set up the branch on which you can then continue to work.
Jan
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
