sábado, 1 de julio de 2023

Debian 12 - OpenOCD: Error: libusb_open() failed with LIBUSB_ERROR_ACCESS

Solución a Error: libusb_open() failed with LIBUSB_ERROR_ACCESS (st-link, picoprobe, etc), utilizando OpenOCD en Debian 12

En este caso se describe para permitir el acceso a picoprobe.

Primero:

$ lsusb

......
Bus 001 Device 007: ID 2e8a:0004 Raspberry Pi Picoprobe
Bus 001 Device 003: ID 0a05:7211 Unknown Manufacturer hub
Bus 001 Device 004: ID 0a5c:22be Broadcom Corp. BCM2070 Bluetooth 3.0 + HS
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 006: ID 046d:c08c Logitech, Inc. G PRO Gaming Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


......


Como root crear un  archivo en /etc/udev/rules.d/


Ej: 

# nano /etc/udev/rules.d/77-myrules.rules

Y en el interior pegar :

# Raspberry Pi Picoprobe
ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="0004", MODE="664", GROUP="plugdev"

Salvar archivo.

Luego desconectar el dispositivo USB

Ejecutar:

# udevadm control --reload

Reconectar el dispositivo y ya debería permitir el acceso.

jueves, 29 de septiembre de 2022

Manjaro primeros pasos

Ayuda memoria para los primeros pasos en Manjaro (basado en Arch Linux)

Gestor paquetes:

# pacman

Instalar (Sync):

# pacman  -S <pkgname>

Buscar paquetes (Syncsearch):

# pacman -Ss <pkgname>

Actualizar sistema:

# pacman -Syyu 

Instalar "equivalencia" build-essentials (SyncRefresh)

# pacman -Sy base-devel 

Verificar si <pkg> está instalado:

# pacman -Q <pkg>

# pacman -Qi <pkg>

Punto de montaje:

Debian:

/media/user/<mountpoint>

Manjaro:

/run/media/user/<mountpoint>

Para compilar Nuttx:

automake, bison, libtool, pkg-config y flex incluidos en base-devel 

Instalar:

# pacman -S gperf

# pacman -S arm-none-eabi-gcc

#  pacman -S stlink

Instalar kconfig-frontends por medio de AUR:

$ mkdir manjaro-aur

$ cd manjaro-aur

$ git clone https://aur.archlinux.org/kconfig-frontends.git

$ makepkg -si

Añadir <user> a grupo <group>:

 # gpasswd -a <user> <group>

 

En desarrollo, última actualización 29/09/22

sábado, 3 de julio de 2021

NuttX en Raspberry Pi-Pico RP2040

Introducción.

  Hace varios años comencé a testear al RTOS NuttX.

  De un tiempo a esta parte, no he podido dedicarle las horas necesarias para seguir su desarrollo. 

  Hace unos meses me dí a la tarea de retomarlo y entre las primeras grandes diferencias es que NuttX es llamado también Apache Nuttx. (No me detendré a explicar lo anterior, hay bastante info al respecto)

  A la vez siempre trabajé dentro de la línea de STM32 ya sea cortex M3 (F103) o cortex M4 (F407), pero recientemente descubrí a una nueva competidora la Raspberry pi Pico.

  Esta placa posee un microcontrolador ARM cortex M0+ de doble núcleo siendo una opción muy interesante para los RTOS que aprovechen la potencia de esto. Además su precio es equivalente a una blue-pill (STM32F103).

  En las próximas líneas explicaré como obtener el código fuente de NuttX, compilarlo e instalarlo en  la Pi Pico. Todo ello realizado desde una PC con Debian.

Comenzando.

Descargamos el SDK de Raspberry Pi Pico en un directorio acorde:

$ mkdir pico

$ cd pico

$ git clone -b master https://github.com/raspberrypi/pico-sdk.git

$ cd pico-sdk

$ git submodule update --init 

Y luego exportamos la variable de entorno:

$ export PICO_SDK_PATH=/home/usuario/pico/pico-sdk/

Ahora seguimos con NuttX

Instalamos las siguientes herramientas como root:

# apt install automake bison build-essential flex gcc-arm-none-eabi gperf git libncurses5-dev libtool libusb-dev libusb-1.0.0-dev pkg-config kconfig-frontends

Debo aclarar que puede ser que actualmente sea necesario algún paquete extra o incluso que alguno de los nombrados ya no sea necesario, esto lo realicé hace muchos años, y si bien he ido actualizando mi PC, en ocasiones instalo paquetes para otros desarrollos que quizás no noté que sean necesarios y los halla pasado por alto. De todas formas en el siguiente canal de YouTube hay muy buenos video tutoriales.

 Luego descargamos con git los siguientes repositorios en una carpeta acorde, en mi caso:

$ mkdir nuttx-workspace 

$ cd nuttx-workspace

$ git clone https://github.com/apache/incubator-nuttx
 
$ git clone https://github.com/apache/incubator-nuttx-apps.git apps


Una vez hecho lo anterior nos movemos a:

$ cd incubator-nuttx

Allí lanzamos el siguiente comando que configurará por default varias opciones, para que podamos tener un binario con la consola de NuttX y algunas funciones/aplicaciones básicas disponibles:

$ ./tools/configure.sh raspberrypi-pico:nsh

También si deseamos podemos agregar/quitar, características/aplicaciones  desde el config de NuttX (muy interesante para los que nos gusta probar :) )

$ make menuconfig

Finalmente compilamos con:

$ make -j4 

Una vez finalizada la compilación deberíamos tener el archivo nuttx.uf2

Grabando.

Ahora continuamos "grabando" el archivo nuttx.uf2 en la Raspebrry Pi Pico.

Para ellos necesitamos que la PC detecte a la Pi Pico, como una unidad de almacenamiento (como si de un pendrive se tratara). El procedimiento es muy simple, mientras mantenemos presionado el boton "BOOTSEL" de la placa, la conectamos por medio de un cable USB a nuesta PC, luego soltamos el botón y al cabo de unos segunos la PC reconocerá nuestra placa como una unidad de almacenamiento con la etiqueta "RPI_RP2".

Posteriormente "pegamos" el archivo nuttx.uf2 a la "RPI_RP2", y luego de unos segundos se reinicia nuestra placa y comienza a correr NuttX.

Conexión

Una vez que flasheamos la placa, necesitamos conectarla a nuestra PC, por medio de un conversor TTL-RS232-USB, en mis ensayos utilizo uno basado en el CP2102 (muy popular y económico en el mundo Arduino).

El conexionado es el siguiente:

PI-PICO -- TTL-RS232

GP0 (Tx)      Rx       

GP1 (Rx)      Tx

GND            GND


Una vez realizado lo anterior, conectamos nuestra placa por medio del conversor a nuestra PC, y esperamos unos segundos a Linux reconozca el puerto serie, en mi caso /dev/ttyUSB0

Lanzamos minicom y establecemos la configuración:

$ minicom -s


 

Presionamos ESC en nuestra PC.

Presionamos enter y la consola de NuttX debería responder.

Dejo una captura con los comandos, "?", "ps", y "uname" ejecutados.

 Mi setup:

Hay conexiones extra?, próxima entrada del blog.


 

T'T
 








 

viernes, 9 de octubre de 2020

CanOpen, Linux y STM32F103

Introducción. 

    Estuve trabajando en proyectos con CanOpen.
    Dicho protocolo era una materia pendiente para mi.
    Así que me dí a la tarea de tratar de entender y comunicarme mínimamente con dispositivos CanOpen de distintos fabricantes.

     Sin más dejaré asentado las herramientas que fuí utilizando, lejos está de estar optimizado el sistema, pero es un buen punto de partida, para quién esté interesado.

     Sepan que no soy un experto en el tema, así que quizás haya temas que no estan profundamente desarrollados y quizás, también, con algunos errores conceptuales. No obstante, los invito que si están realmente interesados en profundizar en el protocolo, busquen e investiguen. Con lo aquí descripto he podido comunicarme con cualquier equipo con 
CanOpen disponibles.

    Como siempre, lo aquí descripto, es lo que utilicé personalmente para entender y poner en marcha  este sistema.



Referencias:


    El texto en este formato y color es el devuelto por la PC.


    El texto en este formato y color es el que deben ingresar en la línea de comando.

Que es CanOpen?

Abunda información sobre lo que es CanOpen, así que si llegaron hasta esta entrada del blog, seguramente están necesitando algo mas práctico para empezar a utilizarlo.

Algunas definiciones aburridas, pero necesarias.
Resumen de definciones.

*- CanOpen posee tres modelos de comunicación:

    *- Master/Slave
    *- Client/Server
    *- Producer/Consumer 

*- Protocolos disponibles esenciales:

    NMT (Network management): Utilizado para establecer el estado del nodo. (Initialization, pre-operational, operational, stopped). 
 Utiliza el modelo Master/Slave

    SDO (Service device object): Utilizado para mensajes de configuración. (Permite leer y escribir registros determinados). También se puede utilizar para operar el dispositivo, no obstante es poco eficiente.
 Utiliza el modelo Master/Slave


Código de comados por SDO
Comando


4 byte de datos 2 byte de datos 1 byte de datos
5to a 8vo byte 5to a 6to byte 5to byte
Pedido de escritura (Enviar parámetro al drive) 23h 2Bh 2Fh
Respuesta de escritura (El drive responde a la solicitud de la escritura, reconociendola) 60h 60h 60h
Pedido de lectura (Pedido de lectura de un parámetro desde el drive) 40h 40h 40h
Respuesta de la lectura (Responde a la lectura con el valor actual) 43h 4Bh 4Fh
Respuesta con error 80h 80h 80h


Tabla 1


    PDO (Process device object): Utilizado para el intercambio de datos entre nodos en tiempo real.

     Los protocolos SYNC (Synchronization), EMCY (Emergency), TIME (TimeStamp) y HEARTBEAT (Node monitoring), están disponibles también, pero escapan a esta entrada (mas información en la WEB).

*-Estructura del paquete:


Identificador Datos
11 bits Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7

Tabla 2



Identificador
x x x x x x x x x x x
Cod. Funcion Id Nodo

Tabla 3


 Entre el Identificador y Datos existen 5 bits propios del telegrama Can, sin embargo, son generados por el módulo de Can del dispositivo, se han omitido por legibilidad.


Herramientas.


*-Slcan:

    Linux (distro Debian en mi caso), tiene disponible SocketCan, que provee algunas interfaces del tipo CAN:

    *- Interfaces virtuales como vcan0
    *- Interfaces nativas  (hardware real), como can0
    *- Interfaces SLCAN (interfaces serie), como slcan0
 
*-Stm32-slcan:

https://github.com/GBert/misc/tree/master/stm32-slcan



   Es un proyecto del tipo OpenSource, que utiliza librerías libopencm3, para convertir una placa blue-pill (STM32F103), en una económica interfaz serie para CAN.

    El código fuente lo compilé y subí a mi blue-pill, utilizando Atom junto al framework de libopencm3.

    He modifcado el archivo "usart.c", en la línea

    #define USART2_SPEED    500000

    para 

    #define USART2_SPEED    115200 

    Hice lo anterior ya que no podía comunicarme con el dispositivo (creo que mi adaptador USB-Serial TTL no soporta esa velocidad)

    En fuentes, dejo el link a los archivos  "slcan-bluepill.elf" y el "slcan-bluepill.bin", por si quieren evitar la compilación. Estos archivos, son los que subí a mi placa y funcionaron. 

    Para grabarlo en su placa pueden utilizar openocd (si poseen un dongle st-link) o con la utilidad  stm32flash para grabarlo por medio de un USB-serial TTL. ( Mas info en la web, quizás en algún momento elaboro una entrada con el uso de stm32flash).

    Además del firmware, para que nuestra placa pueda conectarse a un bus Can, es necesario colocar un adaptador de interfaz serial a Can, en mi caso utilicé el iso1050 el cual lo obtuve de unos PLC inoperantes. Este componente con encapsulado 8-Pin DUB, es muy fácil de conectar, y soldando unos pines es facilmente utilizable en un protoboard.

    El esquema de conexiones está perfectamente detallado en el repositorio de stm32-slcan. (no utilicé el MCP2562, ni los leds para el estado de comunicación que detalla en el diagrama)

Mi configuración para pruebas. En el HUB USB se observa el conversor USB-Serial TTL y mi dongle St-link. En el protoboard, fuente USB-Protoboard, ISO1050 (cable amarillo CanH, cable negro CanL) y blue-pill.
 
