Evolution of usb connector?

#50 Reply
Posted by coppercone2 on 21 Dec, 2018 05:20
I like rs232 for lab work because i don't want to deal with USB but I think using it for consumer products is kind of a step backwards

my main interest in it is as a charge port however, since its literary everywhere and its excellent for gadgets. You have like a 20% chance of finding someone on the street with a portable battery if you need it.

#51 Reply
Posted by IDEngineer on 21 Dec, 2018 05:23
Quote from: westfw on 21 Dec, 2018 04:58
USB has become a bit cluttered with feature-itis, and maybe some cronyism. But in its original form at only 11Mbps and with the "huge" connectors, it was a pretty brilliant solution to real problems that were plaguing the industry.
That's exactly what I meant when I said:
Quote
USB has definitely suffered from feature creep
...and when I said that RS-232C was "simple", remember it was at its heart a three-wire connection, one of which was ground so really just two wires. Hey, sometimes you had to cross them so TX was connected to RX. But the drivers tolerated misconnection like that, so no harm done. And once it was connected you could be exchanging data in minutes. Meanwhile, have you read the USB 3.0 spec? It's hundreds of pages long, and the "basic" steps just to establish a connection between two logical endpoints is anything but trivial.

I like USB. It was a good solution to a real problem of multiple dissimilar connectors, etc. But when I'm slogging through another "standard" USB implementation, I often pine for the simplicity of good ol' serial. Have you tried to work with the USB stack in Android, for example? There's a nasty bug in its logical disconnect routines that cannot be worked around except with a physical disconnect. The bug has been acknowledged by the dev team... it's in the buglist... but in the three years since it was first reported and confirmed, there's been absolutely ZERO work done on it. Sure one could fork your own version of the Android source and fix it (the fix is trivial, literally already documented in the buglist!) but then you're condemned to repeat the fix with every release, for every platform.... Ugh.

#52 Reply
Posted by tooki on 21 Dec, 2018 12:48
USB vs RS-232 (or any similar serial standard like RS-422 or RS-485) are so different as to be barely comparable.

Yes, for an engineer, serial is far easier to work with. But for an end user, it's much, much more complex. And conversely, for a user, serial is a nightmare, but USB is simple. Why? Because in getting things to work, the effort has to come into play somewhere in the process. And when it comes to user-friendliness, the effort comes on the engineering side. (I'm a usability guy, bear in mind.)

Suppose we'd created "RS-232 version 10" by now, with better, standardized connectors (so no gender changers, null modem cables, etc.) and modern data rates, but had left the protocol as simple as before (i.e. essentially nonexistent). A user setting up an RS-232v10 audio interface, for example, would have to 1. choose one of the 10 potential ports on the computer (and remember the port number), 2. install a driver (assuming one exists for their OS — and hope it works), and potentially 3. configure the data format on the port. In USB, this all happens automatically.

Why? Because the USB standards perform far more layers of abstraction, including foundation specs for all kinds of devices, so that we don't need separate drivers for each model of a type of device. (If we ever manage to crack generic printer drivers, we'll be pretty much done!) It's complex for the engineer so that it's simple for the user. And this is, for anything distantly approaching a mass-market device, unequivocally a good thing.

And for stuff like lab gear… well, doesn't it all use USB as a serial port anyway? All the gear I have presents a simple COM port.

#53 Reply
Posted by tooki on 21 Dec, 2018 13:03
Quote from: IDEngineer on 20 Dec, 2018 21:08
I will say, though, that as a hardware/firmware/software Engineer USB has definitely suffered from feature creep.
Quote from: westfw on 21 Dec, 2018 04:58
USB has become a bit cluttered with feature-itis, and maybe some cronyism. But in its original form at only 11Mbps and with the "huge" connectors, it was a pretty brilliant solution to real problems that were plaguing the industry.

The "feature creep" of USB is the filling in the gaps of features needed to make many use cases work correctly.

