ASM51

Alguem pensou nisto ?
É coisa do CAPETA

Mais facil refazer o codigo nao? E se for com Linux completo, acho mais facil portar um programar de PC do que um embarcado.

tcpipchip escreveu:Alguem pensou nisto ?
É coisa do CAPETA

hard ou soft real time?

Se for soft-realtime, é basicamente substituir o semáforos, queues, mutexes, etc pelo padrão POSIX

juro que estou me esforçando, mais não consegui entender ,,,,

Portar um RTOS para o linux ? como assim ?

mastk escreveu:Mais facil refazer o codigo nao? E se for com Linux completo, acho mais facil portar um programar de PC do que um embarcado.

Pois é, mas RTOS tradicional é geralmente baseada em uma modelo de memória plana. Todas as aplicações, juntamente com o núcleo são parte de uma única imagem que é então carregado para o alvo.
Serviços do kernel, como schedulers, timers, e outros, são executado no mesmo espaço de endereço físico como aplicativos do usuário.
As aplicações solicitam qualquer serviço do kernel usando um simples interface de chamada de função. Aplicações do usuário também compartilhar espaço de endereço comum entre si.
Por ser plana, sem MMU, qualquer usuário aplicação pode danificar o código do kernel ou de dados ?
Tem como proteger o código (PROCESSO e suas THREADS) no RTOS?

TCP, você está certo. É coisa do capeta.

Mas é possível, você só precisa de uma pena, uma gota de sangue e um pentagrama.

pbernardi escreveu:TCP, você está certo. É coisa do capeta.

Mas é possível, você só precisa de uma pena, uma gota de sangue e um pentagrama.

pessoal, ninguém vai me responder sobre portar um rtos para o linux ?

Nossa, cada coisa... O SO propriamente dito, são os códigos que fazem o tratamento de tudo...

tcpipchip escreveu:Alguem pensou nisto ?
É coisa do CAPETA

Xenomai?

fabim escreveu:

pbernardi escreveu:TCP, você está certo. É coisa do capeta.

Mas é possível, você só precisa de uma pena, uma gota de sangue e um pentagrama.

pessoal, ninguém vai me responder sobre portar um rtos para o linux ?

Nossa, cada coisa... O SO propriamente dito, são os códigos que fazem o tratamento de tudo...

mal pela resposta evasiva.

Eu sou um cara de HW puro, que mexe pouco com códigos. Mas eu sei que é possível, porque existe placa que faz isso por aqui. Mas enfim, não sei detalhes de como a bagaça foi feita, não tenho um conhecimento tão profundo a ponto de entender o assunto (que é tenso), mas sei que a associação dessa placa com o demônio já era conhecida muito antes desse post.

Pra ajudar, na época que essa placa foi feita, veio um cara da Conectiva, olhou para nossa placa, fez o pacto, inseriu o código lá dentro, e depois foi para o Inferno.... hahaha mentira. Dizem as más línguas que ele foi trabalhar na Microsoft, que talvez seja pior.

Dizem as más línguas que ele foi trabalhar na Microsoft, que talvez seja pior.

Pagando bem, eu trabalharia até como produtor de música sertaneja...

Roteiro

Divida todas as tarefas de RTOS em duas grandes categorias: tarefas do espaço do usuáro e tarefas do kernel. Por exemplo, qualquer tarefa UI (interface de Usuário) é uma tarefa de espaço do usuário e qualquer hardware tarefa de inicialização é uma tarefa do kernel. Você também deve identificar uma lista de espaço de usuário e funções do kernel. Por exemplo, a função de qualquer dispositivo que manipula registros é uma função do kernel e qualquer função que lê alguns dados de um arquivo é uma função do espaço do usuário. Duas estratégias de portabilidade podem ser adotadas.

Modelo de UM processo
Nesta abordagem tarefas do espaço do usuário do RTOS migram como segmentos separados em um único Processo do Linux. A vantagem desta abordagem é o redução do esforço de portabilidade, pois requer menos modificações no código base existente. A maior desvantagem é não proteção de memória entre threads dentro do processo. No entanto os serviços do kernel, drivers, e assim por diante são totalmente protegidos.

Modelo multiprocesso
Categoriza tarefas como tarefas independentes e relacionadas
- Tarefas Independentes: tarefas fracamente acoplados que utilizam mecanismos IPC oferecido
pelo RTOS para se comunicar com outras tarefas ou stand-alone que não estão relacionadas com outras tarefas podem ser migradas como processos separados Linux.

-Relacionados com tarefas: tarefas que compartilham variáveis globais e funções “callbacks” função falham nesta categoria. Eles poderiam ser migrados como threads separadas em um
Processo de Linux.

