Iniciando com RTOS MQX

[fabim]

Senhor!!!
PERDOAI OS QUE USAM RTOS PARA PISCAR UM LED.
POIS ELES NÃO SABEM O QUE FAZEM.

amen

[Ricardo_Franco]

Pessoal Calma lá ...
Sou iniciante neste RTOS, mas também não sou TÃO BURRO !!!

Preciso fazer uma aplicação com TCP/IP, julgo que o melhor caminho seja o RTOS, não está tanto a terra, (quanto ao nivel de escovar bits), e nem tanto ao céu, (quanto ao uso de um sistema uLinux, visto que precisaria de memória na ordem de alguns Mbytes).
Portanto estou incursionando neste mundo dos RTOS, e preciso de um start-Up, e um desenvolvimento progressivo.
Preciso controlar algumas variaveis analógicas, digitais, e posteriormente a pilha TCP/IP, o passo seguinte seria implementar SIP. (mas até lá temos um longo caminho).

Agora enquanto eu não conseguir piscar um LED, nem posso sonhar em aplicar ethernet neste cara.

Entenderam?

[Rodrigo_P_A]

RIcardo, pq vc num dá uma olhada no FreeRtos?

Acho que ele é bem fácil de entender, além disso tem ports para vários tipos de microcontroladores, dá até para usar com os Freescale.

[Ricardo_Franco]

Ola Senhores.
Caro Rodrigo, achei muito interessante sua sugestão.
Para os demais segue o link com os dispositivos suportados pelo FreeRTOS:
http://www.freertos.org/a00090.html

[marcelo_asm]

Ricardo, voce tem participado dos fóruns da Freescale ? Vai conseguir muito boas informações, diretamente de funcionários que desenvolveram os produtos e/ou soluções de software.

[msamsoniuk]

eu olhei por cima e achei equivalente em nivel de complexidade... tem alguma vantagem um ou outro?

Ola Senhores.
Caro Rodrigo, achei muito interessante sua sugestão.
Para os demais segue o link com os dispositivos suportados pelo FreeRTOS:
http://www.freertos.org/a00090.html

[Ricardo_Franco]

Ola Senhores.

Ricardo, voce tem participado dos fóruns da Freescale ? Vai conseguir muito boas informações, diretamente de funcionários que desenvolveram os produtos e/ou soluções de software.

Caro Marcelo, na verdade não, na verdade não havia pensado nessa alternativa, ja me increvi e ja estou sapeando por lá. obrigado.

eu olhei por cima e achei equivalente em nivel de complexidade... tem alguma vantagem um ou outro?

Bem colocado Marcelo, alguém com mais experiencia poderia nos dizer vantagens de um sobre o outro?

Código: Selecionar todos

// -- Função Inicializa IO
boolean InitializeIO(void)
{
  const uint_32 output_set[] =
  {
  LED_1 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  LED_2 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  LED_3 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  LED_4 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  GPIO_LIST_END
  };
/* Open and set port TC as output to drive LEDs */
output_port = fopen("gpio:write", (char_ptr) &output_set);

  if (output_port)
  {
  ResetOutputs();
  }

return (output_port!=NULL);
}

Senhores estou analisando a função acima usada para controlar os GPIO.
Algumas dúvidas:

Código: Selecionar todos

const uint_32 output_set[] =
  {
  LED_1 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  LED_2 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  LED_3 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  LED_4 | GPIO_PIN_STATUS_0,// Pino Inicializa em "0" após reset
  GPIO_LIST_END
  };

Pelo que pude entender ele cria um vetor de constante de 32 bits para controlar 4 UNICOS bits? é isso ?

Na primeira linha temos o código "output_set", para definir estes mesmos IO's como entrada eu uso "input_set" ?

É possivel definir isso dinamicamente? Assim eu poderia multiplexar as IO's.

Qual seria o procedimento para escrever uma rotina de Input?

[msamsoniuk]