Remember, the original USB 1.0/1.1 spec was intended only for low-speed devices like input devices (keyboards, mice, joysticks, etc), basic printers, and random gadgets. It was not intended as a high-speed bus for high-bandwidth or latency-sensitive applications. FireWire was meant to cover those use cases.

As it became clear that most computer and device vendors didn't want to support two different buses, Intel created USB 2.0, which adopted many of FireWire's advantages (high data rate, isochronous transfer modes, etc) to allow USB to cover use cases like mass storage and realtime video.

All the while, for both USB 1.x and 2.0, the USB consortium worked on creating more and more generic drivers for different devices. People forget that the only things that actually had generic drivers in the beginning were keyboards and mice, and even that was only very basic support (like any kind of media keys, extra mouse buttons, etc). Early USB audio, serial, scanners, disk drives, GPS receivers, webcams, UPSs… all of it needed vendor-specific drivers because there were no standards. USB Mass Storage, audio, and UPS came first. And progressively we have gotten capable generic drivers for nearly any kind of USB device except printers (and given Apple's example with AirPrint, as well as how PPDs enabled any PostScript-printing-capable OS to properly use any PostScript printer, it seems to me that there's no reason why the USB printing class can't be finally made to actually work without device-specific drivers).

So it's not "bloat", it's all things added specifically to eliminate the need for device-specific drivers. (A great example of this at the low level is isochronous transfers, added to make sure that streaming video is guaranteed its required bandwidth with deterministic latency.)

#54 Reply
Posted by james_s on 21 Dec, 2018 17:47
Quote from: tooki on 21 Dec, 2018 12:48
Yes, for an engineer, serial is far easier to work with. But for an end user, it's much, much more complex. And conversely, for a user, serial is a nightmare, but USB is simple. Why? Because in getting things to work, the effort has to come into play somewhere in the process. And when it comes to user-friendliness, the effort comes on the engineering side. (I'm a usability guy, bear in mind.)

We are engineers, and thus discussing these things from an engineer's standpoint. Serial is at least an order of magnitude simpler compared to USB. For the end user yes, obviously USB is easier, but that's because it can be viewed as a black box, you just plug it in and it works, that's not the issue here.

Now try using a basic microcontroller and bit-banging your communication interface. Anybody who has ever tried to bit bang USB quickly finds out just how complex it really is. Bit banging RS232 is super easy, nothing to it.

#55 Reply
Posted by tooki on 22 Dec, 2018 01:02
Yeah. Gosh, it’s almost as though I addressed this in my rather detailed posts...

#56 Reply
Posted by westfw on 22 Dec, 2018 03:26
Quote from: james_s on Yesterday at 10:13:14 pm
A serial port is still simpler though ... No drivers, no handshaking

Hmm. So you never used a serial mouse or more than two uarts on a PC, eh? Drivers required. Separate drivers for deep FIFO UARTs. Interrupt conflicts, and separate drivers for different vendors that handle them differently. Inherent performance issues because it's fundamentally a byte-at-time protocol not well suited toward being handled by DMA/etc. No "msg" or packet modes, leading to added overhead and protocols (drivers) for anything that isn't a single-byte protocol. Thousands of interrupts per second, per port, usually on legacy buses that do horrible things to modern high speed CPUs.
Don't confuse "the driver for the limited case that I wanted to use is built-in" with "complex drivers aren't required." I've written async drivers for fancy (and dumb) uarts that support character traffic, SLIP, PPP, and "other" things, and it's really not that much easier than a higher-level IO device. Especially if you want 10+ to 1500ish ports per box...

you can put a scope on it and see the bits, decode them by hand if you like.

Granted... And those little LED breakouts that I mentioned previously were pretty useful for passive devices...
Not that we didn't spend tens of thousands of dollars on rs232 "protocol analyzers" anyway...

>Remember, the original USB 1.0/1.1 spec was intended only for low-speed devices like input devices (keyboards, mice, joysticks, etc), basic printers, and random gadgets. It was not intended as a high-speed bus for high-bandwidth or latency-sensitive applications.
Even USB 1.0 had "full speed" mode and isochronous transfers. 11Mbps was just "pretty fast" for those days...

