Há 43 anos, homem chegava à Lua com computador de 2kb de RAM

[Claudio Novais]

Aí é que está a coisa! Atualmente os Sistemas Operativos e aplicações que instalamos são absurdamente golozas em termos de processamento e memória. Dantes havia uma preocupação enormíssima na otimização pois os recursos eram escassos. Agora uma página Web é um autêntico absurdo de processamento.

Infelizmente estamos numa fase que na minha opinião é má. esperemos que com estes exemplos as coisas voltem ao normal. Eu sei que todo este processamento acrescido deve-se ao facto da programação modelar ser mais eficar no escalonamento, mas o problema é que isso traz um processamento bem superior. Se se deve voltar À idade da pedra na programação, não modelando o software? Acho que não. Mas utilizar uma estrutura modelar conceptual de forma a escalar a compilação da forma mais otimizada possível é sem dúvida um futuro risonho. Aliás, se um dia alguém fizer algo assim (talvez a google para o seu Android por causa destes problemas com o Java) certamente irá ganhar o mercado de uma forma muito fácil.

Sobre essas teorias: acredito nos dois lados. Os argumentos existem para os dois lados. Claro que acima de tudo a mentira é algo bastante plausível tendo em conta que os estados unidos estavam a ficar muito assustados com a situação da Guerra Fria. Mas não sei. É algo que era possível, apesar dos fracos recursos comparados com os atuais em termos de tecnologia. Algo que era extremamente difícil para calcular posicionamento da nave na aterragem, mas não impossível.

[Luis Cardoso]

(...) É algo que era possível, apesar dos fracos recursos comparados com os atuais em termos de tecnologia. Algo que era extremamente difícil para calcular posicionamento da nave na aterragem, mas não impossível.

Não é tão difícil como possa parecer, pois uma vez programado, o sistema agia com alguma autonomia! O problema atual é quererem meter "coisas gráficas" onde não é necessário... Pois se se quer processamento em tempo real, esqueçam os aspetos agradáveis, onde geralmente o Ambiente Gráfico cede regularmente devido à quantidade de informação que tem de processar!

[Claudio Novais]

Não sei muito de eletrónica, mas pensei que calcular matematicamente o posicionamento para a aterragem fosse algo complexo, tendo em conta que os sensores estariam constantemente a bombardear informação do posicionamento e até talvez da força da gravidade e outros aspetos do clima lunar...

[Luis Cardoso]

Não sei muito de eletrónica, mas pensei que calcular matematicamente o posicionamento para a aterragem fosse algo complexo, tendo em conta que os sensores estariam constantemente a bombardear informação do posicionamento e até talvez da força da gravidade e outros aspetos do clima lunar...

Só um pequeno exemplo!
Características:

• Micro-controlador (MCU): MSP430 da Texas Instruments:
  
  • 4kB de RAM (por imposição do IAR que na versão livre apenas permitia usar 4 dos 16 kB);
  • Freq.: 1MHz (embora pudesse usar até 4MHz, mas não era necessário);
  • Tensão de funcionamento (U): 3V.
• 2 pares de emissores/receptores de Infra-Vermelhos (IV);
• Motor DC para tracção (U:12V - Imáx: 4.5A);
• Servomotor para direcção (U: 5V - força: 6kg).

Por motivos de teste, no vídeo usou-se uma fonte de alimentação de um computador (a falta de força do motor traseira, deve-se à alta resistência que o fio apresentava quando estava totalmente esticado, daí não ter força para o motor)...

Aqui apenas se mostra o teste que fizemos ao carro para se desviar de obstáculos com recurso aos sensores, embora estes fossem capazes de detectar obstáculos até 40 cm, por excesso de IV, este estava com uma detecção a oscilar entre 10~20 cm.

Sabiam que o CPU apenas consegue somar e multiplicar? Verdade, pelo menos aqueles que usei apenas tinham opcode (código que indica ao CPU o que deve fazer com a instrução que recebeu) para adicionar (ADD) e multiplicar (MUL). Para realizar outras operações, o utilizador terá de as programar! Daí hoje não termos de programar em linguagem máquina, pois o GCC (isto se estiver a usar C/C++) já faz isso pelo utilizador.

[Claudio Novais]

Mas acho que fora da terra as coisas mudam muito, não? Para além de terem de ter muitos mais sensores de diferentes tipos, tinham de estar preparados para um ambiente diferente e variável, visto que com a aproximação da lua as forças de atração mudam.

Mas, certo, esse exemplo mostra bem que pouca capacidade e consegue resolver problemas!

[Luis Cardoso]

Mas acho que fora da terra as coisas mudam muito, não? Para além de terem de ter muitos mais sensores de diferentes tipos, tinham de estar preparados para um ambiente diferente e variável, visto que com a aproximação da lua as forças de atração mudam.

Mas, certo, esse exemplo mostra bem que pouca capacidade e consegue resolver problemas!

Se apenas tiveres o código necessário a correr, não haverá problemas, mas se lhe adicionares um DE, a coisa fica muito complicada, foi por isso mesmo que o nosso grupo apostou nesta topologia, tornou a coisa bem rápida. Fizemos um outro teste mas aí não gravei (pois, era eu que estava a filmar ), usando apenas a bateria, o carro andou pelos corredores e só parou, porque ao fazer uma curva a bateria saiu projectada com a rapidez com que o carro fez a curva (o que nos fez correr nesse dia...)!

Sim a panóplia de sensores seria sensivelmente maior. Quanto a aproximação, etc... O sistema vai calculando com base no que chega ao CPU, até porque os sensores não estão constantemente a enviar dados, ou por outra, até podem estar, mas o CPU só sabe o que lê em determinado instante! O mesmo acontece com os nossos computadores, ou achavas que o controlador da MotherBoard andava sempre a ler os sensores? Ele vai correr todos os sensores de x em x tempo! Pode por exemplo, ler os dados dos sensores a cada 1ms, que foi o que nós fizemos e era mais que suficiente (tem em conta que o carro podia dar até 30km/h).

E tendo em conta que andavam pelo "desconhecido", é boa prática usar as leis da física e não assumir como padrões deste ou daquele sítio. Devia ter algum sensor que indicava certos parâmetros que ajustavam as fórmulas da física de forma a lidar com a situação do momento!

[Claudio Novais]

Lá está é aí que eu queria chegar, às aproximações físicas! No momento da aterragem os sensores provavelmente deveriam estar a funcionar a um nível de atualizações considerável e ao mesmo tempo a fazer aproximações das fórmulas algo que mesmo não exato através de métodos numéricos gasta processamento. Algo que pode ser exagerado para um hardware daquela altura, não? É principalmente neste aspeto que me refiro das dúvidas da capacidade do hardware!

[Luis Cardoso]

Lá está é aí que eu queria chegar, às aproximações físicas! No momento da aterragem os sensores provavelmente deveriam estar a funcionar a um nível de atualizações considerável e ao mesmo tempo a fazer aproximações das fórmulas algo que mesmo não exato através de métodos numéricos gasta processamento. Algo que pode ser exagerado para um hardware daquela altura, não? É principalmente neste aspeto que me refiro das dúvidas da capacidade do hardware!

A taxa de atualização é sempre a mesma...

Quanto a precisão dos cálculos, tendo em conta a velocidade, o resultado bem podia vir com inteiros, pois as casas decimais de nada serviam Convém lembrar que o CPU desenhado na Terra com a frequência de 3MHz, terá um comportamento semelhante a 300MHz no espaço!
Não te esqueças que a aeronave, tendo um processador de 8 bit, pode ter até 256 sensores, pois o CPU consegue endereçar 2⁸ = 256:

Código: Selecionar todos

000: [0000 0000] → Sensor 0
001: [0000 0001] → Sensor 1
.
.
.
254: [1111 1110] → Sensor 254
255: [1111 1111] → Sensor 255

Eu até acho que já é muito sensor...

[Claudio Novais]

ui, 300Mhz no espaço 3 Mhz?

[Luis Cardoso]

ui, 300Mhz no espaço 3 Mhz?

Pois, não há certos fatores que se encontram na Terra. Aliás, no espaço, o CPU tem de ser aquecido, na Terra tem de ser arrefecido!