cancel
Showing results for 
Search instead for 
Did you mean: 

Manage RTS/CTS in VCP mode

fabien
Associate II
Posted on February 11, 2015 at 15:24

Hello,

Can someone tell me if it is possible to manage RTS/CTS signals over USB in VCP mode please ? It seems that the CDC example can receive commands, but what should I do to set these signals in software ?

static uint16_t VCP_Ctrl (uint32_t Cmd, uint8_t* Buf, uint32_t Len)
{ 
switch (Cmd)
{
...
case SET_CONTROL_LINE_STATE:
/* Not needed for this driver */
...

Thanks.
9 REPLIES 9
Robmar
Senior III

9 years on ST Support staff still haven't replied.

It is a valid question, I also am looking for information on controlling the CTS signal over USB from a CDC host.

BarryWhit
Senior III

@Robmar, individual ST staff have a felt presence on the forum but this is not the primary support channel for ST. It is only a central place for customers/users to help one another and/or waste time.

 

You can open support requests for ST directly using the OLS (Online Support) system:

https://ols.st.com/s/

 

Update: if your volume is large enough, you might try to contact ST to get an FAE assigned.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

I've used OLS direct support and found it just a lacking, the fact is ST managers don't value the MCU product line, and the support is less than minimal.

I've solved all the issues I posted within our own team, but the feeling we have towards STM is that we cannot rely on the company.

BarryWhit
Senior III

That's a pretty standard state of affairs unless your sales volume has a noticeable effect on their stock valuation. Not exclusive to ST unfortunately.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

haha, wow, as STM's stock value recently tanked, we'd need to order about a zillion MCUs to get any attention, but even then STM as a company doesn't own the USB IP in their products, they bought it in from Synopsis, who do have a more complete USB driver, but even they just told me that it might be better to use TinyUSB off GitHub, as that private project has better support!
Look at Boeing, $ billions for their StarLiner, and the things an unstable disaster, so its not about money, its about intent and focus, of which STM IMHO have neither.

BarryWhit
Senior III

Yet airlines all over the world, as well as the US government with its awesome purchasing power, keep awarding Boeing billions and billions of dollars in contracts despite decades of failures, inefficiency, price-gauging, and outright fraud. The same goes for Lockheed-Martin or Northrop-Grumman. And most of humanity does the same with Facebook/Google/Apple/Microsoft/Amazon. Recently (but not for the first time), we have Intel with its 13/14th gen crisis. Why is that?

 

Yes, the system is rotten. No, ST is not a particularly bad example. It's bad only in the common way of its peers, as economic theory predicts. But in any case, ST can't stay in business if they spend more money on supporting your application than you paid them for the chips. That's something you can expect from any vendor. All the more so if their stock has taken a tumble - that would only reinforce such bean-counting on their side.

 

If you think pastures are greener with TI and others, I can only assume you are speaking "out of" experience (and by "out of" I mean as in "for lack of").

 

Update: oh, and USB support is a pure commodity. It makes absolutely zero business-sense for ST to spend the NRE on developing a custom USB IP. And any ASIC designer would know that buying IP blocks instead of developing your own is about as common as your buying tomatoes instead of growing them.

Any differentiation they can offer for USB, if any, is on the software side, but ST is not a software company. Which is why they've pivoted away from their own USB software stack towards ThreadX/UsbX, which is (for now at least) actively developed.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

I worked with Intel back in the 80s, I know how things are.

Since 2012 there are questions on this ST support forum that still haven't been answered but are still being asked by new customers. Some customers gave up and migrated to ESP or Raspberry Pi platforms which have extensive USB support.
STM's policy is to push clients to Microsoft RTOS which has better USB support, so clearly STM are not a computer company, and I think they don't have the intelligent focus needed to stay in the MCU business apart from in niche areas. My view, we'll know in a few years.

ST Paris staff support certain small clients well above requirements, it looks like there is some favouritism, perhaps the apple is a little rotten so no one really cares about MCU customers or whether STM fails in this sector.  Certainly their new MCUs lack features, and a new H743 with more SRAM would be very useful to better support LCD displays with higher resolutions without the need to add external RAM which is slow and costly.

We could chat all about what STM need lol, and get nowhere!

FBL
ST Employee

Hello @fabien 

Have you resolved your problem since then?

Here is an example on how to implement the MW function in your USBX CDC-ACM class handler in ux_device_device_cdc_acm.c  using USBX MW

 

 

/**
  * @brief  Manage the CDC class requests
  * @param  cdc Instance
  * @retval none
  */
VOID ux_app_parameters_change(VOID *cdc_acm)
{
  UX_SLAVE_TRANSFER *transfer_request;
  UX_SLAVE_DEVICE   *device;
  ULONG             request;
  ULONG             value;
  UINT ux_status = UX_SUCCESS;

  /* Get the pointer to the device.  */
  device = &_ux_system_slave -> ux_system_slave_device;

  /* Get the pointer to the transfer request associated with the control endpoint. */
  transfer_request = &device -> ux_slave_device_control_endpoint.
                     ux_slave_endpoint_transfer_request;

  /* Extract all necessary fields of the request. */
  request = *(transfer_request -> ux_slave_transfer_request_setup + UX_SETUP_REQUEST);
  value = _ux_utility_short_get(transfer_request -> ux_slave_transfer_request_setup + UX_SETUP_VALUE);

  /* Here we proceed only the standard request we know of at the device level.  */
  switch (request)
  {
    /* Set Line Coding Command */
    case UX_SLAVE_CLASS_CDC_ACM_SET_LINE_CODING :
    {
      /* Get the Line Coding parameters */
      ux_status = ux_device_class_cdc_acm_ioctl(cdc_acm,
                                                UX_SLAVE_CLASS_CDC_ACM_IOCTL_GET_LINE_CODING,
                                                &CDC_VCP_LineCoding);
      /* Check Status */
      if (ux_status != UX_SUCCESS)
      {
        Error_Handler();
      }

      /* Check if baudrate < 9600) then set it to 9600 */
      if (CDC_VCP_LineCoding.ux_slave_class_cdc_acm_parameter_baudrate < MIN_BAUDRATE)
      {
        CDC_VCP_LineCoding.ux_slave_class_cdc_acm_parameter_baudrate = MIN_BAUDRATE;

        /* Set the new configuration of ComPort */
        USBD_CDC_VCP_Config(&CDC_VCP_LineCoding);
      }
      else
      {
        /* Set the new configuration of ComPort */
        USBD_CDC_VCP_Config(&CDC_VCP_LineCoding);
      }
      break;
    }

    /* Get Line Coding Command */
    case UX_SLAVE_CLASS_CDC_ACM_GET_LINE_CODING :
    {
      ux_status = ux_device_class_cdc_acm_ioctl(cdc_acm,
                                                UX_SLAVE_CLASS_CDC_ACM_IOCTL_SET_LINE_CODING,
                                                &CDC_VCP_LineCoding);

      /* Check Status */
      if (ux_status != UX_SUCCESS)
      {
        Error_Handler();
      }
      break;
    }

    /* Set the control line state */
    case UX_SLAVE_CLASS_CDC_ACM_SET_CONTROL_LINE_STATE :
    {
      UX_SLAVE_CLASS_CDC_ACM *cdc_acm_instance = (UX_SLAVE_CLASS_CDC_ACM *)cdc_acm;

      /* Reset current line state values. */
      cdc_acm_instance -> ux_slave_class_cdc_acm_data_dtr_state = 0;
      cdc_acm_instance -> ux_slave_class_cdc_acm_data_rts_state = 0;

      /* Get the line state parameters from the host.  DTR signal. */
      if (value & UX_SLAVE_CLASS_CDC_ACM_LINE_STATE_DTR)
          cdc_acm_instance -> ux_slave_class_cdc_acm_data_dtr_state = UX_TRUE;               

      /* Get the line state parameters from the host.  RTS signal. */
      if (value & UX_SLAVE_CLASS_CDC_ACM_LINE_STATE_RTS)
          cdc_acm_instance -> ux_slave_class_cdc_acm_data_rts_state = UX_TRUE;               

      /* If there is a parameter change function call it.  */
      if (cdc_acm_instance -> ux_slave_class_cdc_acm_parameter.ux_slave_class_cdc_acm_parameter_change != UX_NULL)
      {        
          /* Invoke the application.  */
          cdc_acm_instance -> ux_slave_class_cdc_acm_parameter.ux_slave_class_cdc_acm_parameter_change(cdc_acm_instance);
      }
      break;
    }

    default :
      break;
  }
}

 

So, this function handles the UX_SLAVE_CLASS_CDC_ACM_SET_CONTROL_LINE_STATE request and updates the RTS and DTS states 

@Robmar I'm not sure the original question is about host mode! 

As you know, firmware examples provided may not cover all features or modes ...

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Yes, as mentioned, I am looking to implement control lines for CDC Host.