Re: When the linux process could recieve the message transport through XDDP？
Hi,Steve: Thank you for the clarification. >>Will ADOES wake up the related linux process at once when the head >>domain write something to the XDDP node?* Or, the linux process >>has to wait for the schedule of linux kernel, if the processor is >>busy, it may wait for a long long time. >The Linux process cannot wake up immediately, otherwise what would >be the point of having an RT co-kernel if it didn't preempt the >non-RT environment. Yea，I can't agree more. Imagine this scenario, your processor have 4 cores and you only have one RT process which has single thread.So, there are 3 cores could be used for the linux processes at least. What i am interested in is that* if * * the linux process wait to receive message through XDDP has to compete* * for the cpu resources** with so many other linux processes .* >If you're going to build code that makes a NRT process a subordinate >of an RT process, you're going to have to employ some non-standard >logic and get creative about how you deal with the inverted priority >relationship that implicitly exists between the RT/NRT schedulers >involved in that scenario. What do you mean by " employ some non-standard logic"？Could you make me more clearlly? Thank you for your attention. Look forward to hearing from you. steve freyder 于2020年5月12日周二 上午11:43写道： > On 5/11/2020 9:16 PM, 孙世龙 via Xenomai wrote: > > Hi, > As i am using XDDP to transport messages bettween the head domain and > linux domain(i mean there are two processes, one is rt process, the other > is linux process.),I wonder that when the linux process could recieve the > message？ > *Will ADOES wake up the related linux process at once when the head > domain write something to the XDDP node?* Or, the linux process has to wait > for the schedule of linux kernel, if the processor is busy, it may wait for > a long long time. > > Thank you for your attention. > Looking forward to hearing from you. > > The Linux process cannot wake up immediately, otherwise what would be the > point of having an RT co-kernel if it didn't preempt the non-RT environment. > > > If the RT process wishes to give the non-RT process an opportunity to run > in order to receive the just-sent message, it had better relinquish the > CPU. Inserting an rt_sleep() call (or equivalent) might be one > (inelegant?) option, but certainly nothing in iPipe or anything at that > layer is going to magically solve that problem for you. > > > If you're going to build code that makes a NRT process a subordinate of an > RT process, you're going to have to employ some non-standard logic and get > creative about how you deal with the inverted priority relationship that > implicitly exists between the RT/NRT schedulers involved in that scenario. > XDDP is a bidirectional data relay, not a scheduler. > > > Regards, > > Steve > > >
Re: Does the xenomai regular thread whose schedule policy is SCHED_OTHER has more opportunities to occupy the cpu resources then the normal linux thread which managed by linux?
On 13.05.20 07:31, 孙世龙 via Xenomai wrote: Hi, I wonder that whether the xenomai regular thread whose schedule policy is *SCHED_OTHER* *has more opportunities to occupy the cpu resources* then the normal linux thread which managed by linux? Even if the linux thread with *SCHED_FIFO * schedule policy? Yes, that happens for Xenomai-attached thread when they enter the real-time domain, e.g. while holding a Xenomai lock. At that point, they are above any regular Linux thread by nature - because they have to in order to not break the scheduling requirements of the RT domain. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: RT I2C Raspberry Driver
Hi, On Mon, May 11, 2020 at 9:55 PM ayaida marwane wrote: > > Hi Greg, Hi all, > > Thank you Greg for your clarifications. > > I have some more questions below. > > BR, > Marwane. > > > Le 11 mai 2020 à 16:39, Greg Gallagher a écrit : > > > > Hi, > > > > On Mon, May 11, 2020 at 3:05 AM ayaida marwane via Xenomai > > wrote: > >> > >> Dear all, > >> > >> We need to communicate in RT with a sensor (accelerometer) working with > >> I2C protocol using a Raspberry 3 or 4 with Xenomai 3. The objective is, > >> for example, to detect a collision in RT. > >> > >> Is there any driver already existing in Xenomai 3 that could help us? > > > > Does the sensor support SPI? There is an existing SPI RTDM driver that > > will work on the Raspberry Pi 3. > > We have few sensors. Some of these sensors support I2C and SPI. Where can I > find the existing SPI RTDM driver that work with Raspberry Pi 3? it's located in the xenomai tree at kernel/drivers/spi/, the specific bcm2835 one is spi-bcm2835.c and the spi framework is in spi-master.c and spi-device.c > > >> > >> To do this, we want to use RTDM driver for that. If not possible, we could > >> use also Alchemy or Posix Skin or other from Kernel or Userland. The most > >> important is to do it in RT. > >> > >> Could you help us please? > > > > If you need I2C you'd have to implement the I2C rtdm driver similar to > > the SPI driver. I don't think anyone has tried Xenomai on the > > raspberry pi 4 yet (anyone?). You may want to stick with the > > raspberry pi 3 and then eventually try getting the arm64 ipipe running > > on the raspberry pi 4. > > Ok, we will try to do it for Raspberry Pi 3 if it is easier. Then, we will > see for Raspberry Pi 4. > > If we will succeed, we will distribute it. So any help, indications or > recommendations are welcome. Sounds great, if you need help porting the ipipe to this new SOC let me know, I'd be happy to help. -Greg > > Thank you in advance for your help. > > > > >> > >> Best regards, > >> Marwane Ayaida. > > > > Thanks > > > > Greg >
Does the xenomai regular thread whose schedule policy is SCHED_OTHER has more opportunities to occupy the cpu resources then the normal linux thread which managed by linux?
Hi, I wonder that whether the xenomai regular thread whose schedule policy is *SCHED_OTHER* *has more opportunities to occupy the cpu resources* then the normal linux thread which managed by linux? Even if the linux thread with *SCHED_FIFO * schedule policy? Thank you for your attention. Look forward to hearing from you.
Re: When the linux process could recieve the message transport through XDDP？
On 5/12/2020 1:37 AM, 孙世龙 wrote: Hi,Steve: Thank you for the clarification. >>Will ADOES wake up the related linux process at once when the head >>domain write something to the XDDP node?* Or, the linux process >>has to wait for the schedule of linux kernel, if the processor is >>busy, it may wait for a long long time. >The Linux process cannot wake up immediately, otherwise what would >be the point of having an RT co-kernel if it didn't preempt the >non-RT environment. Yea，I can't agree more. Imagine this scenario, your processor have 4 cores and you only have one RT process which has single thread.So, there are 3 cores could be used for the linux processes at least. What i am interested in is that*if * * the linux process wait to receive message through XDDP has to compete* * for the cpu resources** with so many other linux processes .* >If you're going to build code that makes a NRT process a subordinate >of an RT process, you're going to have to employ some non-standard >logic and get creative about how you deal with the inverted priority >relationship that implicitly exists between the RT/NRT schedulers >involved in that scenario. What do you mean by " employ some non-standard logic"？Could you make me more clearlly? Thank you for your attention. Look forward to hearing from you. steve freyder mailto:st...@freyder.net>> 于2020年5月12日周二 上午11:43写道： On 5/11/2020 9:16 PM, 孙世龙 via Xenomai wrote: Hi, As i am using XDDP to transport messages bettween the head domain and linux domain(i mean there are two processes, one is rt process, the other is linux process.),I wonder that when the linux process could recieve the message？ *Will ADOES wake up the related linux process at once when the head domain write something to the XDDP node?* Or, the linux process has to wait for the schedule of linux kernel, if the processor is busy, it may wait for a long long time. Thank you for your attention. Looking forward to hearing from you. The Linux process cannot wake up immediately, otherwise what would be the point of having an RT co-kernel if it didn't preempt the non-RT environment. If the RT process wishes to give the non-RT process an opportunity to run in order to receive the just-sent message, it had better relinquish the CPU. Inserting an rt_sleep() call (or equivalent) might be one (inelegant?) option, but certainly nothing in iPipe or anything at that layer is going to magically solve that problem for you. If you're going to build code that makes a NRT process a subordinate of an RT process, you're going to have to employ some non-standard logic and get creative about how you deal with the inverted priority relationship that implicitly exists between the RT/NRT schedulers involved in that scenario. XDDP is a bidirectional data relay, not a scheduler. Regards, Steve You're right, and I shouldn't have ignored the scenario that you pointed out where there are multiple CPUs available. Certainly if there is more than one CPU, then it's possible for the Linux process on the NRT side of the XDDP socket to wake up immediately when the RT side sends data on the socket assuming that the NRT process is waiting for read completion and that it's the highest priority process on the Linux side. To the extent that you can ensure those conditions are met, you'll be able to ensure the kind of performance you're looking for.
