Haz una pregunta
  Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

14/07/2011 #21


Dispositivo Midi USB
josb86 dijo: Ver Mensaje
no hay problema jejej anoche despues de mucho darle y darle funciono solo le tengo conectado 8 pulsadores y 2 potenciometros muchas gracias por el descritor por alli encontre otro que que parece muy pedagogico lo adjunto
Código:
/* Name: usbconfig.h
 * Project: AVR USB driver
 * Author: Christian Starkjohann
 * Creation Date: 2005-04-01
 * Tabsize: 4
 * Copyright: (c) 2005 by OBJECTIVE DEVELOPMENT Software GmbH
 * License: Proprietary, free under certain conditions. See Documentation.
 * This Revision: $Id: usbconfig-prototype.h 216 2006-07-14 21:51:00Z cs $
 */

#ifndef __usbconfig_h_included__
#define __usbconfig_h_included__

/*
General Description:
This file is an example configuration (with inline documentation) for the USB
driver. It configures AVR-USB for an ATMega8 with USB D+ connected to Port D
bit 2 (which is also hardware interrupt 0) and USB D- to Port D bit 0. You may
wire the lines to any other port, as long as D- is on bit 0 and D+ is also
wired to INT0.
To create your own usbconfig.h file, copy this file to the directory
containing "usbdrv" (that is your project firmware source directory) and
rename it to "usbconfig.h". Then edit it accordingly.
*/

/* ---------------------------- Hardware Config ---------------------------- */

#define USB_CFG_IOPORTNAME      D
/* This is the port where the USB bus is connected. When you configure it to
 * "B", the registers PORTB, PINB and DDRB will be used.
 */
#define USB_CFG_DMINUS_BIT      3
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
 * This may be any bit in the port.
 */
#define USB_CFG_DPLUS_BIT       2
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
 * This may be any bit in the port. Please note that D+ must also be connected
 * to interrupt pin INT0!
 */

/* ----------------------- Optional Hardware Config ------------------------ */

#define USB_CFG_PULLUP_IOPORTNAME   D
/* If you connect the 1.5k pullup resistor from D- to a port pin instead of
 * V+, you can connect and disconnect the device from firmware by calling
 * the macros usbDeviceConnect() and usbDeviceDisconnect() (see usbdrv.h).
 * This constant defines the port on which the pullup resistor is connected.
 */
#define USB_CFG_PULLUP_BIT          4
/* This constant defines the bit number in USB_CFG_PULLUP_IOPORT (defined
 * above) where the 1.5k pullup resistor is connected. See description
 * above for details.
 */
/* #define  USB_BUFFER_SECTION         ".bss" */
/* The USB receive buffer (variable "usbRxBuf") with a length of 22 bytes
 * MUST NOT cross a 256 byte boundary. We have introduced this configuration
 * option to allow you to change the data segment where this buffer is
 * allocated. If you have problems with the default segment (start of .bss),
 * you may change this setting. See the comment in usbdrv.h for details.
 * On IAR C, the default is the TINY_Z segment (first 256 bytes). You must
 * change this default for devices which don't have RAM below 0x100.
 */

/* --------------------------- Functional Range ---------------------------- */

#define USB_CFG_HAVE_INTRIN_ENDPOINT    1
/* Define this to 1 if you want to compile a version with two endpoints: The
 * default control endpoint 0 and an interrupt-in endpoint 1.
 */
#define USB_CFG_HAVE_INTRIN_ENDPOINT3   0
/* Define this to 1 if you want to compile a version with three endpoints: The
 * default control endpoint 0, an interrupt-in endpoint 1 and an interrupt-in
 * endpoint 3. You must also enable endpoint 1 above.
 */
#define USB_CFG_IMPLEMENT_HALT          1
/* Define this to 1 if you also want to implement the ENDPOINT_HALT feature
 * for endpoint 1 (interrupt endpoint). Although you may not need this feature,
 * it is required by the standard. We have made it a config option because it
 * bloats the code considerably.
 */
#define USB_CFG_INTR_POLL_INTERVAL      10
/* If you compile a version with endpoint 1 (interrupt-in), this is the poll
 * interval. The value is in milliseconds and must not be less than 10 ms for
 * low speed devices.
 */
#define USB_CFG_IS_SELF_POWERED         0
/* Define this to 1 if the device has its own power supply. Set it to 0 if the
 * device is powered from the USB bus.
 */
#define USB_CFG_MAX_BUS_POWER           100
/* Set this variable to the maximum USB bus power consumption of your device.
 * The value is in milliamperes. [It will be divided by two since USB
 * communicates power requirements in units of 2 mA.]
 */
#define USB_CFG_SAMPLE_EXACT            1
/* This variable affects Sampling Jitter for USB receiving. When it is 0, the
 * driver guarantees a sampling window of 1/2 bit. The USB spec requires
 * that the receiver has at most 1/4 bit sampling window. The 1/2 bit window
 * should still work reliably enough because we work at low speed. If you want
 * to meet the spec, set this value to 1. This will unroll a loop which
 * results in bigger code size.
 * If you have problems with long cables, try setting this value to 1.
 */
#define USB_CFG_IMPLEMENT_FN_WRITE      1
/* Set this to 1 if you want usbFunctionWrite() to be called for control-out
 * transfers. Set it to 0 if you don't need it and want to save a couple of
 * bytes.
 */
#define USB_CFG_IMPLEMENT_FN_READ       1
/* Set this to 1 if you need to send control replies which are generated
 * "on the fly" when usbFunctionRead() is called. If you only want to send
 * data from a static buffer, set it to 0 and return the data from
 * usbFunctionSetup(). This saves a couple of bytes.
 */
#define USB_CFG_IMPLEMENT_FN_WRITEOUT   1
/* Define this to 1 if you want to use interrupt-out (or bulk out) endpoint 1.
 * You must implement the function usbFunctionWriteOut() which receives all
 * interrupt/bulk data sent to endpoint 1.
 */
#define USB_CFG_HAVE_FLOWCONTROL        0
/* Define this to 1 if you want flowcontrol over USB data. See the definition
 * of the macros usbDisableAllRequests() and usbEnableAllRequests() in
 * usbdrv.h.
 */

/* -------------------------- Device Description --------------------------- */

#define  USB_CFG_VENDOR_ID       0xc0, 0x16	/* VOTI / obdev subrange */
/* USB vendor ID for the device, low byte first. If you have registered your
 * own Vendor ID, define it here. Otherwise you use obdev's free shared
 * VID/PID pair. Be sure to read USBID-License.txt for rules!
 * This template uses obdev's shared VID/PID pair: 0x16c0/0x5e4.
 * Use this VID/PID pair ONLY if you understand the implications!
 */
#define  USB_CFG_DEVICE_ID       0xe4, 0x05	/* 0x05e4 = 1508, obdev MIDI */
/* This is the ID of the product, low byte first. It is interpreted in the
 * scope of the vendor ID. If you have registered your own VID with usb.org
 * or if you have licensed a PID from somebody else, define it here. Otherwise
 * you use obdev's free shared VID/PID pair. Be sure to read the rules in
 * USBID-License.txt!
 */
#define USB_CFG_DEVICE_VERSION  0x01, 0x00
/* Version number of the device: Minor number first, then major number.
 */
#define USB_CFG_VENDOR_NAME     'w', 'w', 'w', '.', 'c', 'r', 'y', 'p', 't', 'o', 'm', 'y', 's', '.', 'd', 'e'
#define USB_CFG_VENDOR_NAME_LEN 16
/* These two values define the vendor name returned by the USB device. The name
 * must be given as a list of characters under single quotes. The characters
 * are interpreted as Unicode (UTF-16) entities.
 * If you don't want a vendor name string, undefine these macros.
 * ALWAYS define a vendor name containing your Internet domain name if you use
 * obdev's free shared VID/PID pair. See the file USBID-License.txt for
 * details.
 */
#ifdef DEBUG_LEVEL
#	define USB_CFG_DEVICE_NAME     'V', '-', 'U', 'S', 'B', '-', 'M', 'I', 'D', 'I', '-', 'D', 'B', 'G'
#	define USB_CFG_DEVICE_NAME_LEN 14
#else
#	define USB_CFG_DEVICE_NAME     'V', '-', 'U', 'S', 'B', '-', 'M', 'I', 'D', 'I'
#	define USB_CFG_DEVICE_NAME_LEN 10
#endif
/* Same as above for the device name. If you don't want a device name, undefine
 * the macros. See the file USBID-License.txt before you assign a name if you
 * use a shared VID/PID.
 */
