ASM51

Pode até parecer que o tópico esta no lugar errado, mas é que eu preciso primeiro explicar a situação para que vocês possam me ajudar a resolver o problema.

Olha só onde eu fui me meter...
Um amigo meu tem um antigo sistema de incêndio que gera relatórios constantes via RS232 para uma impressora matricial, ou seja, a cada evento que acontece ela imprime uma ou duas linhas descrevendo a situação. Ele queria saber se era possível eliminar essa impressora e salvar estes eventos em um cartão de memória.

Inocentemente lembrei do famoso módulo Dosonchip que é vendido pela sparkfun.com que tendo tantas facilidades descritas no site, pensei que seria "moleza" fazer uma interface usando um 16F877 e um display 2x16.

Ele sabe que atualmente estou mexendo com microcontroladores PIC só por hobbi e se ofereceu para comprar o hardware necessário, dai eu indiquei o módulo e ele fez o pedido.

Confiando no meu taco, fiz as rotinas do display e só fui correr atrás da documentação depois que a criança chegou, dai veio a surpresa... No site do fabricante só tem três documentos a respeito do módulo e os que descrevem o funcionamento estão incompletos e muito mau feitos.

No site o fabricante diz que é possível atualizar o firmware para comunicar em I2c mas a única atualização existente é de Junho de 2006 e não foi para isso, dai escolhi o SPI pois vou precisar da 232 do PIC. E pra me deixar mais encucado ainda, meu módulo usa um chip diferente do que o fabricante descreve, o fabricante usa um tal de CD17B10 que me parece ser um chip dedicado, mas no meu módulo veio um controlador C8051F310...aff...

Procurei mais informações na net e só encontrei reclamações, pelo que entendi, a interface SPI desse módulo não funciona exatamente como as memórias que usam essa mesma interface. É preciso enviar comandos mas a questão é que não sei se o dado é transmitido na subida ou descida do clock, se os dados são enviados primeiro o LSB ou se é o contrário, quanto tempo preciso esperar para escrever outro byte... e ai vai. O fabricante não responde a e-mails e o fórum de dúvida deles esta repleto de Spaw.

Bom, como deu pra perceber, estou no mato sem cachorro e mais da metade dos cabelos ja foi embora...rs... Um belo tiro no próprio pé.

Esse é o fabricante...
http://www.dosonchip.com/modules.htm
Esse é o bendito...
http://www.sparkfun.com/commerce/produc ... ts_id=7955
Informações mais coerentes...
Parte1 http://www.techranch.com/blog/comments. ... 104-003740
Parte2 http://www.techranch.com/blog/comments. ... 106-003328
Parte3 http://www.opencircuits.com/Dosonchip

Estou pensando em adaptar este código para C do CCS mas nem sei que compilador é esse para fazer a tradução...
http://www.techranch.com/Files/SPI_Test.c

C8051F310 http://www.datasheetarchive.com/C8051F3 ... sheet.html

Olá RegisCruz.

Eu faria um pouco diferente. Se vc entrar no site da microchip e dar uma pesquisada, já existe uma biblioteca pronta para usar esses MMC Card, e o hardware é super simples, o problema é ter que utilizar o compilador C18 (que eu eu acho meio complicado), mas pelo fato que você vai ter que fazer algo relativamente simples, então vc teria que mudar uma ou duas linhas do código fornecido pela microchip.

abração

Já desenvolvi centrais de alarmes de incêndio . Não entendi porque gravar os eventos de alarmes em cartão de memória de 512 mega bytes.

Nao é um exagero usar tanta memória assim?

Afinal vc só precisará gravar eventos de alarmes, e alarmes de incêndio nao ocorrem toda hora, todos os dias.

Também ja fiz uma aplicaçao para gravaçao em SD CARD.

http://www.proex.eng.br/gravador.htm

Se fosse vc usaria uma memoria serial comum, dessas com barramento i2c.

Obrigado Proex, Bardelli e os que estão acompanhando.

