Arduino dominando o mundo.

[msamsoniuk]

eh cada uma que eu leio aqui nesse forum que nao dah gosto nem de comentar! hahaha

[andre_luis]

Talvez porque estejam faltando argumentos...

O fato é que ninguem vai deixar de adotar determinado uC por ter certas funcionalidades implementadas em co-processador ou no próprio core.

+++

[msamsoniuk]

Talvez porque estejam faltando argumentos... O fato é que ninguem vai deixar de adotar determinado uC por ter certas funcionalidades implementadas em co-processador ou no próprio core.

com certeza nao eh por falta de argumentos, mas pq perder tempo com gente teimosa? deixa pra lah! (:

[andre_luis]

...com certeza nao eh por fala de argumentos, mas pq perder tempo com gente teimosa?...

Uma pena, pois o exercício da argumentação faz parte do debate de opiniões, e fica a impressão de não ser o único teimoso.

Gostaria de ser convencido de que estou errado, pois significaria que estou aprendendo algo com alguem que possua mais conhecimentos que eu.

...deixa pra lah!...

De acordo...



+++

[mastk]

André, FPU é um modulo de alta performance, de ela não estiver ligada a CPU de forma eficaz, perder o sentido a existência dela, imagine o seguinte, enviar 8 bytes do 8051 até a FPU e depois 4 leitura para recuperar o resultado, é tanto tempo, mas tanto que a FPU ficaria tomando chá e o processador se mataria tentando suprimir a FPU.
O 8051 normal jamais poderia ser tão eficiente como um FPU, mas ai o problema já não é a presença ou não dela, mas sim o animal que insiste em usar um CORE desses, quando quase tudo que tem no mercado é melhor.

[andre_luis]

Concordo contigo, pois a ALU deve estar no próprio core da CPU, já que as instruções algébricas são executadas nela.
Inclusive, não creio que atualmente nenhum uC utilize conceito diferente para uma FPU.

De qualquer forma, não era isso que estava sendo contestado, mas o exemplo que ele passou do PIC com ETH.
O core pode ter quantos módulos built in necessários, se isso vai agregar mais performance como um todo.



+++

[mastk]

Um modelo de ETH de 100, precisa de uma CPU de 32 bits no mínimo de um barramento desse tamanho para poder operar com boa performance, a ETH dos PICs e MCU de 8 bits funciona bem obrigado, mas estão longe de serem capazes de grandes transferências e coisas assim, justamente para ter uma velocidade razoável, é precisa de Power PC da pesada e/ou FPGA.
Mas lembrando do que escreveu, o conjunto apresenta a funcionalidade necessárias, ponto e é isso o que o mercado quer e precisa.

[edison]

O VIRTUAL BREAD BOARD é baseado no FRITZING...e PROCESSING....
Nós temos instalados aqui na Universidade....mas ainda está instável....

Hummmm....bom saber ,vamos ficar atentos.
Grato.

[msamsoniuk]

Concordo contigo, pois a ALU deve estar no próprio core da CPU, já que as instruções algébricas são executadas nela.
Inclusive, não creio que atualmente nenhum uC utilize conceito diferente para uma FPU.

vc nao cre, mas tem! por sinal, se vc ler com atencao vai ver que nao apenas mostraram que existe um 8051 com FPU conectada como modulo de IO, como citaram que o 68k jah suportou pelo menos tres diferentes metodos de conexao de FPU:

a) como modulo de IO: a motorola inicialmente queria ter um coprocessador matematico no 68000, como todo outro fabricante de processador 16 ou 32 bits da epoca, mas imaginava vagamente como fazer isso. eles reservaram 2/16 do set de instrucoes para isso (os prefixos Axxx e Fxxx) e soh. quem queria um coprocessador colocava um 8087 ou weitek mapeado via IO e tratava ele como um mero periferico, ou seja, um modulo de IO. mais tarde, quando o 68881 surgiu, era possivel compilar o codigo normalmente como se houvesse uma FPU, entao as ocorrencias das instrucoes da FPU caiam na interrupcao de linha-F, de modo que um longo e complexo programa decodificava os bitmaps e simulava a interface entre core e coprocessador via IO mapeado em memoria. a vasta maioria dos processadores da decada de 70 nao foram planejados para ter interface de coprocessador e usam essa metodologia, pq nao tem como integrar ponto flutuante no set de instrucoes.

b) como coprocessador: com o 68020, a motorola definiu finalmente como seria a interface entre o core 68k e o coprocessador. inicialmente as opcoes de coprocessador eram uma MMU (68851) e uma FPU (68881) e o core tinha um protocolo de comunicacao com os coprocessadores que permitia compilar as instrucoes de ponto flutuante, por exemplo, de modo que a interrupcao de linha-F nao era mais necessaria. ao inves disso, o core decodificava parte da instrucoes com prefixo F e parte era enviada para o coprocessador. apesar do ganho de performance, havia um gargalo: toda a comunicacao era feita pelo barramento externo, q era por onde tambem passavam as instrucoes e dados. a vasta maioria dos processadores de 16 e 32 bits lancados na decada de 80 e que foram planejados para ter interface de coprocessador resevaram espaco no set de instrucoes e usam essa metodologia.

