PONTEIRO C.

[fabim]

Pô meu, perdi alguma coisa /?
Pelamor de DEUS.
Todo mundo ajudando o inutil aqui, eu aprendendo rapidão, se sair discução por causa de besteira, vou meter o pé no fiofó de meio mundo aqui em...

Recado ta dado..

[Djalma Toledo Rodrigues]

Pois é, os 8051s são os únicos uC com opção Processador Booleano ( Processador de um bit)
uC ideal para a Linguagem Booleana e Principalmente para o genial Grafcet
dos franceses.

Algumas intruções Booleanas:

CPL C – Complementa o Carry.
CPL Bit – Complementa o bit endereçado.
ANL C,Bit – Operação AND entre o Carry e o bit endereçado.
ANL C,/Bit – Operação AND entre o Carry e o complemento do bit
ORL C,Bit – Operação OR entre o Carry e o bit endereçado.
ORL C,/Bit – Operação OR entre o Carry e o complemento do bit endereçado.
MOV C,Bit – Move o bit endereçado para o Carry.
MOV Bit,C – Move o Carry para o bit endereçado.
JB Bit, rel – Salta se o bit endereçado estiver em "1".

E muito +++

Curioso é que os uC da Intel (8051) tem apenas parte da memória endereçada por bit. Os Pic tem endereçamento por bit em toda a memória mas, não tem o recurso de Processador Booleano.


Fabim tem um estranho jeito de aprender não acham ?

[ze]

fabim vem pro pau!!!! rs

o que Vós não pecerbeis é a sutilezA dos "rs" (smiles: coisa de bixa) colocados em ponTos estratégicOs da frase. eles tem uM poder (implícito, concordo) de trAnformar uma fRase apareNtemente OfenSiva em convErsa de amigos nUm boteCo. portanto, atenção aos rs´s dos amigos. são qUarks, mas são fundamentais pRa bons relacionamentoS.

sansung o recado era: você pensa grande, isso é bom, mas... ahhhhh.....esquece....detalhes...

eu que falo a lingua do fabim, tenho dificuldade em entender ele... tadim du 6. rs

"boa idéia" deletar isso.rs

[Djalma Toledo Rodrigues]

... ser uma grande estrela tem seu lado bom. um dia cai ....

É a tal estrela cadende ?

[joao]

Fabim,

Acho que o que o Jorge quis dizer é colocar os prototipos das funções no .h, para poder deixar ele reusável. Eu pelo menos acho.
Dai no .c ficaria apenas o código de processamento, que na verdade é o principal.

Só lembrando que se vc criar uma variável no seu .h, vc pode usar ela em outro carinha desde que tenha feito o include. Algumas vezes não é o que vc deseja, pois vc quer "proteger" ela de pessoas que podem usa-la erroneamente. Dai vc cria uma variável global no seu .c mesmo que os outros arquivos não terão acesso a ela.

Outra coisa.
Por exemplo, eu trabalho bastante com symbian OS. O que eles fazem é te fornecer apenas o .h e a lib, que seria o objeto compilado do .c(.cpp no meu caso). Assim vc protege o seu código e pode vender as libs apenas. Dai o carinha que comprar elas pode apenas incluir os headers(.h) no código dele e usar as funções.

Um pouco a mais sobre isso:
Se vc tem dois arquivos, vc precisa tomar cuidado na compilação, pois ela tem, digamos assim, duas etapas. Uma é a compilacão e a outra é o link. Na compilação, o compilador ve vc usando uma função/variável e sai correndo atrás dela, ou no código já gerado(uma funçào em cima da função que está chamando ela por exemplo) ou nos headers(no caso de usar os includes) e pronto. Ele não vai nem querer saber se o código está lá ou não desta função que vc chamou. Entende? Só vai acreditar que existe um prototipo, então provavelmente deve existir um código para ele.

Dai no link (linkage) ele tenta juntar tudo e dai se vc não tiver ela compilada e gerada a lib/obj, vai dar erro de linkage, pq ele compilou mas não conseguiu linkar com o outro código. Sempre preste atenção nos erros do compilador para não ficar se matando atoa!

[]'s

[fabim]

hummmmmmmmmm, por isto esta acontecendo uns erros imbecis aqui.

Imagina o seguinte.
4 includes para o projeto original.
*.C:
Aqui eu tenho as funções, procedimentos etc.
*.H-1:
Aqui eu tenho arrays de dados que contem os descriptor´s para a comunicação USB.
*.H-2:
Aqui eu tenho constantes do sistema, que são as definições de SFR´s nomeação das SFR´s, nomes de valores usadas para lógica do sistema etc.
*.H-3:
Aqui eu tenho algumas variaveis, struct´s..

*************************************************************

*.C, utiliza os 3 headre´s

*.H-1, Utiliza o *.H-2

*************************************************************

Pois bem, como fazer a linkagem ?
Pelo que eu observei, não tem como inserir um header dentro de outro..

Tipo, Header 1.
#include "header-2"...

agora fiquei cafusio..

Fabim

[Sergio38br]

Vc podia reportar que tipo de rro??

[ ]'s
Sergio

[Jorge_Francisco]

....Por exemplo, eu trabalho bastante com symbian OS...

Ah tah, e eu fe f**** aqui para aprender a fazer um APP no Symbian, pode me ajudando aí,hehehehe. Fiz meu Hello World e consegui capturar a camera, já é uma avanço,hehehe.


Fabim,

Faz assim:

main.c // programa principal
funcoes.h//todas as funcoes
def.h//todas as definições
var.h//variaveis

Só não vejo muito a necessidade de fazer um .h só para variáveis, mas sei lá, existem casos e casos.

Para incluir é fácil. Supondo que queira usar as definições em alguma função, então no arquivo funcoes.h colocará #include def.h, e então pode usar no main.c, colocando #include funcoes.h no main.c. Pronto.

[msamsoniuk]

ah, era soh charminho meu mesmo!

voces acham que um cara que queima aldeias e empilha corpos carbonizados fim de semana ficaria sensibilizado por algum "recado" do lellis ? pode vir para a porrada que o armamento aqui eh pesado!

bom, a regra que vc tem q adotar eh a seguinte:

arquivos .c == codigo e variaveis locais
arquivos .h == prototipos, definicoes e variaveis globais

imagina a nocao de encapsular coisas. vc tem uma caixa preta, por exemplo, a caixa preta do lcd, entao vc tem:

lcd.h
lcd.c

dentro de lcd.h vc tem definicoes e prototipos, por exemplo:

Código: Selecionar todos

#define LCD_PIN_D0 PTA0
#define LCD_PIN_D1 PTA1
...
#define LCD_CMD_CLEAR 0x01
...

void lcd_putchar(char);
void lcd_clear(void);


e assim por diante... do ponto de vista de usuario, esse lcd.h eh uma api! no lcd.c vc tem o codigo da api propriamente dito:

Código: Selecionar todos

#include <lcd.h>

// essa eh uma funcao nao visivel no .h, pq ela eh um metodo disponivel internamente apenas!

void lcd_access(char i,char rs,char rw)
{
   LCD_PIN_D0 = i&0;
   LCD_PIN_D1 = i&1;
   ...

}

// essas sao funcoes visiveis no .h, pq eh um metodo disponivel externamente!

void lcd_clear()
{
  lcd_access(LCD_CMD_CLR,0,0);
}

void lcd_putchar(char i)
{
  lcd_access(i,1,0);
}

...


quando o cara que vai usar a api compila a aplicacao dele (que provavelmente contem o main), ele nunca faz include de um arquivo .c! ele inclui apenas o .h e entao linka a aplicacao dele com a sua:

Código: Selecionar todos

#include <lcd.h>

int main()
{
  lcd_init();
  lcd_printf("minha aplicacao feliz!");
  ...
}


o linker varia de compilador para compilar, mas genericamente eh algo como:

ld -o application main.o lcd.o

esse lcd.o pode ser um cara que ele compilou na hora se ele tiver o lcd.c ou, o que eh o ideal, um lcd.o que vc compilou e vendeu para ele!

eventualmente, tambem eh comum vender bibliotecas, nesse caso seria um liblcd.a ou liblcd.so (a diferenca eh ser uma biblioteca de linkagem estatica ou linkagem dinamica).

mas pq nao incluir um arquivo.c ? pq compilar dezenas ou centenas de arquivos separadamente eh muito mais eficiente que compilar um mega arquivo!

no caso do exemplo acima, poderia ter dezenas de modulos:

cc -c lcd.c
cc -c main.c
cc -c lalala.c
cc -c lelele.c
...
ld -o application *.o

para isso, vc poderia fazer um Makefile! posso passar mais tarde um Makefile e melhores exemplos com o SDCC compilando para um antigo, arcaico e simplorio 68HC08, que eh para uns e outros nao falarem que eu soh faco coisa para powerquicc-iii hehehe ;D

[barboza]

Bem deixa eu dizer como organizo meus projetos:

main.c /// main(), Init_Hardware, start_OS quando tem ou o while(TRUE) da vida


app.c // Funcoes da minha aplicaçao e variaveis locais
app.h // Prototipos, defines da APP e variaveis publicas para quem incluir app.h

driver_x.c // funcoes do driver em questão
driver_x.h // Prototipos, defines e variáveis publicas para quem incluir driver_x.h


se voce criar um arquivos com todos os defines, funcoes e variaveis quando quiser reaproveitar algum modulo (xxx.c) em outro projeto terá que levar o .h que tem definicoes de outros módulos do outro projeto.

outro cuidado que deve tomar ao criar e publicar variaveis em .h é usar pragmas para identificar qual arquivo esta incluindo o .h para criar a variavel somente em seu modulo, pois senao o compilador/link vai gritar ao compilar o segundo arquivo .c que incluir o .h pois terá duas variaveis com o mesmo nome.

[barboza]

Enviei o post acima em paralelo com o Marcelo e quis dizer o mesmo que ele.

Compartilho com a mesma organização do projeto.

[fabim]

á caca é essa então.
Duplicated ....
undeclared...

vou ajeitar isto..

[msamsoniuk]

a duplicacao pode ser resolvida de forma simples!

por exemplo, para um lcd.h

Código: Selecionar todos

#ifndef LCD_HEADER
#define LCD_HEADER

seus prototipos
suas definicoes
etc

#endif


se vc tiver um app.h que inclui o lcd.h e o cara por azar incluir novamente o lcd.h, nao tem problema, pq ele esta definido exatamente uma unica vez.

sobre o Makefile, olha ele ae:

Código: Selecionar todos

TARGET  = hc908rtos.S19
OBJS    = strings.rel stdio.rel stdlib.rel main.rel sci.rel kbi.rel adc.rel tim.rel spi.rel tbm.rel
CC      = sdcc
CFLAGS  = -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF

%.rel: %.c
        $(CC) $(CFLAGS) -o $@ -c $<

all: $(TARGET)

$(TARGET):: $(OBJS)
        $(CC) $(CFLAGS) -o $@ $(OBJS)

install: $(TARGET)
        hc908sh /dev/ttyS0 -start -erase -upload $(TARGET) -end

clean:
        rm -vf *.{S19,asm,lnk,lst,map,mem,rel,rst,sym}


no caso, os .rel sao os .o (o SDCC os chama assim!). na hora de compilar, basta eu digitar make:

Código: Selecionar todos

# make
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o strings.rel -c strings.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o stdio.rel -c stdio.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o stdlib.rel -c stdlib.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o main.rel -c main.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o sci.rel -c sci.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o kbi.rel -c kbi.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o adc.rel -c adc.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o tim.rel -c tim.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o spi.rel -c spi.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o tbm.rel -c tbm.c
sdcc -mhc08 --code-loc 0xEE00 --data-loc 0x40 --stack-loc 0x1BF -o hc908rtos.S19 strings.rel stdio.rel stdlib.rel main.rel sci.rel kbi.rel adc.rel tim.rel spi.rel tbm.rel


simples! para ficar perfeito soh falta descobrir pq o ld do SDCC nao gosta que os arquivos se chamem .o hahaha

[barboza]

Para evitar duplicata e publicar variáveis no .h use assim:

arquivo.c

Código: Selecionar todos

/************************************************************************
                      SEU HEADER
*************************************************************************/

#define _ARQUIVO_C_

/************************************************************************
                  INCLUDE - GERAL
*************************************************************************/

#include   <LPC2103.H>
#include   <RTL.h>
#include   <string.h>
#include   "types.h"

/************************************************************************
                  INCLUDE - LOCAL
*************************************************************************/
#include   "PROG.h"

/************************************************************************
            VARIAVEIS DISPONIVEIS APENAS PARA O MODULO
*************************************************************************/
static   U8   u8_xxxx;

/************************************************************************
                        FUNCOES
*************************************************************************/

void funcao_1 (void)
{
 u8_xxxx++;
}

/*************************************************************************/



PROG.h

Código: Selecionar todos

/************************************************************************
                      SEU HEADER
*************************************************************************/

#ifndef _ARQUIVO_H_

#define _ARQUIVO_H_

#ifdef _ARQUIVO_C_
#define   PUBLIC
#else
#define   PUBLIC   extern
#endif

/************************************************************************
                     DEFINES
*************************************************************************/

/************************************************************************
                     ESTRUTURA
*************************************************************************/

/************************************************************************
            VARIAVEIS DISPONIVEIS PARA TODOS OS MODULOS
*************************************************************************/
PUBLIC   OS_TID os_tid_prog_setup;

/************************************************************************
         PROTOTIPOS - FUNCOES DISPONIVEIS APENAS NO MODULO
*************************************************************************/
static   void   task_prog_setup   ( void )   __task;

/************************************************************************
         PROTOTIPOS - FUNCOES DISPONIVEIS PARA TODOS OS MODULOS
*************************************************************************/
void   p_prog_init   ( void );

/************************************************************************/

#undef   PUBLIC
#endif  // _ARQUIVO_H_

[Sergio38br]

Bom dia, Fabim , cuidado ao fazer menção aos alias dos pinos, registradores ou de algum bit especifico, geralmente isto esta no arquivo H do PIC utilizado.

[ ]'s
Sergio