Subhilo sobre Linux, su Kernel y los drivers y su programación

Hola amigos. Debido a que mi proyecto paso a paso con el RaspBerry Pi consiste de hilos diferentes donde cada uno sigue un aspecto del proyecto espero que los administradores me permitan el crear hilos adicionales para cada grupo de temas relacionados y que no, como ha ocurrido con mi hilo sobre el RaspBerry Pi Zero estos sean cerrados y movidos. La intención es separar los temas para permitir poder seguirlos sin tener que saltar contribuciones sobre otros aspectos del proyecto. El hilo “master” seguirá siendo mi proyecto de paso a paso sobre el RaspBerry Pi e iré indicando allí la referencia a otro de los hilos para mantener las relaciones entre los aspectos del proyecto.

Para mi esta forma de proceder es aplicar una estructura al proyecto y el recibir críticas y preguntas siempre relacionadas al tema del hilo. Como por razones de salud no sé cuánto tiempo mentalmente sea capaz de seguir mis objetivos y porque el volver a leer mis propias contribuciones me ayudan a recordar y reinicializarme en la materia. Desafortunadamente, como ocurre en el caso de mis estudios y experimentos para implementar la estructura de comunicación entre mi ordenador usando “ssh” cliente y servidor y las placas Raspi, no llegue a implementar e inicializar la software para protegerla de ataques desde el Internet. El resultado es que siempre que arranco mi ordenador, después de cierto tiempo se crean un número grande de procesos conhost.exe y reg.exe *32 que bloquean totalmente mi ordenador y que recién al cabo de cierto número de horas dejan de existir. Claro está que me voy a tener que volver a meter en el tema.

En este hilo quiero compartir mis estudios sobre sistemas de tiempo real usando la placa Raspi y un Linux propietario y lo relacionado a implementar la combinación de usar uno de los núcleos del Raspi para ejecutar el Linux normal para actividades no críticas referente a su ejecución en tiempo real y que se llama “mercury” e implementar el núcleo “cobalt” que será ejecutado en un segundo núcleo pudiendo así garantizar tiempos de reacción determinísticos en el orden de algunos µsegundos. Pienso utilizar para esto mi placa RaspBerry Pi B+.
En este hilo no asumiré sólidos conocimientos de mis lectores, sino que trataré de encontrar un camino que me permita introducir a la materia a novatos como yo lo soy!

Voy a escoger la metodología de tutorial para compartir la información que voy ganando.
El objetivo del hilo es convertir Linux de ser una “caja negra” a ser una herramienta que uso para realizar mis diversos objetivos.

Quiero mencionar, que debido a los problemas que tenía en mi PC originadas por no implementar las barreras contra infiltraciones desde el Internet me decidí actualizar mi PC y poner Windows 10. Me considero compensado por haber tomado el riesgo de la actualización del os. Los problemas han desaparecido, por ahora!

Finalmente también me llego el libro sobre el programar de “drivers” y del “Kernel” de Linux que incluye referencias para aplicar los conocimientos a las placas Raspi, incluyendo el Raspi 2B. El 3B que ahora está disponible y del que tengo una placa va a requerir ciertos cambios, pero aquellos cambios entre por ejemplo la B+ y la 2B dan indicación de cómo será la adaptación al 3B.

La literatura que uso asume el uso de Ubuntu como sistema “host”, por lo que voy a cargar en mi PC como segundo sistema operacional Ubuntu. Escaneando el libro sobre programación de drivers y del Kernel he visto que el material incluye las instrucciones de cómo hacer tales programaciones de forma local en la placa Raspi y como el de hacer la programación en forma de “cross-desarrollo”, lo que significa usar las herramientas en el entorno del PC con Ubuntu y transferir el código generado para la ejecución en la placa Raspi 3B. Uso la placa Raspi 3B para tener el entorno más poderoso posible en el entorno del Raspi

Quiero empezar siguiendo las secuencias usadas en el libro y por lo tanto empezar con definir los términos a usar y de presentar el entorno que representa Linux y los conceptos relacionados con la funcionalidad con énfasis en Linux y su Kernel. Porque malas lenguas en ciertos foro ya me han echado el chisme que me siento superior a otros foristas, aquí quiero poner las bases:

