Do you still use "RS232" or something else?

That is trivial. *You* are creating the files. *You* are supplying the VTOC to the browser/OS. The filenames need not be meaningful to the user -- they just have to be unique and easily mapped to recognizable accesses. E.g., files could be named "1", "2", "3",... and each be one block long *and* (coincidentally?) arranged on the medium such that file N is at block N thereby making the mapping process easily invertible.

Remember, you aren't trying to be a generic, repurposable storage device. Rather, just trying to act like an "address decoder". Similar to hanging a '138 on some address lines and using the decoded *strobe* outputs to "do things" regardless of the "data" on the bus at the time...

You're fetching a web page. Does the browser ignore "Expires" because it considers "file://" URL's to be "different" than other URL's? I didn't notice anything allowing that behavior in the spec...

Note that there are browser *bugs* that you have to work around but, IME, those fixes are trivial -- especially if you have no concern over the size/content of the "actual files" (since they aren't *really* files but, rather, just "file accesses").

IIRC, "Expires" was explicitly designed to tell *everything* between the "source" and "browser" NOT to cache the data. I.e., the onus is on the browser to tell the OS to "go back to the source" for each new reference to the URL.

I have no idea how anti-virus software works (my products are immune to virii and I don't use it "personally"). Are you claiming that

*any* reference by *any* piece of software to *any* storage medium leaves the door open for a virus scanner to poke around *everything* on that medium?

This should be easy to test. Put a few tens of thousands of 10KB files on a USB stick in a folder. Access *one* file in that folder. See how long the device stays "busy".

Better yet, do something similar with a floppy (smaller files) and see if the drive stays busy for "a second" or "minutes". Hmmm... I wonder if I have any tools that will log these accesses? I think there may be one of the SysInternals suite that can watch a medium and log all accesses to it. If so, I should be able to put N bogus pages on a thumb drive and watch to see what the browser *actually* does!

Reply to
D Yuniskis
Loading thread data ...

may

The problem is the OS sees any USB file storage as single ownership and therefore it can cache with impunity. And re-read requests will be satisfied from the read cache if possible, no differently than it would do from a local hard drive. After all the OS will see all writes to the device so it will know if it has been changed.

Worse than that, simply inserting the device into a USB port *may* initiate a full scan. It depends on the product and possibly scan settings. It is after all a foreign untrusted media. And, yes, I've seen it done. In some cases the it observed since the OS will refuse to allow the device to be shut down because the virus scanner is accessing it.

Robert

Reply to
Robert Adsett

Hmmm... it *thinks* it can cache with impunity. E.g., how does it deal with "smart devices" that *look* like mass storage devices? E.g., cameras, MP3 players...

Or, do those devices just inherently "have problems"?

Is the behavior inherent in the *driver* interface or at the filesystem level? Are *any* hooks exported to control it? Which OS's make this assumption? (I've seen nothing that explicitly *allows* it to be made -- hmmm, wrong choice of word)

It sees all writes *only* if it's assumption about being the sole owner is correct. What about SMART data on drives? What hook tells the OS that it *can't* cache that information (since the drive *will* be updating it WHILE the OS is accessing the drive)?

So, timestamps of *every* file on the media will change? I.e., how do you control wear on non-volatile media? You are saying that every "in use" block will be read. Each time the volume is mounted. What does that portend for solid state drives?

This seems like an interesting thing to "play" with! Maybe I'll drag some tools onto my laptop and fiddle with it on the plane...

Reply to
D Yuniskis

That's what others have said. I haven't empirically verified it -- in particular, how it is handled in browsers (which are supposed to be able to work-around caching).

*Any* interface that is commonplace on contemporary machines will be "complicated" (if you rule out installing software on the host).

Modern machines are rapidly moving to higher speed, higher abstraction, interfaces. USB, Firewire, Ethernet, Bluetooth... All have significant "stack sizes" on the client side.

If you want something that can be accessed from the host

*without* installing software, then you have to rely on some *existing* software -- e.g., to date, you have been relying on HyperTerminal (the only thing on a PC that gives the user the ability to "talk" to a serial port).

You could telnet to a remote device -- but then your device needs to support TCP. Since the serial port is becoming extinct, you can't "SLIP" (et al.) leaving Ethernet. But, the hardware and software costs of Ethernet are beyond your product's price point/capabilities.

Parallel ports are gone so you can't PLIP (or "whatever").

PC's don't usually have FW ports -- OTOH, Mac's do. Regardless, FW puts you in the same boat as USB (which is more ubiquitous from the client's side/implementation)

