• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sending data direct to USB in OSX
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sending data direct to USB in OSX


  • Subject: Re: Sending data direct to USB in OSX
  • From: Graff <email@hidden>
  • Date: Sun, 14 Mar 2004 22:40:04 -0500

On Mar 14, 2004, at 9:30 PM, Doug McNutt wrote:

At 17:58 -0500 3/14/04, Graff wrote:
Isn't the /dev directory the attachment point for the device in question, not the drivers per se? It sounds like the driver did the right thing and properly translated the text you sent to it. I'm not sure if I'd trust this method without prior knowledge as to if the device driver handles input in this manner. For example, if there was a USB drive at the other end of that USB cable what would sending raw text do? Create a file and start filling it with the data? Start overwriting the disk headers with the text? You don't really know if you haven't read the documentation and thus you could cause big trouble.

The Delcom folks seem to know what they're doing but they are UNIX-oriented rather than Mac-oriented. USB devices have registered address information which allows a "driver" to know which physically connected USB device to connect to. When you're using the Delcom sampler you're using one of their registered addressed which will not be mistaken for a disk. When a hot-plugin occurs the registered address gets converted to one of 127 local USB addresses which are guaranteed to be unique on a particular USB.

No, you misunderstand what I mean. Yes, a registered address on a USB bus is pretty much guaranteed to get the data intended for it, no question about that. I was just using a drive as an example of a seperate case where sending raw data to a /dev entry could be a bad thing.

In the case of the Delcom chip piping raw text did no harm because the signal was not being used for anything yet. The chip just passes the signal on to whatever it is connected to. Say however that the chip is connected to a device and that the bit pattern 0111 means tells that device to "erase firmware". Now someone pipes a bell character (ASCII 7) directly into the /dev entry for the device, which becomes 00000111 and is sent to the device, which is interpreted as the command to erase firmware... you see what I mean.

I'm not saying that such a dumb and unlikely series of events will happen, just that you should never mess around with stuff like /dev entries unless you really understand the device in question. That's why I asked him to provide more information on the device, so that we could give the best possible (and safest) answer.

- Ken
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.


References: 
 >Sending data direct to USB in OSX (From: Rod McDevitt <email@hidden>)
 >Re: Sending data direct to USB in OSX (From: Doug McNutt <email@hidden>)
 >Re: Sending data direct to USB in OSX (From: Graff <email@hidden>)
 >Re: Sending data direct to USB in OSX (From: Doug McNutt <email@hidden>)

  • Prev by Date: Re: floating point idle delays, 'with timeout' and the date class
  • Next by Date: Re: floating point idle delays, 'with timeout' and the date class
  • Previous by thread: Re: Sending data direct to USB in OSX
  • Next by thread: Re: Sending data direct to USB in OSX
  • Index(es):
    • Date
    • Thread