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 <[EMAIL PROTECTED]> 
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. ;)
> 
>> 
>> [EMAIL PROTECTED]:/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!
>> 
>> [EMAIL PROTECTED]:/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.
> 
>> 
>> [EMAIL PROTECTED]:/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
>> 
>> [EMAIL PROTECTED]:/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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
RTnet-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers

Reply via email to