I/O Bit Streamming pela SPI do ATMEGA

[Jozias del Rios]

Alguém que já tenha trabalhado com o SPI do ATMEGA pode dizer se é possível fazer um streamming de bits pela porta SPI-MASTER dele sem que existam "bits de parada", isto é, bits que forçosamente devem ser Low ou High, ou dessincronismos entre bytes?

Por exemplo, se eu configuro o SPI-MASTER para rodar com clk/8 e MSB first e programar:

Código: Selecionar todos

ldi r16, 0x11
out SPDR, r16
nop
nop
; (...) aqui estão 8*8 - 2 instruções NOP
nop
nop
ldi r16, 0x88
out SPDR, r16


O que deverá ser visto na porta MOSI, independe do SCK?
Gostaria que fosse visto isso (bits amostrados em clk/8):

Código: Selecionar todos

..., 0,0,0,1,0,0,0,1,1,0,0,0,1,0,0,0, ...


Mas o micro consegue mesmo isto? Ou entre o "...,1,1,..." haverá algum tempo perdido, tal como por exemplo um periodo de oscilação do clock do micro?

E da mesma forma, se eu precisar ler o que foi recebido pela SPI nessa mesma cadência durante esta transmissão, posso fazer seguramente um "in r16, SPDR" em qual ponto?

O objetivo é preparar um low-cost Atmeta para ser responsável por esses streamming de bits (bit-banging) com diversos dispositivos, desde Sensores CMOS, LCDs sem VRAM e protocolos de comunicação variados, por exemplo USB1.1. Qualquer alternativa é bem vinda.

Abs!

[mastk]

Opa jozias, pelo o que eu entendi, vc quer enviar bits numa cadencia determinada pela SPI, ate ai sem problemas, nao ha stop-bit nem nada assim no protocolo, receber ja eh outra historia, pq dentro de um MCU, vc nao tem um dispositivo rapido para comunicacao como a SPI, foram o tempo das instruscoes de move, ja irao limitar a velocidade.

A entrega ou acquisicao dos bits, eh forcada pelo clock da SPI, normalmente vc pode escolher a fase e a polaridade, mas nao tenho certeza nos AT-MEGA.

MOSI depende totalmente do SCK.

Sim havera o tempo de ser enviado o byte, 8 clocks de SPI.

Recepcao msm coisa o mestre cloca (cloka? rs) e vc seta ou nao o MISO.

[Jozias del Rios]

Sobre "stop-bit", eu quis dizer que eu preciso que o SPI-Master do ATMEGA não coloque nenhum delay entre o envio de um byte e o envio do próximo byte. Isto é, o recarregamento do shift-register interno do uC tem que ser imediato, sem atraso, para que não se saiba (por divisão temporal) onde um byte acaba e outro começa.

O sinal de saída SCK não será utilizado. Estou usando a SPI para me comunicar com outro tipo de dispositivo.

O datasheet me parece deixar vago este ponto que coloquei em questão.

[Jozias del Rios]

Maus resultados, no Protheus ISIS é mostrado claramente um "glitch" na linha MOSI entre um byte e o próximo.

Se, por exemplo, o SPI do Atmega estiver configurado como Master, Fclk/4, MSB-first então ao se enviar os dois bytes na sequencia 0x55 e 0xAA, será visto:

Código: Selecionar todos

MOSI SPI (fck/4) scope:
 
    ____    ____    ____    ____ ___    ____    ____    ____
____    ____    ____    ____    _   ____    ____    ____    ____

 0   1   0   1   0   1   0   1  | 1  0   1   0   1   0   1   0
 ------------------------------ | -----------------------------
            = 0x55              |             = 0xAA
                                |
                                *--- glitch! deveria ter nivel alto constante!


Espero que tenha ficado claro: entre um byte e o próximo há uma inesperada transição H->L->H com encurtamento da duração do sinal do bit MSB do segundo byte.

Bom, acredito que neste detalhe este simulador de AVR do Protheus tenha sido bem feito, mostrando o que de fato ocorre num ATMEGA nestas circunstancias.

De acordo com isto, fica mostrado que o SPI não é um bom periférico para produzir bit-bang.

Sugestões?

[mastk]

Mas truta, acho que entendi melhor a questao, e SPI eh o que ha msm, vc deve avaliar a velocidade que vai enviar o dados, o codigo, pq se nop a mais pode criar esse glitch, talvez o que tenha que fazer seja mover o dado para SPI e fazer e ficar lendo o flag de quando ela termina.

[Jozias del Rios]

Então, mas a quantidade de NOP é justamente o mínimo possível para que não ocorra um Write Collision Flag. Testei isso pelo Protheus, deixando apenas o necessário mesmo.
Mesmo assim, vc concorda que pelo "scope" que eu montei, o sinal com glitch dura 3 clks enquanto todos os outros tem 4 clks, ou seja, alguma coisa não funcionou corretamente.
Mesmo assim estou pensando em um dia testar isso na prática...
é possível clockar o atmega a partir de um 555 com 1Hz?? Não quero ter de ir atrás de um osciloscópio por aqui...

[Djalma Toledo Rodrigues]

Certamente o Glitch não apareceria se estivesse usando o Clock mas,

como não pode levar o Clock aos Periféricos tenta seguinte:

Flip flop tipo D

Dados em D

Clock em C

Saida em Q (Limpinha, sem Glitch )
.

[Jozias del Rios]

É uma alternativa, embora adicione um chip inteiro... eu to buscando soluções alternativas, por exemplo usar um outro pino para substituir o MOSI nestes momentos complicados e fazer um OR entre eles por transistor ou wire-OR, algo do tipo... ;-)

[Djalma Toledo Rodrigues]

Então implementa o FF em Soft

Clock do SPI interrompe uC

uC lê Dado SPI e escreve Dado em outro Pino, Pino "Q"

algo assim.
.

[RobL]

Se do outro lado estiver um SPI slave, clock fornecido pelo lado Master, esta descida do pulso não será interpretada pois não haverá clock neste momento.

Se do outro lado não for um SPI slave, sempre terá uma descida de alguns ciclos de máquina, conforme observada.
Neste caso sem soft e hardware não dá para ficar contínuo.
O sw teria que analisar qual o último bit do byte e alterar o nível da porta ao final do último bit, o mais rápido possível, e tendo lá um filtro RC calculado pelo tempo necessário para a mudança de nível desse sw. Isto limitará sua velocidade.

Acabo de ter outra idéia:
Se o outro lado não for um SPI, use o clock do master para "autenticar" a mudança de estado, desde que o outro lado seja algo programável.
Por exemplo: Se o último bit foi alto, o clock parou, o nível desceu "glitch" mas não foi autenticado pelo clock, pois este não subiu. Portanto o nível continuará alto até a chegada do outro byte.