Respostas:
A velocidade da transmissão é importante porque o USB é half-duplex: para transmitir uma resposta, o barramento deve ser girado e os dados transmitidos na outra direção. Portanto, o host envia dados e aguarda uma confirmação ou resposta. Todas as transferências são controladas pelo host. O dispositivo tem um tempo (razoavelmente curto) para responder. Esse tempo é aproximadamente o tempo necessário para duas viagens de sinal ao longo de um cabo de 5m.
(Não consigo encontrar referências neste momento, mas os documentos de especificação relevantes são públicos)
Edit: obrigado psmears por encontrar esta seção
Soluções para cabos e longo curso
- Por que existem limites de comprimento de cabo e quais são eles?
R: O comprimento do cabo foi limitado por uma especificação de atraso de cabo de 26ns para permitir que os reflexos se instalassem no transmissor antes do envio do próximo bit. Como o USB usa terminação de fonte e drivers no modo de tensão, esse deve ser o caso, caso contrário, os reflexos podem se acumular e explodir o driver. Isso não significa que a tensão da linha tenha sido totalmente ajustada até o final do bit; com pior caso de subterminação. No entanto, houve amortecimento suficiente até o final do bit que a amplitude da reflexão foi reduzida para níveis gerenciáveis. O comprimento do cabo de baixa velocidade era limitado a 18ns para impedir que os efeitos da linha de transmissão impactassem os sinais de baixa velocidade.
- Quero construir um cabo com mais de 5 metros, por que isso não funciona?
A: Mesmo que você violasse as especificações, isso literalmente não o levaria muito longe. Supondo tempos de atraso na pior das hipóteses, um dispositivo de velocidade total na parte inferior de 5 hubs e cabos tem uma margem de tempo limite de 280ps. Reduzir essa margem para 0ps forneceria apenas 5 cm extras, o que dificilmente vale a pena.
Portanto, minha resposta é apenas meio certa: o limite de ida e volta é para uma cadeia de hubs e cabos na pior das hipóteses, para uma profundidade total de 25m.
Dan Neely também é certo que a USB foi sempre suposto ser a solução de menor custo para os periféricos "lento", como teclados, mouses, impressoras etc. Se você queria full duplex para mais velocidade e mais distância, 100baseT ethernet é a escolha natural.
Consulte esta página, /superuser/64744/maximum-length-of-a-usb-cable .
Q1: quanto tempo de um cabo posso usar para conectar meu dispositivo? A1: Na prática, a especificação USB limita o comprimento de um cabo entre dispositivos de velocidade máxima a 5 metros (um pouco menos de 16 pés e 5 polegadas). Para um dispositivo de baixa velocidade, o limite é de 3 metros (9 pés e 10 polegadas).
P2: Por que não consigo usar um cabo com mais de 3 ou 5m? A2: O design elétrico do USB não permite. Quando o USB foi projetado, uma decisão foi tomada para lidar com a propagação de campos eletromagnéticos nas linhas de dados USB de uma maneira que limitava o comprimento máximo de um cabo USB a algo na faixa de 4m. Esse método possui várias vantagens e, como o USB é destinado a um ambiente de desktop, as limitações de alcance foram consideradas aceitáveis. Se você está familiarizado com a teoria das linhas de transmissão e deseja obter mais detalhes sobre este tópico, consulte a seção de sinais USB nas Perguntas frequentes dos desenvolvedores.
Não é realmente possível "bufferizar" o USB, pelo menos não no sentido usual da palavra. Normalmente, buffer significa amplificação elétrica e talvez regeneração de sinal.
Com o USB, o host dirige a totalidade do barramento. Um host envia uma solicitação e o dispositivo precisa emitir uma resposta para o host. O início da resposta deve chegar ao host um certo tempo após o término da transmissão da solicitação. Com um cabo muito longo, o atraso de propagação é muito longo para que a resposta chegue ao host a tempo.
Portanto, existem soluções alternativas, e nenhuma delas envolve "buffering" simples, pois o buffer adiciona atrasos adicionais e precisamos, de alguma forma, tornar o host mais tolerante a um atraso maior.
Existem duas classes de soluções alternativas:
Soluções alternativas que inserem hubs físicos ou virtuais. Se um host enumera um hub no barramento, o próprio hub adiciona um atraso extra e há outro cabo potencialmente completo entre o hub e o host. Quaisquer solicitações de dispositivos que se conectam a jusante do hub são agendadas com atrasos adicionais.
Você pode inserir um hub de porta única a cada 4m do cabo, com até 7 hubs em série. A limitação é de 7 níveis de hubs do host para o dispositivo final; portanto, se houver hubs a montante da sua engenhoca, você precisará reduzir o número de hubs de acordo. Muitos hosts USB incluem um hub interno de nível único; portanto, um limite realista seria 28m de cabo, com 6 hubs em série. Todos os hubs, exceto o primeiro, terão que fingir ser auto-alimentados.
Você pode adicionar hubs virtuais, com um transceptor robusto com pré-ênfase, diretamente no plugue que entra no host e depois transmitir o tráfego USB através de um cabo mais longo. Enquanto os sinais recebidos pelo dispositivo no final de um cabo estendido estiverem dentro das especificações, e enquanto o seu receptor puder recuperar os dados enviados pelo dispositivo padrão por um cabo longo, você estará bem. Os hubs virtuais são adicionados para que o host permita um longo atraso - mas é claro que não há hubs físicos, apenas uma representação deles.
Soluções alternativas que emulam um dispositivo que parece "lento" em um nível mais alto de protocolo. É assim que alguns "extensores" USB Cat-5 funcionam. Existem cinco parceiros aqui: o host real (rHost), um dispositivo emulado visto por ele (eDev), um cabo longo, um host emulado (eHost) e os dispositivos que o veem na extremidade do cabo (rDev) .
Inicialmente, o eDev finge não estar lá. Em algum momento, o eHost vê que um rDev foi conectado. Ele o enumera e encaminha os dados para o eDev. O eDev emula um evento de plug-in e o rHost o enumera. O rHost acredita que vê o rDev, mas apenas o eDev está lá, fingindo. Da mesma forma, o rDev pensa que vê um rHost, mas é apenas um eHost lá, fingindo.
Eventualmente, o rHost deseja emitir algumas transferências para o rDev que acredita estar lá, para usá-lo. Para transferências IN, o eDev finge não ter dados (respostas com um NAK). A solicitação de transferência é encaminhada para o eHost, que a executa novamente com o rDev. Os resultados são encaminhados de volta ao eDev, que usa os resultados na próxima vez que o host tentar a transferência.
Para transferências OUT, o eDev precisa adivinhar qual seria o comportamento do rDev. Existem várias heurísticas e comportamentos que podem ser tentados aqui. Uma maneira é o eDev sempre receber os dados e responder com um ACK. A transferência é encaminhada para o eHost, que depois repete a transferência para o rDev. Idealmente, o rDev eventualmente consumirá os dados e os aceitará. Se isso não der certo, ou se o rDev responder com um STALL, o melhor que o eDev poderá fazer é agir dessa maneira na próxima transferência do host. Como alternativa, o eDev sempre pode NAK a transferência, com a suposição geralmente correta de que o host simplesmente tentará a transferência idêntica posteriormente. Embora a transferência original tenha sido NAK-ed, ela é encaminhada para o eHost, que executa a transferência com o rDev. Qualquer que seja a resposta do rDev, ela se torna a resposta do eDev assim que o aprende.
As implementações realistas começarão com heurísticas conservadoras que envolvem ida e volta completa ao rDev para todas as transferências que podem ser adiadas por um NAK. À medida que as transferências prosseguem, o comportamento esperado do rDev pode ser aprendido e o eDev pode se tornar menos conservador. O "extensor" pode usar o conhecimento de classes USB padrão e algumas classes / conhecimentos de dispositivos / listas negras / listas de permissões específicas de fornecedores para oferecer melhor desempenho também.
A maioria dos esquemas de transmissão de dados por cabo possui um padrão decente reconhecido internacionalmente que descreve como implementá-los, incluindo uma especificação para a "impedância característica" do cabo (pense nisso como resistência, mas aplica-se à corrente alternada), impedância de terminação (a 'resistência' no final da conexão, necessária para evitar reflexos do seu sinal retornando ao cabo de volta ao remetente), geralmente uma 'taxa de variação' especificada (o tempo que leva para o sinal mudar de uma Estado 0 para 1 estado ou vice-versa) e, portanto, o número máximo de transições entre 0/1 por segundo (ou seja, kbps / Mbps / Gbps) e, por quanto tempo, o cabo pode demorar até a integridade do sinal diminuir o material para de funcionar corretamente.
Comparado ao USB, o RS232 possui todas as especificações do tipo de cabo, impedância característica, taxa de giro, comprimento do cabo, tipo de conector. Certamente, os conectores D de 25 pinos e 9 pinos eram comuns, mas, na realidade, o RS232 foi projetado para todos os tipos de conectores, cabos e produtos sem nenhuma especificação real para dizer o contrário. Na prática, com o RS232, geralmente é possível percorrer distâncias maiores, diminuindo para uma taxa mais baixa de bits por segundo (aka 'baud'). A distância máxima que você pode alcançar também será determinada em grande parte pela impedância do seu cabo, seja ele blindado ou não, terminação no final e assim por diante.
e, ao comparar o RS232 ao USB, você está comparando um 'padrão' da década de 1960 que superou os 115k2 (com raras exceções), com um dos anos 90 e 2000 que começou a 1,5 Mbps, uma ordem de magnitude mais rápida, depois 12Mbps (quase 100x mais rápido) e 480Mbps (quase 5000x mais rápido), mas o que significava que os parâmetros e o comprimento do cabo desempenhavam um papel importante ao fazê-lo funcionar de maneira confiável . Ele foi projetado como um padrão de conexão periférica de desktop; portanto, 5m foram considerados aceitáveis e, em seguida, todos os parâmetros dos cabos e conectores e velocidades foram estabelecidos a partir desse ponto. Se houvesse uma maneira de tornar o USB mais lento, você provavelmente poderia executá-lo em cabos mais longos (sem repetidor).