"Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote in message news:eJWdnVI5BJIYVIXSnZ2dnUVZ_qidnZ2d@giganews.com...> >I've been implementing custom devices for stage music use for several > years, >>using small SBCs that run a basic RTOS that I code up myself. The input > and >>output is MIDI, coded music tokens (not digitised audio) at a serial data > >>rate of 31.25 KB. Even with the maximum amount of processing involved, >>latency time between receipt of a byte and its associated transmission was > >>never more than a millisecond or so. >> >>The main limitation has been HMI, for that reason I'm looking at moving to > a >>SBC that can support USB so that I can connect to a tablet or palm device. > >>What I'm finding is that boards that support the sort of interfaces that >>will talk to eg. a tablet, are often really slow in comparison. Based on >>information I've managed to glean, many of these systems are likely to >>introduce throughput delays of 30mS or longer, even for a 2-line program >>loop read char/send char.That's getting to be too long for music. >> >>The OS involved, usually Linux, is one contributor, random processing >>holdups of > 10mS for system housekeeping are cited. One system I checked > >>out doesn't use interrupts for the serial ports that MIDI uses, it just >>polls them at about 100 Hz, adding another potentially 20mS to the round >>trip. >> >>What I'm after is a small SBC that has reasonable support for USB comms, > and >>also can guarantee turnround of only a few mS for low level I/O such as >>serial comms. Does anyone have any suggestions? TIA >> >> >> > > Could you explain a bit more about your HIM implementation and how is your > SBC hardware? In general you can set the priority of your music process > to > maximum, and the HIM managin to your left time. In general, you can set > some sort of DMA to always transfer your image buffer to the display. So > all you got do is uptdate your display buffer at RAM. The user inputs > would > be handled by a interrupt, but just effectively processed when you got > time > left. I belive that is the most common implementation. > > Cya > > --------------------------------------- > Posted through http://www.EmbeddedRelated.comThanks for the information, everyone, it's very useful. I've already purchased hardware that I thought would serve, only to find that timing issues have probably invalidated its use. As per the request/suggestion above, here'a bit more info on the situation. My envisaged config will have two components, a 'client' which will be a SBC, and a 'Master', which will be a tablet. The musical signals that need controlled latency will come into the client via a UART, and leave the same way. The client does some fairly rudimentary processing, such as as interspersing control sequences. The USB is purely for communication between the client and the master tablet, things like selecting instrumentation and manual stop/starts. None of the information passing between these is particularly time critical. My concern is delays that (reportedly) can occur from UART input to UART output within the client, running Linux. Why am I considering USB at all? Because AFAIAA, tablets don't come with any alternative interfaces that will easily connect to a SBC micro. Thanks again to everyone who took the time to input.
I/O latency for systems not using a RTOS
Started by ●January 19, 2012
Reply by ●January 21, 20122012-01-21
Reply by ●January 21, 20122012-01-21
Op 20-Jan-12 11:10, David Brown schreef:> On 20/01/2012 03:42, langwadt@fonz.dk wrote: >> On 19 Jan., 17:08, pip...@disney.com (Jack) wrote: >>> David Brown<da...@westcontrol.removethisbit.com> wrote: >>>> choices here. Linux is never "hard" real time, but it can certainly be >>>> pretty "solid" real time and good enough for uses like this. In >>> >>> well, actually you can use some patch to make linux hard real time. >>> For example Linux-RTAI<https://www.rtai.org/> >>> > > There are a few systems that let you use Linux in a hard real time > system. But they are, in a sense, a cheat - they work by using an > independent hard real time OS on the bottom, and running Linux as a > low-priority task on the RTOS. > > The normal Linux RT options (such as kernel preemption) are good enough > for most uses - if you need something with tigher control you are > usually best with a separate microcontroller for the critical stuff. > >> >> usb will always have a latency of atleast 1ms, thats the frame rate. >> >> must be possible doing hard realtime in windows too, cnc programs like >> mach3 >> does 10s of kHz on the parallelport >> > > No, that is not hard realtime. You can do sort-of real time on Windows, > and there are third-party extensions that make it a bit better (though > never "hard"). Remember, there is a big difference between "running > fast" and "realtime". Yes, you can run the parallel port fast on Windows > (or Linux) - but you can't guarantee that it will /always/ run fast. > Sometimes the program will be delayed unexpectedly - hence it is not > real time.There are several real-time extensions for Windows (like INtime) that are basically RTOSes running Windows (or Linux) basically as a low priority process. I've been involved with some projects that used those extensions. The real problem is not so much the software, but the PC hardware. On one PC you get very predicable timing, on another it is all over the place, even when the RTOS is assigned its own core and hardware resources. In modern PC's there are a lot things the affect the response time (power management features, shared busses, busmaster DMA, caches...etc), some you can control others you can't or don't even really know about. 15 years a ago on a project we used an home-brew embedded board clocked at 15MHz with a home-brew OS. We understood the hardware and the processor very well (because it was so simple) and could guarantee response times within a few cycles. On that board we ran applications with hard real-time requirements that even on todays PC's with hundreds of times more processing power difficult if not impossible to do, simply because it is hard, if not impossible, to guarantee response times in the uS range on an arbitrary PC platform, regardless what software you use. As systems become more complex it becomes exceedingly more difficult to give hard guarantees.
Reply by ●January 23, 20122012-01-23
On Sat, 21 Jan 2012 13:47:29 +0800, Bruce Varley wrote:> "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote in message > news:eJWdnVI5BJIYVIXSnZ2dnUVZ_qidnZ2d@giganews.com... >> >I've been implementing custom devices for stage music use for several >> years, >>>using small SBCs that run a basic RTOS that I code up myself. The input >> and >>>output is MIDI, coded music tokens (not digitised audio) at a serial >>>data >> >>>rate of 31.25 KB. Even with the maximum amount of processing involved, >>>latency time between receipt of a byte and its associated transmission >>>was >> >>>never more than a millisecond or so. >>> >>>The main limitation has been HMI, for that reason I'm looking at moving >>>to >> a >>>SBC that can support USB so that I can connect to a tablet or palm >>>device. >> >>>What I'm finding is that boards that support the sort of interfaces >>>that will talk to eg. a tablet, are often really slow in comparison. >>>Based on information I've managed to glean, many of these systems are >>>likely to introduce throughput delays of 30mS or longer, even for a >>>2-line program loop read char/send char.That's getting to be too long >>>for music. >>> >>>The OS involved, usually Linux, is one contributor, random processing >>>holdups of > 10mS for system housekeeping are cited. One system I >>>checked >> >>>out doesn't use interrupts for the serial ports that MIDI uses, it just >>>polls them at about 100 Hz, adding another potentially 20mS to the >>>round trip. >>> >>>What I'm after is a small SBC that has reasonable support for USB >>>comms, >> and >>>also can guarantee turnround of only a few mS for low level I/O such as >>>serial comms. Does anyone have any suggestions? TIA >>> >>> >>> >>> >> Could you explain a bit more about your HIM implementation and how is >> your SBC hardware? In general you can set the priority of your music >> process to >> maximum, and the HIM managin to your left time. In general, you can set >> some sort of DMA to always transfer your image buffer to the display. >> So all you got do is uptdate your display buffer at RAM. The user >> inputs would >> be handled by a interrupt, but just effectively processed when you got >> time >> left. I belive that is the most common implementation. >> >> Cya >> >> --------------------------------------- Posted through >> http://www.EmbeddedRelated.com > > Thanks for the information, everyone, it's very useful. I've already > purchased hardware that I thought would serve, only to find that timing > issues have probably invalidated its use. As per the request/suggestion > above, here'a bit more info on the situation. > > My envisaged config will have two components, a 'client' which will be a > SBC, and a 'Master', which will be a tablet. The musical signals that > need controlled latency will come into the client via a UART, and leave > the same way. The client does some fairly rudimentary processing, such > as as interspersing control sequences. > > The USB is purely for communication between the client and the master > tablet, things like selecting instrumentation and manual stop/starts. > None of the information passing between these is particularly time > critical. My concern is delays that (reportedly) can occur from UART > input to UART output within the client, running Linux. > > Why am I considering USB at all? Because AFAIAA, tablets don't come with > any alternative interfaces that will easily connect to a SBC micro. > > Thanks again to everyone who took the time to input.So the master talks to the client via USB, and the client talks to some unnamed device via UART? You could go with a plain-vanilla SBC without on-board USB, and use a serial-to-USB converter. This will save you from delay problems on the client side -- but as most tablet PCs either run Android (which is Linux), or Windows (which is a horror), you're right back to the same worries about delay. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
