rtnet-developers — development-related list

Re: [RTnet-developers] some suggestions for the next TDMA version

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Hello,
>=20
> I'm currently working on getting RTnet working on an Infineon TriCore
> 1130 and found some issues, which could be solved in the next major
> TDMA version comming with RTnet. Would like to discuss these issues
> to see other's opinion about that.
>=20
> The TriCore1 architecture is a little bit tricky. When you want to
> send a frame over Ethernet, the host (the "cpu") has to write it into
> a shared memory (available via FPI bus). Then the host writes a
> special register to tell the DMUT (Data Management Unit Transmit) to
> get this Frame from shared memory and write it into Transmit Buffer
> TB. The TX block of the MAC takes the frame from TB and sends it to
> MII, which will put it on the wire. All this can be found in detail
> in [1], chapter 31.
>=20
> Here comes the problem: When sending request calibration frames, one
> has to provide a transmission time stamp as close as possible to the
> real transmission time. As the TriCore does not support changing the
> frame after writing it into shared memory (by host), there is no way
> for providing a real transmission time stamp. Only option is to put
> the scheduled transmission time there which will have the effect,
> that transmission time on the wire t_trans is always calculated to
> long because the real transmission is done later.

Unless you have to make the steps of writing to the shared mem +
triggering the transmission preemptible, the solution is simple: just
push out the local time taken right _before_ you start writing the
frame. For your arch, that is the point "as close as possible" to the
real tx date.

>=20
> To fix this issue there will be a few possibilities, one comes here:
> One could change TDMA.spec and allow slaves to send a two-parted
> request calibration frame. First one has a don't care Transmission
> Time stamp (marked as don't care by a bit or sth similiar). Slaves
> will notice their transmission time stamp in their TXISR, and send it
> in the second ReqCalFrm. This would make the whole process much more
> precise, but of course requires changes in TDMA.spec.

Yeah, that's how NTP and PTP work as well (follow-up message carrying
the timestamp of the first one), IIRC. Would be possible to extend the
specs, but there should be real hard needs for it.

Again, as long as the tx timestamp is taken at a fixed date before real
tx, TDMA can handle this (may one should clarify the spec in this regard)=
=2E

Jan

[RTnet-developers] some suggestions for the next TDMA version

[Karl R. <Kar...@gm...>]

Hello,

I'm currently working on getting RTnet working on an Infineon TriCore 1130 and found some issues, which could be solved in the next major TDMA version comming with RTnet. Would like to discuss these issues to see other's opinion about that.

The TriCore1 architecture is a little bit tricky. When you want to send a frame over Ethernet, the host (the "cpu") has to write it into a shared memory (available via FPI bus). Then the host writes a special register to tell the DMUT (Data Management Unit Transmit) to get this Frame from shared memory and write it into Transmit Buffer TB. The TX block of the MAC takes the frame from TB and sends it to MII, which will put it on the wire. All this can be found in detail in [1], chapter 31.

Here comes the problem: When sending request calibration frames, one has to provide a transmission time stamp as close as possible to the real transmission time. As the TriCore does not support changing the frame after writing it into shared memory (by host), there is no way for providing a real transmission time stamp. Only option is to put the scheduled transmission time there which will have the effect, that transmission time on the wire t_trans is always calculated to long because the real transmission is done later.

To fix this issue there will be a few possibilities, one comes here: One could change TDMA.spec and allow slaves to send a two-parted request calibration frame. First one has a don't care Transmission Time stamp (marked as don't care by a bit or sth similiar). Slaves will notice their transmission time stamp in their TXISR, and send it in the second ReqCalFrm. This would make the whole process much more precise, but of course requires changes in TDMA.spec.


I would really appreciate to get your opinions and comments to that idea!

Karl


[1] http://www.infineon.com/cms/en/services/download.html?filename=%2fdgdl%2ftc1130_um_v1.3_2004_11_per.pdf%3ffolderId%3ddb3a304412b407950112b41b37c12c2b%26fileId%3ddb3a304412b407950112b41b38162c2c&location=Products.Microcontrollers.32-Bit.TC1130_Family__TC1130__TC1115__TC1100_.TC1130.DOCUMENTS.tc1130_um_v1.3_2004_11_per.pdf
-- 
von Karl Reichert

GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Re: [RTnet-developers] High performance Giga Ethernet possible with RT-net?

[Jan K. <jan...@we...>]

Fillod Stephane wrote:
> ...
> I'll stop here my random thoughts for now, because I'd like to know
> whether
> RT-net is the right place. Besides, some people may have already taken
> that
> route, or at least that goal, and why not escape this wheel of
> reincarnation?

Sorry for cutting down your _very_ interesting mail that much, but I'm
short on time. A few comments that shall not end this discussion by not
citing your individual ideas, rather let the ideas flow even more:

 - RTnet is not only RTmac/TDMA. Just think of EML (Ethercat Master Lib)
   over RTnet, it has quite similar requirements! Also, several users
   are running plain RTnet/UDP against "black-box" devices without TDMA.

 - Zero-copy RX is on my list as well, probably with single-user mode
   for the beginning until HW-demuxing becomes commodity. There are also
   improvements for certain scenarios along the wakeup path possible.
   Same for zero-copy TX.

 - New APIs should always consider what happens around "normal" Linux
   first. Only divert from (upcoming) standard approaches when hard RT
   demands it.

 - NIC polling instead of IRQs: Sounds like Linux's NAPI. The drivers
   should look very similar under RTnet, one only has to reconsider the
   mode switch (IRQ-driver <-> polled) policy /wrt determinism.

 - There are certainly some things to do to push RTnet in the sketched
   directions, but we should be able to do this evolutionary, step by
   step.

Jan

[RTnet-developers] High performance Giga Ethernet possible with RT-net?

[Fillod S. <ste...@th...>]

Dear RT-net hackers,

I would like to open a discussion about the use of RT-net with Gigabit
Ethernet=20
in a high-performance fashion. The scene takes place in an embedded
platform,
with scarce resources, and the task is to process raw Ethernet frames
(RX+TX),=20
eventually at line rate (~950Mbps, 100k frames/s avg).

Looking at the present API, a Xenomai user task need to do one syscall
per
packet for each RX and TX side. On some platforms, a syscall can cost up
to=20
several microseconds. Up-to 4*950Mbps bandwidth with RAM (2x on RX, 2x
on TX)=20
is needed just for crossing kernel-user boundary. On the driver side,
RT-net=20
requests one interrupt per frame, which is normal to achieve low
latency, but=20
pointless when the only user task is periodic. What would be nice is the

ability for the user task to put the driver in polling mode. Of course
the=20
counterpart implies not being able to use TDMA and such in that mode,
but=20
that's fine with that kind of application.

So far, do you think it is among RT-net mission to offer such quality of

service? It might be also that this is present already, but I still
haven't=20
found it in RT-net 0.9.9 as I'm still digging through the code.

What I have in mind are the following, in order of importance:
* zero-copy interface between kernel-user
* scatter-gather support on TX side
* batched mode (more than one frame per syscall, interrupts->polling)

For the zero-copy, I was thinking about a pre-allocated rx buffer zone
that would be mmap'ed as read-only to user tasks. Some kind of reworked
rt_recvmsg() would query the list of frames received since last call.
The address of buffers would not be provided by the user task, but
by the rtnet stack, by filling in the msg_iov.iov_base field with=20
a pointer to the mmap'ed area. Once the user task is done with a
frame, a new call (or ioctl? direct access through mmap'ed zone
a la PACKET_MMAP[1]?) would release it to the driver for future use as=20
input frames.
Zero-copy for the TX side is a bit tricky, because it depends whether
the packet to be sent is mapped in kernel space or not. Does RTDM
provide developers with interface for easy kmapping? Virtual addresses=20
will have to be converted for valid DMA space. Once the transmit is
done,
the packet can be kunmapped and RT task should be notified that its
buffer can be reused. In that regard, I like the async API of
libusb-win32
outlined here[2] (rest easy, nothing about win32 with that kind of API
:-).
Unfortunately, such an API would work only with a MAC offering hardware
pattern matching, ie. doing the demultiplexing before the DMA.
[1] linux/Documentation/networking/packet_mmap.txt
[2] http://article.gmane.org/gmane.comp.lib.libusb.devel.windows/198