tem o exemplo completo no final do AN3905. ele na verdade cria tipo um file descriptor ali com fopen e entao a manipulacao eh feita via ioctl, como seria em um unix qualquer:

ioctl(output_port, (state) ?
GPIO_IOCTL_WRITE_LOG1 : GPIO_IOCTL_WRITE_LOG0,
(pointer) &led1);

conforme o valor de state, ele manda 1 ou 0 para o pino. provavelmente, para ler deve ter um ioctl com parametros tipo GPIO_IOCTL_READ ou qq coisa assim (estou chutando, vc tem q ler a documentacao hehehe).

note que cada inteiro de 32 bits possui varios parametros:

#define LED_1 (GPIO_PORT_TC | GPIO_PIN0)
#define LED_2 (GPIO_PORT_TC | GPIO_PIN1)
#define LED_3 (GPIO_PORT_TC | GPIO_PIN2)
#define LED_4 (GPIO_PORT_TC | GPIO_PIN3)

e que vc tem um array de 4 inteiros, onde cada inteiro manipula os parametros associado a uma GPIO (nao a um bit, mas uma GPIO inteira):

const uint_32 output_set[] =
{
LED_1 | GPIO_PIN_STATUS_0,
LED_2 | GPIO_PIN_STATUS_0,
LED_3 | GPIO_PIN_STATUS_0,
LED_4 | GPIO_PIN_STATUS_0,
GPIO_LIST_END
};

isso pq para cada GPIO vc tem q definir uma serie de coisas: em que porta ela esta, em que bit na porta ela esta e em que estado ela deve estar. tendo isso, vc abre com fopen e ganha um descritor para usar ioctl:

output_port = fopen("gpio:write", (char_ptr) &output_set);

para vc ter como input, eu chutaria:

input_port = fopen("gpio:read",(char_ptr)&input_set);

sendo que input_set teria todos os parametros de output_set, exceto GPIO_PIN_STATUS_0, pq acho q nao deve ter nexo inicializar em zero a porta se ela eh input.

ou seja, parece tudo muito bacana e estruturado, mas deve ser um peh no saco de usar!

[Rodrigo_P_A]

eu olhei por cima e achei equivalente em nivel de complexidade... tem alguma vantagem um ou outro?

Ola Senhores.
Caro Rodrigo, achei muito interessante sua sugestão.
Para os demais segue o link com os dispositivos suportados pelo FreeRTOS:
http://www.freertos.org/a00090.html

A PRIMEIRA e MUITO IMPORTANTE é:

Não é feito somente para freescale!

[msamsoniuk]

e isso eh vantagem?

eu diria que as vantagens do freertos eh poder usar gcc em um ambiente de macho (unix), ao inves de ter que usar codewarrior naquele ambiente de mocinhas (windows)... porem tem um problema serio nessa abordagem opensource!

as ferramentas opensource sao muito genericas e normalmente nao possuem device drivers para hardwares altamente especializados, como os que vc encontra apenas nos processadores da freescale. daih ou vc nivela todos os processadores diferentes por software e fica uma completa m**** ou vc escreve seus proprios device drivers.

em uma ocasiao eu tentei a segunda abordagem no powerpc: parti do device driver da scc com protocolo ethernet e alterei com facilidade para operar com protocolo hdlc (encapsulando ip). de hdlc para pcm foi um pulinho e com alguns refinamentos mais complexos eu consegui fazer as sccs gerarem trafego rtp diretamente, fornecendo assim suporte a 4 canais rtp ou hdlc praticamente com custo zero em termos de processamento, pq o hardware fazia praticamente todo o trabalho pesado.

o proximo passo seria pegar um destes device drivers e, com um esforco cavalar, colocar uma scc para operar em modo qmc, multiplicando a capacidade dela por 32x e suportando uma capacidade limite de 64 canais... infelizmente, o nivel de complexidade das sccs em modo qmc foram bem alem da minha capacidade e eu consegui arranhar 8 canais rtp, ainda assim picotando audio e perdendo interrupcoes!

bom, funcionar eu sei que funciona, pq a cisco possui uma implementacao similar q suporta qmc! mas daih diante disso, repito a pergunta de outra forma: o mqx com o codewarrior por acaso nao disponibiliza device drivers prontos para este tipo de hardware especializado?

eh aquele negocio neh... se eu for perder para os caras da cisco, daih eu vou empatar com quem? hehehe se o mqx suportar isso ae, eu ateh arrisco instalar um windows e codewarrior!

eu olhei por cima e achei equivalente em nivel de complexidade... tem alguma vantagem um ou outro?

Ola Senhores.
Caro Rodrigo, achei muito interessante sua sugestão.
Para os demais segue o link com os dispositivos suportados pelo FreeRTOS:
http://www.freertos.org/a00090.html

A PRIMEIRA e MUITO IMPORTANTE é:

Não é feito somente para freescale!

[Ricardo_Franco]

Ola Senhores.
Estou caminhando com o aprendizado, usando os exemplos da pasta MQX (sugestão do Douglas de outro forum). No exemplo GPIO tem algumas rotinas interessantes e fiz algumas modificações para funcionar com minha rotina.

Código: Selecionar todos

// -- Função para Ler no Port
int ReadInput(unsigned char Pino)
{
int DummyA = 0;
// -- Vetores para leitura de IO
static const uint_32 swt2[] = {
                              SWT_2,
                              GPIO_LIST_END
                              };
                             
                               
  switch(Pino)
  {
    case 1: ioctl(input_port, GPIO_IOCTL_READ, (char_ptr) &swt2);
              if (swt2[0] & GPIO_PIN_STATUS)
              {
              DummyA = 1;
              }
            break;
  }
 
return DummyA;
}

Mas a rotina não funciona me retornando sempre "0". Alguém arrisca algum pitaco?

Att.

Ricardo Franco

[msamsoniuk]

que atributos vc passou para esse input_port no open?

Ola Senhores.
Estou caminhando com o aprendizado, usando os exemplos da pasta MQX (sugestão do Douglas de outro forum). No exemplo GPIO tem algumas rotinas interessantes e fiz algumas modificações para funcionar com minha rotina.

Código: Selecionar todos

// -- Função para Ler no Port
int ReadInput(unsigned char Pino)
{
int DummyA = 0;
// -- Vetores para leitura de IO
static const uint_32 swt2[] = {
                              SWT_2,
                              GPIO_LIST_END
                              };
                             
                               
  switch(Pino)
  {
    case 1: ioctl(input_port, GPIO_IOCTL_READ, (char_ptr) &swt2);
              if (swt2[0] & GPIO_PIN_STATUS)
              {
              DummyA = 1;
              }
            break;
  }
 
return DummyA;
}

Mas a rotina não funciona me retornando sempre "0". Alguém arrisca algum pitaco?

Att.

Ricardo Franco

[Ricardo_Franco]

Ola Senhores.
Opa ... ficaram faltando alguns detalhes:

MAIN.H

Código: Selecionar todos

#define INIT_TASK   5
#define LEDS_TASK   6
#define CHAVES_TASK 7

MAIN.C

Código: Selecionar todos

TASK_TEMPLATE_STRUCT MQX_template_list[] =
{
/*  Task number, Entry point, Stack, Pri, String,   Auto? */
   {INIT_TASK,   Init_task,   1500,  9,   "init",   MQX_AUTO_START_TASK,  0,  0},
   {LEDS_TASK,   Leds_task,   1500,  10,  "leds",   0,                    0,  0},
   {CHAVES_TASK, Chaves_task, 1500,  10,  "chaves", 0,                    0,  0},
   {0,           0,           0,     0,   0,        0,                         }
};

DRV_IO.C

Código: Selecionar todos

// -- Variaveis Globais
static FILE_PTR output_port = NULL;
static FILE_PTR input_port  = NULL;

