Jump to content

[Version 1] Sd/storage Controller


1n5aN1aC
 Share

Recommended Posts

Actually, I've been planning to add more device types in the next version of Teensyduino. Once that's released (there will be beta tests....), implementing this using the Arudino IDE will be as easy as just selecting it from the Tools menu.

In addition to a SD card connected to the 4 SPI pins, I also plan to support using the unused flash memory as a tiny read-only volume. You can expect example and documentation to be rough at first and become better over time....

Yes, it'll be a composite device which also provides a HID keyboard interface. Everything already written with Keyboard.print(), Keyboard.send_now(), etc should work when changing to this other device type.

Link to comment
Share on other sites

Iv been working on a nice plan on a system with switchs (like im sure youv seen) and having different modes on the teensy. One being used as a storage device such as this ;D Daisy chain a few large SD cards together to get ridiculous space >.< Thinking of 5 or 6 8GB cards. So, 40 or 48 gigs on an extremely small usb. XD I could sell these.

Link to comment
Share on other sites

Iv been working on a nice plan on a system with switchs (like im sure youv seen) and having different modes on the teensy. One being used as a storage device such as this ;D Daisy chain a few large SD cards together to get ridiculous space >.< Thinking of 5 or 6 8GB cards. So, 40 or 48 gigs on an extremely small usb. XD I could sell these.

http://www.google.com/products?hl=en&q...sa=N&tab=wf

Link to comment
Share on other sites

Actually, I've been planning to add more device types in the next version of Teensyduino. Once that's released (there will be beta tests....), implementing this using the Arudino IDE will be as easy as just selecting it from the Tools menu.

In addition to a SD card connected to the 4 SPI pins, I also plan to support using the unused flash memory as a tiny read-only volume. You can expect example and documentation to be rough at first and become better over time....

Yes, it'll be a composite device which also provides a HID keyboard interface. Everything already written with Keyboard.print(), Keyboard.send_now(), etc should work when changing to this other device type.

Is there ever a way to set a device to be 2 USB devices? a HID and a Mass Storage?

Make sure you let us know on Hak5 when you update the Arudino IDE

Thanks for all your work.

Link to comment
Share on other sites

A MicroSD breakout board would be better.

Would you believe I just sent in PCB files for a prototype. It's half the size of the Teensy, meant to mount above or below using the first six pins, just above and below the USB connector.

If everything goes perfectly, the soonest they could be manufactured and available in any quantity would be early to mid May.

Is there ever a way to set a device to be 2 USB devices? a HID and a Mass Storage?

The short answer: Yes.

Now, for the long answer......

USB has a lot of terminology which has very specific meaning. You probably know "host" is the PC, or whatever has the "A type" connector, and "device" is whatever has the "B type" connector. There can be only 1 host, which controls everything, and of course many devices. Because the functionality is completely different between a host and the devices, they used different shape connectors, so it's (supposed to be) impossible to plug devices together without a host, or more than 1 host connected together, even if someone makes a "gender changer".

With USB a "device", there are "configurations", "interfaces" and "endpoints". These are probably less familiar USB terms, unless you've designed a USB device or you just happen to like reading the 650 page USB 2.0 spec and the dozens of supplementary documents, adding up the thousands of pages.

Endpoints are similar to port numbers in TCP/IP networking. Just like how a server can have port 80 for http, port 25 for smtp, port 22 for ssh, and so on, a USB device can have many endpoints, each used for a specific purpose.