It looks like the scatter-gather TX support is already present in the
API
through the mean of sendmsg, but the driver is missing that information.
In fact, the gathering is done by a call to rt_memcpy_fromkerneliovec.
IMO, this should be up to the driver to decide whether to do soft
gathering using rt_memcpy_fromkerneliovec, or taking advantage of=20
hardware s/g DMA. Maybe a new field hard_start_xmit_sg would be welcomed
in struct rtnet_device? In the end, the sendmsg call would still need
to offer an asynchronous interface.

I'll stop here my random thoughts for now, because I'd like to know
whether
RT-net is the right place. Besides, some people may have already taken
that
route, or at least that goal, and why not escape this wheel of
reincarnation?

Thanks for reading and feedback,
--=20
Stephane

PS: has anybody ported the PowerQUICC 3 gianfar driver to RT-net?

Re: [RTnet-developers] adding a new discipline to the Kconfig script

[Jan K. <jan...@we...>]

[Please keep CC]

Giammarco Zacheo wrote:
> Ok, solved.

Fine.

>=20
> Oops, I saw the symbolic link in the folder after ./configure-ing, so
> I thought it had been automatically overwritten. :-S
>=20
> Thanks a lot, very kind. I stil have a lot to learn... :-)
>=20
> One more question. It is possible to use tdma on two different
> adapters at the same time?

Yes, in theory. I'm not sure right now when I last tried this nor am I
aware of any user doing so.

> When I start by hand tdmacfg on the second adapter, it says something
> like "file already opened", can't replicate the whole thing right
> now...i'll let you know soon

Please post more details (precise commands and error messages).

Jan

Re: [RTnet-developers] adding a new discipline to the Kconfig script

[Jan K. <jan...@we...>]

Giammarco Zacheo wrote:
> I feel very dumb asking...
>=20
> I would like to do some modifications to the tdma discipline, but
> without overwriting the existing one, so I tried to add a new menu
> entry into the Kconfig script of rtnet.
>=20
> I cloned the tdma folder, renaming it and everything into it with a
> new name, e.g. tdmb, then modified Kconfig and GNUmakefile.am. Done
> the same into the rtmac folder, adding in OPTDIRS the tdmb options,
> and finally modified configure.ac in the main folder. Ready to go, at
> least I thought: runned autoconf, automake, make menuconfig. All fine.
> The configure script seems to be correctly built, but when make enters
> the tdmb folder it complains about tdmb.c missing. I am not really a
> Make fan (my fault, I know) but I don't understand why it turns to a
> default target. Tried make -p, -d --debug with various arguments. but
> did not found a clue.
>=20
> What's wrong with this?

Can't tell, need code. Most interesting are likely the GNUmakefile.am
and Makefile.kbuild in the tdmb folder. Hmm, did you actually patched
Makefile.kbuild as well ("tdmb-objs")?

Yeah, RTnet's build system is "a bit" complex due to layering autotools
on top of the kernel module build system.

Jan

[RTnet-developers] adding a new discipline to the Kconfig script

[Giammarco Z. <g.z...@gm...>]

I feel very dumb asking...

I would like to do some modifications to the tdma discipline, but
without overwriting the existing one, so I tried to add a new menu
entry into the Kconfig script of rtnet.

I cloned the tdma folder, renaming it and everything into it with a
new name, e.g. tdmb, then modified Kconfig and GNUmakefile.am. Done
the same into the rtmac folder, adding in OPTDIRS the tdmb options,
and finally modified configure.ac in the main folder. Ready to go, at
least I thought: runned autoconf, automake, make menuconfig. All fine.
The configure script seems to be correctly built, but when make enters
the tdmb folder it complains about tdmb.c missing. I am not really a
Make fan (my fault, I know) but I don't understand why it turns to a
default target. Tried make -p, -d --debug with various arguments. but
did not found a clue.

What's wrong with this?

Thanks for helping

Giammarco

Re: [RTnet-developers] smc91111 driver

[Jan K. <jan...@we...>]

CAMUS Benoit wrote:
> Hello all,
> =20
>        =20
> I want to use rtnet with xenomai on a custom board (based on
> pxa255 with smc91x ethernet chip).
> Was glad to see this chip was supported, but a bit less when i tried to=

> use it.
>=20
> Loading it failed at probing even with the right physical address of th=
e
> chip. I'm on the way to solve this refering to standart driver (probabl=
y
> an ioremap missing).
> I saw too that smc_tx and smc_phy_interrupt were commented, that's
> surprinsing.
>=20
> So as i need a fully fonctionnal driver to test rtnet, i'd like to have=

> a statement of the driver, from that i'll can try to do what's missing
> or correct bugs.

The driver was once hacked for demo purposes to run on a fairly low-end
x86 embedded board (DIL/NetPC by SSV) which had a fairly slow I/O
interface. For that reasons, a hack like re-enabling IRQs inside the IRQ
handler of that device exists. I bet you have a better interface,
something like DMA...

Well, I would say go wild with an updated version that targets
up-to-date hardware. We could then look at both versions, either merge
them (maybe via CONFIG-magic) or simply move the old variant into a
different file. The problem is anyway that I will likely not be able to
dig out the DIL/NetPC and do regression testing. But I don't think there
are real users of this driver out there.

Jan

[RTnet-developers] smc91111 driver

[CAMUS B. <ben...@le...>]

Hello all,
 
        
I want to use rtnet with xenomai on a custom board (based on
pxa255 with smc91x ethernet chip).
Was glad to see this chip was supported, but a bit less when i tried to
use it.

Loading it failed at probing even with the right physical address of the
chip. I'm on the way to solve this refering to standart driver (probably
an ioremap missing).
I saw too that smc_tx and smc_phy_interrupt were commented, that's
surprinsing.

So as i need a fully fonctionnal driver to test rtnet, i'd like to have
a statement of the driver, from that i'll can try to do what's missing
or correct bugs.

Thanks in advance
                
ben

Re: [RTnet-developers] IRQ raise in rt_8169 rtnet driver using a NetGear PCI Board...

[Jan K. <jan...@we...>]

jean-francois wrote:
> Hello,
>=20
>=20
> I would like to make Ethernet communications between boards with few ji=
tter.
> For that, I am using RTNET 0.9.8 and xenomai 2.3 on a linux kernel=20
> 2.6.18.6. My hardware is a powerpc target with a Netgear gigabit PCI bo=
ard.
>=20
> Therefore, I use the experimental rt_8169 driver. I succeed in sending =

> frames, sending ping requests but the interrupt handler is not called=20
> when a frame is received by the driver.
> I tried to modify the acknowledgment of the interrupt status in=20
> rtl8169_interrupt  function(I modified it the same way as in the r8169 =

> linux driver). Whether the acknowledgment is modified or is  as provide=
d=20
> in rtnet package, the interrupt is never called.
>=20
> Complementary information :
>=20
>     * Xernomai is built in the kernel.
>     * I do not install tdma.ko.
>     * r8169 driver is not installed in the kernel when I use rt_8169.
>     * The r8169 linux driver works fine on the target.
>=20
> What is missing ? Thanks for your help in advance.
>=20

Well, you are probably the first (yet unlucky) person to try this driver
again since it was contributed.

Do you get interrupts on tx completion, or are there no interrupts at
all with that NIC? The latter would indicate some setup issue of the
hardware, not some acknowledging problem. Comparing the RT variant
against vanilla is already the right path to follow.

Jan

[RTnet-developers] IRQ raise in rt_8169 rtnet driver using a NetGear PCI Board...

[jean-francois <jef...@ya...>]

Hello,


I would like to make Ethernet communications between boards with few jitter.
For that, I am using RTNET 0.9.8 and xenomai 2.3 on a linux kernel 
2.6.18.6. My hardware is a powerpc target with a Netgear gigabit PCI board.

Therefore, I use the experimental rt_8169 driver. I succeed in sending 
frames, sending ping requests but the interrupt handler is not called 
when a frame is received by the driver.
I tried to modify the acknowledgment of the interrupt status in 
rtl8169_interrupt  function(I modified it the same way as in the r8169 
linux driver). Whether the acknowledgment is modified or is  as provided 
in rtnet package, the interrupt is never called.

