3 Nov
2013
3 Nov
'13
5:36 a.m.
On Nov 3, 2013, at 8:10, Jochen Kunz <jkunz at unixag-kl.fh-kl.de> wrote:
Just using GPIOs is the wrong aproach anyway, IMHO. You really want
some hardware to preprocess the signals somewhat. Also keep in mind
that those ARM SOCs as used on the RPi or Beaglebone Black have some
rather sophisticated DMA capable SPI, PWM, ... peripherals. You did
somthing wrong when you didn't get faster then 6 ms.
It was probably due to the overhead of the Linux GPIO layer.
BTW: Microchip has some PICs with a build in
"Configurable Logic Cell".
AFAIK that is somthing similar to a GAL / CPLD. Probably enough to do
the (de)serializing of the bitstream. Then the PIC could hand over the
data via some DMA capable interface to a Beaglebone Black that cares
about storing it on its SD card...
I think the biggest advantage of an FPGA/CPLD handling the bit
stream is in handling any write precomp effects. That's an example
of something that's really unpleasant to do in software, but trivial to do
at a bit-serial level in hardware.
I wouldn't try to decode much in hardware, since there are a number
of different encoding schemes (IIRC). Storing the raw bitstream (possibly
after undoing write precomp) is probably a good way to go.
- Dave