Si no recuerdo mal una de las peores cosas que tenía esta placa era que el ethernet iba por SPI y esto creaba un cuello de botella

Creo que te equivocas en la IGEPv2 el controlador de Ethernet utiliza el bus de Memoria (REF: LAN9221i no es SPI). De hecho el ethernet por SPI es utilizado en algunas placas de expansión de la beagleboard.
Saludos
worsy

Sin baterías no la hemos probado, pero parece ser que el consumo es bajo para lo que es, pero elevado si lo comparamos con un PIC de pico potencia o un AVR a femtowatios. Es un tema que sí que queremos probar, pero las condiciones son variadas, pues no es lo mismo usar la interfaz de video con un TFT, por ejemplo que usarlo para controlar un robot por wifi con el mínimo consumo de potencia por parte de periféricos.

Muy guapa la beagle xM, pero sigo prefiriendo algo que lleve WiFi. Al fin y al cabo, me interesa la movilidad, no un elemento fijo (la xM lleva 10/100 ehternet, no wifi).

Por cierto, lo del cuello de botella SPI parece ser algo habitual con los PIC's, pues unos brasileños que conozco desarrollaron un producto interesante que precisamente se quedaba corto precisamente por eso. Así que ya se han comprado la IGEP para sustituir su 18F. Por cierto, ese cuello de botella ya lo había pronosticado yo hace tiempo con los PIC32.

Sin baterías no la hemos probado, pero parece ser que el consumo es bajo para lo que es, pero elevado si lo comparamos con un PIC de pico potencia o un AVR a femtowatios. Es un tema que sí que queremos probar, pero las condiciones son variadas, pues no es lo mismo usar la interfaz de video con un TFT, por ejemplo que usarlo para controlar un robot por wifi con el mínimo consumo de potencia por parte de periféricos.

Muy guapa la beagle xM, pero sigo prefiriendo algo que lleve WiFi. Al fin y al cabo, me interesa la movilidad, no un elemento fijo (la xM lleva 10/100 ehternet, no wifi).

Por cierto, lo del cuello de botella SPI parece ser algo habitual con los PIC's, pues unos brasileños que conozco desarrollaron un producto interesante que precisamente se quedaba corto precisamente por eso. Así que ya se han comprado la IGEP para sustituir su 18F. Por cierto, ese cuello de botella ya lo había pronosticado yo hace tiempo con los PIC32.

¿Estás comparando a los PIC32 con un ARM Cortex-A8? Vamos ni de lejos...

Ya se que no se pueden comparar.

Pero hubo un momento en que alguien comentó que los PIC 32 tenían mucha variedad, pero no cubrían los periféricos que yo necesito en el trabajo. A saber: CAN, varias USART, algún que otro LCD, LIN, en algunos casos Ethernet, ADC's de 12-16 bits a 1MSPS, SDCards, I2C, expansión de I/O de baja velocidad con registros de desplazamiento, etc. Eso implica poner la mayoría de periféricos por SPI. Y sólo de CAN ya necesito un megabit por segundo. Si añadimos SDcard, ADC's y demás, los PIC32 presentan un cuello de botella en este punto. La opción es usar un ARM con los periféricos integrados, de manera que el SPI se use para lo imprescindible. Y eso, igual pasa por no poder usar la IGEP más que para los cálculos y cosas gordas (SDCard, LCD's, LIN), y dejar el ARM cortex M3 para el ADC interno, CAN en tiempo real, y poco más. El tiempo real es necesario, y el Linux no me lo garantiza del todo, sobre todo si hay más de un periférico en el mismo SPI.

Sin baterías no la hemos probado, pero parece ser que el consumo es bajo para lo que es, pero elevado si lo comparamos con un PIC de pico potencia o un AVR a femtowatios. Es un tema que sí que queremos probar, pero las condiciones son variadas, pues no es lo mismo usar la interfaz de video con un TFT, por ejemplo que usarlo para controlar un robot por wifi con el mínimo consumo de potencia por parte de periféricos.
...

¿Quieres decir "con batería no la hemos probado? 🙂

Mi idea es usarla con batería y habitualmente sin nada más. Iría conectada a los servos por usb. Aunque en algunas creaciones también sería interesante utilizar la wifi.