Complementary information :

    * Xernomai is built in the kernel.
    * I do not install tdma.ko.
    * r8169 driver is not installed in the kernel when I use rt_8169.
    * The r8169 linux driver works fine on the target.

What is missing ? Thanks for your help in advance.


	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

Re: [RTnet-developers] No buffer space available

[Jan K. <jan...@we...>]

[You'll find the reply on rtnet-users which is the more appropriate list
for this question.]

Saiful Khan wrote:
> hello,
> I have a very simple client running on xenomai+rtnet, whish is simply
> sending 50 byte message continuously to server and the server is
> running on other linux system which is simply continuously receiving
> it printing.
> But the client can able to send (sendto()) only 16 messages  then it
> gives error: "No buffer space available".
>=20
> can you please tell me whats the reason.
>=20
> Thanks and regards
> Saiful
>=20
> -----------------------------------------------------------------------=
--
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers

[RTnet-developers] No buffer space available

[Saiful K. <sai...@gm...>]

hello,
I have a very simple client running on xenomai+rtnet, whish is simply
sending 50 byte message continuously to server and the server is
running on other linux system which is simply continuously receiving
it printing.
But the client can able to send (sendto()) only 16 messages  then it
gives error: "No buffer space available".

can you please tell me whats the reason.

Thanks and regards
Saiful

Re: [RTnet-developers] kernel thread "rtnet-stack" suspending[0.9.9]

[Yuchen Z. <yuc...@gm...>]

Problem solved! After doing everything over, including re-patching and
re-compiling the kernel using xenomai2.1, and ofcoz re-compiling
rtnet-0.9.9, everything works again. So it seems to be caused by some
misconfiguration on my site.

Yuchen

On 4/5/07, Yuchen Zhang <yuc...@gm...> wrote:
> Hi, all,
>
> I am using RTnet-0.9.9 and Xenomai2.1(Linux2.6.14). Everytime I load
> rtnet.ko, I got the error message: suspending kernel thread
> "rtnet-stack" after exception #14. Who else had the similar problem?
>
>
> Regards,
> Yuchen
>

Re: [RTnet-developers] how to disable the packets discarding in RTL8169

[Jan K. <jan...@we...>]

Romildo Souza wrote:
> Hello,
>=20
> I have a Network Interface Card (NIC), chipset RTL8169, and I would lik=
e to disable the packets discarding by the CRC. I mean, I need to capture=
 all the packets received and calculate, by myself, the CRC.=20
>=20
> I've made a search through the internet and didn't find any driver for =
this chipset with this feature.
>=20
> The linux kernel version is 2.6.18. Anyone could help me?
>=20

You will probably have to look for some datasheet of the 8139 chip in
order to check if such knob exists and in which register.

Jan

Re: [RTnet-developers] kernel thread "rtnet-stack" suspending[0.9.9]

[Jan K. <jan...@we...>]

Hi Yuchen,

let's keep this issue on one list for now.

Yuchen Zhang wrote:
> Hi, all,
>=20
> I am using RTnet-0.9.9 and Xenomai2.1(Linux2.6.14). Everytime I load
> rtnet.ko, I got the error message: suspending kernel thread
> "rtnet-stack" after exception #14. Who else had the similar problem?
>=20

First, make sure the kernel build is consistent (make clean/make/make
install on both kernel and RTnet). Did older RTnet versions load on the
same kernel/xenomai combo?

Then, at what address is the oops? What code is behind that address?
/proc/kallsyms can help, also objdump -dS <module.ko> if the module was
compiled with debug infos on.

Jan

[RTnet-developers] kernel thread "rtnet-stack" suspending[0.9.9]

[Yuchen Z. <yuc...@gm...>]

Hi, all,

I am using RTnet-0.9.9 and Xenomai2.1(Linux2.6.14). Everytime I load
rtnet.ko, I got the error message: suspending kernel thread
"rtnet-stack" after exception #14. Who else had the similar problem?


Regards,
Yuchen

Re: [RTnet-developers] RTnet port for Tricore?

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Thanks for the helping answer :)
>=20
> The plan is not to write a generic lib, although this would be very fin=
e. I'm writing my diploma at university of applied sience Berlin from beg=
inning of may for three months. This work consists of much more than a RT=
net implementation. I also have to first evaluate the requirements of the=
 whole system, communication ...