By bloat in USB, I'm talking about adding a new data speed (needs negotiated!) every version ("full speed", "high speed", "super speed", etc...), power delivery negotiation of various sorts, etc. All needing to be backward compatible. Nice for users, not so nice as clean engineering. Not that you can really separate the "engineering niceness" from the "user usability" (perhaps USB was one of the first IO protocols to recognize that need...)

Quote
[You can bit-bang RS232]
No you can't. You can bit-bang the uart part, and you still need external drivers to get rs232 (theoretically, anyway.) I can go to sparkfun, or aliexpress, and the cost of a uart-to-rs232 adapter (including official connector) and a uart-to-usb adapter (with official connector) are about the same. And you can still bit-bang the uart side from your "simple" micro. (Hmm. I wonder why there aren't any GP micros that have a full bridge for fixed USB protocols (HID or UART.) Seems like it would be quite popular with the "doing all the USB stuff is too complicated" crowd...)

#57 Reply
Posted by james_s on 22 Dec, 2018 05:58
Quote from: westfw on 22 Dec, 2018 03:26
Hmm. So you never used a serial mouse or more than two uarts on a PC, eh? Drivers required. Separate drivers for deep FIFO UARTs. Interrupt conflicts, and separate drivers for different vendors that handle them differently.

No you can't. You can bit-bang the uart part, and you still need external drivers to get rs232 (theoretically, anyway.) I can go to sparkfun, or aliexpress, and the cost of a uart-to-rs232 adapter (including official connector) and a uart-to-usb adapter (with official connector) are about the same. And you can still bit-bang the uart side from your "simple" micro. (Hmm. I wonder why there aren't any GP micros that have a full bridge for fixed USB protocols (HID or UART.) Seems like it would be quite popular with the "doing all the USB stuff is too complicated" crowd...)

*sigh*

Maybe some day I'll learn to remind myself before posting how insanely pedantic some people are here, everything has to be spelled out explicitly right down to the letter, can't infer anything. I'm not even sure if this is because people honestly can't figure it out, or whether they enjoy being deliberately obtuse but it's not something I've encountered in any other kind of forum.

Who is talking about mice? Yes for a serial mouse you need a driver, just like for a USB mouse you need a driver, normally it's built into the PC but it's still there. No I don't think I ever used more than two serial ports on a PC back before the days of USB serial, although as I recall it was not too terribly difficult to use up to four. Have you written a mouse driver for both serial and USB at a low level? I'd be seriously shocked if the USB mouse driver is less than 10x the amount of code and that's being very conservative. I have a serial port on my Apple II, I have a serial port on most of my FPGA retro computing platforms. There are serial UARTs built into the 8 bit AVRs I use, the last hardware job I had our products all had serial debug ports built in. It's stil the defacto standard even today because it's dead simple, no fuss, 3 wires, it can connect to anything and just works.

And yes I know that RS232 technically specifies the hardware and voltage levels but colloquially it is a term that is often used to describe any "traditional" serial communications, even if the actual levels are simply TTL. You knew what I was talking about didn't you? If I just called it "serial" I suppose someone would ask if I meant USB, or SAS, DSI, or some other nonsense rather than figuring it out from the context.

I never thought I'd encounter someone claiming that USB is simpler than plain old serial though. I mean 2 wires and a ground, no handshaking needed, you don't even need to go both ways, if one direction is ok you only need two wires. It's been around since what, the 1960s? It can be built in hardware using jellybean TTL ICs. Try building a USB interface out of TTL ICs and then tell me how much simpler it is. Decap a USB IC and compare the transistor count to an old fashioned UART, I'm betting the difference is greater than an order of magnitude.

#58 Reply
Posted by Siwastaja on 22 Dec, 2018 08:15
Quote from: westfw on 22 Dec, 2018 03:26

Quote from: james_s on Yesterday at 10:13:14 pm
A serial port is still simpler though ... No drivers, no handshaking

