From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25629 invoked by alias); 4 May 2006 13:44:24 -0000 Received: (qmail 25617 invoked by uid 22791); 4 May 2006 13:44:21 -0000 X-Spam-Check-By: sourceware.org Received: from dns2-bos.paetec.net (HELO dns2-bos.paetec.net) (64.80.233.228) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 May 2006 13:44:13 +0000 Received: from dtcsrvr09.dtccom.com ([66.153.88.146]) by dns2-bos.paetec.net (8.13.6/8.13.6) with ESMTP id k44Di5hX000781; Thu, 4 May 2006 09:44:10 -0400 (EDT) Received: by dtcsrvr09.dtccom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 May 2006 09:43:27 -0400 Message-ID: From: "Doyle, Patrick" To: "'Andrew Lunn'" , "Doyle, Patrick" Cc: "'ecos-discuss@ecos.sourceware.org'" Date: Thu, 04 May 2006 13:44:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] USB MSD stack X-SW-Source: 2006-05/txt/msg00021.txt.bz2 > -----Original Message----- > From: Andrew Lunn [mailto:andrew@lunn.ch] > > Arn't these commands actually SCSI commands? And i assume these > commands are for read block/write block. How are you thinking about > mapping this onto a disk in eCos? How do you think you will solve the > concurency problems? I guess you will have FATFS running locally on > eCos and your host also using FAT, both accessing the same block > storage device. > > If you fancy going down the closed source, commercial path, > eCosCentric have the Jungo USB protocol stack. I expect this includes > MSD. > > I think i also remember a press release from ATMEL about a free MSD > implementation, but i don't remember the details. > > Andrew > Hi Andrew, Thanks for your thoughts... >From what I've learned so far, yes the commands are actually SCSI commands. They are transferred from the host to the device via one of the "Bulk" transport pipes define by USB. The device responds with standard SCSI status messages via a Bulk transport pipe. Data sectors are also exchanged between the host and the device via these pipes. That's what I know so far. The SCSI packets include things like "write the following block of data to sector 123 on your disk" and "please read sector 456 from your disk" (as well as things like "please tell me how many disks you have and how big they are). So, at that level, I wouldn't have FATFS running locally on eCos (not when I'm allowing the host to access the local storage), I will interact directly at the block level with the storage device (RAM, flash, SD-Card, etc...). As I said, it strikes me as a pretty simple protocol (read a block, write a block) and probably will take me longer to think about it than to write the code, but if somebody else has already thought about it and written the eCos code, I figured I would stand upon the shoulders of the giants who have preceeded me. As I look at this, I am becoming more concerned about the HID requirements for our product because a) I still don't know what I don't know about it; b) I've read that it requires "interrupt" transfers; c) I've read that the eCos stack in the CVS tree doesn't include "interrupt" transfers; d) I know more about SCSI than I do about HID; and e) I don't know very much at all about SCSI :-) All of that being said, I still need to finish the low level driver... off to coding land! --wpd -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss