Hi David and Werner, Thanks for your suggestions.
The current system is composed of a small SPI ADC board + 6410 EVB, with a qt4 GUI in qt-extended4.4.3 environment. The ADC is connected to the SPI bus of 6410 and I wrote a very simple and naive driver for demostration, because I mainly focused on the GUI curve plot part before. Therefore it is a good news that NN could support qt4.7, and it should work for the GUI part. When it comes to the driver part, it is much more complicated for me, because I do not have too much experience on this before. Luckily, the system requirement is not very sensitive to high-speed and jitter, and 5Ksamples/sec and even less would be quite enough. Meanwhile, we are more interested in multi-channel implementation. Therefore, the UBB or SPI controller will be both OK, and of course if we finally decide to design a new board for this, we may use SPI bus for safety. But, currently, I am wondering whether I could quickly write a very simple SPI ADC driver demo based on UBB without considering too much about the jitter, rate, etc, and a very low speed at user space will also be OK. Any hints or reference on this will be welcome. Thanks. 2011/4/9 Werner Almesberger <[email protected]> > Jianming Liu wrote: > > I am writing to query about whether it is possible to use UBB to extend a > > SPI ADC (ads8341), because currently I am designing a data collection > system > > using a SPI ADC ads8341 based on S3C6410. > > That should work, yes. One question is what sampling rate you need > and how much delay and jitter your samples tolerate. UBB is > bit-banged, so your maximum data rate is limited to something like > 1 Mbps (or ~30 kSa/s), at 100% CPU utilization. > > The jitter depends on your trigger. Would you do periodic sampling, > have a trigger signal, or would your program decide when it's time > on its own ? For anything that uses a timer/external trigger, you > need to consider the Ben's interrupt latency. > > Delay depends on latency plus how quickly you need to retrieve the > sample. In the best case, if you have interrupt-driven operation, > you'd first retrieve the previous sample and only then start the > next acquisition and conversion. That way, you only need one > interrupt per sample. > > > I am considering whether it is > > possible use the UBB and JZ47xx instead for this. > > If "JZ47xx" means that you'll design your own board, then you could > use the SPI controller and thus wouldn't have to worry about > bit-banging. You'd still have to think about the other timing > issues, though (like you would with any other processor). > > > How to implement the driver for this under Linux, > > That again depends on your requirements ;-) If they're modest > enough, even a user-space implementation might do. > > Ben+UBB with a user-space driver may also be handy for prototyping. > > - Werner > > _______________________________________________ > Qi Hardware Discussion List > Mail to list (members only): [email protected] > Subscribe or Unsubscribe: > http://lists.en.qi-hardware.com/mailman/listinfo/discussion >
_______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