/*#define USB_CFG_SERIAL_NUMBER   'N', 'o', 'n', 'e' */
/*#define USB_CFG_SERIAL_NUMBER_LEN   0 */
/* Same as above for the serial number. If you don't want a serial number,
 * undefine the macros.
 * It may be useful to provide the serial number through other means than at
 * compile time. See the section about descriptor properties below for how
 * to fine tune control over USB descriptors such as the string descriptor
 * for the serial number.
 */
#define USB_CFG_DEVICE_CLASS        0	/* Defined at interface level */
#define USB_CFG_DEVICE_SUBCLASS     0	/* Defined at interface level */
/* See USB specification if you want to conform to an existing device class.
 */
#define USB_CFG_INTERFACE_CLASS     1	/* AUDIO class */
#define USB_CFG_INTERFACE_SUBCLASS  3	/* MIDI streaming */
#define USB_CFG_INTERFACE_PROTOCOL  0	/*  */
/* See USB specification if you want to conform to an existing device class or
 * protocol.
 * This template defines a HID class device. If you implement a vendor class
 * device, set USB_CFG_INTERFACE_CLASS to 0 and USB_CFG_DEVICE_CLASS to 0xff.
 */
#define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH    0	/* total length of report descriptor */
/* Define this to the length of the HID report descriptor, if you implement
 * an HID device. Otherwise don't define it or define it to 0.
 * Since this template defines a HID device, it must also specify a HID
 * report descriptor length. You must add a PROGMEM character array named
 * "usbHidReportDescriptor" to your code which contains the report descriptor.
 * Don't forget to keep the array and this define in sync!
 */

/* ------------------- Fine Control over USB Descriptors ------------------- */
/* If you don't want to use the driver's default USB descriptors, you can
 * provide our own. These can be provided as (1) fixed length static data in
 * flash memory, (2) fixed length static data in RAM or (3) dynamically at
 * runtime in the function usbFunctionDescriptor(). See usbdrv.h for more
 * information about this function.
 * Descriptor handling is configured through the descriptor's properties. If
 * no properties are defined or if they are 0, the default descriptor is used.
 * Possible properties are:
 *   + USB_PROP_IS_DYNAMIC: The data for the descriptor should be fetched
 *     at runtime via usbFunctionDescriptor().
 *   + USB_PROP_IS_RAM: The data returned by usbFunctionDescriptor() or found
 *     in static memory is in RAM, not in flash memory.
 *   + USB_PROP_LENGTH(len): If the data is in static memory (RAM or flash),
 *     the driver must know the descriptor's length. The descriptor itself is
 *     found at the address of a well known identifier (see below).
 * List of static descriptor names (must be declared PROGMEM if in flash):
 *   char usbDescriptorDevice[];
 *   char usbDescriptorConfiguration[];
 *   char usbDescriptorHidReport[];
 *   char usbDescriptorString0[];
 *   int usbDescriptorStringVendor[];
 *   int usbDescriptorStringDevice[];
 *   int usbDescriptorStringSerialNumber[];
 * Other descriptors can't be provided statically, they must be provided
 * dynamically at runtime.
 *
 * Descriptor properties are or-ed or added together, e.g.:
 * #define USB_CFG_DESCR_PROPS_DEVICE   (USB_PROP_IS_RAM | USB_PROP_LENGTH(18))
 *
 * The following descriptors are defined:
 *   USB_CFG_DESCR_PROPS_DEVICE
 *   USB_CFG_DESCR_PROPS_CONFIGURATION
 *   USB_CFG_DESCR_PROPS_STRINGS
 *   USB_CFG_DESCR_PROPS_STRING_0
 *   USB_CFG_DESCR_PROPS_STRING_VENDOR
 *   USB_CFG_DESCR_PROPS_STRING_PRODUCT
 *   USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER
 *   USB_CFG_DESCR_PROPS_HID
 *   USB_CFG_DESCR_PROPS_HID_REPORT
 *   USB_CFG_DESCR_PROPS_UNKNOWN (for all descriptors not handled by the driver)
 *
 */

