LPC IOH -> IO Handler

[Rodrigo_P_A]

Achei bem interessante, quando eu tiver um tempinho vou testar: http://www.lpcware.com/content/project/ioh


Legal saber que pode direcionar qualquer pino para fazer as funções especiais.

Outra coisa que eu vi em algum lugar é um tipo de MATRIX que a NXP tá fazendo para que possamos mapear os pinos com função especial para qualquer pino do microcontrolador, isso vai facilitar muito roteamento de placas.

[Maffeis]

pelo que eu tinha entendido isso era uma biblioteca de sw para emular as funções igual aquelas do CCS

[Rodrigo_P_A]

pelo que eu tinha entendido isso era uma biblioteca de sw para emular as funções igual aquelas do CCS

é algo assim pelo q eu entendi, mas além disso também tem algo sobre esta matriz, com essa matriz é possível colocar a função especial em qualquer pino, e não é software, é mapeamento em HW.

assim que eu encontrar eu posto aqui,

[Maffeis]

minha duvida era realmente essa se e sw ou hw

[tcpipchip]

se é por hardware, é SHOW

[Maffeis]

O I / O Handler (IOH) é um mecanismo de hardware suportado pelas bibliotecas de software que adiciona performance, conectividade e flexibilidade de projetos de sistemas, e está atualmente disponível apenas na LPC11U37HFBD64/401 e o LPC11E37HFBD64/401. O IOH pode emular interfaces seriais, como UART, I2C, I2S e com nenhum ou muito baixa carga adicional CPU e pode off-load o CPU, realizando as funções de processamento intensivo como transferências DMA em hardware. O C API conveniente de cada biblioteca garante a funcionalidade adicional é facilmente integrado ao aplicativo. Todas as bibliotecas são oferecidos gratuitamente.

Sei lah parece ser SW mais tem um HW pra ajudar

Ninguém do site tem contato com os engenheiros da NXP a parada tah meio confusa no site deles (Eu conheci um japonês num hands-on mais não tive mais contato)

[tcpipchip]

O Marcelo S. pode dar a opnião.

[msamsoniuk]

O Marcelo S. pode dar a opnião.

eu? mas eu nao conheco quase nada de ARM e menos ainda de NXP... bom, mas se for para chutar, eu diria que talvez seja similar aos coprocessadores de IO da freescale. no caso da freescale, eu considero o conceito realmente muito bom e acho que soh perde mesmo para um conceito de IO packetizado. os primeiros coprocessadores de IO que eu conheco da antiga motorola surgiram em 1990 na familia 683xx. na epoca eles lancaram muitas aberracoes malucas, como coprocessador de IO para graficos vetoriais, mas a maioria era para clientes especificos e com o tempo os produtos morreram... porem pelo menos dois modelos de coprocessadores de IO sobreviveram ateh os dias de hoje: o TPU e o CPM.

o TPU eh uma especie de coprocessador de IO generico:



a ideia eh simples: um pequeno core RISC executa um microcodigo otimizado que desempenha funcoes de IO genericas sem intervencao no core principal (68k, coldfire ou powerpc). o pulo do gato eh a flexibilidade: vc programa o core RISC para imitar certa interface, entao, enquanto os tradicionais fabricantes cabeca-ocas entopem os chips de interfaces e mesmo assim sempre falta uma, vc tem a flexibilidade de tirar da cartola qualquer interface possivel mexendo no microcodigo do core RISC. de certa forma, eh um meio termo entre um hardware dedicado e uma FPGA, pq vc tem liberdade para escolher as funcionalidades. e tem gente que pensa que o supra-sumo do IO eh usar DMA para ativar GPIOs. sim, eh rapido, mas o DMA nao tem capacidade de decisao: ele vai transferir um bitmap fixo e a capacidade de decisao depende da performance do core principal. eh um pouco melhor do que ficar fazendo toggle em pino de GPIO, mas dependendo do caso vc joga fora a performance soh para fazer isso. com um coprocessador de IO como o TPU, vc tem alguma capacidade de decisao e isso flexibilida bastante as coisas: o core RISC dedicado para o IO vai fazer a parte chata e o core principal fica livre para fazer outras coisas.

soh para ilustrar, aqui tem alguns exemplos de variados da TPU:

http://www.eslave.net/tpu/source/source.shtml

para ter uma ideia da capacidade da TPU original de 1990, ela podia tocar 13 transmissores e 3 receptores a 9600 bps ao mesmo tempo. nem eh muito, mas pense bem: isso eh tirado do nada, no aspecto que nao tem hardware de UART ali dentro. quanto a eTPU usada nos powerpcs e coldfires, aparentemente ela tem o dobro de canais e roda com um clock muito maior. mas para a mesma aplicacao, ao inves da quantidade eles indicam a velocidade, sendo 1.4Mbps no powerpc e 830 kbps no coldfire. imagino que a NXP esta oferecendo algo bem similar e essas estimativas de performance devem dar uma ideia se eh isso mesmo e se a performance deles eh boa ou nao.

aqui tem algumas aplicacoes da eTPU dos dias de hoje:

http://www.freescale.com/webapp/etpu/

jah o conceito do CPM eh muito similar ao TPU, contudo, a coisa nao apenas comecou mais complexa e especializada, como evoluiu em uma escala realmente impressionante em termos de funcionalidade. quando surgiu em 1990, o CPM era baseado em um core RISC que falava com o core 68k hospedeiro atraves de uma memoria RAM dual-port:

http://www.freescale.com/webapp/sps/sit ... de=MC68302

era dificil estimar precisamente onde comecava e termina o hardware do CPM, mas procurando pistas nas analises de performance, era facil perceber que o hardware realmente nao fazia muito mais que serializar e de-serializar as FIFOs e todo o resto era feito pelo core RISC, incluindo o DMA, que jah operava com multiplos canais e ring-buffers em 1990, em uma epoca que os PCs ainda precisavam gerar uma interrupcao no fim do frame recebido para reprogramar o controlador de DMA para apontar para um novo frame... em termos de protocolos, inicialmente eles suportavam protocolos simples, como HDLC, UART e outros menos importantes, bem como interfaces fisicas nao-multiplexadas e multiplexadas (TDM, CGI e IDL). mais tarde surgiram variacoes com mais interfaces e mais protocolos, incluindo ethernet, ATM e capacidade para HDLC e PPP multicanal em cima de TDM. essencialmente era o mesmo chip rodando com clock maior e com um patch no microcodigo para mais opcoes de protocolos e interfaces.

soh para ilustrar a flexibilidade de adicionar um novo protocolo, aqui tem o manual do patch para ATM:

http://cache.freescale.com/files/32bit/ ... TOM1UM.pdf

por exemplo, na pagina 32 ele comenta sobre o scrambler para a linha ATM... obviamente isso nao pode ser feito por hardware, pq eh uma caracteristica que foi adicionada pelo suporte a ATM, que originalmente nao existia. isso mostra a flexibilidade de se ter isso feito por um coprocessador de IO. a grosso modo, ali onde ele fala em performance de interfaces HDLC, ATM e ethernet, ele esta considerando a performance do core RISC em cima destes protocolos.

isso ilustra o que um coprocessador de IO consegue fazer e qual eh o caminho para obter um equilibrio perfeito entre hardware e software: como suportar protocolos futuros? atraves de software. mas o software nao vai ter performance suficiente para, por exemplo, serializar e deserializar uma interface fisica ATM... entao a solucao foi desenvolver um hardware que serializa e de-serializa um frame generico, deixando justamente a montagem do frame para o software. claro, se vc jah tem ideia do que vai precisar em termos de hardware, vc pode suprir, por exemplo, o timeslot assigner para interface fisica TDM eh um hardware especializado pq opera bit a bit e isso mataria o core RISC.

aqui comeca a surgir a diferenca entre o TPU (bem generico) e o CPM (bem especializado). mas ateh onde pode chegar o nivel de especializacao? bom, o cara que substitui o CPM hoje em dia com o mesmo conceito, mas bastante melhorado, eh o QUICC engine:



http://cache.freescale.com/files/ftf_20 ... _F0420.pdf

no MPC8569E, o coprocessador de IO possui quatro cores RISC operando a 667MHz e muitos layers especializados para canalizar interfaces fisicas de forma eficiente. por exemplo, vc pode programar uma UCC para trabalhar com 128 canais HDLC. o core RISC vai cuidar da parte de bus master, DMA e provavelmente protocolo HDLC, enquanto a UCC vai serializar/de-serializar isso e canalizar em timeslots atraves do TSA e chegar ao mundo externo atraves de uma das interfaces TDM.

e olha que, de forma alguma, o CPM ou QUICC engine sao a ultima palavra em coprocessador de IO: em certo aspecto, parte do conceito do QUICC engine esta ficando obsoleto a medida que as interfaces de IO comecam a se concentrar em torno de interfaces packetizadas (PCI-express, GbE, etc). note como o QUICC engine, apesar da complexidade, eh apenas uma caixinha discreta e miuda dentro do MPC8569E:



