checksum 8 bit.

[barboza]

por falar em int, no thumb mode fica como 16 bits ou continua como 32 bits...? (compilador)

int é int...
O modo thumb define a palavra de instrução e não muda a arquitetura.

[fabim]

entãosis PA.
Por isto estou pedindo ayuda.

Imaginando que:
Somar os bytes, sem definir se é posi ou neg, de -127 a + 128, a integral seria verdadeira cabendo dentro de um 8, havendo poucos estouros.
Se sair somando só posi, vai estourar um atraz do outro né ?
Por isso quero entender essa nhaca !!

é mania !!
unsigned char.
signed char.
Eu só escrevo assim , é que na pressa não me atentei !!

Abraços e obrigado !! Fabim

[xultz]

Estatisticamente, se você fizer um crc (independente do algoritmo) de 8 bits, ele tem uma chance em cada 256 de dar um falso positivo. Por isso o CRC32 é tão legalzudo, porque a chance disso acontecer é "não durante a existência humana".
Mas como eu sou um completo jumento em se tratando de estatística, eu posso estar completamente enganado.

Aliás, pensando bem, não tem absolutamente nada nesse mundo que eu tenha certeza.
Não, esse assunto aí eu tenho certeza. O resto não.

[msamsoniuk]

bom no meu caso, ja existem redundancias de mais. rsrsrs mais do que eu imaginaria que tivesse !!
CHR E SAM, muito obrigado meninos !!

Sam, to pensando aqui, a SUM signed dos dados é basicamente uma integral de string.
Se houverem dados reciprocos inversamente, não é totalmente verdade que ele identifique falhas em algum bit perdido.

Sua tênica sagrada, eu não entendi direito !!
Pode explicar a lógica ?

Li 3X, e ainda não entendi !!!

bom, vamos partir do principio de somar os bytes mesmo. a cada byte vc vai acumulando a soma:

soma = dado + soma

entao se vc quiser escrever a palavra "ab", vc vai ter em hexa:

ab = 61+62 = a0

mas suponha que vc se engana e digita "ba"... a soma em hexa vai ser:

ba = 62+61 = a0

a soma vai ser a mesma e o erro nao vai ser detectado pq eh um tipo de erro simetrico. infelizmente esse tipo de erro eh muito comum: quando o cara digita algo meio rapido, eh comum digitar os caracteres corretos, mas invertidos.

uma forma de deixar isso mais robusto seria ter alguma especie de informacao q conecte as posicoes, de modo que a primeira posicao seja a e a segunda posicao seja b. por exemplo, podemos shiftar os valores:

soma = dado + (soma<<1)

assim temos:

ab = c2+62 = 24
ba = c4+61 = 25

ou seja, o erro duplo sera detectado corretamente

note que o algoritmo nao melhora a resistencia contra erros randomicos, apenas move o erro para outro padrao de simetria nao tao obvio:

ae = c2+65 = 27
bc = c4+63 = 27

eu particularmente acho melhor: digitar "ae" ao inves de "ea" eh estatisticamente muito mais provavel do que digitar "bc" ao inves de digitar "ea".

ah sim, daih tem um detalhe tecnico: quando vc esta shiftando os valores, depois de oito shifts o valor inicial some, ou seja:

aaaaaaaaaaa = 9f
baaaaaaaaaa = 9f

para corrigir esse problema o truque eh fazer uma rotacao, jogando o bit msb no lsb da soma:

soma = dado + (soma<<1) + (soma & 0x80 ? 1:0)

agora sim:

baaaaaaaaaa = 81
aaaaaaaaaaa = 95

o negocio vai ficando mais robusto e vai ficando mais dificil criar pares de palavras com o mesmo checksum. qdo mais dificil p/ vc, certamente mais dificil para os fatores externos!

e finalmente... usar xor ou soma? efetivamente, parece que nao faz muita diferenca, mas perceba o seguinte:

87 + 88 = 10f
87 ^ 88 = 0f

a soma de dois numeros de 8 bits, eventualmente, produz um resultado de 9 bits e vc descarta o carry. um xor de dois numeros de 8 bits produz dois numeros de 8 bits.

na pratica o xor eh uma soma sem carry:

0^0 = 0 = 0+0
0^1 = 1 = 0+1
1^0 = 1 = 1+0
1^1 = 0 = 1+1 (seria 10, mas sem carry 1+1=0)

agora, sob outro ponto de vista, o circuito que calcula CRC:

1_27Fig02.gif

em essencia eh um shift-register onde eh feito xor em alguns bits. claro, o circuito do CRC acima funciona para um bitstream serial, nao eh equivalente a fazer xor e shiftar bytes. mas eh uma ideia similar.

por sinal eh muito parecido com os scramblers:

2_scrambler1.gif

e com geradores de numeros aleatorios:

3_1743Fig01.gif

e daih voltamos ao checksum: pq tornar o checksum aleatorio com shift+xor eh melhor? pq erros simetricos e repetitivos acabam sendo filtrados mais facilmente.

[fabim]

é, check não ficou legal não !!

gerei uma **** sugeira na I2C, e sim, com Check melhora, mais não resolve.

CRC em 8 bits é possivel ?