#define USB_CFG_DESCR_PROPS_DEVICE                  USB_PROP_IS_DYNAMIC
#define USB_CFG_DESCR_PROPS_CONFIGURATION           USB_PROP_IS_DYNAMIC
#define USB_CFG_DESCR_PROPS_STRINGS                 0
#define USB_CFG_DESCR_PROPS_STRING_0                0
#define USB_CFG_DESCR_PROPS_STRING_VENDOR           0
#define USB_CFG_DESCR_PROPS_STRING_PRODUCT          0
#define USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER    0
#define USB_CFG_DESCR_PROPS_HID                     0	// USB_PROP_IS_DYNAMIC
#define USB_CFG_DESCR_PROPS_HID_REPORT              0
#define USB_CFG_DESCR_PROPS_UNKNOWN                 0

/* ----------------------- Optional MCU Description ------------------------ */

/* The following configurations have working defaults in usbdrv.h. You
 * usually don't need to set them explicitly. Only if you want to run
 * the driver on a device which is not yet supported or with a compiler
 * which is not fully supported (such as IAR C) or if you use a differnt
 * interrupt than INT0, you may have to define some of these.
 */
/* #define USB_INTR_CFG            MCUCR */
/* #define USB_INTR_CFG_SET        ((1 << ISC00) | (1 << ISC01)) */
/* #define USB_INTR_CFG_CLR        0 */
/* #define USB_INTR_ENABLE         GIMSK */
/* #define USB_INTR_ENABLE_BIT     INT0 */
/* #define USB_INTR_PENDING        GIFR */
/* #define USB_INTR_PENDING_BIT    INTF0 */

#endif				/* __usbconfig_h_included__ */

hay cosas que no entiendo pero este codigo sigue las explicaciones precisas y en orden del midi10.pdf
Josb86 vi que lograste armar un dispositivo con PIC que mandaba señales midi por usb, con 8 botones y 2 potes. ¿Serías tan amable de pasarme el codigo que estas utilizando? No he logrado enumerar mi dispositivo, y estoy tratando de armar algo similar a lo que mencionas.
Desde ya te agradezco.
Saludos
15/07/2011 #22


Con este descriptor, y acordandote de hacer la llamada desde el programa

#include <midi7.h> //USB Configuration and Device descriptors for this UBS device

tiene que funcionar. No cambies nada, y haz solo un programa que haga llamda a esto, y al conectarlo te lo tiene que reconocer como dispositivo midi. En cuanto te lo reconozca como midi, empieza a hacer lo de los botones y todo lo que quieras.
Pero el descriptor no lo hay que cambiar ni adaptar a los potenciometros. Vale tal como está.

Saludos y suerte
15/07/2011 #23


hola rachelies como andas, mira no se si a ti se te ha presentado un problema que se me sucede a mi. el controlador funciona perfectamente en mi pc de escritorio pero en mi portátil algunas veces se cuelga, el pic sigue trabajando pero el programa en este caso guitar rig no me recibe los datos que manda el pic y ya he probado en varios portátiles y pasa lo mismo.


crooin mira el archivo que coloca rachelies es el mas importante ahoramismo no estoy en el pc donde tengo el archivo de ccs primero que todo si has manejado usb de pic?
15/07/2011 #24


Pasa lo siguiente, he usado el descriptor que me esta en midi7.h pero parece que se enumera y se me cuelga la maquina. cuando reinicio aparece como dispositivo de audio usb, pero ningún programa lo ve como controlador midi. Por eso quería ver como era que lo enumerabas vos josb86.
Conocen algún programa para ver los descriptores de los dispositivos que se conectan, para ver que esta mandando el pic.
No sé porque no quieren compartir código que ya este probado que funciona, no creo que tenga sentido re-inventar la rueda. La parte de la enumeración y conexión usb es solo una parte de otros proyectos que si se quieren son mas personales, pero tanto la conexión usb, como cualquier otra interfaz, que solo son una parte de algo deberían compartirse. Igual es mi humilde opinion y respeto la forma de pensar de cada uno.
Desde ya mis saludos...
16/07/2011 #25


Para ver lo que está enviando y recibiendo el USB utilizo el USBTrace.
Por lo de los problemas de colgarse...yo no tengo portatiles, y en mi pc lo utilizo en Windows 7 64bits, y en Windows XP, en los dos sin problemas, y lo utilizo con el Traktor de Native Instruments. No he probado con otros, por lo que no sabria ayudar en eso.
Y crooin, no te enfades, ahora no tengo tiempo, pero nada más que pueda pongo aquí un código funcionando al 100% para que lo pruebes. Déjame uno o dos días, que este finde ando bastante liado.
Un saludo a todos