// -- Função para inicializar IO
boolean InicializaIO(void)
{
  const uint_32 output_set[] =
  {
  LED_1 | GPIO_PIN_STATUS_0,
  LED_2 | GPIO_PIN_STATUS_0,
  LED_3,
  GPIO_LIST_END
  };
 
  const uint_32 input_read[] =
  {
  SWT_2,
  GPIO_LIST_END
  };
   
 
output_port = fopen("gpio:write", (char_ptr) &output_set);
input_port = fopen("gpio:read", (char_ptr) &input_read);
}



// -- Função para Ler no Port
int ReadInput(unsigned char Pino)
{
int DummyA = 0;
// -- Vetores para leitura de IO
static const uint_32 swt2[] = {
                              SWT_2,
                              GPIO_LIST_END
                              };
                             
                               
  switch(Pino)
  {
    case 1: ioctl(input_port, GPIO_IOCTL_READ, (char_ptr) &swt2);
              if (swt2[0] & GPIO_PIN_STATUS)
              {
              DummyA = 1;
              }
            break;
  }
 
return DummyA;
}

DRV_IO.H

Código: Selecionar todos

// -- Definições de uso Geral
#define LED_1 (GPIO_PORT_TE | GPIO_PIN3)
#define LED_2 (GPIO_PORT_TG | GPIO_PIN5)
#define LED_3 (GPIO_PORT_TE | GPIO_PIN5)
#define SWT_2 (GPIO_PORT_TG | GPIO_PIN6)


// -- Protótipos de uso Geral
extern boolean InicializaIO(void);
extern void SetOutput(unsigned char Pino, boolean Estado);
extern int ReadInput(unsigned char Pino);

A rotina de Escrita no LED (que não aparece acima), funciona perfeitamente (foi totalmente baseada no NA da Freescale).
Alguém tem alguma sugestão?

[msamsoniuk]

sim, acho que uma ideia eh verificar o estado de cada funcao passo a passo para ver se nao esta empacando antes por outro motivo. suponho que o RTOS eh muito similar ao unix, ou seja, retorna um estado da operacao e vc pode assim seguir passo a passo para ver onde esta a falha.

por exemplo, no codigo unix normal, eu faria:

Código: Selecionar todos

if((fd = open(porta,atributo))!=-1)
{
  if(ioctl(fd,operacao)!=-1)
  {
    processa dados...
  }
  else
  {
    perror("ioctl: ");
  }
  close(fd);
}
else
{
  perror("open: ");
}


ou seja, nesse caso eu sei que uma operacao resulta em erro se ela retorna -1. testando isso, eu imprimo a falha indicando a operacao e o erro. no caso do unix, o erro eh armazenado em uma varivel global chamada errno, por exemplo, uma falha abrindo o arquivo q na verdade eh um diretorio retornaria um valor ERISDIR. no caso, existe a facilidade de uma macro chamada perror() que imprime uma string e concatena o texto do erro em errno.

teria que verificar o que as funcoes no RTOS retornam e, se retornam -1, por exemplo, se tem como pegar algo similar a errno para pelo menos saber o numero do erro e ter um diagnostico mais preciso.

[Ricardo_Franco]

Ola Senhores.
Caro Marcelo, consegui resolver o problema (com as devidas ajudas), mas ficaram algumas duvidas. vejo que as mesmas são inerentes ao conceito de RTOS.

Bom a solução foi:

Tornar global o Buffer Input,

Código: Selecionar todos

static uint_32 input_read[] =
{
SWT_2,
GPIO_LIST_END
};

Depois deletar o buffer criado dentro da Rotina e fazer a rotina de Input ler diretamente do Buffer Global

Código: Selecionar todos

ioctl(input_port, GPIO_IOCTL_READ, (char_ptr) & input_read);
if (input_read[0] & GPIO_PIN_STATUS)

E as duvidas:
A opção anterior (minha primeira tentativa) deveria ter funcionado, o que tinha de errado com ela?

O que são esses printf ? pelo que sei é para usar um output padrão do sistema, mas qual é esse output? a serial? Se sim, onde eu configuro os parametros da mesma?

Att.