mas daih eh outro patamar e vamos ficar por hora entre o TPU e CPM. bom, em "escala PIC de complexidade", implementar um TPU em FPGA eh como colocar um homem no espaco e implementar um CPM em FPGA eh como colocar um homem em marte. eu ateh diria que jah consegui colocar um pedaco de um cara na lua, mas tah dificil mandar o resto... e pela minha experiencia, sem partir para um core RISC fazendo coprocessamento de IO, nao tem como chegar lah.

mas o CPM eh especializado demais, entao eu chutaria que a NXP tem algo parecido com o TPU mesmo, pq eh mais o foco dos clientes deles. e se for verdade, eu realmente tenho que dar os parabens a eles, pq mesmo sendo algo generico e estando 20 anos atrasados, eh um passo em direcao a qualidade, flexibilidade e performance... quem sabe um dia eles oferecam algo do porte do CPM.

[andre_luis]

...Outra coisa que eu vi em algum lugar é um tipo de MATRIX que a NXP tá fazendo para que possamos mapear os pinos com função especial para qualquer pino do microcontrolador, isso vai facilitar muito roteamento de placas.

Esse conceito já era implementado nos cores ARM fabricados pela CYPRESS, que também permitem ainda dinamicamente uma alteração da configuração de hardware mesmo em runtime dos periféricos a partir de standard cells analógicas e digitais:

http://www.cypress.com/psoc/images/PSoC ... iagram.png

Inclusive possuem uma ferramenta bem agradável de lidar com blocos pré-fabricados, que podem ser simplesmente arrastados para a área da pastilha, e a IDE mostra o quanto ainda resta de recurso disponível para montar mais módulos perfiféricos, e para quais pinos de I/O podem ser roteados:





+++

[tcpipchip]

Nao é mais rapido um ARM multi core master slave onde nos slaves se implemente um bit banging em qualquer io ?

[msamsoniuk]

Nao é mais rapido um ARM multi core master slave onde nos slaves se implemente um bit banging em qualquer io ?

nao sei, tem que fazer as contas!

vamos supor que vc quer criar uma interface fast-ethernet "virtual" operando a 100Mbit/s em cima de uma versao simplificada da RMII, com RX[1:0], TX[1:0], TXEN, RXEN e CLK. bom, o clock precisa ser de 50MHz, portanto vc gastaria pelo menos 100MIPS apenas fazendo o toggle do pino CLK. isso magicamente vai permitir que o TX e RX fiquem sincronizados, visto que o PHY vai usar esse clock para TX e RX, eliminando a necessidade de fazer um "super-sampling" dos sinais. bom, supondo um sub-sistema de memoria de 16-bits, para os pinos TX[1:0] vc gastaria 6.25MIPS puxando words de 16 bits da memoria para um registro e mais 50MIPS escrevendo TX[1:0]. como o pino TXEN vc ativa quando comeca a transmitir e desativa quando termina, eu nem vou considerar um custo para ele. porem vc precisa ficar de olho no pino RXEN para saber quando o PHY comeca a transmitir algum frame. e isso vai gastar 50MIPS. a boa noticia eh que, quando o PHY comeca a transmitir um frame, vc pode parar de monitorar RXEN e comecar a ler RX[1:0] a taxa de 50MIPS. como o frame tem um comprimento minimo, vc nem precisa testar RXEN, mas a partir de um certo momento vc precisa comecar a testar a cada 4 leituras de RX[1:0], o que se traduz portanto em 12.5MIPS. os dados recebidos, claro, sao reconstruidos para formar words de 16-bits e vc gastaria mais 6.25MIPS enviando words de 16 bits de um registro para a memoria.

100 MIPS = clock RMII
12.5 MIPS = R/W memoria
100 MIPS = R/W dados RMII
12.5 MIPS = monitoramento do RXEN