Bueno, aquí pongo un código que junto con el midi7.h, sirve para enviar 32 botones y 2 potenciometros. Está probado y a mi me funciona. Los botones están conectados en una matriz. Ahora si que no tengo mas tiempo para explicar más, pero solucionaré las dudas que vayan saliendo.
Archivos Adjuntos
Tipo de Archivo: rar MIDI_12.rar (2,2 KB (Kilobytes), 397 visitas)
17/07/2011 #26


crooin dijo: Ver Mensaje
Pasa lo siguiente, he usado el descriptor que me esta en midi7.h pero parece que se enumera y se me cuelga la maquina. cuando reinicio aparece como dispositivo de audio usb, pero ningún programa lo ve como controlador midi. Por eso quería ver como era que lo enumerabas vos josb86.
Conocen algún programa para ver los descriptores de los dispositivos que se conectan, para ver que esta mandando el pic.
No sé porque no quieren compartir código que ya este probado que funciona, no creo que tenga sentido re-inventar la rueda. La parte de la enumeración y conexión usb es solo una parte de otros proyectos que si se quieren son mas personales, pero tanto la conexión usb, como cualquier otra interfaz, que solo son una parte de algo deberían compartirse. Igual es mi humilde opinion y respeto la forma de pensar de cada uno.
Desde ya mis saludos...

jejeje por pasarlo no hay problema te cuento que es lo que pasa a mi notebook que es donde tengo todo me toco mandarle a hacer reballing no te preocupes que yo posteo el codigo
26/07/2011 #27

Avatar de Baruc

hola rachelies como andas, mira no se si a ti se te ha presentado un problema que se me sucede a mi. el controlador funciona perfectamente en mi pc de escritorio pero en mi portátil algunas veces se cuelga, el pic sigue trabajando pero el programa en este caso guitar rig no me recibe los datos que manda el pic y ya he probado en varios portátiles y pasa lo mismo.
Te cuento josb86 yo tengo un controlador comprado BCD2000 y me pasaba lo mismo que a vos. Averiguando por todos lados encontré que desactivando la placa LAN funciona, igual prueba con las 2 desactiva las 2 placas de red y verás. Espero eso te solucione el problema.
13/09/2011 #28


Hola He intentado con el descriptor de rachelies pero como ya habian mencionado no lo logro en mi notebook, al simularlo con proteus primero empieza a instalar el software de controlador pero justo despues de eso me sale pantallaso azul y se reinicia mi notebook, al reiniciarse vuelvo a probar y ya nno me sale pantallaso azul pero aunque me reconoce como dispositivo Audio USB no lo puede utilizar (sale signo de admiracion amarillo en el controlador). ¿Que puedo hacer? la verdad me estoy trabando mucho con el descriptor, no tengo idea de como se configura, he leido el documento "Universal Serial Bus Device Class Definition for MIDI Devices" pero no se como pasar a código. (Tengo Windows 7 x64 professional).
16/09/2011 #29


Deme dijo: Ver Mensaje
Hola He intentado con el descriptor de rachelies pero como ya habian mencionado no lo logro en mi notebook, al simularlo con proteus primero empieza a instalar el software de controlador pero justo despues de eso me sale pantallaso azul y se reinicia mi notebook, al reiniciarse vuelvo a probar y ya nno me sale pantallaso azul pero aunque me reconoce como dispositivo Audio USB no lo puede utilizar (sale signo de admiracion amarillo en el controlador). ¿Que puedo hacer? la verdad me estoy trabando mucho con el descriptor, no tengo idea de como se configura, he leido el documento "Universal Serial Bus Device Class Definition for MIDI Devices" pero no se como pasar a código. (Tengo Windows 7 x64 professional).
¿No tienes ningún pc con otro windows? El controlador que utiliza es de windows, no hace falta instalar nada. Yo tengo un pc con windows 7 x64 y me funciona correctamente todo. Si puedes trata de probarlo con otro windows para saber de donde viene el problema.
Saludos
19/11/2011 #30


hola la verdad me interesaria mucho poder crear un controlador midi ya qe me estoy llendo mucho por la rama de la musica electronica si podrian subir esqemas diagramas circuitos o fotos estaria muy agradecido
21/11/2011 #31


