Criar drivers USB (módulo 3G da SW)

[SJD22]

Boa tarde,

este post abrange várias áreas... vou tentar não me dispersar... cá vai...

Ando de volta de um módulo 3G da Sierra Wireless. Neste momento estou a usá-lo com a develop board que adquiri também.

Quando essa board está ligada em Windows, este detecta-me várias portas COM. Por exemplo "AT COMMAND PORT", "DM PORT", "NMEA PORT" e mais 2 ou 3. São portas criadas pelos drivers da SWireless e cada uma tem a sua função concreta.

Ora bem, na verdade o que eu pretendo fazer é ligar este módulo a um Atmel 2560 mas este processador só tem UART e não USB. A conversão para USB faz-se com o FT232, portanto penso que não há problema. Aqui a questão é escrever um driver para o Atmel 2560 me conseguir comunicar com o módulo da SWireless.

Numa primeira fase, queria começar por escrever um driver USB de raíz em Windows e só depois avançar para o Atmel 2560. Alguém tem experiência a escrever drivers ou sabe por onde começar?

Fisicamente so existe uma ligação USB entre o computador e a develop board, por isso a ligação é partilhada pelas várias portas COM. A questão do direccionamento das portas está no modo como o driver é programado.

O objectivo final é conseguir enviar mensagens QMI (Qualcomm MSM Interface) para o chipset do módulo da SWireless. O protocolo QMI já o consigo recriar portanto é na boa este passo.

Obrigado.

[KammutierSpule]

Nao entendo o que tens e nao sei como as coisas estao ligadas, no entanto deixo aqui algumas ideias:

- Provavelmente nao quereras desenvolver um driver USB nem para o PC nem para um microcontrolador. A maior parte dos microcontroladores nao faz USB host. Mesmo que fosse possivel host, fazer um driver USB 'e daquelas coisas que so esta ao alcance de alguns: Para alem de ser algo extremamente complicado, exige conhecimentos do protocolo que o proprietario desenvolveu... que normalmente nao e' publico.

- Nao podes ligar USB directo com USB, nao 'e possivel ligar um conversor serie - usb - usb - serie.

Parece-me que o que tens, so podes fazer se conseguires comunicar com o modulo com microcontrolador por porta serie UART directa.

[SJD22]

O proprietário disponibiliza toda a documentação para fazer os drivers.

Isto tem é documentação que nunca mais acaba e não é fácil descascar tudo.

[senso]

Se é um FT232 só existe uma porta serial fisica, o que o software/driver faz é provavelmente criar várias portas COM e dividr consoante algum numero mágico num pacote a dizer para onde coisa deve ir no lado do windows, é agarrar no osciloscópio e pescar as linhas tx/rx directamente, conversor usb-serial para um terminal e ver o que é que te aparece.
O atmega2560 tem 4 portas serial nativas/em hardware..

[SJD22]

Não senso, não é um FT232.... isso é o que eu quero usar no futuro.

Vou tentar explicar-me melhor:

- trata-se de um módulo 3G da Sierra Wireless com 52 pinos dos quais apenas 2 são USB (D- e D+). O resto é pins para outras coisas... não interessa para o caso.
- o módulo encaixa-se na develop board que por sua vez a ligo por USB ao computador (Windows).
- São detectadas 6 portas COM (AT, NMEA, DM, CNS, dados, etc).
- Faço requests com comandos AT pela porta do AT sem problemas.

Mas agora eu quero é enviar comandos QMI (um protocolo especifico que é publico e é facil de implementar). O problema está em enviar esses comandos... Segundo o fabricante, esses comandos enviam-se atraves de uma API deles usando um SDK. So que eu futuramente no meu device nao tenho nenhum sistema operativo... tenho somente, e neste caso, 4 UARTs para comunicar. O que estou a pensar fazer no device é passar de UART para USB e ligar ao módulo. É pacifico e funciona penso eu... a questão é que eu tenho que de certa forma enviar algum pacote especial para o modulo interpretar isso da forma mais correcta. É o mesmo que acontece e que tu falaste senso... apenas uma porta USB fisica mas com varias COM's... por isso de certa forma ha pacotes que fazem a destinçao de que porta é que a informaçao partiu do Windows e chegou ao módulo. É isso que necessito perceber.