Wireless technologies require a device that has wireless capabilities (how about a WiFi phone as the user interface?). And, requires a significant footprint in your device.

Floppies are gone (I designed one device that used floppies as a transport medium for configuration -- but it also required a special application to write the floppies lest the user make syntactical errors).

The IDE interface is internal and obsolescent.

Using SATA puts you in the same boat as the "USB mass storage" device. The same can be said for any other "sneakernet" style interface (SD, MS, etc. cards).

PCMCIA interfaces tend only to be available on laptops. And, not *universally* so. Regardless, if you deal with a "memory style" interface, you're back in the above boat. Anything else requires software on the host.

PS/2 interfaces are obsolescent and, regardless, would undoubtedly require some application on the host to interact with such an "atypical" device.

Most USB devices require "administrator privilege". I think even new (non-network) printers can't be installed without it. Mass storage and HID seem to be the only exceptions.

Mass storage has more options available to "talk to it". HID requires something to interpret the information sent.

If your constraints remain inflexible (no software to install, small footprint in the device, etc.), then the only idea I can offer would be a device with two USB ports -- host mode on one of them. Insert device as a keyboard wedge (PS/2 would be far cheaper but requires obsolescent keyboards) and instruct the user to open, for example, "Notepad".

Then, push characters into notepad -- in effect, using it as a "text display". Respond to keystrokes from the keyboard that is now plugged into your device and update the "display" accordingly.

This is far too much of a kludge, for me! :-/ Too many things can go wrong if, for example, the focus shifts...

Find a robust USB-serial dongle and give your users instructions on how to install the drivers. Purchase a lifetime supply of these dongles and sell them to your users at "cost". (this is not an unreasonable approach; I have known many companies that relied on third party products to buy up lots of "new stock")

If your market can bear the "support cost", *buy* them a customized laptop that boots directly to *your* application (and nothing else!).

Reply to
D Yuniskis

I think the OP's point is that getting (reliable and available) serial ports on computers is becoming increasingly difficult. E.g., it is similar to "finding a 5in floppy".

While you can purchase USB-serial dongles, installing one on a machine requires having administrator privileges (PC-speak). So, it is a "less desirable" approach than it has been hysterically.

Yes, but the OP doesn't want to bear the cost of the NIC and stack. E.g., I use lighterweight protocols to connect "dumb peripherals" (e.g., motes) to a more "capable" host and then have that *host* export a more versatile interface to the user -- acting as an intermediary (i.e., the motes can be regarded as part of the host instead of as separate entities)

... unless it isn't available! :>

For "human" interaction, I have found EIA232 to always be fast enough. Especially with a good presentation layer mediating. Even at something as slow as 19200 baud, you can repaint an entire screen in a second (or less).

OTOH, if you are transfering *data* (configuration files, log files, firmware updates, etc.) it can be painfully slow! I grumble anytime I have to push/pull data to/from my Unisite over the serial port -- which can be necessary with bigger ROMs, etc.

Reply to
D Yuniskis

Actually, this approach might not be a bad one!

Your "problem" is obsolescent serial ports and flakey USB-serial dongles (and the "permissions" required to install them). I.e., this implies that your customers are willing to buy "an interface" to the existing serial port on your device(s).

USB-oriented interfaces have costs associated that you don't want/like (recurring costs if you move that functionality into the device; nonrecurring costs if you force the user to "install something").