Hmm. So you never used a serial mouse or more than two uarts on a PC, eh? Drivers required. Separate drivers for deep FIFO UARTs. Interrupt conflicts, and separate drivers for different vendors that handle them differently. Inherent performance issues because it's fundamentally a byte-at-time protocol not well suited toward being handled by DMA/etc. No "msg" or packet modes, leading to added overhead and protocols (drivers) for anything that isn't a single-byte protocol. Thousands of interrupts per second, per port, usually on legacy buses that do horrible things to modern high speed CPUs.

It's almost like if we replace a slowly evolved bunch of incompatible things, designed for small niche market of computing back then, with a clean-sheet design that's designed grounds-up exactly to support keyboards, mice, etc., with massive design budget due to it being designed for markets orders of magnitudes bigger, it tends to work for those specific purposes it's designed for; even if it's internally more complex. If it didn't, it wouldn't fly.

It's almost if the software has evolved to implement complex automatic operations of probing devices, and installing drivers automatically; despite the lower level being much more complex. It's almost if this has something to do with computers becoming mass market consumer devices, and having excess CPU and RAM to write more complex software.

Yet, a funny anecdote: when I needed to install Windows on my machine which has no issues whatsoever running Linux, my mouse didn't work with Windows 7 installer. Third mouse I tried worked, so I was able to install Windows, and download and install a driver manually, to make a freaking USB mouse work on Windows 7.

#59 Reply
Posted by IDEngineer on 22 Dec, 2018 19:24
My bottom line: USB has grown so far past its original intentions that there is also a need for a much simpler serial interface to fill the role for which USB was originally intended. For example, SPI or I2C could provide a modest performance, easy-to-implement serial comm standard that would cover perhaps 75% of the connections now using USB. I2C accommodates addressing multiple devices on shared serial data lines, and SPI can support data rates of 1MHz (easily) and up to 10MHz (with good cabling). Both of these can be implemented by bit-banging at the lowest level, and are incorporated as on-chip peripherals in a huge number of MCU's for midrange cost and performance.

Let USB3+ handle the high data rates, and use a standardized connector for an SPI or I2C lower speed "bus", and you've got the vast majority of usage cases covered with R&D and production costs that scale with required performance.

#60 Reply
Posted by james_s on 22 Dec, 2018 23:46
Is there any case not to just stick with RS232 or the TTL equivalent for applications where you need a really basic low level solution and use USB for everything else? I mean USB does work quite well, and treated as a black box it is simple despite the underlying complexity. I don't really see a need for yet another standard to fill that gap. USB 1.0 is still around.

#61 Reply
Posted by IDEngineer on 23 Dec, 2018 02:33
Quote from: james_s on 22 Dec, 2018 23:46
Is there any case not to just stick with RS232 or the TTL equivalent for applications where you need a really basic low level solution....
RS-232C (at any voltage level) generally maxed out around 115Kbps. Still fast enough for many applications these days, but I was giving the nod to a couple of more modern standards (SPI and I2C) if only because they are newer and support faster data rates and multiple devices on the bus whereas RS-232C is point to point only. SPI and/or I2C would give you reasonable data rates, multiple devices, and ultra-simple implementation; they'd be worthy successors to the old COM1/COM2 type connections for anything that doesn't require USB's fastest data rates or implementation complexity.

#62 Reply
Posted by james_s on 23 Dec, 2018 06:01
Some of the more modern RS232 UARTs can go up beyond 1Mbps, traditional serial based peripherals never got that fast but that's only because such peripherals stopped being developed for the most part well over a decade ago. There's nothing fundamentally limiting the standard to such low speeds, they are just what is supported by legacy peripherals.

#63 Reply
Posted by westfw on 23 Dec, 2018 09:44
Quote
Is there any case not to just stick with RS232 or the TTL equivalent
I mentioned "performance issues" and the difficulties with "substantial" numbers of serial ports on the host...Y'all are not realizing just how horrible host-side UARTs can be. (Sure, you can use USB/Serial on the host side, and it's a little better. Do you consider that "USB" or "RS232"? I guess "host-side" USB on a microcontroller is equally problematic, making non-USB protocols more desirable for micro-to-micro communications.

