CCS mastiga tudo,até os códigos

[vtrx]

Adoro a interface do CCS,acho 'bonita' de se ver(sei que isso não importa mas ajuda...),mas sempre tem algo 'estranho' quando o programa vai desenrolando.
Estou usando a versão 5.070,que contem muitas melhorias para a família 18,que é a que uso com esse compilador.
Não programo muito com ele,apenas quando vou uso USB HID pois já tenho vários templates feito nele,além de ser rápido a programação,mas conforme acrescento alguma rotina ou lógica algo pode acontecer.
Hoje acrescentei duas rotinas de leitura da eeprom interna do 18F4550,para serem mostradas no programa principal,no PC via USB,os dados gravados,e surgiu um comportamento 'estranho'.
Nos endereços da eeprom interna do PIC,entre os endereços 24 a 144,existem dados que podem ser gravados ou lidos e que são armazenados no boot,em endereços de ram(variáveis) e são usados por uma rotina que lê os valores e faz algo dependendo do byte gravado,ou envia para o PC,em blocos de 64 bytes(HID),pois são 120 bytes.
A rotina de início do PIC,que Lê os valores e carrega nas variáveis, está correta ,pois o micro responde a cada byte corretamente e na gravação do firmware já é estabelecido valores fixos,logo as variáveis foram carregadas corretamente e os valores da eeprom estão corretos,mas ao ler os valores das variáveis e passar para o PC,só a primeira parte(60 bytes)são enviados corretamente,a segunda parte é enviada a 28 bytes a frente do endereço especificado pela rotina
Para melhor compreensão,mostra as rotinas;

Código: Selecionar todos

  static int8  data_pc[120];

---------------------

void Mostra_Keyboard01(void)
   {
    int8 i;
     for(i=24; i<84 ; i++)
      {
       out_data[i-24] = read_eeprom(i);
       // out_data[i-24] = data_pc[i-24];
      }
   }

  void Mostra_Keyboard02(void)
   {
    int8 i;
     for(i=84; i<144 ; i++)
      {
       out_data[i-84] = read_eeprom(i);
       //  out_data[i-84] = data_pc[i];
      }
   }

A primeira rotina funciona corretamente utilizando a variável data_pc,que é onde fica armazenado os valores no boot(primeiros 60 bytes),a segunda não,os valores são mostrados 28 bytes a frente,mas se eu ler diretamente da eeprom,sem mudar nada na rotina,os valores ficam correto.
Para 'resolver' utilizei a leitura direta da eeprom nas duas rotinas.
O que pode estar ocorrendo?
O compilador não está encontrando algum banco da Ram?
Alguem tem alguma ideia?

[andre_luis]

Meu palpite é porque você utilizou uma variável i para indexar o array que poderia assumir valores de -127 á 128 mas voce está utilizando até 144, isso porque o compilador por padrão define int8 como signed.

[vtrx]

Não pensei nisso,depois vou testar.

PS:Ainda não testei,mas acho que não é isso pois tenho a rotina que carrega os valores e ela utiliza int8 carregando valores entre 24 e 144.

[KrafT]

O que faria para testar...
Primiero, separaria o índice, só para teste:

Código: Selecionar todos

  void Mostra_Keyboard02(void)
   {
    int8 i,j=0;
     for(i=84; i<144 ; i++)
      {
       out_data[j] = read_eeprom(i);
       j++;
      }
   }


Depois, mandaria essa informação para uma outra saída, como porta serial, display, etc. para localizar o ponto em que o problema ocorre. Receio que seja na biblioteca USB HID.
O CCS é legal, mas as vezes é temperamental.

[vtrx]

Alguem sabe me dizer se oCCS lida com os bancos automaticamente conforme o código cresce?

[andre_luis]

Sim, voce nao precisa se preocupar com isso.

[KrafT]

Já fiz projetos com o CCS em que tive que usar partes em assembly para caber num PIC16F648, mas sem ter que me preocupar bancos da RAM e a encrenca do PCL+PCLATH, que no assembly seria uma tortura. Mais tarde só me sobrou um projeto com 18F para manter, o que á mais favorável ao compilador, também sem maiores surpresas.

Mas quanto ao problema original? Resolveu?

[vtrx]

Mas quanto ao problema original? Resolveu?

Ainda estou terminando o Software no lado do PC,depois volto a parte do Soft do PIC.

[andre_luis]

Ja tive um projeto no CCS em que tive de trapacear o compilador, não sei se foi problema de Banco (acho que nao) ou se foi outra coisa, mas tive de repartir um array const extenso em partes menores que 256 bytes.

[Red Neck Guy]

Quando eu comecei a querer unificar minhas bibliotecas, tive que parar de utilizar o CSS, pois ele não é sério.
Faz tempo que não uso PIC, mas nas última vez utilizei o hitech C, acho que agora é da própria microchip e tal.
É doloroso no começo, mas é muito melhor buscar compiladores ANSI C89 ou C99 e codificar dentro do padrão, pois quando tu mudar de plataforma - e um dia vai precisar disso - tuas bibliotecas migram contigo.(Em tese)