Hola Deme. Aquí puedes ver el esquema que tengo hecho a mano y una foto de como va el invento, jejeje. No tengo demasiado tiempo ahora para seguir con él. Espero que te sirva para empezar con el tuyo, y ya sabes, comenta lo que no sepas. Un saludo.
Imágenes Adjuntas
Tipo de Archivo: jpg Foto00982.jpg (367,7 KB (Kilobytes), 173 visitas)
Tipo de Archivo: jpg Foto01192.jpg (236,4 KB (Kilobytes), 174 visitas)
Tipo de Archivo: jpg Esquema2.jpg (382,8 KB (Kilobytes), 355 visitas)
02/03/2012 #32

Avatar de fernandoae

Muy bueno, y funcionó a la primera en un pic 18F2550, lo único que tuve que hacer desde el pickit fué cambiar las palabras de configuración porque tenia cristal de 4 mhz solamente.
Lo que si nunca programé en CCS y no puedo compilar nada desde el MpLab, me explicarias como crear un proyecto y compilarlo utilizando los dos archivos que están en el rar? porque al querer compilarlo me dice que faltan archivos, los tengo que buscar en la carpeta del mplab no? dame una manito asi arranco con el proyecto.
Ah y las jogwheels como las envias? como notas?
02/03/2012 #33


Con los jogwheels sólo hice pruebas antes de tener el programa completo, y no lo tengo aún probado en el controlador montado. Creo que lo enviaba como comandos CC, y enviaba 7F cuando giraba a derecha y 01 cuando giraba a izquierda, un envío por cada pulso.
Luego estos pulsos se configuran en el software (Traktor o Virtual Dj) para que los interprete como jogwheel.

Hace tiempo que probé esto y ahora no lo tengo muy claro. A ver si un día de estos tengo tiempo y lo vuelvo a probar y comento.

Sobre lo de integrar el CCS en el Mplab, buscando en google encontrarás ayudas más fáciles que lo que yo te podría explicar. No es dificil.

¿¿¿Te funciona con el cristal de 4Mhz???

Un saludo.
02/03/2012 #34

Avatar de fernandoae

Si, me funcionó con un pic 18f2550 y cristal de 4MHz porque antes de grabarlo con el Pickit 2 le cambie la palabra de configuración para acomodar el divisor y adecuarlo a los 4Mhz, esto me ha funcionado varias veces. El tema es que por ahi no tengo un determinado cristal y el autor del proyecto no da el código fuente, solo el hex para tal frecuencia
Tenés algún otro código más completo? con note on-off, cc... etc.. la verdad que soy de tomarme las cosas con calma, leer mucho hasta evacuar mis dudas y conseguir las cosas por mi cuenta...pero este proyecto me tiene medio ansioso y hace tiempo quiero hacerlo, hace un tiempo nomás me puse con el usb.
Todavia tengo que aprender a programar en CCS
Gracias por compartir tu proyecto, ojalá todos fuesemos así...
03/03/2012 #35

Avatar de fernandoae

Acá vengo con novedades, estuve leyendo un poco en la página del vdj y me enteré que se puede crear un controlador HID creando un archivo con la configuración (en la pc) de lo que hace cada byte enviado desde el pic... según lo que decia tiene menor latencia que el midi y lo recomiendan para las jogwheels. Pero la desventaja que le veo es que seria un poco mas incomodo asignar las funciones de cada boton o fader...
http://www.virtualdj.com/wiki/Contro...nitionHID.html
http://www.virtualdj.com/wiki/HIDImplementation.html

Que opinan? midi o hid?
Otro tema a tener en cuenta seria la compatibilidad entre programas
03/03/2012 #36

Avatar de tecniloco80

fernandoae dijo: Ver Mensaje
Acá vengo con novedades, estuve leyendo un poco en la página del vdj y me enteré que se puede crear un controlador HID creando un archivo con la configuración (en la pc) de lo que hace cada byte enviado desde el pic... según lo que decia tiene menor latencia que el midi y lo recomiendan para las jogwheels. Pero la desventaja que le veo es que seria un poco mas incomodo asignar las funciones de cada boton o fader...
http://www.virtualdj.com/wiki/Contro...nitionHID.html
http://www.virtualdj.com/wiki/HIDImplementation.html