N.A.: Por alguna razón que aún no investigué, deben presionar reset en la blue-pill luego de flashear o al energizar el sistema, no siempre es necesario, pero en ocasiones que no pude comunicarme con los slaves, presionando reset, todo funcionaba correctamente. Así que, ni bien energizan, presionan reset.

*- CanOpen Slave:

    Para los primeros ensayos utilicé un variador de frecuencia WEG modelo CFW500 para 1Hp, al cual hay que añadirle un accesorio llamado plug-in CanOpen, para darle conectividad a la red (los manuales de los link están en español, no obstante estos equipos son de origen brasilero, por lo que recomiendo que utilicen los manuales en portugués, para quién comprenda dicho idioma, solo es una recomendación, en español son funcionales).


Pinout del plug-in para CFW500 (Recordar que CanOpen Posee alimentación independiente,  es decir no proviene del equipo). CAN H y CAN L, son conectados al montaje anteriormente descripto (cable amarillo y negro en mi montaje)

    Mas ensayos realicé con PLC unitronics, variador SEW, y un sensor de presión. Todos con resultados satisfactorios.

Poniendo en marcha el sistema.

Presentadas las herramientas, comenzaremos a configurarlas y utilizarlas.

Comenzamos en nuestra PC con Linux.

Para los ensayos utilicé Konsole (escritorio KDE), como terminal, en la cual abro 3(tres) pestañas, una con usuario root para el montaje de los módulos. Otra como usuario normal para enviar comandos y la tercera pestaña también como usuario normal para ver la actividad del CanOpen, con candump.


Cuando conecten su adaptador serial TTL a USB a la PC, asegurense de la denominación que linux le dió ($ ls /dev/tty*) en mi caso /dev/ttyUSB0
 



*- Iniciando slcan

    # modprobe can
 
    # modprobe can-raw

 
    # modprobe slcan

    # slcand -s2 -S115200 /dev/ttyUSB0 can0

    # ip link set up can0


Pestaña root para el montaje de los módulos y la inicialización de la interfaz
Ahora para utilizar las siguientes herramientas en Linux primero debemos instalar:

    # apt install can-utils

Una vez hecho lo anterior podremos hacer lo siguiente:

 
*- Analizando bus (pestaña terminal):
      En esta pestaña podremos observar toda la actividad del bus, desde lo que "enviamos" hasta todas las comunicaciones de los nodos. (esto último, muy útil para usuarios con experiencia)

    $ candump can0

Pestaña usuario normal con candump para registrar la actividad del bus


*- Enviando comandos (otra pestaña terminal):
     Desde esta pestaña "enviaremos" los comandos hacia los nodos. (mayormente los nodos son servidores y nuestra PC cliente)

Pestaña usuario normal utilizando cansend para enviar comandos hacia la red CanOpen



    Pasar a operacional al nodo ID 2
    $ cansend can0 000#0102



Ejemplo de paquete:

Queremos enviar un SDO desde master, solicitando al slave ID 2, el registro cuyo indice es  1008h y subindice 0. Para  un equipo "CanOpen-Compliant", este registro corresponde al nombre del nodo.

Comando linux:
Ejemplo de paquete:

Queremos enviar un SDO desde master, solicitando al slave ID 2, el registro cuyo indice es  1008h y subindice 0. Para  un equipo "CanOpen-Compliant", este registro corresponde al nombre del nodo.

Comando linux:

$ cansend can0 602#4008100000000000

 602 = Cob ID 600 + Id nodo 2 = 602

(Mas avanzado el tema explico como se arma el comando)

$ cansend can0 602#4008100000000000

 602 = Cob ID 600 + Id nodo 2 = 602

(Mas avanzado el tema explico como se arma el comando)

 
 ENTRADA EN DESARROLLO.

DEJA TU COMENTARIO PARA SEGUIR EL DESARROLLO DE LOS SIGUIENTES TEMAS:

 
*- Configuracion inicial del CFW500 (conexiones del plug-in, parametrización)
*- Comunicando con el CFW500.
*- Modificando parámetros con SDO. 
*- Modificando diccionario de objetos.
*- Control por PDO. 

*-Finalizando.


Fuentes:

https://www.canopensolutions.com/english/about_canopen/about_canopen.shtml


https://elinux.org/Bringing_CAN_interface_up

https://en.wikipedia.org/wiki/CANopen

https://www.csselectronics.com/screen/page/canopen-tutorial-simple-intro/language/en