ASM51

Olá pessoal
Estou migrando um software que eu escrevi para um MSP430F1232 para o 89S53. Acontece que começou a encher a ram do 89S53. É só adicionar algumas funções e começa a não compilar mais por falta de memória.
Então fiz um teste simples: Em uma função tenho um vetor de 10 posições (variável local). Agora em outra função declaro denovo um vetor de 10 posições, também variável local. Acontece que ao declarar este ultimo vetor, na informação do tamanho da memória DATA, aumenta em 10bytes.
Como são variáveis locais imagino que poderia ser compartilhado os endereços de memória, mas do jeito que tá parece que é tudo variável global.
Mudei de tudo quanto é jeito as configuração do compilador e não muda nada.
Tem jeito de consertar isso?

sds
Henrique Thiesen

Caro Henrique,

Não utilize o 89S53 pois esse mcu deixou de se fabricado. Se estiver se referindo ao 89S8253, tudo bem.

A memória interna desse micro é dividida em 128 bytes na memória direta e 128 bytes na memória indireta.

Tente colocar a maior parte de suas variáveis na memória indireta (exceto índices de laços). Isso pode resolver seu problema.

Use a diretiva idata na definição da sua variável.

p.ex.

idata unsigned char vetor[16];


Outra coisa, se você tiver muitas variáveis globais, você pode ter problemas na compilação. Tente usar mais variáveis locais.

sds
Jorge

Olá Jorge
No desespero por mais memória já havia usado a diretiva idata, mas isso só me deu um folego a mais, não sendo suficiente. Ainda tenho que colocar muitas funções e o que tenho notado é cada variável local que eu declaro parece ser uma variável global, pois o compilador não está compartilhando esses endereços alocado para variáveis locais.

Só um palpite:

Procura mudar o nível de otimização do compilador e testar depois.


+++

Já mexi em todos níveis de otimização e não tem jeito. Alguma coisa tem de errado nisso. Fiz o mesmo teste no programa original que fiz no IAR para msp430, e a declaração de variáveis locais (no caso um vetor de 10 posições) não muda nada no espaço de ram usado.
Estava vendo na ajuda do Keil tem alguma coisa sobre data overlaying, mas parece que por default é usado data overlaying.

Talvez seja um problema do Linker, e não do compilador. Estas funçoes estão em módulos diferentes ?

Que versão do Keil voce está usando ?

+++

As funções estão em modulos diferentes, mas para testar coloquei tudo em um arquivo e o diagnostico é o mesmo. Meu keil é 8.01 e testei também no 7.2.

Se você estiver chamando uma função dentro da outra, o compilador não poderá compartilhar a mesma area de memoria para o seu vetor, pois assim o valor delas não será preservado.

Talvez o problema não esta no compilador, e sim na sua estrutura.

Ex.:

void func1(void)
{
char vet[10];

.......


}

void func2(void)
{
char vet[10];

.......
func1();
........


}

Tem razão barboza, não tinha pensado nessa situação.

Mas agora fiz outro teste: Compilei o programa com o SDCC...e voilá...funcionou, só não onde informa a quantidade de ram usada.
Acho que não estou sabendo trabalhar com o programa em diversos modulos no keil. Quando compilei no SDCC o compilador chiou, ainda precisei escrever muitos include nos arquivos dos módulos.

Vou dizer como estou fazendo no keil. Adiciono o arquivo com a main.c no Source Group 1 do keil.(Ou devo adicionar todos os arquivos de todos módulo??)

No inicio do arquivo main.c coloco os includes de todos os modulos.

Esse consumo exagerado de memória é parecido com aquela situação de o Keil tratar rotinas declaradas mas que não são chamadas como interrupção.

Pessoal, problema resolvido.
Eu tenho alguns vetores com o nome dos dia da semana e meses, e declarei como const unsigned char. Aí não tem ram que aguente mesmo. Por isso quando eu incluia minha biblioteca de calendário estourava a ram. Mudei para "code" e tudo resolvido.

Obrigado pela contribuição de todos