Simple memory card player idea

[Karen O]

My attention has turned to Compact Flash. These have an IDE/parallel ATA interface which just looks like eight eight-bit registers. And they can handle up to 20Mbyte/sec apparently.

[Kat Manton]

The thread title includes the word "player"; so I am not thinking analogue input is required.

Using an SD card (or similar) makes getting the data onto it simple. Plug it into a USB card reader/writer, then write to it. Very easy with Linux.

Devices (including mass-storage devices and partitions on them) appear as files under /dev.

E.g., if you already have one hard drive, that'd appear as /dev/sda. Partitions on it appear as /dev/sda1, /dev/sda2 etc.

So an SD card in an attached USB reader/writer would (probably) appear as /dev/sdb.

Normally you'd partition it (creating one partition, /dev/sdb1), then format the partition, mount it to some mount-point (say, /mnt/sdcard) then stuff files on it.

But there's nothing stopping you opening /dev/sdb in a C (etc.) program then writing to it directly. No partitions, no filesystem; data can be written exactly how your player hardware requires it. (It's nice when an OS doesn't prevent you doing whatever you want to!)

So if I were you, I'd stick with some kind of memory card which can be plugged into a PC via an adapter or USB device; just FFmpeg and a simple little program would get video data onto the card without designing/building yet more hardware.

Just my two penn'orth...

Kat

[ppppenguin]

Kat has put this very well. I am not very software orientated so I bow to her knowledge of how to make Linux do lots of useful things. Reading out video from a flash card without a filing system should be very easy indeed.

One approach is to store the data as literal waveforms, complete with blanking and sync. Then the readout mechanism is little more than a counter. This is wasteful of memory space so just storing active video means that you have to generate sync and blanking in the CPLD or FPGA. I say CPLD because this is well within range of a CPLD such as the Coolrunner series. An inexpensive DAC and you've got a video output.

There is the question of the filter after the DAC. Without oversampling the filter gets very hairy if you want a nice frequency and phase response. It's entirely possible to do oversampling in a FPGA. I've done it to a very high standard though that needs a lot of logic, mainly multipliers, to make the FIR. More modest arrangements can give very good results though multipliers are still needed which means FPGA rather than CPLD.

[Karen O]

Kat, that is exactly what I planned to do!

I feel lucky that my first major development was on a Unix clone back in the early eighties. That inoculated me against all the MS nonesense that came later. I remember having to reload a machine that had no memory management - when someone brought it down it was usually because a null pointer caused them to overwrite the interrupt vectors (if it stayed up, you could see strings on them in /dev/kmem!)

Anyway, I reminisce.

Kat, your reputation precedes you. I've known for some time you are 'the girl that got 405 lines out of a Linux PC'! I am suitably in awe

[Kat Manton]

Hi,

Ah, that's cool

You'll be quite happy at the command line typing cryptic streams of stuff with zillions of options which looks like line noise, know what pipes are and know that if you think you should be able to do it, you probably can (even if it breaks your system very badly...)

I just had a quick look at FFmpeg; it lists 'rawvideo' as an input and output format. So I reckon FFmpeg should be able to take a file containing video in pretty much any format, decode/crop/scale, convert to greyscale and write it straight to a memory card. If, say, 512 or 1024 bytes per line makes the player hardware easier; no problem. (I've spent some time making FFmpeg jump through hoops...)

Oh, and thanks! Though you really shouldn't be in awe; Unix (well, the X Window System) has been capable of being configured for fixed-rate monitors for as long as it existed. I've had a few (they were cheap because they were a PITA to use with Windows.) All I did was realise a 405-line telly could be seen as a fixed-rate monitor...

Anyway... it looks like getting raw video data onto some sort of memory card in whatever arrangement the player hardware requires is achievable without much effort and possibly without writing a line of code...

I might have a play around with that...

Kat

Microchip do demo code for an SD card, fits directly onto an Explorer 16, and they do interface caeds for all sorts of things. Farnell stock them, a couple of hundred quid and you have a full system ready for hacking.

[tubesrule]

Originally Posted by ppppenguin

I would recommend a Spartan 3A unless you have a specific reason to use 3E. The 3A emerged as the mainstream series ahead of the 3E which I think of as a bit of a backwater. I know the Aurora uses a 3E but not sure Darryl would recommend it for a new design either. Actually all the Spartan 3 stuff has recently been taken off the main "recommended for new designs" list. Spartan 6 now seems to the main low cost series but I would have no worries about using 3A for quite a while yet.

This sounds like an interesting project, and would be a useful device when finished.

The main difference between the Spartan 3E and 3A is the 3E is targeted for designs that require more logic with a moderate amount of I/O while the 3A is for more I/O intensive designs. Because of the dual ring I/O in the 3A, there are other differences that need to be considered in the design like the removal of input protection diodes for most standards.

The Spartan 6 is certainly recommended for any new designs, and while its capabilities far exceed those of the Spartan 3, there is only one leaded package available for the Spartan 6 with everything else being leadless. This sort of precludes the possibility of soldering them at home.

Xilinx is wonderful at not obsoleting parts for many years, so there is no fear in choosing a Spartan 3 for this project. Any part in this family would be more than capable of reading a raw video stream from a flash card and formatting it if necessary. Since Kat pointed out that FFMpeg would be a good choice to get the data onto the flash card, you may want to go with a larger fpga and take a stab at doing decompression in the fpga for one of the compressed formats FFMpeg supports. This would certainly be a substantial project on its own, but could allow for hours of video on a single flash card. Then you could add fast forward and review buttons, and lots of other goodies.

Darryl

[neon indicator]

Unless you are going into Production, the Spartan3E starter board is a good idea. It often comes with a free SD card reader. There is a a simple mod to increase the colours on the VGA out. The R, G and B can be weighted as 2, 4 and 1 into a resistor based "DAC" on the add-on modulator (which is simple).

There is a video capture add-on available.
http://www.wattystuff.net/electronic...starter-board/

Most of the tutorials use Spartan 3E.

Advanced use to simulate Arcade Video and Amiga etc http://www.fpgaarcade.com/


Here is optional video board so you can add to your USB/Ethernet/SD Card player the ability to be an Aurora
http://www.digilentinc.com/Products/...cfm?Prod=VDEC1

This is the board I have:
http://www.digilentinc.com/Products/...&Prod=S3EBOARD

I bought it in Germany, much cheaper than the Digilentic site even though they make it.

I bought it to explore "stand alone" Software Defined Radio. I use Scilab SW (free) to help calculate DSP coeficients and I did a little Scilab script to make a file in format for the free Xilinx tools.

You can in theory even implement the audio and video modulated carriers direct on the FPGA, but a discrete analogue one is easy. I think the possible performance is such that the Spartan 3E can do up to 1920x1080@60fps progressive, in 10bit RGB.

The Starter Board has 64 MByte (512 Mbit) of DDR SDRAM, x16 data interface, 100+ MHz speed on board and most of the space of a Coolrunner CLPD.

It's not what I would choose for a PRODUCT, but I still think a good choice to develop or do a one off.

You can also get small ready made PCB with a Spartan 3E ready mounted, but there is complex PSU and lots of other HW. Still, it's a route to go to do 10 or so.

The SD card adaptor plugs in here http://www.wattystuff.net/electronic...ption-headers/
(it's often included free, and is simply a connector adaptor)

[pitbuell94]

Hi Karen O,

If you have some interest to make some tests, I have some brand new S29AL016D90.

It's Flash Memory about 16Mb running at 3V.

Just give me your adress.

Frédéric Cabanes.

[Karen O]

Frédéric,

That is a lovely offer but I'm going to direct my efforts at compact flash for the moment. Probably won't be fast enough but you gotta try.

Many thanks,
KarenO

[Kat Manton]

Hi,

This has set me off thinking about a variation of the idea, which wouldn't require data to be read from the card at a high rate (or audio.) I can already watch off-air and recorded Freeview, DVDs, etc. with the MythTV system so I don't really need another player.

What I'm thinking about amounts to a CF card 405-line "slide projector". (At the NVCF in 2006 I lost count of how many times I explained the Linux/MythTV system; having a 405-line TV sitting there sequencing through still images of text, diagrams etc. would've been handy!)

I also never really got into these new-fangled FPGA etc. things. They have too many legs. I know where I am with large bits of Veroboard full of CMOS...

Kat

[Kat Manton]

Linux discussion split off to this thread.

[dominicbeesley]

I'm quite interested in the idea of reading a raw stream of bytes from a card at a fairly high rate (say 10Ms/s) and just putting it straight out with no processing other than some oversampling and filtering. Then we could muck around with any formats we like!

I've got from brianc what we think is an NIR or ART video decoder, it would be great if I could mess around making some signals in software to test it out!

I've already done this kind of thing with "narrow bandwidth" television with up to 128 lines using PC soundcards but something with a bit more bandwidth would be brilliant...

Dom

[Karen O]

Hi Dominic,

I am gathering together parts to attempt to generate a TV signal in exactly the way you describe - straight out of the memory and into a video DAC.

I found a (possibly old) copy of the CF spec on the web (which I'm pleased about - the CFA charges $100!) It suggests that reading at around 6 Mbytes/sec as a byte stream is just possible which is good because the 405 line square pixel clock is around that frequency.

I plan to read my CF card in 8 bit PC mode which is frankly not a lot different to IDE mode. That means I can probably modify a CF-IDE adapter and take the eye strain out of the task. My eyes simply aren't good enough for those ridiculous lead pitches any more.

My plan is to get a PIC generating the sync pulses and timing the transfers from card to DAC latch. The PIC is nowhere near fast enough to handle a 6MHz byte stream but it doesn't need to - it just produces read pulses at that rate.

The PIC can talk to the card (slowly) during the frame blanking period and hopefully set up a multi-sector transfer command. Then, when it gets to the active picture lines, it can clock the bytes out. Conveniently, a sector (512 bytes) is conveniently around one scan line (512 bytes @6MHz is 85usec)

I will pre-load the first sectors of my CF card with an image using my Ubuntu machine.

I don't know if it will work but if it doesn't, I won't have invested much.

[dominicbeesley]

Let me know how you get on, I'm still quite interested in doing something like this but just clocking everything out of the card sync pulses, blanks and all so I can play around with close captioning, teletext and "odd" formats.

I'm half tempted to have a go with my FPGA board again but I kind of lost interest last time as getting all the stupid compilers and tools to talk to each other seemed more trouble than it was worth...I finally made a few LEDs blink and got some odd noises out of the speakers but it took me a whole weekend to get working, then the tools broke.

Have you tried any of the newer PIC stuff?

Dom

[neon indicator]

What will do the transfer? An CF-IDE adaptor is just a port. So effectively is the CF card. They need something else. Since you can read 8 bits at a time you can gate DAC direct to the IDE adaptor. If you use use RAW (i.e. just sequential bytes in CF card) then I suppose you could actually use PIC 18F if you can do it in one or two instruction per IDE to DAC direct latch. A 374 octal latch between DAC and IDE connector data lines.

I'd use an PIC18F4550 programmed with JAL V2 (12 MIPs )

Or is there a command where you can simply gate a with a S/R latch clock at 5,103,000 Hz to IDE R/W line and it auto increments. have a 504 counter that then resets the gate and interrupts PIC. Line Sync period enough to set up next transfer?

Clock with 512 pixels per line is 5,184,000 I think.. maybe do 512 bytes per line?

AFAIK you need no modifications to an IDE -CF adaptor to do this.

[Karen O]

Hi Dominic,

No, I haven't looked at the newer PIC stuff. I'm saving my next self education exercise for the Texas C2000 DSPs. They're a bit like the C2x and C5x parts I used about twenty years ago but I still expect it to be a shock. I'm overdue with this - I have let a client down terribly.

Hi Neon Indicator (sorry, I don't know your name),

I plan to transfer bytes from the CF adapter to the latch by having the PIC generate a 6MHz waveform (there are ways and means of doing that . The card will see its read clock cycling and feed bytes out on its data lines. An 8 bit latch will then acquire each byte on the rising edge of this clock. The PIC just arranges that the address lines select the card's data register.

The timing looks okay to do this. My fear is that the CF will go AWOL on certain sector boundaries while it does an internal transfer. If that happens my approach will be scuppered!

[neon indicator]

Use a suitable crystal clock gated on/off by PIC

[ppppenguin]

The job seems to be just right for a CPLD. Amply fast, plenty of resources for a job like this. you can get inexspensive evaluation kits for the Xilinx coolrunner parts (around £30 I thhink).

[delaitt]

Are the Altera FPGA development boards any good as an alternative to the Xilinx Spartan 3E/3A ?

Thierry.