Divirtam-se.
http://dmitry.co/index.php?p=./04.Thoug ... 0on%208bit
Fórum sobre desenvolvimento de sistemas embarcados: Hardware e Software, Tecnologias: Eletrônica digital e analógica, Microcontroladoras, Microprocessadores, Sistemas *NIX (Linux, BSD), Software embarcado Baremetal. Sem fins lucrativos.
Linux em um MCU de 8-bits emulando ARM
Moderadores: 51, guest2003, Renie, gpenga
22 mensagens
• Página 1 de 2 • 1, 2
Linux em um MCU de 8-bits emulando ARM
por ivan braga » 04 Abr 2012 17:07
"Mesmo o objeto mais inanimado tem movimento suficiente para ficar na sua frente e provocar um acidente."
"Even the most inanimate object has enough movement to stand in your way and cause an accident."
"Even the most inanimate object has enough movement to stand in your way and cause an accident."
-
ivan braga - Nibble
- Mensagens: 60
- Registrado em: 15 Dez 2006 18:02
- Localização: Rio de Janeiro
por tcpipchip » 04 Abr 2012 17:59
O Russo nao podia sair de casa...por causa da neve, nao tinha mulher...estao resolveu estudar a maquina de estados do ARM...
Caramba....!!!!! Muito bom!!!!
Vou sair desta area!
TCPIPCHIP
PS: boot de 2 horas
Caramba....!!!!! Muito bom!!!!
Vou sair desta area!
TCPIPCHIP
PS: boot de 2 horas
-
tcpipchip - Dword
- Mensagens: 6560
- Registrado em: 11 Out 2006 22:32
- Localização: TCPIPCHIPizinho!
por proex » 05 Abr 2012 08:07
A parte que eu mais gostei foi essa:
" It takes about 2 hours to boot to bash prompt ("init=/bin/bash" kernel command line). Then 4 more hours to boot up the entire Ubuntu ("exec init" and then login). "
Ou seja, somando tudo, o bicho demora 6 horas pra dar o boot no Linux.
.
" It takes about 2 hours to boot to bash prompt ("init=/bin/bash" kernel command line). Then 4 more hours to boot up the entire Ubuntu ("exec init" and then login). "
Ou seja, somando tudo, o bicho demora 6 horas pra dar o boot no Linux.
.
- proex
- Dword
- Mensagens: 2101
- Registrado em: 11 Out 2006 14:05
- Localização: São Paulo
por Rodrigo_P_A » 05 Abr 2012 10:43
realmente o cara é bom, e eu acredito que é possível sim.
mas que o cara teve que estudar muito e ter muita paciência, isso ele teve!
mas que o cara teve que estudar muito e ter muita paciência, isso ele teve!
---
-
Rodrigo_P_A - Dword
- Mensagens: 2237
- Registrado em: 12 Out 2006 18:27
- Localização: Osasco - S.P - Brasil
por tcpipchip » 05 Abr 2012 11:21
Nao é dificil não...mas tem que ter um bom PARSER...e muita paciencia como o RODRIGO falou...
Nos chegamos a fazer um emulador da maquina M+, o qual chamamos de M++...só tinhamos apenas 16 instruções para criar a maquina de estados...(microinstruções)
O cara é bom mesmo!!!! E novo!
veja os exemplos do PARSER dele...
cp.c e outros que começam com cp...c
Lá o cara mostra a troca do modo system para user e como ele preserva os registradores
É hora de clonar o ARM
Dá até um TCC, passando para um FPGA...
TCPIPCHIP
Nos chegamos a fazer um emulador da maquina M+, o qual chamamos de M++...só tinhamos apenas 16 instruções para criar a maquina de estados...(microinstruções)
O cara é bom mesmo!!!! E novo!
veja os exemplos do PARSER dele...
cp.c e outros que começam com cp...c
Lá o cara mostra a troca do modo system para user
e como ele preserva os registradores
É hora de clonar o ARM
Dá até um TCC, passando para um FPGA...
TCPIPCHIP
-
tcpipchip - Dword
- Mensagens: 6560
- Registrado em: 11 Out 2006 22:32
- Localização: TCPIPCHIPizinho!
por msamsoniuk » 05 Abr 2012 11:42
se ele fosse realmente bom, teria feito algo melhor. botar um emulador de processador 32 bits em um processador de 8 bits soh p/ dizer que roda linux eh supra-sumo do "eu sou um idiota e preciso chamar a atencao".
Rodrigo_P_A escreveu:realmente o cara é bom, e eu acredito que é possível sim.
mas que o cara teve que estudar muito e ter muita paciência, isso ele teve!
-
msamsoniuk - Dword
- Mensagens: 2935
- Registrado em: 13 Out 2006 18:04
por msamsoniuk » 05 Abr 2012 12:06
antes de tentar, dah uma olhada nisso:
http://opencores.org/articles,1004822682
bom, fora a questoes legais, tem uma importante questao funcional: performance!
tem tempo, eu achei alguns posts em foruns sobre o assunto e o povo comentava que a performance do blackARM era decepcionante, coisa da ordem de apenas 15 MHz, o q eh baixo comparado com os tipicos 30MHz que se consegue com um clone de 68000. recentemente eu portei um design nosso de um bus de 8 bits p/ 16 bits, houve uma piora de performance e comecei a entender como a coisa funciona.
e o motivo eh bem simples: em uma FPGA, quando maior a largura do barramento, maior eh o requerimento de tempo extra de setup/hold. se vc tiver uma unica linha, vc consegue fechar o tempo de setup/hold em algo da ordem de 500MHz em uma FPGA barata. se vc tem duas linhas, os tempos de setup/hold delas vao ser diferentes e o tempo total sera a soma dos tempos de setup/hold. com 16 linhas vc chega em algo como 30MHz e com 32 linhas fica nos 15MHz.
a maior parte das FPGAs tem otimizacoes p/ larguras de 16 bits, mas o uso requer uma certe simetria de construcao. quando a logica eh muito complexa (como eh um ARM ou 68000), existe um quebra de simetria e a logica passa a ser descrita de forma assimetrica. o resultado eh aquele espalhamento da temporizacao de setup/hold.
designs simples, como o J1, conseguem manter uma certa simetria, nao apenas melhorando a performance, como tambem ocupando muito menos espaco:
http://excamera.com/sphinx/fpga-j1.html
nao sei quanto o BlackARM ocupava (nos foruns falaram algo da ordem de uma virtex com 1 milhao de gates!), mas p/ ter ideia, um 68000 em verilog consome espaco equivalente a oito cores J1 (uns 500 mil gates). e o J1 roda 3x mais rapido que o 68000.
http://opencores.org/articles,1004822682
bom, fora a questoes legais, tem uma importante questao funcional: performance!
tem tempo, eu achei alguns posts em foruns sobre o assunto e o povo comentava que a performance do blackARM era decepcionante, coisa da ordem de apenas 15 MHz, o q eh baixo comparado com os tipicos 30MHz que se consegue com um clone de 68000. recentemente eu portei um design nosso de um bus de 8 bits p/ 16 bits, houve uma piora de performance e comecei a entender como a coisa funciona.
e o motivo eh bem simples: em uma FPGA, quando maior a largura do barramento, maior eh o requerimento de tempo extra de setup/hold. se vc tiver uma unica linha, vc consegue fechar o tempo de setup/hold em algo da ordem de 500MHz em uma FPGA barata. se vc tem duas linhas, os tempos de setup/hold delas vao ser diferentes e o tempo total sera a soma dos tempos de setup/hold. com 16 linhas vc chega em algo como 30MHz e com 32 linhas fica nos 15MHz.
a maior parte das FPGAs tem otimizacoes p/ larguras de 16 bits, mas o uso requer uma certe simetria de construcao. quando a logica eh muito complexa (como eh um ARM ou 68000), existe um quebra de simetria e a logica passa a ser descrita de forma assimetrica. o resultado eh aquele espalhamento da temporizacao de setup/hold.
designs simples, como o J1, conseguem manter uma certa simetria, nao apenas melhorando a performance, como tambem ocupando muito menos espaco:
http://excamera.com/sphinx/fpga-j1.html
nao sei quanto o BlackARM ocupava (nos foruns falaram algo da ordem de uma virtex com 1 milhao de gates!), mas p/ ter ideia, um 68000 em verilog consome espaco equivalente a oito cores J1 (uns 500 mil gates). e o J1 roda 3x mais rapido que o 68000.
tcpipchip escreveu:Nao é dificil não...mas tem que ter um bom PARSER...e muita paciencia como o RODRIGO falou...
Nos chegamos a fazer um emulador da maquina M+, o qual chamamos de M++...só tinhamos apenas 16 instruções para criar a maquina de estados...(microinstruções)
O cara é bom mesmo!!!! E novo!
veja os exemplos do PARSER dele...
cp.c e outros que começam com cp...c
Lá o cara mostra a troca do modo system para user
É hora de clonar o ARM
Dá até um TCC, passando para um FPGA...
TCPIPCHIP
-
msamsoniuk - Dword
- Mensagens: 2935
- Registrado em: 13 Out 2006 18:04
por xultz » 05 Abr 2012 12:57
se ele fosse realmente bom, teria feito algo melhor. botar um emulador de processador 32 bits em um processador de 8 bits soh p/ dizer que roda linux eh supra-sumo do "eu sou um idiota e preciso chamar a atencao".
98% das vezes estou certo, e não estou nem aí pros outros 3%.
-
xultz - Dword
- Mensagens: 3001
- Registrado em: 13 Out 2006 18:41
- Localização: Curitiba
por Rodrigo_P_A » 05 Abr 2012 13:04
xultz escreveu:se ele fosse realmente bom, teria feito algo melhor. botar um emulador de processador 32 bits em um processador de 8 bits soh p/ dizer que roda linux eh supra-sumo do "eu sou um idiota e preciso chamar a atencao".
kkkk, eita, agora vai começar a treta!
---
-
Rodrigo_P_A - Dword
- Mensagens: 2237
- Registrado em: 12 Out 2006 18:27
- Localização: Osasco - S.P - Brasil
por EvandrPic » 05 Abr 2012 13:46
O cara é bom mesmo...
O outro projeto dele também é bem interessante.
PIC-based audio player 2
http://www.youtube.com/watch?v=UtMgx4yMETw&hd=1
O outro projeto dele também é bem interessante.
PIC-based audio player 2
http://www.youtube.com/watch?v=UtMgx4yMETw&hd=1
- EvandrPic
- Dword
- Mensagens: 2116
- Registrado em: 31 Mar 2010 15:05
por proex » 05 Abr 2012 16:02
EvandrPic escreveu:O cara é bom mesmo...
O outro projeto dele também é bem interessante.
PIC-based audio player 2
http://www.youtube.com/watch?v=UtMgx4yMETw&hd=1
Até ai, nada de mais. Eu também já fiz isso a dois anos atras: http://www.proex.eng.br/gravadordigital.htm
.
Editado pela última vez por proex em 05 Abr 2012 19:51, em um total de 1 vez.
- proex
- Dword
- Mensagens: 2101
- Registrado em: 11 Out 2006 14:05
- Localização: São Paulo
por EvandrPic » 05 Abr 2012 17:50
Mas não com um PIC 12F né? 
proex escreveu:EvandrPic escreveu:O cara é bom mesmo...
O outro projeto dele também é bem interessante.
PIC-based audio player 2
http://www.youtube.com/watch?v=UtMgx4yMETw&hd=1
Até nada de mais, eu também já fiz isso, a dois anos atras: http://www.proex.eng.br/gravadordigital.htm
.
- EvandrPic
- Dword
- Mensagens: 2116
- Registrado em: 31 Mar 2010 15:05
22 mensagens
• Página 1 de 2 • 1, 2
Quem está online
Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante