Re: [RTnet-developers] RTnet port for Tricore?
Brought to you by:
bet-frogger,
kiszka
|
From: Jan K. <jan...@we...> - 2007-04-05 17:30:43
|
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 |