Thanks for your productive information.
My colleague has written a SBP-2 target software for our printer
optional board fitted with H8 CPU. The ROM size was 18k B.
Those source code was developed by C and assembler. Thus
we confirm Greg’s estimation for SBP-2 ROM size is correct.
And I also think this size of ROM or CPU would not be acceptable for
some consumer devices. For these devices, DPP could be a
desirable solution.
So please continue to explain your idea about 1394 printing.
Does your DPP seem to be stream style protocol? Or are you
going to have any plan to provide memory bus style protocol?
--------------------------------------------
-------------------------------
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: Tuesday, February 17, 1998 12:26 AM
To: Fumio Nagasaka
Cc: 'Stephen Holmstead'; 'Brian Batchelder';
p1394@pwg.org; 'PWG-C mailing'; Turner, Randy
Subject: Re[2]: Re[2]: P1394> Rough SBP-2 &
IP1394 core component ROM sizes
Hi Nagasaka-san,
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
> >
>
>
>