Rotina(s) tipo objeto.

[fabim]

Pessoal.
Me surgiu uma duvida meio estranha, mas não custa perguntar.

Imaginem o seguinte.
Eu possuo um APP rodando num ARM7, onde eu fiz uma estrutura de ponteiro para rotinas....

Existe a possibilidade eu eu.:

Compilar uma rotina no pc, enviar o "(HEX intel 32) até aqui tudo bem" para o arm.
O Arm faria um HEX to bin desta rotina, alocaria na memoria RAM no setor que eu criei pra programa, e (agora o bixo pega) faria um CALL para esta memoria de programa na ram, e no final da rotina etc, o PC sairia da ram e voltaria novamente e lindamente rodando na flash.

É possivel isto ? o ARM7 me da esta liberdade ? Indexar CALL´s dinamicamente ?

[Red Neck Guy]

Sim, dá pra fazer.
Se tu compilar a função toda com a base de endereço lá de onde irá rodar na ram, o fato da rotina ter sido carregada dinamicamente não tem problemas.
Inclusive, poderia fazer

Código: Selecionar todos


void(*ptr)(void);

ptr = void(*)(void) 0xFFFFFF;//o endereço e tal
ptr();



O importante nisso é saber como o compilador passa os parametros pra função e o onde a função coloca as coisas quando retorna. Isso, no caso do IAR, até que é fácil de fazer. Dá pra compilar um programa e gerar o disassembly - inclusive num doc deles sobre isso, eles indicam fazer isso.

[Rodrigo_P_A]

Pessoal.
Me surgiu uma duvida meio estranha, mas não custa perguntar.

Imaginem o seguinte.
Eu possuo um APP rodando num ARM7, onde eu fiz uma estrutura de ponteiro para rotinas....

Existe a possibilidade eu eu.:

Compilar uma rotina no pc, enviar o "(HEX intel 32) até aqui tudo bem" para o arm.
O Arm faria um HEX to bin desta rotina, alocaria na memoria RAM no setor que eu criei pra programa, e (agora o bixo pega) faria um CALL para esta memoria de programa na ram, e no final da rotina etc, o PC sairia da ram e voltaria novamente e lindamente rodando na flash.

É possivel isto ? o ARM7 me da esta liberdade ? Indexar CALL´s dinamicamente ?

sim, eu já faço isso, a idéia é como o Aquino disse. Funciona sim.

[tcpipchip]

Fabim, funciona
É assim que uso para o UCLINUX

Código: Selecionar todos

#######################################################################################*/

#include "main.h"

/*#######################################################################################
Config System
#######################################################################################*/
void SystemInit(void)
{

   // --- enable and connect the PLL (Phase Locked Loop) ---
   // a. set multiplier and divider
   SCB_PLLCFG = MSEL | (1<<PSEL1) | (0<<PSEL0);
   // b. enable PLL
   SCB_PLLCON = (1<<PLLE);
   // c. feed sequence
   SCB_PLLFEED = PLL_FEED1;
   SCB_PLLFEED = PLL_FEED2;
   // d. wait for PLL lock (PLOCK bit is set if locked)
   while (!(SCB_PLLSTAT & (1<<PLOCK)));
   // e. connect (and enable) PLL
   // Cuidado, se usar LPC2478
   SCB_PLLCON = (1<<PLLE) | (1<<PLLC);
   // f. feed sequence
   SCB_PLLFEED = PLL_FEED1;
   SCB_PLLFEED = PLL_FEED2;
   
   // --- setup and enable the MAM (Memory Accelerator Module) ---
   // a. start change by turning of the MAM (redundant)
   MAM_MAMCR = 0;   
   
   SCB_EXTPOLAR= 0x04;
   SCB_EXTINT   = 0x04;
   
   
   // b. set MAM-Fetch cycle to 3 cclk as recommended for >40MHz
   MAM_MAMTIM = MAM_FETCH;
   // c. enable MAM
   MAM_MAMCR = MAM_MODE;
   
   // --- set VPB speed ---
   SCB_VPBDIV = VPBDIV_VAL;
   
   // --- map INT-vector ---
    SCB_MEMMAP = MEMMAP_USER_FLASH_MODE;
}

void swiirqp (void)
{   
   printf("\Trap...\n");
}