>=20
> So, what I can say to the requirements is, that I need a realtime ether=
net communication, but with much less features RTnet is offering. I need =
for example no backup masters, no protection against failing slaves ...  =
I just need a very simple, basic realtime ethernet, cause we are dealing =
with some testing systems here and if sth like failing stations occure, w=
e will just stop whole tests, so no need for that. We are dealing with on=
ly few use cases here, which are communication from master to slave(uni/m=
ulticast) with or without answers, callbacks and communication between sl=
aves. The whole communication is totally async.=20
>=20
> But of course writing a generic lib could be an option for me afterward=
s, or maybe for master thesis next summer.
>=20
> So why I am asking these questions is, because I'm at the moment thinki=
ng about differnet possibilities how to solve this problem. One of those =
- and at the moment my most prefered one, cause there is already a ready =
implementation for the PC (master) - is RTnet, but what I'm trying to fin=
d out is, how much work this would be, porting this (not completely, but =
basic features we need) to tricore 1130.
>=20
> So, don't really know what to ask at the moment. Maybe you could give m=
e some hints/suggestions, if you consider RTnet to be right for this, if =
you see any major problems ...

Sounds feasible. Did I already asked this: Do you have a working
"bare-metal" Ethernet NIC driver for the TriCore? That would be the base
to build all RTnet timing and protocol stuff around. And, finally, you
could then add the application code on top of it.

Try to find a clean separation (can already be a simple function call)
between RTnet services and your control application on top. Makes it
easier to cope with potentially changing requirements of the control
application.

Jan

Re: [RTnet-developers] RTnet port for Tricore?

[Karl R. <Kar...@gm...>]

> Karl Reichert wrote:
> > -------- Original-Nachricht --------
> > Datum: Thu, 29 Mar 2007 10:34:31 +0200
> > Von: Jan Kiszka <jan...@we...>
> > An: Karl Reichert <Kar...@gm...>
> > CC: rtn...@li...
> > Betreff: Re: [RTnet-developers] RTnet port for Tricore?
> > 
> >> Karl Reichert wrote:
> >>> Hello all,
> >>>
> >>> is there any work done porting RTnet on tricore from Infineon?
> >>>
> >>> What do you think, how much work would it be, writing an ethernet
> driver
> >> for RTnet for triboard 1130 NIC? I'm talking about a direct
> >> implementation, so no RTLinux like Xenomai/RTAI underneath.
> >>
> >> On bare metal? No OS at all? Feasible, for sure. It's much like hacking
> >> RTmac/TDMA (I suppose that is your goal) into Etherboot, see the old
> >> patches. The basic TDMA support was fairly small code, just suffering a
> >> bit from our lacking standardised format for transmitting the TDMA
> >> configuration to the slaves (you will see the shell script parser in
> the
> >> patch...). Additionally, I had to add high resolution timer support to
> >> Etherboot.
> >>
> >> The advantage of bare-metal RTnet clearly is that you can achieve very
> >> low jitters for frame timing and time stamp synchronisation. Basically,
> >> you should get into the region which Ethernet Powerlink reaches as well
> >> by dedicating separate controllers on their protocol handling. I would
> >> be very interested to hear about your experiences!
> >>
> >> Jan
> >>
> > 
> > Well, I'm still reading lots of papers to evaluate things, but as far as
> I understood until now, there are two possible ways how to do:
> > a) As there is no port of etherboot to the tricore architecture, I first
> have to port it to this and then using the old patches and hacking them
> into etherboot.
> > b) Implementing the RTnet spec directly on the tricore itself, which
> means, without using etherboot.
> > 
> > Would you agree with that or do you have any other ideas?
> > 
> > What would you consider to be less work, if you can tell?
> 
> Go for b), unless you want features of Etherboot as well (boot image
> download...). I gave the reference just to study the TDMA patch, not the
> whole Etherboot design.
> 
> What will be the application of that port? Means: what control structure
> will your code on tricore have, what communication will take place
> (periodic data reception or delivery, interactive traffic)? Or do you
> plan to write an RTnet library, ie. something totally generic? That's
> relevant when considering possible designs of the RTnet state machines.
> 
> Jan
> 