Quote
can be implemented by bit-banging
I'm not sure I understand the desire to "bit bang." It used to be that a $4 microcontroller (Q1 from hobbyist sources) like the PIC16F84 could bit-bang a UART. Good, I guess. It's been a long time since a $4 micro hasn't included UART hardware, and more recently it will come with a full-speed 6-endpoint USB peripheral controller (and a software library that makes that somewhat easier to use.)(and of course, bit-banging more than one port at a time gets problematic.)

Quote
Have you written a mouse driver for both serial and USB at a low level?
Yeah, I think I did, back in the DOS days. More "library" than "driver", since DOS didn't do interrupts for COM ports, each program that wanted to do anything "moderately real" with the UARTs had to diddle the vectors and handle the interrupt itself. (I wrote "several" terminal emulators and related programs - Almost made me rich and famous (perhaps.)) Programs in general were tiny in those days. One of the "requirements" for the most complex of the com programs I wrote was that it run off of a single 360k floppy, including the extensive help text... (The basic H19 terminal emulation code with built-in serial driver was... about 700 lines of x86 assembly language, including comments.)

#64 Reply
Posted by Buriedcode on 23 Dec, 2018 16:09
Quote from: IDEngineer on 21 Dec, 2018 05:23
Have you tried to work with the USB stack in Android, for example? There's a nasty bug in its logical disconnect routines that cannot be worked around except with a physical disconnect. The bug has been acknowledged by the dev team... it's in the buglist... but in the three years since it was first reported and confirmed, there's been absolutely ZERO work done on it. Sure one could fork your own version of the Android source and fix it (the fix is trivial, literally already documented in the buglist!) but then you're condemned to repeat the fix with every release, for every platform.... Ugh.

Surely that is an Android bug, rather than a problem with the USB spec itself ? And lets face it, Android is bloated. For most versions on modern devices its 6 gig. That is 50% larger than a full windows 10 installation. Android development is a complete mess, it has to be said, and is an order of magnitude slower than it should be.

As for USB connectors/spec. It seems there's quite a few complaining about "poor reliability". In my experience I have found the opposite - extremely reliable. Sure, I have repaired equipment with USB faults.. these are almost always: 1) a failed USB A socket after > 4 years. 2) A failed USB B socket after >4 years. 3) USB mini B socket SMT torn off the board.

1) and 2) are just wear and tear, these devices must have had 20 insertions a day for years. Also remember the entire mechanical stress is on the connector and PCB, as they rarely have any panel mounting. In these instances, the TH mountings seem to be doing a fine job, but are bound to fail at some point (like literally everything every created).

3) seems to be what the OP is complaining about. I have only seen a couple of broken USB mini B sockets, where the internal piece of plastic has snapped, but I have seen quite a few torn off the PCB - which is understandable as the whole mechanical stress is on the glue that holds the copper to the FR4 substrate. This isn't really a USB spec problem - it is because the PCB takes all the stress, the connector itself is pretty sturdy and rarely breaks. This is the same for any SMT connector with relatively small mounting pads that takes a cable-mounted plug it is going to get pulled and yanked.

Now, coppercone, I have read a few posts where you have complained about the weakness of some parts, or that modern devices have "snap together" enclosures and you have almost destroyed them taking them apart. Whilst we can all agree that USB mini B SMT is probably the most prone to breakage - maybe its just you have a heavy hand with things? If you're regularly breaking connectors, tearing things off PCB's, cracking laptop cases, and snapping plastic, you might want to evaluate how much force you're using.

Nothing is completely bullet-proof, everything is designed and manufactured to a price point. The USB spec, IMO has been pretty damn good, and "just works". We only remember when things go wrong, not the countless times it does its job. This is the same for the polarity of USB plugs - people seem to forget all the times they get it right first time, leading them to believe they always have to turn it around. It's all well and good complaining that its unreliable, and doesn't work for you, but I fear you are in the tiny minority here.

I'm not suggesting everything is perfect, nothing is, but as far as I'm concerned, it is a fine example of engineering, and serves us well.

