ASM51

Após tanto relutar acabei por mudar de compilador (CCS para MikroC pro versão 5.4) ) e tão grande foi minha decepção ao ver que um programa que havia sido compilado no CCS com uso de 61% de ROM e 32% de RAM(118 bytes), não podia ser compilado no tão louvável MikroC pro, por falta de RAM...

Troquei o PIC de 16f877A para um com mais RAM e ROM: o 18F4550, e o MikroC conseguiu compilar com uso de 474 bytes...

Agora eu pergunto será que as rotinas prontas do ccs são melhores que a do mikroc? ou sou eu na minha ignorância que não estou sabendo fazer bom uso delas(do mikroc)???

Pelo que vi nas estatísticas o compilador aloca muitos endereços para variáveis que não pertencem ao meu programa e algumas consomem até 40 bytes, nas configurações vi que o menor uso de RAM pelo mikroc pro ocorre quando ativo a opção Dynamic link for string literals.

Ajuda aew...

Algo que pode estar afetando o consumo da memória, é o fato de que provavelmente alguma rotina que voce acessava implicitamente por módulo de Hardware, agora o compilador deve estar implementando a manipulação por Firmware.

É apenas um palpite, mas já passei por algo parecido...

+++

Pela grande diferença, acredito que alguma declaração de buffer de constante pode estar sendo alocada em RAM, algo como strings e ....

Dê uma olhada no .lst gerado....

não se preocupe. a apollo 8 passou por isso também. deu erro 1202 na hora de pousar. vi isso ontem no discovery enquanto voce via a apuração das escolas de samba ou algo do gênero.

perdi o contato com mikroc. mas me lembrei que quando comecei a mexer com o hitech-c passei por estes momentos também: para este pic16 voce tem que especificar qual banco de memória ele está usando na variável. p.ex. unsigned int bank1 tmp,tmp1,tmp2; de repente tem algo semelhante no mikroc. Como disse não me lembro. Outra dica é usar o sdcc que no atual estágio pode até gerar codigos menores que o mikroc além de ser gratuito e integrável ao mplab. No entanto se tiver um trocadinho sobrando, vá de hitech-c. Gera código de tamanho igual ou menor do que se fosse feito em asm. Ele tem um lance de gerar 2 letras por 'palavra' de programa o que otimiza o uso de strings.

a dica do amigo barboza tem todo sentido
abç

o mikroC tem deficiencias de baixo nivel.
tipo, por algum motivo o montador vai alocar um swapf, cara o compilador usa quase 115 bytes pra isso, e não é dinâmico é estatico isso !!
sprintf então c ta loco !!!

Outra coisa é a forma de definir strings na rom ou na ram, no mikroC é diferente do CCS e do HITEC, você precisa dar uma olhada no help.
Em tools tu consegue mexer nisso viu, otimizar de 0 a 5.

Por isso não uso mais pic, hoje não me preocupo mais com isso.. hehe

eu ia editar meu post com relação à apollo 8
na verdade só tem um pouco a ver pois não estavam compilando e sim executando. Resumo: o tal erro 1202 era de sobrecarga do uso do 'computador' que tinha 73K. Os programas eram literalmente costurados com fios de cobre. Conseguiram compactar o computador no tamanho de uma geladeira. Um algoritimo de uso de maior recurso para tarefas principais pode ter salvo a missão e a vida dos astronautas. fica a dica para assistir "veículos lunares ep. 8" (acho). mó legal. Bom agora nem precisa ver + . off topic nada a ver né.

Voltando do mundo da lua...
os printf da vida não foram feitos pros mc pequenos. come memoria pracarai. tampouco use floats ou variável maior que 16 bits. jamais faça conta complexa como seno cosseno e afins e finalmente etc... esta dica sim resolve tudo

abç & boa sorte

Eu estou usando o CCS num firmware e eu realmente preciso mexer com floats. O CCS está gerando bugs dos mais improváveis, chegou a um ponto de eu fazer
printf("%f %f", variavel, variavel)
ou seja, imprimo das vezes a mesma variavel no mesmo printf e ele imprimir dois valores diferentes.
O CCS tá me tirando o sono. Que compilar seria mais recomendável, o Hitech ou o MikroC? A Microchip não mantém mais o PICC?
O sdcc está num ponto de ser chamado de confiável?
Qualquer sugestão, dica ou experiência me é bem vinda!