/*#######################################################################################
Main Programm
#######################################################################################*/
int main(void)
{

   void (*kernelstart)(void);
 
   SystemInit();
 
   uart0Init(B9600, UART_8N1, UART_FIFO_OFF); // setup the UART
   
   PCB_PINSEL2 = 0x0F814924; //Init Extendet Memory
   BCFG1 = 0x2000FFEF;

   
   printf("\n\n\r");
   printf("*******************************************\n\r");
   printf("*                                         *\n\r");
   printf("*    ARM Linux MMC Boot Loader            *\n\r");
   printf("*                                         *\n\r");
   printf("*                                         *\n\r");
   printf("*******************************************\n\n\r");
   while (mmc_init() != 0)    //setup the MMC Card
         {
            printf("**MMC/SD - Card not found! **\r");
         }

   //Speichern der Cluster Size und Cluster Offset (Anfang Datenbereich)
   Cluster_Data_Store();
   //Initialisierung der MMC/SD-Karte ENDE!

   load_file (FILE1,(int*)KERNEL_START);
   //verify_file (FILE1,(int*)KERNEL_START);
   //load_file (FILE2,(int*)BOOTIMG_ADDR);
   
   printf("\n\n\Executando KERNEL!\n\n\r");
   
   PCB_PINSEL0 = 0x80000005;
   PCB_PINSEL2 = 0x0F814924;
   
   BCFG0 = 0x2000FFEF;
   BCFG1 = 0x20000420;
   BCFG2 = 0x0000FFEF;
   BCFG3 = 0x0000FFEF;

   VICDefVectAddr = 0x81000018;
   
   kernelstart = (void (*)(void))KERNEL_START;//KERNEL_START;      
   (*kernelstart)(); 
   
   printf("Alcance me se for capaz");
   
   while(1)
      {
      }
return(0);
}




[fabim]

Hum, nossa.
A gente fica tanto tempo trabalhando limitado com algumas merdas, que quando passamos pra coisa muiiiiito muiiiito muiiito melhor, a gente continua com o pensamento fechado.
Tipo, eu imaginava isso como sendo coisa somente para risc, e SO. Não imaginava que poderia fazer isso em RISC na unha.

Aquino a parte de endereço é tranquilo, pode refazer a tabela.. o padrão INTEL HEX32 é simples !! Tipo tu manda o hex pro ARM, ele faz a linkedição para endereço estatico ou dinamico depende, independente do endereço que o HEX foi compilado.

Pessoal, muito obrigado pela ajuda!!

Descobri como funciona uma poha de um equipo, que eu queria descobrir a alguns anos!!

[Red Neck Guy]

O que deve ser observado é o contexto, pra não quebrar a aplicação que tá chamando essas rotinas dinamicamente. Mas na documentação do compilador tem lá um lugar onde diz onde ele passa os parametros pra função, e onde a função deve devolve-los. Essa é uma coisa que deve ser observada, pois quebrando o contexto a chance de quebrar a aplicação é alta.

[fabim]

O que deve ser observado é o contexto, pra não quebrar a aplicação que tá chamando essas rotinas dinamicamente. Mas na documentação do compilador tem lá um lugar onde diz onde ele passa os parametros pra função, e onde a função deve devolve-los. Essa é uma coisa que deve ser observada, pois quebrando o contexto a chance de quebrar a aplicação é alta.

Aquino eu não entendi.
Pode me explicar um pouco melhor ?

[Red Neck Guy]

Assim, digamos que o código que tu queres executar dinamicamente é uma função e não uma aplicação que substituirá o programa atual como no caso do uCLinux exemplificado pelo Miguel.
Dessa forma o teu código que será chamado em tempo de execução deve respeitar a passagem de parâmetros e uso dos registradores, pois, se o teu código alterar alguma coisa que o código em execução já estava utilizando quando tu retornar da função o teu programa ficará altamente louco. Se quiser usar esses dados de retorno e passados por referência, utilizando a convenção de chamada, a função dinâmica vai "se comportar como uma estática".
Agora, se o programa for mesmo só um loader, como esse do uClinux, é só copiar o código pra lá, dar um JUMP e só alegria.

[fabim]

Tendeu Aquino!!

Cara, eu tinha pensado em algo bem simplista, onde os parametros de entrada e saida, não existiriam..
Seria algo do tipo criar literalmente uma estrutura bem grandinha que comportaria todas as variaveis do sistema, flags, etc.

Uma coisa que eu estou batendo cabeça e não to conseguindo nem a pau, talvez ninguém aqui tenha conseguido. rsrsrs

Compilar um codigo.C no windows, sem o uso de uma IDE qualquer, tipo usando o GNU for windows... Eu pesquisei pra caramba e não achei nada em lugar nenhum!!

[tcpipchip]

Use entao o WINARM

Eu usei muito para o UCLINUX em 2006

http://gandalf.arubi.uni-kl.de/avr_proj ... ts/#winarm

Teu projeto deve ter um MAKEFILE...e no prompt de comandos voce digita

make

Tambem neste TCC que orientei utilzamos WINARM (linha de comando)

http://www.bc.furb.br/docs/MO/2008/331560_1_1.PDF

T+

TCPIPCHIP