#65 Reply
Posted by IDEngineer on 23 Dec, 2018 16:20
Quote from: Buriedcode on 23 Dec, 2018 16:09
Quote from: IDEngineer on 21 Dec, 2018 05:23
Have you tried to work with the USB stack in Android, for example? There's a nasty bug in its logical disconnect routines that cannot be worked around except with a physical disconnect.
Surely that is an Android bug, rather than a problem with the USB spec itself ?
Yes, and I said as much in the portion of my post that you quoted above. My point was not to suggest that this was a problem in the USB spec per se, but instead as further evidence that the USB spec has become so complex and convoluted that even a mainstream operating system can have difficulty properly implementing it. Meanwhile, things like SPI and I2C and UART-style serial are fast, easy, and straightforward to implement and (at least in the former two cases) have sufficient bandwidth and multi-device addressability to cover the vast majority of all but the highest bandwidth devices out there. Why overcomplicate a solution unnecessarily?

#66 Reply
Posted by james_s on 23 Dec, 2018 18:43
Quote from: westfw on 23 Dec, 2018 09:44
Quote
Is there any case not to just stick with RS232 or the TTL equivalent
I mentioned "performance issues" and the difficulties with "substantial" numbers of serial ports on the host...Y'all are not realizing just how horrible host-side UARTs can be. (Sure, you can use USB/Serial on the host side, and it's a little better. Do you consider that "USB" or "RS232"? I guess "host-side" USB on a microcontroller is equally problematic, making non-USB protocols more desirable for micro-to-micro communications.

Quote
can be implemented by bit-banging
I'm not sure I understand the desire to "bit bang." It used to be that a $4 microcontroller (Q1 from hobbyist sources) like the PIC16F84 could bit-bang a UART. Good, I guess. It's been a long time since a $4 micro hasn't included UART hardware, and more recently it will come with a full-speed 6-endpoint USB peripheral controller (and a software library that makes that somewhat easier to use.)(and of course, bit-banging more than one port at a time gets problematic.)

Quote
Have you written a mouse driver for both serial and USB at a low level?
Yeah, I think I did, back in the DOS days. More "library" than "driver", since DOS didn't do interrupts for COM ports, each program that wanted to do anything "moderately real" with the UARTs had to diddle the vectors and handle the interrupt itself. (I wrote "several" terminal emulators and related programs - Almost made me rich and famous (perhaps.)) Programs in general were tiny in those days. One of the "requirements" for the most complex of the com programs I wrote was that it run off of a single 360k floppy, including the extensive help text... (The basic H19 terminal emulation code with built-in serial driver was... about 700 lines of x86 assembly language, including comments.)

But none of this reflects the underlying complexity, it is simply skirting around it. No sane person can argue that USB is simpler than RS232, it's just not. The hardware contains orders of magnitude more transistors, the software is hugely more complex, there is a bunch of handshaking required just to detect the device and initialize it before you even start to exchange data. It's far more complex.

Yes it can be simple from a user standpoint, a lot of this complexity is handled by "black box" hardware that you don't really need to deal with internally and existing software infrastructure, that doesn't mean the complexity isn't there.

I don't normally bit bang serial, there's no need to, as you say most microcontrollers contain a UART, but this is the pedantic thing again that I mentioned earlier. The point, since you seem unable or unwilling to extrapolate it from my statement is that the fact that it's simple to bit bang serial illustrates that serial (RS232 or TTL) is inherently simple, the hardware is simple, the communication is simple, there is no overhead, it can be built with 50 year old technology.

Yes you can get microcontrollers with built in USB, although I've tried using PIC, AVR and ARM types with it and my success under the best of circumstances has been about 10%, the ARM I couldn't get it to work at all, the PIC and AVR both worked but were flaky, was it firmware, hardware, software on the PC side? Who knows, I don't have a way of analyzing the USB data at a low level so I was flying blind. Serial on the other hand is trivial, I can scope it and see exactly what's going on. Simple. Not necessarily superior, but simple.