nada ainda...
coloquei algumas variáveis dentro de funções para que se tornassem locais e ocupassem ram apenas quando necessário mas ... ganhei uns 30 bytes
Não estou encontrando o problema. Vi que se deixar de selecionar algumas Librarys o código fica menor... já eliminei até a chamada de delay ao longo do código, chamando uma função delay pois li que o compilidaor insere mais código quando encontra delay_ms()....
Resumindo... como fazer para o MikroC Pro vencer o CCS????

xultz escreveu:Eu estou usando o CCS num firmware e eu realmente preciso mexer com floats. O CCS está gerando bugs dos mais improváveis, chegou a um ponto de eu fazer
printf("%f %f", variavel, variavel)
ou seja, imprimo das vezes a mesma variavel no mesmo printf e ele imprimir dois valores diferentes.
O CCS tá me tirando o sono. Que compilar seria mais recomendável, o Hitech ou o MikroC? A Microchip não mantém mais o PICC?
O sdcc está num ponto de ser chamado de confiável?
Qualquer sugestão, dica ou experiência me é bem vinda!

Se você quer um compilador C profissional, você deve usar Hi-Tech C ou IAR. Eles são compatíveis com ANSI C, mas limitados funções específicas prontas como tem o CCS, MIKROC

O MPLABC, acredito que nao tenha bugs...coisas complexas, como pilhas TCP/IP, miwi, zigbee, ethernet...milhares de linha...rodando perfeitamente...sem bugs visiveis...mas tambem limitado em funções prontas...

lellis escreveu:eu ia editar meu post com relação à apollo 8
na verdade só tem um pouco a ver pois não estavam compilando e sim executando. Resumo: o tal erro 1202 era de sobrecarga do uso do 'computador' que tinha 73K. Os programas eram literalmente costurados com fios de cobre. Conseguiram compactar o computador no tamanho de uma geladeira. Um algoritimo de uso de maior recurso para tarefas principais pode ter salvo a missão e a vida dos astronautas. fica a dica para assistir "veículos lunares ep. 8" (acho). mó legal. Bom agora nem precisa ver + . off topic nada a ver né.

Posta o linka aê mano!

Valeu truta!

Eu dei uma olhada no site da IAR, e parece que eles pararam de desenvolver o compilador prá PIC, e me parece que a Keil também. Será que é isso mesmo?

Xultz

O SDCC parece bom...para teres uma idéia...os telefones ip que "projetei"...foram escritos em SDCC para Z80... e estão funcionando 100%

chrdcv vi aquilo no discovery science. mesmo se tivesse não gosto de linkar publicamente coisas do submundo. Mas googlei isso procê
http://meiobit.com/76058/apollo/
está fiel à reportagem que vi

xuts/itamar,
Apesar de eu achar que se voce não usar lib pronta (tipo printf... pelamôr né! 2old4this) deve ter uma redução de espaço considerável, hitech-c resolve vosso problema. sdcc (pros pics) pra programas simples = ok. Pra um médio que era de acionar matriz de leds eu não obtive sucesso. O problema é ele mesmo pois o fonte serve pro hitech e sdcc só chaveando um #define. O projeto mplab com fontes e simulação no proteus estão a diposição bastando me implorar de joelhos. Não tenho programas complexos com tcpip usb etc pra testar. Só tenho "pisca leds"



tá perdido por aí um post meu com fotos e fontes. me lembro usei um pic com 1k escrever num display gráfico com hitech c e com pouquíssimo conhecimento (o que não podia ser diferente). grande m****. mas foi impensável pro mikroc e em asm estaria tentando até hoje.
abç & sucessos!

xultz escreveu:Eu estou usando o CCS num firmware e eu realmente preciso mexer com floats. O CCS está gerando bugs dos mais improváveis, chegou a um ponto de eu fazer
printf("%f %f", variavel, variavel)
ou seja, imprimo das vezes a mesma variavel no mesmo printf e ele imprimir dois valores diferentes.
O CCS tá me tirando o sono. Que compilar seria mais recomendável, o Hitech ou o MikroC? A Microchip não mantém mais o PICC?
O sdcc está num ponto de ser chamado de confiável?
Qualquer sugestão, dica ou experiência me é bem vinda!

XULTS

Use sprintf...

testei printf....dá pau...

TCPIPCHIP