3 Nov
2013
3 Nov
'13
5:30 a.m.
On Nov 3, 2013, at 6:06, "Robert Jarratt" <robert.jarratt at ntlworld.com>
wrote:
The new batch of SoC FPGAs from Alter and Xilinx are really quite
compelling, and I have a few projects in mind for them if I ever get the
time and money. You don't need the performance they give you for
this, though; it's like putting a Mustang engine in a golf cart.
I would recommend a small FPGA coupled with a small micro that
has a parallel bus available (or very fast SPI). You can push the
cylinder data to the FPGA for replay during your "seek" time and write out
the contents of the current track at the start of the seek time (a very
simple write-back cache). I'd recommend the STM32F4DISCOVERY
board, because it's cheap and I'm rather fond of it, but it doesn't
have an SD connector. There are lots of third-party breakout boards
you could use to attach one, e.g. from AdaFruit or SparkFun.
Add a DE0-Nano for the FPGA and you're set.
As you mentioned, you'll need a level converter because no one speaks
5v anymore. That's also pretty easy to overcome; try some of the '244
and '245 variants from the 74LVC family. They're very cheap.
- Dave
Yes, I was looking at this and I have to say it does
look promising. I then
realised that I already have a Raspberry Pi, so I had a quick go at some
bare metal programming on it, but the sampling rate I got on the GPIO pins
was woeful. I wrote a program just to turn one of the GPIO pins on and off
as fast as possible, but only seemed to get a pulse period of 6ms, which is
5 or 6 orders of magnitude too slow. At that rate even if I use a shift
register externally it would be way too slow. I could have been doing
something wrong, has anyone else ever tried this?
Well, running through Linux's GPIO layer is going to be pretty slow.
Linux in General is MASSIVE overkill for this, and I think directly
manipulating GPIO in general (even on bare metal) is going to be
problematic and slow. With a fast enough CPU (or at least some
good DMA magic), you might be able to make SPI do the trick.
I wonder if bare metal access to GPIO on the
beaglebone would be any better
than the Raspberry Pi? I have had a quick look at the docs and I can't find
anything about the speed of GPIO. I found one post which suggests you can
achieve 1.5MHz
(http://www.supermicros.org/1/post/2013/07/beaglebone-gpio-musings.html). If
that is right then a shift register would be needed, but wider than 8 bits I
think.
GPIO in general is probably going to be too slow. I'd definitely
recommend some sort of shift register, whether it's SPI or something
in external custom logic. GPIO should be fine for control pins.
The beaglebone SPI support looks like it might be an
alternative. Although I
am not clear how fast this can go and whether I could get the timing to be
accurate enough. I would need to build some custom hardware that sends data
to/from the SPI interface on the beaglebone. That might not be too bad, but
I don't really know what is involved at the moment, probably an FPGA to make
prototyping easy.
Well, SPI is just a shift register, and you have a rich set of PLLs on
modern micros to drive the clocking. You might not have enough flex
in the divider ratios to make the timing exact with the crystals
on the board, but I'm not familiar enough with the drives in question
to say what that would require. My assumption, since MFM is self-
clocking, is that you don't need an exact frequency so much as a
consistent, low-jitter clock. Is that correct?
I have not written a driver before, that is a
possibility but I feel that
bare metal is probably the way to go.
I agree. Linux adds a ridiculous amount of overhead to this. It
does, of course, give you a software base with a file system and
drivers for things like the SD card, but you're still killing flies with
orbital bombardment.
If you want a
FPGA consider the ZedBoard. It is much more expensive
(starting at 199 US$) but will give you a dual core Cortex-A9 and a FPGA
on
one chip.
http://www.zedboard.org/
That is too expensive :-(