MCU with IEEE-1394 peripheral ?

Warning, FireWire is considered a moribund standard; eSATA and (soon) USB 3.0 have essentially killed it.

we have used the TSB41BA3 PHY and TSB12LV26 for the LLC, 1394 is a horrific convoluted expensive piece of crap

??????????????????????????????????

IEEE-1394 is far more involved than a standard UART, and at a guess I'd say it's at least as bad as a host-side USB.

If you get the standard you'll save it all back in less work, so figure how that reflects the amount of work you'll do.

(and, by the way, I like 1394, I just don't harbor any illusions about it).

From what little I've read, 1394 seems to be rather similar to SCSI (protocol-wise). Unlike USB, 1394 is peer-to-peer and is "interrupt-driven" rather than being polled like USB. That allows multiple transactions to be done in parallel (pretty much like SCSI).

Yes. It's a nice protocol, in its way. It's complex to deal with, but then it's very powerful. I was part of a group that used it very successfully (:-) to transmit video inside of a system; of all of the candidates that we looked at it was the first one to go obsolete :-(.

What about the MAC ? Apple have invested quite heavily in FireWire and even though it's market share is much lower than USB, there is still a significant number of devices out there. Also I have not seen the latest generation PC chip sets dropping it. Only the very low priced Motherboards do not have IEEE-1394 ports. From my googling efforts it also looks as if the TV / Movie industry level video cameras and support equipment uses IEEE-1394 extensively.

As long as I have a reasonable level of confidence that IEEE-1394 would be available on higher end laptops (Desktops one can add an interface card), then it is another candidate for communicating between a PC and an embedded device. With all the support available foe USB and ethernet, it is not too difficult to get some comms going, but a very different story if one has fairly tight timing for one's own app and the data rate one requires starts being over 50% of the USB or ethernet bandwidth. So I am looking for something where most of the communications overhead and timing is handled by hardware on the embedded side.

Regards Anton Erasmus

I believe some of the latest Macs do not have 1394 ?

Anton Erasmus schrieb:

Well, all 1394 chips I'm aware of need PCI. The easiest way to get an embedded system with 1394 would be a microcontroller with PCI bus, a Linux port and a 1394 controller as a Micro PCI card (like the WLAN cards found in notebooks).

Apple's removal of FireWire from their latest-generation portables is considered the final nail in the coffin.

The one really unique, compelling use for 1394 was importing video from miniDV (and digital 8) consumer camcorders, and it got that way because USB of the era when these came out did not have the bandwidth for decent video.

A year ago, I was worried about netbooks not having 1394, but at this point most of the camcorders I'd buy to pair with a netbook don't have it either, as they are all going to modern compression schemes and flash media, with USB 2.0 (or just moving the SD card) the new import mechanism.

For implementing your own device, USB 2.0 via something like the cypress family of parts (if you need to move a lot of data without interpreting it) or one of the higher performance cores with USB on it (if you need the device to think about the data) seems the best bet today - well understood, likely to be supported for quite some time yet.