libusb & ATtiny85-20SU

[Kahn P. (Gast)]

Hallo zusammen,

ich bin Not geraten und vielleicht weiß jemand Rat.
Ich verwende den ATtiny85-20SU, und habe libusb installiert.

Alles wunderbar, libusb erzeugt keinen Physikalischen COM port (Fehler?)
Aber ich verwende die Arduino IDE über DIGISPARK 16.5Mhz (Default)
Der COM -Port wird also scheinbar ignoriert da nicht vorhanden.
Soweit alles gut und auch Programmierbar.

Ich möchte nun die libusb direkt ansprechen um Serial Daten mit dem
ATtiny zu teilen, dazu verwende ich teile des Codebeispiels aus
der libusb/bulk.c

Das Gerät wird gefunden und ich kann es öffnen und ein Interface 
erlangen.

Leider schlägt jedes Read oder Write mit einem Fehlercode -5 oder -22 
fehl.

// Device vendor and product id.
#define MY_VID 0x16D0
#define MY_PID 0x0753

// Device configuration and interface id.
#define MY_CONFIG 1
#define MY_INTF 0

// Device endpoint(s)
#define EP_IN 0x81
#define EP_OUT 0x01

// Device of bytes to transfer.
#define BUF_SIZE 8


usb_dev_handle *open_dev(void)
{
    struct usb_bus *bus;
    struct usb_device *dev;

    for (bus = usb_get_busses(); bus; bus = bus->next)
    {
        for (dev = bus->devices; dev; dev = dev->next)
        {
      printf("Vendor %0x4 Product %0x4\r\n", dev->descriptor.idVendor, dev->descriptor.idProduct);

            if (dev->descriptor.idVendor == MY_VID && dev->descriptor.idProduct == MY_PID)
            {
                return usb_open(dev);
            }
        }
    }
    return NULL;
}

int main(void)
{
    usb_dev_handle *dev = NULL; /* the device handle */
    char tmp[BUF_SIZE];
    int ret;
    void* async_read_context = NULL;
    void* async_write_context = NULL;

    usb_init(); /* initialize the library */
    usb_find_busses(); /* find all busses */
    usb_find_devices(); /* find all connected devices */

    if (!(dev = open_dev()))
    {
        printf("error opening device: \n%s\n", usb_strerror());
        return 0;
    }
   
    if (usb_claim_interface(dev, 0) < 0)
    {
        printf("error claiming interface #%d:\n%s\n", MY_INTF, usb_strerror());
        usb_close(dev);
        return 0;
    }
 
    // Running a sync write test
    ret = usb_bulk_write(dev, EP_OUT, tmp, sizeof(tmp), 5000);
    if (ret < 0) printf("error writing:\n%s\n", usb_strerror());
   
    // Running a sync read test
    ret = usb_bulk_read(dev, EP_IN, tmp, sizeof(tmp), 5000);
    if (ret < 0) printf("error reading:\n%s\n", usb_strerror());
 
    usb_release_interface(dev, 0);

    if (dev)  usb_close(dev);
    
    return 0;
}

Für Hinweise wäre ich sehr dankbar,
 grüße
   Karsten

[Jim M. (turboj)]

Wie lauten die Fehlermeldungen zu den Codes? Wenigstens eine klingt nach 
timeout, d.h. der µC hat die Daten nicht rechtzeitig bereitgestellt oder 
abgenommen.

Ist das VUSB? Dort würde ich eher mit Control Transfers arbeiten, Bulk 
ist bei low speed laut USB Spec nicht erlaubt.

[Kahn P. (Gast)]

Hallo Jim,

die Meldungen aus dem Codefragment lauten wie folgt:

Vendor 16d04 Product 7534
error writing:
libusb0-dll:err [submit_async] submitting request failed, win error: The 
parameter is incorrect.

error reading:
libusb0-dll:err [submit_async] submitting request failed, win error: The 
parameter is incorrect.

Press any key to continue . . .


Ich habe mit usb_control_msg statt bulk die selben Fehler erlangt.