e o total para ter uma fast-ethernet virtual seria de 250 MIPS. nao conheco o set de instrucoes do ARM a fundo, mas vamos supor que eh bom o suficiente para fazer essas tarefas quase que diretamente, o q de forma alguma eh uma garantia de viabilidade real para isso. trata-se de uma aproximacao bem preliminar, mas dah uma ideia do trabalho necessario e eu diria que, se seguir essa teoria, em um dual-core ARM de 1000MIPS por core provavelmente vc pode colocar o segundo core para criar quatro fast-ethernet virtuais. um ponto barra pesada eh o bandwidth de memoria, mas se vc tiver memoria dual-port integrada acessivel por ambos os cores, vc pode deixar a DDR externa apenas para o core principal e usar essa dual-port apenas como memoria para o core de IO, sendo acessivel pelo core principal apenas para transmitir e receber frames rapidamente. mas sera que vale a pena gastar mais de 1000MIPS para trabalhar com um bandwidth de apenas 400Mbit/s? e olha que nessa conta nem coloquei o calculo do checksum do frame ethernet... sera que eh realmente necessario? afinal o header IP e TCP/UDP jah possuem seu proprio checksum... mas isso nao vem ao caso no momento.

agora vejamos o que o concorrente oferece: o QUICC engine quad-core rodando a 667MHz fornece 8 interfaces RMII (8x100Mbit/s), 2 RGMII (2x1Gbit/s) e 2 UTOPIA OC12 (2x622 Mbit/s). em teoria o QUICC engine consegue gerar 2666MIPS, mas trabalha com um bandwidth total de mais de 4Gbit/s. note q a relacao eh inversa: na minha conta vamos gastar 2.5MIPS por Mbit/s no ARM, mas 0.6MIPS por Mbit/s no QUICC engine... mas perae! ele nem eh superescalar! entao eh obvio que ele tem ajuda de hardware especializado na parte de serializacao e interface de hardware. nesse caso, podemos imaginar que o bandwidth efetivo que o QUICC engine mastiga eh 1/8 do bandwidth em bits, algo da ordem de 500Mbytes/s. e daih realmente fica muito mais gerenciavel: 5.3MIPS por Mbyte/s. e ele nao apenas calcula os checksums corretamente dos frames, como as interfaces fisicas sao isentas de problemas de temporizacao, na medida que as FIFOs entre o core RISC e as interfaces fisicas elimina as variacoes de temporizacao criadas pelo microcodigo que processa sequencialmente as interfaces.

a moral da historia eh que fazer isso com bit banging parece possivel sim, mas solucoes melhores existem. se vc seguir a dica do QUICC engine e adicionar a esse segundo core algum suporte bem basico em hardware para serializar e de-serializar os streams, a coisa muda de figura: um core ARM de 1000 MIPS, supondo que eh tao eficiente quanto o core RISC do QUICC engine, vai conseguir manipular um bandwidth de quase 200Mbytes/s, suficiente para 16x RMIIs. o problema eh que parece que os caras que trabalham com ARM nao percebem isso, entao nao tem esse tipo de solucao no hardware. uma alternativa seria entao plugar uma FPGA externa, por exemplo, com a funcao apenas de receber os streams com os frames ethernet e serializar/deserializar em maior velocidade.

e de fato isso existe: o zynq da xilinx eh uma FPGA com um ARM dual-core integrado:



na pratica, a solucao ficaria com um core ARM para rodar aplicacoes, um core ARM para tocar 16x RMII auxiliado pela FPGA (nao precisa ter os MACs completos, apenas a interface RMII) e, de quebra, ainda teria alguns extras, como um par de interfaces GbE em hardware. em relacao ao QUICC engine, oferece o dobro de interfaces RMII e nao oferece interfaces UTOPIA, mas custa metade do preco e parece mais adequado a uma topologia baseada somente em ethernet. o fato de disponibilizar apenas um core ARM pode ser um problema: tipicamente o powerpc jah eh 2x mais potente que um ARM com o mesmo clock, daih vc multiplica a diferenca novamente por 2x usando um core ARM apenas para IO e o resultado pode ser uma performance 4x menor.

olhando o problema em um patamar menor, daria para pensar no seguinte: o padrao VGA requer um pixel clock de aproximadamente 25MHz para gerar 640x480 a 60Hz. bom, via software imagino alguma coisa como:

Código: Selecionar todos

p=buffer;
j=525;
while(j--)
  {
  i=100;
  while(i--)
  {
    pixel = *p++;
    *out = (pixel = pixel>>1)&1;
    *out = (pixel = pixel>>1)&1;
    *out = (pixel = pixel>>1)&1;
    *out = (pixel = pixel>>1)&1;
    *out = (pixel = pixel>>1)&1;
    *out = (pixel = pixel>>1)&1;
    *out = (pixel = pixel>>1)&1;
    *out = (pixel = pixel>>1)&1;
  }
}


