• AVR
• микроконтр
• Система
• Архитектура
• ATmega128
• 7/16-битный

AVR280

Демонстрация USB CDC хоста

1.Введение

Интерфейс RS232 исчезает из ПК нового поколения, его заменяет интерфейс USB. Для соответствия этому изменению приложения на базе интерфейса UART должны переходить на USB. Переход на USB может привести к сложным разработкам как на стороне устройства, так и на стороне ПК. Для того, чтобы избежать этих сложностей, Atmel предлагает Вам решение на базе класса CDC (Communication Device Class):

• Приложение-устройство класса CDC (см. Application Note AVR272): такое устройство может быть подключено к ПК и является виртуальным последовательным портом.
  
• Хост приложение класса CDC: это приложение заменяет ПК, легко осуществляет связь с CDC устройством.

Цель этого документа — описание начала реализации и разработки CDC хост-приложения с использованием отладочного набора STK525 или USBKEY, и в конце демонстрируется простой пример двойного моста USB-UART между двумя ПК.

Предполагается, что разработчик знаком с программным шаблоном AVR USB (http://www.atmel.com) и спецификацией CDC (http://www.usb.org).

Рисунок 1-1. CDC хост приложение

2. Принцип работы

2.1 Конфигурирование CDC

2.1.0.1 USB

Конфигурирование CDC класса заключается в конфигурировании двух интерфейсов:

• Интерфейс данных: состоит из двух каналов (обычно осуществляют передачу массивов данных), по каналу на каждое направление передачи для обмена данными.
• Интерфейс связи: используется для передачи запросов для управления состоянием устройства и регистрации событий. Интерфейс состоит из двух элементов:
  • Управляющий элемент, который состоит из нулевой конечной точки и конфигурирует и управляет устройством с помощью стандартных и специальных запросов.
  • Опциональный регистрирующий элемент, который состоит из конечной точки в режиме передачи по прерываниям (или передачи массивов данных), используемой устройством для извещения хоста о событиях. Передаваемые сообщения имеют следующий формат: 8-байт заголовка, а за ним поле переменной длины.

В итоге, CDC приложение должно иметь два канала в добавок к управляющей конечной точке. Но заметьте, что CDC устройство распознается стандартным ПК, (с помощью драйвера по умолчанию) только если оно содержит опциональный элемент регистрации.

2.1.0.2 Модели

Спецификация CDC класса представляет различные модели связи. Каждая модель характеризуется типом реализованного интерфейса и поддерживаемыми командами или протоколом. Это особенно используеется при связи с USB модемами, которые могут использовать специфический уровень протокола (например V42bis), и даже с USB телефонами и т.д.

Но для пользователей, которые не принимают во внимание эти модели, а только хотят реализовать обмен данными между двумя приложениями, эти модели не имеют значения.

Эти «рекомендации» коротко представляют читателю эти модели и соответствующие команды и /или запросы. Как бы то ни было, основная цель этого документа — объяснить архитектуру низкого уровня CDC хост приложения и продемонстрировать простейшую конфигурацию на демонстрационном примере.

2.2 Передачи

2.2.1. Передачи данных

2.2.1.1 Исходные данные

После того, как хост провел энумерацию устройства, можно легко пересылать данные между приложениями.

• Устройство может заполнять свои IN конечные точки любым количеством данных. Предполагается, что хост опрашивает IN конечные точки так часто, как это возможно и получает все данные в свой IN канал.
• Хост может заполнять свой OUT канал любым количеством данных. Устройство получит пакет в свою OUT конечную точку как только хост закончит передачу.

Это простейший способ для реализации обмена данными между двумя базовыми приложениями с использованием USB, но с простотой UART:

• использовать передачу массивов данных, которая может теоретически осуществляться с максимальной скоростью 1.2 Мбайт/с в режиме Full Speed.
• Уменьшенный размер разъема USB (и меньшая стоимость).

Это самый простой случай использования моста UART-USB. В такой конфигурации когда устройство прошло энумерацию и было сконфигурировано, интерфейс управления может не использоваться, а весь обмен данными осуществояться через интерфейс данных.

2.2.1.2 Инкапсулированные данные

Для приложений более высокого уровня CDC класс определяет формат инкапсуляции данных для обработки пакета упаковщиком данных протокола. Этот режим здесь обсуждаться не будет, т.к. Он выходит за рамки простой демонстрации. Для получения более подробной информации см. Таблицу 1 на стр 1 Спецификации CDC ("CDC Class Specification v1.1").

2.2.2 Управление связью

Эта часть класса не является обязательной для приложений осуществляющих простой обмен данными.

2.2.2.1 Управляющий элемент

Хост может посылать двунаправленные запросы устройству через управляющую конечную точку. Формат этих запросов соответствует Спецификации USB 2.0:

Таблица 2-1. Формат пакета управляющего запроса

Можно рассматривать два типа запросов:

• Запросы, которые переводят устройство в специфическое состояние или конфигурацию или которые посылают информацию:
• SET_LINE_CODING: этот запрос конфигурирует такие параметры устройства, как: четность, скорость передачи (baudrate) и некоторые другие параметры.
• SET_HOOK_STATE: этот запрос переводит устройство в специфическое состояние (подключение, отключение, перехват).
• SEND_ENCAPSULATED_COMMAND: этот запрос посылает пакет в соответствии с специфическим протоколом инкапсуляции и т.п. ... (см. Раздел 6.1 спецификации CDC класса).
• Запросы, которые получают состояние или конфигурацию устройства или другую информацию:
• GET_LINE_CODING: этот запрос возвращает конфигурацию устройства.
• GET_ENCAPSULATED_RESPONSE: этот запрос получает пакет в соответствии с специфическим протоколом инкапсуляции и т.п. ... (см. Раздел 6.1 спецификации CDC класса).

2.2.2.2 Регистрирующий элемент

Через этот опциональный канал (IN передача по прерываниям ) устройство может передавать хосту специальные сообщения о событиях.

Таблица 2-2. Формат сообщения о событии

Несколько примеров:

• NETWORK_CONNECTION: устройство сообщает хосту о состоянии соединения (например, после изменения)
• RESPONSEAVAILABLE: устройство сообщает хосту, что готов ответ. Хост должен послать запрос GET_ENCAPSULATED_RESPONSE через управляющий элемент для получения этого ответа.
• И т.п. (см. Раздел 6.3 спецификации CDC класса).

Для получения более подробной информации о реализации связи, пожалуйста, прочитайте главу 6 спецификации CDC класса.

3. Архитектура программного обеспечения Atmel

Ниже приведен обзор архитектуры программного обеспечения CDC хоста, где представлены все необходимые для работы файлы.

Рисунок 3-1. Архитектура программного обеспечения CDC хоста

Управление CDC осуществляется с помощью файла "host_cdc_task.c". Главная функция, которая периодически вызывается планировщиком — host_cdc_task(void) — которая выполняет три основные операции:

• определение подключения (и отключения)
• «принять» или «отвергнуть» новое устройство согласно дескрипторам интерфейса
• связать физические каналы с программными каналами CDC
• Передача данных
• проверка потока входящих данных
• посылка данных, если это требуется приложением пользователя
• Управляющие передачи
• проверка получения сообщения о событии
• пользователь также может посылать запросы через управляющую конечную точку

3.1 Энумерация

Когда устройство подключается к хосту, начинается процесс энумерации. Если задача нижнего уровеня программного обеспечения хоста, которая сравнивает дескрипторы устройства со списком поддерживаемых интерфейсов, «принимает» интерфейс устройства, то host_cdc_task() «видит» сообщение о подключении (Is_new_device_connection_event() возвращает TRUE).

Текущее количество «принятых» интерфейсов возвращается функцией Get_nb_supported_interface(). Для каждого номера интерфейса программа имеет доступ к кодам класса, подкласса и протокола благодаря макросам Get_class(i), Get_subclass(i) и Get_protocol(i).

Во-первых, программа проверяет есть ли у подключенного устройства CDC интерфейс данных. Если интерфейс устройства принят, функция соединения обнаруживает, какой канал IN, какой OUT для связи их с более общими именами: pipe_cdc_data_bulkin и pipe_cdc_data_bulkout. После этого IN канал может принимать данные в канал.

Затем программа проверяет, есть ли у устройства CDC интерфейс связи (регистрирующий элемент). Если есть, адрес канала также сохраняется под более общим именем pipe_cdc_comm_int. Пользователь разрешает определение управляющего интерфейса с помощью определения CDC_USE_MANAGEMENT_INTERFACE. Номер интерфейса сохраняется в переменной cdc_interface_comm, потому что он будет нужен, если используются управляющие запросы.Когда соединение принято, флаг cdc_connected устанавливается в 1 и каналы могут быть использованы приложением пользователя. Ниже приведен соответствующий код функции:

Код 3-1. Определение подключения CDC устройства

if(Is_new_device_connection_event())  //Device connection
  {
   for(i=0;i<Get_nb_supported_interface();i++)
   {
   // Data Interface
   if((Get_class(i)==CDC_DATA_CLASS)  && (Get_protocol(i)==CDC_DATA_PROTOCOL))
   {
    cdc_connected=1;
    Host_enable_sof_interrupt();
    LOG_STR_CODE(log_cdc_connect);
    if(Is_ep_addr_in(Get_ep_addr(i,0)))
    { // Yes associate it to the CDC Data  IN pipe
     pipe_cdc_data_bulkin =  host_get_hwd_pipe_nb(Get_ep_addr(i,0));
     pipe_cdc_data_bulkout =  host_get_hwd_pipe_nb(Get_ep_addr(i,1));
    }
    else
    { // No, invert...
      pipe_cdc_data_bulkin = host_get_hwd_pipe_nb(Get_ep_addr(i,1));
      pipe_cdc_data_bulkout =  host_get_hwd_pipe_nb(Get_ep_addr(i,0));
    }
    Host_select_pipe(PIPE_CDC_DATA_IN);
    Host_continuous_in_mode();
    Host_unfreeze_pipe();
   break;
   }
   // Management Interface
#ifdef CDC_USE_MANAGEMENT_INTERFACE
   if(Get_class(i)==CDC_COMM_CLASS  && Get_protocol(i)==CDC_COMM_PROTOCOL)
   {
    cdc_interface_comm = i; // store  interface number
    pipe_cdc_comm_int =  host_get_hwd_pipe_nb(Get_ep_addr(i,0));
    Host_select_pipe(PIPE_CDC_COMM);
    Host_continuous_in_mode();
    Host_unfreeze_pipe();
   }
#endif
}
}

3.2 Передача данных

Передачу данных очень легко реализовать.

3.2.1 Получение данных

Если подключено CDC устройство, программа проверяет так часто, как это возможно (каждый раз при входе в в функцию), приняты ли каналом новые данные.

Рассматриваемое программное обеспечение позволяет выполнять две операции с данными каналов:

• Данные сохраняются в массиве:
• Программное обеспечение заполняет массив cdc_stream_in_array[CDC_STREAM_IN_SIZE] получаемыми данными.
• переменная rx_counter указывает на положение следующего записываемого в массив байта (при инициализации присваивается 0, буфер заполнен, когда rx_counter равен CDC_STREAM_IN_SIZE). Следовательно, она «показывает» пользователю количество записанных байт.
• Когда программное обеспечение ползователя считывает данные из массива, оно должно использовать другой указатель для доступа к данным или считывать весь массив за раз и сбрасывать rx_counter. Если пользователь уменьшает rx_counter при считывании каждого байта из массива и выходит из функции до того, как считан весь массив, возникнет проблема (например повреждение данных при следующем приеме данных каналом).
• Данные посылаются в UART (конфигурация моста USB-UART):
• все данные посылаются в UART
• это блокирующая функция, которая ждет отправки каждого байта перед попыткой получить доступ к следующему (это ограничение может быть легко удалено)
• этот режим разрешается определением метки CDC_USE_UART.

Код 3-2. Чтение данных из устройства

Host_select_pipe(PIPE_CDC_DATA_IN);
   if (Is_host_in_received() &&  (Is_host_stall()==FALSE))
   {
    #ifdef CDC_USE_UART
    while (Host_data_length_U8() != 0)
     {
      uart_putchar(Host_read_byte());
     }
     Host_ack_in_received(); // pipe is  empty
     Host_send_in(); // ready to receive  more data
#else
     while ((rx_counter !=  CDC_STREAM_IN_SIZE) && (Host_data_length_U8() != 0))
     {
      cdc_stream_in_array[rx_counter] =  Host_read_byte();
      rx_counter++;
     }
    if (Host_data_length_U8() == 0)
     {
      Host_ack_in_received(); // pipe is  empty
      Host_send_in(); // ready to receive  more data
     }
    #endif
  }

Эти операции реализованы с целью оценки. Пользователь может использовать эту функцию «как есть», но также может реализовать свой собственный обработчик данных (или упаковщик данных, например), имеющий доступ непосредственно к каналу.

3.2.2 Посылка данных

Принцип работы очень похож на прием данных. Данные, которые нужно отправить, сначала сохраняются в массиве cdc_stream_out_array[CDC_STREAM_OUT_SIZE]. Глобальная переменная tx_counter содержит текущее количество сохраненных байт, и таким образом, указывает на положение следующего сохраняемого байта.

Существует два возможных источника данных для массива:

• Программа пользователя: специфическое программное обеспечение пользователя может записывать данные в массив, увеличивая tx_counter при записи каждого байта (при инициализации присваивается 0, когда нет сохраненных данных)
• UART: если метка CDC_USE_UART определена, массив будет заполняться каждым новым принятым через UART байтом.

Более того, существует два возможных условия передачи данных массива в OUT канал:

• Заполнение буфера: как только буфер заполнен (tx_counter = CDC_STREAM_OUT_SIZE), все данные массива передаются в канал.
• Тайм-аут: переменная счетчик времени cdc_cpt_sof увеличивается при каждом прерывании по началу кадра USB (каждую 1 мс) в функции sof_action(). Когда этот счетчик достигает или превосходит заданное пользователем значение CDC_NB_MS_BEFORE_FLUSH, и, если массив не пуст, все данные из буфера передаются в канал.

Передача по каналам USB обеспечивается функцией cdc_pipe_out_usb_flush().

Код 3-3. Посылка данных устройству

  #ifdef CDC_USE_UART
    // Check if new byte in USART, to be  stored for USB
     if (uart_test_hit() &&  (tx_counter != CDC_STREAM_OUT_SIZE))
     {
      cdc_stream_out_array[tx_counter] =  uart_getchar();
      tx_counter++;
     }
  #endif
    // Check if pipe flush is needed  (buffer full or time-out period elapsed)
    if(((cdc_cpt_sof>=CDC_NB_MS_BEFORE_FLUSH)  && (tx_counter!=0)) || (tx_counter == CDC_STREAM_OUT_SIZE))
     {
      cdc_cpt_sof=0;
      cdc_pipe_out_usb_flush();
     }

Код 3-4. Дополнительные функции

void  cdc_pipe_out_usb_flush (void)
  {
    Host_select_pipe(PIPE_CDC_DATA_IN);  // BULK IN must be frozen else BULK OUT may not be sent
    Host_freeze_pipe();
    if (PIPE_GOOD ==  host_send_data(PIPE_CDC_DATA_OUT, tx_counter, cdc_stream_out_array))
     {
      tx_counter = 0; // if frame not sent,  will try again next time (no data loss)
     }
     Host_select_pipe(PIPE_CDC_DATA_IN);
     Host_unfreeze_pipe();
   }

void sof_action(void)
  {
    cdc_cpt_sof++;
  }

3.3 Управление связью

3.3.1 Управляющий элемент

Через нулевую конечную точку пересылаются специфические запросы CDC? Определенные в спецификации CDC класса. Эти запросы могут быть определены в следующей форме:

Код 3-5. Схема управляющего запроса

#define host_cdc_get_line_coding()  (usb_request.bmRequestType = BM_REQUEST_TYPE,\
                                     usb_request.bRequest = B_REQUEST,\
                                     usb_request.wValue = W_VALUE,\
                                     usb_request.wIndex = W_INDEX,\
                                     usb_request.wLength = W_LENGTH,\
                                     usb_request.uncomplete_read = FALSE,\
                                     host_send_control(data_stage))

Где параметры, написанные полужирным курсивом, должны быть заменены параметрами, соответствующими специфическому запросу.

Поле W_INDEX обычно равно "cdc_interface_comm", что соответствует интерфейсу управления (если он разрешен) устройства.

Поле W_LENGTH содержит число байт, передающихся в запросе. Данные (для передачи или полученные) храняться в соответствующем массиве.

Пользователь может легко добавить другой запрос путем изменения файла "host_cdc_task.h". Как бы то ни было некоторые из них уже интегрированы в програамное обеспечение CDC хоста от Atmel.

3.3.1.1 Инкапсулированные запросы

Эти запросы используются для передачи специфических запросов, которые инкапсулированы в соответствии со специфическим протоколом.

Таблица 3-1. Запрос SEND_ENCAPSULATED_COMMAND

Таблица 3-2. Запрос GET_ENCAPSULATED_RESPONSE

3.3.1.2 Запросы параметров связи

Эти запросы могут использоваться для посылки (получения) конфигурации CDC устройства, для связи по UART.

Таблица 3-3. Запрос SET_LINE_CODING

Таблица 3-4. Запрос GET_LINE_CODING

Таблица 3-5. Структура кодирования строки

3.3.2 Регистрирующий элемент

Регистрирующий элемент, который состоит из дополнительной IN конечной точки, получает сообщения о событиях от устройства.

Рассматриваемое программное обеспечение Atmel для CDC хоста не включает в себя упаковщика пакетов для этого канала. Но отведено место для пользовательского обработчика сообщений.

Пожалуйста, для получения более подробной информации о возможностях, предоставляемых этим интерфейсом, прочитайте спецификацию CDC класса.

Код 3-5. Шаблон обработчика сообщений канала

Host_select_pipe(PIPE_CDC_COMM);
  if (Is_host_in_received())
  {
    // Handle here notification messages  sent by device
    // Notifications messages have the  following structure :
    // bmRequestType - bNotification - wValue  - wIndex - wLength - Data (wLength is the number of bytes of the Data field)
	
    // - NETWORK_CONNECTION : indicates  that device has connected to network
    // - RESPONSE_AVAILABLE : indicates  that device has a ready encapsulated response (wait for host request)
    // - SERIAL_STATE : indicates state  of device' UART (errors, carriers and misc. signals)
    // - etc...
	
    // ...and now...just coding...
  Host_ack_in_received();
  Host_send_in();
  }

4. Пример

4.1 Обзор

Вся эта теория может показаться сложной, поэтому здесь с целью ознакомления приведен простой пример — двойной мост UART-USB, — который позволяет осуществить быструю оценку и является введением в разработку устройства CDC класса. В этой конфигурации, CDC хост приложение соединено через UART с последовательным портом ПК-1. У CDC устройства также есть UART, который подключен или к другому последовательному порту этого же ПК-1 или к последовательному порту другого ПК-2. Оба CDC приложения соединены вмести через USB. Это приложение, бесполезное в промышленном или потребительском использовании, просто показывает механизм обмена данными в устройствах CDC.

Рисунок 4-1. Оценочный пример двойного моста USB-UART

Замечание: Могут использоваться дополнительные CDC платы для реализации портов RS232 на ПК, если на них доступны только USB порты.

CDC устройство может быть реализовано на любом AVR USB с использованием программного обеспечения, доступного на сайте Atmel. CDC хост использует соответствующее программное обеспечение, которое также доступно в интернет.

4.2 Аппаратное обеспечение

Оба программных обеспечения могут быть запущены на доступных стартовых наборах. На время написания программное обеспечение для CDC хоста может быть запущено на STK525 или USBKEY (для AT90USB647/1287 ), а програамное обеспечение для CDC устройства может быть запущено на STK525, USBKEY (AT90USB64x/128x) или STK526 (AT90USB82/162).

Плата с USB устройством должна быть сконфигурирована в режиме питания от шины для простейшей работы. Плата с USB хостом должна иметь собственный источник питания (внешний источник питания) и сконфигурирована так, чтобы обеспечивать питание платы с USB устройством.

4.3 Программное обеспечение

4.3.1 Микроконтроллер

4.3.1.1 Описание работы

Этот пример не осуществляет обмен данными через управляющий интерфейс. Как бы то ни было, этот интерфейс может быть реализован для обеспечения совместимости с другими CDC приложениями. После энумерации каждый байт, полученный от ПК-1 будет отправлен из UART в OUT канал CDC хоста, получен в OUT конечную точку CDC устройства и в конце концов передан в ПК-2 через UART. Байты, посылаемые из ПК-2, идут в обратном направлении и «прибывают» в последовательный буфер ПК-1.