I'm not sure why I bother to reply though, I have no doubt you will pick apart grammatical details, ignore or miss the main points and go off on irrelevant tangents.

#67 Reply
Posted by westfw on 24 Dec, 2018 04:19
I'm just trying to insist that people recognize that the simplicity of "rs232" comes with a pretty substantial cost. At one "cpu involvement" per millisecond, USB gets you something like 512kbps, a UART gets you about 10kbps, and bit-banging gets you about 1kbps. All those settings and things that "USB Complexity" adds, you now have to be sure to do correctly, manually.

#68 Reply
Posted by IDEngineer on 24 Dec, 2018 06:23
Keep in mind that nobody is bit-banging USB. By definition, USB requires dedicated hardware (at least a peripheral in an MCU). So it's simply not realistic to claim that USB is simpler on the hardware side than SPI, I2C, or good ol' "serial". To make the comparison fair the latter options get to have dedicated hardware too, and the moment that's true you're left with protocol implementation - which nobody can legitimately claim is "easier" with USB.

To sum up: Spec-compliant USB cannot be implemented without dedicated hardware, so if you want a simple HARDWARE serial interface USB is off the list while "traditional" serial, SPI, and I2C are all very viable candidates. If you level the hardware playing field and allow everyone to have dedicated hardware, USB loses the simplicity argument again because of all the handshaking mentioned several times in this thread. In contrast, you can implement a simple serial/SPI/I2C protocol in a few hours, and a multi-device protocol using network addressing in a bit longer, on any of the simpler standards.

USB is awesome for the correct application. But it's grown far past its original intention. It's become the serial equivalent of spaghetti code - started off with one set of requirements, and has had so many new features cobbled onto it while demanding backwards compatibility that it's lost the whole point of its conception. That's why I believe there's a need, AND room in the industry, for a simpler standard and we have lots of good ones to choose from. I can tell you this... the next clean-sheet design I do that doesn't require full USB bandwidth I will push hard for SPI or I2C as its serial interface for all of the above reasons.

#69 Reply
Posted by digsys on 24 Dec, 2018 08:28
If you use your imagination, RS232 can be quite awesome ! 15-18 yrs ago I was running RS232 at 4Mb, multidrop, on a 2MIPS 680X MPU ... very little CPU
overhead ... I used external COM chips, cranked up, fiber drivers with tristate buffers and MOST importantly - FIFO buffers with trigger latches.
All the CPU had to do was fill it's FIFO, and hit start ... the receivers would wait for a "data full" interrupt, usually a time-out timer etc then load in from the FIFO.
It didn't even matter if a new block had started coming in while I was processing the first one. Headers, data# length, CSMs took care of that.
It's not rocket science :-) I have done many 100s high speed RS232 networks over the years ... FIFOs rule !! :-)

#70 Reply
Posted by Siwastaja on 24 Dec, 2018 08:29
Quote from: westfw on 24 Dec, 2018 04:19
I'm just trying to insist that people recognize that the simplicity of "rs232" comes with a pretty substantial cost. At one "cpu involvement" per millisecond, USB gets you something like 512kbps, a UART gets you about 10kbps, and bit-banging gets you about 1kbps. All those settings and things that "USB Complexity" adds, you now have to be sure to do correctly, manually.

It's completely normal to have an UART peripheral with a FIFO and DMA connectivity, and a driver layer that handles the DMA transfers, and this can provide even lower CPU than USB due to less housekeeping activities. And, it's still orders of magnitude simpler than the USB stack - at least when the asynchronous separate rx&tx byte streams with no HW packet delimiting is what you want...

The issue there isn't strictly technical. It's just that exactly due to the low-level simplicity, UARTs have the history of being used in various ad-hoc ways, everybody implementing their own software layers (often minimal, for the specific task) and their own connectors, their own signaling levels (compare RS232, TTL, 5V or 3V3 CMOS, optocoupled MIDI...)

OTOH, USB is ground-up designed for connecting all imaginable (and non-imaginable, by extending the standard later) PC peripherals to a PC, and do this invisibly to the consumer end user.

