Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.arch.embedded Subject: Re: Common name for a "Task Loop" Date: Sat, 9 Jul 2016 21:41:39 +0300 Organization: Tidorum Ltd Lines: 34 Message-ID: References: <52krnb9mmrtr1rvf0mc287dk2fvfeip778@4ax.com> <-9ydnaZZCujtUuLKnZ2dnUU7-QmdnZ2d@giganews.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Nd1bRBqTzz+ra2CKUrxIHQVyWVmc2tGhM4e30o4rApr0aeaa4q Cancel-Lock: sha1:xwlD+49QslAu3hsSo+AvjCK8wgI= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: Xref: csiph.com comp.arch.embedded:24588 On 16-07-09 01:28 , upsidedown@downunder.com wrote: > On Fri, 8 Jul 2016 23:35:22 +0300, Niklas Holsti > wrote: [snip] >> One example of interactions I find difficult is a shared I/O channel or >> bus that must be used by various tasks, for various purposes, with most >> transmissions being sporadic and such that the sending task must wait >> for and check a response transmission. I believe that there are analysis >> methods which can find bounds on the response times for these tasks, >> including queueing delays and communication latencies, but I haven't >> studied or tried them yet. I may have to do so in my current project, >> however, because the system has three inter-communicating computers, >> with each computer connected by one SpaceWire link to a central router. > > I would never even dream of letting multiple tasks directly accessing > a serial line. > > Just put a high priority task on every serial line and let it do the > arbitration between the application tasks. You can put much more > intelligence than into the ISR. I was not speaking of an *implementation* difficulty, but of the difficulty of *analysing* the resulting client-task timing and response times. Of course the implementation uses one or more transmit queues, a dedicated channel-server task, interrupt handling, and possibly a separate channel-receiver task (for full-duplex channels). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .