Migração de microcontroladores

Leonardo A. Corinta Trinta · 30 de junho de 2016

Fala pessoal, tudo em ordem?

Estou na seguinte situação:

Tenho um projeto antigo e algumas alterações foram necessárias, porém, no final do caminho me deparei com o problema mais trash da história: Falta de memória no uC. Tentei otimizar o máximo que consegui o bendito código, mas não adiantou. Originalmente, o projeto utiliza o arcaico AT89S8253, eu não consegui encontrar nenhum da mesma linha com mais memória de código, então fui atrás do AT89LP3240 que aparentemente é compatível (através da inspeção dos pinos) mas quando tentei portar o código, tive problemas e por fim não consegui fazer com que o trem funcionasse.

Sem mais mimimi, gostaria de saber se alguém conhece algum uC compatível com o AT89S8253, porém com mais memória, ou se já passaram por essa situação e se há ainda uma luz no fim do túnel que não resulte em todo o reprojeto (kk).

Obrigado desde já e um forte abraço!

.if · 30 de junho de 2016

Sim já tive contato com o 89s8253 há muito.. muito tempo mesmo.

Sabendo-se que não basta apenas a...

1 hora atrás, Leonardo A. Corinta Trinta disse:

inspeção dos pinos

Fale mais sobre isso...

1 hora atrás, Leonardo A. Corinta Trinta disse:

quando tentei portar o código, tive problemas

Se for c, há mais chance de obteres ajuda. O macete está em preparar ou setar o hw corretamente pois o núcleo seria a lesma lerda.

Se assembly, só lamento

Leonardo A. Corinta Trinta · 30 de junho de 2016

3 minutos atrás, Isadora Ferraz disse:

Sim já tive contato com o 89s8253 há muito.. muito tempo mesmo.

Sabendo-se que não basta apenas a...

Fale mais sobre isso...

Se for c, há mais chance de obteres ajuda. O macete está em preparar ou setar o hw corretamente pois o núcleo seria a lesma lerda.

Se assembly, só lamento

Fala Isadora, obrigado por responder.

Bom, falando um pouco sobre o código, é bem antigo e está em C, mas foi escrito de uma forma não muito conveniente (tudo em um loop) com umas máquinas de estados jogadas para todo lado e sem nenhuma indicação. Fora o desabafo, indo realmente ao que interessa, vou listar algumas coisas que fiz ou tentei fazer. Lembrando que a IDE é o Keil (que na minha opinião é muito limitado, ou eu que não sou tão familiarizado com ele).

A primeira delas foi mudar na IDE o uC para qual estava sendo compilado. Após a inclusão do novo header, percebi que um registro utilizado para controle da eeprom não existia no novo uC (EECON), sei que não é boa prática, mas fui comentando todas as linhas em que o tal aparecia (kk). O código utiliza ele basicamente para liberar o acesso a memória em alguns momentos e gravar algumas flag's e informações. Bom, compilei, não funcionou. É como se o uC não estivesse colocado na placa.

Aparentemente o gerenciamento de memória é diferente no 89PL3240 (também encontrado com 64k de flash como 89PL6440). Tentei liberar o acesso a memória com o MEMCON mas não resultou em nada. Sempre o mesmo problema.

De forma básica foi isso até agora, não tenho grande experiência com esses caras, então pode ser que eu esteja deixando passar algo que seja básico, mas até agora não encontrei. Até agora não consegui definir se o uC está iniciando e travando o programa ou se nem iniciando está. Não sei se pode ser alguma configuração na IDE ou no momento de gravar (utilizo o Elnec PG4UW) .

Abraços!

.if · 30 de junho de 2016

1 hora atrás, Leonardo A. Corinta Trinta disse:

um registro utilizado para controle da eeprom não existia no novo uC (EECON),

é disso que estou falando. Além dos pinos compatíveis, você deve analisar se o hw interno o é. P.ex. (por intuição/dedução-não li o d.s) o novo mc não tem eeprom interna e...

1 hora atrás, Leonardo A. Corinta Trinta disse:

liberar o acesso a memória em alguns momentos e gravar algumas flag's e informações

pode ser parte importante do kernel para a boa fluidez das funções (falei bunito agora hein...)

Desconheço o lance de MEMCON (por dedução: controle de memória. qual/como/porque.. descubra) e k entre nós

1 hora atrás, Leonardo A. Corinta Trinta disse:

Sempre o mesmo problema.

Haja bola de cristal!!

1 hora atrás, Leonardo A. Corinta Trinta disse:

se o uC está iniciando e travando o programa ou se nem iniciando está.

Pra decidir isso é fácil: faça um pisca led com seu hw mesmo. No mínimo 1 led deve ter nele né?! E que não seja verde

1 hora atrás, Leonardo A. Corinta Trinta disse:

não tenho grande experiência com esses caras

tamo junto. Mas nada que uma boa leitura no d.s. e conhecendo o circuito não resolvam

Leonardo A. Corinta Trinta · 30 de junho de 2016

5 minutos atrás, Isadora Ferraz disse:

é disso que estou falando. Além dos pinos compatíveis, você deve analisar se o hw interno o é. P.ex. (por intuição/dedução-não li o d.s) o novo mc não tem eeprom interna e...

pode ser parte importante do kernel para a boa fluidez das funções (falei bunito agora hein...)

Desconheço o lance de MEMCON (por dedução: controle de memória. qual/como/porque.. descubra) e k entre nós

Haja bola de cristal!!

Pra decidir isso é fácil: faça um pisca led com seu hw mesmo. No mínimo 1 led deve ter nele né?! E que não seja verde

tamo junto. Mas nada que uma boa leitura no d.s. e conhecendo o circuito não resolvam

kkk... Pois é, no datasheet não fala sobre eeprom interna (deduz-se que ela não exista).

Infelizmente não há um led que eu possa acessar diretamente, isso porque todo o controle de periféricos é realizado por latches (controlados por SPI), eu tenho um latch para uma barra de led's (amarelos), que deveria acender logo no início e não, não acende, na realidade, nada está sendo controlado. Acho que respondi minha pergunta né?! Acredito agora que o programa não esteja sendo executado.

Dando uma estudada no datasheet, me parece que a forma como as coisas são armazenadas na memória é diferente e a forma de acessá-lá também, mas mesmo assim, o uC deveria dar um sinal de vida pelo menos (não?), penso isso pois armazeno variáveis no xdata e apenas atribuo valores aos mesmos, deveria rodar. Não acho que seja algo relacionado ao acesso da memória.

Vou montar um hello world na proto, vamos ver o que vira, rs.

Posto aqui se algo der certo...

Abraços.

Leonardo A. Corinta Trinta · 1 de julho de 2016

Um salve a todos,

Bom, descobri o problema. Com tantas coisas acontecendo ao mesmo tempo aqui, não me atentei ao essencial: Power Supply. (kkk).

Não me zoem!!

Recebi a recomendação em um dos fóruns da atmel, de utilizar para substituição o uC AT89LP51ED2, me parece que será mais tranquilo já que o mesmo possui eeprom interna e os registros parecem bater. Quem sabe não dê certo, só preciso encontrar para comprar aqui.

Bom, não resolvi o problema, mas fica a lição:

É importante descansar a cabeça antes de trabalhar e tomar cuidado ao fazer muitas coisas ao mesmo tempo, ou tentar fazer, rs.

Forte abraço a todos e obrigado pela ajuda, Isadora.