ASM51

Olá Colegas,

Estou pensando em desenvolver um controlador de Eventos com baseado em tempo real (relógio).

As opções de configuração seriam dia da semana (selecionável), o horário (que poderia ser fixo ex.: de quinze em quinze minutos, ou em horário quebrado), tempo de acionamento (configurável).

O sistema precisa ter a capacidade de armazenar determinada quantidade destes programas completos.

Questões:

1) Multiplicando as opções que poderiam ser selecionadas estou obtendo uma quantidade grande de dados para serem armazenados;
2) Qual melhor modo para gerenciar a execução?

Obrigado!

Eu pensaria em manipular memória dinamicamente, alocando e liberando, caso o tamanho do conteúdo armazenado fosse variável. De um modo geral a tabela é a solução padrão; ou seja, uma variavel array multidimensional como indexador para ponteiros, que seriam as colunas dessa tabela. Mas como voce não especificou se é bare metal ou SO, não dá pra saber se pode contar com um DB.

Eu faria algo do tipo:

Código: Selecionar todos

typedef enum{
EVENTO_UNICO,
EVENTO_DIARIO,
EVENTO_SEMANAL,
EVENTO_MENSAL,
EVENTO_WHATEVER
}eEVENT_TYPES;

typedef struct{
  eEVENT_TYPES tipo;
  unsigned char hora,minuto,segundo,dia,mes;
  unsigned short int ano;
  unsigned char args[10];
};


Assim esse bloco da struct seriam as tuas programacoes, logo se forem muitas eu jogaria numa dataflash ou eeprom externa.
Para o processamento eu faria um loop a cada TICK do teu controlador, varrendo a lista de "programacoes" e vendo se o trigger dela foi satisfeito, assim tomando a acao necessaria.
Alias, ja fiz algo assim.
Mas eu configurava os eventos por um software no PC.

Coisas que esqueci de mencionar:
Na camada de software que busca/salva os dados na memoria externa eh interessante colocar uma verificacao de integridade, um checksum simples ja resolve.
A quantidade de funcoes que voce conseguira processar esta relacionada com a duracao do TICK e a duracao da execucao de cada "processamento" no loop.

Olá André,

Sim, a principio estou pensando em ciar uma matriz representando todas as opções de horários possíveis composta por 0 e 1 onde onde 1 (desl e lig).

Através da interface de ajuste, selecionando dias da semana, horários, etc iria configurando.

A rotina de execução leria esta tabela de acordo com o tempo e comandaria as saídas de acordo com as opções selecionadas.

Porem nunca fiz nada parecido e não tenho uma visão clara da melhor forma de implementar...

Aquino, bem lembrado, já tive problema com a integridade de dados vindos de eeprom!

No tempo dos blackout's de energia eu fiz um projeto assim, que carregava as programações via PC (software feito no Delphi).

No meu caso, eu buscava da EEPROM os eventos mais recentes e trazia para a RAM, assim não precisava ler a EEPROM a cada tick. Quando estava próximo do fim do que já foi executado na RAM, buscava um novo bloco. O próprio Delphi já organizava os eventos cronologicamente, então o processador não precisava "pensar", só executar sequencialmente.

Uma coisa que facilitava é que não havia programações distantes, como mensais ou anuais... Só semanais, coisa que um programador horário de 50 Reais faz de boa.

Isso foi para um cliente de SP, que conheci no fórum do Vidal e que nunca me pagou. Acho que ele descobriu os programadores de mercado tipo esse...

Eu acho que nao expliquei direito, da forma que coloquei aqui estava tudo praticamente pronto.
Entao vamos lá:

A enumeracao é só um açúcar sintático...

Código: Selecionar todos

typedef enum{
EVENTO_NAO_HABILITADO,
EVENTO_UNICO,
EVENTO_DIARIO,
EVENTO_SEMANAL,
EVENTO_MENSAL,
EVENTO_WHATEVER
}eEVENT_TYPES;


Essa estrutura é para você poder elevar o nivel de abstracao das programacoes

Código: Selecionar todos

typedef struct{
  eEVENT_TYPES tipo;
  unsigned char hora,minuto,segundo,dia,mes;
  unsigned short int ano;
  unsigned char args[10];
}sPROG;


Entao o loop de processamento seria algo assim:

Código: Selecionar todos

void tick_progs(void){
  sPROG progr;

  for(unsigned char i=0;i<NUM_PROGS;i++){
    BUSCA_EVENTO(i,&progr);
    if(checa_crc(prog))
      decode(prog);
  } 
}


void decode(sPROG  *prog){

  switch(prog->tipo){
    case EVENTO_UNICO:
     // aqui voce faz as verificacoes de data e hora, ser é pra ligar/desligar/ ou qualquer outra coisa
          break;
    case EVENTO_DIARIO:
        break;
  }
}



A ideia do vetor entro do struct, é guardar os argumentos para os comandos.
Por exemplo, vai que alem de ligar e desligar em uma determina data e hora, tu quer inventar algum comando que envia uma mensagem, ou disca para um numero ou acessa um IP. Esses 10 bytes sao para esses parametros, que mudam conforme o tipo do comando. Se fosse escrito em C++ ao inves de C, o sPROG poderia ser uma classe abstrata ao inves de uma struct e as programacoes deveria extender essa classe ja especializando os parametros de acordo com a necessidade.
Mas é outro papo.

Obrigado pela sugestão da leitura por bloco da eeprom Kraft!

Obrigado pelas ideias Aquino!

Como a frequência de parte dos eventos possui uma certa regularidade, para economizar memória, pensei em criar dois sistemas para execução dos eventos: um fixo, onde não é necessário armazenar o tempo, e outro que o usuário pode ajustar o tempo. Armazenados em áreas diferentes.

A rotina de armazenamento se encarrega de ordenar o tempo de execução dos eventos com tempo ajustável.

A rotina de execução lê os dois grupos de eventos e executa na ordem.

Abraços!!!

Você quer construir um data logger que registra eventos períodicamente ou quando ocorrem tipo o ring buffer do kernel do Linux, ou você quer construir um sistema tipo o cron/crontab do Unix, que executa determinadas tarefas em horários pré definidos ? Ou uma mistura de ambos?

Pamv, o sistema é microcontrolado e com recursos bem limitados, é preciso ser criativo no código...

brasilma escreveu:Pamv, o sistema é microcontrolado e com recursos bem limitados, é preciso ser criativo no código...

Sim, eu sei, usei como exemplos, mas qual dos dois sistemas você deseja criar? Logger ou crontab?
Os fundamentos para um e outro são os mesmos independente de onde se vá implementar. Um registra eventos o ou outro controla eventos

Controle de eventos!

A maior dificuldade a principio era que os eventos apresentavam uma variabilidade grande, após cozinhar os neurônios consegui organizar de um modo que permitiu reduzir a dimensão da matriz de armazenamento!

Então o seu projeto é um data logger? O ring buffer do kernel é uma boa idéia, você salva a data do sistema entrando no ar e depois só deltas de tempo em relação a ela, se o buffer estourar sem você te-lo salvo, ele sobrescreve o evento mais antigo, pra evitar flood usa-se o "evento xx observado n vezes nos últimos t segundos"