-Tarefas chaves: tarefas que executam atividades-chave, tais como tarefas de vigilância do sistema (WATCH-DOG) devem ser migrados como processos separados Linux. Isto assegura que tarefas chaves são protegidos de corrupção de memória de outras tarefas.

tcpipchip escreveu:

mastk escreveu:Mais facil refazer o codigo nao? E se for com Linux completo, acho mais facil portar um programar de PC do que um embarcado.

Pois é, mas RTOS tradicional é geralmente baseada em uma modelo de memória plana. Todas as aplicações, juntamente com o núcleo são parte de uma única imagem que é então carregado para o alvo.
Serviços do kernel, como schedulers, timers, e outros, são executado no mesmo espaço de endereço físico como aplicativos do usuário.
As aplicações solicitam qualquer serviço do kernel usando um simples interface de chamada de função. Aplicações do usuário também compartilhar espaço de endereço comum entre si.
Por ser plana, sem MMU, qualquer usuário aplicação pode danificar o código do kernel ou de dados ?
Tem como proteger o código (PROCESSO e suas THREADS) no RTOS?

Sim, qualquer usuario pode danificar ate o Kernel. Ate aonde eu saiba nao da para proteger um RTOS, a nao ser que sua CPU tenha alguma separacao de privelegios do tipo, SUPERVISOR e USUARIO, do 68K e mesmo asism, nao tem uma protecao contra acesso/escrita indevidos em regios distintas ao programa.

Ja a portagem, tem que pegar o que sua funcao faz e transformar isso em um programa, dependendo do nivel de abstracao que seu codigo esteja feito isso pode ser ate simples, mas em RTOS, creio que seja facil ficar mais perto do HW e ter uma rotina dificil de portar, por isso suponho que refazer seja mais produtivo.

bom, resumidamente.
não da pra portar um RTOS para o linux, pois ele não vai ser mais RTOS, pois ele vai ser manipulado pelo linux, que dependendo do cara pode transformar o kernel linux em RTOS, então pra que pegar um RTOS e cagar nele, o utilizando como uma thread prioritário ?

Em um RTOS, vc nao fica muito longe do HW, entao para um programador de embarcados, vc tem uma camada de acesso aos perifericos, mas nao esta muito longe, e como dito, nao ha limitacoes, o seu programa, vai estar rodando com outros em conjunto e pode dar m****.

Agora em um SO real, seu programa tem severas restricoes, dado que esta em cima de muitas camadas de abstracao e seu programa, tem memorias e outros recursos alcados exclusivamente para ele, o que tras uma serie de beneficios.

mastk, eu já havia entendido a questão.
É que a ideia do miguel me deixou tão confuso e sem entender porque, de fazer algo do tipo, que meu sarcasmo subiu a tona !!!

A velocidade e prioridades de um RTOS, junto com o dinamismo do linux!!
Isto é a forma incorreta de pensar!!

O linux é um so com um amontoado de scripts que acessam o hw através de device drivers, tanto lado kernel quanto usuário.
Ou seja, você sempre e sem exceção, vai ter dois níveis para o hw!! Nível lógico, e nível fisico!!

O RTOS tem o tick mais curto, e prioriza o nível físico, e pode dar paus nos níveis lógicos exatamente pelo tempo de latência inserida nos scripts lógicos!!!
EX: no linux, quando existe uma INT, o SO não vai lá direto tratar aquilo, e para no exato momento o que esta fazendo.
Ocorre uma sinalização, tempo X depois, onde o kernel salvou os contextos, fez isso e aquilo, ele vai lá na sinalização tratar o que aconteceu... Isto demora alguns mS ou uS depende da máquina.

Então o que é um RTOS ?

Bom, eu me atrevo a dizer, que RTOS, é somente uma máquina onde tudo gera interrupção, e ele vai exatamente naquele momento tratar o que a gerou, e nas threads mais baixas ele fica tratando aqueles critérios de latência alta ou desprezível...

Agora imagina você pegar estes scipts de um RTOS, e jogar no KERNEL como sendo um thread, que vai ser regido por um tick timer, com percentual de conclusão variando pela velocidade da maquina ?
Ou pior criar um driver, e jogar tudo de hw lá dentro, e criar um frame-work conversando com este driver !! Que lixo !!


Miguel para de ficar querendo sacanear a gente!! Tu ta acostumado a fazer pegadinha com seus alunos, e quer ficar envergonhando a gente !!
To estudando feito louco, e quanto eu ficar com 10% do seu conhecimento e do sam, ai vou começar a sacanear também, tu vai ver !!!