Yo soy un aprendiz, lo que incluye que voy a tomar muchos caminos equivocados, que en el transcurso de los temas de este hilo voy a ir, si Dios y mis capacidades mentales lo permiten, adquiriendo una “vista” ojalá cada vez más amplia que pueden refutar percepciones expresadas antes. Aquí en el foro existen individuos que realmente saben de la materia y pido perdón por la forma inmadura que iré compartiendo mis intentos de aprendizaje! En suma, como aprendiz peco de la arrogancia de meterme y confrontarme con estos temas. Pero a la vez estoy consciente que probablemente sea inferior en mis capacidades a muchos. Si presento conceptos y términos, sea usando el vocabulario erróneo, o sea que son trivialidades para el lector de este hilo, mi intención es crear una plataforma de conocimientos, términos la cual compartiremos en la aventura!
 
Este post no aporta nada sobre el tema
Pero si quisiera con el, dar apoyo , ya que siempre desarrollas con tu aportación gran ayuda a topes como yo que no saben donde esta la mano derecha y en consecuencia se pierden en el intento
Sigue dándonos un poco de luz
 
Gracias. Ayer intenté a la rápida instalar ubuntu y me presentó con opciones sobre las cuales debía hacer decisiones y de tomarlas soy incapaz, ahora! La razón que en mi primer contribución escribí mucho sin realmente contribuir al tema fue para permitir a Ustedes mis lectores entender porqué estoy iniciando este "subhilo" y tratando de dar una perspectiva sobre lo que estoy empezando a hacer! El hilo sobre el Raspi Zero me fue cerrado y movido, por lo que creo que debo justificar mi proceder. Los moderadores cumplen la importante función de evitar que el hilo vaya por malos caminos por lo que creo merecen y se justifica dar explicación!
 
La programación de drivers en Linux es un tema muuuuuy interesante, pero hace falta un buen libro (que pareces haber comprado) que explique la "filosofía" y técnica de programación, por no es un programa "normal" en C sino que tiene algunas cosas raras que cuando lo entiendes se hacen muy naturales, pero no es simple de ver si no has programado interacción con el hardware y con otros módulos de software.

Yo diseñé un driver para un kernel muuuy viejo (2.2) con el objeto de conectar un ADC de 8 canales al puerto paralelo y usar el soporte del propio driver del puerto paralelo para conformar el acceso al ADC evitando tener que manejar desde cero el hardware del puerto.
Funcionó muy, pero muy bien, y la interfaz de acceso al ADC quedó escondida tras un conjunto de 3 o 4 funciones en C de alto nivel que permitía un uso simple e intuitivo.
 
Dr. Zoidberg, lo que escribes es totalmente correcto! Aquí si no mal recuerdo se usan los Kernel 4.x y del Raspi 4.03. Con la intención y con la obligación que me dado con este hilo estoy leyendo en "diagonal" unos subcapítulos del libro para poder tener la chance de poner las cosas que presentaré en contexto! Tu contribución me dice que realmente tiene mucho sentido el presentar el "pegamento" que el autor presenta para poner las informaciones en contexto! Pero tal cual siempre es, presentar algo requiere estudiar la materia y lo que llamas la filosofía es algo que he visto el autor presenta por todo el libro. El autor muy claramente dice que lo que presenta es, por usar tu término "filosofía" para poder entender e interpretar las informaciones que van por encima del objetivo del libro y que se encuentran en el código del kernel disponible y de las informaciones que aparecen en diversos sitios que va indicando en el Internet. Por decirlo de otra forma. El presenta la base teórica y los conceptos primero, para luego mostrar como realizar ejemplos y finalmente dando "templates" que sirven como punto de partida y marco de la implementación de los ejemplos y que finalmente lo capacitan a uno escribir sus propia software para integrar en el kernel y su entorno donde corresponda. Pero favor tener paciencia que mi aprendizaje y estudio no es de la velocidad de un estudiante joven universitario. Yo mismo tengo que combatir mi urgencia de empezar a codificar cosas en el Raspi. Muchos de los conceptos los conozco de mi pasado profesional, pero el/los libros lo ponen en contexto y lo aplican en la "filosofía! Si alguien quiere algunos datos por adelantado con gusto me esfuerzo por dar informaciones sobre la filosofía y la lógica del kernel y su entorno pero solo por MP para aquellos que ya están mucho mas adelantados. Así ojalá pueden contribuir y/ corregir errores que cometa!
 
