Ao projetar um dispositivo baseado em ARM que deve exibir gráficos simples em um LCD colorido, como melhor projetar coisas para permitir atualizações rápidas, de preferência sem estar vinculado a um fornecedor específico de ARM ou LCD? Meu projeto atual usa um monitor em preto-e-branco que pode ser acionado rapidamente por uma porta SPI em um PIC (redesenhando um monitor complexo em 1/60 de segundo). Parece que os displays LCD coloridos comuns têm uma porta SPI, mas mesmo preenchendo um LCD de 160x120 com uma cor sólida levaria 30ms e um 320x240 demoraria 120ms na melhor das hipóteses (clock de mudança de 10MHz).
Se alguém poupasse os pinos do controlador, o modo paralelo poderia ser melhor, mas não conheço nenhum meio independente de família de conectar a interface paralela sem exigir três instruções separadas de armazenamento de memória para cada pixel (um para definir os dados, uma para ajustar a saída do relógio para alta e outra para diminuir a velocidade do relógio). Alguns chips ARM têm interfaces de barramento de memória, mas geralmente querem fazer coisas como endereço e dados multiplex ou comprometer muitos pinos para gerar bits de endereço irrelevantes (o LCD precisaria apenas de um bit de endereço).
Observando o ILI9320 da ILITEK ou o HD66789 da Renesas, uma abordagem que pareceria interessante seria usar um CPLD para converter SPI em dados paralelos e incluir um modo que produzisse um pixel por bit. Observando a planilha de dados da Renesas, pode ser possível obter gravações de pixel por bit com hardware mínimo (sem necessidade de CPLD), fazendo com que todos os bits de dados da porta paralela rastreiem o pino de dados seriais, usando o modo serial para tudo, menos o pixel grava e usa as funções de comparação / máscara para que os pixels com todos os zeros sejam transparentes e os pixels com todos os bits definam bits selecionados no GRAM, ou os pixels com todos os pixels sejam transparentes e os pixels com todos os zeros limpem os bits selecionados. A seção "recursos" da folha de dados do IKITEK sugere que ele possui funcionalidade semelhante, mas os mapas de registro não
Supondo que o código mostre principalmente texto e gráficos em cores sólidas, a abordagem ideal parece usar um CPLD para fazer a interface entre a porta SPI do ARM e a porta paralela do monitor e permitir que o CPLD seja carregado com cores de primeiro plano / plano de fundo. Isso seria especialmente bom se houvesse um meio de escrever pixels "transparentes". Dada uma fonte como um bitmap de duas cores, pode-se simplesmente carregar os dados da fonte diretamente na porta SPI; isso permitiria que os dados da fonte fossem mostrados a uma taxa de um pixel a cada dois relógios ARM. Por outro lado, um CPLD suficiente para lidar com essa tarefa de controle de exibição custaria cerca de US $ 2.
Qual é a melhor maneira de fazer a interface de um ARM com um LCD colorido, se o objetivo é mostrar principalmente texto em cores sólidas ou gráficos simples (por exemplo, 16 cores ou 64 cores)?
Editar
Realizei muitos projetos de telas de LCD, com muitos tipos de LCDs, incluindo LCDs no modo de caracteres, segmento multiplexado personalizado 3: 1, usando meu próprio método de unidade, LCDs gráficos em preto e branco com controladores embutidos e preto e preto e branco. LCDs brancos para os quais eu projetei meu próprio controlador baseado em CPLD para fazer interface com o DMA de uso geral de um microcontrolador (fornecendo até quatro níveis de escala de cinza). Eu me orgulho de fazer exibições compactas. Um dos controladores gráficos era um cão que exigia cerca de 1/10 de segundo para uma atualização em tela cheia, mesmo ao gravar dados constantes, mas a maioria dos meus monitores pode renderizar até uma imagem bastante complexa em menos de 1/50 segundo.
Muitos dos projetos que realizo são movidos a bateria; portanto, o consumo atual é um problema. O controlador de exibição baseado em DMA funcionou muito bem, mas era para um projeto alimentado por linha. Acredito que a única maneira de obter uma corrente razoável de um LCD gráfico é usar um controlador que combine o buffer de exibição e os drivers da coluna. O envio de muita exibição entre chips de cada quadro gastaria muita energia, mesmo em uma única exibição de bit por pixel; em uma tela colorida com dezesseis bits por pixel, seria muito pior.
Eu só comecei a olhar para as folhas de dados do LCD colorido; muitos monitores parecem usar um controlador semelhante ao ILITEK ILI9320, embora todas as folhas de dados que encontrei para os controladores com base nesse design geral tenham sido marcadas como "preliminares". Alguns, como o ILITEK, afirmam ter recursos de máscara e transparência, mas não listam nenhum registro para eles; Não sei se os chips reais têm esses recursos, mas as folhas de dados "preliminares" deixaram de incluí-los ou se os omitiram, mas se esqueceram de mencionar a menção deles. Se na prática todos esses chips tiverem recursos de transparência, seria razoável projetá-los; se não, não.
Eu esperaria que, para a maioria dos projetos, uma tela típica consistisse em texto colocado arbitrariamente em número moderado de fontes de cores sólidas de tamanho arbitrário. As fontes provavelmente seriam armazenadas como dados de bit por pixel. Usando um Cortex-M3, se eu quisesse gravar a tela com dados paralelos, o "loop interno" do código para escrever dois pixels provavelmente terminaria algo como:
rol r0, r0, # 2; Obter um bit em C, o outro em N itcs strhcs r1, [r3, # DATA_OFS]; Gravar dados strhcc r2, [r3, # DATA_OFS]; Gravar dados strb r4, [r3, # CLOCK_SET_OFS]; Definir relógio alto strb r4, [r3, # CLOCK_CLR_OFS]; Definir relógio baixo itmi strhmi r1, [r3, # DATA_OFS]; Gravar dados strhpl r2, [r3, # DATA_OFS]; Gravar dados strb r4, [r3, # CLOCK_SET_OFS]; Definir relógio alto strb r4, [r3, # CLOCK_CLR_OFS]; Definir relógio baixo
Não é exatamente a coisa mais rápida do mundo. Eliminar as gravações nas instruções de ajuste / limpeza do relógio ajudaria. Meu palpite seria que não existe uma maneira agradável e independente da arquitetura de eliminar as duas gravações de clock, mas pode haver uma maneira bastante comum que permita a eliminação de uma (por exemplo, muitos chips podem ter um contador / PWM que pode ser feito para pulsar uma saída brevemente em resposta a uma única operação de armazenamento de memória).
Usar a porta SPI e adicionar hardware ao clock de um pixel por bit aceleraria bastante o acesso à tela. Se estiver usando uma exibição sem mascaramento e transparência, o CPLD precisará incluir um contador de endereços e, para cada pixel, registre uma palavra de dados em pixels ou um comando set-address para a posição do pixel a seguir (para a qual seria necessário um contador ) Por outro lado, se um monitor tivesse mascaramento e transparência, tudo o que eu precisaria seria permitir que o CPLD suportasse um modo em que, depois de registrar o clock em 16 bits, cada bit adicional registrasse uma palavra de dados no monitor com o LSB rastreando o pino SDI (talvez nem seja necessário usar um CPLD - apenas alguns chips lógicos normais). Eu definiria a cor da transparência como a cor que eu quero escrever, mas com o LSB invertido.
Não quero criar um design bonito que dependa de máscara e transparência e depois descobrir que os únicos monitores com esses recursos têm um prazo de entrega de 30 semanas. Por outro lado, se tais monitores estiverem disponíveis e permanecerem amplamente disponíveis em muitos fornecedores, não quero que a paranóia sobre a disponibilidade me leve a usar um design inferior.