EX: slave devolve (data 16b)+(CRC . ?

Abraços

[KrafT]

é, check não ficou legal não !!

gerei uma **** sugeira na I2C, e sim, com Check melhora, mais não resolve.

CRC em 8 bits é possivel ?

EX: slave devolve (data 16b)+(CRC . ?

Abraços

Código: Selecionar todos

int calc_crc(int *buff, int num_vals)
{
   int shift_reg=0, data_bit, sr_lsb, fb_bit, i, j;

   for (i=0; i<num_vals; i++)   // for each byte
   {
      for(j=0; j<8; j++)   // for each bit
      {
         data_bit = (buff[i]>>j)&0x01;
         sr_lsb = shift_reg & 0x01;
         fb_bit = (data_bit ^ sr_lsb) & 0x01;
         shift_reg = shift_reg >> 1;
         if (fb_bit)
         {
            shift_reg = shift_reg ^ 0x8c;
         }
      }
   }
   return(shift_reg);
}

Autor: Fábio Pereira
Tirado de: http://www.erica.com.br/detalhes.asp?cod=9352
Mas PIC é um lixo, não uso o código.

[fabim]

Egidio, se me recordo alguém aqui comentou que precisa de um constante polinomial ?
Aonde que ta isso ai ?
Olhei algumas vezes e não entendi !!

TKS

[xultz]

A constante polinomial é um valor que é usado prá calcular o CRC. Esse número você inventa, apesar de existirem alguns valores padronizados que algum matemático sem coisa melhor prá fazer calculou qual tem probabilidade maior de não deixar um erro passar batido. O importante é que de um lado (da transmissão) deve usar uma constante prá calcular o CRC, e do outro lado (da recepção) deve usar a mesma constante prá checar o CRC. Por exemplo, a rede ethernet usa CRC32 prá calcular o checksum, e o valor da constante é padronizado na especificação 802.alguma_coisa da camada de enlace da rede.

[KrafT]

... algum matemático sem coisa melhor prá fazer calculou qual tem probabilidade maior de não deixar um erro passar batido.

Na mosca, Xultz: http://www.ece.cmu.edu/~koopman/roses/d ... bedded.pdf

[fabim]

nossa preciso parar de ler normas, e voltar a ficar procurando coisa dificil pra fazer.
Meu hobby era procurar coisas que eu nunca ia precisar talves !! Agora meu hobby é memorizar normas !!!
Bosnia, eu fiquei tentando entender mais a entendencia deu um nó na minha mente.

int calc_crc(int *buff, int num_vals)
{
int shift_reg=0, data_bit, sr_lsb, fb_bit, i, j;

for (i=0; i<num_vals; i++) // for each byte
{
for(j=0; j<8; j++) // for each bit
{
data_bit = (buff[i]>>j)&0x01;
sr_lsb = shift_reg & 0x01;
fb_bit = (data_bit ^ sr_lsb) & 0x01;
shift_reg = shift_reg >> 1;
if (fb_bit)
{
shift_reg = shift_reg ^ 0x8c;
}
}
}
return(shift_reg);
}

Então isso aqui é mais ou menos o que o sam explicou não ? o Xará usou um valor "0x8c", para fazer um togle e esticar um pouco mais o limite para erro !?
Então não é um CRC, e sim um check com a técnica que o sam explicou né ?

[Maffeis]

Funciona legal (pelo menos até agora não tive problemas com ele)
Cheguei a esse cara estudando modbus
Peguei simuladores de modbus para comparar
não cheguei a implementar ele como modbus msm

envios pacotes com 1500 valores, rs485

está nos planos implementar isso na memoria I2C também.

copie de algum lugar e modifiquei alguma coisa, não lembro qual foi a fonte

cpp code

void  CRC16(unsigned int dataLength, volatile uint8_t *buffer)
{
	unsigned int CheckSum = 0xFFFF;
	unsigned int j;		
	unsigned short i;		

	for (j=0; j<dataLength; j++) 
	{
	CheckSum = CheckSum^(unsigned int)buffer[j];
	for(i=1; i<=8; i++)			
        if((CheckSum)& 0x0001)	
		{
        	CheckSum = (CheckSum>>1)^0xA001; 
		}
        else
		{
        	CheckSum>>=1;
		}
	}
	highCRC = CheckSum>>8;     
	CheckSum= (CheckSum<<8); 
	lowCRC = CheckSum>>8;  
}

[fabim]

Maffeis, tem que ser CRC8 mesmo, por causa de alguns fatores.
Aquele poli ai, o 0xA... você excolheu ?
Será que eu pódo, 0xA1, e fechar na logica de 8 ?

Funciona legal (pelo menos até agora não tive problemas com ele)
Cheguei a esse cara estudando modbus
Peguei simuladores de modbus para comparar
não cheguei a implementar ele como modbus msm

envios pacotes com 1500 valores, rs485

está nos planos implementar isso na memoria I2C também.

copie de algum lugar e modifiquei alguma coisa, não lembro qual foi a fonte

Código: Selecionar todos

void  CRC16(unsigned int dataLength, volatile uint8_t *buffer)
{
   unsigned int CheckSum = 0xFFFF;
   unsigned int j;      
   unsigned short i;      

   for (j=0; j<dataLength; j++)
   {
   CheckSum = CheckSum^(unsigned int)buffer[j];
   for(i=1; i<=8; i++)         
        if((CheckSum)& 0x0001)   
      {
           CheckSum = (CheckSum>>1)^0xA001;
      }
        else
      {
           CheckSum>>=1;
      }
   }
   highCRC = CheckSum>>8;     
   CheckSum= (CheckSum<<8);
   lowCRC = CheckSum>>8; 
}

[barboza]

Bem, prefiro não reinventar a roda...

Porque não usa algo definido para o CCITT?

http://code.ohloh.net/file?fid=xjPuRH74 ... ed=true#L0

ou o CRC8 como quer?

http://code.ohloh.net/file?fid=Iw9KiARq ... ed=true#L0


Isso pode te ajudar a entender um pouco mais:

http://en.wikipedia.org/wiki/Cyclic_redundancy_check

[Maffeis]

oq eu li na época o modbus utiliza esse 0xA001 como padrão

para outros protocolos ele deve ou pode mudar, não sei dizer.