Tal vez mi comentario sobre el asunto de crear “drivers” para un sistema operativo informático pueda resultar un tanto escueto ya que desde mis inicios, hace ya 38 años, el mayor logro fue controlar un simple led vinculado a un sencillo switch que por software (interprete del lenguaje basic) pudiera establecer su estado; Antes de eso, obvio tuve que entender como eléctricamente se formaba el intrínseco vínculo entre ese switch y ese led. Recuerdo muy cercanamente que a mis 10 años de edad, cuando mi padre con una batería, el switch y los cablecitos que conformaban ese sencillo circuito me enseño como controlar la luz de ese Led y casi 6 años después le mostré muy entusiasmado a mi padre; ¿Ya viste que ya puedo controlar al Led desde la computadora? Y su respuesta fue… ¿Y? definitivamente mi padre no entendió el dogma revelado que tenía en mis manos.

Hoy en día, sigo viendo la cara admirada de sobrinos, amigos, gente de toda índole, cuando a través de un Arduino les muestro como tener control de un led con el conocido programa de “BLINK”; obviamente ellos no tienen idea de todo el camino sufragado para poder hacerlo tan fácil "aparentemente", puesto que se requiere tener una computadora de alto nivel, un sistema operativo, la interface de desarrollo de software/hardware y muchas otras cosas para poderlo lograr, sin embargo nunca me he tomado la molestia de hacercelos comprender.

Por estas razones considero que si es muy importante establecer un tema específico sobre como tener control de las prestaciones “físicas” de una PC (Linux, Windows) para tener control de sus salidas/entradas desde un IDE de desarrollo común que sirva para explotar los procesadores que tenemos en mano y que seguramente podrán establecer el entendimiento a ese “dogma” que tempranamente me permitieron desarrollarme y que ahora prácticamente en el retiro; sigo disfrutando.

En otros “temas” de nuestro querido foro me he manifestado, tal vez malamente, en que no comprendo el entusiasmo de controlar un arduino desde un raspberry, convertir un Microcontrolador PIC de 8 bits en WEB server y otras muchas cosas más, siendo que desde una PC (sistema operativo) ya se tiene todo lo necesario y que sí se tiene conocimiento de ese dogma al que me refiero; entonces si se puede aprovechar todo el poder que hoy tenemos en mano. Tan poco dejo de ver el poder de tener un raspberry o todos esos sistemas embebidos con todo un sistema operativo en una electrónica tan pequeña en sus dimensiones físicas.

¡La cosa es saber lo grande que se tiene en tan pequeñas dimensiones!

En verdad es necesario crear un tema actual sobre como controlar un led con Ubuntu 14.0, Windows 10 para poder pasar al tema de moda de hoy: el IOT (Internet de las cosas)

Les dejo un saludo cordial saludo.
 
Me alegro de leer el apoyo e interés que tiene el tema. Como muchas cosas de la electrónica y de circuitos digitales y computadores, el principio no es que sea difícil, pero hay que concientizarse de un gran numero de términos. Una vez que se ha logrado la meta de tener un primer entendimiento del significado y la función detrás de tales términos viene otro reto que Dr. Zoidberg muy bien nombro "filosofía". Como es frecuentemente, existen muchos caminos para llegar a Roma. La "filosofía" del Kernel y su interacción tanto con las aplicaciones, como por "drivers" a la "hardware", requiere entender que camino hacia Roma la comunidad de desarrollo del Kernel ha escogido. Entendiendo esa filosofía y el entorno dentro del Kernel permite "saber" el porque de la forma como se implementa algo en el Kernel. Creo que es de gran ayuda, cuando viene el tedioso estudio de los términos y de los métodos, que habiendo adquirido esto vamos a empezar a aplicar esto a nuestras placas Raspi! En paralelo al estudio del libro sobre la programación del Kernel y de sus drivers, se llama:

A: "Linux-Treiber entwickeln, Eine systematische Einführung in die Gerätetreiber- und Kernelprogrammierung", traducido literalmente:
"Desarrollo de drivers para Linux. Una introducción sistemática en la programación de "Drivers para "devices=periferia?" y del Kernel" en la cuarta edición.

B: "Embedded Linux, aprender usando el RaspBerry Pi"

El tercer libro de la trilogía que el profesor "Jürgen Quade" ha publicado, doy un enlace para poder saber de quién hablo, se llama:

C: "Moderne Realzeitsysteme kompakt", "Sistemas de tiempos reales, compacto"! El libro estrictamente no contiene mas que presentar los términos que se presentan en el entorno de sistemas reales y de presentar sus funciones. Confieso, aunque estoy familiarizado con quizá el 95% de los términos y conceptos presentados allí, pone estos términos y los métodos asociados con ellos en contexto y que aún voy a estar mirando en ese libro una y otra vez.

El libro que presenté bajo el punto "B: " tiene la ventaja de poder realizar algo en corto tiempo. El encontrar un camino que permita aplicar las cosas que se van aprendiendo en la plataforma "Raspi" y en el os "Ubuntu" instalado en paralelo al Windows en mi P permite verificar que lo entendido funciona en la realidad.

Así mis contribuciones al hilo iran saltando entre el contenido de estos 3 libros de forma equivalente a como piensa progresar en la materia.

Creo que estas contribuciones iniciales en este hilo son importantes para que todo forista eventualmente interesado en la materia sepa en que se está metiendo. Desafortunadamente no conozco libros similares en español, lo que se explica que aún no se en detalle que contienen los libros que uso en alemán!
 
La programación de drivers en Linux es un tema muuuuuy interesante, pero hace falta un buen libro (que pareces haber comprado) que explique la "filosofía" y técnica de programación, por no es un programa "normal" en C sino que tiene algunas cosas raras que cuando lo entiendes se hacen muy naturales, pero no es simple de ver si no has programado interacción con el hardware y con otros módulos de software.

Yo diseñé un driver para un kernel muuuy viejo (2.2) con el objeto de conectar un ADC de 8 canales al puerto paralelo y usar el soporte del propio driver del puerto paralelo para conformar el acceso al ADC evitando tener que manejar desde cero el hardware del puerto.
Funcionó muy, pero muy bien, y la interfaz de acceso al ADC quedó escondida tras un conjunto de 3 o 4 funciones en C de alto nivel que permitía un uso simple e intuitivo.

Te hago una consulta, ¿existe alguna forma de tomar el control de un DMA a un GPIO mediante un driver?

Suponiendo el caso de un ADC que trabaja a una frecuencia muy alta y colgarlo directamente de esos GPIO (con DMA).
 
En una PC podes apuntar los DMA a una zona de memoria donde este mapeado el periferico que desees usar de este modo, y con un poco de logica de handshake podes hacer que el ADC se dispare y luego que el DMA se lleve el resultado.
Para hacer lo mismo con un GPIO en un micro este debe estar accesible en memoria y no el subsistema I/O aislado y debe poder conectarse a las lineas de handshake del DMA para señalizar el inicio de la transferencia.
En la arquitectura de los ARM no tengo idea como funciona, pero la vieja serie 80C196Kx de Intel ya lo tenia previsto en el hardware/microcodigo, y si configurabas algunos registros le podias decir que iniciara las conversiones AD, que guardara los resultados en memoria, que parara luego de numero de muestras y que mandara una interrupcion para avisarte que estaba listo... digamos... lo mismo que un DMA pero en forma muy simple...
Por supuesto que usando un driver podes hacerlo... es mas, casi que no hay otra forma de tocar ese hardware.

Fijate acá: https://lwn.net/Kernel/LDD3/
 
Última edición:
Hola amigos, me estoy dirigiendo a ustedes usando mi PC con el Ubuntu 15.10. Responder a sus preguntas no seré capaz hasta después de aprender mucho. Como para programar mis placas Raspi con Python desde el PC me compré una licencia del IDE PyCharm, hoy aprendí que esa licencia también me habilita usar la IDE en el entorno de Ubuntu.
Lo que no he podido realmente encontrar es la información donde instalo la IDE de PyCharm. En algún futuro también adquiriré una licencia de la IDE de Jetbrains para C/C++. Aparentemente programas propios se instalan en "usr/local". Pero mirando allí no me encuentro con los compiladores ya existentes de C y C++ por ejemplo, o de Python. Donde es de acuerdo a las usanzas de Linux el lugar correspondiente?
También he investigado como es lo de las actualizaciones automatizadas, lo que ocurre por ejemplo si descargo e instalo programas des el "Ubuntu Software-Center". Desafortunadamente allí solo se encuentra la versión "Community" que es gratis y no la versión "Professional" que requiero y poseo si quiero usar la funcionalidad de "cross-platform" desarrollo.
Algo he empezado a investigar de como funcionan los mecanismos en Linux en referencia a diversos "tipos" de versiones de programas, algo relacionado con el estado de las versiones.
 
...
Lo que no he podido realmente encontrar es la información donde instalo la IDE de PyCharm. En algún futuro también adquiriré una licencia de la IDE de Jetbrains para C/C++. Aparentemente programas propios se instalan en "usr/local". Pero mirando allí no me encuentro con los compiladores ya existentes de C y C++ por ejemplo, o de Python. Donde es de acuerdo a las usanzas de Linux el lugar correspondiente?

/usr/share/local/
/opt/

puede instalarse en una subcarpeta en donde ejecutaste el script de instalación .sh (si es que se instaló de esa forma).
en el home ya sería más raro, aunque puede estar ahí una carpeta oculta que empieza con "." y en donde se guarden archivos de configuración y preferencias de usuario. Si es un IDE probablemente en el home estén los archivos del workspace (si es que usa algo parecido a un workspace).

Si conocés el nombre del ejecutable en un terminal tipea:
whereis NombreDePrograma
y te devuelve la ubicación del ejecutable.

...
También he investigado como es lo de las actualizaciones automatizadas, lo que ocurre por ejemplo si descargo e instalo programas des el "Ubuntu Software-Center". Desafortunadamente allí solo se encuentra la versión "Community" que es gratis y no la versión "Professional" que requiero y poseo si quiero usar la funcionalidad de "cross-platform" desarrollo.
Algo he empezado a investigar de como funcionan los mecanismos en Linux en referencia a diversos "tipos" de versiones de programas, algo relacionado con el estado de las versiones.

Sí, el software manager de Ubuntu solo reconoce actualizaciones de programas que están en los repositorios. Y los repositorios tardan unos meses en cargan la versión del programa que salió hoy, porque se privilegia la estabilidad del software (a no ser que se trata de una actualización de seguridad).

Seguramente para la versión paga debe haber un repositorio, que lo tendrás que agregar a la lista de repositorios del ubuntu, desde el Software center/gestor de actualizaciones o incluso desde el synaptic package manager (settings -> repositories en este ultimo). O también con línea de comandos:
https://help.ubuntu.com/community/Repositories/Ubuntu
La url del repositorio debería darlo la empresa proveedora del software.
Puede ser que no tengan un repositorio y que la actualización se realice desde el propio programa.
 
En una PC podes apuntar los DMA a una zona de memoria donde este mapeado el periferico que desees usar de este modo, y con un poco de logica de handshake podes hacer que el ADC se dispare y luego que el DMA se lleve el resultado.
Para hacer lo mismo con un GPIO en un micro este debe estar accesible en memoria y no el subsistema I/O aislado y debe poder conectarse a las lineas de handshake del DMA para señalizar el inicio de la transferencia.
En la arquitectura de los ARM no tengo idea como funciona, pero la vieja serie 80C196Kx de Intel ya lo tenia previsto en el hardware/microcodigo, y si configurabas algunos registros le podias decir que iniciara las conversiones AD, que guardara los resultados en memoria, que parara luego de numero de muestras y que mandara una interrupcion para avisarte que estaba listo... digamos... lo mismo que un DMA pero en forma muy simple...
Por supuesto que usando un driver podes hacerlo... es mas, casi que no hay otra forma de tocar ese hardware.

Fijate acá: https://lwn.net/Kernel/LDD3/

Se me pasó de largo este mensaje, gracias por el material, estaba buscando algo así. (y)
 
