ASM51

desculpem criar esse topico...mas ...nem sei por onde eu começo... sei programar coisas básicas como ler um valor em um port ou gravar o valor em um port, usar a interface serial, habilitar interrupções e etc. nem sei se meu compilador tem todas as headers pra usar a diretiva Xbyte... eu até elaborei um diagrama com um hardware pra rodar o meu programa. vou só passar o desenho dele pro pc e vou postar o link pra voces poderem visualizar.

se não vão poder me ajudar...podem me indicar algum livro que explique detalhadamente o uso de I/O mapeado em C?(basicamente um livro q ensine a usar um 8051 também com ram e rom externa.)

eu tenho grandes ideias aqui e quero compartilhar com vocês aí...

byte Dado @ 0x0200;

Depende da sua IDE.

Renan,


Não existe nenhum mistério no mapeamento de I/O em C.
Na verdade, o mapeamento não passa de um apelido que se dá á determinado pino da I/O.

Ou seja, se para você escrever um bit nesse pino precisaria acessar um SFR ( registraodr interno da CPU ) de valor 0xnn, o apelido dessa I/O torna o programa mais inteligível. Resumindo, o mapeamento se resume á criar declarações no programa ( com a diretiva #define ) que permite você chamar o pino pelo apelido, ao invéz do registrador.


+++

andre_teprom escreveu:Renan,


Não existe nenhum mistério no mapeamento de I/O em C.
Na verdade, o mapeamento não passa de um apelido que se dá á determinado pino da I/O.

Ou seja, se para você escrever um bit nesse pino precisaria acessar um SFR ( registraodr interno da CPU ) de valor 0xnn, o apelido dessa I/O torna o programa mais inteligível. Resumindo, o mapeamento se resume á criar declarações no programa ( com a diretiva #define ) que permite você chamar o pino pelo apelido, ao invéz do registrador.


+++

hum... poderia me dar um exemplo mais prático?

#define PORT_A 0x20

mastk escreveu:#define PORT_A 0x20

ou seja: basta definir o endereço como defino um pino dando um nome a ele...

mas e pra ler ou gravar num periférico?

renan

Talvez o único inconveniente de usar #define para mapear I/O seja o fato de os depuradores não conseguirem enxergá-las pelo nome. O #define é, na prática, uma substituição textual durante o processo de pré-compilação. Portanto, quando for depurar, você deverá usar o endereço da variável e não o nome dela.

Para contornar isso você pode declarar o I/O da seguinte forma (considere que o datasheet de um uC qualquer informe que o PORTA é mapeado no endereço 0x0010):

Código: Selecionar todos

volatile char PORTA = 0x0010

Assim, quando precisar depurar o PORTA, basta colocar a variável e não o seu endereço no watch. Neste caso os 8 bits do PORTA foram mapeados no endereço 0x0010 conforme o datasheet do componente.

Espero ter ajudado

Renan,


Os compiladores já possuem em suas bibliotecas, os arquivos ( .H ) onde esse mapeamento já é feito.
Se você não estiver usando um uC "lançamento" recém saído do forno, já terá esses arquivos á sua disposição, bastando os incluir.

+++

olá. perdão mas sobre mapear io já tá até desenhado e exemplificado nos outros tópicos seus atingindo assim meu (meu) limite teórico de explicações. Mas por coincidência também estive a labutar sobre alguma expansão de io. Favor considerar o descrito abaixo...
ao pesquisar sobre i2c e spi caí num tópico daqui mesmo. note que é uma alternativa curiosa para expansão de i/o e que usa pouquissimos pinos do MC. como o spi é facílimo de implementar em sw - pro cê ter uma idéia, até o xuts conseguiu e pasme! até eu! - creio que não deva ser totalmente descartado. Em hw (caso tenha o mc) então é + fácil ainda. Teoricamente não ha limites de quantos pinos pode expandir usando apenas 5 do MC. Permiti-me trasladar parte das tradicionais sábias letras e o link do amigo m. samgsung...clique no link.

Marcelo Samsoniuk escreveu:b) o protocolo i2c eh infinitamente mais complexo que o spi, portanto seria mais facil deixar o hardware para a i2c e fazer a spi por software, que vai ser eficiente pq spi eh completamente sincrono em relacao ao master.
tem um terceiro ponto de vista q eh o meu: i2c nao vale a pena! ...
http://www.mikrocontroller.net/attachme ... 4HC595.pdf

Se insistir no mapeamento, sugiro que releia seus próprios tópicos. Acho que andei editando uns posts meus.
Que suas grandes ideias sejam enormes.

lellis escreveu:olá. perdão mas sobre mapear io já tá até desenhado e exemplificado nos outros tópicos seus atingindo assim meu (meu) limite teórico de explicações. Mas por coincidência também estive a labutar sobre alguma expansão de io. Favor considerar o descrito abaixo...
ao pesquisar sobre i2c e spi caí num tópico daqui mesmo. note que é uma alternativa curiosa para expansão de i/o e que usa pouquissimos pinos do MC. como o spi é facílimo de implementar em sw - pro cê ter uma idéia, até o xuts conseguiu e pasme! até eu! - creio que não deva ser totalmente descartado. Em hw (caso tenha o mc) então é + fácil ainda. Teoricamente não ha limites de quantos pinos pode expandir usando apenas 5 do MC. Permiti-me trasladar parte das tradicionais sábias letras e o link do amigo m. samgsung...clique no link.

Marcelo Samsoniuk escreveu:b) o protocolo i2c eh infinitamente mais complexo que o spi, portanto seria mais facil deixar o hardware para a i2c e fazer a spi por software, que vai ser eficiente pq spi eh completamente sincrono em relacao ao master.
tem um terceiro ponto de vista q eh o meu: i2c nao vale a pena! ...
http://www.mikrocontroller.net/attachme ... 4HC595.pdf