Thanks for the helping answer :)

The plan is not to write a generic lib, although this would be very fine. I'm writing my diploma at university of applied sience Berlin from beginning of may for three months. This work consists of much more than a RTnet implementation. I also have to first evaluate the requirements of the whole system, communication ...

So, what I can say to the requirements is, that I need a realtime ethernet communication, but with much less features RTnet is offering. I need for example no backup masters, no protection against failing slaves ...  I just need a very simple, basic realtime ethernet, cause we are dealing with some testing systems here and if sth like failing stations occure, we will just stop whole tests, so no need for that. We are dealing with only few use cases here, which are communication from master to slave(uni/multicast) with or without answers, callbacks and communication between slaves. The whole communication is totally async. 

But of course writing a generic lib could be an option for me afterwards, or maybe for master thesis next summer.

So why I am asking these questions is, because I'm at the moment thinking about differnet possibilities how to solve this problem. One of those - and at the moment my most prefered one, cause there is already a ready implementation for the PC (master) - is RTnet, but what I'm trying to find out is, how much work this would be, porting this (not completely, but basic features we need) to tricore 1130.

So, don't really know what to ask at the moment. Maybe you could give me some hints/suggestions, if you consider RTnet to be right for this, if you see any major problems ...

Thanks a lot
Karl
-- 
von Karl Reichert

"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [RTnet-developers] RTnet port for Tricore?

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> -------- Original-Nachricht --------
> Datum: Thu, 29 Mar 2007 10:34:31 +0200
> Von: Jan Kiszka <jan...@we...>
> An: Karl Reichert <Kar...@gm...>
> CC: rtn...@li...
> Betreff: Re: [RTnet-developers] RTnet port for Tricore?
>=20
>> Karl Reichert wrote:
>>> Hello all,
>>>
>>> is there any work done porting RTnet on tricore from Infineon?
>>>
>>> What do you think, how much work would it be, writing an ethernet dri=
ver
>> for RTnet for triboard 1130 NIC? I'm talking about a direct
>> implementation, so no RTLinux like Xenomai/RTAI underneath.
>>
>> On bare metal? No OS at all? Feasible, for sure. It's much like hackin=
g
>> RTmac/TDMA (I suppose that is your goal) into Etherboot, see the old
>> patches. The basic TDMA support was fairly small code, just suffering =
a
>> bit from our lacking standardised format for transmitting the TDMA
>> configuration to the slaves (you will see the shell script parser in t=
he
>> patch...). Additionally, I had to add high resolution timer support to=

>> Etherboot.
>>
>> The advantage of bare-metal RTnet clearly is that you can achieve very=

>> low jitters for frame timing and time stamp synchronisation. Basically=
,
>> you should get into the region which Ethernet Powerlink reaches as wel=
l
>> by dedicating separate controllers on their protocol handling. I would=

>> be very interested to hear about your experiences!
>>
>> Jan
>>
>=20
> Well, I'm still reading lots of papers to evaluate things, but as far a=
s I understood until now, there are two possible ways how to do:
> a) As there is no port of etherboot to the tricore architecture, I firs=
t have to port it to this and then using the old patches and hacking them=
 into etherboot.
> b) Implementing the RTnet spec directly on the tricore itself, which me=
ans, without using etherboot.
>=20
> Would you agree with that or do you have any other ideas?
>=20
> What would you consider to be less work, if you can tell?

Go for b), unless you want features of Etherboot as well (boot image
download...). I gave the reference just to study the TDMA patch, not the
whole Etherboot design.

What will be the application of that port? Means: what control structure
will your code on tricore have, what communication will take place
(periodic data reception or delivery, interactive traffic)? Or do you
plan to write an RTnet library, ie. something totally generic? That's
relevant when considering possible designs of the RTnet state machines.

Jan

Re: [RTnet-developers] RTnet port for Tricore?

[Karl R. <Kar...@gm...>]

-------- Original-Nachricht --------
Datum: Thu, 29 Mar 2007 10:34:31 +0200
Von: Jan Kiszka <jan...@we...>
An: Karl Reichert <Kar...@gm...>
CC: rtn...@li...
Betreff: Re: [RTnet-developers] RTnet port for Tricore?