Ayer moví la carpeta de instalación PyCharm a /home/hellmut1956/ y el resultado fueron:

Las carpetas:
pycharm-20161.2
bin/pycharm y
PycharmProjects

En la segunda carpeta econtre el archivo "test.py" que generé ayer. Pero no logro volver a ejecutar la pycharm IDE. Ahora no ejecuta pycharm IDE! A ver a que se debe esto!
 
Ayer moví la carpeta de instalación PyCharm a /home/hellmut1956/ y el resultado fueron:

Las carpetas:
pycharm-20161.2
bin/pycharm y
PycharmProjects

En la segunda carpeta econtre el archivo "test.py" que generé ayer. Pero no logro volver a ejecutar la pycharm IDE. Ahora no ejecuta pycharm IDE! A ver a que se debe esto!
no se entiende nada

pero en linux los ejecutables solo se ejecutan si estan en un directorio que este especificado en la variable PATH
 
Finalmente pude instalar PyCharm correctamente bajo el directorio "/opt/" trabajando desde la terminal usando la instrucción "sudo" para tener la autorización de hacerlo. Ademas puse el programa PyCharm en la barra de aplicaciones en el desktop! Una de las causas de mi problema fue en hacer la instalación desde el "GUI", donde no tengo los derechos de "superuser"! Ya desde la terminal pude poner las instrucciones.
Fue un buen ejercicio para familiarizarme con la estructura de archivos de Linux y del impacto de las autorizaciones.
 
Me miré el libro sobre el escribir de drivers para Linux, posible leerlo de forma gratuita, data del 2005. La próxima edición está anunciada para 2017. Mi enlace es solo uno mas y no implica el menos valorar tu enlace! Díos me salve, quién fuera para valorar esto en vista de un real experto como eres tu, Dr. Zoidberg. para prevenir malentendidos! Esto lo escribo creyendo lo que escribo!

Mientras busco aliento y motivación para seguir los trabajos de mi panel me he puesto a investigarel asunto de la herramienta "Make". Aprendí que hay aparentemente 3 tales herramientas, siendo "Makefile" una de ellas y siendo "CMake" laherramienta correspondiente que usa la IDE de Jetbrains, "CLION". Como pienso usar la IDE CLION y esta usa CMake estoy empezando a estudiar "CMake".

Encontré en YouTube un tutorial, del que desafortunadamente no me guardé el enlace, que presentó el concepto elemental de la herramienta Make.

Básicamente, si lo entendí bien, basa en lo siguiente:

1. Recursivamente describe como se crea por ejemplo un programa ejecutable:

Luego viene el renglón de gcc++ .. que genera este partiendo de archivos "*.o" y que como resultado genera el programa ejecutable.

En el siguiente renglón parte de los archivos "*.cpp, *.h, *.c" y genera los objetos "*.o" que usamos en el renglón anmterior.

Si la herramienta "Make" registra que algún archivo ha sido actualizado, esta herramienta monitorea, entonces ejecuta la compilación solo sobre aquellos objetos que han sido actualizados desde la última vez que se ejecutó la herramienta "Make".

Si un proyecto consiste de un gran número de módulos de software, entonces el tiempo para generar una nueva versión del ejecutable es reducida al máximo posible limitándose a "tocar solo aquellos objetos que fueron actualizados.

Pero también para un programa corto le ahora al programador tener que volver a entrar las instrucciones con todos los parámetros, cosa que puede resultar en errores tipográficos.

Pero también puede ver que la herramienta como "Make" por ejemplo tiene sus propias "instrucciones" del tipo "#..." y que requiero leer los manuales para conocerlos y aprenderlos.

Encontré en Amazon un libro extenso que trata "make", pero como lo que usaré es "CMake", tendré que buscar y aprender los conocimientos equivalentes en otra parte.

La IDE "CLION" genera el archivo de "CMake", "CMakeLists.txt" basándose en los datos que conoce del proyecto. Así me iré familiarizando. Aquí un enlace a un tutorial de "CMake"!

Para todos aquellos "expertos" en la programación de "C" y "C++" seguro que resulta absurdo que me dedique a saber que demonios es "Make". Dos de las razones por las cuales he evadido realmente programar en "C" o "C++" son:

1. Mi incapacidad de establecer una tal llamada "toolchain" por ser falto de demasiada información!

2. Mi total ignorancia sobre como funciona "Make".

Quizá uno que otro de mis apreciados lectores comparta mis limitaciones o parte de ellas y así estas contribuciones tienen alguna utilidad.
 
Última edición:
Me miré el libro sobre el escribir de drivers para Linux, posible leerlo de forma gratuita, data del 2005. La próxima edición está anunciada para 2017. Mi enlace es solo uno mas y no implica el menos valorar tu enlace! Díos me salve, quién fuera para valorar esto en vista de un real experto como eres tu, Dr. Zoidberg. para prevenir malentendidos! Esto lo escribo creyendo lo que escribo!
Noooooo Hellmut!!!! No hablo de menospreciar nada!!!!
Solo lo puse por que el link que presentaste es muy básico como para entender el funcionamiento y operación de los DMA en el kernel Linux... pero nada mas que eso. Tu link dá una visión muuuuuy global de las funciones del kernel para gestión de los DMA, pero el LDD dá una imagen mucho mas profunda de para que se usan esas funciones y datos y algunos ejemplos de código de aplicación (y)

Mientras busco aliento y motivación para seguir los trabajos de mi panel me he puesto a investigarel asunto de la herramienta "Make". Aprendí que hay aparentemente 3 tales herramientas, siendo "Makefile" una de ellas y siendo "CMake" laherramienta correspondiente que usa la IDE de Jetbrains, "CLION". Como pienso usar la IDE CLION y esta usa CMake estoy empezando a estudiar "CMake".
Andá despacio con esto. Los IDE usan CMAKE (internamente) pero por lo general vos no tenés que saber nada de esta herramienta. Los IDE generan los archivos de configuración de CMAKE al vuelo, y este genera - a partir de esos archivos - los Makefiles nativos en base a lo que el IDE les dice.

Encontré en YouTube un tutorial, del que desafortunadamente no me guardé el enlace, que presentó el concepto elemental de la herramienta Make.
.
.
.
2. Mi total ignorancia sobre como funciona "Make".
.
Si lográs dominar el comando Make te juro que voy a Alemania a alabarte...
:alabanza: :alabanza: :alabanza: :alabanza:
:alabanza: :alabanza: :alabanza: :alabanza:

Naaaaa... no tenés que saber nada del Make. Si el IDE es bueno, vos hacés "click" en el ícono de compilación y el IDE corre el Make por vos sobre el makefile que generó el CMake y te informa los resultados del proceso. Si querés aprender a escribir Makefiles.... te aviso que son un despelote muy importante... con cosas como que si te sobra un espacio en blanco o identaste mal una línea, te llena de errores que ni se entienden :confused: :confused: :confused:... en fin... un gran lío.

Mejor confiá en lo que haga el IDE y listo ;)
 
Gracias por tu respuesta. Hay gente que por fomentar el uso de electrónica en el modelismo naval y compartir los esfuerzos que hago andan hechando el chisme que dizque me considero superior a los demas foristas navales!
Sobre lo que escribes de "make" y de las IDEs en parte me tranquiliza. En el pasado traté de compilar programas en "C" no usando una IDE, sino compilando directamente. Total fallo! Eso fue un importante factor para decidirme usar los controladores de NXP y en ese contexto las placas LPCXpresso. En esacombinación NXO ofrece la IDE gratis, es mas usando la IDe en combinación con una de las placas LPCXpresso, la IDE "conoce" la placa y se configura deacuerdo a ello.
Ahora el paso a tratar de aprender cosas básicas sobre Linux, su Kernel, el escribir drivers, lo de la parte del Kernel llamada "Mercury" para ejecutar Linux "normal" y "cobalt en una core que se reserva para ello implementar la funcionalidad de sistema de tiempo real volvió a sacar a flote esas experiencias mías con "C" y "C++". El libro sobre el "desarollar Drivers para Linux usando el Raspi va a pasitos "sencillos" y eso en combinación con "CLION de Jetbrains me dio aliento para tratar y meterme en el tema. Tus respuestas me dan aliento adicional. Gracias!
 
Atrás
Arriba