[I'm still pushing the browser approach]

Why not give the user an ethernet interface that is NOT part of your device? I.e., instead of buying a USB-serial dongle, have them buy a "one port terminal server".

Yes, this is (considerably) more expensive than a USB serial dongle "commodity" product. But, they only need one of these for each system that wants to "troubleshoot" your device(s). Since "whatever" will have to be cabled to your device, they can simply cable *this* to your device (and "this" to their network/PC).

You can then telnet to the device and have it act as an EIA232 bridge.

You could eventually design a low-cost version that deals with your needs exclusively (to make this more affordable to the user). You could even opt to design *your* device to present a web interface to the user -- and translate the user's interactions with it's "served pages" into explicit EIA232 "commands".

This is similar to my placing a "capable host" above my motes -- except, in your case, that "capable host" looks even more like an "exclusive agent" ("host" when viewed from your device; "smart device" when viewed from the user's

*host*).

Again, without an understanding of your market, I can't analyze the cost-benefit tradeoffs.

But, you could pick up *a* "one port terminal server" and get a feel for how easy it would be to use...

Reply to
D Yuniskis

e may

They don't generally write to the storage while plugged into a PC so it's not a problem.

I know of people who have tried doing as you suggest and the result was data corruption.

Windows at least. USB is a master slave arrangement. I think it's inherit in the definition of the drive profile that the host is the single owner of the storage (it can reformat after all). But I've never looked it up.

That's the point.

What are you referring to? I don't know of any drive that updates file data while running in a PC.

ve

Don't know, haven't verified. Just seen that it happens. Not with all combinations of tools but it does happen.

Robert

Reply to
Robert Adsett

The same. Which is why the saner ones of those types of devices switch modes when connected to a PC. They stop being cameras or whatever, and become pure mass storage devices.

They're all entitled to making it. You don't get to both have the cake and eat it. If your device claims to be a mass storage device, it _has_ to behave like one.

USB mass storage doesn't have that. SMART is a side channel of hard drive interfaces.

Reply to
Hans-Bernhard Bröker

I think you are misunderstanding the issues here. A "mass storage device" USB class is a mass storage device - like a hard disk. When a computer is accessing it, it does so in exactly the same way as if it were accessing a hard disk. That means the computer assumes full control over all writes to the disk while it is mounted. (There are some filesystems that allow for multiple systems to write concurrently to the same disk, but you can be sure that you won't find them on Windows!).

So no, cameras, MP3 players, etc., have no problems - they play by the rules and don't try to write to the disk while it is mounted on a host system. They normally won't even try to read from the disk while it is mounted, although that can be done safely to some extent, if you are /very/ careful (some systems use that as a method for updating firmware, for example).

This behaviour is inherent in the definition of a storage device. All OS's will assume they have complete control over the file system when it is mounted, with the possible exception of ancient DOS systems that didn't do much caching. Non-windows systems typically make significantly better use of caching than Windows does, so you will see the effect more there.

SMART data is not part of the file system, and is not read as blocks from the disk. It is read using specific ioctls (i.e., disk commands that don't correspond to block reads).

The host /is/ the sole owner of the disk itself, and thus it makes a safe assumption that it knows about all writes.

If you run anti-virus software, you have very little control over it. It can do anything other privileged software can do. So if the AV authors think it is a good idea to read every file on a USB stick when it is inserted, then that's what it will do.

Reply to
David Brown

I just did a quick check of the size of the files in the directory - I didn't look at exactly what they were. But it's not important if it is

5 MB or 10 MB - it is still much larger than a simple terminal emulator (unsurprisingly, since it is /not/ just a simple terminal emulator).

Maybe, maybe not - I haven't looked. I was just trying to say that having lots of registry entries is something that makes a program "not lightweight", even if it happens to be small in size. Other "not lightweight" characteristics (that TTP mostly doesn't have) include requirements for particular software (exact service pack numbers, dotnot libraries, etc.), changes to environment variables, extra startup program entries, extra programs, requirements to reboot the machine under installation or removal, etc.

TTP has extra unnecessary programs (such as "collector") that are installed by default, and start up automatically. It is therefore not a lightweight program, by my definition. It also has lots of features beyond being a simple terminal emulator, it is therefore not a lightweight terminal emulator (even if you don't install the optional software).

I am not saying that TTP is bloated, or that it is /bad/ that it is not lightweight. I find some of TTP's extra features (such as the ssh client and the macros) very useful.

Reply to
David Brown

Well I get that, yes, my point is that adapting to what MS & Intel do is doing work for them. Not that I can offer Oliver some alternative path, just observing and moaning, I guess (but moaning putting my money where my mouth is).

I get that, too - and I made it clear in my first post. It is insane to expect a NIC + tcp stack on top of a tiny hc08 or something. OTOH, getting a 400 MHz power (PPC) SOC consuming just 1W and costing tens of dollars has been possible for years now, this is the other extreme.

My point, they made USB exactly to gain more control. There was no compelling technical reason not to define a connector with power on it for Ethernet back then instead of defining a standard they would control. And if there is no decent USB RS232 converter on the market (which appears to be the case), this is only one more reason for me to treat wintel systems as what they are, computerized TV sets. So far they are forced to have Ethernet - I am sure they are working on that problem they have, too.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

I believe that quite a lot of cameras have (or perhaps just can) connect their USB ports using a different protocol/profile than MSC (PTP).

formatting link

This might be so that they can avoid the caching issue, or perhaps it's a step towards avoiding having to expose (and license) FAT file systems. Dunno.

Cheers,

--
Andrew
Reply to
Andrew Reilly
[...]

Also MTP and PTP work without installation, put HID seems to be simpler and there are lots of code samples and even extremly simple hardware solutions.

It could be used to read and store configuration with a text editor, but not for interactive things. Larger footprint than HID.

Try this with a notebook computer.

An euphemism, IMO.

The Ethernet EIA232 thing you mentioned in the next posting is simpler and more elegant. In the past, we already considered supplying such a tool, but it would have the already mentioned connectivity problems if the PC Ethernet port can't be used exclusively, and often it would be not where it's needed (unscheduled service in the field).

That's what we recommend today if the customer didn't buy a good computer _with_ comm port.

I even give them out for free.

The "not available in the field" problem still applies. Often we have to deal with the solutions the field worker already has on his computer. And they often use crappy USB UART dongles.

Oliver

--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

USB, not

because

operating

phone to

operating

Mac OS

it.

a

the

If the device has a device id, then you only get one COM port. If it doesn`t you get a new COM port if you change the USB port. BR, Ulf Samuelsson

--
Best Regards,
Ulf Samuelsson
Reply to
Ulf Samuelsson

not

because

operating

All it

in

so

where

well. No

.exe

I have an SD card aware bootloader that can boot U-Boot/Linux or the USB MSA from the SD Card and this is GREAT. The Bootloader is stored on the SD Card so no flash in the system. BR Ulf Samuelsson

On serial comms: I really wish SLIM Bus would take off.

28.8 kbps - 28.8 Mbps. Two wires Multidrop Peer to peer Automatic configuration of network Isochronus operation BR Ulf Samuelsson
--
Best Regards,
Ulf Samuelsson
Reply to
Ulf Samuelsson

serial

Still have RS232 on my laptop - It is old... The plans for a new laptop would be an Expresscard where the serial port is on PCI Express and not on USB. BR Ulf Samuelsson

--
Best Regards,
Ulf Samuelsson
Reply to
Ulf Samuelsson

I can beat that: I still have a parallel printer port on the laptop. ;-) An old HP workhorse but it's really my main machine. Had to scrub and reload WinXP from scratch recently (Windows had rusted too much) but it's otherwise been a champion.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb
[...]

Several new notebook PCs are offered with a real serial port, but not many, so the card might be the preferred method.

Pay attention not to get a disguised USB interface.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

Although few laptops come with a serial port (or parallel port), a fair number of docking stations have them. We got some Dell laptops about a year or two ago, with docking stations with a parallel port and a serial port. It's not quite as good as having it on the laptop itself, but the chances are if you've room on the desk for the electronics, you've room for the docking station.

Reply to
David Brown

Dnia Mon, 17 Jan 2011 08:21:29 -0700, hamilton napisa³(a):

Terminal

formatting link

Single file, size: 288kB, without installation. Display in ASCII, HEX, BIN, DEC.

pgw

Reply to
pgw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.