Senior Project: PCI Digital Video Recorder

NTDEV
1

G’day to all y’all,

My name is Eric Bowden, and I’m basically in charge of writing the PCI Interface for my team’s Computer Engineering senior project.  The goal is to design and fabricate a PCI digital video recorder (DVR) (think TiVo) where the card is in charge of digital/analog encoding/decoding and frame buffering, and the host is in charge of storing the data and performing time shifting operations (like pause, rewind, etc.). 

I have no experience with PCI, but am really excited to learn about it.  To this end, I was wondering if osronline’s 9054 DMA Learning kit would be a good investment.  If my understanding of DMA (in a PCI context) is correct, this would be useful in learning how a host application may push frames of data (frames) directly to the PCI card’s memory, where they may be buffered and then analog-ized for TV-viewing.  Yes, it’s kinda general, but as I become more familiar with PCI’s capabilities, I can hone the design into something concrete.

So, back to the question, would the DMA learning kit be a worthwhile purchase, or is the current PCI learning kit (Sealevel Digital I/O) sufficient.  Perhaps someone knows of other good resources … ?  I could purchase the Rapid Development Kit from PLX for their 9054 PCI I/O Accelerator, but starving-student considerations make this highly unlikey.  I look forward to plumbing the depths of collective knowledge in this forum as I get rolling!  :slight_smile:

Thanks,

Eric Bowden




2

Israphæl Ðaishí wrote:

G’day to all y’all,

My name is Eric Bowden, and I’m basically in charge of writing the PCI
Interface for my team’s Computer Engineering senior project. The goal
is to design and fabricate a PCI digital video recorder (DVR) (think
TiVo) where the card is in charge of digital/analog encoding/decoding
and frame buffering, and the host is in charge of storing the data and
performing time shifting operations (like pause, rewind, etc.).

Microsoft calls this “Windows XP Media Center Edition”. If you provide
a tuner and capture card, the rest of it is provided for you.

Do you expect to design a tuner/capture/encoder board, or is this a
purely software project where you will integrate off-the-shelf
hardware? Do you have a system diagram planned out yet? Do you plan to
use DirectShow for the transport? Do you have people who know Windows
drivers?

I have no experience with PCI, but am really excited to learn about
it. To this end, I was wondering if osronline’s 9054 DMA Learning kit
would be a good investment. If my understanding of DMA (in a PCI
context) is correct, this would be useful in learning how a host
application may push frames of data (frames) directly to the PCI
card’s memory, where they may be buffered and then analog-ized for
TV-viewing.

If you use a standard graphics card for the conversion to television,
and a standard audio device for the sound, your job will be much
easier. The standard DirectShow functionality doesn’t make it
particularly easy to have a custom rendering device.

By the way, in DMA, the host application doesn’t “push” data to a PCI
card. Instead, the PCI card “pulls” the data into its memory. It’s
called “bus mastering”, because the PCI device temporarily becomes the
“master” of the bus.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Eric,

I commend you for stating up front that you are a student. So if I’m
understanding your Senior Project, you are trying reinvent Windows Media
Center? OK, sounds like it could be fun. Do I understand correctly that
your video input is on the PCI card, and that does the A-D conversion of
captured frames, and then the D-A conversion when it’s sent back to the
display? Are you using an existing TV board, or did your team design one?

Do you understand the basics of DMA (Direct Memory Access)? The host
application doesn’t “push frames directly to the PCI card’s memory”. The
PCI device reads from and writes to host memory without any intervention
from the host processor, once the DMA is setup properly. You would setup
the transfer on the PCI device and start it, then go on with whatever
other processing you need to do until the device interrupts. When the
interrupt happens, you start the next DMA transaction or idle the device.
In your particular case, one DMA transaction describes some fractional
part of a frame, where that fraction can be anywhere from 1/N to N/1
frames, depending on the frame size and your hardware’s DMA limits.

I don’t have the OSR PCI learning kit, but I do have the OSR FX2 USB kit,
and it’s a good kit, so I expect that you will be pleased with it. While
you are still trying to make up your mind about it, if you haven’t
already, download the KMDF 1.1 from Microsoft, it has the latest
production DDK (Windows Server 2003 SP1, AKA 3790.1830) included, so you
are out $0 for it.

Look at the WDF samples, especially follow the step-wise refinement in the
osrusbfx2 sample. It won’t teach you about PCI DMA directly, but it will
give you a better understanding of how to assemble whatever driver you
decide you need?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Israph?l ?aish?
Sent: Friday, May 19, 2006 12:04 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Senior Project: PCI Digital Video Recorder

G’day to all y’all,

My name is Eric Bowden, and I’m basically in charge of writing the PCI
Interface for my team’s Computer Engineering senior project. The goal is
to design and fabricate a PCI digital video recorder (DVR) (think TiVo)
where the card is in charge of digital/analog encoding/decoding and frame
buffering, and the host is in charge of storing the data and performing
time shifting operations (like pause, rewind, etc.).

I have no experience with PCI, but am really excited to learn about it.
To this end, I was wondering if osronline’s 9054 DMA Learning kit would be
a good investment. If my understanding of DMA (in a PCI context) is
correct, this would be useful in learning how a host application may push
frames of data (frames) directly to the PCI card’s memory, where they may
be buffered and then analog-ized for TV-viewing. Yes, it’s kinda general,
but as I become more familiar with PCI’s capabilities, I can hone the
design into something concrete.

So, back to the question, would the DMA learning kit be a worthwhile
purchase, or is the current PCI learning kit (Sealevel Digital I/O)
sufficient. Perhaps someone knows of other good resources … ? I could
purchase the Rapid Development Kit from PLX for their 9054 PCI I/O
Accelerator, but starving-student considerations make this highly unlikey.
I look forward to plumbing the depths of collective knowledge in this
forum as I get rolling! :slight_smile:

Thanks,

Eric Bowden

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Eric,

I’d just like to add that Peter Wieland’s blog has an amazing 9-part
entry on DMA:

http://blogs.msdn.com/peterwie/

Which should answer many of your questions.

Best regards,
Alex Ionescu

xxxxx@seagate.com wrote:

Eric,

I commend you for stating up front that you are a student. So if I’m
understanding your Senior Project, you are trying reinvent Windows Media
Center? OK, sounds like it could be fun. Do I understand correctly that
your video input is on the PCI card, and that does the A-D conversion of
captured frames, and then the D-A conversion when it’s sent back to the
display? Are you using an existing TV board, or did your team design one?

Do you understand the basics of DMA (Direct Memory Access)? The host
application doesn’t “push frames directly to the PCI card’s memory”. The
PCI device reads from and writes to host memory without any intervention
from the host processor, once the DMA is setup properly. You would setup
the transfer on the PCI device and start it, then go on with whatever
other processing you need to do until the device interrupts. When the
interrupt happens, you start the next DMA transaction or idle the device.
In your particular case, one DMA transaction describes some fractional
part of a frame, where that fraction can be anywhere from 1/N to N/1
frames, depending on the frame size and your hardware’s DMA limits.

I don’t have the OSR PCI learning kit, but I do have the OSR FX2 USB kit,
and it’s a good kit, so I expect that you will be pleased with it. While
you are still trying to make up your mind about it, if you haven’t
already, download the KMDF 1.1 from Microsoft, it has the latest
production DDK (Windows Server 2003 SP1, AKA 3790.1830) included, so you
are out $0 for it.

Look at the WDF samples, especially follow the step-wise refinement in the
osrusbfx2 sample. It won’t teach you about PCI DMA directly, but it will
give you a better understanding of how to assemble whatever driver you
decide you need?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Israphæl Ðaishí
Sent: Friday, May 19, 2006 12:04 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Senior Project: PCI Digital Video Recorder

G’day to all y’all,

My name is Eric Bowden, and I’m basically in charge of writing the PCI
Interface for my team’s Computer Engineering senior project. The goal is
to design and fabricate a PCI digital video recorder (DVR) (think TiVo)
where the card is in charge of digital/analog encoding/decoding and frame
buffering, and the host is in charge of storing the data and performing
time shifting operations (like pause, rewind, etc.).

I have no experience with PCI, but am really excited to learn about it.
To this end, I was wondering if osronline’s 9054 DMA Learning kit would be
a good investment. If my understanding of DMA (in a PCI context) is
correct, this would be useful in learning how a host application may push
frames of data (frames) directly to the PCI card’s memory, where they may
be buffered and then analog-ized for TV-viewing. Yes, it’s kinda general,
but as I become more familiar with PCI’s capabilities, I can hone the
design into something concrete.

So, back to the question, would the DMA learning kit be a worthwhile
purchase, or is the current PCI learning kit (Sealevel Digital I/O)
sufficient. Perhaps someone knows of other good resources … ? I could
purchase the Rapid Development Kit from PLX for their 9054 PCI I/O
Accelerator, but starving-student considerations make this highly unlikey.
I look forward to plumbing the depths of collective knowledge in this
forum as I get rolling! :slight_smile:

Thanks,

Eric Bowden

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Tim Roberts wrote:
> Microsoft calls this “Windows XP Media Center Edition”. If you provide

a tuner and capture card, the rest of it is provided for you.

Yup, we’re pretty much (re)inventing both the hardware (tuner/capture
card) and the software. (Although the software isn’t quite as ambitious.)

Do you expect to design a tuner/capture/encoder board, or is this a
purely software project where you will integrate off-the-shelf
hardware? Do you have a system diagram planned out yet?

Yes, in fact it is required. As part of a Computer Engineering project
we must have a significant hardware and software component. We have a
block diagram, but not any schematics (e.g. gerber files). Our
project’s progress is being hosted at
http://www.cs.utah.edu/~ebowden/omegacore/. If you have time, the
diagram you’re looking for is in the “Latest Proposal” link, just skim
through looking for pictures.

Do you plan to

use DirectShow for the transport?

Forgive my ignorance, but I don’t quite understand the question. We
plan on digitally encoding the NTSC analog television signal on the PCI
board into an MPEG2 digital signal. This digitized signal will be
stored on the host PC where the some software will store it. The user
interacts with this software (pause, fast-forward, rewind, etc.) in
order to determine what is sent back to the PCI card, where a
microcontroller will assemble the frames and serially ship them out to
the television. For the purposes of this project, the user interface
will be a GUI on the host PC – what we want to do, if we have time, is
have a simple Infrared Receiver (e.g. for remote control) and not have
the user need to look at a computer monitor. (i.e., re-invent a simpler
TiVO)

Do you have people who know Windows

drivers?

That’s my job XD I plan on using my summer vacation to become very
familiar with Windows drivers and PCI Interfacing.

By the way, in DMA, the host application doesn’t “push” data to a PCI
card. Instead, the PCI card “pulls” the data into its memory. It’s
called “bus mastering”, because the PCI device temporarily becomes the
“master” of the bus.

Myth #1: dispelled. Thanks, obviously I need to research this more.

Eric Bowden

6

xxxxx@seagate.com wrote:

Eric,

I commend you for stating up front that you are a student. So if I’m
understanding your Senior Project, you are trying reinvent Windows Media
Center?

I don’t own the Media Center Edition (unless you’re referring Media
Player [which I doubt]), but from other people’s comments, I’d gather
the answer is “sort of.” =) To be honest, we probably don’t need the
host PC, the only reason we’re using it is so we don’t have to interface
to a hard drive directly. The reason I want to do the project though,
is for the Media Center, that is to say, have the ability to watch TV on
the computer using some hand-crafted software, and managing the process
from start to finish. The billed purpose is build a TiVO; basically
have a black box that sits above the TV (the size of a computer tower
^_^) and allows the user to futz with live TV. (Thus, this card would
incidentally be to output to a television set, in my mind.)

OK, sounds like it could be fun.

That’s what we’re thinkin’!

Do I understand correctly

that your video input is on the PCI card, and that does the A-D
conversion of captured frames, and then the D-A conversion when it’s
sent back to the display?

Yup.

Are you using an existing TV board, or did

your team design one?

We have a preliminary design. We’re going to start fabricating this
summer just to test immediate encoding/decoding of the AV signal. The
PCI will be integrated in the second spin.

Do you understand the basics of DMA (Direct Memory Access)? The host
application doesn’t “push frames directly to the PCI card’s memory”.
The PCI device reads from and writes to host memory without any
intervention from the host processor, once the DMA is setup properly.
You would setup the transfer on the PCI device and start it, then go on
with whatever other processing you need to do until the device
interrupts. When the interrupt happens, you start the next DMA
transaction or idle the device. In your particular case, one DMA
transaction describes some fractional part of a frame, where that
fraction can be anywhere from 1/N to N/1 frames, depending on the frame
size and your hardware’s DMA limits.

Thank you, thank you – I needed that clarification! So let me puzzle
this out, out loud really quick. Assuming DMA is set up properly, the
device is initially started, or it notices that its output-to-TV buffer
is about to run dry (or a previous DMA finished) so it interrupts
saying, “hey host-PC, send me more TV!” At this point the host doesn’t
actually “send” anything (the whole DMA paradigm), the PCI device reads
some block of memory where the host-PC software has placed the beginning
of another group of frames. When the PCI device has cached these frames
in the output-to-TV buffer it will interrupt again – but should
probably wait like a good citizen to give other devices bus access.

Is my thinking straight here? So, in a nutshell, DMA will allow me to
define some chunk of memory that the PCI device can access (hopefully as
a burst) like a vampire and suck that data out, BUT!–the host PC
software can put the desired data in the same memory locale as well? I
hope my whole communication paradigm makes sense … for example, if a
user hits pause, then I want the host PC to only provide the same frame
over and over again, and I want the PCI microcontroller to pick up those
frames.

I don’t have the OSR PCI learning kit, but I do have the OSR FX2 USB
kit, and it’s a good kit, so I expect that you will be pleased with it.
While you are still trying to make up your mind about it, if you haven’t
already, download the KMDF 1.1 from Microsoft, it has the latest
production DDK (Windows Server 2003 SP1, AKA 3790.1830) included, so you
are out $0 for it.

Will do!

Look at the WDF samples, especially follow the step-wise refinement in
the osrusbfx2 sample. It won’t teach you about PCI DMA directly, but it
will give you a better understanding of how to assemble whatever driver
you decide you need?

I’ll stick it in my queue – thank you much!

Eric Bowden

7

Alex Ionescu [397670] wrote:

Eric,

I’d just like to add that Peter Wieland’s blog has an amazing 9-part
entry on DMA:

http://blogs.msdn.com/peterwie/

Which should answer many of your questions.

I am much obliged, thank you for the information!

Eric

8

Eric Bowden wrote:

Tim Roberts wrote:
> Microsoft calls this “Windows XP Media Center Edition”. If you provide

> a tuner and capture card, the rest of it is provided for you.

Yup, we’re pretty much (re)inventing both the hardware (tuner/capture
card) and the software. (Although the software isn’t quite as
ambitious.)

Hmmm, that’s what YOU think.

> Do you plan to use DirectShow for the transport?

Forgive my ignorance, but I don’t quite understand the question. We
plan on digitally encoding the NTSC analog television signal on the
PCI board into an MPEG2 digital signal. This digitized signal will be
stored on the host PC where the some software will store it. The user
interacts with this software (pause, fast-forward, rewind, etc.) in
order to determine what is sent back to the PCI card, where a
microcontroller will assemble the frames and serially ship them out to
the television. For the purposes of this project, the user interface
will be a GUI on the host PC – what we want to do, if we have time,
is have a simple Infrared Receiver (e.g. for remote control) and not
have the user need to look at a computer monitor. (i.e., re-invent a
simpler TiVO)

Do you plan on relying on ANY operating system services to do this, or
are you going to create every single piece of software yourselves,
including the MPEG encoding and decoding, tuning (US only?), fine
tuning, volume controls, closed captioning, packet timing, A/V sync,
buffer allocation, error handling, etc. etc. etc.?

In the normal Windows world, your application would create one or more
DirectShow graphs to manage the data flow. That way, you can leverage
off of the many good MPEG encoders and decoders in the world today. It
also handles packet timestamps, color space transformations, A/V
synchronization, FF, REW, etc. You write a tuner, capture, and crossbar
driver to talk to your hardware, which exposes the standard AVStream
interface. This allows those drivers to participate in the DirectShow
filter graph as well.

If you don’t plan to use a framework like DirectShow, then your software
task is VASTLY greater than your hardware task. All of the tuner
vendors, TV decoder chip vendors, and MPEG chip vendors have reference
designs you can download. There’s very little innovation required on
the hardware side. You’re mostly plugging together well-understood
components.

That’s my job XD I plan on using my summer vacation to become very
familiar with Windows drivers and PCI Interfacing.

Interfacing with PCI is trivial. There are sample drivers covering all
of the PnP stuff, and even basic DMA. The much harder part is designing
an appropriate application interface, especially if you are rolling your
own.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, May 19, 2006 3:23 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Senior Project: PCI Digital Video Recorder

Thank you, thank you – I needed that clarification! So let
me puzzle
this out, out loud really quick. Assuming DMA is set up
properly, the
device is initially started, or it notices that its
output-to-TV buffer
is about to run dry (or a previous DMA finished) so it interrupts
saying, “hey host-PC, send me more TV!” At this point the
host doesn’t
actually “send” anything (the whole DMA paradigm), the PCI
device reads
some block of memory where the host-PC software has placed
the beginning
of another group of frames. When the PCI device has cached
these frames
in the output-to-TV buffer it will interrupt again – but should
probably wait like a good citizen to give other devices bus access.

No, you don’t drive stuff from the hardware, you drive it from the host
app. In the case of a “TiVo”, you have to keep the hardware supplied with
DMA-ready transactions, which means that you have the buffers ready to DMA
(locked in memory, LogicalAddress is valid, SGL if your device supports
Scatter/Gather DMA, which you probably need), and all you have to do is
setup the hardware to DMA into the particular buffer you’ve chosen for
this particular transfer. If you stop feeding the hardware with DMA
buffers, the hardware will stop capturing data.

Is my thinking straight here? So, in a nutshell, DMA will
allow me to
define some chunk of memory that the PCI device can access
(hopefully as
a burst) like a vampire and suck that data out, BUT!–the host PC
software can put the desired data in the same memory locale
as well? I
hope my whole communication paradigm makes sense … for
example, if a
user hits pause, then I want the host PC to only provide the
same frame
over and over again, and I want the PCI microcontroller to
pick up those
frames.

You have two separate data streams, even in the case of live TV. You have
one stream of freshly digitized TV signal that needs to be encoded into
MPEG or some other format, and stored to the hard disk. You have another
stream of data that is encoded video coming from the disk, going to the TV
chip, and sent to the display.

Your app(s) must set up the DMA from the tuner, encode the buffer, then
write the buffer that you filled with encoded data to the disk. Unless
your hardware is going to do the encoding for you, then you can simply
write the raw data to the disk. The disk transfer is also DMA (probably),
but that is out of the app’s control. You just do a WriteFile() or some
std lib wrapper around that.

Then your app must read data from the disk (ReadFile()) into a buffer,
then (optionally, if your hardware doesn’t decode for you, decode it and)
send it to your hardware. Your driver will set up the DMA to the tuner
board, the tuner board will DMA the data from the buffer, and turn it into
the TV signal again.

Tim Roberts isn’t kidding, if you are not going to leverage as much of the
available Windows services as you can, your SW component gets unmanageably
large. In that case, Windows is probably the worst environment you could
choose to try to completely reinvent this particular wheel. BSD or
another open source OS would probably be more appropriate.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

10

Tim Roberts wrote:

Eric Bowden wrote:

> Tim Roberts wrote:
>> Microsoft calls this “Windows XP Media Center Edition”. If you provide
>> a tuner and capture card, the rest of it is provided for you.
>
> Yup, we’re pretty much (re)inventing both the hardware (tuner/capture
> card) and the software. (Although the software isn’t quite as
> ambitious.)

Hmmm, that’s what YOU think.

Forgive my optimism; it is an ambitious project – I just won’t realize
it until I’m in over my head. I’m trying to mitigate that by scoping
things out right now.

Do you plan on relying on ANY operating system services to do this, or
are you going to create every single piece of software yourselves,
including the MPEG encoding and decoding, tuning (US only?), fine
tuning, volume controls, closed captioning, packet timing, A/V sync,
buffer allocation, error handling, etc. etc. etc.?

I would love to leverage whatever support Windows provides in the way of
system services; but most of the things you have listed are taken care
of in our hardware design. Specifically, MPEG encoding and decoding
takes place on the card with dedicated ICs; volume control is simply
part of the television; A/V syncing will be managed by the
micro-controller software. Packet-timing could be an issue; it’s part
of the interface my team needs to design–obviously complicated by the
whole real-time issue.

The much harder part is designing
an appropriate application interface, especially if you are rolling your
own.

Very true.

I think there may have been some sort of disconnect – viewing the
television on the computer is secondary (optional). The host
application’s job is to determine what MPEG2 data to send back to the
PCI card for analog encoding and output – that is, the host is merely a
“storage” medium.

In fact, I would have suspected (my naivety again) that because the NTSC
(yes, US only) video signal is MPEG2 encoded before it gets to the host
PC, that it would be as trivial as using the Java Media Framework to
play the MPEG file as it is recorded (if we decided to include playback
on the host computer). But I digress. The important thing is, the host
should be able to take the MPEG data that it receives from the card and
store it somewhere. And the host must “simultaneously” decide what MPEG
data to send back to the PCI card for on-chip decoding. Perhaps I am
oversimplifying; it is a place to start, however, as I have never done
this before. I am thankful for your advice as I continue to refine the
design; as such, your concerns are duly noted. I am very grateful to
you for them; there is no room for complacency on my part if I want to
graduate on time with a successful project

Thanks again,
Eric 2.0

11

xxxxx@seagate.com wrote:

No, you don’t drive stuff from the hardware, you drive it from the host
app. In the case of a “TiVo”, you have to keep the hardware supplied with
DMA-ready transactions, which means that you have the buffers ready to DMA
(locked in memory, LogicalAddress is valid, SGL if your device supports
Scatter/Gather DMA, which you probably need), and all you have to do is
setup the hardware to DMA into the particular buffer you’ve chosen for
this particular transfer. If you stop feeding the hardware with DMA
buffers, the hardware will stop capturing data.

My mistake, I thought the card was in charge due to my interpretation of
your original line: “You would setup the transfer on the PCI device and
start it, then go on with whatever other processing you need to do until
the device interrupts.”

You have two separate data streams, even in the case of live TV. You have
one stream of freshly digitized TV signal that needs to be encoded into
MPEG or some other format, and stored to the hard disk. You have another
stream of data that is encoded video coming from the disk, going to the TV
chip, and sent to the display.

Your app(s) must set up the DMA from the tuner, encode the buffer, then
write the buffer that you filled with encoded data to the disk. Unless
your hardware is going to do the encoding for you, then you can simply
write the raw data to the disk. The disk transfer is also DMA (probably),
but that is out of the app’s control. You just do a WriteFile() or some
std lib wrapper around that.

Then your app must read data from the disk (ReadFile()) into a buffer,
then (optionally, if your hardware doesn’t decode for you, decode it and)
send it to your hardware. Your driver will set up the DMA to the tuner
board, the tuner board will DMA the data from the buffer, and turn it into
the TV signal again.