Isto não é facil explicar porque nem eu ainda percebi bem a globalidade disto. Muita documentação e dispersa... Telit nisso é bem melhor

[StarRider]

Boa tarde,

este post abrange várias áreas... vou tentar não me dispersar... cá vai...

Ando de volta de um módulo 3G da Sierra Wireless. Neste momento estou a usá-lo com a develop board que adquiri também.

Quando essa board está ligada em Windows, este detecta-me várias portas COM. Por exemplo "AT COMMAND PORT", "DM PORT", "NMEA PORT" e mais 2 ou 3. São portas criadas pelos drivers da SWireless e cada uma tem a sua função concreta.

Ora bem, na verdade o que eu pretendo fazer é ligar este módulo a um Atmel 2560 mas este processador só tem UART e não USB. A conversão para USB faz-se com o FT232, portanto penso que não há problema. Aqui a questão é escrever um driver para o Atmel 2560 me conseguir comunicar com o módulo da SWireless.

Numa primeira fase, queria começar por escrever um driver USB de raíz em Windows e só depois avançar para o Atmel 2560. Alguém tem experiência a escrever drivers ou sabe por onde começar?

Fisicamente so existe uma ligação USB entre o computador e a develop board, por isso a ligação é partilhada pelas várias portas COM. A questão do direccionamento das portas está no modo como o driver é programado.

O objectivo final é conseguir enviar mensagens QMI (Qualcomm MSM Interface) para o chipset do módulo da SWireless. O protocolo QMI já o consigo recriar portanto é na boa este passo.

Obrigado.

Boas,

Se a ideia for algo no género  Atmel2560 <---> FT232 <----> 3G não vai funcionar.

O FT232 implementa em firmware a classe CDC, pelo que é um USB DEVICE, da mesma forma o 3G implementa igualmente
a classe CDC com múltiplas interface (dai a varias portas COM) sendo que qualquer deles tem que estar ligado a um USB
HOST que neste caso é implementado pelo Windows.

Ora, ligar o 3G a um FT232 não vai funcionar pois são 2 UBS DEVICES que estão à espera de uma conexão a um USB HOST
como especificado pela classe CDC.

Da mesma forma, não estou a ver bem como entra ai o " driver USB de raíz em Windows" ... e muito menos o driver
USB para o Atmel, alias é completamente impossível pois esse Atmel nem sequer sabe o que é um PHY USB.

Se a ideia é comunicar com o 3G a partir de um MCU a única forma de o fazer é recorrer a um MCU com USB e implementar
no mesmo um USB HOST para tal.

Abraços,
PA

[SJD22]

Obrigado StartRider... se calhar está na altura de largar o Atmel 2560 e dar o salto para o Raspberry...

[StarRider]

Obrigado StartRider... se calhar está na altura de largar o Atmel 2560 e dar o salto para o Raspberry...

Boas,

Yap 

Como eu disse, podes recorrer a um MCU com USB (com PHY interno tens os LPC, por exemplo) e pode implementar
no firmware um USB HOST que vai aceitar o 3G e depois é só enviar o protocolo pelas portas COM virtuais.

A questão está mesmo na implementação desse HOST ... se fores avançar com o projecto, e depois de teres escolhido
o MCU ou board, não me importo de tratar da parte do HOST ... desde que não seja para fins comerciais como é óbvio

Abraços,
PA

[SJD22]

eu nao me importo de começar com o raspberry mas parece-me que depois para desenvolvimento é mais complicado, ou seja, largar o raspberry e usar so o processador

so arranjar o processador parece mais dificil e depois soldá-lo numa PCB em casa também nao é facil... fora toda a complexidade da arquitectura processador...

[senso]

O chip usado na RaspberryPi é um SoC da Broadcom, que só olha para ti se falares em comprar uns milhões de chips, é um BGA e precisas de pelo menos 4 layers de pcb se tiveres arte, se não 6 ou 8, tem de ser soldado em forno e inspecionado via raio X, penso que tem um pitch de 0.5mm possivelmente 0.4mm, não é de todo uma pcb feita na itead por 5€.

O SoC em si está coberto de NDA's e o bootloader em si é um blob binário, quem faz o arranque do SoC é um dos cores do GPU e não o CPU, sem o blob binário o CPU corre a uns fantásticos 19Mhz porque os PLL's ficam todos trancados.

Se queres algo que corra linux, obviamente vais tirar partido do OS, não é muito comum usar um SoC bare metal, para isso perdes tudo quanto é software oferecido pelo OS.
Se realmente queres ir por esse caminho, podes pensar num AllWinner A10 que é um TQFP144 ou um Freescale i.MX233 tambem disponivel em TQFP, tens linux pronto a usar, e só precisas de uma pcb de 4 layers(já se faz por algo na casa dos 30-50€).

Porque não um micro-controlador, como o StarRider referiu

[StarRider]

O chip usado na RaspberryPi é um SoC da Broadcom, que só olha para ti se falares em comprar uns milhões de chips, é um BGA e precisas de pelo menos 4 layers de pcb se tiveres arte, se não 6 ou 8, tem de ser soldado em forno e inspecionado via raio X, penso que tem um pitch de 0.5mm possivelmente 0.4mm, não é de todo uma pcb feita na itead por 5€.

O SoC em si está coberto de NDA's e o bootloader em si é um blob binário, quem faz o arranque do SoC é um dos cores do GPU e não o CPU, sem o blob binário o CPU corre a uns fantásticos 19Mhz porque os PLL's ficam todos trancados.

Se queres algo que corra linux, obviamente vais tirar partido do OS, não é muito comum usar um SoC bare metal, para isso perdes tudo quanto é software oferecido pelo OS.
Se realmente queres ir por esse caminho, podes pensar num AllWinner A10 que é um TQFP144 ou um Freescale i.MX233 tambem disponivel em TQFP, tens linux pronto a usar, e só precisas de uma pcb de 4 layers(já se faz por algo na casa dos 30-50€).

Porque não um micro-controlador, como o StarRider referiu

Boas,

Para ser sincero nunca mexi numa RaspberryPi ... mas partilho da mesma opinião.

Existe uma board da Olimex com o AllWinner A10 que por acaso só ontem é que tomei conhecimento da mesma pelo
facto de o TheDeadLives ter falado sobre  as boards da Olimex num outro tópico.

Ainda só dei uma vista de olhos, um pouco na diagonal, mas parece que tem potencial, e para este projecto penso
que era uma boa opção:  https://www.olimex.com/Products/OLinuXino/A10/

Em principio vou mandar vir uma para experimentar.

Abraços,
PA

[SJD22]

Infelizmente grandes empresas é tudo aos milhoes... o que é uma pena porque corta logo as pernas a um gajo qdo tenta começar um projecto (que no futuro ate pode dar origem a pedido de milhoes de componentes)... enfim... Quando contectei a Telit mandaram-me dar uma curva... a Sierra Wireless foi simpatica... e ha outros igualmente acessiveis tb.

Anyway... tanto tecnicamente como logisticamente falando ja percebi que usar Raspberry é para esquecer porque o passo a seguir seria usar o processador apenas e já percebi que por ai nao vou la...

Vou tentar as vossas alternativas! Na verdade eu so quero mesmo um processador com USB (4 idealmente)... ter SO ou nao será irrelevante...

Vamos ver...

Obrigado.

[SJD22]

Encontrei aqui uma soluçao que talvez não seja má de todo...

Existe um Arduino Mega ADK (http://arduino.cc/en/Main/ArduinoBoardMegaADK) com o Ateml 2560 que usa um IC chamado MAX3421e que permite USB Host.

Isto parece-me uma boa solução, nao? Vou explorar mais

[metRo_]

Não queres partilhar o modulo que estás a usar?

[SJD22]

é o MC 7710