WWDC2004 Session 501

Transcript

Kind: captions
Language: en
hello welcome to session 501 firewire
thank you okay every year we see new
firewire products and applications all
sorts of areas the technology just keeps
going further the main reason is because
of you are developers you keep
innovating with this technology finding
new ways to use it and that's great
that's exactly why we're here so we're
trying to keep up with you we've got a
lot of new services new features new API
s new sample code new tools even a few
bug fixes this year we're back at dub
dub DC just like every year to bring all
that to you for those of you who are
already developing with firewire we have
a lot of new material this year
especially as relates to tiger and for
everybody we have a quick introduction
to the hardware and the software so that
you'll all get the complete big picture
so we're going to start by recapping
where the firewire ports are and why
they're there because that's where your
device plugs in that's where the
opportunities exist then we'll quickly
look at the software how that works from
drivers up to application again where
can you hook in what's your part going
to do the bulk of the presentation is on
what's new what's new and tiger and
what's new since last year and then
we'll wrap up with a quick look at some
of the great resources that we have for
you as developers to help you develop on
fire wire so first the hardware where
are the firewire ports with this parts
easy because they're pretty much
everywhere every product that we make
every CPU from the ibook up to the
xserve has firewire ports built in we've
been doing it for years every ipod that
we make has firewire ports and there's
two more products that have firewire one
is the isight camera used with ichat AV
and the other only introduced yesterday
is our new line of flat panel monitors
which have built in firewire hubs so
there are lots and lots of ports for
your customer to plug your device into
why why do we have so many firewire
ports what's so great about firewire in
years past we could get up here and say
well it's hot pluggable Auto configuring
note
terminators no scuzzy IDs thin friendly
cables these days that's true pretty
much every I owe anything left and
firewire that makes it special where's a
few things firewire is really fast
firewire 800 800 megabits per second
that's 100 megabytes per second it's the
fastest general-purpose interface on the
box you want to get data in or out in a
hurry we've got the speed for you
multi-speed firewire devices shipped
starting at 100 megabits and then moved
up to 800 you can freely mix and match
these on a firewire buff the slow
devices go flow the fast devices go fast
but firewire can change speed on a
packet by packet basis so the fast
devices don't get slowed down by having
to speak at a common slower speed
firewire can cover really long distances
longer than the other general-purpose
iOS firewire can go up to 100 meters
that's longer than a football field you
want to get your device really far away
from the user firewires the way to do it
firewire provides a lot more power than
any other bus to maybe that's why you
want to get the device far away firewire
can provide 45 watts of power our
machines provide less but plenty to run
an eye sight or an iPod but if you have
a custom application the cables the
sockets are all rated for 45 watts you
can do some really innovative things
with that and customers love it there's
no extra power supply for the isight
camera the ipod charges when it's
plugged in on firewire and charges
quickly a big advantage for firewire
isochronous some other interfaces have
this but i shock but firewire does this
really well isochronous moves streaming
data audio video data that has to go in
real time firewire has very low latency
and guaranteed bandwidth for isochronous
it works very well for delivering your
media data firewire is peer-to-peer
firewire has been peer-to-peer from day
one the very first firewire product was
a digital video camcorder in 1995 there
was only one other thing you could plug
into it on fire wire another digital
I am quarter you can't get more peer to
peer than that but it worked you could
copy one tape from one camera to another
you could edit DV kind of cumbersome
didn't have final cut back then but you
could do it peer-to-peer between those
two cameras everything about firewires
peer-to-peer the host the devices from
day one some other interfaces this may
be cobbled on years later it may kind of
work especially if you only have two
peers may work some of the time not in
firewires been there from day one it
gives you tremendous flexibility and all
those together that's really what
firewire is about flexible if you choose
firewire as the interface for your
product you won't get boxed in by design
constraints as your product grows as you
add new features capabilities speed
performance firewire can take you there
firewire has so many different ways of
meeting your product needs its
open-ended you won't get stuck on the
limitations of the buff and it's
efficient when you have lots of devices
on a firewire bus the bus can run nearly
a hundred percent there's no collisions
in firewire there's no back off there's
no lost packet firewire operates very
efficiently even under stress so let's
take a closer look at some of these key
concepts one thing that makes firewire
really fast is the physical DMA this is
a feature in our products in the host
controller that allows a firewire device
to directly read and write memory
without getting the CPU involved that
speeds things up a lot let's look at how
that works suppose we have a Power Mac
g5 tower and the new ipod mini of course
it's plugged in by firewire let's look
inside the g5 tower and look at just a
high-level view some of the system parts
in there on the left you see the CPU in
the center is the Northbridge and it
connects the CPU to the memory which is
on the right and the i/o controller down
below the firewire interface is in that
IO controller when the ipod has been
directed to move data it's going to copy
data into or out of the system so let's
have a buffer here in memory the ipod
requests the transfer is initiated by
the ipod it tells the mac i want to read
the buffer or i want to
right the buffer here here here and here
this transfer goes through the i/o
controller which receives the requests
over firewire and goes directly to DRAM
to service them the CPU is simply not
involved there are no interrupt there's
no polling no Pio no handshake nothing
it goes as fast as it possibly can and
the CPU is available to do other
important work of course when the
transfer is done we send a special
packet that does cause an interrupt
because we do want to know the data made
it where it's trying to go but this
makes firewire extremely fast also the
pacing is under control of the ipod this
is a very unequal system the ipod has a
very small disk it's just not quite as
fast as the g5s memory system the ipod
controls the pacing I want to read data
now now now everything goes exactly at
its speed so this little need for flow
control or congestion with the ipod
driving it can do absolutely the best
that it can another important feature is
the guaranteed isochronous bandwidth
this is for real time services if you
want to connect a camera or microphone a
device that streams media firewire gives
it guaranteed access to the bus it's
packets will get to they'll get to on
time even if someone else is trying to
drive the bus to 100% let's take a look
at how that works we'll start with the
isight camera this camera made by apple
sends video and audio / firewire into a
mac and is commonly used with ichat AV
if we look at a graph of the activity on
a FireWire bus from an iChat from an
isight camera it's very flat let's
suppose the camera is set to a very high
resolution high quality video mode the
camera might be using fifty percent of
the firewire buff if it's the only
device on there nothing magic is
happening of course it can get fifty
percent of the buff but let's consider a
more complicated case let's take a non
real-time device like a hard drive a
hard drive has a lot of moving parts and
so the rate at which it can transfer
data is going to vary over time
especially if you're doing complex
transfers like directory copies so if we
look at the access pattern of a hard
drive on fire wire we'll see it's all
over them
app if it gets going it may go up to a
hundred percent and saturate the
firewire bus but then it may drop off
while it waits for the media to rotate
around and grab some new sectors so the
access pattern is fairly unpredictable
what happens when you put these two
together on the same firewire bus well
the bandwidth for the eyesight is
guaranteed the eyesight's going to get
its fifty percent all across time
perfectly smoothly and the hard drive is
going to get everything that's left over
the hard drive doesn't have to back off
or moderate its requests it can go out
and say I want to move data and I want
to move it now and the hardware in
firewire make sure that as soon as the
eyesight is done moving its isochronous
data the hard drives can get every
little bit that's left over so in this
combination the bus efficiency can be
pushed basically to 100% the hard drive
can just go full bore it'll take a
little longer because the eyesight is
also on the bus but there's no impact at
all on the eyesight the audio and video
keep flowing completely smoothly this
guarantee is provided and hardware so
you can't mess it up finally I said
firewire can go really long distances
but you may have noticed that we don't
have long distance ports on our product
why is this does this really work well
most of the devices our customers
connect are things they want to use
nearby because they're probably
interacting with the device as well as
with the mec such as an isight camera
and ipod a DV camera where they may be
changing the tape but there are some
kinds of devices that are very
interesting at long distances such as a
security camera or music studio
application or an industrial application
where you want to put some distance
between yourself in the device so we can
do that what you do is get a 1394 be hub
this is a very simple device because
it's just one piece of silicon the hub
has regular firewire 400 ports on one
side which you can connect today to our
I bloke is shown here and it has long
haul 1394 be ports on the other side
such as plastic optical fiber glass
optical fiber or category 5 unshielded
twisted-pair you can choose the media
that's most
it to your application this way we don't
have to pick between those three for the
port on our computer and you can still
get the long distance now if your device
is something that's always going to be
used or often going to be used at long
distance it may make sense for you to
incorporate the long-haul connector
directly then the customer doesn't need
two hubs they only need one other
important thing to note about this
picture the two devices at either end
the ibook the isight camera those are
not 1394 be devices they're firewire 400
can they work with this long distance
sure 1394 b is completely backwards
compatible the hubs understand how to
talk to the firewire 400 device and how
to talk to the long-haul connection and
the data flows seamlessly through from
one end to another so this means if you
want to put some distance between the
devices you're not limited to our latest
models like the g5 and the powerbook
that have firewire 800 your customers
can use this with all of our products
that ever had firewire ports going back
many years so this is very flexible
technology let's move on into the
software you've seen where the ports are
why they present unique opportunities
where do you hook in if you're writing
software consider the Macintosh suppose
you have some firewire devices that
you'd like to use you're going to have
some applications that launch when you
want to use these devices now as I
explained earlier in the diagram with
the ipod every McIntosh has one built in
firewire controller it's the industry
standard 1394 open HCI open host
controller interface all of these
devices are going to have to share they
all want to use it at once someone's
going to have to mediate this so you've
got different applications different
drivers different devices each doing
their own different thing on a single
controller that's the main job for the
firewire family the family steps in
takes ownership of the controller and
moderates so that everybody can do their
thing without even worrying about what
else is going on that's the main
function that the family provides now
may not see it but consider the two
devices on the left the still camera the
ipod mini they actually have a lot in
common they both use a mass storage
oriented protocol they use the firewire
transport called SBP to serial bus
protocol too and they communicate using
a scuzzy architecture on top of that so
we provide a standard software layer
that they can share so their drivers
don't have to re-implement this protocol
from scratch similarly the camcorder and
the guitar look pretty different but
they both use a protocol known as a vc
audio video command or control here too
we have a common layer of services for
speaking this protocol so the individual
drivers don't have to re-implement it so
in a nutshell firewire software shares
one interface and provides common
services that multiple drivers can
leverage to simplify driver writing and
ensure uniform common behavior now
everything about firewire here is in the
kernel because some firewire devices
provide services to other layers of the
kernel for example a mass storage device
can provide a file system or a io5 r.i.p
can provide networking services those
are both colonel services so firewire
has to be in the kernel to make those
possible but we've gone out of our way
to make everything in firewire available
in user space as well as in the kernel
so odds are you can write an application
or a plug-in for an application you can
run it and debug it in user space which
is much more pleasant than trying to do
your development in the colonel now that
you've seen the basics let's look a
little more at the details of the layers
here's the items from before at the
bottom we have the hardware interface
apple fw ohci is a system kernel
extension that effectively is the device
driver for that interface and it has
sole control sole direct access to the
hardware above it is io firewire family
also a kernel extension and it has sole
ownership of the ohci driver above the
family first we find protocols such as
you saw in the previous slide such as
ABC or SBP to above protocols we have
drivers for particular
devices or classes of devices for
example a mass storage device uses the
i/o firewire serial bus protocol
transport driver as its gateway up into
mass storage and the file system whereas
the DV camera uses I OFW DV components
as its gateway up into QuickTime other
drivers are more specific like Apple
eyesight or IO firewire IP in fact these
drivers don't use a separate protocol
layer they really are a protocol and
driver all wrapped up in one so drivers
can also hook in directly to the
firewire family above this layer we have
what I call everything else once you
move above this layer you're not in
firewire anymore you're in quick time
you're in Final Cut you're in the file
system somewhere else not my problem so
say I tuned Final Cut Pro QuickTime
they're good places to be there above
firewire these could be applications or
they could be additional Colonel layers
so this is the basics of how the
firewire software hooks together I
mentioned that in applications you can
access all the fire wire services so of
course applications can talk directly to
drivers but there's two other paths as
well we provide what's formally known as
a device interface and is often called a
user client this is a library API that
lets you talk directly to a protocol or
even directly to the firewire family
itself from an application so we're very
flexible you can hook in anywhere you
need in the kernel in application space
we provide lots of ways to do it now I
mentioned I Oh firewire IP what's that
doing here in firewire IP is a protocol
that's designed to span the globe it
works well on slow comparatively slow
unreliable links doesn't sound like
firewire well turns out it works great
on fire wire doesn't depend on anybody
dropping packets but a lot of devices
already have IP in them for one reason
or another generally because it's
ubiquitous a lot of printers today have
a little web server inside that lets you
browse the status or configure the
device even if the main data is sent
over some more native protocol say SBP
too so if you already have IP
capabilities in your device you can
carry these into your firewire device
and the user will have full access to D
services in Mac OS 10 we implement ipv4
and ipv6 in firewire it fully supports
rendezvous if you have a surfable device
you can get to it to firewire no special
effort is needed so we're very flexible
there please think about taking
advantage of that the firewire family
this was the master control layer that
provides all the services just what are
those services first and most important
when your device gets plugged in we have
to find it the family knows how to
notice that a new device is on the bus
and the family will ask the device hey
what are you why are you here the family
takes these answers and puts them in the
IO registry which is not a FireWire
structure it's a general I okay at
service io kid then comes along and
matches drivers or protocols to your fat
to your device based on the information
that firewire provided and this process
may be iterative your device might say
well I speak the AVC protocol so we
would match the ABC layer which would
then ask your device further questions
saying okay what kind of sub units do
you have your device might say I have a
tape subunit and audio sub unit we put
that information in the io registry as
well and then match further so we can
get just the right driver for your
device on a firewire bus the node IDs
may change their assigned randomly as
devices come and go they may change the
last thing your driver wants to deal
with no problem every firewire device
that we can talk to has a unique serial
number called a good global unique ID
the family will track this down and
it'll follow it around the bus so the
family always knows what node ID your
device is on it will automatically send
your drivers packets to your device so
you don't have to worry about this on a
firewire bus I mentioned you can have
mixed speeds maybe your device does
firewire 800 but your customer plugged
it into an iBook that has firewire 400
we don't want your driver to have to
figure that out the family figure set
out the family looks at who's connected
to who finds the fastest path between
devices
automatically routes your traffic at the
best speed that it can do also the
family having looked at the bus topology
can perform an optimization to tune the
bus to make it operate as fast as
possible again something your driver
won't have to worry about okay so your
device has been discovered it's on the
bus keep keeping track of it now you
want to talk to your device the most
basic communication on fire wire is an
asynchronous request a read or a right
directed at a memory location in your
device the family will do this for you
it'll send the packet to your device and
if your device is so kind as to respond
the family will fish the response out
from all the traffic on the bus and hand
just that response back up to your
driver so you don't have to worry about
the other devices that are on the bus
you may want to do the reverse maybe
your device will initiate the
communication if so it needs an address
that it can talk to in the Macintosh so
the family will allocate an address
space for you and as packets come in to
that address space it will hand them to
your driver and say here do something
with this so you can go either way you
may want to communicate in real time
we'll get to that in a moment the family
also publishes a configuration rom this
is the structure that tells every device
on the bus what you do for a device like
an iPod or a nice site that functions
probably locked in at the factory so
this may truly be a rom but for a device
like a Macintosh its capabilities may
change as new applications are loaded
new drivers are installed so that's why
I put quotes around rom on the Macintosh
the configuration rom really comes out
of RAM and is managed by the firewire
family for example when I Oh firewire
our IP load it says please tell
everybody that IP services are now
available on this node so the family put
that information in its configuration
and announces it on the bus if you want
to communicate in real time to send or
receive streaming data the family
manages that for you and we'll go into a
lot more detail about how that works
additionally the family can get you your
reservations on the bus if you want to
reserve band
for your real-time communication just
ask the family it will get the
reservation and it'll keep the
reservation valid for as long as you're
using it now there's a second completely
input independent implementation of
firewire in the Macintosh and that's in
the bootrom why well you can boot the
computer from a firewire disk so
somebody has to load Mac OS 10 from the
disk over firewire can't load itself the
bootrom does that you may not do this
every day I do but this is very helpful
you might need to install mac OS 10 on a
lot of different computers say in a
laboratory or classroom environment
installing from a hard drives a lot
faster than installing from optical
media or you may need to install mac OS
10 over and over and over again if
you're testing or debugging or checking
different versions and you only have one
system firewire booting is great for
this it really speeds things up the
other thing that the bootrom can do is a
service called target disk mode this is
where firewires peer-to-peer capability
really shines in target disk mode the
Macintosh will emulate a firewire hard
drive completely in software you can
then plug it into a second Macintosh and
it will show up on the desktop as a
firewire hard drive here to you may be
wondering why would I do this well it's
a real easy way to move data quickly
between systems it's also a great way to
fix up the system if it's not booting
properly if you're developing Colonel
drivers and you've installed a new text
and rebooted the system there is a
chance the system will crash in your
text well that makes it very hard to get
your system working again because you
can't boot to find her and get rid of
that text no problem with the system in
target disk mode plug it into your other
Mac go delete the offending text take it
out of target disk mode now it'll boot
fine very quick recovery it's a lot
better than reinstalling the OS so two
capabilities in the boot rom that you
may find useful we also have a third
completely independent implementation of
firewire and that's called the firewire
reference platform you may recall that
we purchased a company called zion.t a
few years ago and they had a product
called tnf 1394 that's what this is
this is software that's designed for
pretty much anything except a computer a
peripheral device a multifunction device
it's a rich modular software stack
designed to run within the limitations
of a real-time operating system or an
embedded operating system you can
download the entire TNF sources from our
website they're posted for everyone to
use if you want to incorporate the
source in your product you need to sign
a license from Apple but it's free no
problem tnf has very rich services it
has lots of examples what it calls
applications which is sort of the heart
of whatever your product does it
especially has good AVC services so if
you're doing an audio or video device
using the ABC command set there's really
rich capabilities here that could give
you a huge head start it's available on
the web you can take a look at it and
see if it meets your needs ok now that
everyone's well versed and firewire
let's move on to what's new first most
importantly what's new you guys have
been great you shipped a ton of products
this year all sorts of innovative things
so big thank you to our developers
really happy with all the stuff we've
seen new product I'm sure you've seen is
the ipod mini but maybe you didn't know
it has SBP 3 what is that it's the same
SBP to that we use for match towards
mass storage devices but it has a new
feature that makes it go faster let's
look at what happens with an older ipod
and a powermac as we try to read 2k of
data from the device using an operation
that has a page table here's the two
devices there's going to be seven
packets exchanged on the firewire bus to
complete this operation to signal it to
move the data and to indicate that it's
done the packets are very efficient so
this isn't bad we get good performance
from this but fast start makes it a
little bit better with new ipod mini
that same operation takes just three
packets fifty-seven percent improvement
this gave us a good performance
improvement we were very happy to have
fast start in stp three has been
supported since mac OS 10.2 point five
we encourage you to try it out in your
products if you use SBP to
ABC the audio/video command set we've
had support from ABC since day one
because that first product was a
camcorder but there's one thing we've
never done quite right and that's a kind
of command called notify the notify
command an ABC is something that may
complete later it may complete a lot
later you're telling the device I expect
something to happen in the future please
tell me when it does but our API for
sending this kind of command is
synchronous so you call this API saying
hey tell me what's going to happen it
may be days later before it returns and
says okay it happened that doesn't
really work so we still have the old API
no change at all there ABC command lets
you send a device out to them their
command out to your device but we have a
new service that's also available you
can create an ABC asynchronous command
and assign to it a call back when you
submit the command it returns right away
later when the device completes the
notifier sends the status your callback
will be called so this is perfect for
use with the notified command you can
also use this with other types of
command but they'll generally complete
right away if you're familiar with our
software development kit you may have
seen our MPEG framework it's a pretty
rich collection of services that allow
you to stream MPEG on fire wire on a
macintosh well we've taken that a lot
further that was in sdk 19 we've
extended it and renamed it and now it's
the AVC video services framework what
we've done is added DV the completely
second video format and we've integrated
all of the AVC commands and control that
are necessary to set up discover and
maintain these streaming connections so
your device your driver doesn't have to
worry with these details all in all it
provides better support than our older
api's like this awkwardness data handler
for example only with the new framework
can you do dvcpro HD in writing your
applications keep in mind this is still
a very low level way of talking to your
devices depending on what you're doing
this may be appropriate however
application software may want to use
higher level api's such as quicktime if
you use quicktime you can talk to any
kind
video device without worrying about
whether it's on fire wire or something
else but if it's appropriate you can use
this framework we know several
developers are already shipping products
based on the framework that's in the SDK
now in tiger this will be a private
framework but it will continue to be in
the SDK and you can pick it up there and
build it into your products we would
like to consider making it a public
framework so you can just count on it
being there we need to hear from you we
want to hear how you're going to use it
how it's going to help your product and
what you're doing with it that kind of
feedback will help us to take this into
a public framework so please take a look
at this evaluated for your needs and
then let us know isochronous data we've
talked about sending real-time data on
the bus how do you receive this data in
your driver we have a new capability
called buffer fill a sock received but I
haven't really described how to receive
any data or even really said what
isochronous is let's do all three
isochronous literally means equal time
so if we take a timeline and divide it
up into equal chunks that's isochronous
then we send the packets on the bus in
these equally spaced cycles here's six
packets going across the bus at regular
intervals the firewire bus provides
these cycles 8,000 times per second if
you're receiving isochronous data you
probably don't want us calling you a
thousand times per second to say hey a
new packet arrived quick better do
something because there's another one
coming in 100 microseconds isochronous
whether you're sending or receiving it's
about planning ahead what you do is you
make a list of instructions for us in
memory using an abstract structure
called a data stream control lift you
give this list to firewire and say
here's a plan I want to receive the next
hundred packets as so it might look like
this a series of instructions each of
which says receive one packet and here's
a little buffer to put the packet into
then when you run this program and start
the isochronous stream the packets flow
into the buffers just like you'd expect
this is what we've had all along this
can serve any kind of isochronous
reception neat but this is not always
what you want
the particular stream shown here has
packets that are not all the same size
this depends on your kind of device some
devices all we send a single size of
packet others may be all over the map in
the later case you may waste a lot of
memory a lot of buffer space because if
you don't know which packet is going to
come when every but has to be big enough
to hold the largest possible packet the
hardware in the industry standard ohci
provides a way to pack the packets
together neatly and this may be what you
want depending on the kind of data that
you have so while maintaining the
existing services and tiger we're adding
a new way to receive isochronous data
called buffer fill which is simpler here
we simply have a list of buffer pointers
and some significantly larger buffers as
the packets come in from firewire the
hardware will neatly pack them into the
buffers using up every last bite you can
see on packets for it didn't completely
fit in the first buffer so the hardware
just split it in half and put the
remainder in the second buffer you can
choose whichever of these is more
suitable to the kind of data that you
are receiving but some future services
such as receiving from two channels at
the same time may require the buffer
film mode because that's the only way
the underlying hardware can do it
speaking of dcl which is the data stream
control language for sending or
receiving packets we've made some
improvements in tiger we've cleaned up
what happens when the computer sleeps
isochronous means real-time but if
you're sending packets and the computer
goes to sleep that's not real time
anymore when the computer wakes up any
packets that you had prepared our way
out of date nobody's listening nobody
cares so we used to try to keep sending
and that was a mistake we've cleaned it
up now we stopped your program when the
computer wakes up we send you a message
saying hey your program stopped because
the computer went to sleep you want to
start it up again go right ahead you
should check and see if your device is
still on the bus see if there's anyone
listening but then go ahead and start
your program up every dcl has a callback
known as the force stop proc it gets
called if your program is
opted against your will for some reason
such as the computer went to sleep or
such as you lost your isochronous
reservation which is very rare but this
is a special case where it can happen so
be sure you hook up this callback pay
attention to the hardware slept message
then just call stop and start to get
your stream going again you don't have
to tear down your dcl just make sure it
makes sense fill it in with fresh data
and get it started again some kinds of
isochronous since it's real time the
system may be trying to meet various
real time deadlines especially in the
case of receiving audio and firewire
there may be very high priority threads
running trying to do everything with the
lowest possible latency this may work at
cross-purposes to firewire because it
may hold off the execution of firewires
processing of your packets that are
going in or out so we've added a method
you can call that will directly force
the update of your program regardless of
the priority so if you are running on a
high priority thread and you want
firewire up-to-date call this method
firewire will run even if it's being
held off otherwise and your data will be
up to date the typical case to do this
is with audio we've made further changes
if you have a transmit program it's
common to make changes to the program
while it's running you can change the
size of the packets on the fly you can
change the buffers the packets come from
on the fly you can even rearrange the
program order on the fly this is often
done because the programs typically run
either in a loop or in a sort of open
loop that's constantly being refreshed
with additional data previously if you
changed either the length or the pointer
to a buffer it was very inefficient as
we went through an updated debt and
we've greatly streamlined that so it's
much more practical now especially if
you have a big program to use this
technique I mentioned that the callbacks
for audio processing you can have
priority problems in addition to the
direct service method you saw on the
last slide we have a new capability to
assign a dedicated thread to
you're dcl if you have multiple DCL this
will let you prioritize them or prevent
deadlox between them if you're running
in the kernel you can allocate and
create the thread of your choosing and
set all the parameters just the way you
like then assign it to your dcl on the
other hand if you're running in user
space you can simply set a flag saying
that your dcl should be processed on a
separate thread so it doesn't depend on
anybody else more isochronous in a way
the isight camera it sends audio and
video on fire wire but no one really
knows how the audio works because that's
not in the spec that it otherwise
complies with the camera complies with
the 1394 trade association hi IDC camera
specification Apple extended that a
little so this camera would work well
with ichat AV we added some video
formats that work well with Internet
chat and we added an audio capability we
have prepared a developer technical note
that explains how these work and some of
the other subtleties of the device like
how to find out if the shutter is open
and what's in the config ROM and what
all those unit directories mean this
tech notes about ninety percent done we
hope to have it out to you in the SDK or
post it on apples developer support site
in the very near future let's talk about
some changes to tool color Firebug you
may be saying hey I like color that
sounds good but what's Firebug Firebug
is Apple's packet analyzer it's a
Snooper it requires a special pci card
or card bus card but it lets you see
every packet on the firewire buff and
this can be tremendously useful in
trying to debug your device Firebug is
the poster child for crude but effective
you can see the user interface is
somewhat lacking but it shows you every
packet on the bus and has lots of
options for how to arrange the data here
if you're a Firebug Wiz you can see that
it's showing operations to an iPod as we
read and write data from the disk but
some of you may still not really see
that so clearly does that help color
Firebug can colorize the packets based
on various different criteria the goal
is to help you quickly identify what
you're looking for here the packets are
colored based on their
type reads writes block squad let's
requests responses each one has a
different color you can color based on
the packet speed based on the sender ID
the target ID the isochronous channel
the acknowledged code depending what
you're looking for this may make it jump
out if you've got one packet that's at
the wrong speed it's real easy to spot
one red line in a field of blue then it
go through trying to read all of the
digits in the speed code so if you use
Firebug download the latest SDK this is
in Firebug 1.9 try it out we've also
enhanced our fire starter tool this is a
tool that was designed primarily for
firewire plugfest or anywhere that you
have a lot of firewire devices connected
together on one firewire buff it uses
the same code as Firebug for displaying
the bus topology there on the right hand
side in a simple ASCII rendition showing
what's connected to what this is based
on receiving the self IDs and no special
hardware is required for that so this
tool can run on any of our products
firestarter also sorts all the self IDs
and tells you things like how many nodes
are running at each speed firestarter
1.4 has some improvements in particular
there's an options menu that lets you
select several different things you can
configure some subtle details about the
role firestarter will play on the bus in
bus management you can ask firestarter
to announce itself to Firebug by sending
a packet after every bus reset to say
hey I'm here I'm on node 7 you can even
ask firestarter to play the system beep
sound on every bus reset if you need to
know these are happening and finally
there's a new display mode that shows
the raw self IDs when would you use this
well if you have a really low level
problem in firewire the self ID sequence
may not complete properly a defective
hub or an out of spec cable may cause
some kind of problem where the self IDs
get messed up in which case firestarter
can't make sense of them and it won't
even try to draw the tree it'll just
show you a blank page so select this new
option and the page changes to show the
hex values of all the self ID packets
exactly as they came in this will help
you figure out what's going on also we
like colors in like
to added some here too if there's a bus
reset firestarter will tell you about
that too just like that some other tool
updates we have a tool called Phi tool
that we described in great detail last
year it lets you view and edit the
registers in the thigh and the Macintosh
and you can view these registers on
other nodes on the firewire buff Phi
tool 1.7 has some important new features
among other things it properly supports
Panther and tiger there's no user
interface problems and it has some
important bug fixes especially if you
were changing five registers the earlier
versions would change a little bit too
much so you might get confused it won't
break anything but you might really
wonder what's going on if you're using
fights who will please be sure to get
version 1.7 vigilante is a new tool in
our SDK it really doesn't have anything
to do with firewire but it tracks memory
allocations for objects in the kernel
and we used it recently to track down a
big memory leak in the tiger version
firewire it was so effective we said hey
this is great let's put it in the SDK
will let everybody use it so give this a
try it's another good tool another
capability we've never talked about
before is the ability to put debug
information in the i/o registry when
you're working with firewire what is
this this is kind of like a dynamic
printf rather than logging out
information constantly you can arrange
to grab information from your driver at
exactly the moment of interest this is
really flexible although it's a little
complicated to set up if you get
firewire SDK 19 and you install it you
can then navigate down through the
folders as shown here and for the
different versions of firewire there are
installer packages that will install new
firewire texts into your system choose
the package that has debug in the name
and it has a few special tricks after
you've installed this package and
rebooted you'll be running with a
slightly different version of firewire
look in the Applications folder in the
SDK and you'll find a tool called mr.
registry this is a browser that our team
produced that can look at properties in
the i/o registry if you look down
towards the bottom is marked in orange
you find the firewire controller pick
that and show the property and you'll
notice something new
marked in orange on the right is a
property called debug info that's not
usually there that's added by the debug
build of the extension so open that up
it has some information about the
isochronous DMA context this is pretty
low level stuff why would you use this
suppose you're transmitting isochronous
on fire wire it's pretty easy to use
Firebug to see the packets are going out
across the bus you know your
transmitters working receive is another
story your device may be sending packets
in Firebug shows them but they don't
seem to be making it to your driver you
don't even know if the mac is listening
here's a technique that can give you a
bit of a clue I just happen to know that
my receiver is running on to context too
but this only eight so it shouldn't take
you too long to find open up context to
and you can see direct information about
the ohci controller it's command pointer
and its command state if you refer to
the ohc i spec you can see that that
state 843 one indicates the DMA is
running its active and it records event
complete meaning is has received at
least one Packer so that's a good sign
we're getting somewhere but maybe that's
all that happened it received one packet
it stopped and now your applications not
getting anything what more can we learn
look at the part marked in orange that's
the command pointer this shows where in
the DMA program the DMA is executing
well press the refresh button and it
changed another good sign this means the
DMA right now is still running it's
receiving packets it's doing something
with them so everything looks very good
at this point this is pretty esoteric
stuff not everybody's going to need to
dig down in here to see if their dma is
running or not but the point is this
gave you a real-time printf rather than
constantly logging information about
what it's doing you were able to reach
in and look just when you want to do and
see a key piece of information the way
this works is that the property that's
created in i/o registry has a call back
that says when you need the value for
this just call me and I'll tell you when
I our registry when mr. registry asked
up-to-date information is provided
you can do this in your driver to see
almost any kind of information there's
examples in our source code get the SDK
and look in the source code for the IP
driver or the SBP to service layer and
you can see how to do this another
capability we haven't talked about
before debugging with fire log this is
not new but we never explained how it
works and we'd like you to give it a try
this is one of the oldest techniques in
the book you take two systems you run on
one of them you use the other to look
into you what's going on so your driver
is running on the g5 fire log creates a
buffer in memory where your driver can
log some messages the other system is
connected by firewire and it runs an
application that can view these messages
so your driver runs along recording
information this all shows up in the
other mac pretty basic stuff you could
do this with a serial port you could do
this with ethernet why do this with
firewire well there's a difference this
system uses the physical VMA just like
the ipod that you saw before what does
that mean when your driver logs and
message it's nothing but a sprint f into
memory there's no I oh you don't have to
call the ethernet driver the serial port
driver no interrupts no context switches
it's extremely lightweight going through
other iOS could add variables to what's
happening on the system that you're
trying to debug this is not likely to
change very much on the system you're
debugging suppose your drivers in the
kernel suppose your driver panics it
happens even worse the potion driver
hang and doesn't have the good grace to
panic well you may not be able to get
the very last message that it wanted to
log if you're logging in the system log
or on a serial port or Ethernet you may
have panicked before that message really
got all the way out no problem with fire
log the physical DMA does not depend on
the cpu even if the machine is panicked
the remote machine can reach in look at
the buffer and see what's there and get
the very last message that your driver
logged before it died and odds are
that's the one you want to see so this
is a really unique capability on
firewire give this a try
this is a bit tricky to set up there's
two ways to do it you can rebuild the
firewire family to turn on fire log or
you can install the debug package like
you saw on the previous slide where this
should already be turned on but we're
trying to make this easier we hope to
provide a text that you can drop into
any version of firewire that will
automatically make fire log available
take a look in the SDK there's
instructions for how to get this set up
okay let's quickly review firewire
resources we've got a lot of great stuff
for your developers in addition to the
tools and code that you saw here I keep
mentioning the SDK our software
development kit it's available on the
web for free download we've made 19 of
these since we started on Mac OS 10 and
of course we're hard at work on number
20 SDK has lots of source code sample
code application stuff colonel stuff
great place to get started often the SDK
has advanced versions of firewire
software if we've made some fixes or
added some features we can use the SDK
to get those out to you so you can try
them out before your customers do you
can let us know if they work you can let
us know what we need to change all of
the tools that you saw are all built
into the SDK and as various notes and
documentation there's a lot of stuff
we've had 19 spins on it we've really
put a lot in there pick this up it's on
our SDK website it's real easy to get we
have some public mailing list there's a
main list for firewire any kind of Mac
os10 firewire development questions are
welcome we will try to answer and often
developer to answer each other's
questions which is great there's a
second mailing list for the reference
platform where there's some very
specific discussion about porting to
specific real-time operating systems
specific Hardware interfaces that's
another active list there's a third list
a lot of you may want to visit which is
the ATA and scuzzy list why would you go
there a lot of firewire devices that use
SBP to have a scuzzy architecture in
their command set even though they may
have no actual fuzzy hardware if you're
talking to that kind of device most
likely the easiest way to do it is
through discuss eat ask user client
provided by our mass storage team
support for that interface is discussed
on this mailing list for all of these
you can subscribe 1 common place on
apples developer site it's very easy to
do apple owns the firewire trademark but
we're not very selfish about it use this
on your products your customer wants to
know the product has firewire put this
on the product put this on the box put
this in the marketing on the web page go
nuts just license it from us and do be
sure to use it correctly if you license
it from us should get high-quality
artwork so you won't mess it up there's
another logo that shows your product has
passed the compliance testing from the
1394 trade association this one you
can't get from Apple because we don't
run those tests attend one of the 1394
ta events or send your products into one
of their vendors and have them tested
you can get tremendously useful
information about your product from this
testing and we send a lot of our
products in we always learn something
new this is a really good program ok a
little bit more if you'd like to talk to
Apple about firewire Craig Keithley who
will be up here for Q&A our main contact
or if you're located in Asia you're
welcome to contact stephen chick in our
japan office or if you're not sure who
to talk to just write to firewire at
apple.com and we'll find somebody in the
reference library on apple's ADC website
firewire itself we have some basic
information about the technology there's
a substantial document for working with
firewire device interfaces this is the
user client I talked about earlier that
lets you talk to firewire from an
application or from a plug-in that's
running in the context of an application
Apple publishes developer notes for each
of our CPU platforms they're quite
detailed they will tell you how many
firewire ports there are if it's
firewire 400 or 800 how much power is
survived it is provided what's the
internal architecture of that system
lots of valuable information there so
please take a look finally if you do
have to write in the colonel there's a
starter document device driver
fundamentals not specific to firewire
take a look at that that should get you
up and running we have a good techno
Tandy CL program if you're going to be
sending or receiving isochronous data
take a look at this technical
out for sample code there's some basic
sample code for firewire scuzzy and
general mastered posted on the ADC
website to independently and then
there's a good deal more in our fire our
SDK as I discussed before since you're
here at dub dub DC there's two more
things you should know about tomorrow
and Thursday we will have firewire
engineers in the i/o technology lab if
you go out these doors turn left it's
right down the hall at the end we'll be
happy to take your walk-in questions we
can demonstrate the tools we'll try to
debug your code come on by and see us
tomorrow we'll be there from 9am to 630
except during the firewire feedback form
in the afternoon and on Thursday will be
there from nine a.m. to five and then
we'll all leave for the other event
which is the ADC plugfest at the apple
campus bash so on Thursday we will have
a bunch of firewire devices that you all
brought and we'll connect them together
in one big buff and you'll get to see
for example firestarter in operation and
see what happens when there's lots of
devices all sharing the bus a lot of the
devices we already have but you're still
welcome to walk in with more and we'll
plug them in and see what happens we'll
have more engineers more opportunity to
try the tools or ask questions that
Thursday evening from the start of the
campus bash until the close