On Jul 27, 7:51=A0am, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
> If simple 'filtering' is what's required, I wonder if that can be done
> without implementing a full host USB stack. =A0Normally the host talks to=
the
> target mass storage device directly. =A0But if the host tries to write da=
ta
> blocks, the filter intercepts the write command, doesn't pass it on to th=
e
> device but returns an error result instead.
>
> Obviously it'll be more complex than that (effectively it's buffering and
> changing packets on the wire, through several layers of abstraction) but
> that would make it seem more like a slave device rather than a host. =A0T=
he
> big question is whether tampering with the results like this will confuse
> hosts or devices, and if you can do it without upsetting the protocol.
Hmm, how about instead of filtering out the writes, changing their
destination address to something impossible? Then the mass storage
device would do the complaining, and know it had hopefully taking care
of any synchronization issues.
Reply by Theo Markettos●July 27, 20092009-07-27
Mike Harrison <mike@whitewing.co.uk> wrote:
> I think you'll be well into FPGA territory if you don't want to slow
> anythning down, especially as micros with teh USB IO performance will
> likely come with a ton of other peripherals you don't need but will be
> paying for.
If simple 'filtering' is what's required, I wonder if that can be done
without implementing a full host USB stack. Normally the host talks to the
target mass storage device directly. But if the host tries to write data
blocks, the filter intercepts the write command, doesn't pass it on to the
device but returns an error result instead.
Obviously it'll be more complex than that (effectively it's buffering and
changing packets on the wire, through several layers of abstraction) but
that would make it seem more like a slave device rather than a host. The
big question is whether tampering with the results like this will confuse
hosts or devices, and if you can do it without upsetting the protocol.
This would be FPGA territory, but if successful perhaps less work than a
full host controller.
If you control the devices, as someone mentioned it may be easier to use
your own writeproof USB drive instead. If you can't buy one, perhaps
implement write protection for ATA - where doing it is much simpler - and
then you could put this between a USB-ATA bridge and a hard drive or
CompactFlash card. Or perhaps a further ATA-SATA or ATA-SD card bridge
(either as a chip you integrate or a commercial module).
Theo
Reply by Boudewijn Dijkstra●July 27, 20092009-07-27
> ubrida wrote:
>
>> The logic is very simple filtering. The minimum requirement is write
>> blocking (making a device act as if it is read only).
>
> I would strongly recommend you reflect that idea back to its source for
> clarification. USB sticks in the early days had write-protect switches.
> Somehow this feature seems to have become uncommon, but I still think
> you would be a lot better off acquiring some of those instead of doing
> your own stunt for this.
Be careful, such a switch could be a soft-switch where the driver is
responsible for the actual write-protection.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
Reply by ●July 26, 20092009-07-26
On Jul 26, 10:58 am, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> If you expect open-ended requirement changes like that already, the
> device you're talking about will for all practical intents and purposed
> end up being a full-blown PC. Nothing much short of that will have the
> spare CPU power to handle such infinite variety.
Yes, but thanks to things like the smartphone market, PC-class
functionality is turning up in highly integrated embedded multi-chip
modules.
Reply by linnix●July 26, 20092009-07-26
On Jul 26, 10:58=A0pm, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> ubrida wrote:
> > =A0 The logic is very simple filtering. =A0The minimum requirement is w=
rite
> > blocking (making a device act as if it is read only).
>
> I would strongly recommend you reflect that idea back to its source for
> clarification. =A0USB sticks in the early days had write-protect switches=
.
> =A0 Somehow this feature seems to have become uncommon, but I still think
> you would be a lot better off acquiring some of those instead of doing
> your own stunt for this.
>
If he can dictate the hardware selections, building the flash drives
with write protection is still cheaper and easier than this usb bridge
solution.
Reply by ●July 26, 20092009-07-26
ubrida wrote:
> The logic is very simple filtering. The minimum requirement is write
> blocking (making a device act as if it is read only).
I would strongly recommend you reflect that idea back to its source for
clarification. USB sticks in the early days had write-protect switches.
Somehow this feature seems to have become uncommon, but I still think
you would be a lot better off acquiring some of those instead of doing
your own stunt for this.
> Beyond this, more fine grained filtering is desirable. Filtering
> accurately describes all of the current goals. However follow on
> projects could explore other functions.
If you expect open-ended requirement changes like that already, the
device you're talking about will for all practical intents and purposed
end up being a full-blown PC. Nothing much short of that will have the
spare CPU power to handle such infinite variety.
Reply by linnix●July 26, 20092009-07-26
On Jul 26, 12:22=A0pm, "ubrida" <mjpar...@mail.com> wrote:
> Thanks for all the input. =A0To clarify a few points discussed, I will
> provide some more detail.
>
> Logic
> =A0 The logic is very simple filtering. =A0The minimum requirement is wri=
te
> blocking (making a device act as if it is read only). =A0Beyond this, mor=
e
> fine grained filtering is desirable. =A0Filtering accurately describes al=
l of
> the current goals. =A0However follow on projects could explore other
> functions.
>
> Why needed
> =A0 The previous post has it correct. =A0The PC cannot be trusted.
>
> Speed Requirement
> =A0 As already mentioned, using mass storage means the bandwidth requirem=
ent
> is not a gross overstatement. =A0The minimum requirement is to support hi=
gh
> end USB flash drives. =A0It is a goal to support external USB hard drives=
. =A0I
> termed the requirement at hi-speed because USB full-speed is not adequate=
.
> I would say that 240 mbps meets the minimum requirement. =A0However, my g=
uess
> is that if I can reach that lofty speed on hi-speed rated hardware, then =
I
> can probably achieve a bandwidth close to the experienced rates on direct=
ly
> connected external USB hard drives.
To give you some idea of what's necessary. The new Atmel SAM3U {ARM M3
cortex @ 96Mhz} supports hi-speed usb device. You will need this
class or better for host,
Reply by Mike Harrison●July 26, 20092009-07-26
On Sat, 25 Jul 2009 10:38:24 -0700 (PDT), cs_posting@hotmail.com wrote:
>On Jul 24, 4:23 pm, "ubrida" <mjpar...@mail.com> wrote:
>
>> I need to build a custom usb to usb bridge. At a high level it is like a
>> one port hub with custom logic in the middle. So I need 2 usb ports, one
>> host and one device, and a programable MCU. It needs to support Mass
>> Storage Devices at USB 2.0 Hi-Speed (480 mbps). I am hoping to use vendor
>> libraries for the Mass Storage Device specification.
>
>I think you might be able to accomplish something with one of the TI
>OMAP chips having both host and device interfaces. As others have
>pointed out its going to be very hard to do much processing at full
>USB bandwidth, but you might find you could go fast enough for your
>application.
>
>I'm not sure if it's possible to use both USB ports at the same time
>on the Beagle Board OMAP evaluation board - they had some problems on
>some versions with one of the USB ports and I think in some cases they
>just removed it.
I think you'll be well into FPGA territory if you don't want to slow anythning down, especially as
micros with teh USB IO performance will likely come with a ton of other peripherals you don't need
but will be paying for.
Reply by ubrida●July 26, 20092009-07-26
Thanks for all the input. To clarify a few points discussed, I will
provide some more detail.
Logic
The logic is very simple filtering. The minimum requirement is write
blocking (making a device act as if it is read only). Beyond this, more
fine grained filtering is desirable. Filtering accurately describes all of
the current goals. However follow on projects could explore other
functions.
Why needed
The previous post has it correct. The PC cannot be trusted.
Speed Requirement
As already mentioned, using mass storage means the bandwidth requirement
is not a gross overstatement. The minimum requirement is to support high
end USB flash drives. It is a goal to support external USB hard drives. I
termed the requirement at hi-speed because USB full-speed is not adequate.
I would say that 240 mbps meets the minimum requirement. However, my guess
is that if I can reach that lofty speed on hi-speed rated hardware, then I
can probably achieve a bandwidth close to the experienced rates on directly
connected external USB hard drives.
Reply by ●July 25, 20092009-07-25
On Jul 25, 1:47 pm, Paul Carpenter <p...@pcserviceselectronics.co.uk>
wrote:
> I cannot see why you would need a bridge device (host and slave/device)
> for mass storage device.
I'm betting he wants to do something like real time virus scanning, or
whole disk encryption, and to do it in a bridge device because he
doesn't trust or isn't allowed to modify the host PC operating system.