Bryan said:

The user’s install procedure includes...

Have you ever tried to install a recent HP printer? You must not, unde rno circumstances, connect the printer before installing the drivers. Setting up the firewall to use the printer in a network requires hours of searching in the Internet and creating dozens of rules for the firewall for various programs, libraries etc. They even send 'discover' unicasts that do not belong to the local network address - and expect an answer.
Still they seem to sell enough printers to continue this concept.

The install procedure you described is required when not following the correct install procedure or when developing the drivers (needing to update them).

Isn't usbser.sys a standard windows driver? On my system, it is from Microsoft. So why do you blame TI for something that is part of the OS?

Bryan said:

The new MSP430F6x are intriguing but with the use of the LCD pins, allows only one UART.

Well, you can't eat the cake and keep it. Using lots of pins for LCD leaves less pins available for peripherals. And if some are sacrificed for a second UART, people would complain about missing them.

BTW, the MSP430F67xx1 sub-family has four UARTs and still 8*40 segment LCD simultaneously. But I guess, the 128 pin form factor is then something to complain about.
Now a 14-pin, 320segment LCD, 4 UART chip simply isn't possible.

How does setting up a HP printer over the network have any relation to using USB?

The install procedure I described is right from the "Examples_Guide_MSP430_USB.pdf" " "2.5.4 Installing a CDC Interface on Windows 8".  It has nothing to do with, as you say, "required when not following the correct install procedure".  It IS the install procedure.  You should read it before you comment on it.

Yes usbser.sys is a standard windows driver.  It is so lacking that no other USB chip provider uses it.  Only Ti.  It is a basket full of problems.

I mentioned it is too bad they did not include UARTA1RX/TX in the list of items that Port Mapping Controller can assign i.e. digital functions to port pins.  There would be no "sacrificed for a second UART". 

Thanks for suggesting a look at the MSP430F67xxx.  Perhaps they could provide 40 LCD segments and two TX/RX uarts at the same time.  They are missing a TIMER_B put perhaps the RTC can be used for periodic wakeups.

Bryan said:

How does setting up a HP printer over the network have any relation to using USB?

It's related to your post and what you wrote about what TI should do to not lose customers.

Bryan said:

It IS the install procedure.

then follow it. As I said: on other products, the installation procedure is even more complex (and not even documented).

Bryan said:

Yes usbser.sys is a standard windows driver.  It is so lacking that no other USB chip provider uses it.  Only Ti.  It is a basket full of problems.

As is the whole Windows driver system. The changes Microsoft has done to it in Win8 didn't improve anything. It just renders all existing drivers useless and forces everyone to maintain multiple completely different driver mechanisms.

I agree tat TI is a big company and one should think there is enough manpower to come up with a better solution soon. However, TI has also a large portfolio, so the manpower per product is likely much smaller than with smaller companies who support only a few products. Also, Win8 is so new and the changes are so severe, that it takes some time to straighten all things out. If you look around, all kinds of developers are complaining about the new, poorly documented and not really working stuff.

Bryan said:

I mentioned it is too bad they did not include UARTA1RX/TX in the list of items that Port Mapping Controller can assign

Ah, okay, thsi wasn't clear. There are a lot of MSP430F6xxx chips now, so I dodn' tknwo which one you mean and assumed the chip you are talking about has only one UART.
Well, if you take a look at the port pin schematics, the port mapping controller is an enigma. No wonder that there is no 'map everything anywhere' feature. (especially the USCI_B mapping is a miracle, as it requires the port driver to support OC output)
My guess is that mapping to LCD pins won't work well. So a function is either on a LCD pin and not mappable, or mappable. (remember that you need to 'unmap' at least input functions before mapping them elsewhere) But that's just a guess.
Well, more features, more costs. And people always want things to be cheap.

If you really need a second UART on this MSP, then you'll have to go with 38 instead of 40 LCD segments. Since there is no fixed meaning which segment line drives which segment, you just lose two segments (or 8, if multiplexing)

Bryan said:

They are missing a TIMER_B

But have four TimerA instead. Well, with less CCR units. :(

Bryan said:

Yes usbser.sys is a standard windows driver.  It is so lacking that no other USB chip provider uses it.  Only Ti.  It is a basket full of problems.

Yes, usbser.sys is bad and you can complain to MS about that. Anyway, nobody forcing you to use it (CDC) on Win. I implemented with MSP430F5xx USB generic bulk transfer (winusb.sys)  without any problems.

http://forum.43oh.com/topic/2775-msp430-usb-benchmark

USB-UART bridges are different animals with dedicated drivers (chip producer writing their own drivers), completely different story than standard USB devices.

FTDI is just 1Mbps bridge chip, that can't compete with hi-speed USB transfer 1000 KB/s (based on MSP430F5xx USB module).

Thank you for that Zrno,

Our device allows users to utilize any terminal program, like hyperterminal, putty, etc., to open the USB virtual COM port and control the device, download ASCII data, etc. using ASCII characters.  Could not do that with winusb generic bulk.

Bryan

Bryan said:

Our device allows users to utilize any terminal program,

Well, then why don't you write a driver the utilizes your device? (I agree, it is easier to have it done by someone else) :)

Oh OK write a driver and get it certified.  Why do that when I can just use a FTDI chip?

 http://www.ftdichip.com/Drivers/VCP.htm

Bryan

Bryan said:

Oh OK write a driver and get it certified.  Why do that when I can just use a FTDI chip?

USB-serial bridge IC's are fixed function chips. It is logical for IC manufacturer to supply reference designs together with ready to use drivers - so OEM vendors needs just copy existing design, put everything on board, stick label on product and sell huge quantities.

Msp430 is completely different story, it is not fixed function, nor USB-serial bridge. I would not expect TI to manufacture flatbed scanner Windows drivers for my hypothethical scanner. Why do you ask for USB-serial bridge drivers?

Oh OK if one wants a CDC interface then throw out and ignore all the

MSP430 USB Developers Package

and write your own CDC code and write the drivers yourself and get them certified.

Bryan said:

Our device allows users to utilize any terminal program, like hyperterminal, putty, etc., to open the USB virtual COM port and control the device, download ASCII data, etc. using ASCII characters.  Could not do that with winusb generic bulk.

Yes, you can do the same with generic bulk, but in this case you must write your own (terminal) application as interface to your device. Instead of Win API WriteFile/ReadFile must be used WinUsb_WritePipe/WinUsb_ReadPipe. It's not too complicated, but it's also not a one-day job.

Bryan said:

Oh OK write a driver and get it certified.  Why do that when I can just use a FTDI chip?

I was using not-MSP430 uC with PL2303HXD bridge for fast data transfer (>2 Mbps) between PC and uC. Later I switched to MSP430F5xx USB devices, and there is no more way back. I was also downloaded source of MS CDC like driver, with idea to improve it, but later I gave up. For my needs, Win CDC default driver is just fine. If there is some special reason I can easily switch to generic bulk.

Bryan said:

Oh OK if one wants a CDC interface then throw out and ignore all the

MSP430 USB Developers Package

and write your own CDC code and write the drivers yourself and get them certified.

Yes. MSP430 USB Dev Pack is just example of how thing can be done. I write my own stack, and using it in every project. Same story with drivers. Everybody can (try to) write their own drivers or buy it from third part (for example something like http://www.jungo.com/st/products/windriver).