TODOPIC
Misceláneas - Interés General => Off Topic => Mensaje iniciado por: bitpic en 06 de Octubre de 2013, 08:47:44
-
Hola Foreros!!!
Como todos sabéis cada vez más los dispositivos están integrando Sistemas Operativos para todo tipo de aplicaciones. Los SO más usados son Linux y Android.
Dentro de estas SoC o SBC podemos encontrar algunas muy conocidas como RaspBerry Pi:
(http://www.internetdeglioggetti.it/wp-content/uploads/2013/09/351321-raspberry-pi.jpg)
La BeagleBoard:
(http://beagleboard.org/static/images/black_hardware_details.png)
Su hermana mayor BeagleBoar XN:
(http://www.liquidware.com/system/0000/3754/BeagleBoard_xM_Angle_1.jpg)
y un sin fin de tarjetas comerciales más muy potentes.
Además de estas luego hay las más "profesionales", con esto no quiero decir que las otras no lo sean, si no que hay otras que podemos integrar en el circuito impreso de nuestra aplicación:
TQMP2020:
(http://www.matrix.es/var/ezwebin_site/storage/images/procesadores-embedded-y-pcs-industriales/procesadores-embedded/modulos-embedded-propietarios/modulos-coldfire-linux-windows2/fotos/tqm2020/45607-10-esl-ES/TQM2020_product_template_main.jpg)
TQMa28:
(http://www.matrix.es/var/ezwebin_site/storage/images/procesadores-embedded-y-pcs-industriales/procesadores-embedded/modulos-embedded-propietarios/modulos-cpu-java-compatibles-con-tini2/fotos/tqma28/44605-8-esl-ES/TQMa28_product_template_main.jpg)
Carambola:
(http://shop.8devices.com/image/cache/data/8devices/NEW%20CARAMBOLA%20Module/DSC_0061-500x500.jpg)
Carambola en su plataforma de desarrollo:
(http://nut-bolt.nl/assets/carambola-dev-500.jpg)
y muchas otras más.
Todo esto es la actualidad, los microcontroladores que usamos no están desfasados ya que para algunas aplicaciones no se justifica usar un sistema operativo integrado, pero si creo que debemos dar el salto a estas plataformas que son auténticos ordenadores integrados en tarjetas electrónicas de un tamaño de una tarjeta de banco.
Iniciarse en estos sistemas no es sencillo, supone conocimientos de Linux y su kernel.
Actualmente estoy buscando información sobre estos sistemas y sobre como instalar linux en estos SoC.
Tengo una Raspberry PI con la que estoy ahora haciendo pruebas con Debian y Java y en esta tarjeta es muy sencillo instalar el Debian, pero no creo que a nivel profesional sea tan sencillo. Ojala que si, y que solo nos tengamos que preocupar por hacer la aplicación del proyecto en algún lenguaje como Java, C, C++, Phytom, etc. pero se me hace raro que sea sencillo instalar el SO en una tarjeta para uso profesional como podría ser la TQMa28.
Me gustaría saber vuestras opiniones, si conocéis este mundo, si habéis hecho alguna aplicación con algún SBC o SoC, si existen manuales y si hay algún experto en el foro que nos pueda orientar como introducirnos en este mundo.
A los administradores del foro, no soy nadie para decir esto, pero quizás podría ser interesante un subforo sobre este temario donde podamos aportar conocimientos sobre este tema tan interesante en los tiempos que corren.
Hago mi primera aportación y os dejo aquí dos cursos online sobre la Raspberry PI:
Curso RaspBerry PI Universidad de Granada (http://cevug.ugr.es/raspberry_pi/)
Curso Raspberry PI Universidad Galileo (http://telescopio.galileo.edu/curso/raspberry-pi/)
-
Algunas puntualizaciones:
* La segunda que enseñas es una beaglebone black no una beagleboard.
* Creo que confundes un poco la terminologia. La beagleboard o la beaglebone son SBC (single board computer). Por ejemplo, la TQMa28 es un SoM ó CoM (system/computer on module). Y un SoC (system on chip) no es más que el procesador.
* No creo que los microcontroladores estén desfasados. Avanzan a su ritmo: hace 5-6 años ni hubiese soñado un PIC con USB maestro, ETH o gráficos. Creo que cada uno vale para una cosa distinta.
* Si te planteas usar estas placas de forma profesional te recomiendo que tengas en cuenta la diferencia entre las placas de desarrollo y las de uso comercial. Puedes comprar todas las RPI o BBB que quieras pero no te van a garantizar una continuidad de stock ni te dan un soporte. Con las de TQ, por ejemplo, sí.
Si quieres empezar con este mundo te recomiendo que te compres una desarrollo (mejor la BBB que la RPI), te instales una Ubuntu o Fedora, un compilador cruzado, y empiezes a trastear con el kernel: cambiar la resolución de pantalla, encender/apagar LEDs, etc.
Si lo que quieres es desarrollar el hardware también te recomiendo paciencia y que tengas en cuenta que barato no es.
Un saludo y suerte!
-
Yo tengo la Raspberry y la Beaglebone black, y ambas vienen con el sistema operativo Linux precargado, también están disponibles ficheros imagen para volver a instalarlo, pero en ningún caso se hace una instalación partiendo de cero, por lo tanto la instalación es sencillísima.
En la comparativa Raspberry - Beaglebone black, cada una tiene lo suyo, Beaglebone black es más potente y tiene flash en placa, mientras que Raspberry solo puede arrancar desde tarjeta SD. Beaglebone black tiene muchos puertos, mientras que el SPIO de Raspberry creo que solo tiene 16 puertos o poco más. Lo único malo de la Beaglebone black es que no tiene decodificación de video por hardware, y eso la limita mucho en ese aspecto, por ejemplo no puede reproducir video de alta definición y sobrecarga mucho la CPU la reproducción de video con resolución DVD o inferior, porque la decodificación se tiene que hacer por software, por contra la GPU de la Raspberry si que integra decodificación de video por hardware, incluido full HD.
En cuanto a los entornos de desarrollo, bajo Linux, puedes usar Eclipse y GCC para programar en C++, no he trabajado nunca en Java, si instalas Android supongo que no tendrás más remedido que usar Java. Buena parte del post que puse hace tiempo para instalar y configurar Eclipse para STM32, te va a servir, solo tendrás que ver que paquetes o plugins necesitas para estas tarjetas.
Sobre otras alternativas de hardware, yo estoy muy pendiente, de la Parallella, una tarjeta que prometen será mucho más potente que Raspberry, con versiones de 16 ó 64 nucleos y aunque más cara de precio, es aceptable: http://www.parallella.org/board/
Otros chismes de estos que compré hace tiempo de los chinos, son el MK802, uHost y Mele, pero estos no tienen puertos de expansión, todo tiene que ir por USB, además solo ruedan Android, y aunque hay alguna versión de Linux, no reconoce la GPU, por lo que cualquier aplicación que necesite tirar del motor gráfico, no va cara al aire, como MAME, XBMC y similares, comprobado personalmente con MAME.
Aqui la Parallella, una muy buena alternativa para montar sistemas embebidos que requieran potencia, a un precio aceptable:
(http://www.parallella.org/wp-content/uploads/2013/01/BoardGen1Annotated.jpg)
-
Algunas puntualizaciones:
* La segunda que enseñas es una beaglebone black no una beagleboard.
* Creo que confundes un poco la terminologia. La beagleboard o la beaglebone son SBC (single board computer). Por ejemplo, la TQMa28 es un SoM ó CoM (system/computer on module). Y un SoC (system on chip) no es más que el procesador.
Hola manwenwe, tienes razón, confundí beaglebone con beagleboard (las prisas, no me lo tengas en cuenta :oops:)
En el segundo punto supongo que también, soy novato en este tema y todavía no conozco todas las terminologías. A lo que me refería es a CoM (Computer on Module), supongo que la diferencia entre un SBC y un CoM es que el CoM es un modulo que insertas en una placa electrónica y el SBC es toda la placa con sus periféricos.
* No creo que los microcontroladores estén desfasados. Avanzan a su ritmo: hace 5-6 años ni hubiese soñado un PIC con USB maestro, ETH o gráficos. Creo que cada uno vale para una cosa distinta.
No, no quería decir eso, de echo yo uso los microcontroladores, el ultimo proyecto con un PIC18, lo que creo que conseguir dominar esos CoM puede dar más juego a nuestras aplicaciones (Cuando digo aplicaciones me refiero a control de una maquina por ejemplo, no cosas más sencillas que solemos hacer con los micros). A demás hacer según que tipo de aplicación con un microcontrolador a veces es un poco engorroso, por ejemplo hacer una interfaz gráfica agradable (tipo Android) con un microcontrolador es una tarea ardua, en cambio con un SO sería mucho más fácil. O si quieres que tu aplicación a demás de una interfaz gráfica agradable tenga un servidor web u otras cosas, con el microcontrolador se complica (no digo que sea imposible) en cambio usar un lenguaje tipo Java, C++ u otros te hace la aplicación algo más fácil (no digo que no tenga su complicación también, pero hacer un interfaz gráfico por ejemplo en Java sobre un SO en más sencillo que con un PIC).
Además no descarto combinar los dos y por ejemplo tener algunos micros controlando algunos procesos y el CoM con SO que sea el Interfaz de Usuario y la unidad central que sincroniza todos los procesos de estos micros.
* Si te planteas usar estas placas de forma profesional te recomiendo que tengas en cuenta la diferencia entre las placas de desarrollo y las de uso comercial. Puedes comprar todas las RPI o BBB que quieras pero no te van a garantizar una continuidad de stock ni te dan un soporte. Con las de TQ, por ejemplo, sí.
Si quieres empezar con este mundo te recomiendo que te compres una desarrollo (mejor la BBB que la RPI), te instales una Ubuntu o Fedora, un compilador cruzado, y empiezes a trastear con el kernel: cambiar la resolución de pantalla, encender/apagar LEDs, etc.
Si lo que quieres es desarrollar el hardware también te recomiendo paciencia y que tengas en cuenta que barato no es.
Un saludo y suerte!
Me gustaría hacerlo en plan profesional, pero empece con la Raspberry porque la tengo más a mano, el precio es asequible, y la instalación de linux muy sencilla. Pero la idea sería pasarme a una tipo TQ.
¿Aprender a usar una Raspberry o BeagleBone te permite luego dar el salto a las TQ? ¿Viene a ser lo mismo o no tiene nada que ver?
¿Conoces alguna CoM como las TQ que me puedas recomendar y que haya bastante documentación por la red?
Gracias por tus opiniones.
Yo tengo la Raspberry y la Beaglebone black, y ambas vienen con el sistema operativo Linux precargado, también están disponibles ficheros imagen para volver a instalarlo, pero en ningún caso se hace una instalación partiendo de cero, por lo tanto la instalación es sencillísima.
En la comparativa Raspberry - Beaglebone black, cada una tiene lo suyo, Beaglebone black es más potente y tiene flash en placa, mientras que Raspberry solo puede arrancar desde tarjeta SD. Beaglebone black tiene muchos puertos, mientras que el SPIO de Raspberry creo que solo tiene 16 puertos o poco más. Lo único malo de la Beaglebone black es que no tiene decodificación de video por hardware, y eso la limita mucho en ese aspecto, por ejemplo no puede reproducir video de alta definición y sobrecarga mucho la CPU la reproducción de video con resolución DVD o inferior, porque la decodificación se tiene que hacer por software, por contra la GPU de la Raspberry si que integra decodificación de video por hardware, incluido full HD.
En cuanto a los entornos de desarrollo, bajo Linux, puedes usar Eclipse y GCC para programar en C++, no he trabajado nunca en Java, si instalas Android supongo que no tendrás más remedido que usar Java. Buena parte del post que puse hace tiempo para instalar y configurar Eclipse para STM32, te va a servir, solo tendrás que ver que paquetes o plugins necesitas para estas tarjetas.
Sobre otras alternativas de hardware, yo estoy muy pendiente, de la Parallella, una tarjeta que prometen será mucho más potente que Raspberry, con versiones de 16 ó 64 nucleos y aunque más cara de precio, es aceptable: http://www.parallella.org/board/
Otros chismes de estos que compré hace tiempo de los chinos, son el MK802, uHost y Mele, pero estos no tienen puertos de expansión, todo tiene que ir por USB, además solo ruedan Android, y aunque hay alguna versión de Linux, no reconoce la GPU, por lo que cualquier aplicación que necesite tirar del motor gráfico, no va cara al aire, como MAME, XBMC y similares, comprobado personalmente con MAME.
Aqui la Parallella, una muy buena alternativa para montar sistemas embebidos que requieran potencia, a un precio aceptable:
(http://www.parallella.org/wp-content/uploads/2013/01/BoardGen1Annotated.jpg)
Hola Planeta999 muy buenas esta Parallella. De momento con las RaspBerry voy sobrado, cuando la domine ya iré probando otras (a no ser que no me recomendéis la Rasp).
C++ lo he usado poco, pero supongo que viene a ser parecido al Java. Elegí Java por lo de la maquina virtual, te permite pasar el programa de windows a Linux más fácilmente y a parte está el Android que si no me equivoco muchas de sus aplicaciones estan hechas en este lenguaje.
De momento el lenguaje de programación es lo que menos me preocupa, ahora lo que me preocupa es saber como instalar o configurar el kernel de linux para un CoM y que CoM elegir.
Como decía ahora estoy con la RaspBerry porque ya la tengo, pero la idea es pasarme a alguna profesional que me permita en el futuro adaptarla a mis aplicaciones.
No me veo poniendo una Raspberry Pi o una BeagleBone en una maquina de las que hacemos en la empresa en la que trabajo :lol:
Lo que realmente me gustaría es poner una CoM tipo la TQ en nuestras maquinas y darle algo de inteligencia tipo telefono móvil , con menús deslizables, conexión a internet, poder acceder a las maquinas y comprobar el estado y hacer actualizaciones desde un web browser por ejemplo, etc. En definitiva actualizar mis conocimientos y darle un toque más moderno a las maquinas.
Actualmente para el control usamos tarjetas electrónicas con microcontrolador y pantallas LCD de lineas o graficas, pero el aspecto que dan ya queda un poco anticuado, quiero dar un paso más y darle un aspecto mucho mejor.
En alguna ocasión si he usado algún PLC con windows CE y el aspecto es mucho más agradable, solo que este tipo de PLC tiene un coste muy elevado.
-------------------------------------------------------------
Después de escuchar vuestras opiniones tengo un poco más claro por donde ir, la idea está en tirar para los CoM tipo TQ.
Como pasa en los microcontroladores habrán muchos tipos de CoM y tienes que elegir el que mejor se ajusta a tu aplicación, no os voy a pedir que me digáis uno en concreto (aunque bienvenido será si lo hacéis) pero si algún fabricante con varios modelos y sobre todo con bastante documentación y si tiene el Linux adaptado a sus CoM mucho mejor aun. :D
De paso si alguien sabe de cursos o formación al respecto bienvenida será.
Yo soy de España y no encuentro muchos sitios donde den este tipo de formación.
Gracias por todo!
-
Dejo una lista de BSC que he encontrado por la red por si hay algún interesado:
- Raspberry Pi Model B – Broadcom BCM2835 (ARM11)
- Rikomagic MK802 – Allwiner A10 (ARM Cortex-A8)
- Mele A1000 – AllWinner A10 (ARM Cortex-A8)
- Rhombus-Tech A10 EOMA-68 – AllWinner A10 (ARM Cortex-A8)
- Gooseberry board – AllWinner A10 (ARM Cortex-A8)
- A13-OLinuXino – AllWinner A13 (ARM Cortex-A8)
- VIA APC – Wondermedia WM8650 (ARM11)
- VIA ARTiGO A1200 – VIA Eden X2 (x86)
- VIA ARTiGO A1150 – VIA Eden X2 (x86)
- BeagleBoard Rev. C4 – TI OMAP3530 (ARM Cortex-A8)
- BeagleBoard-xM – TI DM3730 (ARM Cortex-A8)
- BeagleBone – TI Sitara AM3359 (ARM Cortex-A8)
- PandaBoard – TI OMAP4430 (ARM Cortex-A9)
- PandaBoard ES – TI OMAP4460 (ARM Cortex-A9)
- Cotton Candy – Samsung Exynos 4210 (ARM Cortex-A9)
- CuBox – Marvell Armada 510 (ARMv7 architecture)
- Hawkboard – TI OMAP-L138 (ARM9)
- ISEE IGEP v2 – TI DM3730 (ARM Cortex-A8)
- ISEE IGEP COM Proton – TI DM3730 (ARM Cortex-A8)
- ISEE IGEP COM Module – TI DM3730 (ARM Cortex-A8)
- Gumstix Overo series – TI Sitara and OMAP processors (ARM Cortex-A8)
- Origen Board – Samsung Exynos 4210 (ARM Cortex-A9)
- Ionics Plug Nimbus – Marvel Kirkwood 6281 (ARM9)
- Ionics Plug Stratus – Marvel Kirkwood 6281 (ARM9)
- SheevaPlug dev kit (Basic) – Marvel Kirkwood 6281 (ARM9)
- GuruPlug Standard – Marvel Kirkwood 6281 (ARM9)
- GuruPlug Display – Marvell ARMADA 168 (ARMv7 architecture)
- DreamPlug – Marvel Kirkwood 6281 (ARM9)
- D2Plug – Marvell PXA510 (ARMv7 architecture)
- Trim-Slice series – NVIDIA Tegra 2 (ARM Cortex-A9)
- Snowball – ST-Ericsson Nova A9500 (ARM Cortex-A9)
- i.MX53 Quick Start Board – Freescale i.MX53 (ARM Cortex-A8)
- Pineriver H24/MiniX – AllWinner A10 (ARM Cortex-A8)
- Smallart UHOST – AllWinner A10 (ARM Cortex-A8)
- Genesi Efika MX Smarttop – Freescale i.MX515 (ARM Cortex-A8)
- Embest DevKit8600 – TI Sitara AM3359 (ARM Cortex-A8)
- Embest SBC8018 – TI Sitara AM1808 (ARM9)
- Embest SBC8530 – TI DM3730 (ARM Cortex-A8)
- Embest DevKit8500D – TI DM3730 (ARM Cortex-A8)
-
He encontrado esta, a ver que os parece
(http://phytec.com/site/assets/files/1968/cosmic_1_web.png)
(http://phytec.com/site/assets/files/1968/single-board-box-2.jpg)
PhyCore SoM (http://phytec.com/products/single-board-computers/)
Es una Dev Board basada en el Modulo phyCORE-Vybrid
Es lo más parecido a un SoM profesional que he encontrado a buen precio. 65$ la version phyCORE-Vybrid/VF6xx SOM (Cortex™-A5/M4)
Se que existen más potentes, pero para empezar creo que esta muy bien por ese precio. Si todo sale bien y llego a comprender estos sistemas luego será más fácil dar el salto.
¿Que os parece?
-
No me veo poniendo una Raspberry Pi o una BeagleBone en una maquina de las que hacemos en la empresa en la que trabajo :lol:
La Beaglebone no tiene nada que envidiarle a otras placas para sistemas embebidos, lo bueno es que como resultan tan populares salen muy baratas. No te dejes deslumbrar por el precio desmedido de otros productos, y lo baratas que son la Raspberry o la Beaglebone. Además gracias a lo populares que son la Raspberry o la Beaglebone, hay una comunidad tremenda, foros, incluso un revista en exclusiva para Rpy, infinidad de software gratuito, tarjetas de expansión, varias versiones de SO personalizado según necesidades, todo eso no lo vas a tener, si tiras por un producto exclusivo y caro que no lo conoce ni el "tato".
Un sistema embebido tiene sus limitaciones en cuanto a potencia de proceso, o ya entramos en el rango de procesadores que necesitan refrigeración asistida, y eso ya es un PC. Como Pc también hay unidades muy pequeñas como las Nano de Zotac, pero ya te empiezas a alejar de lo que es un sistema embebido, pequeño, integrado, sin ventilación asistida, funcionando con una vulgar fuente de 5v 1Amp, etc...
Si quieres algo más potente, pero barato, estáte atento a la Parallella, yo de todas formas me centraría en al Beaglebone black, a menos que precises reproducir video de alta definición, en ese caso la Raspberry o un MK802 rodando Android y controlado por USB.
Esta placa la diseñé hace tiempo, aunque solo la tengo por ahora en el CAD, la hice para conectar por USB con el MK802, pero al final le añadí un puerto para Raspberry, es posible que haga otra versión para Beaglebone black, es para gestionar entradas/salidas en máquinas de pinball, gestiona 128 entradas en matriz, 24 entradas directas, 256 salidas para led con PWM, y con otra tarjeta adicional, 40 salidas de potencia para controlar bobinas, lleva puerto USB y tarjetero micro SD para actualizar firmware o para configurar el producto.
(http://img11.imageshack.us/img11/4141/c3j2.jpg)
-
No me veo poniendo una Raspberry Pi o una BeagleBone en una maquina de las que hacemos en la empresa en la que trabajo :lol:
La Beaglebone no tiene nada que envidiarle a otras placas para sistemas embebidos, lo bueno es que como resultan tan populares salen muy baratas. No te dejes deslumbrar por el precio desmedido de otros productos, y lo baratas que son la Raspberry o la Beaglebone.
Un sistema embebido tiene sus limitaciones en cuanto a potencia de proceso, o ya entramos en el rango de procesadores que necesitan refrigeración asistida, y eso ya es un PC. Como Pc también hay unidades muy pequeñas como las Nano de Zotac, pero ya te empiezas a alejar de lo que es un sistema embebido, pequeño, integrado, sin ventilación asistida, funcionando con una vulgar fuente de 5v 1Amp, etc...
Si quieres algo más potente, pero barato, estáte atento a la Parallella, yo de todas formas me centraría en al Beaglebone black, a menos que precises reproducir video de alta definición, en ese caso la Raspberry o un MK802 rodando Android y controlado por USB.
Esta placa la diseñé hace tiempo, aunque solo la tengo por ahora en el CAD, la hice para conectar por USB con el MK802, pero al final le añadí un puerto para Raspberry, es posible que haga otra versión para Beaglebone black, es para gestionar entradas/salidas en máquinas de pinball, gestiona 128 entradas en matriz, 24 entradas directas, 256 salidas para led con PWM, y con otra tarjeta adicional, 40 salidas de potencia para controlar bobinas, lleva puerto USB y tarjetero micro SD para actualizar firmware o para configurar el producto.
(http://img11.imageshack.us/img11/4141/c3j2.jpg)
Muy buena placa Planeta999,
A ver si nos enseñas videos de ese Pinball cuando lo tengas acabado :)
Basicamente quiero usar este tipo de SoM, SoC, SBC o Placas con Sistema Operativo integrado (para que nos entendamos todos) por la interfaz gráfica y por la conexión a internet (o Red interna de una empresa).
En realidad no me hace falta un sistema de procesado muy potente, con un PIC puedo hacer todo el control, pero si quiero darle una interfaz gráfica tipo Android, gestión de datos a través de internet (mediante una web o programa que se comunique por UDP o TCP), me están pidiendo últimamente poder ver estado y alarmas de la maquina desde un telefono movil o Tablet, poder registrar datos en un pendrive o tarjeta de memoria SD.
Digamos hacer la maquina un poco más interactiva o agradable para el usuario.
¿Has podido comunicar alguna vez la MK802 con un PIC? Si puedes comunicarte entre los dos por USB es un avance. Quizá se podría hacer el control con el PIC y la interfaz gráfica con el MK802. He hecho alguna aplicación para android con java, pero no he tocado el puerto USB.
¿Se podría hacer un puerto serie virtual en Android?
Me suena que Microchip tiene librerias para Android, pero nunca las he usado, no se que tal van para una aplicación así.
Supongo que a demás de la MK802 habrán otras tarjetas parecidas con Android, con lo que el programa podría cambiarse a otra tarjeta con Android sin problemas ¿es así?
-
Yo no pondría Android en nada industrial: Android es un OS para dispositivos móviles. Si quieres interfaz gráfica con un Linux pelao y QT te sobra: tendrás widgets tan chulos como en Android o iOS, necesitarás menos procesador y RAM y arrancará 10 veces más rápido.
Se te han olvidado todas las placas basadas en iMX6.
Un saludo.
-
Muy buena placa Planeta999,
A ver si nos enseñas videos de ese Pinball cuando lo tengas acabado :)
Bueno, no estoy diseñando un pinball, aunque hace algunos años si que me planteé hacerlo, pero comercialmente no le veo mucha salida, lo que diseño son circuitos para esas máquinas, para reemplazar electrónica antigua de los 90, por cosas más modernas. Tengo una colección de 29 máquinas de pinball, para hacer mis experimentos, en uno de mis facebook tengo fotos de mis 29 cacharricos: https://www.facebook.com/pages/PinballSP/336137879799788
Basicamente quiero usar este tipo de SoM, SoC, SBC o Placas con Sistema Operativo integrado (para que nos entendamos todos) por la interfaz gráfica y por la conexión a internet (o Red interna de una empresa).
En realidad no me hace falta un sistema de procesado muy potente, con un PIC puedo hacer todo el control, pero si quiero darle una interfaz gráfica tipo Android, gestión de datos a través de internet (mediante una web o programa que se comunique por UDP o TCP), me están pidiendo últimamente poder ver estado y alarmas de la maquina desde un telefono movil o Tablet, poder registrar datos en un pendrive o tarjeta de memoria SD.
Digamos hacer la maquina un poco más interactiva o agradable para el usuario.
Pues entonces con una Beaglebone, tienes más que de sobra, te viene cargada con Linux, pero creo que también se le puede poner Android. Con Linux, le instalas Eclipse y GCC y a funcionar. Tienes salida de video por HDMI, USB, Ethernet, 2Gb de flash en placa para el sistema operativo y prograrmas, tarjetero micro SD para almacenamiento adicional, creo que 512K de Ram, y un puñao de puertos accesibles en dos tiras de pines dobles de paso 2,54mm, alimentaciòn a 5V por un jack redondo.
¿Has podido comunicar alguna vez la MK802 con un PIC? Si puedes comunicarte entre los dos por USB es un avance. Quizá se podría hacer el control con el PIC y la interfaz gráfica con el MK802. He hecho alguna aplicación para android con java, pero no he tocado el puerto USB.
Afortunadamente Microchip facilita mucha información, drivers y demás para comunicar un PIC con Android, eso no es problema. En el caso del MK802, para control industrial, hace falta una placa que se podría hacer con un PIC, para gestionar entradas y salidas. Con el PIc puedes simular un dispositivo HDI para evitar drivers, pero Microchip también facilita drivers específicos para una comunicación más rápida.
¿Se podría hacer un puerto serie virtual en Android?
Me suena que Microchip tiene librerias para Android, pero nunca las he usado, no se que tal van para una aplicación así.
No he trasteado mucho con Android y Java, soy más de C++ y Linux, pero si, Microchip tiene algún kit de desarrollo para Android, todas las librerías y fuentes se pueden descargar de su web, sin coste.
Supongo que a demás de la MK802 habrán otras tarjetas parecidas con Android, con lo que el programa podría cambiarse a otra tarjeta con Android sin problemas ¿es así?
Los chinos han sacado montones de dispositivos similares, los llaman TV-BOX, que es básicamente un tablet sin pantalla. Yo tengo el uHost, Mele y MK802 II, luego sacaron el MK802 III con procesador de doble nucleo y más potente, ahí ya les perdí la pista, me empecé a meter con los ARM STM32 y la Beaglebone que la tengo por aquí, pero aún no he empezado con ella. Es que hay tantas cosas, que al final revientas, no has terminado con algo, y ya han sacado algo nuevo, no da tiempo a probar tantas cosas.
Yo en los últimos meses, me he estado dedicando al desarrollo web con Joomla, una maravilla de CMS para montar páginas web de todo tipo, pero tiene mucha miga, además tengo que traspasar una web actual con Oscommerce a Joomla, he estado desarrollando los cript en PHP para traspasar usurios y productos, traspasando todas las fotos que he tenido que redimensionar, creando la parte estética de la web, cuando acabe volveré a la electrónica, a ver si liquido el tema de los ARM y me pongo con la Beaglebone black...
-
La verdad es que prefiero usar un modulo profesional con Linux, como dice manwenwe. Creo que luego te puede servir para abrirte camino profesional.
Que os parece la WandBoard con el Freescale i.MX6 Solo (están con el Dual y el Quad, pero creo que con el Solo tengo de sobra)
(http://www.wandboard.org/images/wandboard-freescale-imx6.png)
Estoy entre esta y la phyCORE-Vybrid. ¿Como lo veis?
Manual WandBoard (http://www.mouser.com/ds/2/608/wandboard-user-guide-20130208-230692.pdf)
-
Creo que Wandboard es tambiénn algún tipo de organización "sin animo de lucro" como BBB o RPI: es decir, no te van a dar más soporte que el foro.
El cortex A5 de freescale no lo he probado: creo que esta familia está orientada únicamente a infotainment en coches. El iMX6 SOLO es super competitivo: "tira" mucho más que el AM335x (BBB) y con más periféricos por un precio similar o menor. Lo digo con conocimiento de causa: en mi empresa tenemos desarrollados módulos con los 2 micros.
Un saludo.
-
Creo que Wandboard es tambiénn algún tipo de organización "sin animo de lucro" como BBB o RPI: es decir, no te van a dar más soporte que el foro.
El cortex A5 de freescale no lo he probado: creo que esta familia está orientada únicamente a infotainment en coches. El iMX6 SOLO es super competitivo: "tira" mucho más que el AM335x (BBB) y con más periféricos por un precio similar o menor. Lo digo con conocimiento de causa: en mi empresa tenemos desarrollados módulos con los 2 micros.
Un saludo.
Corrigeme si me equivoco, pero la wandboard no es la placa de desarrollo y lleva un SoM iMX6 Solo?
Supongo que el soporte que más interesa es para el iMX6 y la wandboard es solo la plataforma que lleva los periféricos.
Conoces alguna dev board interesante y a buen precio?
Mañana le echare un ojo a la wandboard que ahora estoy contestando desde el móvil.
Un saludo
-
El SoC (micro) es un iMX6. Wandboard lleva un iMX6: un SoM (modulo) + una placa de expansión. Lo que te decia es que no es una empresa privada común que venda modulos o placas ya que comercializa por mouser, digikey, etc. y el soporte es a través del foro. El precio es "acojonante" (con perdón). No vas a encontrar nada con mejor calidad/precio en el mercado. Luego puedes reutilizar/modificar (con "mucho" cuidado) el Linux con licencia GPL de cualquier otra empresa, modulos/placas con este micro hay muchas.
Cuando aprendas mucho y necesites comprar muchas avísame ;-): nuestros módulos son igual de buenos pero no podemos competir con la economía de escala ;-).
Un saludo.
-
El SoC (micro) es un iMX6. Wandboard lleva un iMX6: un SoM (modulo) + una placa de expansión. Lo que te decia es que no es una empresa privada común que venda modulos o placas ya que comercializa por mouser, digikey, etc. y el soporte es a través del foro. El precio es "acojonante" (con perdón). No vas a encontrar nada con mejor calidad/precio en el mercado. Luego puedes reutilizar/modificar (con "mucho" cuidado) el Linux con licencia GPL de cualquier otra empresa, modulos/placas con este micro hay muchas.
Cuando aprendas mucho y necesites comprar muchas avísame ;-): nuestros módulos son igual de buenos pero no podemos competir con la economía de escala ;-).
Un saludo.
Por lo que dices deduzco que es una buena Dev Board para comenzar, luego si cambias a otro SoM le pones el Linux adaptado a ese SoM y a correr igual de bien.
Creo que no lo voy a pensar más ejejejej
En cuanto a lo de comprar muchas.... OJALA jaajaj eso querrá decir que me he convertido en un profesional de la materia ajajaj entonces si que hablaremos (¿Fabricais en china? :D).
Aunque decida quedarme esta Dev Board seguiré buscando info porque una vez tienes la plataforma ahora toca comprender el boot, el kernel y linux.
Si no me equivoco a estas SoM se les instala el Linux como a la RaspBerry o sea que por ese lado no será muy complicado (o eso espero).
Iré dejando en este hilo información que vaya encontrando y avances y así los comentamos entre todos.
Muchas gracias por todo :P Un saludo.
-
Hola gente,
Al final decidí comenzar con la RaspBerry, más adelante ya daré el salto a los SOM.
No me he olvidado de este hilo, es que voy liado :D
He pedido una pantalla TFT de 7" a China y ya la tengo aquí, os enseño algunas imagenes por si a alguien le interesa. Podéis encontrarla en Ebay.
(http://imageshack.us/a/img812/2439/b2nq.jpg)
(http://imageshack.us/a/img801/6394/ihh1.jpg)
(http://imageshack.us/a/img547/4417/tnc6.jpg)
El estado del "proyecto/aprendizaje" está en la elección del lenguaje de programación Java, JavaFX, Python y C++ y las IDEs Eclipse, NetBeans, QT. La idea es utilizar un lenguaje que me permita crear interfaz gráfica con un buen diseño (para eso pensaba usar JavaFX, pero tengo algún problemilla al ejecutarlo en la RPi) y que a la vez me permita acceder a las GPIO, ethernet, USB, etc.
Cuando tenga alguna aplicación que tenga alguna funcionalidad la subiré.
Un saludo.
-
C++ y QT: sin duda :D
A darle fuerte y a aprender!!!
Un saludo.
-
Hola gente,
Al final decidí comenzar con la RaspBerry, más adelante ya daré el salto a los SOM.
No me he olvidado de este hilo, es que voy liado :D
He pedido una pantalla TFT de 7" a China y ya la tengo aquí, os enseño algunas imagenes por si a alguien le interesa. Podéis encontrarla en Ebay.
¿ Que te ha costasdo esa pantalla y la controladora ?
Yo empecé usando un TV LED de 13 pulgadas con HDMI, pero me dejaba la vista, y al final me agencié un monitor de 19 pulgadas, que me cedió mi sobrino, después de que le regalara para su cumpleaños un monitor HP LED de 23 pulgadas (una maravilla), compré un conversor HDMI-VGA en Pccomponentes y mucho mejor para trabajar decentemente.
Otra cosa es que realices los proyectos en un ordenador principal con un monitor de 23 pulgadas y Linux o Windows con Vmwhare rodando Linux y subas los desarrollos al Raspberry por Ethernet.
Como entorno de desarrollo, yo prefiero C++ y Eclipse.
-
Hola gente,
Al final decidí comenzar con la RaspBerry, más adelante ya daré el salto a los SOM.
No me he olvidado de este hilo, es que voy liado :D
He pedido una pantalla TFT de 7" a China y ya la tengo aquí, os enseño algunas imagenes por si a alguien le interesa. Podéis encontrarla en Ebay.
¿ Que te ha costasdo esa pantalla y la controladora ?
Yo empecé usando un TV LED de 13 pulgadas con HDMI, pero me dejaba la vista, y al final me agencié un monitor de 19 pulgadas, que me cedió mi sobrino, después de que le regalará para su cumpleaños un monitor HP LED de 23 pulgadas (una maravilla), compré un conversor HDMI-VGA en Pccomponentes y mucho mejor para trabajar decentemente.
Otra cosa es que realices los proyectos en un ordenador principal con un monitor de 23 pulgadas y Linux o Windows con Vmwhare rodando Linux y subas los desarrollos al Raspberry por Ethernet.
Como entorno de desarrollo, yo prefiero C++ y Eclipse.
Pues ahora te lo digo de memoria, pero unos 45 euros todo, con mando a distancia y todo, mañana te lo digo exacto y te pongo el link.
Yo la quiero para hacer un HMI, para usarla como monitor es un poco pequeña. Para controlar la RPi o programar lo hago por SSH o con escritorio remoto.
Por lo que veo C++ tiene más asiduos. Para crear ventanas en un entorno visual sirve eclipse o hay alguna IDE que vaya mejor?
Siempre me ha dado un poco de respeto el C++ pero habrá que remangarse y practicar
-
Por lo que veo C++ tiene más asiduos. Para crear ventanas en un entorno visual sirve eclipse o hay alguna IDE que vaya mejor?
Yo bajo Linux no he hecho nada todavía, y Eclipse solo lo he usado para los microcontroladores ARM STM32.
En PC bajo Windows, solo utilizo Visual Studio.
En cuanto me ponga con Beaglebone Black o Raspberry, seguramente instalaré VMware para crear un entorno Linux en Windows, y me instalaré Eclipse y GCC, sobre la programación visual en Linux, ni idea, no he hecho nunca nada, espero que haya algo parecido a Visual Studio, si no estamos perdidos.
-
C++ y QT: sin duda :D
+1
-
Hola,
Aquí dejo el Link de la TFT
TFT 7" (http://www.ebay.es/itm/HDMI-VGA-2AV-Remote-Controller-7-TFT-INNOLUX-AT070TN92-50-Pin-LCD-Screen-800x480-/370816075241?pt=US_Laptop_Screens_LCD_Panels&hash=item56565c45e9&_uhb=1)
Creo que como dice manwenwe con QT puedes programar ventanas tanto para Linux como para windows. Lo que supongo que el compilador de C++ será diferente para cada SO, en cambio Python creo que es multiplataforma si no me equivoco.
También hay otros IDE para crear ventanas, ya os informaré cuando empiece a hacer alguna aplicación con alguno de ellos.
-
Hola,
Aquí dejo el Link de la TFT
TFT 7" (http://www.ebay.es/itm/HDMI-VGA-2AV-Remote-Controller-7-TFT-INNOLUX-AT070TN92-50-Pin-LCD-Screen-800x480-/370816075241?pt=US_Laptop_Screens_LCD_Panels&hash=item56565c45e9&_uhb=1)
Creo que como dice manwenwe con QT puedes programar ventanas tanto para Linux como para windows. Lo que supongo que el compilador de C++ será diferente para cada SO, en cambio Python creo que es multiplataforma si no me equivoco.
También hay otros IDE para crear ventanas, ya os informaré cuando empiece a hacer alguna aplicación con alguno de ellos.
Muy competitivo el precio.Le falta el touch no?.
Alguién conoce displays con touch capacitivo a buen precio?. Si fuese uno grande con lvds ya sería magnifico!!!. También me vale sólo el touch que cuadre con el tamaño de algún display de pc portatil que suelen ser baratos...
-
Hola,
Aquí dejo el Link de la TFT
TFT 7" (http://www.ebay.es/itm/HDMI-VGA-2AV-Remote-Controller-7-TFT-INNOLUX-AT070TN92-50-Pin-LCD-Screen-800x480-/370816075241?pt=US_Laptop_Screens_LCD_Panels&hash=item56565c45e9&_uhb=1)
Creo que como dice manwenwe con QT puedes programar ventanas tanto para Linux como para windows. Lo que supongo que el compilador de C++ será diferente para cada SO, en cambio Python creo que es multiplataforma si no me equivoco.
También hay otros IDE para crear ventanas, ya os informaré cuando empiece a hacer alguna aplicación con alguno de ellos.
Muy competitivo el precio.Le falta el touch no?.
Alguién conoce displays con touch capacitivo a buen precio?. Si fuese uno grande con lvds ya sería magnifico!!!. También me vale sólo el touch que cuadre con el tamaño de algún display de pc portatil que suelen ser baratos...
Si, le falta el touch, lo eche en falta una vez ya pedido, pero bueno, buscaré uno de estas medidas cuando tenga tiempo. Si lo consigo a buen precio ya pondrá aquí referencias
-
Hola,
Aquí dejo el Link de la TFT
TFT 7" (http://www.ebay.es/itm/HDMI-VGA-2AV-Remote-Controller-7-TFT-INNOLUX-AT070TN92-50-Pin-LCD-Screen-800x480-/370816075241?pt=US_Laptop_Screens_LCD_Panels&hash=item56565c45e9&_uhb=1)
Creo que me voy a comprar una.
Unas preguntillas:
¿ Incluye el cable para conectar con el Raspberry ??
¿ En Raspberry hay que configurar algo para que la salida de video se haga por S2 ?
¿ Puede salir video a la vez, por HDMI y S2 ?
Salu2
-
Lo del cable hdmi evidentemente no lo sé :p.
Lo de S2: es un puerto DSI , por lo que ahí tienes que conectar un display MIPI. El display de bitpic es un RGB paralelo con una placa con un emisor DVI (para poder conectar el cable HDMI).
La RPI sólo te deja sacar una fuente de video a la vez.
Un saludo.
-
Hola,
Aquí dejo el Link de la TFT
TFT 7" (http://www.ebay.es/itm/HDMI-VGA-2AV-Remote-Controller-7-TFT-INNOLUX-AT070TN92-50-Pin-LCD-Screen-800x480-/370816075241?pt=US_Laptop_Screens_LCD_Panels&hash=item56565c45e9&_uhb=1)
Creo que me voy a comprar una.
Unas preguntillas:
¿ Incluye el cable para conectar con el Raspberry ??
¿ En Raspberry hay que configurar algo para que la salida de video se haga por S2 ?
¿ Puede salir video a la vez, por HDMI y S2 ?
Salu2
La RPi tiene HDMI, RCA y un puerto especifico de TFT (desconozco si ya existe la compatibilidad de pantallas TFT para el puerto especifico, para el puerto de la cámara si)
La pantalla TFT tiene entrada HDMI, RCA y VGA, pero viene sin cable, tendrás que comprar un cable HDMI o RCA
En principio si que hay un fichero de configuración en la SD que es donde se instala el Debian. En este fichero puedes configurarlo. Normalmente no suelo usar pantalla, suelo usar SSH o escritorio remoto, y si la uso es con HDMI, pero en una ocasión use el RCA y me funciono sin tocar el fichero de configuración.
Igualmente la configuración es sencilla.
Tengo otra pantalla TFT 3,5" (http://www.bricogeek.com/shop/pantallas-lcd/574-pantalla-tft-35-ntsc-pal.html) que es por RCA si te interesa.
(http://www.bricogeek.com/shop/574-1920-thickbox/pantalla-tft-35-ntsc-pal.jpg)
No lo he probado, pero como dice manwenwe creo que solo te permite una salida de video.
Voy a mirarme el QT y C++ a ver que podemos sacar de bueno. ¿Sabéis de algún manual interesante?
:)
-
bitpic: se ve la pantalla un poco recortada en vertical. Revisa los timmings (busca algún ejemplo en internet para tu resolución). Lo de QT y C++ ni idea: yo no programo, programa mi socio, lo que sé es que los gráficos animados (qml) son una pasada.
Un saludo.
-
bitpic: se ve la pantalla un poco recortada en vertical. Revisa los timmings (busca algún ejemplo en internet para tu resolución). Lo de QT y C++ ni idea: yo no programo, programa mi socio, lo que sé es que los gráficos animados (qml) son una pasada.
Un saludo.
La foto de la pantalla de 3.5" es la de la tienda, la de 7" si es foto de mi pantalla y tienes razón se ve recortada tanto vertical como en horizontal. En los botones de configuración de la pantalla no había menú de configuración para expandirla, tendré que tocar la configuración de la RPi. Cuando me ponga con la pantalla me lo miraré, ahora lo que me preocupa es la programación.
Me estoy mirando un poco ahora el Python, parece sencillo de digerir.
En QT si no me equivoco puedes programar tanto en C++ como en Python.
Mi gran duda ahora es:
- Por comodidad me gustaría hacer el programa en windows y luego pasarlo a la RPi con Linux. En Java lo puedo hacer, pero si uso QT + Python o QT+C++ ¿también me será compatible o tendré que instalarme el QT+Python o QT+C++ en la RPi y compilarlo allí para que me funcione?
- En caso de tener que compilar en Linux para que sea compatible, ¿puedo instalarme una maquina virtual con Debian en mi windows y compilar en la maquina virtual y luego pasarlo a la RPi o forzosamente tiene que ser en la RPi?
Esto lo digo porque la RPi es rápida, pero es mucho más rápido un PC normal y por tanto más cómodo.
Supongo que si algún día paso a un SOM u otra SBC el dilema será el mismo ¿verdad? o ¿puede que sea muy diferente? suponiendo que este SOM o SBC tenga Linux también claro.
:)
-
* Tiene pinta de que lo que te venia en la RPI son timmings para 640x480 y la tuya es 800x480 RGB666 (si tu config es RGB888 no te preocupes porque se ve "igual").
* Sí. Tienes que compilar soporte QT para la RPI para que te funcionen tus programas hechos en QT.
* Lo de Windows no lo se porque no se si hay compiladores cruzados. Para Linux con una maquina virtual te vale aunque te recomiendo un PC dedicado: yo me cambio porque virtual box con 4GB RAM dedicados y 1 core me va fatal. Te bajas un compilador cruzado (te empollas como va) y compilas de x86 a ARM.
* En el resto de placas el procedimiento es similar.
Un saludo
-
No sé en win, pero para linux Python no es un lenguaje compilado sino que interpretado.
Hay un port de QT para Python que es pyqt. Puedes crear la interfaz grafica con qt-creator y guardarla como archivo .ui y luego utilizas pyuic4 para "cambiarla" a un archivo que pueda interpretar tu programa en Python.
-
La RPi tiene HDMI, RCA y un puerto especifico de TFT (desconozco si ya existe la compatibilidad de pantallas TFT para el puerto especifico, para el puerto de la cámara si)
La pantalla TFT tiene entrada HDMI, RCA y VGA, pero viene sin cable, tendrás que comprar un cable HDMI o RCA
Ok, pensaba que el Raspberry lo conectabas a esa pantalla por el conector S2.
Lo ideal sería poder conectarla directamente por LVDS, de hecho creo que esa controladora debe ser un conversor VGA/HDMI/Compuesto a LVDS.
Yo hace tiempo les compré a los chinos un panel TFT de 18 pulgadas y varias tarjetas LVDS con entrada VGA y video compuesto, para crear sistemas de publicidad con una tarjeta adicional que tiene un lector SD, le pones archivos de video o fotos, y los reproduce automáticamente, es algo parecido a los marcos digitales de fotos.
También estuve mirando para conectar un panel TFT a un PIC32, usando un chip LVDS THC63LVDM83R, como pantalla iba a usar un panel de Sharp de los que montan los parasoles de los coches para los sistemas multimedia con un formato 25:9. No lo llegué a terminar, no se si el PIC32 hubiera tenido suficiente potencia para enviar los datos a la velocidad adecuada para mantener la imagen estable, igual un día lo retomo. El tema LVDS siempre me resultó interesante.
-
- En caso de tener que compilar en Linux para que sea compatible, ¿puedo instalarme una maquina virtual con Debian en mi windows y compilar en la maquina virtual y luego pasarlo a la RPi o forzosamente tiene que ser en la RPi?
Yo creo que lo ideal, es instalar VMware en tu PC con Windows, y rodar un Linux virtual, compilas y lo pasas al Raspberry por Ethernet, yo uso Putty para conectar con mi server dedicado por SSH, supongo que será igual en local con una LAN.
Lo que desconozco por ahora es lo del entorno visual de C++ en Linux, hasta ahora todo lo que he hecho con C++ ha sido con Visual Studio en Windows.
-
LVDS con pantalla reciclada de portátil (1280x800@RGB666):
(http://imageshack.us/a/img29/4827/fx5y.jpg)
Un saludo.
-
LVDS con pantalla reciclada de portátil (1280x800@RGB666):
(http://imageshack.us/a/img29/4827/fx5y.jpg)
Un saludo.
Eiiii que guapo ((:-))!! como has hecho eso, enseña lo que tienes conectado :D
-
Lo que hay conectado es una placa similar a la wandboard. Lo dejamos ahí: vengo al foro a compartir conocimientos, no a hacer publicidad de mi curro ;-).
Un saludo!
-
LVDS con pantalla reciclada de portátil (1280x800@RGB666):
Un saludo.
¿ a que dispositivo y con que tarjeta, has conectado el panel ?
Yo tengo varias tarjetas que les compré a los chinos, con entradas VGA y video compuesto, a LVDS, pero nunca supieron aclararme si la tarjeta era universal o específica para un panel o grupo de paneles.
En mi caso necesitaba una conexión directa por LVDS a un panel Sharp LQ123K1LG03, este panel lo montan las pantallas de los parasoles de los coches, para los sistemas multimedia, es de 13 pulgadas, pero con una proporción 25:8, es decir mucho más ancho que el tradicional 16:9 de los actuales monitores. El producto en si, lleva una controladora con un chip de Realtek, pero solo tiene entrada por video compuesto, lo que si pude reutlizar es el inversor de la retroiluminación.
Me costó mucho, pero al final localicé el datasheet del panel, en el que recomiendan como controlador LVDS, un chip THC63LVDM83R, que compré a los chinos, pero ahí me quedé, ya me lié con otros temas, y lo dejé. El tema era conectarlo a un PIC32 para sacar video, el controlador LVDS requiere una señal de reloj de 30Mhz para mostrar imágenes de manera estable.
Pongo unas fotos de todos los chismes que compré en su día a los chinos, para trastear con LVDS.
Panel Sharp LQ123K1LG03, me interesaba mucho para un proyecto, pero tenía que reemplazar la controladora que lleva con entrada de video compuesto, por una controladora propia con un chip THC63LVDM83R, algún día retomaré el tema.
(http://imageshack.us/a/img17/8376/5c1l.jpg)
El panel por la otra cara, le quité su controladora, y rotulé la identificación del cableado LVDS en la carcasa, como se ve en la foto. La placa que aparece a la derecha del panel, es la inversora para la retroiluminación.
(http://imageshack.us/a/img849/9301/32c1.jpg)
Un par de controladoras LVDS
(http://imageshack.us/a/img189/544/oj4o.jpg)
Y otra LVDS más, esta con VGA y creo que también con HDMI:
(http://imageshack.us/a/img23/4210/8lte.jpg)
Un par de tarjetas para montar sistemas publicitarios, con salida LVDS, y tarjetero Compact Flash, pueden reproducir video o mostrar fotos en carrusel, como los marcos de fotos digitales
(http://imageshack.us/a/img43/5270/o3m1.jpg)
Cables LVDS y otros
(http://imageshack.us/a/img46/8277/p462.jpg)
Conjunto completo con panel de 18 pulgadas, placa reproductora de video y fotos, tarjeta con pulsadores, mando a distancia por infrarrojos y un par de altavoces elípticos.
(http://imageshack.us/a/img594/8317/rd21.jpg)
-
Como dije la placa es una con el micro de la wandboard (iMX6) con puerto LVDS.
Esto es lo que puedes hacer con un PIC:
http://www.microchip.com/pagehandler/en-us/technology/graphics/technology.html
La tabla indica lo que puedes pintar no a que velocidad. Yo hace años lo más que conseguí con un PIC32 fué 320x240@16bit a 5-10hz (no recuerdo bien).
Un display de 30mhz será de 800x480.
Un saludo.
-
Como dije la placa es una con el micro de la wandboard (iMX6) con puerto LVDS.
Esto es lo que puedes hacer con un PIC:
http://www.microchip.com/pagehandler/en-us/technology/graphics/technology.html
La tabla indica lo que puedes pintar no a que velocidad. Yo hace años lo más que conseguí con un PIC32 fué 320x240@16bit a 5-10hz (no recuerdo bien).
Un display de 30mhz será de 800x480.
Un saludo.
Esa tabla de Microchip se refiere a sus micros con controlador gráfico integrado, que no es mi caso, yo iba a conectar directamente los puertos de un PIC32 (sin motor gráfico) con un conversor TTL/CMOS a LVDS (THC63LVDM83R), para controlar un panel de 24 bits. Es posible que lo retome, pero usando un ARM STM32, que es mucho más potente.
No conozco la wandboard, pero buscando por google, me encuentro esta tabla comparativa con la Raspberry y la Beaglebone, la salida de video que ponen para la wandboard es HDMI, supongo que el LVDS al que te refieres serán esos 30 pines del GPIO para un LCD.
(http://img713.imageshack.us/img713/1021/5hik.jpg)
-
Creo que no es como dices: la tabla es para todos los dipositivos, tanto con controlador (PIC24DA) como por "bit banging" (PIC32). No es por desalentarte pero va a ser muy dificil controlar un LCD "grande" con un PIC32. Por ejemplo, para 800x480@24bit necesitas 1MB de framebuffer: ten en cuenta que los PIC no tienen puerto para conectar RAM en paralelo; y aunque lo tuvieses lo único que podrías conseguir es cargar una imagen estática en 1-2 segundos como poco. Creo que lo mejor es poner una placa con controlador externo (un Solomón por ejemplo): esas placas se encargan de cargar las imágenes desde una SD o un USB y tú sólo tienes que mandar ordenes desde el PIC.
Creo que la wandboard sí que tiene LVDS aunque no estoy seguro. El micro tiene 2xLVDS, HDMI, DSI y RGB. Hay más placas con el mismo micro pero no son tan baratas.
-
Creo que no es como dices: la tabla es para todos los dipositivos, tanto con controlador (PIC24DA) como por "bit banging" (PIC32). No es por desalentarte pero va a ser muy dificil controlar un LCD "grande" con un PIC32. Por ejemplo, para 800x480@24bit necesitas 1MB de framebuffer: ten en cuenta que los PIC no tienen puerto para conectar RAM en paralelo; y aunque lo tuvieses lo único que podrías conseguir es cargar una imagen estática en 1-2 segundos como poco. Creo que lo mejor es poner una placa con controlador externo (un Solomón por ejemplo): esas placas se encargan de cargar las imágenes desde una SD o un USB y tú sólo tienes que mandar ordenes desde el PIC.
Bueno, en mi proyecto solo tenía que gestionar imágenes con una resolución de 128*32, aunque luego estuvieran visualizándose sobre un panel que ofrece mucha más resolución. Otra opción en la que pensé, es en usar un FPGA, pero en ese terreno me queda todavía mucho que aprender, aunque tengo varios kits de Altera y Xilinx, y algunas pruebas he hecho. Y la tercera opción sería usar un Raspberry o una Beaglebone black, tengo ambas placas, y seguramente me decantaré por la segunda.
-
Mejor la BBB sí. Te coges cualquier transmisor LVDS para gráficos y este ya te lo hace todo sólo:
http://www.ti.com/lit/ds/symlink/ds90c385a.pdf
Sólo recuerda que la BBB no te da más resolución de HD ready. Además para full hd necesitarías 2 canales LVDS.
Un saludo.
-
Mejor la BBB sí. Te coges cualquier transmisor LVDS para gráficos y este ya te lo hace todo sólo:
http://www.ti.com/lit/ds/symlink/ds90c385a.pdf
Sólo recuerda que la BBB no te da más resolución de HD ready. Además para full hd necesitarías 2 canales LVDS.
Un saludo.
¿ Te refieres a conectar el conversor TTL - LVDS al GPIO de la Beaglebone ?
Lo que nunca he tenido muy claro es si cada panel o tipo de panel requiere un chip LVDS específico, o cualquiera vale para todos, siempre que sea un panel de la misma cantidad de bits que el conversor, en mi caso un panel de 24bits. Me refiero a que si el formato de los datos de salida LVDS es universal.
Otra opción, sería conectarle a la Beaglebone, un conversor HDMI - LVDS, creo que una de las placas que tengo de los chinos tiene entrada HDMI, y fueron muy baratas. El problema sería la resolución, porque un panel 25:8 tiene un formato de resolución muy especial, y si no se puede configurar bien, la imagen saldrá deforme.
-
A ver, por partes:
* Las salidas GPIO a las que te refieres no son sólo GPIOs. Es decir son pads y cada pad puede configurarse para muchas cosas (a nivel hardware). Es decir: el mismo pad puede ser un GPIO, una bit RGB del controlador LCD, una lina de I2C o UART, etc. Vamos: parecido a los PICs.
* LVDS es un standard a nivel físico: lo puedes utilizar para llevar señales de video, de audio, I2C, lo que quieras. La ventaja es que al ser a través de pares diferenciales la integridad de la señal es mucho mejor. Luego en base a LVDS tienes variantes como HDMI que está basada en codificación TDMS. LVDS en sí no tiene una regla de codificación por hardware pero para ciertas tareas como el video se utiliza un una codificación de software (creo que vale para todos los displays). Lo bueno de los conversores como el que te he mostrado es que lo hacen todo ellos solitos: le metes los 24bit RGB, el reloj, HSYNC, VSYNC y EN y el chip te lo pasa a LVDS como un panel "espera que le entre". Así que a nivel software no te tienes que preocupar: le dices a la BBB que la salida es RGB paralelo y el resto es transparente.
* Yo evitaría lo de HDMI a LVDS: me parece rizar el rizo.
Un saludo.
-
* Las salidas GPIO a las que te refieres no son sólo GPIOs. Es decir son pads y cada pad puede configurarse para muchas cosas (a nivel hardware). Es decir: el mismo pad puede ser un GPIO, una bit RGB del controlador LCD, una lina de I2C o UART, etc. Vamos: parecido a los PICs.
Ya se que los pines del GPIO se pueden configurar para multiples funciones, la cuestión es si se pueden configurar para que generen una salida de video LVDS, sin necesidad de tener que controlarlo yo por software. Yo podría crear un programa que saque por los pines del GPIO los datos RGB y la señal de reloj, pero lo ideal sería que la Beaglebone pudiera configurarse desde Linux, para que vuelque "automáticamente" la misma señal de video que saca por HDMI, pero en formato LVDS por los pines del GPIO.
Buscando por google, me encuentro que hay un shield para LVDS, pero no dan ninguna informacion sobre la configuración de la Beaglebone para usarlo:
http://circuitco.com/support/index.php?title=BeagleBone_LVDS_LCD_Cape
-
No, no hay salidas lvds en la bbb. Las unicas salidas diferenciales son algunas de ddr.
No tienes que preocuparte por la config para el shield lvds. Para ti es como si fuese un display en rgb paralelo
-
Unas dudas,
Veo que en RPi tiene una serie de librerias para controlar los GPIO según si vas a hacer el programa en C, C++, Python, Java, etc.
Cuando usas una SoM "profesional" ¿te proveen estas librerias para distintos lenguajes para el modulo?
Por otro lado, he estado probando Python y Java para crear aplicaciones con ventanas y me gustaría hacer que arrancaran estas ventanas automáticamente al iniciar la RPi (a poder ser sin llegar a ver el escritorio de RPi).
He encontrado algunos sitios donde dicen que añadiendo la linea que ejecuta tu programa en /etc/rc.local arranca la aplicación automáticamente, pero me da a mi que esto solo ocurre con programas creados en la linea de comandos. Al menos yo lo he probado y no me ha funcionado.
¿Sabéis si es posible hacerlo? la idea es crear un HMI para mis aplicaciones y me gustaría que arrancara sin que se vea el escritorio de RPi
-
Unas dudas,
Veo que en RPi tiene una serie de librerias para controlar los GPIO según si vas a hacer el programa en C, C++, Python, Java, etc.
Cuando usas una SoM "profesional" ¿te proveen estas librerias para distintos lenguajes para el modulo?
Por otro lado, he estado probando Python y Java para crear aplicaciones con ventanas y me gustaría hacer que arrancaran estas ventanas automáticamente al iniciar la RPi (a poder ser sin llegar a ver el escritorio de RPi).
He encontrado algunos sitios donde dicen que añadiendo la linea que ejecuta tu programa en /etc/rc.local arranca la aplicación automáticamente, pero me da a mi que esto solo ocurre con programas creados en la linea de comandos. Al menos yo lo he probado y no me ha funcionado.
¿Sabéis si es posible hacerlo? la idea es crear un HMI para mis aplicaciones y me gustaría que arrancara sin que se vea el escritorio de RPi
Me respondo: He podido hacer que se inicie la aplicación automaticamente poniendola en:
sudo nano /etc/xdg/lxsession/LXDE/autostart
Lo malo que aun se me sigue viendo el escritorio al iniciar, y luego queda tapado por la aplicación.
-
Si no quieres ventanas ni las vas a utilizar mejor usa otra distro, yo probaría con ltib o buildroot: van "peladas" pero arrancará como una flecha.
Si no te quieres complicar busca los scripts de arranque y deshabilita x-windows: así no te arrancarán las ventanas que vengan por defecto (creo que LXDE).
Normalmente sí vas a tener soporte para todos esos lenguajes que comentas en cualquier placa. Por los GPIOs no te preocupes, aunque no tengas librerías son muy fáciles de controlar ejecutando comandos de sistema.
Un saludo.
-
Lo malo que aun se me sigue viendo el escritorio al iniciar, y luego queda tapado por la aplicación.
¿ has probado a configuarlo para que arranque en modo consola ?
http://www.taringa.net/posts/linux/9477705/Como-desactivar-el-entorno-grafico.html
Yo creo que lo tengo instalado con Raspbian, y juraría que no arranca el modo gráfico, se queda en la consola de comandos, la que si que me arranca con el entorno gráfico es la Beaglebone Black.
-
Si no quieres ventanas ni las vas a utilizar mejor usa otra distro, yo probaría con ltib o buildroot: van "peladas" pero arrancará como una flecha.
Si no te quieres complicar busca los scripts de arranque y deshabilita x-windows: así no te arrancarán las ventanas que vengan por defecto (creo que LXDE).
Normalmente sí vas a tener soporte para todos esos lenguajes que comentas en cualquier placa. Por los GPIOs no te preocupes, aunque no tengas librerías son muy fáciles de controlar ejecutando comandos de sistema.
Un saludo.
¿Pueden correr java o python estas distro? voy a echarle un ojo a ltib y bouilroot a ver de que va esto. (no me queda nada por aprender... :lol:)
Lo malo que aun se me sigue viendo el escritorio al iniciar, y luego queda tapado por la aplicación.
¿ has probado a configuarlo para que arranque en modo consola ?
http://www.taringa.net/posts/linux/9477705/Como-desactivar-el-entorno-grafico.html
Yo creo que lo tengo instalado con Raspbian, y juraría que no arranca el modo gráfico, se queda en la consola de comandos, la que si que me arranca con el entorno gráfico es la Beaglebone Black.
Por defecto viene configurado para arrancar con la consola, pero puedes configurarlo para que arranque con el escritorio. Si no me equivoco en el raspi-config hay un meno donde puedes elegir si quieres arrancar por defecto en consola o modo gráfico.
-
Sí que puedes sí.
-
Otro bicharraco interesante, la UDOO, con versiones de doble y cuadruple nucleo a 1Ghz, puede instalar Android o Linux, e integra también un procesador Atmel con una configuración compatible Arduino. Y parece que hay una buena comunidad detrás, en Facebook tienen más de 18000 seguidores. http://www.udoo.org/
(http://makerflux.com/wp-content/uploads/2013/09/Udoo-dual-core.jpg)
-
Si, están saliendo un monton de placas de este tipo
(http://arduino.cc/en/uploads/Main/ArduinoTre_LandingPage.jpg)
y Olimex creo que esta desarrollando una nueva con muy buena pinta que ahora no recuerdo como se llama. Si la encuentro os la paso.
La tecnologia avanza mucho más rapido de lo que yo puedo abarcar... :? tendré paciencia conmigo mismo jejejej
-
Lo he encontrado, es este a20-som (http://olimex.wordpress.com/2013/10/09/a20-som-update/)
De manera profesional supongo que es mejor usar un fabricante de SOM que se dedique solo a esto para poder darte continuidad en sus productos y compatibilidad con SOM nuevas que vaya sacando, pero no tiene mala pinta.
Creo que hasta finales de Noviembre no saldrá y no veremos que precio tiene, pero Olimex suele tener buenos precios y un SOM como este para hacer nuestros desarrollos personales va muy bien, a partir de este SOM diseñas la placa con los periféricos que necesites y tienes un SO en tu placa.
(http://olimex.files.wordpress.com/2013/09/a20-som.jpg?w=487)
-
El año que viene Freescale saca micros de 64 bits (A50 ó A57): eso sí que va a ser un puntazo!!!
-
El año que viene Freescale saca micros de 64 bits (A50 ó A57): eso sí que va a ser un puntazo!!!
:shock: Lo que yo te diga... no doy a basto jajaja
Diles que se esperen, que todavía no se como van los de 32 bits, que ya les aviso yo si eso cuando tienen que sacarlo....
Si es que no avanzo... :(
-
Jejeje no te preocupes: yo ya llevo casi 3 años con estas cosas... cada vez aprendes más y más rápido.
-
pffff... tendré paciencia... si la verdad que yo con 32bits me sobran 30 jajajajaj
Por cierto, dejo otro link de una TFT+touch de 7" que he visto en ebay. Quizá me la compre también porque veo que me voy a quedar con las ganas del touch con la mia...
TFT 7"+Touch (http://www.ebay.es/itm/Diy-Monitor-for-Raspberry-Pi-HDMI-VGA-2AV-Lcd-Driver-7-AT070TN92-Touch-Screen-/121119934991?pt=US_Server_Boards&hash=item1c334f8a0f&_uhb=1)
(http://www.b2cqshop.com/yourqshop/Q062151103-4.jpg)
-
pffff... tendré paciencia... si la verdad que yo con 32bits me sobran 30 jajajajaj
Por cierto, dejo otro link de una TFT+touch de 7" que he visto en ebay. Quizá me la compre también porque veo que me voy a quedar con las ganas del touch con la mia...
TFT 7"+Touch (http://www.ebay.es/itm/Diy-Monitor-for-Raspberry-Pi-HDMI-VGA-2AV-Lcd-Driver-7-AT070TN92-Touch-Screen-/121119934991?pt=US_Server_Boards&hash=item1c334f8a0f&_uhb=1)
No hace falta que te compres de nuevo todo el tenderete, el sensor touch lo venden suelto para cualquier tamaño de pantalla, mira por Aliexpress que los chinos lo tienen muy barato.
¿ como llevas el tema de la programacion, ya has conseguido un entorno de desarrollo gráfico tipo Visual Studio o similar ?
-
pffff... tendré paciencia... si la verdad que yo con 32bits me sobran 30 jajajajaj
Por cierto, dejo otro link de una TFT+touch de 7" que he visto en ebay. Quizá me la compre también porque veo que me voy a quedar con las ganas del touch con la mia...
TFT 7"+Touch (http://www.ebay.es/itm/Diy-Monitor-for-Raspberry-Pi-HDMI-VGA-2AV-Lcd-Driver-7-AT070TN92-Touch-Screen-/121119934991?pt=US_Server_Boards&hash=item1c334f8a0f&_uhb=1)
Si, luego lo pensé, le preguntaré al vendedor sin venden el touch suelto con los drivers.
No hace falta que te compres de nuevo todo el tenderete, el sensor touch lo venden suelto para cualquier tamaño de pantalla, mira por Aliexpress que los chinos lo tienen muy barato.
¿ como llevas el tema de la programacion, ya has conseguido un entorno de desarrollo gráfico tipo Visual Studio o similar ?
Pues de momento solo he hecho el típico "Hola mundo" con ventanas, lo hice con Java y con Python.
- Para Java usé NetBeans que viene con una IDE que te permite crear ventanas tipo VisualStudio.
- Para Python lo hice a pelo, sin IDE. Intente hacerlo con PyQT pero no consigo hacerlo funcionar, no he sabido configurar el compilador, seguiré probando.
Con JavaFX hice algo también, pero no me funciona en la RPi, a ver si saco algo de tiempo y puedo instalarme el VMWare con Debian he intentar compilarlo allí a ver si así me corre en la RPi también.
Quiero probar el C++ también, pero de este lenguaje estoy muy verde, de los demás también estoy verde, pero me parecen más fáciles que C++, igual es solo la primera impresión, pero hasta que no lo pruebe no lo sabré.
RESUMIENDO: A nivel pantallas he probado Java y Python y me falta probar C++. Y por otro lado me falta hacer funcionar QT para Python y C++ o pasarme a otro IDE, aunque veo que mucha gente recomienda QT. El siguiente paso es probar las GPIO a ver que lenguaje me interesa, supongo que en este caso C++ será más rápido que Java (que python no lo se).
A ver si monto bien la pantalla y hago algún programa con ventanas y controlando los GPIO, aunque sea encendiendo un LED y os lo enseño.
Ahora mismo lo que necesito son días de 34horas jajaajja
-
¿ Python no es un lenguaje intérprete ?
Si dominas Java, C++ no te costará nada, yo he tocado muy poco el Java, pero todo el tema de las clases, que es lo más complicado del C, también lo tiene el Java.
A mi Java nunca me ha convencido, al no compilar ejecutables, siempre necesitas el JVM, que no deja de ser un intérprete que actua de intermediario en la ejecución del programa, eso le tiene que restar potencia con respecto al C.
A mi me parece que el C y sus variantes (C++, C#), es el lenguaje de programación más versatil, potente y portable que ha existido y existirá. Y aunque siempre hay variaciones entre plataformas, son mínimas, a mi no me costó nada pasar de programar en C++ en Visual Studio, a programar en C con PIC32 o ARM STM32.
Cuando me ponga con las RPI y la Beablebone Black, tengo clarísimo que programaré en C++, solo me falta averiguar que entorno gráfico usar bajo Linux, que sea lo más parecido a Visual Studio. Tengo la experiencia de Eclipse y GCC con ARM STM32, pero por ahí no se ve nada para trabajar con un entorno gráfico, a menos que hayan plugins específicos para eso, que lo desconozco.
-
Si dominas Java, C++ no te costará nada,
Pensaba que era al revés :D
-
Si dominas Java, C++ no te costará nada,
Pensaba que era al revés :D
Si, lo normal es aprender C, luego C++ y luego saltar a Java y otros lenguajes jeje. Yo como soy un tio impaciente, pase de ASM a C con microcontroladores, luego Visual Basic para controlar los micros desde el PC y luego ya me pico el gusanillo y empece a hacer un poco de todo, pero un mucho de nada :D
Lo de usar Java es porque en la universidad me dieron nociones y luego al ser portable de un SO a otro me parecio bueno para eso, pero tengo la espina clavada del C++, creo que acabaré metiendole mano. El Python lo he probado porque veo que para RPi hay mucha info con este lenguaje, pero hasta que me compre la RPi no lo había usado nunca.
En principio la IDE que he visto potente para C++ es QT, pero no es 100% como Visual Studio.
Habrá que mirar si hay algún pluguin para eclipse, es extraño que no lo haya, porque el eclipse es como una navaja suiza, sirve para todo jeje.
Lo que si me he fijadao (creo que manwenwe ya lo comento, corrígeme si me equivoco manwenwe) es que el entorno gráfico (Ventanas y demás...) se suelen hacer en XML y y luego se añade el código del programa en el lenguaje elegido (java, C++, python, etc.).
JavaFX funciona así, QT si no me equivoco también, en una ocasión hice alguna aplicación para Android con eclipse y también era en xml y hace poco estuve mirando otra IDE de Linux que ahora no recuerdo como se llama que tambien te creaba las ventanas y demas en xml y luego le introducias el programa o funciones en Python.
Supongo que un programador profesional pensará que esto es lo normal y que soy novato :oops: :D pero la verdad es que es así, soy un novato jajaja pero tal y como funciona hoy en día la tecnologia ya estoy pensando en estudiar Ingenieria Informatica ejejej todo lo mueven ellos.
Bueno, lo dicho, en cuanto tenga algo decente con ventanas y la TFT montada os pongo algunos resultados.
Un saludo.
-
bitpic: yo no soy un programador profesional pero estoy rodeado,"gracias a dios" como se suele decir, de muchos cracks. Por eso transmito lo que ellos me cuentan (yo me dedico a diseñar hardware).
Qt tiene su propia IDE: QT creator. Lo del XML no me suena (aunque no pongo la mano en el fuego) y para Android/iOS menos: yo diría que eso es si no programas en nativo.
Me lo apunto y mañana lo pregunto ;-)
Un saludo: deseando estoy de ver tus avances con el TFT :-)
-
bitpic, esto es lo que me han contado:
* Para QT utiliza Visual studio, Eclipse o QT creator (netbeans mejor para Java).
* Tenias razón en lo de XML para Android.
* En QT en vez de XML tienes QML.
Me voy a lo mio que es diseñar circuitos y un poquito de C :D
Un saludo.
-
bitpic, esto es lo que me han contado:
* Para QT utiliza Visual studio, Eclipse o QT creator (netbeans mejor para Java).
* Tenias razón en lo de XML para Android.
* En QT en vez de XML tienes QML.
Me voy a lo mio que es diseñar circuitos y un poquito de C :D
Un saludo.
Muy interesante esta información manwenwe. Yo lo intenté con el QT creator, pero tenía problemas con la compilación, pero esta muy bien saber que se puede usar Visual Studio y Eclipse.
Creo que lo que no será tan fácil es hacer una aplicación en Visual Studio que funcione bien el Linux. De momento seguiré provando con QT creator.
A ver si este fin de semana tengo tiempo y hago una aplicación sencilla de cada uno (Java, Python y C++) y las subo. Ya aviso que de momento será algo sencillo, ventana con botón para encender algún led o leer el estado de alguna entrada digital (por algo se empieza).
El día 5 me han invitado a un workshop de PicoITX, a ver si allí aprendo algo.
(http://iwavesystems.com/media/import/Solutions/Development%20Platforms/i.MX6_Pico_ITX_SBC/i.MX6%20Pico%20ITX%20SBC.png)
-
Ta chula la plaquita.
Cuando vayas pregúntales 2 cosas:
1. ¿Por qué le han puesto sólo 512MB de RAM? Con eso van justitos para cargar un OS pesado (Android, Ubuntu, etc.) y mover la GPU al mismo tiempo.
2. ¿Por qué le han soldado un conector SATA si ese modelo no tiene SATA? :shock:. Te dirán que piensan poner un DUAL o QUAD en el futuro... "Pues sueldalo en el futuro" :D
Un saludo.
-
Ta chula la plaquita.
Cuando vayas pregúntales 2 cosas:
1. ¿Por qué le han puesto sólo 512MB de RAM? Con eso van justitos para cargar un OS pesado (Android, Ubuntu, etc.) y mover la GPU al mismo tiempo.
2. ¿Por qué le han soldado un conector SATA si ese modelo no tiene SATA? :shock:. Te dirán que piensan poner un DUAL o QUAD en el futuro... "Pues sueldalo en el futuro" :D
Un saludo.
Perdón perdón perdón....!! He metido la pata, creo que no es exactamente esa placa, es que me he dejado llevar por la emoción. Es una SBC ARMStoneA5, pero no consigo encontrar exactamente cual es, he visto varias muy similares pero con distintos puertos.
1. Con 512MB irá más o menos como una RPi ¿no?
2. Es un DUAL, quizá si se pueda usar, ya te lo confirmaré
Si no me equivoco es esta o muy parecida a esta ARMStoneA5 (http://www.data-modul.com/us/news/current-news-overview/current-news-content/items/armstonea5-pico-itx-board-sbc-freescale-vybrid-cortexa5-and-cortexm4-536.html) y digo "si no me equivoco" porque en el panfleto que nos han dado aparece una tarjeta que no se ve claramente pero parece que tiene un puerto Ethernet, 2 USB y un HDMI, en el link aparece una SBC con dos Ethernet, USB y sin HDMI, y en el mismo link abajo del todo hay otro link para ver la SBC ampliada y aparece otra foto con otros conectores.... vamos, que hasta que no la vea en persona no se cual es exactamente, pero serán muy parecidas supongo.
En 5 horas nos tienen que dar este temario:
Agenda:
- Introducción F&S y descripción de Hardware armStoneA5
- ¿Qué es un Linux Embebido?
· Linux en las plataformas de F&S
· Uboot/Kernel/Rootfs
Configurando y compilando nuestro sistema
· Instalación de toolchain
· Compilación de Kernel
· Compilación Buildroots
Configurar y depurar aplicaciones utilizando Eclipse
Configurar y depurar interfaces gráficos (Qt)
Ejemplo utilización Vybrid (A5 + M4)
-
Los Vybrid estos son A5: no tengo experiencia con ellos.
El que mostraste es un A9 Dual pero un poco "capado": Freescale le llama DualLite y ese no tiene SATA: por eso me ha extrañado el conector.
La placa que enseñaste irá mejor que una RPI con 512MB simplemente xq el core es 5 veces más rápido. Aún así la RAM es un poco "cortita" para el micro: al menos para mi gusto ya que sólo la GPU se puede "comer casi 200MB...
El temario parece interesante: al menos intenta apuntar el nombre de las herramientas que te recomiendan utilizar, no te pierdas en intentar entenderlo todo porque es dificil a la primera.
Un saludo.
-
Bueno ya he aclarado un poco mis ideas.
Hoy he podido dedicarle un rato y ya tengo mi pantalla montada y bien configurada.
(http://imageshack.us/a/img716/8794/cvvc.png)
(si no consigo hacer aplicaciones con la RPi siempre puedo usarlo de marco digital de fotos :D, no ha quedado mal el metacrilato)
Ya solo falta que llegue el dongle wifi para no depender del cable de red y encontrar un touch para esta pantalla.
Además tengo instalado el Qt funcionando correctamente y ya he empezado ha hacer algunas cosas en C++, de momento solo aplicaciones en linea de comandos para aprender un poco de C++ pero espero que en breve pueda dar el salto a las ventanas.
Os adjunto unos manuales que he encontrado de C++ a pelo (linea de comandos) y de Qt + C++. De momento estoy centrado en el primero, pero deseando pasar al segundo para comenzar con las pantallas.
Aprenda C++ como si estuviera en primero (http://mec21.etsii.upm.es/ayudainf/aprendainf/cpp/manualcpp.pdf)
Aprenda QT hoy mismo (http://www.choccac.com/attachments/article/11/Aprenda_Qt4_Hoy_Mismo.pdf)
No se si esta semana me dará tiempo a hacer alguna aplicación con ventanas, porque primero quiero acabar el manual de C++ pero en todo caso iré poniendo aquí los avances que vaya haciendo.
Ahora la idea es:
1º Aprender/Entender al menos lo básico de C++
2º Aplicaciones QT con ventana, widgets, señales y slots
3º Compilar las aplicaciones QT de manera que funcionen en la RPi
4º Usar la GPIO para hacer alguna aplicación (de momento algo sencillo)
PD: Ayer estuve en una librería técnica y me sorprendió ver la cantidad de libros que hay de Arduino y Raspberry... Por casualidad encontré uno de Eagle en castellano que tiene muy buena pinta, habla sobre todo el proceso de diseño de PCBs, desde diseño de esquemáticos y PCB hasta procesos de fabricación y test (DISEÑO DE CIRCUITOS IMPRESOS CON EAGLE - ED.MARCOMBO) (estoy en el segundo capitulo todavía, ya os diré que tal)
-
Si tú o tu empresa os lo podéis permitir yo me iría directamente a Altium...
-
¿ que paquete de QT os habeis instalado ?
He intentado instalar la versión Online Installer para Windows, pero a mitad de proceso da errores al intentar descargar algunos archivos.
Como paquetes completos para Windows, hay cuatro para 32 bits, ni idea de las diferencias entre cada uno, he puesto a descargar el primero y el tercero:
Qt 5.1.1 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB) (Info)
Qt 5.1.1 for Windows 32-bit (VS 2010, 505 MB) (Info)
Qt 5.1.1 for Windows 32-bit (VS 2010, OpenGL, 504 MB) (Info)
Qt 5.1.1 for Windows 32-bit (VS 2012, 511 MB) (Info)
-
Si tú o tu empresa os lo podéis permitir yo me iría directamente a Altium...
Es para uso personal y como comprenderás no hay dinero para una licencia de 3000€ :D (ojalá pudiese)
En mi empresa, para que te hagas una idea, las dos o tres placas que he hecho para ellos las he hecho con el Eagle versión gratuita... :z) por suerte no eran placas muy complejas y me las he apañado con la versión free. Como microcontrolador usé PICs y tuve que usar la versión gratuita de MPLAB también, con eso te lo digo todo... Es una empresa de Ingenieros Mecánicos y para ellos la electrónica es secundario... Triste pero real. (Ahora que ellos si tienen todos sus licencias de SolidWorks al día).
En mi época de becario lo había usado en otra empresa y se nota la diferencia, pero para mis pruebas en casa con Eagle me las apaño bien, aunque tengo que decir que tengo en mente comprarme el libro de Altium de MCelectronics próximamente.
¿ que paquete de QT os habeis instalado ?
He intentado instalar la versión Online Installer para Windows, pero a mitad de proceso da errores al intentar descargar algunos archivos.
Como paquetes completos para Windows, hay cuatro para 32 bits, ni idea de las diferencias entre cada uno, he puesto a descargar el primero y el tercero:
Qt 5.1.1 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB) (Info)
Qt 5.1.1 for Windows 32-bit (VS 2010, 505 MB) (Info)
Qt 5.1.1 for Windows 32-bit (VS 2010, OpenGL, 504 MB) (Info)
Qt 5.1.1 for Windows 32-bit (VS 2012, 511 MB) (Info)
Planeta9999 instalate la versión Qt 5.1.1 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB).
Esta versión viene con el MinGW que es un compilador de GCC. Si no lo tendrás que instalar a parte.
A mi la única que me ha funcionado (ten en cuenta que soy novato y seguramente era culpa mia) es esta que te digo.
Los otros creo que son para usarlos con el Visual Studio, ahora no se decirte si es para usarlo desde el VS o si es para usar el compilador de Visual C++
-
Planeta9999 instalate la versión Qt 5.1.1 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB).
Esta versión viene con el MinGW que es un compilador de GCC. Si no lo tendrás que instalar a parte.
Acuerdate de que no te vale un compilador de x86: no vas a poder ejecutar nada en la RPI. Tienes que compilarlo con uno "cruzado" de x86 a ARM.
-
Planeta9999 instalate la versión Qt 5.1.1 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB).
Esta versión viene con el MinGW que es un compilador de GCC. Si no lo tendrás que instalar a parte.
Acuerdate de que no te vale un compilador de x86: no vas a poder ejecutar nada en la RPI. Tienes que compilarlo con uno "cruzado" de x86 a ARM.
Si si lo tengo claro, de momento estoy probando en Windows y cuando más o menos lo tenga controlado le instalare un compilador para ARM.
¿Sabéis alguno? (tengo que mirarlo todavía)
¿El compilador para ARM sería el mismo para una SOM profesional?
bueno paso a paso, a ver si aprendo en win de momento.
-
A nivel sistema de archivos para ti una RPI, una BBB o un módulo es lo mismo ya que todos son ARM. Miento un poquito: a nivel módulos (GPU, codecs, etc.) puedes tener problemas según la versión del compilador. Como estás ahora mismo te tiene que preocupar "cero".
A nivel Kernel es un rollo más diferente pero tampoco es tan dificil cambiar de plataforma.
No te preocupes: bájate algún compilador que te recomienden para RPI que verás que para ejecutar la misma aplicación sencilla en C++ te va a funcionar igual en la BBB o en cualquier otro "cacharro".
-
Hoy he estado en el seminario sobre SBC del fabricante F&S en concreto hemos tocado la armStoneA5 (http://www.fs-net.de/cms/index.php?id=71&tx_ttnews%5BbackPid%5D=5&tx_ttnews%5Btt_news%5D=267&cHash=79a4cd15128286be20528812ad0cf9d1) que a pesar de sus 256 MB de RAM me a sorprendido que en el mismo chip tengan un Cortex™A5-500MHz para el SO y un Cortex™M4-167MHz para trabajar con los GPIO en tiempo real.
(http://imageshack.us/a/img708/6521/qm0a.jpg)
(http://imageshack.us/a/img266/3889/4cs3.jpg)
(http://imageshack.us/a/img13/9844/cocd.jpg)
Contestando a las dudas de manwenwe:
Ta chula la plaquita.
Cuando vayas pregúntales 2 cosas:
1. ¿Por qué le han puesto sólo 512MB de RAM? Con eso van justitos para cargar un OS pesado (Android, Ubuntu, etc.) y mover la GPU al mismo tiempo.
2. ¿Por qué le han soldado un conector SATA si ese modelo no tiene SATA? :shock:. Te dirán que piensan poner un DUAL o QUAD en el futuro... "Pues sueldalo en el futuro" :D
Un saludo.
1. Supongo que la placa que dije en su día no era exactamente la que hemos tocado. No tiene 512MB en concreto esta tenía 256MB de RAM y 128MB de FLASH, pero pueden ampliar la RAM a 1Gb. Me han dicho que va en función del modelo de SBC, pero en su web ahora mismo no consigo encontrar el modelo de 1Gb.
2. No llevaba conectores SATA (la imagen que puse no se correspondía con esta)
La verdad que ha sido muy interesante porque nos han enseñado desde como compilar tu propio kernel para adaptarlo a tus necesidades a como programar con compilador cruzado con Eclipse y QT. Como era de esperar, mi nivel todavía no es el suficiente como para haberme quedado con todos los pasos que hay que seguir, pero el concepto lo he entendido.
Ellos configuraban el Eclipse y el QT para que además de compilar le enviara directamente por SSH el archivo compilado y lo ejecutaba en la SBC.
Por si a alguien le interesa, el distribuidor (Venco Electronics) tienen una oferta hasta final de mes del SBC+TFT+touch+cables (kit completo de la foto) por 150€
Ahora mi siguiente paso es conseguir configurar el QT para hacer la compilación cruzada con el RPi.
Si alguien sabe hacerlo que nos lo explique, si no en cuanto lo consiga intentare explicar los pasos aquí.
Como me han dicho hoy: Lo más engorroso es configurar el SO y el Toolchain, una vez hecho esto a programar... (vamos que me queda tener un poco de paciencia todavía :D)
-
Despues de toda una mañana dándole vueltas, creo que lo mejor es dejar Windows y pasar a Linux. Por lo que veo hacer el compilador cruzado desde Ubuntu por ejemplo, es "más" sencillo que desde Windows. Así que ya tengo escusa para pasar a Ubuntu :D
A ver si alguien puede resolverme unas dudas de QT:
En QT configuramos el compilador, la versión de QT y el Kit.
Compilador: en este caso entiendo que hay que descargar un compilador para ARM (me he descargado e instalado el GNU Tools ARM Embedded)
Versión de QT: Aquí ya patino un poco, por lo que veo hay que seleccionar un qmake para linux embebido, pero esto no se como se hace. Ahora mismo tengo el qmake del MinGW para windows. ¿Alguien sabe que he de hacer pasa ponerle el qmake para linux-arm?
Kit: Esta parte creo que si las otras dos las tienes bien, es solo seleccionar el compilador y version QT para linux-arm y creas un KIT. En mi caso cuando lo configure bien tendré el Kit para Windows y el Kit para Linux-ARM.
¿Estos es así? ¿Tengo las ideas básicas más o menos correctas? ¿Alguien me puede explicar lo del qmake?
Por lo que tengo entendido, además de todo esto, luego hay que instalar las librerias de QT en la RPI para que el programa que hagas no tenga que incluir todas las librerias y ser pesado.
Saludos!
-
Despues de toda una mañana dándole vueltas, creo que lo mejor es dejar Windows y pasar a Linux. Por lo que veo hacer el compilador cruzado desde Ubuntu por ejemplo, es "más" sencillo que desde Windows. Así que ya tengo escusa para pasar a Ubuntu
¿ Que te has montado una máquina virtual con VMware, para rodar Linux desde Windows ?.
Yo también estoy empezando el melón, y viendo por donde tirar, en mi caso para la Beaglebone Black, luego ya miraré con la Raspberry, que será practicamente lo mismo pero con otro procesador ARM.
-
Aprovechando la ocasión voy a usar un portátil sólo con ubuntu, pero todavía no lo tengo instalado.
Googleando he visto que es más facil hacer la compilación cruzada desde linux que desde windows.
De momento solo he probado con windows sin éxito.
En cuanto a usar RPi o beaglebone creo que será prácticamente lo mismo ya que las dos necesitan compilador ARM.
Cuando consiga hacer funcionar esto pongo los resultados.
-
Aprovechando la ocasión voy a usar un portátil sólo con ubuntu, pero todavía no lo tengo instalado.
Ubuntu "caca": ponte Fedora :D
-
Aprovechando la ocasión voy a usar un portátil sólo con ubuntu, pero todavía no lo tengo instalado.
Ubuntu "caca": ponte Fedora :D
¿Tanto así? No me gusta Unity, pero llevo usando Ubuntu desde el 2005, tanto de manera personal como en el trabajo (aunque en mi nuevo trabajo es prácticamente solo Windows), en mi anterior trabajo dejé dos desarrollos comerciales basados en Ubuntu, y nos respondió muy bien.
-
Pues parece más difícil de lo que pensaba, y mira que sencillo sabía que no iba a ser...
De momento estoy usando Ubuntu, pero no hay manera, no consigo configurar el compilador cruzado para trabajar con QT y RPi. He seguido los pasos de varias webs, pero no lo consigo.
He instalado el compilador de Linaro y lo he configurado en el QT, pero no se como conseguir hacer el qmake para RPi.
El estado en el que estoy es el siguiente:
- Instale QT en Ubuntu y probé que funcionase bien con una aplicación sencilla (funciona)
- Instale el compilador gcc-arm de linaro y lo tengo configurado en QT
- Tengo configurado el dispositivo "raspberry pi" en QT para que conecte por SSH (según el test de QT conecta correctamente)
- Me falta crear el qmake para RPi. He probado varios manuales, pero no me funciona y no se porque (o es que no entiendo los pasos, soy novato en linux).
- Me falta instalar en la RPi las librerías de QT para que funcionen las aplicaciones que cree con el QT de Ubuntu. He seguido manuales para hacerlo, pero no tengo claro de que funcione bien y como no he podido usar el compilador cruzado tampoco se si funciona correctamente.
Si alguien sabe hacer estos dos últimos pasos a ver si me puede echar una mano :oops:
Googleando he encontrado manuales de como hacerlo, pero no he encontrado a nadie que lo este haciendo funcionar, lo máximo que he encontrado es gente que instala el QT creator en la RPi y hace las aplicaciones directamente en la RPi, pero eso no es lo que quiero, yo quiero compilación cruzada.
Cuando usas SOM o SBC profesionales ¿los problemas son los mismos pero con mucha menos información o el fabricante ya te dice que tienes que hacer para configurarlo?
Bueno... yo sigo a lo mio, sigo probando... :huh:
-
Sigo con ello! No paro, tiene que salir como sea :D
Pasaba por aquí para dejar un enlace que me parece interesante. ***** BUILDROOT ***** (http://industriaembebidahoy.com/efsystems/node/59)
En cuanto consiga hacer la compilación cruzada no descarto hacer mi propia distribución para RPI :mrgreen: Además creo que saber usar el BUIDROOT es algo basico para luego dar el salto a las SOM y SBC profesionales (Algún experto que nos lo confirme).
Saludos
-
Buildroot es probablemente la herramienta que más mola para "embedded". El problema es que al final toca bailar al son de los que tocan la música: Texas, Freescale, etc. Si ellos deciden usar open embedded (p.e.: yocto) o ltib pues toca tragar. Más que nada porque portar un linux pelao de una plataforma a otra es accesible, en cambio hacer que funcionen cosas como la GPU puede llegar a ser una locura: si 10 ingenieros de Texas se han currao los drivers para que funcione con Yocto... a ver quien es el guapo que la hace funcionar con buildroot jeje.
Al final al que le compres las placas te va a dar la distro que le dio el fabricante con modificaciones en el kernel para su hardware y lo que le haya querido meter de más en el sistema de archivos (QT, algún RTOS, etc.)
Un saludo.
-
Buildroot es probablemente la herramienta que más mola para "embedded". El problema es que al final toca bailar al son de los que tocan la música: Texas, Freescale, etc. Si ellos deciden usar open embedded (p.e.: yocto) o ltib pues toca tragar. Más que nada porque portar un linux pelao de una plataforma a otra es accesible, en cambio hacer que funcionen cosas como la GPU puede llegar a ser una locura: si 10 ingenieros de Texas se han currao los drivers para que funcione con Yocto... a ver quien es el guapo que la hace funcionar con buildroot jeje.
Al final al que le compres las placas te va a dar la distro que le dio el fabricante con modificaciones en el kernel para su hardware y lo que le haya querido meter de más en el sistema de archivos (QT, algún RTOS, etc.)
Un saludo.
O sea que en teoría la parte de compilación de la distro te la ahorras.... interesante... me alegro de que sea así y poder quitarte un poco de lío de encima.
El otro día estuve mirando otras SOM profesionales y en el manual explicaba como hacer la compilación cruzada con Eclipse, supongo que la IDe y Toolchain también dependerá un poco de lo que te ofrezca el fabricante ¿no? a no ser que por tu cuenta quieras instalarte y configurarte la IDE o toolchain que te convenga.
Bueno os cuento un poco como voy con el tema:
No he avanzado mucho pero he aprendido cosas por el camino, supongo que eso es algo bueno aunque me gustaría haber visto ya mi "Hola mundo" :D
Probé de hacer la compilación cruzada con QT5 pero no lo he conseguido todavía, he visto en el foro de RPi gente que tampoco le ha funcionado la compilación cruzada con QT5, aunque creo que con la versión anterior QT4 si. O sea que me toca probar con QT4 a ver si con esta versión me va y es problema de que la versión QT5 esta muy reciente todavía.
Por otro lado me he liado ha probar el Builroot (no me he podido resistir :P) y lo mismo, he vuelto a fracasar :D, pero igual que decía anteriormente he aprendido cosas por el camino.
Mi intención era hacer una compilación de linux para la RPi incluyendo las tools de QT5.
De momento he conseguido hacer la imagen para la RPi, pero me he quedado en un punto muerto en el que no se si lo he compilado mal o es que no se crear o configurar bien los archivos de la imagen.
Una vez configurada y creada la imagen, configuraciones y root con el Buildroot me queda los siguiente:
1 archivo rootfs.tar
1 carpeta rpi-firmware
1 archivo zImage
rootfs.tar: En este tar se encuentran todos los directorios de la distribución. Se supone que tengo que extraerlo en la partición ext4 de la SD
rpi-firmware: En esta carpeta se encuentran los archivos de configuración y arranque de la RPi. Se supone que estos archivos debo copiarlos en la partición de arranque FAT32 de la SD
zImage: Este archivo es la Imagen de SO. Se supone que debo copiarla también en la particion FAT32 de arranque con la extensión .img
La cuestión es que he copiado todos los archivos y carpetas como indica el manual de Buildroot para tarjetas RPi, pero no me arranca la RPi, de hecho ni se entera, solo se enciende el led rojo de alimentación.
Bueno yo sigo persistente en el tema, a medida que tenga resultados (aunque no sean lo positivos que me gustaría que fueran) iré posteandolos aquí en el foro. Espero que al final todo salga bien y pueda poner un tutorial de como hacerlo por si alguien esta interesado... seguimos para bingo! ;-) :afro:
-
Prueba a crear una uImage en vez de una zImage.
Un saludo.
-
Parece que con uImage al menos arranca la pantalla
(http://imageshack.us/a/img6/9539/8a1q.jpg)
Se queda ahí, no hace nada más :huh:
voy a seguir investigando a ver... :rolleyes:
-
Bueno... he conseguido que aparezca algo :D
(http://imageshack.us/a/img844/8372/zwts.jpg)
Es la misma configuración que había hecho inicialmente con zImage. El problema estaba en que el archivo de configuración del boot estaba como kernel=zImage y yo lo había copiado como zImage.img. He añadido el .img al archivo de configuración y ha arrancado.
Ahora me aparece otro problema en el arranque:
Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux documentation/init.txt for guidance
Cada compilación me cuesta unas horas, por lo que por hoy creo que lo dejo... pero esto seguirá :mrgreen:
:afro:
-
Asegúrate de que la partición que le pasas al kernel para arrancar sea la correcta (root=/dev/mmcblk0p1 ó 2 etc. ).
Si no es esto puede ser que el kernel no soporte ext4, ahí tienes dos soluciones:
1. Reformatear el sistema de archivos en ext2. Peor solución ya que si no cierras bien el sistema siempre te acabarás cargando el sistema de archivos.
2. Habilitar ext3/ext4 en el kernel. Haz un "make menuconfig" y buscas esta opción. Luego yo haría un "make clean" antes de rehacer el kernel.
Un saludo y suerte!
-
Asegúrate de que la partición que le pasas al kernel para arrancar sea la correcta (root=/dev/mmcblk0p1 ó 2 etc. ).
Si no es esto puede ser que el kernel no soporte ext4, ahí tienes dos soluciones:
1. Reformatear el sistema de archivos en ext2. Peor solución ya que si no cierras bien el sistema siempre te acabarás cargando el sistema de archivos.
2. Habilitar ext3/ext4 en el kernel. Haz un "make menuconfig" y buscas esta opción. Luego yo haría un "make clean" antes de rehacer el kernel.
Un saludo y suerte!
Que grande manwenwe!! :-/ ya funciona, el problema era que había creado la partición en ext4, al pasarla a ext3 ya arranca.
Ahora debería estudiarme para que sirve cada opción de buildroot para crear una configuración aceptable ya que ahora mismo la que tengo funcionando no me detecta el ethernet (el usb si) y no reconoce muchos comandos como sudo, apt-get install y otros. Vamos que seguro que me he dejado muchas cosas por configurar.
Bueno, una vez visto el buidroot, creo que voy a volver a centrarme en el compilador cruzado. Instalaré la versión estandard de RPi y a probar el QT.
Tengo que decir que intente en varias ocasiones hacer una compilación de la configuración de Buildroot con las librerías de QT5 incluidas, pero me daba error...
Ya iré informando.
PD: Me he encontrado esta web googleando GNUBLIN (http://gnublin.embedded-projects.net/customized-boards/) parece que te fabrican SBC a medida... lo que me da la impresión de que son algo simples. Lo dejo como info por si a alguien le pueda interesar.
-
Si quieres que te detecte todo el hardware de forma automática habilita udev en el menuconfig y recompila, eso sí: tardará en arrancar unos segundos más. La ethernet no se levanta sola si no lo tienes configurado. Con "ifconfig eth0 up" debería levantarse.
Suerte con Qt: esto no va a ser nada fácil.
suerte!
PD.: Si quieres un Sbc a medida ves preparando XXXXX€ jejeje.
-
Enhorabuena por conseguirlo bitpic. Llevo leyendo el hilo desde su creación porque me parece muy interesante la experiencia con estos sistemas, de los que no tengo ni idea, pero creo que el destino me obligará a lidiar con ellos tarde o temprano.
A propósito, ¿qué significan las siglas SoC y SBC?
-
A propósito, ¿qué significan las siglas SoC y SBC?
Mea culpa, ya lo corregí: no quería decir SoC sino SBC.
SoC: System On Chip (el processador).
SoM: System On Module (una placa con el procesador + RAM y pocas cosas, se monta en una carrier board).
Carrier board: La placa base dónde se monta un SoM (lleva los perifericos y conectores).
SBC: Single Board Computer (SoM + Carrier en una sola placa, un pc completo).
-
Hola Nocturno, Gracias, pero estoy iniciándome, todavía me queda mucho por aprender. Aquí quien sabe es manwenwe, a ver si un día que tenga tiempo nos deleita con un proyecto suyo :P. Yo voy haciendo y siguiendo sus consejos :D
La idea de los SBC y SOM es tener un PC en nuestro sistema y hacer el control de TFT con touch, comunicaciones a través de la red, gestiones de ficheros con memoria USB, SD, etc más fácil que hacerlo con un microcontrolador. Digamos que sería más o menos como hacer un programa para PC.
Eso si, es más fácil porque el programa en si es como si programases en C o C++, pero arrancar el sistema y conseguir que todo funcione es lo complicado (al menos es mi experiencia hasta ahora).
Yo he estado trasteando estos días con el Buildroot que es un configurador del SO que instalas dentro de la SBC o SOM, pero en principio el fabricante debería darte un SO preparado para tu tarjeta. Esto lo he hecho más que nada para entender un poco el funcionamiento del Buildroot por si un día quiero configurar mi SO a medida.
O sea, que en principio en lo que nos deberíamos centrar es en hacer una compilación cruzada entre una IDE tipo QT o Eclipse para crear un programa en nuestro PC y ejecutarlo en la SBC o SOM.
Yo voy a probar con QT porque varía gente de este foro me lo ha recomendado y porque te permite hacer interfaz gráfica de manera más sencilla que con Eclipse.
A ver si esta semana que entra consigo hacer la compilación cruzada con QT y un RPi. En cuanto tenga un poco controlado esto seguramente intente hacerme con una SOM con carrier board para intentar dominarla y luego portarla a alguna carrier board que me haga yo, pero eso ya se vera, todavía queda un largo camino :lol:.
Manwenwe una pregunta: ¿Hacer la compilación cruzada con QT es siempre tan complejo o es solo con la RPi?
Saludos!!
-
No sabría que decirte bitpic. Yo es que solo trasteo con el kernel y con u-boot ya que como diseño yo el hardware es más fácil para mi lo de tocar los registros y cortar/pegar código: parecido a lo que se hace con un PIC. Y me lo dan todo ya configurado.
Mi socio es el que programa. Creo que compilar en Qt para ARM no es demasiado dificil. Lo jodido es instalar Qt con todos los complementos: que QML vaya acelerado por hardware, que funcionen todos codecs, etc. En esto si lo he visto tirarse dias: y eso que tiene muchos años de experiencia en Linux.
-
Bueno yo sigo con lo mio, no he parado (aunque no dispongo de todo el tiempo que me gustaría)
Antes de nada decir que plantea999 ha conseguido hacer compilación cruzada desde windows. Dejo aquí el link porque esta muy interesante Compilación cruzada desde Windows (http://www.todopic.com.ar/foros/index.php?topic=41729.msg347276#msg347276)
A ver si consigo hacerlo funcionar para poner un tutorial de como hacerlo desde Ubuntu.
Ahora estoy encallado con la compilación de librerias de QT para ARM. Para compilarlas para ARM hago lo siguiente:
./configure -embedded arm -little-endian -xplatform qws/linux-arm-gnueabi-g++
Parece que todo el proceso va bien, luego hago un make y un make install. Pero el problema me surge en el QTCreator.
Cuando voy a definir el compilador y el qmake, me dice que el qmake es para x86 y no para arm
(http://imageshack.us/a/img203/484/1ho2.png)
Como podéis ver el ABI me lo define como x86-linux-generic-elf-64bit y todo lo demás (qmake, QT_HOST...) como arm. Aunque tengo que decir que el directorio de qmake es uno y el de los QT_HOST_... es otro, no se si esto es normal.
Creo que es un problema, pero como soy principiante no estoy del todo seguro ¿Alguien sabe si esto es normal o no? ¿Como puedo solucionarlo?
La cuestión es que si lo dejo el ABI en x86 no puedo crear el Kit porque me dice que el compilador es para ARM y que el qmake es para x86 y no son compatibles.
:(
-
A mi también me da un error de ese tipo, pero no es más que un warning, me compila perfectamente, ya lo tengo todo resuelto y me funciona al 100% con RPI, solo tengo un problemilla de librerias con BBB, pero lo fundamental me va bien.
Lo importante es que tengas bien configurado el Compilador, la versión de QT y el Kit, con las vías de acceso correctas al compilador cruzado y a las librerías. No le hagas mucho caso al ABI, puedes editarlo y poner practicamente lo que quieras, debe de ser algo meramente informativo.
-
Bueno he avanzado algo :-/
He conseguido compilar las librerias sin errores. Antes tenía ese problema por que me daba dos errores al compilar las librerías.
El problema era que no había definido correctamente la ruta del compilador dentro del archivo qmake.conf que he creado para la RPi.
Ahora QT me reconoce correctamente el qmake y me aparece como "Qt version 4.8.5 for Embedded Linux"
(http://imageshack.us/a/img842/1940/13ee.png)
Puedo crear bien el Kit de QT y me compila, aunque no me conecta por SSH directamente el QT para enviar el programa a la RPi. Tengo configurado el dispositivo en las opciones de QT para que conecte con la RPi por SSH y haciendo un test manual conecta correctamente, pero por alguna razón todavía no conecta automaticamente para enviar el programa. Me lo mirare tranquilamente.
He compilado, parece que funciona bien, y he subido el programa por SSH a mano, pero al tratar de ejecutarlo en la RPi me da un error de "Violación de segmento" :o
Por su puesto algo mal he hecho o me he dejado algo por configurar, pero tengo que averiguar el qué todavía. Si alguien tiene alguna idea será bien venida :)
-
Puedo crear bien el Kit de QT y me compila, aunque no me conecta por SSH directamente el QT para enviar el programa a la RPi. Tengo configurado el dispositivo en las opciones de QT para que conecte con la RPi por SSH y haciendo un test manual conecta correctamente, pero por alguna razón todavía no conecta automaticamente para enviar el programa. Me lo mirare tranquilamente.
Yo tampoco he conseguido, por el momento, configurar el Deployment del Run Settings, para que QT suba automáticamente el binario compilado, nada más terminar la compilación, además sin esa configuración creo que tampoco se puede hacer Debug, porque los dos iconos para Ejecutar y Ejecutar con Debug aparecen apagados.
He compilado, parece que funciona bien, y he subido el programa por SSH a mano, pero al tratar de ejecutarlo en la RPi me da un error de "Violación de segmento" :o
Por su puesto algo mal he hecho o me he dejado algo por configurar, pero tengo que averiguar el qué todavía. Si alguien tiene alguna idea será bien venida :)
Comprueba que las librerías y cabeceras sean exactamente las mismas en el PC y en la placa, o aunque compile en el PC, luego casca al intentar ejecutar el binario en la placa, a mi me está pasando con la BBB, porque hay una librería compartida con un nombre distinto, y aunque he sincronizado PC y BBB, el problema es al contrario, hay una librería de QT en el PC, que en la BBB tiene añadida una E como sufijo al nombre.
-
Puedo crear bien el Kit de QT y me compila, aunque no me conecta por SSH directamente el QT para enviar el programa a la RPi. Tengo configurado el dispositivo en las opciones de QT para que conecte con la RPi por SSH y haciendo un test manual conecta correctamente, pero por alguna razón todavía no conecta automaticamente para enviar el programa. Me lo mirare tranquilamente.
Acabo de resolver ese tema, después de darle mil vueltas y buscar parámetros por todos los lados, lo he probado y va de narices, ahora ya sube automáticamente el ejecutable a la RPI tras la compilación y también hace debug. En un ratillo subo la solución al post que he abierto para QT con Windows, creo que te funcionará igual en Linux.
Lo que me ha llamado la atención, es que el ejecutable cuando lo ruedas desde Qt, el formulario y los botones se muestran en la pantalla que tengo conectada al RPI, no en la pantalla del PC, con VisualGDB es al revés, cuando ruedas el ejecutable desde Visual Studio, el formulario y los botones del programa salen en la pantalla del PC, que curioso.
También he conseguido una parametrización mejor de qmake, para que se pueda usar el que crea QT por omisión en el proyecto.
La verdad es que esto de Qt con RPI o BBB, va de cojones. Lo próximo que quiero hacer es pincharle unos LED al GPIO y hacer un programita sencillo con varios botones en pantalla que enciendan los led con varias secuencias.
:-/ :-/
-
Que bueno planeta999! Me alegro por todos los avances que has hecho en tan poco tiempo.
Ahora estoy trabajando, pero en cuanto llegue a casa si tengo tiempo pruebo lo de las librerías
Viendo lo que has conseguido en tan poco tiempo en windows estoy por volver a él porque en Linux me estoy volviendo loco :D. Además que los demás IDEs y herramientas que uso los tengo en windows.
Una cosa, veo que con el GNUTOOLCHAINS dependes un poco de SysProg en cuanto a compilador GCC. Mi idea principal para iniciarme en el mundo QT era para aprender a programar SOM y SBC de uso profesional.
Me surgen las siguientes dudas:
¿Es posible desde windows programar una SBC o SOM profesional con las herramientas que has usado en windows?
¿El compilador es genérico para todas lass SBC o SOM o hay que usar uno especifico que proporcionará el fabricante?
¿Los toolchais que ofrece Sysprog sirven para gran cantidad de SBC y SOM o es un poco limitado?
Como hasta ahora lo estoy haciendo todo a mano en Linux supongo que más o menos la complejidad será parecida, pero si con las toolchais de Sysprog tienes un buen abanico de opciones me plantearía usar de momento esas herramientas por la facilidad de uso.
Quizá alguien con experiencia en estas tarjetas nos pueda iluminar mejor, pero cuando me pongo a mirar manuales de TARGETs profesionales como por ejemplo el de este link Manual (http://www.congatec.com/fileadmin/user_upload/Documents/Manual/QMX6ms01.pdf) ves que es bastante complejo iniciarse y te planteas si es necesario comerse tanto la cabeza...
Buenso pongo aquí un resumen de lo aprendido hasta ahora, a ver si van quedando claras las ideas:
HOST:
- Instalar QT
- Instalar compilador GCC para correr en tu TARGET
- Instalar las librerías QT Embedded
- Configurar el qmake con los parámetros de tu TARGET y las librerías GCC que vas a usar (Especificar directorios de las librerías GCC correctamente)
- Configurar en QT el compilador y el qmake de tu TARGET y crear el KIT
TARGET:
- Instalar librerías GCC en el mismo directorio que en el HOST
- Instalar librerías QT Embedded en el mismo directorio que en el HOST
- Y por ultimo crear tu aplicación en el HOST y transferirlo al TARGET.
-
Viendo lo que has conseguido en tan poco tiempo en windows estoy por volver a él porque en Linux me estoy volviendo loco :D. Además que los demás IDEs y herramientas que uso los tengo en windows.
A mi ya me funciona al 100% bajo Windows, si no eres linuxero, vale la pena seguir con Windows.
Una cosa, veo que con el GNUTOOLCHAINS dependes un poco de SysProg en cuanto a compilador GCC. Mi idea principal para iniciarme en el mundo QT era para aprender a programar SOM y SBC de uso profesional.
No, que va, no dependes para nada de Sysprogs, date cuenta de que lo que facilita Sysprogs son realmente "instaladores", ellos han cogido todo el software gratuito (GCC, GDB y Binutils), lo han empaquetado y han creado un instalador, para facilitar la tarea de instalarlo todo del tirón, pero TODAS las herramientas las puedes conseguir individualmente en las web correspondientes, y totalmente gratis.
Por ejemplo GCC para ARM que también incluye GDB (gestor para hacer Debug), lo tienes en esta web: https://launchpad.net/linaro-toolchain-binaries
De hecho el instalador de Sysprogs te está instalando la versión 4.6.3 de GCC, cuando la versión actual ya va por la 4.8.2, quiero bajarla y probarla para tener siempre la última versión.
Y en cuanto al QTCrosstool, no es más que un programa que conecta con la tarjeta por SSH y se descarga al PC, varios directorios de usuario, para tenerlos sincronizados, eso mismo lo puedes hacer a mano conectando con Smartty, Putty o cualquier otro programa con soporte SSH, y bajarte archivos o directorios completos.
Me surgen las siguientes dudas:
¿Es posible desde windows programar una SBC o SOM profesional con las herramientas que has usado en windows?
Seguro que si, solo tienes que conseguir el compilador adecuado, a mi me parece que GNU GCC para ARM, soporta todos los procesadores ARM, y si sale alguno nuevo, lo van añadiendo en nuevas versiones del compilador. Por ejemplo, he visto en la web de Sysprogs, que también facilitan un instalador del Toolchain para los STM32, lo quiero probar porque me parece que con Qt también se podrían trabajar con estos micros, el entorno es muy cómodo e infinitamente más fácil de configurar que Eclipse.
No creo que los fabricantes de micros, se dediquen a diseñar compiladores, creando productos cerrados que les van a matar el mercado.
¿El compilador es genérico para todas lass SBC o SOM o hay que usar uno especifico que proporcionará el fabricante?
No se ahora mismo que familias de micros ARM soporta GCC, por ejemplo la versión ARM Embedded soporta Cortex-M0/M0+/M3/M4, Cortex-R4/R5/R7, y el linaro soporta seguro los SOC de la RPI y la BBB. Tengo la sensación de que cualquier micro ARM, se puede trabajar con GCC.
¿Los toolchais que ofrece Sysprog sirven para gran cantidad de SBC y SOM o es un poco limitado?
Sysprogs, como he comentado, lo que facilita son instaladores de toolchains que incluyen GCC, GDB y Binutils, puedes prescindir de esos instaladores e instalar manualmente cada producto por separado, aquí tienes compiladores GCC ARM para varias plataformas:
https://launchpad.net/linaro-toolchain-binaries
https://launchpad.net/gcc-arm-embedded
Las Binutils: http://www.gnu.org/software/binutils/
Make: http://www.gnu.org/software/make/
Como hasta ahora lo estoy haciendo todo a mano en Linux supongo que más o menos la complejidad será parecida, pero si con las toolchais de Sysprog tienes un buen abanico de opciones me plantearía usar de momento esas herramientas por la facilidad de uso.
Para la instalación inicial es lo ideal, te lo dan todo mascado, si luego quieres actualizar a versiones más actuales, ya habrá que ir a las web de cada proyecto (GCC, GDB, Binutils, Qmake, Make).
Buenso pongo aquí un resumen de lo aprendido hasta ahora, a ver si van quedando claras las ideas:
HOST:
- Instalar QT
- Instalar compilador GCC para correr en tu TARGET
- Instalar las librerías QT Embedded
- Configurar el qmake con los parámetros de tu TARGET y las librerías GCC que vas a usar (Especificar directorios de las librerías GCC correctamente)
- Configurar en QT el compilador y el qmake de tu TARGET y crear el KIT
TARGET:
- Instalar librerías GCC en el mismo directorio que en el HOST
- Instalar librerías QT Embedded en el mismo directorio que en el HOST
- Y por ultimo crear tu aplicación en el HOST y transferirlo al TARGET.
En el kit también tienes que definir el path de mkspecs, para que el compilador encuentre el qmake.conf adecuado, y en el proyecto (archivo .pro) hay que definir unos parámetros para que funcione el deployment para el vuelco automático del binario a la tarjeta y para el Debug.
Por cierto, ayer estuve probando el Debug, y va de fábula.
-
Si quieres probar lo del traspaso automático del programa compilado desde Qt a la RPI y el Debug, acabo de añadirlo en el manual que he posteado, también he hecho algunos cambios en la configuración del kit para el make y el qmake. http://www.todopic.com.ar/foros/index.php?topic=41770.msg347539;topicseen#msg347539
Yo creo que te funcionará igual en Linux, pero si prefieres hacerlo en Windows, ya va todo al 100%. Mi próximo reto es conseguir que Qt también pueda compilar para los ARM STM32 de la Discovery.
-
No hay manera, algo tengo mal. Me he dado cuenta que al hacer el make de las librerías de qt me da dos errores, seguramente sea ese el problema.
make[1]: *** [.obj/release-shared-emb-arm/pixman-arm-neon-asm.o] Error 1
make[1]: se sale del directorio «/opt/qt-everywhere-opensource-src-4.8.5/src/gui»
make: *** [sub-gui-make_default-ordered] Error 2
En la IDE de QT me reconoce el qmake aun teniendo estos errores, pero me da a mi que es posible que este sea el motivo de que no me funcione la aplicación en la RPi.
:?
Me da a mi que voy a tener que volver a windows.... :oops:
-
No hay manera, algo tengo mal. Me he dado cuenta que al hacer el make de las librerías de qt me da dos errores, seguramente sea ese el problema.
make[1]: *** [.obj/release-shared-emb-arm/pixman-arm-neon-asm.o] Error 1
make[1]: se sale del directorio «/opt/qt-everywhere-opensource-src-4.8.5/src/gui»
make: *** [sub-gui-make_default-ordered] Error 2
En la IDE de QT me reconoce el qmake aun teniendo estos errores, pero me da a mi que es posible que este sea el motivo de que no me funcione la aplicación en la RPi.
:?
Me da a mi que voy a tener que volver a windows.... :oops:
¿ en el Kit le has apuntado a las mkspecs correctas ?, es importante, para que el qmake lea el archivo de configuración qmake.conf correspondiente a la plataforma de destino del objeto, yo tuve algún problema con eso hasta que lo descubrí.
-
¿ en el Kit le has apuntado a las mkspecs correctas ?, es importante, para que el qmake lea el archivo de configuración qmake.conf correspondiente a la plataforma de destino del objeto, yo tuve algún problema con eso hasta que lo descubrí.
Esta es la configuración que tengo:
(http://imageshack.us/a/img189/7729/j8qr.png)
Yo diría que si, el directorio que aparece es donde tengo el qmake.conf de la RPi, pero aun así me aparece un error en el KIT de "Mkspecs not found for Qt version".
Veo que tu directorio de mkspecs esta dentro del directorio del compilador... a mi dentro del directorio del compilador no me aparece la carpeta mkspecs. La tengo dentro del directorio de las librerías de Qt
He conseguido corregir los errores que comentaba antes, pero ahora me aparece otro. Voy a ver si consigo hacer toda la configuración del qmake sin errores para descartar que venga de ahí el problema.
-
Esto es lo que me aparece ahora cuando configuro el qmake:
make[1]: se sale del directorio «/opt/qt-everywhere-opensource-src-4.8.5/translations»
Al menos ahora no lo marca como error, pero me queda la duda de si estará bien configurado.
La verdad es que hacer la configuración del qmake con linux es algo pesado, ya que cada configuración tarda unas 2 horas o más en finalizar... Supongo que si lo haces bien a la primera no importa tanto, pero cuando no te funciona se ha ce bastante pesado...
-
Esto es lo que me aparece ahora cuando configuro el qmake:
make[1]: se sale del directorio «/opt/qt-everywhere-opensource-src-4.8.5/translations»
Al menos ahora no lo marca como error, pero me queda la duda de si estará bien configurado.
La verdad es que hacer la configuración del qmake con linux es algo pesado, ya que cada configuración tarda unas 2 horas o más en finalizar... Supongo que si lo haces bien a la primera no importa tanto, pero cuando no te funciona se ha ce bastante pesado...
¿ 2 horas te tarda el proceso qmake ?, eso es una barbaridad, a mi el qmake me procesa en cuestión de segundos para crear el makefile, e inmediatamente me pasa al make para crear objetos y lincar.
Este es mi qmake.conf
#Generated QT specs file for cross-compiling
MAKEFILE_GENERATOR = UNIX
TARGET_PLATFORM = unix
TEMPLATE = app
CONFIG += qt warn_on release incremental link_prl
QT += core gui
QMAKE_INCREMENTAL_STYLE = sublib
include(../common/linux.conf)
include(../common/gcc-base-unix.conf)
include(../common/g++-unix.conf)
# modifications to g++.conf
QMAKE_CC = C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-gcc.exe
QMAKE_CXX = C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe
QMAKE_LINK = C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe
QMAKE_LINK_SHLIB = C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe
# modifications to linux.conf
QMAKE_AR = C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-ar.exe cqs
QMAKE_OBJCOPY = C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-objcopy.exe
QMAKE_STRIP = C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-strip.exe
QMAKE_COPY = copy /y
QMAKE_COPY_DIR = xcopy /s /q /y /i
QMAKE_MOVE = move
QMAKE_DEL_FILE = del
QMAKE_MKDIR = mkdir
QMAKE_DEL_DIR = rmdir
QMAKE_MOC = C:/SysGCC/raspberry/Qt/v4/moc.exe
QMAKE_UIC = C:/SysGCC/raspberry/Qt/v4/uic.exe
QMAKE_IDC = C:/SysGCC/raspberry/Qt/v4/idc.exe
QMAKE_CFLAGS += -Wno-psabi
QMAKE_CXXFLAGS += -Wno-psabi
load(qt_config)
-
Si, dos horas....!! cada vez tengo más ganas de volver a Windows jaajaj
Por eso me desespero, cada prueba me lleva un día prácticamente y se hace pesado, yo lo que quiero es programar sistemas SOM y SBC, no volverme loco con la configuración de Linux y el QT :?
Ahora mismo estoy probando otra configuración a ver que tal...
Una pregunta, ¿en la RPi solo haces esto?
sudo apt-get update
sudo apt-get install libqt4-dev
¿No hace falta bajarte las librerías "Qt libraries 4.8.5 for embedded Linux" y crearte el qmake en la RPi? Me sigue saliendo "Violación de segmento" cuando intento ejecutar la aplicación que he hecho en QT y estoy pensando que igual tiene que ver con las librerías...
-
Una pregunta, ¿en la RPi solo haces esto?
sudo apt-get update
sudo apt-get install libqt4-dev
Si, con eso se instala en la RPI todo lo necesario.
¿No hace falta bajarte las librerías "Qt libraries 4.8.5 for embedded Linux" y crearte el qmake en la RPi? Me sigue saliendo "Violación de segmento" cuando intento ejecutar la aplicación que he hecho en QT y estoy pensando que igual tiene que ver con las librerías...
No, en la RPI no creo nada, solo subo las librerías.
Lo que si que hago es sincronizar las librerias RPI/PC con el programita de Sysprogs que baja al PC en el directorio sysroot, todo el arbol de directorios etc, lib y usr de la RPI. Es importante que en ambos estén exactamente las mismas librerías, sobre todo las compartidas, si no aunque te compile en el PC, cascará al ejecutar en la RPI, a mi eso me pasa con la BBB y aún lo tengo que resolver.
-
Pues ahora mismo ha acabado el ./config en la RPi, esta vez a tardado más porque he intentado instalar las librerías completas en la RPi. Aun así me han salido dos errores.
Me he dado cuenta que en el PC si haces la configuración bien y no tiene errores, te crea un directorio con todas las librerías y el qmake correcto, hasta ahora lo estaba configurando mal en el QT porque al no instalar bien las librerías no me creaba todos los directorios y archivos.
Tenía mal tanto el qmake como el directorio del mkspec
Ahora estoy tratando de instalar y configurar bien las librerías en la RPi, probablemente no arranca el programa porque no se han instalado correctamente las librerías. Ahora me falta encontrar la configuración correcta y hasta dar con ella me supondrá unas cuantas horas de intentos.
Supongo que la gente que domina Linux le resultará más sencillo, pero yo no soy ningún experto en Linux y me resulta más útil una instalación tipo Windows, porque te permite centrarte en tu solución final y no tener que estar haciendo configuraciones y de mas...
A ver si lo soluciono estos días, si no me pasaré a Windows y seguiré tu manual, así podré centrarme en aprender a programar la RPi. Quizá así vea toda la configuración funcionando y vea cual es el problema que tengo en Linux.
-
Como los pasos para configurar las librerias QT se convierten en largos a la hora de instalar las librerías (estoy esperando que acaben en este preciso momento), me vais a permitir que ponga aquí los pasos que he seguido hasta ahora para intentar hacer la compilación cruzada entre QT creator instalado en Ubuntu y la SBC Raspberry PI para aprovechar el tiempo muerto entre compilación y compilación.
Primero de todo, hay que abrir el "Centro de software de Ubuntu" y buscar "QT Creator" e instalarlo.
Una vez instalado tenemos que configurar e instalar las librerías de "Qt libraries 4.8.5 for embedded Linux" y el compilador Linaro tanto en el PC como en la RPi:
Instalando librerias en el PC:
En mi caso voy a descargar e instalar tanto compilador como librerías en la carpeta /opt/ de Ubuntu. Así lo tendré todo localizado en la misma carpeta para mas tarde instalar las librerias y compilador en el mismo directorio pero en la Rpi
- El primer paso sería abrir el terminal y nos vamos a la carpeta /opt
cd /opt
- Luego descargamos el compilador en esta carpeta, para ello ejecutamos lo siguiente:
wget http://swap.tsmt.eu/gcc-4.7-linaro-rpi-gnueabihf.tbz
- Descomprimimos el compilador:
tar xvf gcc-4.7-linaro-rpi-gnueabihf.tbz
- Ahora ya tenemos el compilador en la ruta /opt/gcc-4.7-linaro-rpi-gnueabihf
- Volvemos a la carpeta /opt y descargamos las librerías de QT Embedded:
wget http://download.qt-project.org/official_releases/qt/4.8/4.8.5/qt-everywhere-opensource-src-4.8.5.tar.gz
- Descomprimimos la librerías:
tar xvf qt-everywhere-opensource-src-4.8.5.tar.gz
- Ahora tenemos en el directorio /opt una carpeta con el compilador y otra con las librerías de QT. En mi caso he creado otro directorio dentro de /opt donde instalaré las librerías de QT. Yo he llamado al directorio QtEmbedded, y para crearlo hay que hacer lo siguiente dentro del directorio /opt
mkdir QtEmbedded
- Llegado este punto vamos a comenzar a configurar e instalar las librerías de QT, Primero vamos a crear nuestro qmake.conf con la configuración que necesitamos para la RPi, para ello vamos al directorio mkspecs/qws de las librerías:
cd qt-everywhere-opensource-src-4.8.5/mkspecs/qws/
- Creamos una carpeta que vamos a llamar linux-rpi-g++:
mkdir linux-rpi-g++
- Vamos a coger como patrón los archivos de la carpeta linux-armv6-g++, así que copiamos el contenido de esta carpeta en la que hemos creado para la RPi
cp linux-armv6-g++/* linux-rpi-g++
- Ahora entramos en la carpeta que hemos creado para la RPi
cd linux-rpi-g++
- y editamos el archivo qmake.conf
gedit qmake.conf
- Modificamos el archivo para que apunte al directorio donde tenemos nuestro compilador, quedará algo como lo siguiente:
#
# qmake configuration for building for ARMv6 devices with arm-linux-g++
#
include(../../common/linux.conf)
include(../../common/gcc-base-unix.conf)
include(../../common/g++-unix.conf)
include(../../common/qws.conf)
# modifications to g++.conf
QMAKE_CC = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-gcc
QMAKE_CXX = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
QMAKE_LINK = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
QMAKE_LINK_SHLIB = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
QMAKE_CFLAGS += -march=armv6
QMAKE_CXXFLAGS += -march=armv6
# modifications to linux.conf
QMAKE_AR = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-ar cqs
QMAKE_OBJCOPY = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-objcopy
QMAKE_STRIP = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-strip
load(qt_config)
- Guardamos y salimos.
- Volvemos al directorio principal de las librerías para lanzar el ./config, Ejecutamos "cd .." hasta estar en el directorio /opt/qt-everywhere-opensource-src-4.8.5/
- En mi caso la configuración que he usado para lanzar el ./config es el siguiente:
./configure -embedded arm -xplatform qws/linux-rpi-g++ -nomake tools -nomake examples
-nomake demos -prefix /opt/QtEmbedded -debug -little-endian -no-qt3support -qt-sql-sqlite -host-little-endian
-webkit -nomake tests -opensource -no-pch
- Algunos datos:
-embedded arm: Con esta linea decimos que queremos lo configure para usarlas en un sistema ARM, en nuestro caso la RPi
-xplatform qws/linux-rpi-g++: Esta linea indica donde esta el archivo qmake.conf que queremos que use para configurar el qmake
-prefix /opt/QtEmbedded: Indica donde instalará las librerías QT. Esta carpeta es la que hemos creado inicialmente.
- Ejecutamos y cuando finalice hacemos un "make"
- Cuando finalice el make ejecutamos un "make install". Es importante que el make no nos de errores, si no no se instalarán correctamente las librerias
Si todo ha ido bien ya podemos ir al QT Creator para configurarlo.
- Abrimos QT Creator y vamos a Tools-->Options y dentro de Options vamos a la pestaña "Devices", aquí vamos a configurar nuestro dispositivo, en nuestro caso la RPi. Por tanto añadimos uno nuevo y seleccionamos "Generic Linux Device"
(http://imageshack.us/a/img824/5729/b1tu.png)
- Aceptamos y configuramos el nombre, la IP de nuestro dispositivo, el nombre de usuario (por defecto "pi") y el password (por defecto "raspberry")
(http://imageshack.us/a/img841/911/yjrh.png)
- Nos quedará algo así:
(http://imageshack.us/a/img809/8585/87b7.png)
- Aplicamos los cambios y vamos a la pestaña Build&Run.
-Dentro de esta pestaña nos vamos a la que pone Compilers y añadimos uno nuevo, en mi caso le he llamado GCC ARM y le indicamos donde esta nuestro compilador (/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++)
Quedará algo así:
(http://imageshack.us/a/img32/8121/o4nw.png)
- Ahora vamos a pestaña QT Versions y creamos uno nuevo. En mi caso le he llamado "Qt 4.8.5 (arm)"
- Indicamos donde esta el qmake que hemos creado. En nuestro caso habíamos definido la carpeta QtEmbedded que es donde se han instalado las librerías de QT y el qmake
(/opt/QtEmbedded/bin/qmake)
Quedará algo así:
(http://imageshack.us/a/img833/5309/iwp4.png)
- Si la instalación de las librerías ha ido bien y la configuración del QT Version es correcta nos indicará que nuestra versión de QT es "Qt version 4.8.5 for Embedded Linux"
- Como punto final configuramos el KIT, para ello vamos a la pestaña "Kits" y creamos un Kit nuevo. En mi caso le he llamado RPI y configuramos las opciones como en la imagen:
(http://imageshack.us/a/img202/2756/8bdh.png)
******* Hasta aquí toda la configuración del PC, en este caso en Ubuntu ****************
Instalando librerias en la RPi:
- Igual que hemos hecho en el PC, nos vamos a la carpeta /opt para bajar e instalar el compilador y las librerías.
- Primer paso, vamos a la carpeta /opt :
cd /opt
- Dentro de esta carpeta volvemos a repetir los pasos que hemos realizado en el PC. Primero descargamos el compilador
wget http://swap.tsmt.eu/gcc-4.7-linaro-rpi-gnueabihf.tbz
- Descomprimimos el compilador:
tar xvf gcc-4.7-linaro-rpi-gnueabihf.tbz
- Ahora ya tenemos el compilador en la ruta /opt/gcc-4.7-linaro-rpi-gnueabihf
- Volvemos a la carpeta /opt y descargamos las librerías de QT Embedded:
wget http://download.qt-project.org/official_releases/qt/4.8/4.8.5/qt-everywhere-opensource-src-4.8.5.tar.gz
- Descomprimimos la librerías:
tar xvf qt-everywhere-opensource-src-4.8.5.tar.gz
- Ahora tenemos en el directorio /opt una carpeta con el compilador y otra con las librerías de QT. En mi caso he creado otro directorio dentro de /opt donde instalaré las librerías de QT. Yo he llamado al directorio QtEmbedded, y para crearlo hay que hacer lo siguiente dentro del directorio /opt
mkdir QtEmbedded
- Llegado este punto vamos a comenzar a configurar e instalar las librerías de QT, Primero vamos a crear nuestro qmake.conf con la configuración que necesitamos para la RPi, para ello vamos al directorio mkspecs/qws de las librerías:
cd qt-everywhere-opensource-src-4.8.5/mkspecs/qws/
- Creamos una carpeta que vamos a llamar linux-rpi-g++:
mkdir linux-rpi-g++
- Vamos a coger como patrón los archivos de la carpeta linux-armv6-g++, así que copiamos el contenido de esta carpeta en la que hemos creado para la RPi
cp linux-armv6-g++/* linux-rpi-g++
- Ahora entramos en la carpeta que hemos creado para la RPi
cd linux-rpi-g++
- y editamos el archivo qmake.conf
gedit qmake.conf
- Modificamos el archivo para que apunte al directorio donde tenemos nuestro compilador, quedará algo como lo siguiente:
#
# qmake configuration for building for ARMv6 devices with arm-linux-g++
#
include(../../common/linux.conf)
include(../../common/gcc-base-unix.conf)
include(../../common/g++-unix.conf)
include(../../common/qws.conf)
# modifications to g++.conf
QMAKE_CC = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-gcc
QMAKE_CXX = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
QMAKE_LINK = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
QMAKE_LINK_SHLIB = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
QMAKE_CFLAGS += -march=armv6
QMAKE_CXXFLAGS += -march=armv6
# modifications to linux.conf
QMAKE_AR = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-ar cqs
QMAKE_OBJCOPY = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-objcopy
QMAKE_STRIP = /opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-strip
load(qt_config)
- Guardamos y salimos.
- Volvemos al directorio principal de las librerías para lanzar el ./config, Ejecutamos "cd .." hasta estar en el directorio /opt/qt-everywhere-opensource-src-4.8.5/
- En mi caso la configuración que he usado para lanzar el ./config es el siguiente:
./configure -embedded arm -xplatform qws/linux-rpi-g++ -nomake tools -nomake examples
-nomake demos -prefix /opt/QtEmbedded -debug -little-endian -no-qt3support -qt-sql-sqlite -host-little-endian
-webkit -nomake tests -opensource -no-pch
- Algunos datos:
-embedded arm: Con esta linea decimos que queremos lo configure para usarlas en un sistema ARM, en nuestro caso la RPi
-xplatform qws/linux-rpi-g++: Esta linea indica donde esta el archivo qmake.conf que queremos que use para configurar el qmake
-prefix /opt/QtEmbedded: Indica donde instalará las librerías QT. Esta carpeta es la que hemos creado inicialmente.
- Ejecutamos y cuando finalice hacemos un "make"
- Cuando finalice el make ejecutamos un "make install". Es importante que el make no nos de errores, si no no se instalarán correctamente las librerías
******** HASTA AQUÏ LA CONFIGURACION ********
Si todo ha ido bien, ya podemos crear la aplicación en QT en el PC y pasarla a la RPi para ejecutarla. El problema que tengo ahora mismo es que la parte del ./config no me funciona correctamente y me da errores. Creo que este es el motivo principal por el que creo que no funcionan los programas que hago en QT.
Como podéis ver, en Linux esta configuración lleva su tiempo y son procesos un poco largos. Entre prueba y prueba pueden pasar varías horas, de hecho llevo todo el día (desde las 8 de la mañana) y solo he podido hacer 3 pruebas. Ahora mismo estoy haciendo la ultima (ya son las 00:32 de la noche).
Tengo que decir (muchos ya lo sabéis o lo habéis notado) que soy principiante tanto en QT como en Ubuntu, por lo que puede que una persona que los domine lo tenga todo configurado en unas horas, pero a mi a día de hoy se me esta haciendo un poco pesado todo este proceso.
Bueno, sigo luchando, no me doy por vencido. Cualquier ayuda será bien venida.
(La semana que viene puede que tenga que pararlo un tiempo por necesidad de usar Windows para otro proyecto, pero intentaré llegar a la solución final en la medida que me sea posible)
-
Nada, 16 horas compilando y nada... me sigue apareciendo el siguiente mensaje al intentar ejecutar el programa:
pi@raspberrypi ~ $ ./PruebaRPI
Violación de segmento
Creo que por esta semana C'est Fini... :5]
-
No sé si será un SoC, SBC u otro pero han sacado esta nueva versión del RaspberryPi: el Rasbperry Pi compute module.
http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/