This was the advantage of my "mass storage" device approach -- the user just deals with "files" accessed from his browser. If your "files" contain java applets, you could probably get lots of extra functionality than "plain old HTML" (though that forces the user to have java installed in his browser -- probably a reasonably safe bet?)
Why does this require more than a terminal program? I use a USB serial port with all sorts of software that is written to talk to a serial port. Can a USB device be configured to look like a serial port independent of what the USB chip is actually connected to? I would think you could use any interface you want from the MCU to the rest of the circuit, but the USB MCU should be able to fake out a serial port to the PC, no?
When I say I look forward to, I meant look *forward* to. I'm not saying it is this easy right now.
Has anyone considered USB development tools from
Rick
Double edged sword. 232 =3D slow and far, USB =3D short and fast. Most of my stuff would benefit more from the short and fast. USB can be sent over longer distances using repeaters or actually one port hubs up to some hundred feet, I believe. Never tested it though.
Rick
Yes, any USB uC can implement CDC device. Window can use VCOM (Virtual Com port) for them. The problem is that VCOMXX can be changing. I am upto VCOM17 on my PC, without anything in between 1 and 16.
High speed USB supports up to 5 meter of cable, and up to 7 tiers, including a host, a client, and 5 intermediate hubs, which means a maximum of 6x5 = 30 meter of cable.
Cable length is actually a timing constraint, which is specified as
Not a bad way to go. Still lacks power and differential support, which I think is more important than the various flow control and status lines.
At a huge cost in software though, especially host-side.
Clifford Heath
No. If you don't want to send differential data, pull the diff/power wire to 5V to provide power. The diff receiver on the other end can still get the noise immunity of diff wiring.
If you do want to send diff, then one of the data wires is always at 5V while the other's at 0, so a pair of diodes can extract power.
With a small receive buffer, the handshake circuits don't need the same data rate as the data lines, so arguably don't need differential wiring.
Chicken and egg problem though, no?
Clifford Heath.
If you want to look like a USB drive, you must also act like an USB drive (timeouts).
For more than two years ago, I had problems installing a wireless broadband modem (Huawei). It used one Windows drive letter (file system) for actual modem operation and an other for distributing the (Windows) drivers.
My installation attempts ended up with various timeout proplems.
I finally figured out that by first copying the installation software and drivers from the USB modem "disk drive" to an external drive (such as USB memory stick) the installation process went OK.
Apart from this, the modem has worked flawlessly, when I use the same USB port. Unfortunately using a diffeent USB purt caused a lot of problems.
I've recently been working on a new family of data acquisition modules. Main interface is TCP/IP (actually UDP - there are reasons for that). But from day one I had an NRZ serial interface (RS-232 or RS-422 or RS-485, depending on hardware) for debugging purposes. Since then it's grown - we now need to talk NRZ to a GPRS modem and a GPS module.
Serial comms are still useful. USB, not so much.
Steve
...
The alternative - long ago MacOS X begin to support IP-over-USB and IP- over-firewire - but this is not the point though.
The point is that you can communicate with your device via layer 2 mac/ ethernet/physical-addresses !
You do not need IP and the DHCP functionality.
You only need to write in the device mac-address to communicate with it. In principle the mac-address is unique in the whole world, but the mac-address is typically different on the different ports (USB, ethernet...).
With todays open-source ip-stacks, you can simply remove the ip-part and only use layer 2 communication. Maybe you could use PPP over ethernet II framing?
-layer 2 protocols:
e.g.
Other layer-2 examples over e.g. ethernet or 802.1 not used here: dhcp arp
802.1x (
More about it:
This class is generally implemented in embedded systems like mobile phones to achieve more than one functionality from the device, so that a phone may be used as a modem, fax or network port. The data interfaces are generally used to perform bulk data transfer. ..."
The GNU/Linux "usbnet" Driver Framework:
The current zcip software works with recent versions of usbnet. (There's also a version of this in current versions of Busybox.) It partially supports the goal of a fully hands-off user install experience, so that USB peripherals don't require any sysadmin attention at all during setup, even on networks without DHCP service. (Read more about the IETF Zero Configuration Networking working group.) ... NOTE for RNDIS users: MS-Windows has problems with its USB and RNDIS stacks, which can not be worked around by Linux peripherals. Symptoms include at one extreme a blue screen (panic), to stopping communication after a while, to (the mildest failure) just a temporary lockup that goes away after a while. ..."
If you use ethernet over USB/bluetooth... you can use Wireshark to capture your ethernet for debugging purposes.
...
Microsoft seem to support USB-CDC - it just has to be enabled?:
Drivers for the Supported USB Device Classes
Support for the Wireless Mobile Communication Device Class
Sure. And if you want to look like a DTE or DCE you also have timing constraints -- that goes without saying.
But, you can design an HTML "interface" that implicitly transfers information/commands just by noting which resources are accessed by the client. I.e., you don't have to dynamically serve up a (complex) page for each resource accessed.
Without specific requirements, it's hard to say which, if any, alternatives *will* work -- though we can suggest approaches that *might* work! (the rest is left as an exercise for the reader :> )
...
I wil try to address this here, if you by cost mean money.
If you choose the right microcontroller - the no:
Generally:
USB in a NutShell. Making sense of the USB standard:
Have you tried running the USBCV (compliance verifier) tool with your device? It's at:
ARM:
Migration from PIC to ARM Cortex MCU:
Embedded USB Device Stack:
LPC214x USB stack:
This page is the homepage for an open-source USB stack for the built- in USB controller in LPC214x microcontrollers:
Does ARM provide drivers for the USB controller on my development board?
AVR:
V-USB is a software-only implementation of a low-speed USB device for Atmel=92s AVR=AE microcontrollers, making it possible to build USB hardware with almost any AVR=AE microcontroller, not requiring any additional chip:
USBasp - USB programmer for Atmel AVR controllers
PIC:
USB Framework for PIC18, PIC24 & PIC32:
On 16/01/2011 8:20 PM, Glenn wrote: ....
The "latest" USB library for AVR is LUFA - Lightweight USB Framework for AVRs
Free, reasonably mature, used in Arduino Uno
Tom
Were those (elided) all *host* implementations?
And, what's the relative cost (development time, memory usage, etc.) of writing a UART handler?
The appeal of a serial port is that it is relatively light (in terms of pins on MCU), low memory requirements (buffers can be as small as you want (if you trade latency) numbering in handfuls of bytes, reasonably low overhead (especially if using a device with a deep buffer and/or carefully considering what you push through the interface), "simple" software design, appeal to existing devices (in industrial control applications), easier to test/validate (fewer "special cases") etc. USB is heavier-weight in all of these regards.
I don't know what you are speaking about. Physical interface: Connector, level converter? Logical interface?
The user will walk to the device, not lay a 100m cable to it. IOW 4m is long in this context.
Really long cables will be the mentioned process data buses.
Using a terminal program, there is little difference.
The OS will assume exclusive access, therefore cache data. I think it will be difficult to establish a dynamic data exchange.
And transferring arbitrary numbers from a web browser to a "mass storage" device will be also somewhat weird.
Oliver
It requires drivers to be installed with admin rights.
Yes, using a virtual comm port driver. Installation with admin rights, huge impact on target system.
Would you tolerate that every stupid device you want to configure installs a virtual port? You will run out of port numbers quickly.
IMO that's the wrong way, better would be to stick with EIA-232 and the user installs _one_ good USB serial converter.
I already wrote this 2011-01-14.
Oliver
The problem is that Windows doesn't supply a terminal program. All it comes with is "Hyperterminal". While it has the word "terminal" in it's name I don't think it qualifies as a terminal program. It's so bad it barely qualifies as a program at all.
1/2 ;)
It doesn't even have Hyperterminal any more...
For firmware updates I am just now trying a new method - for me - where the bootloader emulates a USB flash drive. It wasn't too hard to get going, has the advantage of no drivers required. Seems to work well. No more trying to get users to install drivers, or having the windows .exe attachments blocked by all three email accounts they give me.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required