mastk escreveu:Na medida que consegue resolver as coisas bem dessa forma, é a sua realidade, há que use RTOS por preguiça e/ou ignorância e/ou pelo o que já investiu neles, ainda assim na medida que se consegue ser produtivo está bom. Para mim, por uma questão de responsabilidade, acho perigoso usar muito código que não tenha controle.
nao eh questao de preguica, ignorancia ou investimento. depende do nivel de complexidade e o que tenho visto nos ultimos anos eh o seguinte:
1) ambiente monotarefa: caso em que apenas uma aplicacao precisa rodar de cada vez. vc pode ateh formalizar um sistema operacional, mas ele vai ser muito simples, quase que no estilo msdos ou cp/m. pode ateh ter varias aplicacoes, mas elas vao rodar de forma sequencial e nao concorrente, ou seja, uma aplicacao tem q terminar para outra poder iniciar, ou seja, o nivel de complexidade e organizacao eh quase zero. a maioria dos boot loaders e firmwares basicos funciona dessa forma. por exemplo, um firmware basico pode iniciar com a sequencia de tarefas: self-test, update e uma aplicacao de controle de motor.
2) ambiente multitarefa: caso em que varias aplicacoes precisam rodar concorrentemente. vc tem que formalizar um sistema operacional, por mais simples que seja, pois precisa gerenciar multiplas tarefas concorrentes, no estilo UNIX. ou seja, elas vao rodar concorrentemente e independentemente uma da outra, o q requer bastante organizacao e complexidade: vc precisa gerenciar processos, gerenciar memoria e fazer os processos se comunicarem entre eles. aqui vc tem uma serie de opcoes, variando dos RTOS mais basicos aos UNIXes mais avancados. por exemplo: um RTOS poderia rodar concorrentemente varias aplicacoes de controle de motor.
note que normalmente o self-test e update eh feito por um firmware em ambiente monotarefa, para soh entao rodar um RTOS ou UNIX. poderia fazer o self-test e update como tarefas de um RTOS, mas eh meio complicado. o normal eh parar o sistema para fazer essas coisas e fazer em um ambiente mais simples. eventualmente, se te pagarem o suficiente por isso, vc pode implementar self-test e update q funcione com o sistema rodando concorrentemente. nao eh facil, mas eh possivel.
mas onde entra o linux na historia? bom, generalizando: se vc tem necessidade de rede, eh quase certo que vc precisa de um UNIX-like como o linux. vc pode ateh usar um RTOS qualquer, mas convenhamos, o suporte a redes eh realmente muito fuleiro quando vc compara com o historico de 40 anos do UNIX. e nao estou falando necessariamente do linux, bem pq as coisas podem escalar conforme a necessidade. se vc precisa apenas de suporte a rede, como um cliente dhcp, um servidor snmpd (vc pode controlar motores via snmp!) e coisas do genero, acredito que um uclinux pode dar conta tranquilamente, pq nao eh algo que vai destruir o processador ao ponto de requerer uma MMU. talvez ateh um RTOS como o vxworks quebre o galho, mas para que sofrer com um snmpd para vxworks se vc tem n opcoes de snmpds que funcionam no uclinux? tem o source, tem documentacao, tem suporte facil, etc... nao questao de preguica, ignorancia ou custo, mas questao de escolher a opcao mais confiavel e robusta. e se vc precisa de algo mais avancado, por exemplo, um sql server, java, php e outras aplicacoes TI-like que devastam processadores, eh quase obrigacao usar um linux que suporta MMU, em funcao da seguranca: um crash em um processo complexo nao vai derrubar o sistema. e se precisar de mais performance, pode partir para um ambiente SMP e, nesse caso, o linux vai escalar junto.
e qdo chegar nesse nivel, vc provavelmente vai ter mais opcoes: openbsd, freebsd, mach, etc. vale a pena ir um pouco alem do linux e conhecer o que mais existe. por exemplo, tem gente que fica sofrendo para fazer firewall com controle de bandwidth com linux, iptables e 500 outras ferramentas e modulos... total coisa de amador fuleiro! na real, basta colocar um freebsd com ipfw e a solucao se torna limpa, profissional e incrivelmente trivial.
