Re: [RTnet-developers] arcnet driver
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
Re: [RTnet-developers] arcnet driver
|
From: Chris L. <ca...@uf...> - 2006-07-17 22:15:13
|
Hi Jan,
I've modified a simple arcnet communication program to support the
new real-time driver.. but I'm having a problem opening the socket
(the first step, i know!) where the function returns an integer
value of -97? The original program called the socket function with
the following socket type and protocol and I've modified it as
shown below.
int sockfd = socket(PF_PACKET, SOCK_PACKET, htons(ETH_P_ALL)); //
the original
int sockfd = rt_dev_socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
// the modified
I know that SOCK_PACKET is an outdated socket type but the
alternative SOCK_RAW will not work either. I found in the
rt_pci32.c driver that the arguments AF_INET and SOCK_DGRAM work
but I need to use header information in the arcnet packets.
Any suggestions?
Thanks for all of the help,
Chris Lightcap
University of Florida
On Fri Jul 14 12:31:27 EDT 2006, Jan Kiszka <jan...@we...>
wrote:
> Chris Lightcap wrote:
>>
>> Hi Jan,
>>
>> I made the changes you suggested in your last response. I've
>> exported
>> the rtdev_alloc so that I can use that with arcdev_setup in my
>> driver.
>> (code shown below)
>>
>> /* Setup a struct device for ARCnet. */
>>
>> static void arcdev_setup(struct rtnet_device *dev)
>> {
>> dev->type = ARPHRD_ARCNET;
>> dev->hard_header_len = sizeof(struct archdr);
>> dev->mtu = choose_mtu();
>> dev->get_mtu = rt_hard_mtu; // RTNET
>>
>> dev->addr_len = ARCNET_ALEN;
>>
>> // dev->tx_queue_len = 100; // RTNET
>> // dev->watchdog_timeo = TX_TIMEOUT;
>>
>> dev->broadcast[0] = 0x00; // for us, broadcasts are
>> address 0
>> // New-style flags.
>>
>> dev->flags = IFF_BROADCAST;
>> // Put in this stuff here, so we don't have to export
>> the symbols to
>> // the chipset drivers.
>> dev->open = arcnet_open;
>> dev->stop = arcnet_close;
>> dev->hard_start_xmit = arcnet_send_packet;
>>
>> // dev->tx_timeout = arcnet_timeout;
>> // dev->get_stats = arcnet_get_stats;
>>
>> dev->hard_header = arcnet_header;
>> dev->rebuild_header = arcnet_rebuild_header;
>> }
>>
>> struct rtnet_device *rt_alloc_arcdev(char *name)
>> {
>> struct rtnet_device *dev;
>>
>> /*** RTnet ***/
>> dev = rtdev_alloc(sizeof(struct arcnet_local)); //
>> <-------
>> if (!dev)
>> return NULL;
>>
>> arcdev_setup(dev);
>>
>> memset(dev->broadcast, 0xFF, ARCNET_ALEN);
>> strcpy(dev->name, "rteth%d");
>> rtdev_alloc_name(dev, "rtarc%d");
>> rt_rtdev_connect(dev, &RTDEV_manager);
>> RTNET_SET_MODULE_OWNER(dev);
>> dev->vers = RTDEV_VERS_2_0;
>>
>> /*** RTnet ***/
>>
>> if(dev) {
>> struct arcnet_local *lp = (struct arcnet_local *)
>> dev->priv;
>> rtdm_lock_init(&lp->lock); /*** RTnet ***/
>> }
>>
>> return dev;
>> }
>>
>> We're not planning to run RTmac/TDMA over our RT arcnet so we've
>> decided
>> to scratch the rtnet startup script and load the required
>> modules in our
>> own script. Is there anything more that has to be done to load
>> rtnet?
>
> Yes and no. Explanation follows below.
>
>>
>> mknod /dev/rtnet c 10 240
>>
>> ifconfig lo down
>> ifconfig arc0 down
>>
>> insmod /usr/local/rtnet/modules/rtnet.ko
>> insmod /usr/local/rtnet/modules/rtipv4.ko
>> insmod /usr/local/rtnet/modules/rtpacket.ko
>> insmod /usr/local/rtnet/modules/rt_loopback.ko
>>
>> insmod /usr/local/rtnet/modules/rt_arcnet.ko
>> insmod /usr/local/rtnet/modules/rt_com20020.ko
>> insmod /usr/local/rtnet/modules/rt_com20020-pci.ko
>> insmod /usr/local/rtnet/modules/rt_arc-rawmode.ko
>>
>> /usr/local/rtnet/sbin/rtifconfig rtarc0 up 10.1.1.1
>> /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
>>
>> It seems like everything loaded ok (no error messages) and
>> here's the
>> output from dmesg | tail .. is the station address 00 a looming
>> problem?
>> can I change this in the source file?
>
> That looks arcnet-specific to me, and this is something I cannot
> comment
> on due to lacking experience. I would compare the output with
> standard
> Linux. Of course, understanding how the station addresses are
> normally
> used will be even better. ;)
>
>>
>> lightcap@borelli:/usr/local/rtnet/sbin$ dmesg | tail
>> [4299263.969000] rt-arcnet: COM20020 PCI support
>> [4299263.970000] ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 18
>> (level,
>> low) -> IRQ 21
>> [4299263.970000] rtarc0: Contemporary Controls
>> [4299264.272000] rtarc0: PCI COM20020: station 00h found at
>> CC70h, IRQ 21.
>> [4299264.280000] rtarc0: Using CKP 64 - data rate 2.5 Mb/s.
>> [4299264.280000] RTnet: registered rtarc0
>> [4300094.481000] initializing loopback...
>> [4300094.481000] RTnet: registered rtlo
>> [4300094.511000] rt-arcnet: raw mode (`r') encapsulation support
>> loaded.
>> [4300094.512000] rtarc0: WARNING! Station address 00 is
>> reserved for
>> broadcasts!
>>
>> and surprisingly!
>>
>> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtifconfig -a
>> rtarc0 Medium: unknown (7)
> ^^^^^^^
> Hah, this still needs fixing! :o>
> (see tools/rtifconfig.c)
>
>> IP address: 10.1.1.1 Broadcast address: 10.255.255.255
>> UP BROADCAST RUNNING MTU: 508
>>
>> rtlo Medium: Local Loopback
>> IP address: 127.0.0.1
>> UP LOOPBACK RUNNING MTU: 1500
>>
>> Here is the interesting part! I have a worst case rtt of 0.0 us
>> when I
>> ping the local loopback. This can't be right. Even more strange
>> is that
>
> Let me guess: you run this over RTAI? Then you did not start the
> system
> timer /somehow/. Normally, this is done by rtcfg.ko or tdma.ko.
> If those
> modules aren't loaded, your application has to do this. But as
> you do
> not have any application yet: simply insmod rtcfg.ko. This will
> start
> the timer while rtcfg remains passive otherwise.
>
>> I can ping the arcnet card, which I thought was only possible
>> for TCP/IP
>> devices. What should I set for the IP address of my arcnet card;
>> should
>> I leave it empty? And the big question is how can I test the
>> performance
>> of the new arcnet driver without implementing it in our robot
>> control
>> software? I have Ethereal but I it would be helpful if you had an
>> example program.
>
> Well, if it is transparent to the rest of the RTnet stack (and
> this
> seems to be the case), rtping would be a good start. Another
> performance
> tester are the rtt-* examples under examples/xenomai/posix.
> Teresa
> Noviello started a RTAI port recently, but I don't know the
> current status.
>
>>
>> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 127.0.0.1
>> Real-time PING 127.0.0.1 56(84) bytes of data.
>> 64 bytes from 127.0.0.1: icmp_seq=1 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=2 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=3 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=4 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=5 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=6 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=7 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=8 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=9 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=10 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=11 time=0.0 us
>>
>> --- 127.0.0.1 rtping statistics ---
>> 11 packets transmitted, 11 received, 0% packet loss
>> worst case rtt = 0.0 us
>>
>> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 10.1.1.1
>> Real-time PING 10.1.1.1 56(84) bytes of data.
>> 64 bytes from 127.0.0.1: icmp_seq=1 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=2 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=3 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=4 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=5 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=6 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=7 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=8 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=9 time=0.0 us
>>
>> --- 10.1.1.1 rtping statistics ---
>> 9 packets transmitted, 9 received, 0% packet loss
>> worst case rtt = 0.0 us
>>
>>
>> Thanks again! I'm making great process thanks to your quick
>> responses.
>
> I'm just eagerly awaiting your patches... :)
>
> Jan
>
>
>
--
LIGHTCAP,CHRISTOPHER A
|