Auf dem Chip habe ich ein blockendes Read auf den Serialport,
es soll schreiben falls Daten rdy.

Ich verwende TinyWireM Objekt. hoffe das ist überhaupt das richtige.
(Bin gerade neu dazu gestoßen vorher ADuc70)

Wenn der Chip keine lese/schreib Aktionen auslöst sollte ja das timeout 
wirken, alle Fehler werden sofort ausgelöst.


IDE Prog:

#include <TinyWireM.h>      // By default: SCL -> PB2(#2), SDA -> PB0(#0)

#define MOD_TC_MK2_ADDR   0x23
#define GET_TEMP    0x21

#define  Delay_time_ms    50
#define  Led              1  // Select the pin where the led is attached. Options: from 0 to 4


// This function switches over the Led when is called
void Toggle_Led(void)
{
  if(digitalRead(Led)==HIGH)
  { 
    digitalWrite(Led, LOW);   
  }
  else
  {                       
    digitalWrite(Led, HIGH);  
  }
}

// The setup routine is executed once when you power-on the board or press the RST button later
void setup() 
{
  pinMode(Led, OUTPUT);    // initialize the digital pin as an output.
  digitalWrite(Led, LOW);  // Set it in Low state
  
  TinyWireM.begin();         // I2C init
}


// The loop routine runs over and over again until power-off the board or interrupt occure:
void loop() 
{
  uint8_t data[4];
  uint8_t i = 0;
 
  TinyWireM.requestFrom(MOD_TC_MK2_ADDR,4);//this blocks!
  while(TinyWireM.available() > 0)
    data[i++] = TinyWireM.receive();
    
  if(i)
  {
   TinyWireM.beginTransmission(MOD_TC_MK2_ADDR);
   TinyWireM.send(GET_TEMP);
   TinyWireM.endTransmission();
  }
  
   Toggle_Led();
   
   delay(Delay_time_ms);
}

[Jim M. (turboj)]

> Ich verwende TinyWireM Objekt

Für USB ist das sicher das falsche Objekt. TinyWireM braucht man IMHO 
für I²C, ich sehe in dem Sketch nichts für USB. Die VID und PID sind vom 
Bootloader.

Wenn Du USB Bulk Daten austauchen wills, solltest Du Dir einen 
potenteren µC aussuchen, der USB nativ anbinden kann. Das ist mit 12 
MBit/s auch deutlich schneller, die 1,5 MBit bei low speed können 
durchaus ein Nadelöhr darstellen.

[Kahn P. (Gast)]

Hallo Jim,

Es geht eher um die Kommunikation denn die schlägt bei jedem lese oder
schreibversuch, sofort fehl. Öffnen vendor/prod lesen alles kein 
Problem.

Nach dem erfolgreichen öffnen des Gerätes via Libusb0.dll

Löst bereits die blose Abfrage nach device details folgenden Fehler aus:

rval = usb_control_msg(dev,
    USB_TYPE_STANDARD | USB_RECIP_DEVICE | USB_ENDPOINT_IN,
    USB_REQ_GET_DESCRIPTOR, (USB_DT_STRING << 8) + index, langid,
    buffer, sizeof(buffer), 1000);

libusb0-dll:err [control_msg] sending control message failed, win error: 
A device attached to the system is not functioning.

Die IDE hat keine Probleme mit dem Gerät zu kommunizieren.

>>potenteren µC aussuchen
Naja es ist ja kein Spassproject, und bereits der entscheid für einen
micro-controller abgewogen.

Man möchte also nur geringe Daten gelegentlich tauschen.

Scheinbar liegt ein genereller Fehler vor.

[Jim M. (turboj)]

Die USB Deskriptoren muss man nich abfragen. Die Strukturen die 
usb_get_busses() holt enthalten bereits alles nötige bis auf Strings. 
Dort sollte man sich erstmal die Endpoint Deskriptoren ansehen.

Unter Linux geht das einfach mit

lsusb -v

aber unter Windows kenne ich kein leider nichts vergleichbares.