4.3.1.2 Конфигурирование

Некоторые параметры должны быть определены на каждом микроконтроллере для обеспечения правильной работы. Программное обеспечение требует модификации, и оно работает «как есть» и сконфигурировано значениями, приведенными ниже.

• Скорость UART: в файле "config.h" метка BAUDRATE определяется желаемым значением скорости. В программном обеспечении значение по умолчанию 38,4 kbps (BAUDRATE = 38400).
• Конфигурация USB: в файле "confusb.h":
• массив CLASS_SUBCLASS_PROTOCOL должен содержать значения CDC интерфейса данных и CDC интерфейса связи
• Host_sof_action() должна быть связана с функцией sof_action() (прототип которой также должен быть объявлен)
• Конфигурация CDC хоста: в файле "config.h" или в любом хедере доступном файлу "host_cdc_task.c" должны быть определены следующие значения и метки:
• CDC_USE_MANAGEMENT_INTERFACE должно быть определено (даже если нет обмена данными через этот интерфейс)
• CDC_USE_UART должно быть определено (для использования возможности моста USB-UART)
• CDC_NB_MS_BEFORE_FLUSH не очень важно для контролируемых человеком приложений, поэтому по умолчанию может быть установлено в 0x05 (влияние этого значения может зависеть от приложения)
• CDC_STREAM_OUT_SIZE и CDC_STREAM_IN_SIZE зависит от ожидаемой скорости передачи данных: чем выше ожидается скорость (в реальности количество символов, которые могут быть посланы в секунду), тем больше должны быть эти значения. Но не превышайте размер конечной точки или канала! (это приведет к потере данных). Значение по умолчанию 16 (0x10).

