Definir endereço absoluto para constante

[ze]

Olás ... O stm32f051não tem eeprom mas conseguimos emular na flash mesmo. Preciso agora apenas manter 1 byte na posição 0xf000 junto ao arquivo .hex. Pra ler depois. Olha o que já fiz sem sucesso:

const char teste=0x55 absolute 0xf000;
const code char teste=0x55 absolute 0xf000;
const char teste=0x55 absolute 0x800f000; //=0x0801000-0x01000;
etc...

Isso no mikcroc com ajuda de seu help e da net. Preciso agora da sua. No seu compilador como vc define uma constante no seu endereço fixo e conhecido pra o mc desta família? Ou qual o modo genérico mesmo?
Grato.

[denis]

ze,

No GCC eu faço assim:

teste.c

Código: Selecionar todos

uint8_t var1_area[16] __attribute__ ((aligned(8), used, section(".var1_section")));

no arquivo do linker (.ld) você cria uma sessão

Código: Selecionar todos

  .var1_block (0x0004A000):   
  {
    __var1_start__ = .;
   KEEP(*(.var1_section))
  } >FLASH

mas como eu disse, isso vale para o GCC.

[ze]

Obrigado denis...
Meio que consegui assim:

Código: Selecionar todos

const unsigned char teste[]={1} absolute 0xf000;

Só que o compilador fdp não o cria se não o usar mesmo com as otimizações em zero. Assim sendo só fazendo uma atribuição inútil:

Código: Selecionar todos

unsigned char _tmp;
_tmp=teste;

aparece 01 no end 0xf000

Este é um valor de setup que devo alterar no "run time". Só que o 2º fdp é o mc que não grava por cima e nem apaga. Só apaga se eu apagar 1K! Ou seja preciso apagar 1000 pra ajustar o valor de 1. Ou seja se tiver outros setups babau. Estou a contornar isso com uma função que lê um pacotinho de flasheeprom (inventei isso agora), põe na ram, altera o que tem que alterar, apaga flasheeprom, reescreve o pacotinho de novo. Se vc (ou vc) tiver alguma ideia diferente, não se acanhe em contribuir...

[denis]

Sobre alterar o valor da Flash, não vejo outra abordagem a não ser a sua própria.
Basicamente carrega 1 setor da Flash na Ram, altera o valor na Ram, limpa o setor da Flash e grava da Ram na Flash.

[andre_luis]

Um artificio que usei seculos atrás com outro microcontrolador pra outra finalidade foi criar 2 mapas de memoria flash, sendo um o atual e outro o anterior; cada vez que alterava o valor de qualquer variavel escrevia no mapa 'anterior' que agora passava a ser o 'atual' e vice versa. Assim não teria de sobrecarregar a RAM, que tinha pouco disponivel. A vantagem dessa abordagem é a simplicidade, a desvantagem é ter de alocar 2 blocos de memória flash só pra isso. A proposito se voce estiver usando um RTC é provavel que tenha memoria disponivel, ao menos no ds1307 usei num projetinho a ram de uso geral para armazenar algumas configurações estaticamente, obviamente enquanto a bateria durasse, e durava.

[ze]

Obrigado Denis & André
Tive mais um insight. Como essencialmente preciso gravar 1 byte só, pensei em usar o artifício:
-defino um bloco de 1k pra setup
-gravo no 1º byte disponível
-este vai ser o que tiver o conteúdo 0xff
Algo como:

Código: Selecionar todos

for (addr=0;addr<0x400;addr++) if (fashread(addr)==0xff) break; //pronto... addr=disponível
if (addr==0x3ff) flasherase1k();
flashwrite(addr,dado);

De fato já meio que fiz isso e me lembro vagamente de ter comentado sobre em outra publicação...
Pra saber onde está o dado:

Código: Selecionar todos

for (addr=0;addr<0x400;addr++) if (fashread(addr)==0xff) break;
dado=flashread(addr-1);

Fica aí azidéia a quem interessar possa. Passível de reajustes...

[Fábio Pereira]

Olá,

Uma técnica que já utilizei no passado consiste em utilizar 0xFF como operador de controle e funciona assim: iniciando do primeiro endereço de dados da flash, o firmware lê cada byte até encontrar 0xFF ou atingir o fim do bloco. Em qualquer caso, o último valor lido (diferente de 0xFF) é o dado a ser utilizado.
Na gravação, o procedimento é similar, iniciando do primeiro endereço válido da flash, o firmware procura sequencialmente por uma posição com 0xFF ou até atingir o final do bloco, caso encontre 0xFF, o firmware escreve naquele endereço o novo dado, caso não tenha encontrado 0xFF e tenha atingido o fim do bloco, apaga o mesmo e grava o dado no primeiro endereço do bloco.
Em arquiteturas onde somente é possível gravar words (16 ou 32 bits) você terá de utilizar uma word ao invés de um byte, mas basicamente o procedimento é o mesmo.
Esta técnica também pode ser utilizada para armazenamento de estruturas e outros dados com tamanho constante, desde que você possa garantir que um valor lido contendo somente 1s seja considerado inválido para a aplicação.
No exemplo acima, o único limite é que você não pode salvar um dado contendo 0xFF na flash.
Há outras técnicas também (como mapas de bit) que permitem salvar bytes inteiros (inclusive 0xFF) mas que envolvem maior complexidade na determinação da endereço contendo o dado válido que pode ser lido e o próximo endereço livre que pode ser escrito.
Apesar das limitações, estas técnicas possuem alguns pontos muito positivos:
1- Wear-off grandemente reduzido (já que o número de apagamentos é reduzido consideravelmente);
2- Mais rápido e simples do que utilizar emulação de EEPROM;
3- Melhor desempenho em aplicações low-power, já que o número de apagamentos é reduzido e o tempo de apagamento é substancialmente maior que o tempo de escrita;
Espero que seja útil.
Ps.: depois que escrevi o post acima é que vi que o Zé também propôs basicamente a mesma técnica acima. Então o que escrevi acima basicamente só serve para validar a idéia dele!

[Guri]

Aqui vai minha opnião de amador, zé.

Eu tive o mesmo problema e acabei lascando uma eeprom externa e tudo se resolveu, tanto que quando faço algo com ARM, já deixo no hardware uma memória dessas.