This is not even apples to oranges; this is apples to space shuttles. The things are so vastly different that when you compare one specific case (such as connecting a mouse), you always leave other people unsatisfied, and the argument can easily go on.

#71 Reply
Posted by westfw on 24 Dec, 2018 09:02
Quote
I can tell you this... the next clean-sheet design I do that doesn't require full USB bandwidth I will push hard for SPI or I2C as its serial interface
I guess it depends on what you want to talk to as well. Most of my "rs232 is horrible" comments apply mostly to the "host" or PC side.
Personally, I wish Ethernet had ended up being used for a lot of the applications currently served by USB. Between Ethernet and various IP protocols, I think a lot of the same capabilities are present, and the IP world (IETF, I guess) seems to have managed to define a lot of things in much more "straight-forward" ways (and less proprietary.)

Quote
I used external COM chips, cranked up, fiber drivers with tristate buffers and ... FIFO buffers with trigger latches. ...
It's not rocket science
Doesn't sound "simple" any more, though. :-)

#72 Reply
Posted by digsys on 24 Dec, 2018 09:13
Quote from: westfw
Doesn't sound "simple" any more, though. :-)
Ahhhh but back then, the newest / best external comms chips only had 64-256 byte buffers, and 1Mb ish For MOST applications that was often well enough,
so it just bolted on to your MPU, usually in expanded bus mode. BUT if you had very large data streams, and/or high traffic, you needed to "roll" your own.
Usually the "extra" pcb was a standard add-on, often I'd make it part of the RS232 connector IF. Even in vehicles, I prefer this method to the DREADED CAN bus !!
People "bitch" about USB :-) ... CAN is a worse asswipe :-)

#73 Reply
Posted by soldar on 24 Dec, 2018 13:12
Quote from: tooki on 20 Dec, 2018 16:57
Christ on a cracker, man...

What produced the modern USB connectors (culminating in USB-C) isn’t magic new materials. It’s simply ordinary engineering done to improve upon the shortcomings of what came before. The number of devices with USB today is probably orders of magnitude larger than all the computers in the world in 1995, and the use cases cover things never anticipated before. At this kind of scale, you discover issues that you wouldn’t have otherwise. And the economies of scale involved mean that you can amortize much more expensive R&D than you could have before, so we could spend more money designing better connectors to improve upon the last. And at this kind of scale, manufacturers can afford the more expensive tooling for higher-precision parts.
Yup. Evolution. Everything we have today is the product of a long evolution of conditions and possibilities. And this includes cultural and sociological conditions. Fifty years ago people expected things to be sturdy and long lasting. Even if possible, giving them tiny, flimsy connectors would result in complaints about how flimsy they are, how difficult to plug in, and how expensive. I have known people who would wreck USB connectors because they just could not get it into their heads that you cannot just jam in crookedly but with great force. The metal contacts on the mobo connector would bend and that would be the end of that USB port.

But also, the technology just wasn't there yet. Look at any consumer product from around 1950 and it looks incredibly crude with wiring harnesses and *humongous* connectors. That is what was technically and economically feasible at the time. Twenty five years later they were using printed circuit boards that were, by today's standards, also very crude. Today's PCB is the product of a very long evolution of the initial PCBs. Many tiny incremental steps which add up. Along the way many things have been tried which have been superseded or discarded. That is how evolution works.

Asking why they didn't start out making USB-C connectors in the first place misses the historical picture. USB was an improvement over what there was at the time and that was all that was needed. And many other good improvements fell by the wayside. that is how evolution works. Sometimes it is not the best product technically speaking that wins out but others that, for various other reasons, won out.

The ability to manufacture miniaturized connectors, switches, etc, has improved steadily over the decades. Especially the ability to manufacture them economically. It is not like it was always there. and the demand wasn't there either.

Look at any mains power plug of any kind, be it Schuko, Nema or British. They are all bulky and wrong on so many levels but they were designed in their time with the demands and possibilities of those times. Today they remain because changing would be too costly. If we had to design a mains power plug today it would be nothing like what we are using.