ASM51

ATXMEGA1281A1

ADC 12 Bits 2 Mega Samples /s

DAC 12 Bits 1 Mega Conversões /s

DMA 4 Canais

Encriptação DES e AES por Hard

Até 16 M Memória externa adicional

Alimentação 1.6 a 3.6 sem restriçao de Frequência.

Soft: Compilador, Linker, IDE, Programodor, Debugador, gratis

http://www.atmel.com/products/AVR/default_xmega.asp

www.mcselec.com (Bascom)

Fonte: Elektor # 92
.

Desculpe DJ quis dizer

http://www.mcselec.com/


[ ]
Sergio

Olá Sergio38br

Já foi Editado e incluido o Site do Fabricante.

Obrigado.
.

Sempre estivemos em época de transição de tecnologias, mas talvez nunca como nesses "dias".
Na minha interpretação, há uma grande lacuna nos micros de 32 bits que é o consumo de energia.
O Cortex M0 não atende a performance e consumo de energia, mas é um quebra galho para quem tem um trabalho feito para o M3.
Muitos projetos estão tendo dificuldade de decisão devido ao consumo de energia, em relação a plataforma de 32bits.
O que mostra a ciência é que assim que sair o primeiro 32 bits, com solução para consumo de energia, o Xmega perderá o terreno que ocupa.
Por outro lado, como hoje não é mais o assembly que domina e sim os compiladores C, tendo performance e baixo consumo é isso que será mandatório (para trabalhar com baterias), não importando o número de bits.
Portanto, quando o consumo de energia for o foco, a cpu com menor número de bits e maior performance será a seleção mais acertada, no momento.

RobL escreveu: ... Por outro lado, como hoje não é mais o assembly que domina e sim
os compiladores C, tendo performance e baixo consumo é isso que será mandatório
(para trabalhar com baterias), não importando o número de bits.
Portanto, quando
o consumo de energia for o foco, a cpu com menor número de bits e maior performance
será a seleção mais acertada, no momento.

Não entendi o quem tem haver C com Consumo, já que o uC 'roda' em
Linguagem de Máquina (Binário)

Para Portateis , alimentados a Pilha, ou Bateria, o Consumo tem importância claro.
Para Super Computadores também. rs

Abraço RobL
.

Obviamente C nada tem a ver com o consumo. O texto é claro, diz repeito a escolha (independência) da arquitetura devido ao C. Note que se refere a bits.

Em outras palavras, por se usar C, a escolha para baixo consumo, não sofrerá influência tão grande quanto no tempo do assembly, para se decidir pelo core, ou seja, em C não importa se trabalho com 8, 32, 64, etc, bits, desde que tenha atendido pelo meu core performance e consumo.

O que significa "no tempo do assembly": Fica mais difícil migrar (voltar) de 32 para 8 bits, somente para atender um único fator, como consumo de energia, por exemplo se meu trabalho fosse em assembly.

Alguém vai perguntar: O que tem isso com o Xmega?
Justamente, quem está trabalhando com 32bits, incrivelmente terá que voltar aos 8 bits para atender performance e consumo, pois, por exemplo o Cortex M0 não atende ao ítem consumo e a performance, depende.
Para quem trabalha com C este retorno, momentâneo, é mais simples.

A Atmel se beneficiou de toda sua excelente estrutura com 8 bits, estendendo os AVRs para os Xmegas de baixo consumo de energia e isso é muito bom, perfeito, para quem já trabalhava com AVR, praticamente sem lead time. Para os demais é preciso muita análise.

C consome muita energia...rotinas pesadas e grandes...
Realmente quem domina hoje são os compiladores C,digo ,os compiladores porquer as rotinas nem tanto...heheh

me preocupa o fato que a linguagem C não disponibilizou formas de se fazer "Rotate" (ROR/ROL/RCL/RCR) ...
também me preocupa que não é tão fácil saber se uma conta aritmetica deu overflow/carry/borrow de um jeito tão facil quanto aproveitar os flags de resposta...

como vocês contornam isso? Dá nos nervos programar em C de vez em quando...

Jozias,é fácil,é só implementar estas rotinas em ASM no código C,hehe.

O C é do 'Caracas'

Para inclementar: a ++

Para Deslocar a Esquerda 2 X : a <<

Pior, bem pior, MPLAB IDE e demais IDEs.

Inda bem aceita :

Código: Selecionar todos

   _asm
   .
   .
   _endasm 

.

poisé, mas nestes momentos que perde-se a portabilidade tão almejada neste tópico...

e também não se pode ficar fazendo isso na linguagem C toda hora...

pow, seria tão bom se eu pudesse fazer algo do tipo:

Código: Selecionar todos

int a = 0x12345678;
a <<< 8; // rotate!
// agora a = 0x23456781


ou então...

Código: Selecionar todos

for (int i = 0 ; i < 8 ; ++i)
  if ( carry(crc >> 1) )
    crc ^= 0x8005;


ou...

Código: Selecionar todos

unsigned char a, b, c;
// (...)
if ( carry(c = a+b) )
  c = 255;


se é que vcs me entendem... o único jeito de fazer essas coisas em C é por GAMBIARRA!

Quero a cabeça do Kernie&Ritchie!!!

Pior de tudo foi um post de um forum onde um 'programador C',queria implementar rotinas de calculos em ciclo de máquina pois fica muito lento em C...uaauu
Ele queria usar as 'funções de DSP'...hehe
http://forum.clubedohardware.com.br/divisao-dspic-s/734430

O que eu quero dizer é...

Será que existe situação em que um Compilador em C (sem usar asm inline) para AVR (ou para qualquer outro uC) gera uma instrução de Rotate? Quando que ele realmente aproveita o carry ou overfllow flag de uma conta? São instruções e recursos disponíveis em todos os controladores/processadores que eu conheço, porém o K&R deu prioridade ao shift (através do "<<" e ">>" ) mas não ao rotate, e impediu acesso aos flags...
alguém mais sente-se contrariado com esses fatos do C?

Jozias,se voce ficar 'interpretando' o ASM em C,não ha sentido em usar C.
Foi para isso que foi criado a linguagem de alto nível,para programadores que não precisam de todos os recursos de um hardware/Micro,mas precisam desenvolver um código eficiente.
Se um programador precisa de todos os recursos de memória/hardware,ele programa em lignguagem de máquina diretamente usando os DataSheets fornecido por eles,sem depender de rotinas de terceiros.

Será que existe situação em que um Compilador em C (sem usar asm inline) para AVR (ou para qualquer outro uC) gera uma instrução de Rotate?

Sim.

Há um núcleo do C que praticamente todo compilador será igual, mas não nas operações matemáticas. Nestas, vai depender da engenharia de software de cada compilador, pois há muitos meios de se chegar ao mesmo resultado.
Portanto, para certa operação, determinado compilador poderá usar rotate e outros não.
Por isso em C você não vai se preocupar de que forma será resolvida sua expressão.

Para tentar não sair fora do tópico, mais ainda, o C para micro sem sistema operacional deve ser usado com parcimônia. Para os amantes do Assembly, como eu, recomendo usar C como um front end (se me fiz entender) para o Assembly, é muito mais produtivo. O C não tem culpa de gerar códigos enormes e sim quando é mal aplicado em um pequeno micro. É preciso estudar bem o compilador.
Me amarro em Assembly, mas hoje não se justifica não usar C, e sempre que precisar, descer ao assembly, dentro do C. É uma questão de hábito, como tudo.