como configurar o I2C no LPC4350

[fabim]

agora estou pensando em uma tomada simples de decisão.
onde você obrigatóriamente (maioria quase absoluta das aplicações), envia mais de um byte ou recebe mais de um byte, e obrigatoriamente fica parado.
Qual a relevância de usar hw ao invés de sw, se tu vai ficar parado da mesma forma ? e tudo que é int vai continuar operando da mesma forma ?

Software da na mesma, o junior mesmo ja fez 2 projetos grandes recentes e fez por software.

[KrafT]

Sei lá, sou a favor do Aquino e do Proex.

[fabim]

agora estou pensando em uma tomada simples de decisão.
onde você obrigatóriamente (maioria quase absoluta das aplicações), envia mais de um byte ou recebe mais de um byte, e obrigatoriamente fica parado.
Qual a relevância de usar hw ao invés de sw, se tu vai ficar parado da mesma forma ? e tudo que é int vai continuar operando da mesma forma ?

Software da na mesma, o junior mesmo ja fez 2 projetos grandes recentes e fez por software.

[Rodrigo_P_A]

agora estou pensando em uma tomada simples de decisão.
onde você obrigatóriamente (maioria quase absoluta das aplicações), envia mais de um byte ou recebe mais de um byte, e obrigatoriamente fica parado.
Qual a relevância de usar hw ao invés de sw, se tu vai ficar parado da mesma forma ? e tudo que é int vai continuar operando da mesma forma ?

Software da na mesma, o junior mesmo ja fez 2 projetos grandes recentes e fez por software.

Eu entendi o que o Aquino quis dizer, por SW, não é possível usar todos recursos de HW, em um sistema operacional como linux embarcado ou outro qualquer, se a rotina for bem implementada via HW, você pode usar DMA e preencher buffers gigantes com dados vindos da I2C ou enviar dados para a I2C sem a interferência do SW, apenas gerando interrupções quando o "Buffer DMA" estiver em um certo nível, com isso você economiza processamento.

Mas por outro lado é como vc falou fabim, a maioria das aplicações, não transferem grandes quantidades de dados via I2C, transferem alguns poucos bytes e pára.

O uso do DMA para transferir dados para um HW seja ele I2C , Uart, SPI, diminui em muito o uso do procesador e você pode ficar tratando outras coisas enquanto o HW trata de receber ou enviar dados para um HW específico.

Essa técnica é muito usada no linux, principalmente na UART do terminal, imagina só se o Kernel fosse ficar esperando a uart enviar os dados para a serial para continuar o processamento? iria usar muito processamento do processador à toa.

Ao invés disso, ele preenche os dados em uma área da RAM reservada para uso como buffer via DMA para a UART, ou seja, escreve na velocidade da RAM e o HW trata de enviar os dados para a UART.

Claro que eu estou explicando de modo grosseiro, mas a idéia principal é essa, se não fosse isso, para que os fabricantes colocariam DMA , acesso direto de HW x RAM via DMA, etc.. num chip se não fosse para otimizar o desempenho?

Existem aplicações e aplicações.

[proex]

Sei lá, sou a favor do Aquino e do Proex.

É assim que eu gosto, de pessoas com convicção !!!

[KrafT]

Eu confesso: Nunca consegui fazer o harware I2C dos HCS08 funcionar.

Esmiucei os livros do Fábio Pereira, os datasheets e as AN aplicáveis, sem sucesso.

Para ler uma dezena de bytes funciona, mas ler uma 24C256 inteira não vai. O hardware trava em algum ponto indeterminado.

É claro que o assunto aqui é ARM, mas trauma é trauma.

[andre_luis]

...Qual a relevância de usar hw ao invés de sw, se tu vai ficar parado da mesma forma ?...

Uma vantagem de se implementar o handshake por SW ao invéz de manipular o módulo de HW, é a rápida portabilidade. Já usei o mesmo driver I2C ( .C / .H ) criado para o 8051 e sem ter de fazer nenhuma alteração para o PIC, e ambos possuiam I2C built-in, que não foi usado, por pura preguiça de debugar, já que de primeira não funcionaram.

Claro que há diversos outros argumentos a favor ou contra, mas esse á apenas um dos aspectos a se considerar.


+++