4.3.2 Последовательный порт ПК

Для простого использования последовательного порта ПК вы можете использовать терминал. Под Windows вы можете запустить Hyper Terminal (Accessories => Communications). Сначала вы должны выбрать COM порт, к которому подключено приложение (хост или устройство). Затем должна быть правильно проведена конфигурация порта. Используя программное обеспечение без изменений, вы должны установить следующую конфигурацию:

Рисунок 4-2. Конфигурация Hyper Terminal

Затем появляется диалоговое окно терминала, в которое вы можете вводить символы для посылки в открытый порт или видеть принятые символы.

Каждый символ, который вы введете на экране ПК-1 появится на ПК-2 и наоборот.

5. Вывод

В заключение следует отметить, что CDC класс — это широкая спецификация, которая охватывает много различных конфигураций, и соответствует нескольким стандартам связи для поддержки таких устройств, как: модем, мобильные телефоны, интерфейсы LAN...

Хотя работа по реализации таких устройств может быть очень значительной, базовая реализация обмена данными вполне доступна. Эти «рекомендации» были созданы, чтобы помочь людям, которые хотят использовать хост совместимость продуктов Atmel AVR USB для реализации мощной системы связи, легкой в использовании и надежной, с использованием современнфх технологий. Приложения, такие как мост USB-UART (или похожие) могут быть легко созданы.

6. Связанные документы

AVR USB products Datasheet

USB Sotware Framework

Спецификация класса CDC

Документация

262 Kb Engl Исходный файл