Que opinan? midi o hid?
Otro tema a tener en cuenta seria la compatibilidad entre programas
es verdad si funciona lo que dice vdj prueba con un control de videojuego hid crea una configuracion en el virtualdj yo hice un controlador con 12 botones y 4 slider y funciona perfecto
03/03/2012 #37

Avatar de fernandoae

No me conformo con 4 sliders jeje quiero 20 minimo... igual es facil leer muchos analogicos con un pic... se podrian usar los modulos ain de midibox por ejemplo.
Tenés a mano el ejemplo de tu controlador?
03/03/2012 #38


El hid tiene eso, que no puedes poner muchos analógicos. Por otra parte, lo de la latencia no lo veo como problema, porque por lo menos en el mío funciona bien, no noto retardo.
Y en cuanto a la compatibilidad, el midi funciona en Virtual dj y en Traktor, que son 2 de los más conocidos.

En su día no me acuerdo porqué opté por el midi, pero sé que topé con algún impedimento en el hid que me hizo tirar hacia el midi. Pero bueno, también irá en gustos.

Por otra parte, en cuanto a una pregunta anterior sobre el note on/off, no lo utilizo, lo que empleo es el volumen de la nota, es decir, la pongo a 7F para botón activo, y a 00 para inactivo.
La subrutina que utilizo es esta:

Código:
void envianota()
{	
	envia[1]=0x90;
	envia[0]=envia[1]>>4;
	
	usb_put_packet(1,envia,4,USB_DTS_TOGGLE);
}
en ella, se envía una matriz de 4 bytes. El 0 y el 1 son los que dicen que se envía nota, que si no me equivoco, hay que enviar 0x90 y 0x09
En el byte 3 se envía el número de nota, y en el byte 4 el volumen.

---------- Actualizado después de 3 minutos ----------

fernandoae dijo: Ver Mensaje
Acá vengo con novedades, estuve leyendo un poco en la página del vdj y me enteré que se puede crear un controlador HID creando un archivo con la configuración (en la pc) de lo que hace cada byte enviado desde el pic... según lo que decia tiene menor latencia que el midi y lo recomiendan para las jogwheels. Pero la desventaja que le veo es que seria un poco mas incomodo asignar las funciones de cada boton o fader...
http://www.virtualdj.com/wiki/Contro...nitionHID.html
http://www.virtualdj.com/wiki/HIDImplementation.html

Que opinan? midi o hid?
Otro tema a tener en cuenta seria la compatibilidad entre programas
Leyendo en los enlaces esos, parece que hay bastante información sobre el HID, que hace un par de años cuando yo empecé con esto no existían. Todo sería estudiarlo e implementar un programa para el pic, ya que el hardware sirve el mismo no me perjudicaría en nada.

Saludos
03/03/2012 #39

Avatar de dinoelectro

no sabia que se puede hacer esto con USB... la informacion me ha caido de pelicula... siempre tuve la ilusion de hacerme un dispositivo que funcione con musica!!!... voy a leerlo con detenimiento para ver en que puedo colaborar!!!
03/03/2012 #40

Avatar de fernandoae

El hid tiene eso, que no puedes poner muchos analógicos
Por que no? si se pueden enviar reportes hid de 256 bytes... y ahi se acomodarian todos los datos necesarios....

Esto es lo que tengo hecho, y todavia no funciona :enfadado:

Primero hice un descriptor para el dispositivo, usando el VID y PID de mi joystick usb casero:



Acá surge la primer duda, en tamaño del reporte pongo 12 o pongo 13? esto es lo que me tira el hidtrace que es un soft para ver los reportes hid.



El byte 8 es el que varia al mover el pote, en el descriptor iria un 7 o un 8? porque depende de como arranque la numeración... 0 a 7 o 1 a 8, no se si se entiende

Por lo visto va bien, porque cuando inicio el VDJ me sale el mensaje este:



Asi que por lo menos dice que ahi está el invento conectado a la pc.
Pero cuando voy a los dispositivos no se como configurarlo porque no aparece



Por mas que le ponga que muestre los dspositivos desconectados...
Hasta ahora eso es todo, a seguir probando! vamos que va a salir algo bueno de acá... y al alcance de cualquier bolsillo, las consolas comerciales son muy costosas
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.