Dica Basica

[jeanfernandes]

Num sei se existem alguem ainda desorganizado no firmware, mas em todo caso....

http://www.youtube.com/watch?v=6d2FV4lspBU

Zoa nao... mas é assim que venho usando. Tomei com base o naming convention do FreeRTOS e fiz umas adequacoes.

Por hora ta servindo.

Fuiz.
P.S. : Cortex M3 é uma delicia. Nested Interrupts = 8051 32 bits kkkkk.

[Nightcrawler]

Muito bom....
Ta usado quais CM3?

[jeanfernandes]

NXP - LPC1768

Comprei 180 peças na Karimex por 7.3 US$ cada.
Preço ja no brasil.

[Rodrigo_P_A]

eu uso a mesma convenção usada no VC, UINT8, UINT16 , INT16, UINT32 etc....

[fabim]

Eu sou macho, então não uso essas firulas de types.h.
Meu negocio é ansi!! hehehe

[Rodrigo_P_A]

Eu sou macho, então não uso essas firulas de types.h.
Meu negocio é ansi!! hehehe

em um compilador ANSI para plataforma de 16 bits, o tipo int vai ser de 16 bits né?

e em um compilador ANSI para plataforma de 32 bits, o tipo int vai ser de 32 bits né?

Este é um exemplo básico, o uso de arquivos types.h não tem nada a ver com o padrão ANSI.

Até usando plataforma de 32 bits e ferramentas diferentes você corre o risco dos tamanhos dos tipos serem diferentes para cada nome.

além disso ainda tem as diretivas para montar e alinhar structs ( que dependem de cada compilador ), etc...



ou seja, se vc num usa types.h, se vc tiver que portar o código, vai ficar mais complicado, esta é minha opnião.

[fabim]

hehe, Mais que enche, enche!!!
Como não mecho mais com pic, nem com 16 bits, então .... hehehe

Mais a idéia é boa, vlw Rodrigo!!

[MarcusPonce]

Jean, legal a aula...
Sabe que como diz o ditado "cada cabeça... uma sentença" há discussões sobre colocar o tipo da variável no nome dela, pois uns afirmam que se for necessário mais tarde trocar ela de tipo então vai dar um trabalhão... Mas acredito que o maior trabalho de todos é caçar bugs, então tudo que nos ajude a não criar mais bugs é bem vindo, como a sua sugestão.

Sobre o formato uint32_t, int8_t, etc, eu acho que vocês estão querendo falar é do stdint.h que chegou com o C99 para diminuir problemas de portabilidade, como citado pelo Rodrigo. Já me ajudou.

Lá no pacote CMSIS está sendo usado, por exemplo.

Cortex M3 realmente é bacana, já estou usando da NXP também.

[msamsoniuk]

se int ter 16, 32 ou 64 bits no unix nao eh problema, pq seria em outras plataformas? de qq forma, standard eh standard:

http://opengroup.org/onlinepubs/0079087 ... lib.h.html
http://www.opengroup.org/onlinepubs/007 ... dio.h.html
etc

tudo simples, curto e grosso... saiu do standard, com certeza nao vai rodar, entao qualquer coisa diferente eh firula. todo programador devia fazer um preparatorio no BOPE antes de se aventurar nessas coisas!

[Rodrigo_P_A]

se int ter 16, 32 ou 64 bits no unix nao eh problema, pq seria em outras plataformas? de qq forma, standard eh standard:

http://opengroup.org/onlinepubs/0079087 ... lib.h.html
http://www.opengroup.org/onlinepubs/007 ... dio.h.html
etc

tudo simples, curto e grosso... qualquer coisa diferente eh firula.

perai meu, eu quis dizer o seguinte, no PIC por exemplo int = 8 bits

imagina que o cara fez uma rotina qualquer em que ele SABE que determinada variável tem que ter 32 bits, se ele fez a rotina no ARM, ele declarou como int, se ele for testar no PIC por exemplo vai dar PAU, pois no PIC int=8 bits, e a rotina dele não vai rodar

portanto, eu continuo achando melhor usar tipos definidos, em que eu sei o tamanho, pois muitas vezes isso faz diferença sim!

e eu num disse que tem problema na variável int.

[Rodrigo_P_A]

Jean, legal a aula...
Sabe que como diz o ditado "cada cabeça... uma sentença" há discussões sobre colocar o tipo da variável no nome dela, pois uns afirmam que se for necessário mais tarde trocar ela de tipo então vai dar um trabalhão... Mas acredito que o maior trabalho de todos é caçar bugs, então tudo que nos ajude a não criar mais bugs é bem vindo, como a sua sugestão.

Sobre o formato uint32_t, int8_t, etc, eu acho que vocês estão querendo falar é do stdint.h que chegou com o C99 para diminuir problemas de portabilidade, como citado pelo Rodrigo. Já me ajudou.

Lá no pacote CMSIS está sendo usado, por exemplo.

Cortex M3 realmente é bacana, já estou usando da NXP também.

Marcus eu num sabia do padrão introduzido no C99, eu vou dar uma olhada e tentar adotar este padrão agora.

[mastk]

Tempos atras ouvir um programador de servidores, que byte e bit eram coisas ultrapassadas e niguem usa mais essas coisas.

[Rodrigo_P_A]

Tempos atras ouvir um programador de servidores, que byte e bit eram coisas ultrapassadas e niguem usa mais essas coisas.

muitos caras que só programa em pc nem sabe direito o que é bit e para que serve.

muitos declaram tudo como int mesmo precisando só de 1 byte.

mas se a gente for começar a falar disso, aqui vai virar aquelas discussões que num tem nada a ver com o tópico hehehe

[mastk]

Sim, cada empressa que eu vou vejo um padrao diferente para os nomes, entao a regra que sigo hoje, é que não existe regra.

Mas a longe prazo PA, acho que vamos ir na mesma direcao, temos cada vez mais memoria e processamento com o mesmo custo. Talvez nao seja proibitivo vc usar como padrao o byte no tamanho do barramento do seu sistema, já nos dias de hoje.

[jeanfernandes]

Ces falam em portabilidade de codigo como se fosse um negocio feito trocar de roupa todo dia.

ANSI nao ANSI... a ideia foi dar uma visao de uma maneira de trabalhar. Ha pessoas que preferem um codigo mais clean. Bom, é de cada um.

As questoes de alinhamento de byte e diretivas de variaveis x tamanho de bits eh de cada um....

Sobre trocar o tipo da variavel depois : ehehehehehhe, esse depois ae me cheira a nao planejamento, que se resolve atraves de encapsulamento de variaveis.

Problema maior eh de uma forma ou de outra deixar o codigo : readable.

O bom de tudo isso é que : eu ja tenho umas versoes clean das coisas que fiz... esse negocio de trocar nome de variavel eu resolvo de outra maneira ,,,..... com uma planilha eu posso "portar" tudo num clique só....