Eu cheguei a pensar nisso antes de ver os relatórios, é que a central envia frases completas e nào sei onde ela arranja tanto evento para imprimir...rs... A finalidade do negócio é facilitar o trabalho porque me parece que todo mês eles tem que pegar aquelas cinco ou oito folhas impressas e arquivar ou se for um caso de enviar via e-mail eles tem que scanear e é um trabalho desnecessário que pode ser resolvido facilmente com esse cartão de memória, entendeu?
Dei uma lida em alguns tópicos aqui do forum sobre gravar em cartões de memória mas achei que estava muito além da minha capacidade...rs... Dai pensei em facilitar a minha vida, acabei foi arrumando pra cabeça. E o pior é que o cara ja comprou o negócio né, fica mais feio ainda.

Para não dizer que foi tudo um desastre total, eu consegui fazer ele dar um sinal de vida, configurei o mesmo para comunicar via SPI conforme manda o manual (fechar o jumper SJ2) e fiz uma rotina simples em C para receber os comandos via porta serial e envia-los pela SPI para o módulo e vice verse, só que se envio o comando >ow LOG.TXT<cr> ou simplesmente > ele responde com um monte de lixo como se não tivesse entendido ou como se a resposta dele estivesse corrompida, sei lá.

Código: Selecionar todos


#include "C:\Users\Reginaldo\Técnico\IUPUI\Versão C\Prog\Proj_IUPUI.h"
#USE RS232 (BAUD=19200, XMIT=PIN_C6, RCV=PIN_C7)

 //boolean led;
   char y, k;

void   main ()
 {

   setup_adc_ports(NO_ANALOGS);
   setup_adc(ADC_OFF);
   setup_psp(PSP_DISABLED);
   SETUP_SPI (SPI_MASTER | SPI_H_TO_L | SPI_CLK_DIV_64);
   setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
   setup_timer_1(T1_DISABLED);
   setup_timer_2(T2_DISABLED,0,1);
   #define DCHIP_hab   pin_b2
   #define DCHIP_reset   pin_c1
   #define DCHIP_busy   pin_c0

   output_low (DCHIP_hab);
   output_low (DCHIP_reset);
   printf("RS232 ok\r\n");
   delay_ms (20);
   output_high (DCHIP_reset);

    while (true)
   {
      //Recebe SPI e manda para RS232
          y=spi_read(0);
          printf(y);

      //Recebe da RS232 e manda para SPI
          k=getc();
          spi_write(k);

      }
   }

 

Resultado:


O protótipo:


Bom, estou tentando entender como funcionam as rotinas deste exemplo http://www.techranch.com/Files/SPI_Test.c mas não esta fazendo muito sentido o que entendi.

Me parece que na rotina chamada sendHEXNumber é onde ele faz a rotação dos bits para serem enviados mas o cara esta rotacionando só quatro bits...

Obrigado a todos.

Por favor, não me entendam mau mas eu gostaria de dizer que eu não quero nenhum programa pronto, quero apenas que me ajudem a entender como funciona esse módulo para que eu possa fazer isso funcionar.

bom natal, Regis, olha pelo que parece trocaram o chip dedicado por um microcontrolador, mas acredito que devem ter emulado o chip, então inicialmente o melhor é seguir o procedimento do chip anterior, no manual user guide, esta relacionado o modo de trabalho da spi:

" The SPI interface clocks data in on the rising edge and out at the falling edge of the clock pulse (see CD17B10 datasheet for timing parameters). "

dados de entrada na borda positiva e os de saida na borda negativa, o que naum esta explicado é o clock se é zero->um ou um -> zero, acredito que vc deva testar os dois casos. para ver se consegue se comunicar.

uma ajuda sobre os comandos:

retirado do forum do fabricante
"
Sending only a carriage return mounts the card, however, any valid file command will include mounting the card as well.

Here is an example of a list of commands for opening a file called TEST.TXT and writing "Hello World!" to it. This can be easily seen using Hyperterminal over the UART RS232 interface:

