Well, for completely software-controlled timing, I don’t think it will meet your requirements of the
10 us jitter. If you put a buffer on it, and have the ADC sample and trigger an interrupt, then it might
work. Possibly a counter/timer could be used for the ADC trigger and interrupt. Part of the problem is slow context switches and the requirement for cache purging on the ARM CPUs. This is all from anecdotal reports and not measurements I have made personally, but I have been investigating RT performance on several ARM platforms for a motion control project. What little data I have scraped together doesn’t look very good.
embedded/real time/hardware newbie here. I have an requirement to read an ADC, perform some simple FP calculations and write to DAC. It needs to be at least 20KHz but importantly the latency on the DAC/ADC needs to less than 10us. Low jitter is also important. Is the beaglebone up to it? I see this asked many times but not answered so I am not really expecting an answer now
Hi Evan,
This won’t be possible with Linux. Reading in ADC samples at 20KHz is no problem and you can use DMA to store samples into a buffer. The same is true for sending samples to a DAC if you are using DMA with a buffer. If you could batch process the samples in the input buffer and write the results to an output buffer, the Beaglebone would perform fine. However, if you want to send DAC sample 10uS after receiving a corresponding ADC sample, this would not be possible. If you want to do that, then I suggest using StarterWare which you can download from here http://www.ti.com/tool/starterware-sitara
Regards,
John
I have two specific questions
This might be naive but I thought I would try the PREEMPT_RT patch. In particular, I wanted to combine it with Robert Nelson’s patches and build process. After many hours of random git commands, patch and modifying scripts I came to the conclusion that the current PREEMPT_RT patch is for 3.4 whereas Robert’s patches are for 3.6. Firstly, does it even make sense to try PREEMPT_RT on BB? If so, what is the best way to proceed? Use 3.4 versions of Robert’s patches and risk bugs and missing features? Wait for PREEMPT_RT patch against 3.6?
What is the best way to do low latency (<10us) 14bit ADC and DAC on the BB? I assume it would have to be over the SPI bus, but beyond that I’m clueless. If someone can point me in the right direction I would really appreciate it.
Thanks,
Evan.
Well, for completely software-controlled timing, I don’t think it will meet your requirements of the
10 us jitter. If you put a buffer on it, and have the ADC sample and trigger an interrupt, then it might
work. Possibly a counter/timer could be used for the ADC trigger and interrupt. Part of the problem is slow context switches and the requirement for cache purging on the ARM CPUs. This is all from anecdotal reports and not measurements I have made personally, but I have been investigating RT performance on several ARM platforms for a motion control project. What little data I have scraped together doesn’t look very good.
I'll have a look at starter ware. Was hoping for a nice friendly linux environment. When you say not possible on Linux do you mean Linux on bone or Linux on general? Should I consider another platform? I started with a bone because it is cheap and nice tool for learning, but I am not wedded to it.
I’ll have a look at starter ware. Was hoping for a nice friendly linux environment. When you say not possible on Linux do you mean Linux on bone or Linux on general? Should I consider another platform? I started with a bone because it is cheap and nice tool for learning, but I am not wedded to it.
Hi Evan,
There are blocks of code in Linux that disable interrupts and hence the responsiveness of Linux is not deterministic. There are real-time extensions for the Linux Kernel that break up these large blocks of code and this makes Linux more deterministic, but you have to know what you are doing to make this work. Another approach is to use a processor like the one on the Beagle-xM or PandaBoard which have an ARM and DSP processor. On the DSP processor, you use SysBios real-time OS and SysLink for communications between Linux and the DSP. Unfortunately, SysLink does not work with the latest Linux Kernels (currently only supports 2.6.32). There is new work in the Linux Kernel v3.4 where SysLink is replaced with RPMSG (SysLInk3) but currently there is only support for OMAP4. RPMSG also enables the support of virtual I/O. There is work being done on RPMSG to add support for OMAP3 and OMAPL138.
BTW, there is nothing friendly about Linux. It is a beast and the learning curve is long and difficult. That said, Linux is very powerful and can be fun once you know what you are doing.
My guess is that StarterWare is probably your most simple solution and the easiest way to get something up and working quickly.
