[Forger 26]

9 minutes ago, haker_fox said:

Коллеги, полностью разделяю мнение о кубе.

А куб в данном случае как раз ни при чем, это - вполне годный софт для своего круга задач 

Речь же про настойчивое желание всунуть куб в каждый проект. Итог - возникают темы, подобные этой ;)

[haker_fox 61]

2 hours ago, Forger said:

софт для своего круга задач

Тут даже и возразить трудно!))

2 hours ago, Forger said:

куб в каждый проект.

Это да) Я вот сейчас в свободное от работы время (ибо на работе это нахрен никому не надо(((((((((((( ) занялся своим фреймворком: пишу свои дрова, свои хидеры для МК, делаю одинаковые обрамления (интерфейсы) для разных осей и т.п. Попутно стараюсь применить все доступные няшки и фишки из Си++17 (14, 11)... Правда работа идёт довольно медленно, ибо вечерами, если не занят ремонтом квартиры Но вкус от этого занятия получаю прекрасный!

[uriy 5]

Я был уверен что USB_OTG_HS означает HighSpeed. Разве это не так? Поэтому не понимаю зачем ставить внешний PHY если на мой взгляд все уже есть внутри чипа. Сам я применял STM32 только на FullSpeed. По-моему он совсем не годится для работы на HighSpeed

[dimka76 63]

31 minutes ago, uriy said:

Я был уверен что USB_OTG_HS означает HighSpeed. Разве это не так? Поэтому не понимаю зачем ставить внешний PHY если на мой взгляд все уже есть внутри чипа. Сам я применял STM32 только на FullSpeed. По-моему он совсем не годится для работы на HighSpeed

STM имеет встроенный PHY только для FullSpeed.
Для HighSpeed нужен внешний PHY.

[jcxz 243]

3 часа назад, dimka76 сказал:

Для HighSpeed нужен внешний PHY.

... или другими словами: Для HighSpeed нужен другой МК.  

[uriy 5]

Теперь понятно

[Obam 38]

Я был уверен что USB_OTG_HS означает HighSpeed... Сам я применял STM32 только на FullSpeed. По-моему он совсем не годится для работы на HighSpeed

Означает и является параллельным интерфейсом ULPI к внешней физике.
...ДОжили: 200МГц "процы" с полумегабайтом ОЗУхи (F779) не годятся для HS-USB Ж8-\

[MementoMori 4]

Разобрался. Вдруг кому будет полезно.

Если настроить некую ножку под этот Driver_VBUS_HS, то вот что будет в файле usbh_conf.c    - MX_DriverVbusHS(state) - управляет той ногой, которую указать в Кубе.

USBH_StatusTypeDef USBH_LL_DriverVBUS(USBH_HandleTypeDef *phost, uint8_t state)
{
  if (phost->id == HOST_HS) {
    MX_DriverVbusHS(state);
  }

  /* USER CODE BEGIN 0 */

  /* USER CODE END 0*/

  HAL_Delay(200);
  return USBH_OK;
}

а в usb_h_platform.c
  
  void MX_DriverVbusHS(uint8_t state)
{ 
  uint8_t data = state; 
  /* USER CODE BEGIN PREPARE_GPIO_DATA_VBUS_HS */
  if(state == 0)
  {
    /* Drive high Charge pump */ 	     
    data = GPIO_PIN_SET;
  }
  else
  {
    /* Drive low Charge pump */
    data = GPIO_PIN_RESET;
  }
  /* USER CODE END PREPARE_GPIO_DATA_VBUS_HS */
  HAL_GPIO_WritePin(GPIOA,GPIO_PIN_10,(GPIO_PinState)data);
}

Можно просто оставить эту настройку в режиме undefined.  Появится предупреждение, но код будет сгенерирован.

Вот что будет в файле usbh_conf.c  - вызов MX_DriverVbusHS(state) исчезнет.

USBH_StatusTypeDef USBH_LL_DriverVBUS(USBH_HandleTypeDef *phost, uint8_t state)
{

  /* USER CODE BEGIN 0 */

  /* USER CODE END 0*/

  if (phost->id == HOST_HS)
  {
    if (state == 0)
    {
      /* Drive high Charge pump */
      /* ToDo: Add IOE driver control */
      /* USER CODE BEGIN DRIVE_HIGH_CHARGE_FOR_HS */

      /* USER CODE END DRIVE_HIGH_CHARGE_FOR_HS */
    }
    else
    {
      /* Drive low Charge pump */
      /* ToDo: Add IOE driver control */
      /* USER CODE BEGIN DRIVE_LOW_CHARGE_FOR_HS */

      /* USER CODE END DRIVE_LOW_CHARGE_FOR_HS */
    }
  }
  HAL_Delay(200);
  return USBH_OK;
}

 

То есть управление VBUS - это необязательная фишка. Я так полагаю, придуманная для случая, если подключаемый EXT_PHY не  умеет управлять VBUS.

Я правильно понял смысл?