Similar to how IP-based networking has different protocols, like TCP and UDP, in USB there are 4 endpoint types, called Control, Bulk, Interrupt, and Isychronous. Control is a datagram protocol, with an extra 8 byte header, which allows the datagrams to be directed to a diverse number of logical targets within the device. The other three are unidirectional streaming protocols, similar to TCP, except of course TCP is bidirectional, so you need two endpoints for both directions. Like port numbers in TCP and UDP, endpoints are numbered 0 to 15. Endpoint 0 is always control type. Endpoints 1 to 15 can be any other types. (Teensy's hardware supports endpoints 1 to 6)

USB has a concept of "interfaces". An interface is basically just a group of endpoints, which together are intended for some purpose. While there's no direct equivalent in TCP/IP networking, you can think of FTP's "interface" (in active mode) as two TCP ports. Many interfaces uses 2 endpoints, one for sending and one for receiving. Sometimes more than 2 are needed, because the 3 non-control endpoint types have very different bandwidth and timing allocation. Sometimes only 1 is needed, such as most HID interfaces use a single endpoint for sending to the host, and for the very infrequent data from the host to HID (eg, keyboard LEDs), a control packet is sent on endpoint 0 (remember, the extra 8 byte header is very flexible and can specify packets to or from lots of locations, including of course interfaces).

I skipped "configurations", because they aren't so interesting. Basically, they're used in devices like webcams, where each configuration has different specs for its endpoints, usually offering lower bandwidth requirements. If the host knows there isn't much bandwidth available, it can choose one of the lower configurations. This happens before any device drivers are loaded by the operating system.

When you first plug in a USB device, the host uses endpoint 0 to read a bunch of binary data called "descriptors", which inform it about the device and all its configurations, interfaces and endpoints, and sometimes other optional data. Then it chooses a configuration (most devices have only 1). Then it loads drivers.

A windows (or mac, or linux) driver can be associated with the entire device, or with only 1 interface. In some cases, a driver can use more than 1 interface, but not the whole device (though Microsoft only recently supported this in XP-SP3 and Vista SP1, and Apple basically doesn't support it at all, so multi-interface driver associations are very rare).

Most devices with a proprietary driver from the manufacturer use whole-device driver association. The USB device has a "Vendor ID" which is assigned by the USB-IF (for a $2500 fee), and the vendor gives each product a unique "Product ID". They can also assign a revision code. Windows, Linux, and Mac OS-X first look at the VID/PID/Rev and then VID/PID. If a driver matches those numbers, it will load that driver to control the entire device.

Drivers can also be associated with just a single interface. Commonly single-interface drivers are provided with the operating system, and intended for the standardized USB device classes.

USB has many "Device Classes", such as HID and Mass Storage (though Microsoft sadly doesn't support most of them, other than HID and Mass Storage). These classes specify how an interface works, including how many and what types of endpoints it must have and the format of the data send/received on each, what additional messages it send or receives using endpoint 0, any additional descriptor data for detecting the details specific to that interface.

So, the long answer is yes, when there are multiple interfaces, it's called a "composite device" in USB lingo. Even though it's a single device, it contains multiple interface, each of which gets its own driver loaded by the operating system. To the end users, it's as if multiple USB devices were plugged in. But to us, those involved in development of such devices, terminology like "composite device" and the difference between a driver associating with the whole device versus only a single interface are important distinctions.

Link to comment
Share on other sites

If everything goes perfectly, the soonest they could be manufactured and available in any quantity would be early to mid May

Thats awesome news. Can't wait for it to be available. Let us know when you have any updates. Might be cool if a DIP switch shield could be designed for the Teency also.

Thanks for the informative post.

Glad to know that the Teency can act as a composite device utilizing multiple interfaces.

Link to comment
Share on other sites

Paul Stoffregen Wow, thanks for the long summary. I found it quite interesting. So it's actually pretty close to what I expected. I was pretty sure you could use it as a "composite" device, but I wasn't sure how hard it would be.

Link to comment
Share on other sites

http://code.google.com/p/sdfatlib/

However, the only read() is designed for debugging. It reads a file directly to serial. For a project of mine I had to modify that read() to read a byte at a specified position in the file. It wasn't hard to do.

Not that the library does take up a fair amount of memory. You could search for uFat/microFat libraries for the arduino which have some restrictions. There's a big thread on the arduino forums about this. The micro fat libraries are design for datalogging since most arduino users are doing robotics or sensor logs.

Edited by sirpoonga
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...