The USB topic

[Giovanni]

Hello,

Those interested in "official" USB support should check out this branch: https://chibios.svn.sourceforge.net/svn ... es/usb_dev

Briefly, this is the status:

• Generic USB driver, almost done, the API has not been frozen yet but it is so far amazingly simple. Any feedback is welcome, my USB experience is limited.
• Generic "Serial over USB driver", almost done. This is is a virtual com driver that exposes to the application the same API of a serial driver (an idea from the forum user "albi", he implemented this using the standard ST USB driver, which I hate, but I really liked the general idea).
• STM32 driver implementation, working enough to create a "Hello World!"-level virtual com demo.

The idea is to create the a driver with all the complex part coded in the generic driver and only requiring a very simple low level driver on the various architectures. Probably this will not be ready in time for 2.2.0 and will be merged in 2.3.0.

Giovanni

[albi]

Hi Giovanni, I gave a quick look at the code, I think you must also use the ISTR_SOF interrupt (an periodic interrupt generated from the host)
in order to trigger an periodic start of data trasmission when the usb tx buffer isn't full
otherwise the data trasmission will start only when the usb tx buffer is full or by an explicit command
for more clarity, i add an fragment of code used by me

Code: Select all

/*******************************************************************************
 * Function Name  : EP1_IN_Callback  (device Tx)
 * Description    :
 * Input          : None.
 * Output         : None.
 * Return         : None.
 *******************************************************************************/
int32_t EP1_buffer_write(uint8_t* buffer, int32_t len)
{
  return USB_SIL_Write(EP1_IN, buffer, len);
}

void EP1_IN_Callback(void)
{
  int32_t n;
  if (USB1.txongoing) {
    n = vcRequestDataI(&USB1, VIRTUAL_COM_PORT_DATA_SIZE, EP1_buffer_write);
#ifndef USE_STM3210C_EVAL
    SetEPTxValid(ENDP1);
#endif
    USB1.txongoing = (n>0);
  }
}

/*******************************************************************************
 * Function Name  : SOF_Callback / INTR_SOFINTR_Callback
 * Description    :
 * Input          : None.
 * Output         : None.
 * Return         : None.
 *******************************************************************************/
void SOF_Callback(void) {
  if (bDeviceState == CONFIGURED) {
    if (!USB1.frame_count--) {
      /* Reset the frame counter */
      USB1.frame_count = VCOMPORT_IN_FRAME_INTERVAL;
      /* Start the data to be sent through IN pipe */
      if (!USB1.txongoing && !chOQIsEmptyI(&USB1.oqueue)) {
        int32_t b = chOQUsedSpaceI(&USB1.oqueue);
        USB1.txongoing = (b>0);//TRUE;
        EP1_IN_Callback();
      }
    }
  }
}

Alberto

[Giovanni]

Hi Alberto,

I also think the SOF interrupt should be supported, probably as some kind of callback, the driver is still a prototype so it may be missing some features.

I am not sure that a periodic check is required however, in the "Serial over USB" driver the queue status is tested both when a packet has been transmitted and when some data have been inserted in the output queue (using the output queue notification callback). The test should not require a filled queue in order to trigger a packet transmission, unless there are problems of course.

Giovanni

[gniibe]

Hi, I am happy to see USB support in ChibiOS.

It would be good to add the function of unique chip ID.
I think that many CPU has such an ID, and it could be used for
generate serial number of USB device.

Host machine can distinguish devices by their serial numbers.
Users can know/specify to which device communicate,
when multiple same kind of devices are connected.

Perhaps, it would be also useful for other purpose than USB device too.

[Giovanni]

It is an interesting idea, probably it could take the form of an "id" device driver or a specific function in the HAL driver. I'll add this to the to-do list for 2.3.x.

Giovanni

[albi]

Hi Giovanni,

if you modify a bit this driver, i can test it easly on my actual job
you should just have to make compatible the USBD1 driver with SerialDriver type
as to be used with the standard serial APIs.
My time is not much and I have to move quickly from my usb driver to your one, and vice versa in case of trouble.

Alberto

[Giovanni]

Hi,

It is not possible currently to make it use the same "sd" group APIs, those are specific of the SerialDriver class, just like the "sdu" group is specific of the SerialUSBDriver class. It would be possible to use the same group for both drivers because both use I/O queues but the problem is that it would create a dependency among the two drivers, in which module the #define would be declared?

If you want to work interchangeably with both drivers you can use the functions of the common ancestor class BaseAsynchronousChannel.
The functions you should use are those in the group "chIO", for example chIOWriteTimeout(), chIOPutTimeout(), chIOGetAndClearFlags() etc. This group can be used with any serial-like device driver derived from BaseAsynchronousChannel.

Do you have a different suggestion?

Giovanni

[Badger]

Hello,

The latest changes on SVN which removed q_sem from GenericQueue has broken the USB CDC demo. I tried casting GenericQueue as a semaphore as the beginning of the structure almost has the same memory alignment (apart from the type of q_counter) but that didn't work. Obviously this is to be expected when working with brand new features from svn

[Giovanni]

Forgot about that I'll make adjustments tomorrow.

Giovanni

[gniibe]

Hello,

Thanks a lot for USB driver. This is a feedback from a user.

I think that it would be better to provide a API to enable USB connection.

In STM32 example, there is a line like:

Code: Select all

     palClearPad(GPIOC, GPIOC_USB_DISC);

but, in case of my board (STBee Mini), it's GPIOA which controls USB line.

Some abstraction is needed.
--