Linux rt- patch para Android de nadie?

Enlace muy importante

Investigación en curso sobre el androide en tiempo real.

http://code.google.com/edu/submissions/ncsu-rts/

Debajo de la discusión del blog vale la pena leer,

http://groups.google.com/group/android-kernel/browse_thread/thread/fbf7f94d80f5eb2c/4e9f6f4d22a40b36?pli=1

No es diferente del soporte en tiempo real en cualquier sistema Linux, ¿has mirado en el patchset de tiempo real para el kernel de Linux? Debe aplicarse a los kernels de Android sin problemas.

Dice, usted puede con éxito rt-parche de linux a androide.

BTW, Definición de la arquitectura en tiempo real es,

Un sistema en tiempo real es aquel en el que la corrección de los cálculos no sólo depende de la corrección lógica del cálculo sino también del momento en que se produce el resultado. Si no se cumplen las limitaciones de temporización del sistema, se dice que se ha producido la falla del sistema.

Por encima de la referencia de: http: //www.ibm.com/developerworks/linux/library/l-real-time-linux/

Así que, Básicamente, ¿por qué en este universo quieres aplicar rt-patch al kernel android?

Solo encontró

Este artículo vale la pena explorar, puede encontrar un enlace a seguir para su proyecto de investigación.

http://users.ece.gatech.edu/~vkm/Android_Real_Time.pdf

Si entiendo la pregunta. Usted tiene un sistema muy crítico (como el sistema de ayuda de frenado de un coche, etc.), y desea controlarlo / rastrearlo a través de un ingenioso gui creado en android (tablero)?

Creo que siempre debes dividir el sistema crítico, del gui. Eso también en un nivel de hardware. Así que puedes hacer lo que quieras en tu GUI, pero el sistema crítico nunca será influenciado (por la carga de CPU pesada para un gráfico de fantasía, etc.) porque está funcionando en su propio hardware.

Así que tendrás un sistema: el ordenador interno de los coches (como existen hoy en día), y un sistema totalmente otro: la interfaz gráfica de usuario nifty basada en Android.

La comunicación entre esas dos cosas debe ser lo más simple posible, ya hay un montón de normas para comunicarse con la computadora interna, que son en su mayoría dependientes de la marca (ejemplo: VAG com).

No sé acerca de los detalles hasta el nivel del kernel, pero supongo que desea crear una versión RT de Android.

En relación con ese deseo, creo que sólo la aplicación de la revisión de RT no significa llegar a una versión en tiempo real de Android.

Especialmente con una máquina virtual hay mucha complejidad involucrada con las pausas de recolección de basura y que evitan el verdadero comportamiento en tiempo real.

Por ejemplo, mire la especificación en tiempo real para la JVM. Tomó 8 años para conseguir de la presentación inicial a una puesta en práctica de funcionamiento real.

http://www.jcp.org/en/jsr/detail?id=1

Así que en general .. podría y probablemente es posible aplicar el parche RT, pero el resultado no hará lo que probablemente después.

Al igual que otros han dicho, no hay razón real por la que no se puedan aplicar los parches de RT y Android a un kernel de Linux. Pero si o no que es útil para usted depende de lo que usted está tratando de hacer.

No obtendrá aplicaciones Android en tiempo real con soporte API completo. Sin embargo, debería ser capaz de escribir aplicaciones nativas en tiempo real en C. Consulte la documentación para escribir actividades nativas. Sólo tendrás que tener mucho cuidado de no hacer llamadas API a Java (debido al potencial de recolección de basura, para los iniciadores) -y probablemente incluso a muchas llamadas al sistema Linux- de los subprocesos con los que tengas la intención de actuar En tiempo real. Así como cualquier sistema verdadero en tiempo real, la mayor parte del trabajo dependerá de usted.

Siempre que kernel.org vuelva a estar en línea, eche un vistazo a la wiki de RT .

Si su objetivo realmente es sólo arrancar un kernel de Android con el parche de RT, es probable que sea trivial si la arquitectura del dispositivo que ejecuta el kernel es compatible con el parche de RT. Por ejemplo, x86 está bien soportado, y creo que ARM es así.

Yo uso "trivial" en un sentido suelto; El parche RT puede no aplicarse de forma limpia a un kernel arbitrario con cambios personalizados (por ejemplo, no mainline) como el kernel de Android, pero la integración arquitectónica y de menor nivel en cosas como el control de concurrencia pueden ser algunos de los mayores desafíos. El parche RT generalmente está diseñado para funcionar con controladores arbitrarios, por ejemplo – pero otros problemas pueden existir: el parche RT toca MUCHOS subsistemas. En el lado positivo, una cantidad significativa del parche de RT se ha convertido en el kernel ascendente, lo que simplifica la tarea dependiendo de la versión bifurcada en la que se basa el kernel de Android.

Suponiendo que la arquitectura es compatible con el parche RT, se aplica con éxito a un núcleo de Android con conflictos resueltos, y las botas, su trabajo aún está lejos de ser completa. Cualquier aplicación de espacio de usuario, tal como las interfaces de usuario que se ejecutan en la parte superior de la JVM debe ser consciente de las limitaciones de tiempo, etc …

Para obtener más información sobre la construcción de aplicaciones con el parche RT, puede consultar este wiki para el patch RT: http://rt.wiki.kernel.org/ (tenga en cuenta que en el momento de escribir este kernel.org se ha reducido debido a la Reciente violación de la seguridad).

Puedes aplicar los dos parches (kernel de RT y modificaciones del kernel de Android), pero aparte del evidente trabajo duro de integrar los dos sospecho que tendrás al menos un problema conceptual – Android utiliza un sistema de bloqueos, llamado "wake locks", para Controlar cuándo ya qué nivel el sistema en el que se está ejecutando puede pasar al modo de ahorro de energía.

El problema es que los modos de ahorro de energía profunda no son en absoluto compatibles con el tiempo real duro que requiere previsibilidad.

Por supuesto, usted puede modificar los parches de Android y proporcionar una aplicación "ficticia" del mecanismo de bloqueo de la estela, sobre todo porque en un coche tiene una batería mucho más grande que su tableta promedio o teléfono inteligente, pero es algo que tendrá que abordar.

Aparte de eso, todo es integración de código y trabajo de prueba, creo.

Buena suerte

Por fin he tomado el manto yo mismo y venir con un enfoque basado en hiper visor para que Android puede soportar el procesamiento en tiempo real duro.