Arquivos *.hex - LPC2138 - Keil

[lrfad2]

Eu preciso modificar o meu arquivo *.hex afim de viabilizar a produção. Para que vcs consigam entender um pouco melhor eu fiz um controlador para um LCD 240x128 dots. Na memória flash do LPC2138, tem um array armazenado a propaganda do cliente. Ou seja, da maneira que está hj, a cada mudança de cliente eu tenho que modificar o array e recompilar (que é ruim pra mim).

Dei uma olhadinha no formato mais comum do arquivo *.hex que é o da Intel 32 bits (http://en.wikipedia.org/wiki/Intel_HEX). A priori está incoerênte e não consigo explicar o pq. Então as perguntas que faço são: O Keil gera o *.hex no formato Intel 32 bits ? Caso sim, qual é a inconsistência do meu raciocínio na figura abaixo

Muito obrigado pela atenção, e um forte abraço a todos.

[Kremer]

Olá

O produto tem alguma interface de comunicação? Em caso positivo, não seria mais interessante e cômodo fazer um esquema de carregamento e troca do bitmap por esta interface, usando IAP na área reservada para o mesmo?
Talvez isto aqui possa lhe ajudar. Dá uma olhada:

http://www.keil.com/support/docs/1584.htm

Kremer

[lrfad2]

Ola Kremer,

Essa proposta que vc apresentou é muito bacana, mas eu ainda não tenho domínio sobre a IAP... Até onde li a respeito, nos chips da ST vc consegue colocar código nessa área reservada, o que não acontece com os LPC´s.

Outra solução é utilizar a interrupção por Sw para gravar na flash, coisa que tenho uma leve impressão de como fazer mas ainda não testei...

Então, resolvi começar pelo mais simples que é a alteração do *.hex...

De qq maneira muito obrigado pela ideia

[lrfad2]

Acredito que por estar utilizando o U-link2, o Keil, deve acrescentar algo ao código...
Quando mandei debugar utilizando o simulador ai as coisas ficaram coerentes. Seguem as imagens abaixo:

Obrigado a todos

[Kremer]

Olá Irfad2

Agora sim as coisas estão mais claras. Provavelmente o compilador estava inserindo instruções para debug no código. Não utilizo o keil mas com certeza deve haver uma opção no setup de projeto para excluir o debug.
Quanto ao IAP, os LPC´s fazem isto sim. Dá uma olhada no User Manual, pois no datasheet não tem informação detalhada. Basta você definir uma seção da flash no arquivo do linker que seja reservada para armazenar a imagem a ser exibida e posicionar uma imagem padrão nesta área. Para facilitar, o início desta seção deve estar declarada em algum endereço múltiplo do tamanho do setor interno da flash, o que facilita o apagamento somente deste setor na hora de reprogramar usando IAP. Não se deve colocar código nesta seção, somente o arquivo responsável pela imagem (bitmap). Pode-se colocar também flags sinalizadores para a rotina que irá ler esta região e colocar o bmp no lcd, justamente para definir por exemplo a nova orientação (x e y) e outras coisas. Assim existiria uma grande mobilidade quanto ao tamanho de cada bitmap.

Abraço
Kremer

[lrfad2]

Ola Kremer,
Muito obrigado pelas dicas... vou tentar implementá-las.
Uma outra pergunta que tenho é como criar um ponteiro de 32 bits..

por exemplo eu fiz:

unsigned long *pointer;
unsigned long Valor

se faço:
pointer = 0x0000001F;
Valor = *pointer;

funciona corretamente, mas se faço

pointer = 0x0004001F;
Valor = *pointer;

ele dá o erro #513: a value of type "int" cannot be assigned to an entity of type "unsigned long *"

[Kremer]

Hum, me parece algum detalhe de configuração da IDE para lidar com os tipos de dados.
Tenta fazer um cast:

Valor = (unsigned long)(*pointer);

Só realmente não entendi o que você estaria querendo fazer, pois ao carregar um ponteiro com um valor, e tentar repassar o conteúdo deste ponteiro para uma variável, você estará efetivamento repassando para a variável o conteúdo de memória que está sendo apontado pelo ponteiro. Não espere que a variável valor tenha 0x0004001F por exemplo.

Kremer

[lrfad2]

Deu certo não Kremer...

Eu consegui gerar um arquivo externo *.hex que carrega a minha imagem no endereço inicial de 256K. Então é isso mesmo que vc descreveu.. eu pretendo pegar o dado contido no endereço 0x00040000 ou 0x0004001F como queira

[Kremer]

Ola Irfad2

De acordo com o seu post anterior, havia entendido que a variável pointer estava declarada como unsigned long, mas pelo jpeg vejo que você está declarando como unsigned int.
Bem, neste caso o casting também deve resolver, porém precisa ser do tipo da variável.
Ou declare o seu ponteiro como unsigned long e utilize esta linha por exemplo:

pointer = (unsigned long)(0x0004001F);

Deve funcionar, pois isto é tão trivial. Realmente não visualizo o porquê de não estar funcionando. Como disse, deve ser algum setup da ide para tipos de dados. Por exemplo, o codewarrior para coldfire deixa você escolher se o tipo de dado int é de 16 ou 32 bits.
Um detalhe. Pelo que entendi, você fez um aplicativo que abre um hex padrão e troca por exemplo um bitmap default e insere um outro no lugar dele, customizado para o cliente? Se sim, qual a diferença em termos de retrabalho seu exigido entre ter que recompilar o código com o bitmap do cliente e ter que rodar este utility para modificar o hex e gerar um outro hex a partir dele? É claro que você sabe que este novo bitmap deve ter o tamanho igual ao original, pois dependendo de como você declarou este array (const) , provavelmente o linker o colocou na seção rodata e se o novo bitmap for maior, vai sobrescrever dados de inicialização de outras variáveis e aí já viu né.

Abraço

[lrfad2]

Bom dia Kremer,
Eu tentei o que vc me disse mas mesmo assim o compilador acusou erro.. eu verifiquei no Keil e aparentemente toda declaração unsigned long é uma variável de 32bits. Concordo que é simples e deveria funcionar, mas só consegui resolver meu problema fazendo o seguinte: pointer = (U32*)(PointerAddr);, onde meu PointerAddr é uma variável de 32 bits.
Agora o que significa (U32*) pra mim ainda é um icógnita, pois achei isso num app notes da vida. Se souber e puder me explicar agradeço antecipadamente.

O que vc entendeu está correto... se fosse para eu fazer isso, tb concordo que não teria lógica fazer uma outra aplicação somente para alterar o Hex.
Todo esse processo será feito pela minha linha de montagem. Então para adquirir mais um uVison e Ulink sairia muito caro, sem falar que a produção teria acesso ao código fonte (que tb não é muito legal)

cara, muito obrigado mesmo pelas suas dicas e pela sua atenção
abraços
leandro

[Kremer]

Agora o que significa (U32*) pra mim ainda é um icógnita, pois achei isso num app notes da vida. Se souber e puder me explicar agradeço antecipadamente.

Leandro

Bom, como não mexo com o uVision não saberia te dizer onde realmente isto está declarado, mas tenho quase certeza de que o tipo de dado U32 está definido em algum .h como unsigned long.
Então você resolveu o seu problema criando a variável PointerAddr como sendo uma unsigned long por exemplo, carregando diretamente nela o endereço de memória do bitmap e por fim fazendo um casting (U32*) para a variável de ponteiro Pointer. Acredito que você nem necessite então da variável pointer. Você pode testar isto:

unsigned long PointerAddr;

PointerAddr = 0x0004001F;

E toda vez que quiser referir a variável PointerAddr como sendo um ponteiro para uma posição de memória, seria usando o casting. Ou seja, onde você usa a variável ponteiro (Pointer) atualmente, você poderia substituir por:

(unsigned long*)PointerAddr ou (U32*)PointerAddr

Deve acabar funcionando para ambos os casos.
Abaixo segue um exemplo de código que utilizo para apagar a flash interna de um coldfire para posterior salvamento de dados. O coldfire tem um esquema diferente dos arms para apagamento, por isso o segundo argumento da função que realmente apaga é (unsigned long) 0. Mas serve para demonstrar o uso do casting em C para apontamentos de posição de memória.

Código: Selecionar todos


int flash_erase( void *pio  )
{
 unsigned long address;

 flash_init();
   
 for( address = FLASH_START; address < FLASH_END; address += PAGE_SIZE )
 flash_page_erase( (unsigned long *)address, (unsigned long)0 );

 return(0);
}


Abraço
Alexandre

[lrfad2]

Bom dia Alexandre,
Desculpe -me por não ter detalhado... o U32 realmente é o unsigned long... eu mesmo declarei em outro include. O grande lance era o *, mas agora com a sua explicação tudo ficou mais claro...

Cara... eu tenho noção de C, mas ainda não posso me considerar um programador.. tem muito detalhezinho que eu não manjo...

Por exemplo agora estou com problema para declarar subrotinas reentrantes. É uma pena que vc não mexe com Keil. O mais engraçado é que uma pá de dicas no site da keil que vc copia e cola no compilador e dá erro... mas tudo bem se vc souber ou outro alguem e agradeço antecipado.

Vou continuar a pesquisa, se descobrir algo posto aqui
abraço