c) como unidade integrada: o 68030 integrou a MMU externa e o 68040 integrou a MMU e a FPU, de modo que a interacao entre os coprocessadores era feita por barramentos internos sem gargalos. alem disso livrar o barramento externo da interface de coprocessador, ambos os cores jah usavam arquitetura de harvard, de modo que caches separadas para instrucoes e dados supriam barramentos separados. de forma geral, ficou tudo muito mais paralelizado e eficiente. os processadores projetados na decada de 90 jah foram projetados com isso em mente, ou seja, reservam espaco no set de instrucoes para isso. e claro, como o proprio 68k e x86, processadores originalmente planejados para suportar coprocessador externo podem integrar isso internamente com facilidade.

como se percebe, a chave do negocio eh ter sido planejado antes, o q significa que nao tem como ter Z80, 6502, HC08, 8051, PIC, etc com FPU integrada no core: teria q existir uma reserva de bitmaps para essa funcao nos opcodes. e daih soh sobra via modulo de IO. e em alguns deles isso eh particularmente sofrido, pq tem q ser feito via instrucoes in/out.

e olha que eu soh falei da FPU: pega tudo isso e pensa num capitulo a parte soh para a integracao da maldita MMU! ah, e depois quando virou coldfire, acharam que rolava transformar isso em um DSP e metaram uma unidade MAC lah! :B

De qualquer forma, não era isso que estava sendo contestado, mas o exemplo que ele passou do PIC com ETH.

entao, eh o problema das pessoas quererem generalizar tudo como modulo de IO, mas nao dah neh... para FPU tem q ter um planejamento previo na arquitetura, tem q ter reserva no set de instrucoes e o core tem q ter os protocolos adequados para a FPU interagir com o fluxo de instrucoes, com os pipelines e com as caches. dei o exemplo da ethernet pq eh outro caso onde as pessoas generalizam e pisam feio na bola: se vc nao tem bandwidth entre o microcontrolador e o controlador ethernet, eh obvio que vc vai perder pacotes. nao tem milagre, uma interface ethernet operando full-duplex a 100Mbps vai requerer um pico de 25MB/s, entao DMA com suporte a ring-buffers e bastante memoria eh algo mandatorio. sempre existem solucoes alternativas, como controladores ethernet com memoria integrada: o pacote chega, fica nessa memoria e pode ser modificado e reenviado. mas eh uma solucao parcial que atende algumas condicoes. eh melhor que nada, mas obviamente nao eh uma solucao definitiva, cai na mesma historia da FPU lah mapeada em IO: eh um negocio precario que atende algumas necessidades e faz isso com um custo bem baixo, pq ninguem precisou realmente planejar nada com muito detalhe... soh que nao eh uma solucao que serve para todos os casos e falha miseravelmente qdo vc precisa de performance. tem gente q nao entende isso, bate o peh que rola usar a solucao low-cost e daih o cara q precisa do negocio funcionando com alta performance tem q ficar lutando contra os apostolos do juizo final que acham q qq coisa rola fazer com um PIC.

O core pode ter quantos módulos built in necessários, se isso vai agregar mais performance como um todo.

como vimos acima, nao eh tao facil assim. se nao foi planejado previamente, nao dah. o que dah eh para xunxar e meter o negocio a forca, mas vai ficar uma m*rda. por exemplo, no 68020 eh soh ligar o 68881 e deixar eles conversarem que eles se viram pq foi planejado para funcionar facil... agora, no 68000, q nao tem implementado o protocolo pq nao pensaram nisso na epoca, a coisa fica bem complexa e, certamente, vai ser muito mais lento.

soh para ter uma ideia da salada q fica apenas por nao terem planejado previamente:

http://www.retro.co.za/68000/MotorolaPD ... 7_REV0.PDF

e bom, soh de ver o nivel de complexidade jah dah para perceber que essa historia de coprocessador eh um belo de um beco sem saida. nao felizes com isso, os caras da motorola tiraram o velho 68000 da cartola em 1990, colocaram uma dual-port ram entre ele e um coprocessador e bingo: nasceu a familia 683xx. o conceito de interface de coprocessador via dual-port ram eh usado ateh hoje nos powerpcs mais potentes e se encaixa perfeitamente na interface entre FPGA e core... mas daih jah eh historia para outro dia! :B

[andre_luis]

Marcelo,



Valeu pela verdadeira aula, havia muitos detalhes que eu não sabia...

Relamente, o fato é que aparentemente as design-houses parecem ter de optar por decisões difíceis :
Se adotam o conceito da modularidade (com periféricos não integrados ao core) ganham competitividade, c/ várias famílias de uC, mas perde performance.

Se os incorporam, depois fica difícil a otimização no silício no caso de novas famílias, pois retirar determinadas áreas significa ter de redesenhar o layout.
Isso porque apesar de as macrocélulas são desenhadas em separado e com tentativa de manter alturas padronizadas, nem sempre é possível facilmente.

+++

[tcpipchip]

http://s4a.cat/

CHAOS Arduino Flowchart ?