Dear Jan Kiszka,
--> Did you check before that there is, e.g., no IRQ conflict of the
rt_eepro100 with some Linux hardware that prevents correct operation?
cat /proc/xenomai/irq
IRQ CPU0
7: 12 rt_eepro100
216: 532151 [timer]
258: 7 [virtual]
cat /proc/interrupts
CPU0
0: 134467 XT-PIC timer, rthal_broadcast_timer
1: 1819 XT-PIC i8042
2: 0 XT-PIC cascade
4: 260 XT-PIC serial
5: 0 XT-PIC uhci_hcd:usb2
8: 2 XT-PIC rtc
10: 332 XT-PIC uhci_hcd:usb1
12: 7505 XT-PIC i8042
15: 21746 XT-PIC ide1
NMI: 0
LOC: 134415
ERR: 0
MIS: 0
So, I think that there is no conflict for IRQ.
--> Does the slave work without any RTmac/TDMA being activated (test with
rtping)?
I have loaded rt_eepro100, rt_loopback, rtipv4, rtpacket and rtnet. Later
on, I try to rtping the AT91 board from Intel board or rtping the Intel
board from AT91 board and both the results are possitive.
linux:/usr/local/rtnet/sbin # lsmod
Module Size Used by
rt_loopback 4356 1
rt_eepro100 19848 1
rtpacket 6912 0
rtipv4 26400 0
rtnet 38540 4 rt_loopback,rt_eepro100,rtpacket,rtipv4
af_packet 21768 0
ipv6 241920 12
loop 17032 0
<snipped>
linux:/usr/local/rtnet/sbin # ./rtroute add 172.16.6.203 14:09:07:05:05:02
dev rteth0
linux:/usr/local/rtnet/sbin # ./rtping 172.16.6.203
Real-time PING 172.16.6.203 56(84) bytes of data.
64 bytes from 172.16.6.203: icmp_seq=1 time=868.4 us
64 bytes from 172.16.6.203: icmp_seq=2 time=861.6 us
64 bytes from 172.16.6.203: icmp_seq=3 time=872.4 us
64 bytes from 172.16.6.203: icmp_seq=4 time=860.7 us
64 bytes from 172.16.6.203: icmp_seq=5 time=867.3 us
So what to do next? Please advice. Thanks
Regards,
Chun Yeow
On 8/29/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>
> Yeoh Chun Yeow wrote:
> > Dear Jan and Gilles,
> >
> > I further trace down the code in tdma_ioctl.c and found out that the
> > following functional call is not return in the slave (Intel M Processor
> > using rt_eepro100):
> >
> > ret = rtpc_dispatch_call(start_calibration, 0, &req_cal,
> sizeof(req_cal),
> > copyback_calibration, cleanup_calibration).
> > (found in tdma_ioctl_set_slot)
> >
> > Any ideas?
>
> If you are already that deep: The interesting question is why the TDMA
> code is not issuing calibration request frames. Given that those frames
> would be the first to sent by the slave, I wonder if the slave is able
> to send at all. Did you check before that there is, e.g., no IRQ
> conflict of the rt_eepro100 with some Linux hardware that prevents
> correct operation? Does the slave work without any RTmac/TDMA being
> activated (test with rtping)?
>
> Jan
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
