| Electronics > Projects, Designs, and Technical Stuff |
| Evolution of usb connector? |
| << < (14/18) > >> |
| IDEngineer:
--- Quote from: Buriedcode on December 23, 2018, 04:09:25 pm --- --- Quote from: IDEngineer on December 21, 2018, 05:23:27 am ---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. --- End quote --- Surely that is an Android bug, rather than a problem with the USB spec itself ? --- End quote --- 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? |
| james_s:
--- Quote from: westfw on December 23, 2018, 09:44:49 am --- --- Quote ---Is there any case not to just stick with RS232 or the TTL equivalent --- End quote --- 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 --- End quote --- 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? --- End quote --- 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.) --- End quote --- 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. |
| westfw:
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. |
| IDEngineer:
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. |
| digsys:
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 !! :-) |
| Navigation |
| Message Index |
| Next page |
| Previous page |