Protocolo de comunicación JPMSMRV maestro-esclavo de USB/UARTs de microcontroladores y PCs.

En el diseño electrónico de diferentes placas va a existir un protocolo de comunicación entre microcontroladores o microcontroladores y PC.

Se va a crear (ya se está creando) una librería que permitirá comunicar de forma sencilla, eficiente y segura los diferentes dispositivos.
A esta librería la llamaré JPMSMRV, y esto es la versión 20200318A.

Esta librería consta de dos partes:
1.- COMUNICACIÓN ASCII
2.- MAPA DE REGISTROS VIRTUAL

1.- COMUNICACIÓN ASCII:
Realmente la parte de comunicación es una capa HAL que se utiliza de forma intermedia en las comunicaciones efectiva de los datos.

El sistema está formado por:
- Un maestro (microcontrolador o PC)
- Un esclavo (microcontrolador)

La comunicación se realizará con carácteres ASCII (los usados en la codificación base 64), con retornos de carro/avance de línea 0x0D 0x0A y CRC32 incluido en cada línea.

El protocolo no necesitaŕa carácteres de inicio (start), ya que el primer carácter de la comunicación tras un inicio o tras un retorno de carro se interpretará como byte de inicio.
El CRC32 ya se encargará de descartar inicios inadecuados.

Al final este protocolo se basa en mandar y recibir líneas completas, que temporalmente se están almacenando en un bufer circular o un bufer de tamaño limitado de un tamaño adecuado.

Se define la trama de la línea de la siguiente manera:
B0 B1 B2 .. Bx 0x0D 0x0A

B0 a Bx contiene los caracteres ASCII de un bloque de datos binario codificado en "Base64", Bx.

El bloque binario está compuesto antes de ser codificado a base64 por un conjunto de bytes, considerándolos como "Datos" Dx:
D0 D1 .. Dx CRC0 CRC1 CRC2 CRC3

Como se ve se mantiene por convenio la transmisión de datos "Little-Endian", usado también en las arquitecturas Intel y ARM a la hora del almacenamiento en memoria o comunicaciones serie.

Para realizar el CRC32 se ha probado con éxito el uso de la librería Fast CRC32 de Stephan Brumme:
https://create.stephan-brumme.com/crc32/
https://create.stephan-brumme.com/crc32/Crc32.h
https://create.stephan-brumme.com/crc32/Crc32.cpp
Testeada tanto en un PC con procesador Intel/AMD como en el STM32F103C8T6 de la placa Bluepill.
https://create.stephan-brumme.com/crc32/Crc32Test.cpp

A la librería Fast CRC32 se le ha tenido que aplicar ciertas modificaciones para poder ser compilada correctamente.
En principio se usará el método "Slicing-by-8", por ser uno de los más rápidos y consumir no demasiados recursos en cuanto a memoria flash del STM32F103C8T6.
#define CRC32_USE_LOOKUP_TABLE_SLICING_BY_8
Usa +7328 bytes de flash  respecto a CRC32_USE_LOOKUP_TABLE_BYTE en el STM32.
Usar slicing by 8 en el STM32F103C8T6 está consumiendo aproximadamente unos 8K de 64K, no es demasiado.

Con esta definición de trama ya se podría mandar un bloque de datos binarios de forma clara, trasparente y segura.
El receptor de los datos chequearía el CRC32 y admitiría el paquete de datos binarios o no.

En el caso de que no le llegue el paquete de datos o le llegue corrupto al receptor, se comportará como si hubiera llegado.

El maestro se encargará de repetir las veces necesarias el paquete enviado y con los periodos de tiempo que se necesiten hasta que el esclavo devuelva una respuesta válida.
Más adelante se indicará qué es una respuesta válida.

Los datos binarios como hemos visto ya están compuestos por una serie de bytes, considerados "Datos" Dx:
D0 D1 D2 D3 D4 D5 .. Dx

Los primeros 4 bytes van a consistir en un identificador de paquete.
D0 D1 D2 D3 serian ID0 ID1 ID2 ID3

Lo que el paquete binario sería algo como esto:
ID0 ID1 ID2 ID3 D4 D5 .. Dx

Y al incluir el CRC32:
ID0 ID1 ID2 ID3 D4 D5 .. Dx CRC0 CRC1 CRC2 CRC3

Así el maestro numeraría todo los bloques binarios enviados, aun teniendo que recalcular el CRC32 de bloques binarios que se reenvían (por cambian el ID).

La respuesta del esclavo a todos los paquetes recibidos por el maestro va a costar de:
ID0 ID1 ID2 ID3 CRC0 CRC1 CRC2 CRC3
Todo esto codificado correctamente en base 64, y este paquete funciona de forma similar a un eco, omitiendo la retransmisión innecesaria de los datos.

Si el esclavo tuviera que mandar bloques de datos en respuesta a lo solicitado por el maestro los enviará posteriormente a este eco.
Estos bloques adicionales mantendrán el ID, los datos R referentes a la respuesta y el correspondiente CRC32.
ID0 ID1 ID2 ID3 R4 R5 .. Rx CRC0 CRC1 CRC2 CRC3

Estarse atentos, los datos sin el identificador, se han definido como:
- D3 D4 .. Dx
- R3 R4 .. Rx
Tanto R0 .. R3 como D0 .. D3 harán referencia a ID0 .. ID3.

El maestro tomará las decisiones adecuadas dependiendo de los paquetes recibidos, su integridad, el tiempo de recepción y los identificadores que pudieran estar desordenados.

Cualquier comunicación que no acabe con el eco correcto y la recepción de la respuesta adecuada se interpretará como un error en la comunicación y se repetirá, si se considerara procedente.

La librería que implementa esta capa HAL de momento se compone de funciones genéricas muy sencillas, no incluyendo las repeticiones o los tiempos.

En el envío, tanto el maestro como el esclavo usan la siguiente función:
void send_block (uint32_t id, uint8_t *bloque, uint32_t size);

En la recepción el maestro usa:
uint32_t receive_block_master (uint32_t *id, uint8_t *bloque, uint32_t *size); // Siendo la respuesta distinta de 0x00 considerada como error.

En la recepción el esclavo usa:
uint32_t receive_block_slave (uint32_t *id, uint8_t *bloque, uint32_t *size); // Siendo la respuesta distinta de 0x00 considerada como error.

En la recepción una respuesta 0x00 se puede considerar como que aun no ha habido error:
- Si size es 0x00 es que aun no se ha recibido nada o una línea completa, repitiéndose la comprobación.
- Si size es distinto distinto de 0x00 es que se ha recibido un bloque de datos de forma correcta.

Habiendo recibido un bloque de datos de forma correcta, en el caso de que el receptor sea el maestro, este bloque recibido puede ser un eco.
Hay que repetir el paso de recepción en el caso del maestro para recibir los datos del esclavo cuando así se requiera.

Hasta ahora la unidad básica de medida en la variable "size" es el "byte", esto es en esta parte de la comunicación.
Esta capa formada por estas 3 funciones ya contiene lo mínimo necesario para establecer una comunicación de forma correcta.

Posteriormente habrá que implementar más código para repeticiones, temporizaciones, descartar paquetes, etc.

Todo esto esta implementado en C, probado y compilado por el software Arduino para stm32duino y para PC con gcc.
Cuando estén más depuradas, testeadas las librerías y desarrolladas las aportaré.

Comentarios

  • 2.- MAPA DE REGISTROS VIRTUAL:
    Teniendo esta librería básica de comunicación, lo que se hace a continuación es crear un Mapa de Registros Virtual.

    ¿A qué me refiero con esto?

    Imaginaros que hay que fijar 3 parámetros en el microcontrolador de la placa principal:
    - Parámetro 1: Velocidad de flujo.
    - Parámetro 2: Presión.
    - Parámetro 3: Frecuencia respiratoria.

    A la hora de implementar un programa principal o cuando el PC tenga que obtener los valores de estos parámetros sería bastante complicado estar revisando código y creando funciones específicas para la lectura de cada parámetro.
    El Mapa de Registros Virtual simplifica mucho el desarrollo de código, la ampliación y el mantenimiento.

    En el microcontrolador se define inicialmente la posición de memoria MRV_ADDR que va a tener cada parámetro, por ejemplo:
    #define MRV_ADDR_VFLUJO 0x00000000
    #define MRV_ADDR_PRESION 0x00000001
    #define MRV_ADDR_FRESPIRATORIA 0x00000002
    No es una dirección de memoria real del microcontrolador, es una posición de direccionamiento del Mapa de Registros Virtual.

    Habrá una parte de código adicional que se encargara de asociar cada dirección de memoria del Mapa de Registros Virtual a la dirección de memoria real en el microcontrolador o PC, usando principalmente las direcciones de las variables o punteros.
    #define MRV_MEM_ADRR_VFLUJO &velocidadflujo
    #define MRV_MEM_ADRR_PRESION &presion
    #define MRV_MEM_ADRR_FRESPIRATORIA &frecuenciarespiratoria

    En el PC se mantienen estas mismas definiciones.
    Cuando se solicite una lectura de un parámetro en el PC, por ejemplo el de presión, el PC estará haciendo:
    - Lectura de la dirección 0x00000001 del Mapa de Registros Virtual.

    Si se solicita una escritura en ese registro, se estaría cambiando el parámetro de presión.

    Esto simplifica todo lo que se quiera implementar a:
    1.- Definir (mapear) los parámetros, datos o bloques de datos que queramos usar, definiendo también el tamaño de cada bloque. Para 1 dato o parámetro el tamaño es 1 registro (ya indicaremos el tamaño de 1 registro).
    2.- Una tabla "lookup table" o función que traslade las direcciones del MRV a las direcciones reales de memoria.
    3.- Un comando de lectura de Mapa de Registros Virtual (MRV), indicando posición y tamaño.
    4.- Un comando de escritura de Mapa de Registros Virtual (MRV), indicando posición y tamaño.

    Ejemplo anterior completado:
    #define MRV_ADDR_VFLUJO 0x00000000
    #define MRV_SIZE_VFLUJO 0x00000001
    #define MRV_MEM_ADRR_VFLUJO &velocidadflujo
    #define MRV_ADDR_PRESION 0x00000001
    #define MRV_SIZE_PRESION 0x00000001
    #define MRV_MEM_ADRR_PRESION &presion
    #define MRV_ADDR_FRESPIRATORIA 0x00000002
    #define MRV_SIZE_FRESPIRATORIA 0x00000001
    #define MRV_MEM_ADRR_FRESPIRATORIA &frecuenciarespiratoria

    Como las arquitecturas usadas están optimizadas para 32 bits (o 64 bits) tanto en los ARM como el los procesadores de PC, todos los datos, registros y direcciones serán de 32 bits.
    El usar como unidad en este Mapa de Registros Virtual un word de 32 bits como unidad mínima de almacenamiento tiene sus ventajas e inconvenientes.

    Inconvenientes principales:
    1.- Algo de procesamiento para bytes, cadenas char o de bytes, o words de 16 bits.
    Si se quiere almacenar por ejemplo una matriz de 27 bytes en los registros se tendrán que utiliza 7 registros del MRV.
    Cada registro contendrá 4 bytes, salvo el último, que contendrá únicamente 3 bytes.
    2.- Se tiene que pensar que cada incremento de registro en bloques contiguos de datos supone un aumenento de dirección de 4 bytes en el direccionamiento real de memoria del PC o microcontrolador.

    Ventajas principales:
    1.- En un sólo registro se puede almacenar datos de capturas de conversores de 16 bits o 24 bits de forma muy rápida, con pocas instrucciones de código ensamblador.
    2.- Facilita el entendimiento del código, estando todo contenido en el MRV, independientemente de tratarse de tipos de datos distintos: byte, char, short int, int, floats, etc.
    3.- Se puede usar variables "double" siempre y cuando se utlicen 2 registros por variable.

    Aquí he priorizado lo práctico sobre la optimización de memoria.

    Las 2 funciones del MRV son:
    uint32_t mrv_read(uint32_t address, uint32_t *datos, uint32_t size);
    uint32_t mrv_write(uint32_t address, uint32_t *datos, uint32_t size);

    Una respuesta distinta de 0x00 supondría un error, ya sea por errores en las comunicaciones o por cualquier otra causa.

    Estas 2 funciones incluiría la capa HAL de comunicaciones vistas previamente.
    Un PC podría ver el estado, modificar parámetros y datos o recibir un volcado de información de un microcontrolador de forma sencilla.
    Todo basado en un Mapa de Registros Virtual.

    He de indicar que el tamaño de memoria RAM disponible en el microcontrolador esta limitado a 20KB, así que hay que tener algo de cuidado con lo que se está utilizando en cada momento o lo que se reserva.
    El bufer circular o un bufer de tamaño limitado de recepción de datos no puede ser demasiado grande, limitando la longitud máxima de cada línea a ese tamaño, y por tanto limitando el bloque máximo de datos trasmitidos por paquete a X bytes.

    Teniendo bien definido el Mapa de Registros Virtual se puede desarrollar código de forma simultánea por diferentes programadores.

    Todo se esta implementado en C, tanto para el software Arduino usado por stm32duino como para el gcc de los PC.
    Cuando estén más depuradas, testeadas las librerías y desarrolladas las aportaré.

    De momento, los desarrolladores que quieran empezar pueden usar esto, para poder compilar adecuadamente su código, aunque no se ejecute nada:
    uint32_t mrv_read(uint32_t address, uint32_t *datos, uint32_t size) {
      return 0x00;
    }
    uint32_t mrv_write(uint32_t address, uint32_t *datos, uint32_t size) {
      return 0x00;
    }

    Estas son las especificaciones iniciales de la libreria JPMSMRV versión 20200318A, posiblemente sufra modificaciones sobre la marcha.
  • ..
    En el caso de que no le llegue el paquete de datos o le llegue corrupto al receptor, se comportará como si hubiera llegado.
    ..
    En la recepción el maestro usa:
    uint32_t receive_block_master (uint32_t *id, uint8_t *bloque, uint32_t *size); // Siendo la respuesta distinta de 0x00 considerada como error.

    En la recepción el esclavo usa:
    uint32_t receive_block_slave (uint32_t *id, uint8_t *bloque, uint32_t *size); // Siendo la respuesta distinta de 0x00 considerada como error.
    Revisando el protocolo he encontrado alguna errata, que corregida queda:

    En el caso de que no le llegue el paquete de datos o le llegue corrupto al receptor, se comportará como si NO hubiera llegado.

    Y se deja en una única función común la recepción, tanto para el maestro como para el esclavo.

    En la recepción, tanto el maestro como el esclavo usarán:
    uint32_t receive_block (uint32_t *id, uint8_t *bloque, uint32_t *size); // Siendo la respuesta distinta de 0x00 considerada como error.

    En futuras revisiones se actualizará el documento pdf para la impresión.
  • He creado un ejemplo de uso de la librería JPMSMRV y cómo se maneja el Mapa de Registros Virtual (MRV).
    Adjunto el pdf.
  • Ya me encargo de las 2 funciones. Mvr_ read y mvr_ write. 
  • editado 20 de marzo
    Ya me encargo de las 2 funciones. Mvr_ read y mvr_ write. 
    Las funciones están incluidas en la libreria, son la API pública de la libreria.
    La parte del PC es la interfaz grafica que permita fijar los parámetros o ver las variables del ejemplo.
    Será necesaria una función adicional para seleccionar el puerto y las características de velocidad.
    En Windows seria un COMx a 115200,8,n,1.
    En linux /dev/ttyACM0 a 115200,8,n,1.
    Asi que se tendrá que poner algo como:
    mrv_cfg(COM0,115200,8,n,1);


  • Actualizo versión en el pdf adjunto.
    Protocolo de comunicación JPMSMRV maestro-esclavo de USB UARTs de microcontroladores y PCs 20200320A.pdf

  • tengo unas  preguntas;
    1) el codigo para estas dos funciones ya estan desarrolladas?  son para implementarlas en el micro?
    uint32_t mrv_read(uint32_t address, uint32_t *datos, uint32_t size);
    uint32_t mrv_write(uint32_t address, uint32_t *datos, uint32_t size);


  • editado 20 de marzo
    Hola,
     Tenemos aparte de impresoras 3D, placas de control de motores NEMA disponibles en España (cerca de 500 ahora mismo, hasta 10.000 en 2 semanas): https://www.jjrobots.com/product/devia-robotics-control-board-v1-0/ La placa permite control desde un smartphone o PC, con entradas listas pare sensores y control WIFI. Tenemos desarrolladores de APP y software en la empresa disponibles. Aparte de esto, hemos mirado el diseño del respirador y adaptado ligeramente sus piezas para que quepa en las camas de impresoras 3D "standard" Si estuvieseis interesados, hacérnoslo saber por favor. Gracias por todo esto
  • editado 20 de marzo
    tengo unas  preguntas;
    1) el codigo para estas dos funciones ya estan desarrolladas?  son para implementarlas en el micro?
    uint32_t mrv_read(uint32_t address, uint32_t *datos, uint32_t size);
    uint32_t mrv_write(uint32_t address, uint32_t *datos, uint32_t size);


    La API la estoy definiendo, desarrollando y testeando yo sobre PC y sobre la placa Bluepill.

    El resto de programadores no podrán testear el hardware o las funciones que implementen porque no tendrán el Bluepill con las placas electrónicas conectadas.

    Por eso he definido este protocolo fácil de incluir y que pueda desarrollarse el código simultáneamente, y llegar al mismo tiempo a las fases de testeo.

    Hay partes que ya he probado con éxito, como las comunicaciones por USB, UART, codificaciones base 64 y CRC32.

    Estoy ahora con la segunda parte, con la parte del MRV, que sería la API pública de la librería.

    En la documentación hay 3 funciones de la API que devuelven siempre 0x00.

    Se puede testear así, o crear en memoria RAM el Mapa de Registro Virtual para testear el programa que se está creando a través de una simulación.

    Voy a añadir en una revisión esta tarde ese modo para permitir simulaciones.

    Algo tan sencillo como:
    uint32_t MRV_RAM[0x0800];
    Y las funciones devolverán o actualizarán el contenido de ese MRV.
    Lo rellenare previamente con valores aleatorios de caracteres numéricos para que no siempre devuelva 0x00.

    Si puedes revisa este hilo:
    https://foro.coronavirusmakers.org/index.php?p=/discussion/298/coordinacion-de-colaboradores-diseno-electronico-y-programacion#latest
    Y pon un comentario como este:

    Ariel_arias, programación App PC respirador Pancho_Cañizo, inicio

    O lo que consideres oportuno siguiendo las normas del hilo.

  • editado 20 de marzo
    JuanPC dijo:
    Hola,
     Tenemos aparte de impresoras 3D, placas de control de motores NEMA disponibles en España (cerca de 500 ahora mismo, hasta 10.000 en 2 semanas): https://www.jjrobots.com/product/devia-robotics-control-board-v1-0/ La placa permite control desde un smartphone o PC, con entradas listas pare sensores y control WIFI. Tenemos desarrolladores de APP y software en la empresa disponibles. Aparte de esto, hemos mirado el diseño del respirador y adaptado ligeramente sus piezas para que quepa en las camas de impresoras 3D "standard" Si estuvieseis interesados, hacérnoslo saber por favor. Gracias por todo esto
    Buenas tardes JuanPC

    He visto el modelo de placa, las características y el esquema electrónico.

    Indico alguno de los puntos por los que no serían apropiadas ahora mismo para este desarrollo:
    - Usan un microcontrolador diferente a los que se están utilizando aquí (STM32F103C8T6, y para los programadores esto son dificultades y tiempo.
    - Hay que tener en cuenta que habría que implementar un protocolo de comunicaciones con este microcontrolador.
    - Hay que ver el soporte "software", actualmente se utiliza arduino/stmduino como entorno de programación.
    - Hay que ver si existen y funcionan correctamente las librerías de los periféricos (SPI, I2C, LCD, etc). El que existan no significa que puedan usarse sin tener problemas.
    Por las características del sistema, es posible que el uso de RTOS mas que ayudar, dificulten. Hay que controlar mucho. Hay que integrar constántemente sin perder muestras.
    - No disponen de drivers de potencia de los los motores paso a paso.
    - La plataforma STM32 se ha elegido específicamente por determinados motivos, más que por la potencia "hardware", que también, por el "software" que hay disponible y que he testeado yo mismo.

    Esto no quiere decir que no se puedan utilizar en otro desarrollo electrónico paralelo a este.

    Gracias por esta aportación, todas las aportaciones son bienvenidas.

    Si hay algún otro electrónico que quiera abrir hilos paralelos, los puede abrir, yo no limito las opciones de desarrollo que puedan tener otros.
  • JuanPC dijo:
    Hola,
     Tenemos aparte de impresoras 3D, placas de control de motores NEMA disponibles en España (cerca de 500 ahora mismo, hasta 10.000 en 2 semanas): https://www.jjrobots.com/product/devia-robotics-control-board-v1-0/ La placa permite control desde un smartphone o PC, con entradas listas pare sensores y control WIFI. Tenemos desarrolladores de APP y software en la empresa disponibles. Aparte de esto, hemos mirado el diseño del respirador y adaptado ligeramente sus piezas para que quepa en las camas de impresoras 3D "standard" Si estuvieseis interesados, hacérnoslo saber por favor. Gracias por todo esto
    Buenas tardes JuanPC

    He visto el modelo de placa, las características y el esquema electrónico.

    Indico alguno de los puntos por los que no serían apropiadas ahora mismo para este desarrollo:
    - Usan un microcontrolador diferente a los que se están utilizando aquí (STM32F103C8T6, y para los programadores esto son dificultades y tiempo.

    El microcontrolador es compatible con Arduino IDE (la placa se detecta como Arduino ZERO) 100% compatible. En caso de necesidad, tenemos programadores disponibles para sacar adelante cualquier proyecto

    - Hay que tener en cuenta que habría que implementar un protocolo de comunicaciones con este microcontrolador.
    Tenemos ya eso implementado, es accesible via WIFI o USB. Toda la documentacion está disponible. Esta placa se usa para robotica educacional y el apartado de las comunicaciones es estandard.

    - Hay que ver el soporte "software", actualmente se utiliza arduino/stmduino como entorno de programación.
    La placa es 100% compatible con Arduino IDE (la placa se detecta como Arduino/Genuino ZERO al conectarla al ordenador)

    - Hay que ver si existen y funcionan correctamente las librerías de los periféricos (SPI, I2C, LCD, etc). El que existan no significa que puedan usarse sin tener problemas.

    Está ya preparada para acceder a cualquier dispositivo SPI e i2C. Usa las librerias standard de Arduino

    Por las características del sistema, es posible que el uso de RTOS mas que ayudar, dificulten. Hay que controlar mucho. Hay que integrar constántemente sin perder muestras.
    - No disponen de drivers de potencia de los los motores paso a paso.
    Los drivers de potencia se conectan a los zocalos existentes. Se pueden usar desde los A4988, DRV8825 a TMC2208. La placa admite hasta 15V de entrada y se puede refrigerar con FANs de 12v en caso de mucha demanda de potencia

    - La plataforma STM32 se ha elegido específicamente por determinados motivos, más que por la potencia "hardware", que también, por el "software" que hay disponible y que he testeado yo mismo.

    Esto no quiere decir que no se puedan utilizar en otro desarrollo electrónico paralelo a este.

    Gracias por esta aportación, todas las aportaciones son bienvenidas.

    Cualquier otra cosa, por favor, comentemela

    Si hay algún otro electrónico que quiera abrir hilos paralelos, los puede abrir, yo no limito las opciones de desarrollo que puedan tener otros.

  • Bueno JuanPC

    Yo sólo te puedo decir que por mi experiencia como programador, las cosas no funcionan como uno espera.

    El que haya una cosa funcionando para un Arduino no significa que vaya a funcionar en otros microcontroladores.

    Pongo un ejemplo claro, la lectura y escritura de ficheros FAT32 en tarjetas de memoria microSD y SD se ha conseguido en los micros de Atmel (Arduino Uno, Arduino Mini Pro, etc) usando el bus SPI (a 3.3V).
    Un ejemplo claro de esto lo encontrareis en el OpenLog de Adafruit que usa un Atmega328.

    En cambio las mismas librerías han dado problemas en microcontroladores Cortex M0.

    No es lo mismo decir que hay programadores disponibles, que ser el programador.
    En este caso soy yo el programador, y te digo que las placas no son 100% compatibles con lo que se está desarrollando aquí.

    Necesitan hacerse modificaciones sustanciales y parchear cosas que difieren de los micros STM32.
    Micros que estamos usando los programadores, y no vamos a cambiar de placa para que tu puedas vender las tuyas.

    Te pongo una comparativa con parámetros importantes relevantes para este diseño de las dos placas:

    STM32F103C8T6 (fabricante ST), Cortex M0:
    • fmax=72 Mhz
    • velocidad max muestreo = 1Msps
    • con pines tolerantes a 5V
    ATSAMD21G18 (fabricante Atmel/Microchip), Cortex M0
    • fmax=48 Mhz
    • velocidad max muestreo = 350Ksps
    • sin pines tolerantes a 5V, no se pueden superar 3.6V en los pines de I/O.
    No voy a seguir comparando cosas.

    El que tenga que perder el tiempo mirando manuales de 1111 páginas en vez de estar soldando placas y programando me está empezando a enfadar.
    Voy a tener que tener que solicitar a algún administrador que elimine tu entrada, porque además no tiene nada que ver con este hilo.
    Sería una entrada de un hilo de ventas o de adquisición de material.

    ¿La disposición de programadores que comentas está supeditada a la venta de lotes?
    Porque la ayuda de los programadores que indicas sobre la plataforma Arduino nos vendría bien.

    ¿Cuando afirmas una compatibilidad del 100% significa que en el contrato de compraventa del lote asumes una devolución integra del dinero y una compensación económica por el tiempo y dinero malgastados en caso de que la compatibilidad no sea del 100%?
    Porque es muy fácil lanzar las afirmaciones que has indicado a la ligera.
    Lo indicado en la publicidad en España es vinculante.

    Con mucho respeto te sugiero que intentes vender esos lotes al precio de tu página web a otros que si los quieran.
    Tengo que revisar cómo tratan los administradores del foro el SPAM.

    Yo, como diseñador descarto completamente la placa DEVIA como placa electrónica que se está desarrollando en los hilos que he abierto.

    Te veo muy convencido con tu placa.
    Abre un nuevo hilo y crea un proyecto paralelo si quieres.

    Te sugiero que busques diseñadores electrónicos y llames a los programadores que comentas.

    Y lee detenidamente la información de mis hilos:
    Los drivers de los motores paso a paso son de al menos 6A y entre 30V y 48V.
    Los drivers que indicas son de juguete y a 15V van a ir muy despacio los motores.

    Un saludo
  • JuanPC dijo:
    Hola,
     Tenemos aparte de impresoras 3D, placas de control de motores NEMA disponibles en España (cerca de 500 ahora mismo, hasta 10.000 en 2 semanas): https://www.jjrobots.com/product/devia-robotics-control-board-v1-0/ La placa permite control desde un smartphone o PC, con entradas listas pare sensores y control WIFI. Tenemos desarrolladores de APP y software en la empresa disponibles. Aparte de esto, hemos mirado el diseño del respirador y adaptado ligeramente sus piezas para que quepa en las camas de impresoras 3D "standard" Si estuvieseis interesados, hacérnoslo saber por favor. Gracias por todo esto

    Hola JuanPC,

    podrías sencillamente enviar un mail a aire@abierto.cc? Estamos mapeando todos los recursos desde ahí.

    Por otra parte, si lo que quieres es hablar de otro sistema electrónico, te propongo que abras un hilo diferente y lo manejes desde ahí. 

    Finalmente, te aviso que si lo que quieres es vender material, este no es el lugar para hacerlo. Estamos trabajando como voluntarios y en este momento el material que tenemos viene todo de donaciones. Si lo que quieres es donarnos tus 500 placas, entonces podemos empezar a hablar.
  • En otras notas @Jose, este hilo es puro oro.

    Gracias por el esfuerzo.
  • Bueno JuanPC

    Yo sólo te puedo decir que por mi experiencia como programador, las cosas no funcionan como uno espera.

    El que haya una cosa funcionando para un Arduino no significa que vaya a funcionar en otros microcontroladores.

    Pongo un ejemplo claro, la lectura y escritura de ficheros FAT32 en tarjetas de memoria microSD y SD se ha conseguido en los micros de Atmel (Arduino Uno, Arduino Mini Pro, etc) usando el bus SPI (a 3.3V).
    Un ejemplo claro de esto lo encontrareis en el OpenLog de Adafruit que usa un Atmega328.

    En cambio las mismas librerías han dado problemas en microcontroladores Cortex M0.

    No es lo mismo decir que hay programadores disponibles, que ser el programador.
    En este caso soy yo el programador, y te digo que las placas no son 100% compatibles con lo que se está desarrollando aquí.

    Necesitan hacerse modificaciones sustanciales y parchear cosas que difieren de los micros STM32.
    Micros que estamos usando los programadores, y no vamos a cambiar de placa para que tu puedas vender las tuyas.

    Te pongo una comparativa con parámetros importantes relevantes para este diseño de las dos placas:

    STM32F103C8T6 (fabricante ST), Cortex M0:
    • fmax=72 Mhz
    • velocidad max muestreo = 1Msps
    • con pines tolerantes a 5V
    ATSAMD21G18 (fabricante Atmel/Microchip), Cortex M0
    • fmax=48 Mhz
    • velocidad max muestreo = 350Ksps
    • sin pines tolerantes a 5V, no se pueden superar 3.6V en los pines de I/O.
    No voy a seguir comparando cosas.

    El que tenga que perder el tiempo mirando manuales de 1111 páginas en vez de estar soldando placas y programando me está empezando a enfadar.
    Voy a tener que tener que solicitar a algún administrador que elimine tu entrada, porque además no tiene nada que ver con este hilo.
    Sería una entrada de un hilo de ventas o de adquisición de material.

    ¿La disposición de programadores que comentas está supeditada a la venta de lotes?
    Porque la ayuda de los programadores que indicas sobre la plataforma Arduino nos vendría bien.

    ¿Cuando afirmas una compatibilidad del 100% significa que en el contrato de compraventa del lote asumes una devolución integra del dinero y una compensación económica por el tiempo y dinero malgastados en caso de que la compatibilidad no sea del 100%?
    Porque es muy fácil lanzar las afirmaciones que has indicado a la ligera.
    Lo indicado en la publicidad en España es vinculante.

    Con mucho respeto te sugiero que intentes vender esos lotes al precio de tu página web a otros que si los quieran.
    Tengo que revisar cómo tratan los administradores del foro el SPAM.

    Yo, como diseñador descarto completamente la placa DEVIA como placa electrónica que se está desarrollando en los hilos que he abierto.

    Te veo muy convencido con tu placa.
    Abre un nuevo hilo y crea un proyecto paralelo si quieres.

    Te sugiero que busques diseñadores electrónicos y llames a los programadores que comentas.

    Y lee detenidamente la información de mis hilos:
    Los drivers de los motores paso a paso son de al menos 6A y entre 30V y 48V.
    Los drivers que indicas son de juguete y a 15V van a ir muy despacio los motores.

    Un saludo
    Bueno, recojo carrete. La oferta era por material gratuito (obviamente, sacar beneficio de esto no hay por donde cogerlo).

     Los programadores de la empresa se han ofrecido a trabajar completamente gratis en esto. 
    Solo proponía, desde la buena fe, aunar la capacidad de la empresa para ayudar en todo en esto, pero se ha malinterpretado. 

    Desde aquí queríamos ayudar solventando cualquier problema que surgiese con la programacion y aligerar la carga en ese apartado.

    Nunca indiqué ni compraventa de lotes, ni semejante. Es bochornose que se entienda asi en una situación como está.

    Por favor, si lo consideráis conveniente eliminar mi entrada,
     Muchas gracias por vuestro tiempo y muchas suerte.

  • JuanPC dijo:

    Bueno, recojo carrete. La oferta era por material gratuito (obviamente, sacar beneficio de esto no hay por donde cogerlo).

     Los programadores de la empresa se han ofrecido a trabajar completamente gratis en esto. 
    Solo proponía, desde la buena fe, aunar la capacidad de la empresa para ayudar en todo en esto, pero se ha malinterpretado. 

    Desde aquí queríamos ayudar solventando cualquier problema que surgiese con la programacion y aligerar la carga en ese apartado.

    Nunca indiqué ni compraventa de lotes, ni semejante. Es bochornose que se entienda asi en una situación como está.

    Por favor, si lo consideráis conveniente eliminar mi entrada,
     Muchas gracias por vuestro tiempo y muchas suerte.

    Hola Juan,

    muchas gracias por aclararlo. Por aquí llevamos muchos días trabajando con poco sueño y estamos un poco al límite. Así que me he excedido en mi crítica, me disculpo (te debo una cerveza cuando salgamos de esta).

    En cualquier caso, puesto que tienes equipo y tienes mano de obra, ¿porque no lanzáis una línea de prototipado por vuestra cuenta? 

    Jose está haciendo su prototipo, documentando todo en el foro, mientras que tienes, por ejemplo al grupo de la Reesistencia que lo desarrolla en el gitlab de coronavirusmakers. Porque no te decides por un espacio de trabajo y os ponéis manos a la obra?


  • La idea de Juan sonaba muy bien. Hay que trabajar en varios proyectos en paralelo. Ojalá todos den buen resultado pero podría ser que no. 
    Animaos a desarrollarlo con vuestros recursos que no son pocos!
  • Buenos días.
    Los administradores de este foro no han cumplido con su cometido.
    Con lo fácil que hubiera sido poner algo de orden.
    Debido al completo desorden del foro, la descoordinación y la falta de control de los administradores de este foro he decidido no aportar nada mas al mismo.
    - He tenido que dedicarle tiempo a corregir a otros colaboradores comentarios inciertos para que los lectores no se basaran en ellos.
    - He duplicado hilos por haberlos ensuciado otros miembros con comentarios no relacionados con estos hilos.
    - He reportado a los administradores comentarios que debieran de eliminarse de hilos y éstos no han hecho nada, dejando el hilo inservible, al dejar éste "sucio", lleno de tanta "basura".
    El estar haciendo el doble o el triple de trabajo para mantener la información en este foro me ha estado quitando el tiempo necesario para el desarrollo de un respirador viable.
    Este foro ha sido una carga, en el que aportaba, aportaba y aportaba, y nadie me ha echado una mano.
    31 hilos abiertos y más de 160 comentarios en estos días, mientras que otros se dedicaban a sus montajes (y utilizaban el foro cuando se encontraban con algún problema), yo tenía que estar redactando y documentando todo muy clarito para que los lectores lo entendieran.
    La colaboración de los demás ha sido casi nula, sólo ha servido para dedicarle mi tiempo a otros, y no para avanzar en un desarrollo factible.
    Las pocas cosas que solicitaba en las colaboraciones, que hasta estudiantes de instituto pudieran haber realizado, no la ha realizado nadie, como por ejemplo, las búsquedas en sitios específicos y la realización de listados.
    Todo el mundo se ha centrado en sus intereses, en sus desarrollos propios y no en ver todo esto desde una perspectiva mas amplia.
    Como suelo decir "el que no aporte, que se aparte", veo que para las personas de este foro no "aporto", si no hubieran permitido por ejemplo que administrara mis propios hilos o hubieran hecho relevantes estos hilos.
    Debido a que lo que estoy haciendo no le interesa a nadie, por la nula colaboración que estoy recibiendo de este foro, me aparto.
    Como siempre han decidido centrarse en otros desarrollos, se que la decisión que he tomado es la mejor decisión, por muy dura que sea.
    Después de tantos días, al igual que en un trabajo, sólo queda despedirme de mis compañeros.
    "Ánimo compañeros".
    Atentamente
    Jose_Pizarro

Accede o Regístrate para comentar.