claro, daih depende de como o processador otimiza isso. nao conheco o ARM, mas supondo que ele eh minimamente bom e consegue ser eficiente o suficiente para fazer cada linha em um clock, o loop principal vai consumir 10 instrucoes para serializar 8 pixeis a taxa de 25Mpixels/s, o que totaliza uns 31MIPS. se ele for meia-boca, vai precisar de 62MIPS. nessa conta ele esta transmitindo 800x525, precisaria ainda ter os ifs nos contadores para controlar os sinais de HSYNC e VSYNC, mas vamos deixar isso para lah no momento. nao precisa de algo potente, mas provavelmete uns 100MIPS precisa. enfim, isso sem nenhuma ajuda de hardware... daih imagine um truque interessante: mover os bytes para a SPI e deixar ela ter o trabalho de serializar. nesse caso, para transmitir a uma taxa de 25Mpixels/s, vc precisaria apenas 3.1Mbytes/s:

Código: Selecionar todos

p=buffer;
j=525;
while(j--)
  {
  i=100;
  while(i--)
  {
    while(*spi_state&READY==0);
    *spi_xmit = *p++;
  }
}


vamos supor que o loop interno consuma uma instrucao por linha e vc teria 9 MIPS. extrapolando como da outra vez para o dobro, talvez 18 MIPS? daih digamos que a SPI tem suporte a DMA, a coisa simplesmente fica facil demais: vc gasta 3.1Mbytes/s de bandwidh via DMA transferindo blocos de 100 em 100 bytes e menos de 1 MIPS para gerar o resto da sinalizacao. na pratica, o simples fato de ter uma SPI com DMA, mesmo nao sendo algo especializado, jah te economiza um core barato de 100MIPS.

a freescale tb tem um caso pratico nesse aspecto: o 68302, que eh um cara com o CPM, tinha um modo de operacao que permitia tocar uma interface ISDN 2B+D (2x 64kbit/s de dados/voz + 16kbit/s de controle HDLC). o componente que substitui o 68302, em tese, eh o MCF5272. porem, enquanto o CPM prove canais de DMA e ring-buffers para os canais de dados/voz e HDLC, o MCF5272 prove apenas uma interrupcao de 4kHz e hardware basico para serializar/de-serializar os canais e multiplexados em uma interface GCI. todo o resto, incluindo a montagem do frame HDLC bit a bit no canal de controle, eh feito por software. isso de fato economiza uma area gigantesca de silicio, que no MCF5272 eh preenchida com coisas legais que o 68302 nao tem, como fast-ethernet, usb, controlador sdram, etc. claro, eles cortaram todas as outras facilidades que o CPM do 68302 fornecia, como canais HDLC a 2Mbps, mas para aquela aplicacao especifica de ISDN 2B+D, a substituicao ficou mais direta e simples, provida quase que totalmente por software com o apoio de muito pouco hardware.

[polesapart]

Esses µCs onde a NXP alega ter implementado este tal IO Handler são bem básicos, cortex-m0 a 50mhz. O cortex-m0 é otimizado para baixo consumo ainda por cima. Por conseguinte, esse IO Handler deve ser algo bem básico também. O foco deve ser flexibilidade e não performance. Os exemplos de uso deles são coisas como implementar uma uart extra, fazer crc assistido por "hardware", e tal. Pelo que li ele interage com o controlador dma do chip também, então dá pra automatizar algumas coisas razoavelmente complexas enquanto a cpu hiberna, mas deve ser só isso.

E pelo menos por enquanto não tem documentação low-level nenhuma dessa coisa, só implementações proprietárias da NXP.

[RobL]

E nesse IOH parece não ter nada com relação a remanejar pinos.
Isto seria algo mais simples de pensar (projetar), tal como uma matriz com chaves similar aos velhos CMOS 4066 mas com frequência bem mais alta e registros dedicados a configuração deles. Isso é simples de pensar mas pode ser algo difícil de implementar.
Não conheço a forma utilizada pela Cypress, para remanejar pinos, mas até um simples PIC, AVRs tem algo desse tipo bem restrito, na área do ADC.

Acrescentei isso aqui para o ARM :
Parei e pensei. Se derem essa habilidade para remanejar pinos, as empresas estariam perdendo uma forma de nos manter cativos , ou não ?
Com uma mesma PCI bastava ajustar os pinos e parte do software (até por diretivas já prevendo outros chips), mantendo a produção, adquirindo um lote sempre com menor preço e melhor disponibilidade no mercado de qualquer fabricante !!!