Slashdot Mirror


Apple Releases Free, OS-Independent, FireWire SDK

mcwop writes "Apple announced the release of a free FireWire SDK for embedded devices. The kit is not OS-dependent. Is this a response to the release of USB 2.0 or is Apple simply trying to keep a steady stream of FireWire devices coming? What effect will this have on FireWire b? What are the effects on the Open Source community developing FireWire interfaces? Time will tell. Nonetheless this is an interesting development."

2 of 179 comments (clear)

  1. Sensationalist headlines by ranulf · · Score: 0, Redundant
    Apple Releases Free, OS-Independent, FireWire SDK

    Then reading the body: [...] The kit is not OS-dependent. [...]

    Still, it's definitely good news. With Apple providing royalty free licensing of the trademark, and free SDKs, they have substantially reduced the barriers to other people developing FireWire devices.

  2. Its polled on Mac. No PEER-to-PEER even in OS!!! by Anonymous Coward · · Score: -1, Redundant


    Its POLLED on Mac. No PEER-to-PEER even in OS!

    Apple has crippled Firewire capabilities though this firmware source they just aquired is semi good.

    If you copy from firewire (IEEE 1394) hard disk to another hard disk the speed is cut in HALF on the mac if not using a second firewire controller card.

    Example data comes in from one drive then has to share bus to get recopied bac from mac to destination drive.

    Thats seems logical but firewire has PEER-to-PEER block copying that safely works but apple does not bother supporting it in OS X.

    Worse... what pathetic support for firewire they do have is usually defective or slow... examples?

    Firewire WRITING on a Blue and White G3 tower using default apple ports is limited to HALF SPEED!!!! reading is full speed (38MB sec if the drives such as IBM can handle it).

    Firewire is buggy on apples... on occasion particular bit patterns seem prone to causing lockups or hanging on some models.

    Apple does not know how to use INTERRUPTS... they poll the firewire. POLL!!!! That does not seem so alarming but in SCSI and ATA on macs you can issue ios during a completion of an io interrupt and that new io can truly start running immediately (after too many recursive completions to prevent stack problems, a defferred completion will unfortunately kick in in some SIMs) but firewire is slow slow slow for transactions per second.

    A SCSI320 controller with ONE channel can issue and complete a complete IO in slightly less than 20 mictoseconds round trip.

    A 2Gigabit Fibre Channel card on a mac can HONESTLY issue and complete a SCSI command packet in slighlty longer (80 microseconds).

    A Firewire packet ???..... HA!!!! don;t make me laugh and spit up the food in my mouth even joking about how slow the mac OS X handles small firewire packets.

    some transfer in USER space as a feature (drivers in IOkit must not use that feature to be a valid Darwin boot device though)

    speaking of valid "boot devices"..... you CANNOT with any version of mac firmware.... boot a Blue&White G3 tower mac from its firewire ports!!! And other newer macs cannot boot RAID-ed firewire.

    Firewire is such a limited slow, buggy, crappy subset of SCSI and ATAPI in many ways that I feel its only suited for video cameras and little toy dongles.

    Imagine! Its 2002 and Firewire can only transfer data IN THEORY at a max of about 40 megabytes per second sustained using device chips such as a good Oxford 911 chip.

    Meanwhile SCSI160 is 160 megabytes per second (millions-of-bytes per second technically, not MB) and SCSI320 drives are available on price watch for dirt cheap that can transfer data to or from their internal caches at 320 megabytes per second.

    Fibre is going to 10 Gigabit tranceivers in 7 months for most of the top 5 vendors for the mac and the cards are laready all PCI-X >500 Megabyte per second pci cards....

    while firewire pokes along.

    Cypress and 4 other companies make CHEAP usb chips for usb 2.0 which technically are FASTER than firewire.... regretably these usb 2.0 chips usually use a slow crappy 8051 microcontroller, but some of the late-2002 chips can pump 96 MB sec between usb2.0 chip and dma ports. but these things are one FIFTH to one SEVENTH the price of the cheapest firewire chips.

    USB is technically a crappy protocol (based on serial chips in many pathetic ways), but I have written low level code for all technologies : SCSI, ATA, ATAPI, USB hihghspeed, Fibre, Firewire, iRDA and I have one thing to say.....

    install avirgin copy of OSX 10.1.3 on a dual cpu mac... then attach 6 or 7 firewire drives but make one path go through a high eng belkin 6 port consumer firewire hub.... then copy 40 to 70 gigabytes of mp3s, KABOOM low level user interface freeze repeatable after a few minutes of copying.....

    sure repeater power hubs are cool, sure firewire guranteed delivery video streams are cool, sure daisy chaining 6 or more drives into a 63 device tree is cool, sure it all is cool in principle.... BUT IT ALL CRASHES AND IT BUGGY POLLED SLOW JUNK!!!!

    I can get a usb controller with 8051 core for one dollar and 15 cents... it might not be as fast as firewire, or USB 2.0, but its a dollar 15 and does not hang a modern unix OS copying mp3s.

    Apples web site has the AUDACITY to even MENTION the words PEER-to-PEER SBP-2 as a buzzword on it. really : http://developer.apple.com/techpubs/macosx/Darwin/ IOKit/DeviceInterfaces/WorkingWFireWireDI/FWDevInt erfaces/FireWire_on_Mac_OS_X.html

    and the "cool" high-quality powerred firewire hub that helps the crappy mac OS sieze up is : http://www.macreview.com/Hardware/Hubs/Belkin/FW6P ortHubReview.html

    Newest osx10.2 for August build 10.2 6C15 (6C115?) does not seize the user interface anymore by the way, but all versions of Mac-O-Sux (os x) are very very slow for IO latency due to heavy driver model and class-happy insanity (though Objective C is amazingly fast compared to C++).

    To reiterate : Apples implementation in OS is POLLED crap. No PEER-to-PEER data! But at least that shrouded new open-platform firmware C code they now have is valuable (because they did not write it).

    I posted this again because it got modded to -1 by an apple appologist fanboy.