[andy100 0]

Приветствую всех!

 

Есть примеры на сайте микрочип, generic driver demo.

 

При написании эмулятора мыши вопросов не возникло - hid и передача координат, прямо из примера.

 

при эмуляции eGalax возникли вопросы - с usb2.0 определяется, но не посылаются данные

ставлю usb1.1. (в дескрипторе и low_speed) - не определяется.

 

логи прилагаю

 

оплачу и совет, если человек в теме, если вставлю кусок кода в наш проект Mplab x и заработает передача.

сейчас передача

 

INPacket._byte[0]=0x55;

INPacket._byte[1]=0x54;

INPacket._byte[2]=0x53;

INPacket._byte[3]=0x52;

INPacket._byte[4]=0x51;

INPacket._byte[5]=0x50;

INPacket._byte[6]=0x56;

INPacket._byte[7]=0x57;

 

if (!USBHandleBusy(USBGenericInHandle))

 

{

USBGenericInHandle = USBGenWrite(1,(BYTE*)&INPacket, 8);

}

 

и ничего не передается. Может быть потому что 2.0 а драйвер ожидает 1.1

 

 

Задача срочная.

 

Generic_Driver_Demo___Firmware.rar

USBlyzerLog.rar

[vk123 0]

Ниже мой полный вариант этой функции, работает без нареканий.

Передача производится, когда основная программа установит флаг TrmUSB. А дальше все, как в примере.

 

Функция приема/передачи:

 

void APP_DeviceVendorBasicDemoTasks(void)

{

 

 

//User Application USB tasks below.

//Note: The user application should not begin attempting to read/write over the USB

//until after the device has been fully enumerated. After the device is fully

//enumerated, the USBDeviceState will be set to "CONFIGURED_STATE".

if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1)) return;

 

//As the device completes the enumeration process, the USBCBInitEP() function will

//get called. In this function, we initialize the user application endpoints (in this

//example code, the user application makes use of endpoint 1 IN and endpoint 1 OUT).

//The USBGenRead() function call in the USBCBInitEP() function initializes endpoint 1 OUT

//and "arms" it so that it can receive a packet of data from the host. Once the endpoint

//has been armed, the host can then send data to it (assuming some kind of application software

//is running on the host, and the application software tries to send data to the USB device).

 

//If the host sends a packet of data to the endpoint 1 OUT buffer, the hardware of the SIE will

//automatically receive it and store the data at the memory location pointed to when we called

//USBGenRead(). Additionally, the endpoint handle (in this case USBGenericOutHandle) will indicate

//that the endpoint is no longer busy. At this point, it is safe for this firmware to begin reading

//from the endpoint buffer, and processing the data. In this example, we have implemented a few very

//simple commands. For example, if the host sends a packet of data to the endpoint 1 OUT buffer, with the

//first byte = 0x80, this is being used as a command to indicate that the firmware should "Toggle LED(s)".

if(!USBHandleBusy(USBGenericOutHandle)) //Check if the endpoint has received any data from the host.

{

int i;

for (i=0;i<(sizeof(OUTPacket)-2);i++)

{

OUTPacketStep=OUTPacket[i+2];

}

OUTPacket[0]=0;

 

switch(OUTPacket[0]) //Data arrived, check what kind of command might be in the packet of data.

{

case 0x80: //Toggle LED(s) command from PC application.

LED_Toggle(LED_DEVICE_VENDOR_BASIC_DEMO);

break;

case 0x81: //Get push button state command from PC application.

//Now check to make sure no previous attempts to send data to the host are still pending. If any attemps are still

//pending, we do not want to write to the endpoint 1 IN buffer again, until the previous transaction is complete.

//Otherwise the unsent data waiting in the buffer will get overwritten and will result in unexpected behavior.

if(!USBHandleBusy(USBGenericInHandle))

{

//The endpoint was not "busy", therefore it is safe to write to the buffer and arm the endpoint.

INPacket[0] = 0x81; //Echo back to the host PC the command we are fulfilling in the first byte. In this case, the Get Pushbutton State command.

if(BUTTON_IsPressed(BUTTON_DEVICE_VENDOR_BASIC_DEMO) == false) //pushbutton not pressed, pull up resistor on circuit board is pulling the PORT pin high

{

INPacket[1] = 0x01;

}

else //sw2 must be == 0, pushbutton is pressed and overpowering the pull up resistor

{

INPacket[1] = 0x00;

}

 

//The USBGenWrite() function call "arms" the endpoint (and makes the handle indicate the endpoint is busy).

//Once armed, the data will be automatically sent to the host (in hardware by the SIE) the next time the

//host polls the endpoint. Once the data is successfully sent, the handle (in this case USBGenericInHandle)

//will indicate the the endpoint is no longer busy.

USBGenericInHandle = USBGenWrite(USBGEN_EP_NUM,(uint8_t*)&INPacket,USBGEN_EP_SIZE);

}

break;

}

 

//Re-arm the OUT endpoint for the next packet:

//The USBGenRead() function call "arms" the endpoint (and makes it "busy"). If the endpoint is armed, the SIE will

//automatically accept data from the host, if the host tries to send a packet of data to the endpoint. Once a data

//packet addressed to this endpoint is received from the host, the endpoint will no longer be busy, and the application

//can read the data which will be sitting in the buffer.

USBGenericOutHandle = USBGenRead(USBGEN_EP_NUM,(uint8_t*)&OUTPacket,USBGEN_EP_SIZE);

}

 

if (TrmUSB)

{

TrmUSB=0;

int i;

USBTrmBusy=1;

for (i=0;i<sizeof(INPacket);i++)

INPacket=StepINPacket;

 

USBGenericInHandle = USBGenWrite(USBGEN_EP_NUM,(uint8_t*)&INPacket,USBGEN_EP_SIZE);

USBTrmBusy=0;

}

}//end ProcessIO

 

 

 

[Andy-spb 0]

Если устройство должно работать как low-speed - то надо включать pull-up резистор на линию D-.

В контроллере есть внутренние резисторы на линии D+ и D-, которые управляются программно.

 

В этом контексте смущает вот этот кусок кода в файле usb_config.h:

 

#define USB_SPEED_OPTION USB_FULL_SPEED

// USB_LOW_SPEED (not valid option for PIC24F devices)

Изменено 23 декабря, 2015 пользователем Andy-spb

[andy100 0]

Если устройство должно работать как low-speed - то надо включать pull-up резистор на линию D-.

В контроллере есть внутренние резисторы на линии D+ и D-, которые управляются программно.

 

В этом контексте смущает вот этот кусок кода в файле usb_config.h:

 

#define USB_SPEED_OPTION USB_FULL_SPEED

// USB_LOW_SPEED (not valid option for PIC24F devices)

 

 

в дескрипторе вместо 200 ставлю 11 - ок, но скорость то 2.0.

 

Low_speed ставил - сразу перестает определяться. Я пока не смотрел, но думал low_speed сам эти резисторы переключает.