Do fluxograma para o Programa

[.if]

8 horas atrás, MOR disse:

o compilador compreenderia essa instrução?

if (PINB.0 | PINB.1)  PORTB.2 = 0;

A princípio sim. Geralmente os pinos físicos são tratados como variável tipo bit ou boolean. A propósito, veja com seu compilador como são nomeados. Geralmente é coerente como o d.s. do mc. P.ex. prum pic 12f

if (GPIO0 || GPIO1) GPIO2=0;

Pro 16f mencionado no começo

if (RB0 || RB1) RB2=0;

[MOR_AL]

16 horas atrás, Sérgio Lembo disse:

Se é para comparar com byte, vamos comparar 2 bytes.

if (PORTB & 0b00000011) PORTB.2 = 0;

Mas Sérgio, no meu caso estou tentando saber o estado do pino de ENTRADA. Não seria PINB ao invés de PORTB?

MOR_AL

[Sérgio Lembo]

A porta me retorna o byte onde cada bit corresponde a 1 pino.

A intenção é ler a porta inteira. (leitura do primeiro operando) e na operação AND que se segue  os bits setados (segundo operando) isolam os bits que me interessam.

[.if]

Permita-me...

8 minutos atrás, MOR disse:

Não seria PINB ao invés de PORTB?

Amigo, tudo se elucidará quando ver

8 horas atrás, Isadora Ferraz disse:

com seu compilador como são nomeados. Geralmente é coerente como o d.s. do mc.

P.ex. pro pic 16f

PORTB|=0b00000001;

é o mesmo que

RB0=1;

[MOR_AL]

10 minutos atrás, Sérgio Lembo disse:

A porta me retorna o byte onde cada bit corresponde a 1 pino.

A intenção é ler a porta inteira. (leitura do primeiro operando) e na operação AND que se segue  os bits setados (segundo operando) isolam os bits que me interessam.

Isso eu entendi.

Minha dúvida é que o pino que desejo ler o estado lógico, está caracterizado como entrada. Estou lendo com o nome PINB, mas você está me mostrando a leitura da porta com o nome PORTB. Não seria PINB?

MOR_AL

adicionado 2 minutos depois

8 minutos atrás, Isadora Ferraz disse:

P.ex. pro pic 16f

PORTB|=0b00000001;

é o mesmo que

RB0=1

No PIC não tenho esse problema. Estou estudando o AVR, que tem essa frescura de PORTx e PINx.

EM Tempo: Ainda não estou usando um compilador. Ainda estou estudando.

Olha essa página de uma apostila que escaneei.

O autor lê a porta D via PIND e escreve nela via PORTD.

MOR_AL

[Sérgio Lembo]

Sintaxe é um saco. Se no uC  que está estudando é usado PINx para leitura e PORTx para escrita adapte-se a isso (foi a impressão que me passou a foto postada). Tenho estudado mais sobre os STM8 e STM32F0 onde não se tem essa diferenciação.

adicionado 8 minutos depois

Apenas para te alertar: em muitos uC tem-se forma especial de se escrever na porta, me refiro ao assembler. Se a porta é um byte de registrador, como setar ou clarear um bit (pino) específico sem afetar os demais? Isso te obriga a ter um conhecimento prévio dos demais e mostrar o byte para não bagunçar. No entanto se tem um comando de setar apenas os bits que te interessam se afetar os demais. Mandando 0b00000101 com comando de set bits 0 e 2 são setados e os demais permanecem inalterados. Da mesma forma um clear 0b00000101 reseta bits 0 e 2 sem alterar os demais.

[.if]

26 minutos atrás, Sérgio Lembo disse:

Se no uC  que está estudando é usado PINx para leitura e PORTx para escrita adapte-se a isso (foi a impressão que me passou a foto postada)

Pior. Mas esta é a limitação do compilador e não necessariamente do uC. Mas felizmente a linguagem lhe dá alternativas curiosas pra manipular bits como:

#define setbit(var,bitno) ((var) |= 1 << (bitno))
#define clrbit(var,bitno) ((var) &= ~(1 << (bitno)))
#define xorbit(var,bitno) ((var) ^= 1 << (bitno))

Assim sendo ao fazer...
 

setbit(PORTC,0);
clrbit(PORTB,4);
xorbit(PORTD,2);

... temos o resultado esperado. E tem uma outra macro ainda mais lôca pra converter de hex pra bcd e vice versa... mas não quero causar indigestão no amigo...

 

[MOR_AL]

1 hora atrás, Sérgio Lembo disse:

Sintaxe é um saco. Se no uC  que está estudando é usado PINx para leitura e PORTx para escrita adapte-se a isso (foi a impressão que me passou a foto postada).

Tem razão. É isso mesmo. Sua informação foi útil para minha compreensão.

Tenho estudado mais sobre os STM8 e STM32F0 onde não se tem essa diferenciação.

adicionado 8 minutos depois

Apenas para te alertar: em muitos uC tem-se forma especial de se escrever na porta, me refiro ao assembler. Se a porta é um byte de registrador, como setar ou clarear um bit (pino) específico sem afetar os demais? Isso te obriga a ter um conhecimento prévio dos demais e mostrar o byte para não bagunçar. No entanto se tem um comando de setar apenas os bits que te interessam se afetar os demais. Mandando 0b00000101 com comando de set bits 0 e 2 são setados e os demais permanecem inalterados. Da mesma forma um clear 0b00000101 reseta bits 0 e 2 sem alterar os demais.

Ok. Mas isso já é função da linguagem do compilador. Nos PICs tem as instruções em assembler BCF (Bit Clear Flag) Registro, Bit e BSF (Bit Set Flag) Registro, Bit. Então, os compiladores do PIC devem possuir função semelhante em linguagem de mais alto nível que o Assembler.

Como ainda estou estudando o AVR, não posso afirmar que tenha função semelhante, mas é bem provável que haja.

 

adicionado 2 minutos depois

44 minutos atrás, Isadora Ferraz disse:

.... E tem uma outra macro ainda mais lôca pra converter de hex pra bcd e vice versa... mas não quero causar indigestão no amigo...

 

MOR_AL

[Sérgio Lembo]

Estou mantendo esse comentário  por fidelidade a discussão que se seguiu. São conclusões erradas, a elucidação aparece no fim do tópico.

 

Acho que descobri a causa dessa discriminação entre PINx e PORTx. Estava estranhando o Morris pelo nível já alcançado (bem maior que o meu) estar perdido em algo tão simples como manipulação de IO. Só mesmo um desafio lançado pelo @MOR para me incitar a ler manual.

Fui fuçar o site da Microchip e escolhi um AVR qualquer para ler o datasheet. (ATmega808/809/1608/1609PORT - I/O Pin Configuration). Descobri que além do banco de registradores que estamos acostumados a ver em cada porta de qualquer uC de qualquer fabricante neste modelo ainda temos uma tal de Porta Virtual, um espelho da porta física que permite certas manipulações de dados não presente na porta real (foi o que entendi)

 

Extraido deste manual

http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega808-809-1608-1609-Data-Sheet-DS40002172A.pdf

pagina 142

 

16.3.2.3 Virtual Ports

The Virtual PORT registers map the most frequently used regular PORT registers into the bit-accessible I/O space.Writing to the Virtual PORT registers has the same effect as writing to the regular registers, but allows for memory-specific instructions, such as bit-manipulation instructions, which are not valid for the extended I/O memory spacewhere the regular PORT registers reside.

 

Isso talvez explique aquele tal de PIND. Notem que a sintaxe PINx é usada numa situação onde se deve atualizar flags para viabilizar as condicionais implicitas no comando IF. Não se trata de simples leitura, na linha de baixo temos PORTx sendo usadas não só como leitura como tambem em operação lógica OU mas num contexto onde a atualização de flag não se faz necessária, não há instrução condicional dependente do resultado.

 

O comentário acima talvez esteja errado, ainda não encontrei uma resposta para ser chamada de definitiva.

[Sérgio Lembo]

Estou mantendo esse comentário  por fidelidade a discussão que se seguiu. São conclusões erradas, a elucidação aparece no fim do tópico.

 

Ainda sem entender esse PINx.

Pensei melhor no que escrevi antes. Se o processador primeiro carrega o conteúdo da porta para depois realizar as operações, para a a operação de leitura o uso a ser feito com o resultado é indiferente. Para a ALU o valor já está armazenado em algum registrador da CPU, a origem do dado é passado. Teremos alguma instrução no AVR que permite fazer operação da ALU direta pelo endereço do registro sem carga prévia? Este tópico do Morris que inicialmente parecia ser coisa boba me deixou confuso.

adicionado 26 minutos depois

Ainda sem entender esse PINx.

Abri o set de instruções.

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-0856-AVR-Instruction-Set-Manual.pdf

na pagina 15 temos o texto abaixo, mas isso não seria tarefa para o compilador como bem já observou o Morris?

 

[MOR_AL]

Bom.

Eu peguei a figura do manual do AVR 328 e analisei alguma coisa, mas teria que fazê-lo com os tempos do ciclo. 

Até o momento entendi, e posso não estar certo, que:

1 - Ao setar o pino WDx, o uC desabilita o resistor de PU e habilita a chave A (que eu marquei), liberando o dado do FF à direita de "A". Provavelmente, para escrever apenas no pino de saída, WPx = 0, WRx = WDx  com transição positiva.

2 - Para ler o pino Pxn, RPx = WRX = 1 e RDx = 0.

Não dá para analisar sem os tempos do ciclo, mesmo assim, está ficando muito chato. Vou aceitar e fim, hehehe.

MOR_AL

 

[Sérgio Lembo]

Não entendi essa montagem da porta. São 2 formas de acesso para a mesma coisa, nunca vi nada semelhante. Com certeza deve ter alguma utilidade mas sequer imagino qual seja.

@aphawk, participe aqui! sabe de algo?

[.if]

3 horas atrás, MOR disse:

está ficando muito chato. Vou aceitar e fim, hehehe.

Sábia decisão.

Um programinha bobo que fiz há alguns anos pro atmega16... primo pobre do atmega32. Algo como um pisca led anabolizado com vu com leds...

 

#include <ioavr.h>

#define ADC_VREF_VCC 0x00 //5V

//*********************************************************************************
unsigned int read_adc(unsigned char ch)
{
ADMUX=ADC_VREF_VCC | ch;
ADCSRA|=0x40;
while (!ADCSRA_Bit4);
return ADC;
}
//*********************************************************************************

#define ATMEGA16
//#define PIC16F887
void main( void )
{
unsigned int a,b;

#if defined PIC16F887
TRISA=0x01;
TRISB=0x00;
TRISD=0x00;
TRISD=0x00;
#endif

#if defined ATMEGA16
DDRA=0xfe;// PA.0=entrada analógica
DDRB=0xff; //tudo saída
DDRC=0xff; //tudo saída
DDRD=0xff; //tudo saída
PORTC=PORTD=0;
#endif

ADCSRA=0xc7;
   
for(;;)
{
a=read_adc(0);
a=(a*64)/4096;
a=1<<a;
PORTC=a;
PORTD=a>>8;

PORTB=(b++)>>4;
}
 
}

Envolve um pouco os conceitos que tentei passar (tentei né...) e pode não vos ser totalmente inútil

 

[MOR_AL]

6 horas atrás, Sérgio Lembo disse:

Não entendi essa montagem da porta. São 2 formas de acesso para a mesma coisa, nunca vi nada semelhante. Com certeza deve ter alguma utilidade mas sequer imagino qual seja.

@aphawk, participe aqui! sabe de algo?

O detalhe é que a leitura ou escrita não é simples. Isso ocorre também nos PICs. 

Veja o que consta no manual do 328p, traduzido pelo Google Tradutor... e minhas pequenas alterações na didática.

"Todas as portas do AVR possuem uma verdadeira funcionalidade de leitura-modificação-gravação, quando usadas como portas de E / S digitais gerais. Isso significa que a direção de um pino de porta pode ser alterada, sem alterar acidentalmente a direção de qualquer outro pino com as Instruções SBI e CBI. O mesmo se aplica ao alterar o valor do inversor (se configurado como saída) ou ativando / desativando a capacidade dos resistores de pull-up (se configurados como entrada)."

MOR_AL

[Sérgio Lembo]

Fui caçar no datasheet  do 328 a imagem que comentaste. Ali fala das 3 formas de acesso / modificação da porta: PORTx; PINx e DIRx.

 

trecho da pag 100

Three I/O memory address locations are allocated for each port, one each for the Data Register (Portx),Data Direction Register (DDRx), and the Port Input Pins (PINx). The port input pins I/O location is read-only, while the data register and the data direction register are read/write. However, writing '1' to a bit inthe PINx register will result in a toggle in the corresponding bit in the data register. In addition, the Pull-upDisable (PUD) bit in MCUCR disables the pull-up function for all pins in all ports when set.

 

Seguindo a leitura é descrito algumas funcionalidades extras. Para o caso que alavancou o tópico com o objetivo de fazer leitura e somando a foto que o @MOR postou notei o seguinte:

PINx e PINxn são usados para leitura de entrada.

PORTx e PORTxn são usados para leitura de saida.

 

dos exemplos da foto:

PORTC = PORTC | 0b00000010 // liga o motor 1

Temos aqui a leitura com uso do registro PORTx e escrita do resultado da operação no registro PORTx. PORTC é uma saída.

 

If ((PIND & 0b00000001) == 0){ // se o sensor 1 for zero

Aqui temos o uso do registro PINx para ler uma entrada.

 

 

 

 

[MOR_AL]

13 horas atrás, Sérgio Lembo disse:

PORTC = PORTC | 0b00000010 // liga o motor 1

Temos aqui a leitura com uso do registro PORTx e escrita do resultado da operação no registro PORTx. PORTC é uma saída.

 

Agora entendi.

 

Se eu quiser apenas ler o estado da porta C, uso Registro = PINC.

Agora, se eu quiser escrever algo na porta C, uso o PORTC = PORTC (| ou &) (Registro ou valor).

 

MOR_AL

 

[Sérgio Lembo]

Temos uma limitação nos desenhos do manual da Microchip. Mostram os sinais internos de comando mas não mostram a interligação deles ao registro (nessa parte os manuais da ST são melhores).

Olhando para a figura que comentaste post #36 temos na parte inferior o  schmitt trigger fazendo leitura do pino. Ele que alimenta o PINxn.

 

Quando configurado como saída ler o valor memorizado no registro PORTxn ou o resultado lido pelo schmitt trigger que alimenta PINxn dá na mesma. Como saída ler PORTxn é mais seguro porque evita possíveis interferências que o circuito externo possa provocar no valor instantâneo do pino externo.

Como entrada PORTxn liga/desliga resistor de pull up.

Resumindo:

Na configuração saída: PORTxn é o valor imposto e PINxn é o valor lido pelo schmitt trigger no pino correspondente.

Na configuração entrada: PINxn é o registro ligado ao schmitt trigger e nos retorna o valor do circuito externo. PORTxn é usado para ligar/deslizar resistor de pull-up, isto oé, se 0 temos tristate, se 1 temos pull up. Não serve como leitura de estado lógico da entrada.

PINxn é um read only mas se o pino estiver como saída e escrever 1 nele provoca um toogle no pino e atualiza PORTxn correspondente (uma funcionalidade extra).

adicionado 34 minutos depois

Extraido da pagina 101 do datasheet do 358