Actually a Digital Cam corder is around $2000 list price. It's not CHEAP
though :-).
We are still working to finalize the protocol and estimate the ROM size.
I only can say is that our target ROM size for Thin protocol of DPP is
less than 10KB. This includes sender and receiver function.
If your node doesn't have to implement all functionality, it will be
smaller. This is the case that the node must receive the connection
request but doesn't need to send the request of connection.
We also want to emphasize that DPP has simple scheme.
1) send "connect request"
2) send "data"
3) receive "acknowledge"
4) do 2) and 3)
5) send "disconnect request"
The other side can also do 2),3),4),5).
This is very straightforward.
Again I don't want to make any confusion in PC printing discussion.
I just want to tell DPP to PWG correctly.
Toru Ueda
Sharp Corp.
Software Labs.
On Sun, 15 Feb 1998 13:21:45 +0900
Fumio Nagasaka <fumiona@venus.dti.ne.jp> wrote:
> Dear Toru san,
>
> One point.
> I think 30k is good size even for cheap consumer devices.
> This size is smaller than typical VxWorks implementation, and it
> may be smaller than JetSend.
>
> So please give us information how big your DPP ROM size is expected to.
>
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111, Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
>
> -----Original Message-----
> From: Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
> Sent: Saturday, February 14, 1998 6:45 AM
> To: Turner, Randy
> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> Subject: Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>
>
> I don't want to make any confusion about PC printing protocol. This is
> only for your information.
>
> >From consumer device point of view, "symmetrical" is the essential
> feature of the protocol.
> For example, a digital still camera wants to send its image data to
> printers. Also the same camera wants to receive image data from the
> other still cameras. We want to use the same protocol for both use.
>
> These are three essential features for consumer device.
>
> 1) Bi-directional
> Each side can send and receive data.
> SBP2 supports bi-directional feature.
>
> 2) "True" bi-directional
> Each side can send and receive data at any time.
> Alan's architecture supports "true" bi-directional feature by using
> transmit buffer, receive buffer and unsolicited status.
>
> 3) Symmetrical
> Each side has the same architecture.
> This is completely different from bi-directional issue.
>
> Consumer device needs these three features and the protocol must be
> simple.
>
> If SBP2 implementation needs 30K for initiator and target, it might be
> difficult to use it for consumer device.
>
> Toru Ueda
> Software labs.
> Sharp Corp.
>
> On Wed, 11 Feb 1998 08:35:10 -0800
> "Turner, Randy" <rturner@sharplabs.com> wrote:
>
> >
> >
> > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> > maybe, but I hadn't seen the chip set feature in the brochure for
> > "chip-level SBP-2 support".
> >
> > Also, since 1394 is a peer-to-peer interface, anyone developing a
> > peer-to-peer device (like the majority of the Japanese electronics
> > industry), would have to essentially duplicate the functionality of
> > SBP-2 initiator and target, whether they actually use SBP-2 to do this,
> > or some other (potentially proprietary) method for implementing
> > peer-to-peer functionality.
> >
> > Randy
> >
> >
> >
> > -----Original Message-----
> > From: Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> > Sent: Wednesday, February 11, 1998 8:30 AM
> > To: 'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> >
> > My experiences in the past is that combining target AND
> > initiator
> > functions into a single device is VERY difficult. The
> > complexity of the
> > state tables and ambiguities that can arise make it very
> > difficult.
> > Also, I don't believe any of the chip manufacturers support
> > SBP-2 for
> > both target and initiator. In my opinion, it's NOT just a
> > matter of
> > adding the 15K for the target and 15K for the initiator. The
> > target and
> > initiator have vastly different functions. Designing a model
> > that did
> > both (well) would be a challenge. It was problems like this
> > that fueled
> > many of the AEN (asynchronous event notification) debates.
> >
> > Stephen
> >
> > > -----Original Message-----
> > > From: Turner, Randy [SMTP:rturner@sharplabs.com]
> > > Sent: Monday, February 09, 1998 1:03 PM
> > > To: 'Brian Batchelder'; p1394@pwg.org
> > > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> > >
> > >
> > > I am very interested in the combined target/initiator
> > footprint as
> > > well.
> > >
> > > Thx
> > >
> > > Randy
> > >
> > >
> > > -----Original Message-----
> > > From: Brian Batchelder [SMTP:brianb@vcd.hp.com]
> > > Sent: Monday, February 09, 1998 9:37 AM
> > > To: p1394@pwg.org
> > > Subject: Re: P1394> Rough SBP-2 & IP1394 core
> > component
> > > ROM sizes
> > >
> > > At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> > >
> > > [snip]
> > >
> > > >I approached them about sharing some rough estimates of
> > code
> > > size
> > > >for the IP1394 glue, SBP-2 target and initiator, and
> > 1394 bus
> > > >manager modules to get a feel for how "heavy" the
> > protocol
> > > >implementations really are. They graciously shared the
> > flowing
> > > >estimates with us, and certainly deserve our thanks.
> > Since the
> > > >technology is still being developed, these
> > implementations are
> > > >certainly going to be tuned and the numbers will change
> > a
> > > little
> > > >bit.
> > > >
> > > > Component Rough ROM size (KBytes)
> > > > --------- -----------------------
> > > > SBP-2 initiator core 15 +/- 5
> > > > SBP-2 target core 15 +/- 5 (incl. Mgmt+Fetch
> > agent,
> > > no exec agent)
> > >
> > > Any idea how big a combined SBP-2 target/initiator would
> > be?
> > > 15-30K? ;-)
> > >
> > > [snip]
> > >
> > > Brian
> > >
> > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ~
> > > Brian Batchelder | Hewlett-Packard |
> > > mailto:brianb@vcd.hp.com
> > > Connectivity Futurist | 1115 SE 164th Ave. | Phone:
> > (360)
> > > 212-4107
> > > DeskJet Printers | Vancouver, WA 98684 | Fax:
> > (360)
> > > 212-4227
> >
>
>
>