Se insistir no mapeamento, sugiro que releia seus próprios tópicos. Acho que andei editando uns posts meus.
Que suas grandes ideias sejam enormes.

eu ainda insistirei no mapeamento direto. não quero usar comunicações mais novas como I2C ou SPI pq primeiro, 85% da minha frota de compativeis com 8051foram fabricados entre 1983 a 1989...epoca q nem sonhava em produzir 8051 com SPI ou I2C.

segundo: sei projetar hardware "a moda antiga" mas apenas pra funções basicas.
e terceiro e o mais importante...só quero apenas um codigo fonte de exemplo que faça ativar o pino WR em um determinado momento pra gravar num endereço estipulado
e q esse msm programa também ative o RD em um dado momento também. só preciso aprender os comandos.

entao...
basta ver no seu compilador, passa o nome dele aí, como se acessa a ram externa,

Aquino escreveu:entao...
basta ver no seu compilador, passa o nome dele aí, como se acessa a ram externa,

Uso o SDCC e o JFE editor.

faço toda a compilação dentro do jfe inclusive

dá pra programar um 8032 com ele mas so pósso usar as portas P1 e P3.
mas quero usar I/O mapeada pra n ficar preso apenas a porta P1 e P3, e se eu precisar de usar interrupções, timers e a interface serial? P3 é o barramento de controle.

Faça o que fizer, sua atitude é negativa ou neutra. Orientações lhe foram demasiadas. Despeço-me de você agora. Ajude-se a te ajudarem. Seja mais grato. Enfim, de minha parte só lhe resta a mensagem subliminar

renan-papaco escreveu:...dá pra programar um 8032 com ele mas so pósso usar as portas P1 e P3.
mas quero usar I/O mapeada pra n ficar preso apenas a porta P1 e P3, e se eu precisar de usar interrupções, timers e a interface serial? P3 é o barramento de controle.

Se for usar RAM/ROM externa, não há outra opção, pois as operações de busca pelas memórias de dados e instrução ( fetch ) são realizada intrinsicamente pela CPU, e realmente as portas do barramento DATA/ADDRESS ficam dedicadas é essa finalidade.


+++

lellis escreveu:Faça o que fizer, sua atitude é negativa ou neutra. Orientações lhe foram demasiadas. Despeço-me de você agora. Ajude-se a te ajudarem. Seja mais grato. Enfim, de minha parte só lhe resta a mensagem subliminar

olha eu li e reli os meus topicos mas n encontrei nada esclarecedor. vc não é obrigado a ajudar, mas ainda sim lhe agradeço.