>ow #1 TEST.TXT
1
>w #1 12
"Hello World!"
>q #1

The first line opens the TEST.TXT file (if file is found, it would be appended at the end, if the file is not found, it will be created) and assigns handle #1 to represent the open file.

The second line is the host sending the confirming file handle number.

The third line prepares to write 12 bytes to the file represented by handle #1.

On the fourth line, a quote is sent to the host to signal data can now be written. Then the host sends the 'Hello World!' string. When the last byte is received, a quote is sent to the host.

The fifth line is a command to close the file represented by handle #1.

The "or" command is similar to the "ow" command.

The prompt consists of 3 bytes: line feed, carriage return, and ">".

Echo is on by default for the UART. For SPI, the next byte sent by the host returns the previous byte sent by the host.

As for sleep, the chip automatically goes to sleep when it completes an operation and there is no communication to the host--even if a file is left open.

We recommend becoming familiar with the commands using the UART with Hyperterminal. The only difference with the SPI port is the byte level communication with handshake since it is a slave port.

Please let us know if you need any further assistance.

Best Regards,
Matt
DOSonCHIP Team
"
Boas festa e bom ano novo



G. A.

Sergio

Pois então Sergio, eu vi isso também mas estou desconfiado de que eu estou fazendo algo errado no meu programa.
O que eu conheço de programação em C foi o que eu aprendi no livro do Fabio (aliás muito bom), estou pensando em modificar uma biblioteca de exemplo sobre comunicação SPI para memórias seriais que existe no livro (pag. 272) para fazer esse negócio funcionar. Mas surgiram as seguintes dúvidas.

Baseado no que eu entendi sobre esse módulo, ele não recebe comandos de habilitação da escrita ou leitura ou proteção de memória e outros.
Acredito que desta biblioteca, eu preciso apenas das rotinas responsáveis por ler byte (que depende da rotina que lê bit) e da rotina responável por escrever byte (que também depende da rotina que escreve bit).

A modificação no meu ponto de vista, seria nas rotinas que preparam os dados para serem lidos e escritos (spi_le_eeprom e spi_escreve_eeprom).
No caso da escrita eu pensei nas duas opções abaixo, mas minha dúvida é, como fazer para enviar um comando inteiro?
Para o comando (>ow #1 TEST.TXT<CR>) que preciso enviar 16 bytes ou caracteres...

Código: Selecionar todos

void spi_escreve ()
// comando para criar um aquivo chamado TEST.TXT no cartão de memória.

char comando = ">ow #1 TEST.TXT";
{
  output_low (spi_cs);   // seleciona dispositivo
  spi_escreve_byte (comando); // envia comando de criação do arquivo
  spi_escreve_byte (0x0D);// Enter ou <CR> em ASCII

  output_high (spi_cs);  // desativa linha CS e inicia a escrita
}



No primeiro esta dando um erro 27 que ainda não descobri o que é, dai pensei nesta outra forma.

Código: Selecionar todos

void spi_escreve ()
// comando para criar um aquivo chamado TEST.TXT no cartão de memória.

{
  output_low (spi_cs);   // seleciona dispositivo

  spi_escreve_byte (">");
  spi_escreve_byte ("o");
  spi_escreve_byte ("w");
  spi_escreve_byte (" ");
  spi_escreve_byte ("#");
  spi_escreve_byte ("1");
  spi_escreve_byte (" ");
  spi_escreve_byte ("T");
  spi_escreve_byte ("E");
  spi_escreve_byte ("S");
  spi_escreve_byte ("T");
  spi_escreve_byte (".");
  spi_escreve_byte ("T");
  spi_escreve_byte ("X");
  spi_escreve_byte ("T");
  spi_escreve_byte (0x0D);

  output_high (spi_cs);  // desativa linha CS e inicia a escrita
}



Na leitura eu simplesmente chamaria a rotina responsável por ler byte, armazenaria os comandos recebidos (ainda não pensei como) e ficaria aguardando o comando <CR> conforme aquele exemplo SPI_Test.c daquele links acima.
Vou fazer os testes esta noite pra ver o que acontece, alguem teria alguma outra sugestão?

Obrigado a todos.

Boa tarde........

Regis, ja testou a unidade pela serial????até agora vc se dedicou ao spi e pela serial?os dados serão muitos grandes, com expressiva frequencia??

Emule a serial, naum precisa no caso dela em hardware? e rotina serial vais encontrar muitas por ai..


Abraços e feliz Ano Novo.

Sergio

E ai pessoal, e Sergio desculpem a demora...

Depois de mais algumas tentativas fracassadas pela SPI resolvi chutar o balde e seguir seu conselho.
Habilitei o módulo para o modo serial e fiz uns testes direto do computador, de início tive alguns problemas mas funcionou, valeu pela dica.
Respondendo as suas perguntas.

Sergio38br escreveu:...os dados serão muitos grandes, com expressiva frequencia??...

Sim, pelo que me lembro eram frases de uma ou duas linhas, em média umas 35 palavras por frase que eram impressas na folha. Era um tipo de descrição do evento composto por um numero de log, data, hora e a frase de descrição.
A frequência vai depender da quantidade de eventos durante o dia. Vou ver se consigo uma cópia para ter certeza. Com relação ao módulo, eu fiz uma série de testes e cheguei a montar um mini tutorial "este que esta ai embaixo" na documentação diz que o módulo tem um buffer que suporta 80 caracteres para escrita, mas fiz um teste com 100 e não deu erro, só que os 80 ja resolvem o meu problema... espero...

Sergio38br escreveu:...Emule a serial, naum precisa no caso dela em hardware?...

Vou fazer isso, estou pensando em habilitar a serial do hardware do Pic para comunicação com o sistema e emular uma outra para se comunicar com o módulo. Vou fazer em C que é mais fácil.

Segue abaixo um mini tutorial com os comandos básicos que vou precisar, não tem muito segredo mas descobri um bug.

Código: Selecionar todos


*Para detecção de velocidade no modo RS232 não é suficiente enviar o comando Enter (0x0d = 13 decimal) duas vezes como manda o fabricante, é necessário enviar 10 ou 15 bytes seguidos do comando Enter várias vezes sequêncialmente até o módulo responder com o simbolo (>) ou com (-10>) que indica erro de comando.
*Para usar o modo de comunicação a 3 fios no modo RS232 basta conectar normalmente TX, RX e GND e ligar o pino CTS do módulo no GND e deixar desconetctado o RTS.
*O simbolo (>) indica que o módulo esta pronto e esperando um novo comando.
*Depois de escrever um comando é necessário enviar um Enter = 0x0d = 13 decimal.
*Podem ser abertos no máximo 4 arquivos de 0~3 posições, se o arquivo for aberto para escrita ele ocupa uma posição, o mesmo arquivo pode ser aberto ao mesmo tempo para leitura, mas ocupa outra posição restando apenas duas. Não é possível abrir o mesmo arquivo duas vezes para leitura ou escrita e a orderm é primeiro para escrita e depois para leitura.
*É possível criar o arquivo com qualquer extensão, inclusive .csv desde que seja obedecida a norma.


//***Teste de comandos de escrita***

ow REGIS.TXT
//Comando para criar ou abrir para escrita (ow) um arquivo chamado (REGIS.TXT), se este arquivo existir ele abre, caso contrário ele cria e abre.

0
>w #0 30   
// o módulo envia (0 >) que indica que foi criado ou aberto como arquivo 0 e espera um novo comando (w) é o comado de escrita, (#0) indica que será escrito no arquivo 0, (30) indica que serão escritos 30 bytes, o máximo é 80.

"TESTE DE ESCRITA em um arquivo">
//o módulo envia o simbolo (") dizendo para começar a escrita e quando termina a escrita dos 30 Bytes o módulo envia o simbolo (") novamente seguido de (>) que indica que os 30 bytes foram recebidos e que esta esperando o próximo comando.

>s #0
//o comando (s #0) indica que queremos saber em que posição o ponteiro esta dentro do arquivo, este comando pode ser usado a qualquer momento.

30
>s #0 15
//(30
>) o módulo responde que o ponteiro esta na posição 30 e espera um novo comando, o comando (s #0 15) diz que queremos mover o ponteiro para a posição 15.

15
>w #0 5
//(15 >)o módulo responde que mudou para posição 15 e espera outro comando, foi solicitada uma nova escrita de 5 bytes (w #0 5) a partir do ponteiro 15 setado anteriormente.

"ASM51"
>s #0
//O módulo atende a solicitação e envia o simbolo (") dizendo que aguarda o texto, depois de escritos os 5 bytes solicitados o módulo envia os simbolos (">) dizendo que recebeu e aguarda novo comando. Depois da escrita o ponteiro foi deslocado cinco posições a frente, foi enviado para o módulo o comando (s #0) para confirmar isso.

20
>q #0
O módulo responde com (20>) dizendo que a posição atual do ponteiro é 20 e aguarda novo comando. Para fechar o arquivo foi usado o comando (q #0) que fechou só o arquivo 0, se for usado apenas o comando (q) sem especificar o arquivo ele fecha todos os quatro caso estejam abertos também.


//***Teste de comando de leitura***

or #1 REGIS.TXT
//O comando (or #1 REGIS.TXT) diz para o módulo que queremos abrir para leitura (or) o arquivo (REGIS.TXT) na posição 1 (#1), pode-se indicar qualquer posição liver mas se omitirmos esta parte (#1) ele vai abrir na primeira posição livre que ele encontrar.

1
>r #1
//O módulo confirma dizendo que o arquivo foi aberto na posição 1 e que esta pronto.  O comando (r #1) é um comando de leitura e diz para ler todo o conteudo  do arquivo 1.

30
TESTE DE ESCRITASM51um arquivo
//O módulo responde que o arquivo tem 30 bytes e mostra todos os bytes existentes dentro do arquivo, neste ponto tem uma coisa interessante pois quando foi mudada a posição do ponteiro anteriormente para a escrever outros cinco bytes (ASM51) na posição 15, o módulo simplesmente sobrepôs os bytes (A em ) por (ASM51) ao invés de deslocá-lo para frente ficando (TESTE DE ESCRITASM51um arquivo).

>s #1
//O comando de deslocamento de ponteiro pode ser usado também na leitura, neste caso foi apenas para confirmar a posição do ponteiro após a leitura.

30 >s #1 7
//O módulo mostrou que o ponteiro esta na ultima posição (30>), Se a leitura for realizada a partir deste ponto vai dar erro dois este é o fim do arquivo. O comando (S #1 7) diz que é para o ponteiro ser movido para a posição 7.

7 >r #1 8
//O módulo faz a confirmação e em seguida foi enviado o comando de leitura de arquivo (r #1 8) que diz para fazer a leitura de 8 bytes apartir da posição em que encontra o ponteiro, neste caso, posição 7.

8
E ESCRIT
//O módulo faz a leitura e diz que foram lidos 8 bytes, são eles (E ESCRIT).

>i
//O comando (i) pede informação de todos os arquivos dentro do cartão e também funciona no modo de escrita e com arquivos fechados.

2008-01-05 13:01         30 REGIS.TXT
//O módulo responde com data hora tamanho e nome do arquivo

>q
//O comando (q) fecha todos os arquivos abertos.

>d REGIS.TXT
//O comando (d REGIS.TXT) deleta o arquivos (REGIS.TXT).



Imagem do arquivo criado dentro do cartão:


Conteudo do arquivo:


Obrigado pessoal, em breve eu retorno com o resultado ou com mais dúvidas...rs...

Um abraço a todos.

boa tarde,

Que bom que a sugestão funcionou, o modo de regravação, posicionar ponteiro e novo dado deve funcionar apenas como re-escrita. sem deslocar os dados.

Um bom tutorial sobre as funcionalidades, pena que falta um pouco de respeito quando lançam algo e colocam a documentação capenga, e temos de escovar bits e bytes para descobrir como funciona.


Grande trabalho

G.A.

Sergio

Olá Regis!

Eu não uso C e só dei uma lida rápida nos posts mas, uma coisa
me chamou a atenção, sua rotina spi_escreve não está de acordo
com a informação do manual user guide que o Sérgio passou:


The prompt consists of 3 bytes: line feed, carriage return, and ">".

Creio que deveria ser algo parecido como abaixo:

void spi_escreve ()
// comando para criar um aquivo chamado TEST.TXT no cartão de memória.

{
output_low (spi_cs); // seleciona dispositivo

spi_escreve_byte ($0A);
spi_escreve_byte ($0D);
spi_escreve_byte (">");
spi_escreve_byte ("o");
spi_escreve_byte ("w");

...
...

bom dia, tudo bom

Pergunta que não tem nada a ver com o projeto.... TÁ MUITO FRIO AÍ EM INDIANAPOLIS?????


G.A.

Sergio

Creio que deveria ser algo parecido como abaixo:

Olá Renie, obrigado pela sugestão, mas eu também fiquei confuso nesta parte do manual e só entendi depois que o módulo funcionou.
Na verdade o usuário nunca envia o ">" pois quem envia ele é o módulo, funciona como uma resposta dele e pode ser interpretado como (...estou pronto para receber o próximo comando...) entende?
Ja o carriage return o usuário envia para o módulo sempre depois de escrever um comando e pode ser interpretado como sendo um (...execute esse comando...) realmente eu não me lembrei de falar sobre o carriage return depois de cada comando no tutorial, desculpe.
Eu tive muitos problemas para implementar o modo SPI, fiz alguns testes pelo modo serial e funcionou, acho que vou por esse caminho mesmo ja comecei a escrever o programa, vamos ver no que dá mas mesmo assim obrigado.

Pergunta que não tem nada a ver com o projeto.... TÁ MUITO FRIO AÍ EM INDIANAPOLIS????? Cool Cool Cool Cool

E ai Sergio, o Mineirinho aqui ta sofrendo rapaz, no ultimo sábado dia 05/01 fez -12C, nunca fiquei exposto a uma temperatura dessas na minha vida. Eu não tive coragem de sair la fora mas acho que se eu cuspisse no chão meu cuspi quebrava...rs...

Um abraço

olha , só posso dizer uma coisa, VOCÊ ENTROU EM UMA FRIA.................HEHEHEHEHE

G.A.

Sergio

Pessoal, por favor me desculpem o abandono temporário do post. É que tive uns probleminhas e parei o projeto por alguns meses...

Bom, neste mês de março foi a gota d'água, passei tanta ráiva com este módulo que decidi chutar o balde. Fiz uma bela pesquisa, juntei uma boa documentação a respeito e decidi comprar um módulo FTDI da linha Vinculum.



http://www.vinculum.com/documents/datas ... _VDIP1.pdf
http://www.rogercom.com/index.htm

Fiz vários testes via PC e funcionou tudo redondinho, realmente o produto é muito bom e funciona muito bem ao contrário deste picareta que usei primeiro, aliás não aconselho esse DosOnChip pra ninguém, não tem estabilidade nenhuma, tem bugs no relógio, poucos comandos de edição/criação de arquivos, documentação nota zero e sem falar que muito lento.

Agora estou começando novamente do zero com este novo, acho que esse da para sair alguma coisa via spi.
Continuo contando com a ajuda de vocês, aliás, muito obrigado a todos os que se dispuseram a ajudar.

Um abraço, valew.

Boas, saiu da hibernação Urso, agora passou o inverno, ja da para colocar o nariz de fora da porta.

Abraços
Sergio