Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Beyond Getting Started Questions



on 1/25/03 10:00 PM, email@hidden at
email@hidden wrote:

> Subject: Beyond Getting Started Questions
> From: Bill Rector <email@hidden>
> To: <email@hidden>
Snip, snip
> I am developing a kext driver to support my specific hardware which uses a
> Cypress MPU. It enums as vendor specific. I already have an OS 9 driver and
> having mastered that, about 75% of that code and knowledge can be tossed out
> for OS X.
> 
> I've pretty much decided that what I'm doing requires a kernel driver. My
> driver needs to handle the following services:
> 1. Firmware loader. My hardware uses a I2C 32KB EEProm for boot and
> configurations and a 512KB Flash for MPU code and programmable logic
> firmware storage. By using the Cypress MPU, I can program a brand new or
> previous unit with new firmware. This also means that for new or wiped
> units, the service or client will need to also look for the default Cypress
> 0547 vendor ID. I suppose this can be done as personality setting in the
> kext's plist.
> 2. Data Acquisition. A client application must acquire a continuous data
> stream 96KB/s to 500KB/s over 256seconds minimum but typically all day long
> without any data dropouts. With a bulk pipe of 64Bytes, this means that a
> client app if doing Bulk transfers through IOUSBUserClientInit could not be
> pre-empted for very long.
> 3. Serial services. First, the MPU uses a console style interface on a pair
> of endpoints for command and monitoring by a separate client application.
> Second, the MPU provides an extra serial link to RS232 to enable the
> computer the computer to be connected over a 20Km RF Link. Third is a
> possible link to a RS232 GPS(currently the MPU handles all GPS traffic)

> Question#1.
> Does this look like the right approach?
IMHO, no it doesn't.

Nothing you've said indicates that you need a kernel driver. Your device
doesn't supply services to the file system, or to other kernel drivers.
Apple have done an excellent job of providing userland access to USB
devices. 500kB/sec all day long isn't going be a problem as long as your
users aren't running a scanner or hard disk on the same bus. You may want to
make your data-collection thread a real-time thread.

Although the maximum packet size on the bulk pipe may be 64 bytes, the host
controller takes care of packetizing transfers larger than that. There's
nothing to stop you from requesting 2MB of data over the bulk pipe. There's
certainly no need for you to send a request every 64 bytes if the device has
500kB to deliver, unless it implements a very inefficient protocol.

It is up to you to implement a communication protocol which allows you to
request a specific number of bytes, and to detect how many have been
received.

There's good sample code for loading firmware from userland on Apple's web
site, or in the USB SDK. If your device is going to be deployed outside a
lab, I'd ensure that the device powered on with my own vendor/product ID and
not that of Cypress.

Try doing all your development in userland. Trust me, you'll never want to
go near the kernel again!

Stuart

> Thanks for any insight,
> Bill Rector
> Codar Ocean Sensors
> 
> --__--__--
_______________________________________________
usb mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/usb
Do not post admin requests to the list. They will be ignored.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.