What can I say, but “Right!” This is general idea I had in mind.
('cept with more stuff happening in hardware as I replied to Tim)

Tim Roberts isn’t kidding, if you are not going to leverage as much of the
available Windows services as you can, your SW component gets unmanageably
large. In that case, Windows is probably the worst environment you could
choose to try to completely reinvent this particular wheel. BSD or
another open source OS would probably be more appropriate.

My inexperience is preventing from seeing where all the difficulty
relating to the host software is coming from–I mean, I only want
Windows to act as the mediator to the hard drive. But I must take your
word for it that I am discounting something as easier than it really is.
Unfortunately, until I can start doing some hands-on training with the
training kit, I can’t quite gage what software issues I’m going to run
into. We could move to a Linux platform, although we would rather not
due to our lack of use/knowledge. I suppose those training-wheels need
to come off some time though. My deadline for a Windows PCI-Interface
feasibility study is towards the end of June – if doing all this is
more than we bargained for, we do have a plan B. (Connect a hard drive
directly to the board and simply use the PCI bus for clock and power.)

Thanks for your help, thoughts and concerns! It is phenomenally
gratifying to know there is a generous community of developers out there
with the time to help the little guy.

Eric 2.0

12

Learn AVStream and BDA, these are the architectures for video capture
devices in Windows.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Israphæl Ðaishí”
To: “Windows System Software Devs Interest List”
Sent: Friday, May 19, 2006 10:04 PM
Subject: [ntdev] Senior Project: PCI Digital Video Recorder

> G’day to all y’all,
>
> My name is Eric Bowden, and I’m basically in charge of writing the PCI
Interface for my team’s Computer Engineering senior project. The goal is to
design and fabricate a PCI digital video recorder (DVR) (think TiVo) where the
card is in charge of digital/analog encoding/decoding and frame buffering, and
the host is in charge of storing the data and performing time shifting
operations (like pause, rewind, etc.).
>
> I have no experience with PCI, but am really excited to learn about it. To
this end, I was wondering if osronline’s 9054 DMA Learning kit would be a good
investment. If my understanding of DMA (in a PCI context) is correct, this
would be useful in learning how a host application may push frames of data
(frames) directly to the PCI card’s memory, where they may be buffered and then
analog-ized for TV-viewing. Yes, it’s kinda general, but as I become more
familiar with PCI’s capabilities, I can hone the design into something
concrete.
>
> So, back to the question, would the DMA learning kit be a worthwhile
purchase, or is the current PCI learning kit (Sealevel Digital I/O) sufficient.
Perhaps someone knows of other good resources … ? I could purchase the Rapid
Development Kit from PLX for their 9054 PCI I/O Accelerator, but
starving-student considerations make this highly unlikey. I look forward to
plumbing the depths of collective knowledge in this forum as I get rolling!
:slight_smile:
>
> Thanks,
>
> Eric Bowden
>
>
>
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

>> Tim Roberts isn’t kidding, if you are not going to leverage as much of

> the
> available Windows services as you can, your SW component gets
> unmanageably
> large. In that case, Windows is probably the worst environment you could
> choose to try to completely reinvent this particular wheel. BSD or
> another open source OS would probably be more appropriate.

My inexperience is preventing from seeing where all the difficulty
relating to the host software is coming from–I mean, I only want Windows
to act as the mediator to the hard drive. But I must take your word for
it that I am discounting something as easier than it really is.
Unfortunately, until I can start doing some hands-on training with the
training kit, I can’t quite gage what software issues I’m going to run
into. We could move to a Linux platform, although we would rather not due
to our lack of use/knowledge. I suppose those training-wheels need to
come off some time though. My deadline for a Windows PCI-Interface
feasibility study is towards the end of June – if doing all this is more
than we bargained for, we do have a plan B. (Connect a hard drive
directly to the board and simply use the PCI bus for clock and power.)

Hi,

I justed wanted to say that Linux is not all that good.
Documentation on device driver interfaces is either non-existing or 1 major
kernel revision out of date.
I have written PCI drivers for linux, and though it was fun, there was a lot
of confusion and frustration because of wrong documentation.

The KMDF is really powerfull, and relatively easy to learn. it comes with
several examples and a good set of documentation.
Personally I think that KMDF on windows is going to cost you less time to
learn and implement than a linux solution.
I cannot comment on BSD. Too bad haiku (open BeOS) is not yet stable or you
could have use that.

–

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

14

Bruno van Dooren wrote:

Hi,

I justed wanted to say that Linux is not all that good.
Documentation on device driver interfaces is either non-existing or 1 major
kernel revision out of date.
I have written PCI drivers for linux, and though it was fun, there was a lot
of confusion and frustration because of wrong documentation.

Thank you; I appreciate the input. I will strive to stick with Windows
for this project. Linux just seems more difficult, be it so or not, but
you’re own personal experience certainly helps tip the balance.

The KMDF is really powerfull, and relatively easy to learn. it comes with
several examples and a good set of documentation.
Personally I think that KMDF on windows is going to cost you less time to
learn and implement than a linux solution.
I cannot comment on BSD. Too bad haiku (open BeOS) is not yet stable or you
could have use that.

I’ll be getting the KDMF as soon as the site is back up – Microsoft
said that portion of the site was down for mantainence.

Thanks again,
Eric Bowden 2.0

15

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, May 19, 2006 6:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Senior Project: PCI Digital Video Recorder

xxxxx@seagate.com wrote:

> No, you don’t drive stuff from the hardware, you drive it
from the host
> app.

My mistake, I thought the card was in charge due to my
interpretation of
your original line: “You would setup the transfer on the PCI
device and
start it, then go on with whatever other processing you need
to do until
the device interrupts.”

Based on some comments below and in other posts, I think you are getting
the right idea.
If your hardware does all the encoding/decoding, then all you need the
host app to do is route raw data between the hardware and the disk. In
that case, you just have to do what I outlined in the previous post. If
your host app stops, the card will not “stop” capturing data, but it will
have nowhere to put it, so it will just keep overwriting the hardware
buffers until you start the app again, which will then start sending it
buffers to put the data into again.

[snip]

My inexperience is preventing from seeing where all the difficulty
relating to the host software is coming from–I mean, I only want
Windows to act as the mediator to the hard drive. But I must
take your
word for it that I am discounting something as easier than it
really is.

If your hardware is really doing almost everything for you except managing
the data storage, your software requirement gets a lot simpler. Most
hardware is kept as dumb as possible because it’s easier to fix bugs in
software than it is to fix them in hardware. Conversely, since the
software is doing a lot more, it’s a lot “bigger” job. So your software
challenge is inversely proportional to how much your hardware will do for
you.

Unfortunately, until I can start doing some hands-on
training with the
training kit, I can’t quite gage what software issues I’m
going to run
into. We could move to a Linux platform, although we would
rather not
due to our lack of use/knowledge.

I specifically identified BSD, and didn’t mention any others by name. You
might want to consider why I might do that as you are pondering whether
Windows is the right platform for your project.

I suppose those
training-wheels need
to come off some time though. My deadline for a Windows
PCI-Interface
feasibility study is towards the end of June – if doing all this is
more than we bargained for, we do have a plan B. (Connect a
hard drive
directly to the board and simply use the PCI bus for clock and power.)

Good luck with that! It can work, but now you’ve just moved your software
problem into firmware, where it’s a lot harder to deal with. You now get
to implement a file-system (unless you are simply intending the disk to be
one giant circular buffer) in your firmware, as well.

Hope this helps,

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

16

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno
van Dooren
Sent: Monday, May 22, 2006 1:19 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Senior Project: PCI Digital Video Recorder

Hi,

I justed wanted to say that Linux is not all that good.
Documentation on device driver interfaces is either
non-existing or 1 major
kernel revision out of date.
I have written PCI drivers for linux, and though it was fun,
there was a lot
of confusion and frustration because of wrong documentation.

It was not by accident that I mentioned ****BSD**** by name, and didn’t
explicitly identify any others.

The KMDF is really powerfull, and relatively easy to learn.
it comes with
several examples and a good set of documentation.
Personally I think that KMDF on windows is going to cost you
less time to
learn and implement than a linux solution.
I cannot comment on BSD. Too bad haiku (open BeOS) is not yet
stable or you
could have use that.

KMDF rocks for development that fits well within the model it was designed
to support. I think it will be quite good for developing the kernel mode
component to this particular thing, if the OP decides to go with Windows.
Especially if his hardware does as much as he thinks it will.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

17

>> I justed wanted to say that Linux is not all that good.

> Documentation on device driver interfaces is either
> non-existing or 1 major
> kernel revision out of date.
> I have written PCI drivers for linux, and though it was fun,
> there was a lot
> of confusion and frustration because of wrong documentation.

It was not by accident that I mentioned ****BSD**** by name, and didn’t
explicitly identify any others.

I have played around with BSD. it is amazing, the amount of polish it has
(FreeBSD 6.0)
It does not have as much features as linux, but what it has is designed,
tested and documented.

I only mentioned linux because that is the only nix platform I have written
drivers for.
The impression I have is that with Linux they skip design, testing and
documentation.
That is also supposed to be their reason for not having a stable API. It
would limit them in fixing bugs.
Puhlease. An API should be independent of implementation. They rewrote the
USB interface several times.

Boss: did you finish the driver for linux?
Dev: yes boss. just tested it and it… Uh-oh
Boss: wtf?
Dev: this is good. the kernel hackers solved some bugs by completely
throwing
away the whole subsystem and creating a new incompatible one from
scratch.

I think I should stop now before I bring back more suppressed memories.
Must … put … scissors … down …

–

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

18

Bruno van Dooren wrote:

I only mentioned linux because that is the only nix platform I have written
drivers for. The impression I have is that with Linux they skip design, testing and
documentation. That is also supposed to be their reason for not having a stable API. It
would limit them in fixing bugs. Puhlease. An API should be independent of implementation. They rewrote the USB interface several times.

Boss: did you finish the driver for linux?
Dev: yes boss. just tested it and it… Uh-oh
Boss: wtf?
Dev: this is good. the kernel hackers solved some bugs by completely
throwing away the whole subsystem and creating a new incompatible one from
scratch.

USB is perhaps the one vitally important subsystem where Linux really is
dramatically behind Windows. I’m a Linux advocate – I’ll admit it –
but, as you say, the USB support has been completely rewritten at least
twice, and I’m still not convinced that it’s stable and performant
enough for the Real World.

If someone were to create a friendly wrapper class library around UMDF,
I think Microsoft could actually make Windows believers out of some of
the Linux driver hardcore.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

19

Winusb is available for use outside of UMDF. I don’t know if you knew
that or not.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, May 26, 2006 10:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Senior Project: PCI Digital Video Recorder

Bruno van Dooren wrote:

I only mentioned linux because that is the only nix platform I have
written drivers for. The impression I have is that with Linux they
skip design, testing and documentation. That is also supposed to be
their reason for not having a stable API. It would limit them in fixing
bugs. Puhlease. An API should be independent of implementation. They
rewrote the USB interface several times.

Boss: did you finish the driver for linux?
Dev: yes boss. just tested it and it… Uh-oh
Boss: wtf?
Dev: this is good. the kernel hackers solved some bugs by completely
throwing away the whole subsystem and creating a new incompatible one
from scratch.

USB is perhaps the one vitally important subsystem where Linux really is
dramatically behind Windows. I’m a Linux advocate – I’ll admit it –
but, as you say, the USB support has been completely rewritten at least
twice, and I’m still not convinced that it’s stable and performant
enough for the Real World.

If someone were to create a friendly wrapper class library around UMDF,
I think Microsoft could actually make Windows believers out of some of
the Linux driver hardcore.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer