PIC32 x ARM

Software e Hardware para linha ARM

Moderadores: 51, guest2003, Renie, gpenga

PIC32 x ARM

Mensagempor tcpipchip » 09 Mai 2008 19:10

> Someone can make a comparison between the architectures of the
> ARM7 and PIC32?

For all intents and purposes, they are the same. Minor wrinkles are that
ARM has predicated instructions and MIPS has more registers (hence context
switching can be slower). They both have compact instruction sets for
narrow flash and smaller programs (Thumb/MIPS16). Carry is difficult on
MIPS and MIPS will potentially abort on integer overflow. MIPS has delay
slots, ARM not.

Paul Curtis
CROSSWORKS
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 6560
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Mensagempor Fábio Pereira » 12 Mai 2008 11:24

Bom,

Eu não acho que sejam tão similares não. Os PIC32 são muito mais avançados que os ARM7, eles possuem um conjunto de instruções muito mais rico, permitem fazer multiplicação e divisão por hardware, manipulação direta de bits, além de outras operações que não estão disponíveis no conjunto de instruções ARMv4.

Além disso, os PIC32 possuem 32 registradores de 32 bits (contra os 16 disponíveis num modo ARM).

Acho que a comparação real deve ser entre os Cortex-M3 e PIC32, aí sim temos uma certa equivalência (pelo menos das funcionalidades básicas do conjunto de instruções).

Acredito que a Microchip terá uma tarefa árdua no que diz respeito a aceitação do PIC32 no mercado, pois trata-se de uma arquitetura poderosa mas bastante complexa. Claro que a utilização de ferramentas de alto nível tende a minizar o esforço de programação, mas ainda assim acredito que a programação dos PIC32 seja bastante mais complexa que as demais linhas da Microchip.

Neste ponto, ainda não vi nada mais simples do que os Coldfire v1 da Freescale: a facilidade de portar código de um chip de 8 bits (HCS08) para outro de 32 bits (CFv1) é resumida simplesmente a se clicar no botão TARGET do Codewarrior e selecionar a plataforma desejada. Fiz essa experimentação com alguns exemplos do meu livro HCS08 Unleashed escritos para o MC9S08QE128. Bastou mudar o target para o MCF51QE128, recompilar a aplicação e pronto, a aplicação estava rodando em uma plataforma de 32 bits !

T+
Fábio Pereira
embeddedsystems.io
Avatar do usuário
Fábio Pereira
Word
 
Mensagens: 674
Registrado em: 16 Out 2006 09:07
Localização: Kitchener, ON

Mensagempor Viktor » 13 Mai 2008 12:29

Fabio

Tem certeza qto à divisão por hardware ? O ARM7 também tem instrução de multiplicação e a manipulação direta de bits é, até onde sei, em determinados registradores dos periféricos, o que também existe em ARMs como por exemplo LPCxxxx. O conjunto de registradores maior é realmente, numa primeira analise, uma vantagem, porém a vantagem do conjunto de instruções, a não ser que você programe em assembly, é mais dependente do compilador usado numa primeira análise.
Viktor
Byte
 
Mensagens: 281
Registrado em: 12 Out 2006 11:33

Mensagempor proex » 13 Mai 2008 13:22

Antes de qualquer coisa, acho que para a Microchip conseguir algum sucesso com o PIC32, primeiramente ela tem que coloca-lo no mercado.

Até lá, os ARM já terão dominado ainda mais.

Logo logo, ARM de 200MIPS já serão coisas corriqueiras.
proex
Dword
 
Mensagens: 2101
Registrado em: 11 Out 2006 14:05
Localização: São Paulo

Mensagempor xultz » 13 Mai 2008 13:53

Ué, e já não são? Eu tenho umas plaqunhas em casa já que têm uns 4 anos de idade, com PXA255 que rodam a 400MHz...
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor Viktor » 13 Mai 2008 14:07

o pic32 tem mesmo divisão por hw
Viktor
Byte
 
Mensagens: 281
Registrado em: 12 Out 2006 11:33

Mensagempor msamsoniuk » 15 Mai 2008 12:57

o problema da ausencia de interlock das instrucoes continua presente nestes cores mips ? quem usa pic hoje, adora programar em asm e quer migrar para mips jah ouviu falar nessa historia ?
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor proex » 19 Mai 2008 06:30

Bem, eu só programo PIC em Assembler mas nunca ouvi falar nesse tal de interlock. O que seria isso? Talvez eu conheça por outro nome.

Para mim, a grande diferença entre ARM e PIC32 é que o primeiro, encontra-se a venda.
proex
Dword
 
Mensagens: 2101
Registrado em: 11 Out 2006 14:05
Localização: São Paulo

Mensagempor msamsoniuk » 19 Mai 2008 13:36

bom, eh uma historia meio longa mas...

qualquer processador moderno processa uma instrucao em uma sequencia de eventos internos, que chamamos de pipeline, eh tipo uma linha de montagem. vc tem q buscar a instrucao, decodificar um endereco fonte, por exemplo, puxar o operando, tratar o operando e fazer alguma coisa com esse operando. tudo isso faz parte de uma instrucao e cada estagio consome, digamos, um ciclo de clock. entao uma unica instrucao consome varios ciclos! como vc poderia encolher isso ? bom, vc poderia ter varias instrucoes entrando pelo pipeline como em uma linha de montagem, cada uma defasada um clock da outra, assim quando uma instrucao estivesse buscando um operando, outra estaria usando a alu e outra estaria armazenando o operando.

em um exemplo simples, se vc tiver 5 estagios, vc pode ter 5 instrucoes encaminhadas dentro deles e obter 5 resultados em 5 clocks. se o pipeline estiver sempre cheio, vc vai obter o pico de aproximadamente 1 instrucao por clock... o problema eh que as vezes uma instrucao precisa de um operando q esta em uso por outra instrucao, por exemplo, uma instrucao MUL D0,D1 e outra ADD D2,D1, se ambas estao no pipeline, eh de se esperar que um ADD consiga terminar antes de um MUL, mesmo que tenha entrado depois no pipeline! para evitar isso ativam-se automaticamente interlocks q param o pipeline ateh que o resultado esteja disponivel. isso causa uma queda de performance e vc comeca a nao ter aquela relacao de 1 instrucao por 1 clock...

a mips resolveu isso eliminando os interlocks. entao quando se compila algo, o compilador automaticamente reordena as instrucoes de modo que a instrucao ADD vai entrar lah embaixo, bem depois da instrucao MUL ter disponivel o resultado. no meio, ele simplesmente sobe coisas q nao ativam interlocks e que podem ser colocadas em qualquer posicao. com isso vc garante que chega perto de 1 instrucao para 1 clock a maior parte do tempo, aproveitando totalmente o pipeline do processador, em contrapartida torna a ordenacao das instrucoes altamente especializada, ou seja, vc depende de um compilador que conheca profundamente o processador e saiba como se safar da ausencia de interlock.

bom, as coisas existem pq tem um diferencial nao eh ? se o processador mips nao tem mais o diferencial da ausencia de interlock (o q torna impossivel a programacao manual em asm), realmente o destino dele eh ser esquecido e ir para a lata do lixo! sobrevive soh quem tem algum diferencial ou eh muito importante...
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor Viktor » 22 Mai 2008 07:39

Marcelo

Tanto o ARM como o MIPS tem esse problema e o compilador não pode garantir que isso não vá acontecer. Esse problema eu conheó como STALL.
Viktor
Byte
 
Mensagens: 281
Registrado em: 12 Out 2006 11:33

Mensagempor Fábio Pereira » 22 Mai 2008 09:32

Pelo que li a respeito os interlocks dos MIPS são feitos por hardware há bastante tempo. São estes interlocks por hardware que provocam o STALL que o Viktor mencionou (a paralisação da execução devido à espera por uma unidade de execução que ainda não completou sua tarefa).

T+
Fábio Pereira
embeddedsystems.io
Avatar do usuário
Fábio Pereira
Word
 
Mensagens: 674
Registrado em: 16 Out 2006 09:07
Localização: Kitchener, ON

Mensagempor Viktor » 22 Mai 2008 10:15

Além disso se não fosse feito por hardware (o tal intelock) o programa teria que ser preenchido com NOPs em diversos pontos ou coisa parecida, portanto é imperativo que esta solução tenha que ser feita por hardware, como aliás , é normalmente feita em todos os microcontroladores onde isto se verifica, portanto é difícil entender o tal referencial ao que o Marcelo se refere, já que todos eles tem este mecanismo que provoca o STALL qdo o dado solicitado na instrução não está disponível
Viktor
Byte
 
Mensagens: 281
Registrado em: 12 Out 2006 11:33

Mensagempor jeanfernandes » 25 Mai 2008 08:53

Traduzindo...
É como o Proex falou...
Até sair no mercado ou chegar aqui...
Só loko vai pensar em usar....
Concordo com o Fábio em parte sobre a arquitetura...
Só que...
6 ou 12 meses esperando algo não poe feijao à mesa.
Jean P. Fernandes - Eng. Eletrônico - (83) 2102-2116 - APEL - www.apel.com.br - Campina Grande - PB
jeanfernandes
Word
 
Mensagens: 539
Registrado em: 11 Out 2006 15:36
Localização: Campina Grande - PB

Mensagempor Fábio Pereira » 26 Mai 2008 16:58

Bom,

Eu não estava defendendo o PIC32 ...

Atualmente, em matéria de 32 bits, tenho preferido trabalhar com os Coldfire V1, pois é extremamente simples migrar as nossas aplicações de 8 bits (HCS08) para 32 bits (CFv1).

Além disso, ainda não vi um sistema de depuração melhor que o dos Coldfire/HCS08.

T+
Fábio Pereira
embeddedsystems.io
Avatar do usuário
Fábio Pereira
Word
 
Mensagens: 674
Registrado em: 16 Out 2006 09:07
Localização: Kitchener, ON

Mensagempor mastk » 26 Mai 2008 18:27

Dois entre ARM e PIC32 eu fico com Coldfire...
Avatar do usuário
mastk
Dword
 
Mensagens: 4407
Registrado em: 14 Out 2006 20:43

Próximo

Voltar para ARM

Quem está online

Usuários navegando neste fórum: Google [Bot] e 1 visitante

x