> Karl Reichert wrote:
> > Hello all,
> > 
> > is there any work done porting RTnet on tricore from Infineon?
> > 
> > What do you think, how much work would it be, writing an ethernet driver
> for RTnet for triboard 1130 NIC? I'm talking about a direct
> implementation, so no RTLinux like Xenomai/RTAI underneath.
> 
> On bare metal? No OS at all? Feasible, for sure. It's much like hacking
> RTmac/TDMA (I suppose that is your goal) into Etherboot, see the old
> patches. The basic TDMA support was fairly small code, just suffering a
> bit from our lacking standardised format for transmitting the TDMA
> configuration to the slaves (you will see the shell script parser in the
> patch...). Additionally, I had to add high resolution timer support to
> Etherboot.
> 
> The advantage of bare-metal RTnet clearly is that you can achieve very
> low jitters for frame timing and time stamp synchronisation. Basically,
> you should get into the region which Ethernet Powerlink reaches as well
> by dedicating separate controllers on their protocol handling. I would
> be very interested to hear about your experiences!
> 
> Jan
> 

Well, I'm still reading lots of papers to evaluate things, but as far as I understood until now, there are two possible ways how to do:
a) As there is no port of etherboot to the tricore architecture, I first have to port it to this and then using the old patches and hacking them into etherboot.
b) Implementing the RTnet spec directly on the tricore itself, which means, without using etherboot.

Would you agree with that or do you have any other ideas?

What would you consider to be less work, if you can tell?

Thanks
Karl

-- 
von Karl Reichert

"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail

Re: [RTnet-developers] RTnet port for Tricore?

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Hello all,
>=20
> is there any work done porting RTnet on tricore from Infineon?
>=20
> What do you think, how much work would it be, writing an ethernet drive=
r for RTnet for triboard 1130 NIC? I'm talking about a direct implementat=
ion, so no RTLinux like Xenomai/RTAI underneath.

On bare metal? No OS at all? Feasible, for sure. It's much like hacking
RTmac/TDMA (I suppose that is your goal) into Etherboot, see the old
patches. The basic TDMA support was fairly small code, just suffering a
bit from our lacking standardised format for transmitting the TDMA
configuration to the slaves (you will see the shell script parser in the
patch...). Additionally, I had to add high resolution timer support to
Etherboot.

The advantage of bare-metal RTnet clearly is that you can achieve very
low jitters for frame timing and time stamp synchronisation. Basically,
you should get into the region which Ethernet Powerlink reaches as well
by dedicating separate controllers on their protocol handling. I would
be very interested to hear about your experiences!

Jan

[RTnet-developers] RTnet port for Tricore?

[Karl R. <Kar...@gm...>]

Hello all,

is there any work done porting RTnet on tricore from Infineon?

What do you think, how much work would it be, writing an ethernet driver for RTnet for triboard 1130 NIC? I'm talking about a direct implementation, so no RTLinux like Xenomai/RTAI underneath.

Thanks in advance for your help.
Karl
-- 
von Karl Reichert

"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail

[RTnet-developers] how to disable the packets discarding in RTL8169

[Romildo S. <rom...@ya...>]

Hello,

I have a Network Interface Card (NIC), chipset RTL8169, and I would like to disable the packets discarding by the CRC. I mean, I need to capture all the packets received and calculate, by myself, the CRC. 

I've made a search through the internet and didn't find any driver for this chipset with this feature.

The linux kernel version is 2.6.18. Anyone could help me?

Thanks a lot, 
Romildo

 __________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 

[RTnet-developers] RTmac/TDMA cycle

[<rob...@ao...>]

 Hello,
=20
 Sorry for this stupid question but I unfortunately found no information or=20=
an example in the documentation.
 How can I examine whether I am straight in my Slot or not? Does it give for=
 it an Event?
 Is there of it an example?
=20
 Thanks.
 Robin
=20
 =20
________________________________________________________________________
Kostenlos: AOL eMail
2 GB Speicherplatz sowie erstklassiger Spam- und eMail Virenschutz.
Sichern Sie sich Ihre pers=C3=B6nliche eMail Adresse noch heute!