Jump to content

    

Concorde

Свой
  • Content Count

    56
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Concorde

  • Rank
    Участник

Recent Profile Visitors

1392 profile views
  1. Цитата(Сергей Борщ @ Oct 20 2016, 09:16) Испугался за lwIP. Полез в репозиторий. Это неопределнное поведение было устранено еще в мае 2012 года. Может стоит взять исходники посвежее, там и кучу других ошибок устранили за это время? Само собой. Но речь сейчас идет о том, как такие проблемы поймать на этапе компиляции (в виде предупреждений). Выходит, никак (или я не знаю).
  2. В случае с lwip (dhcp код, gcc_bug.tar): Предупреждение не выдается с любыми флагами: "-Wstrict-aliasing", "-Wstring-aliasing=1", "-Wstring-aliasing=2", "-Wstring-aliasing=3". Везде, кроме этого, есть ключ "-Wall". Кстати, флаг "-fno-strict-aliasing" так же не помогает: начиная с "-O2" генерируется тот же "кривой" код.
  3. Оказался сам дурак (давненько не было проблем с оптимизацией). Смотрите ответы. Придется весь сторонний код как-то тестить и проверять и самому быть гораздо аккуратнее (оптимизация очень жесткой оказалась).
  4. Цитата(aaarrr @ Oct 18 2016, 00:58) Уже Таки да, воспроизводятся оба. Мне на этой неделе продукцию отгружать. С виду все работает (опустился до -O1), но коленки дрожат. Если ли смысл в срочном порядке переходить на 4.9 ?
  5. Цитата(aaarrr @ Oct 18 2016, 00:36) Собирал ряд проектов для Cortex-M3/M4 и ARM926EJ. Всюду оптимизация -O2, багов нет. Не могли бы Вы протестить 'gcc_bug2.tar' (с баг-репорта) у себя ? Собственно, это я баг-репорты запостил.
  6. Хотел бы поинтересоваться у людей - использует ли кто-нибудь GCC 5 при полной оптимизации в проектах ? В gcc 5 (последний от launchpad) полно багов. Вот ссылка на баг-репорт. Есть ли смысл пробывать 4ю версию (или, может, другую 5ю ?). Переехал недавно с IAR - просто в шоке.
  7. Ну, это все-таки не аккумуляторы (заряжаемые), а первичные источники (просто батарейки). Литий-тионилхлоридовые всегда такими были. Делают и китайцы (дешево). С аккумуляторами все гораздо хуже (на минуса (заряд) - только Ni-Cd).
  8. Нет такой возможности (по крайней мере, в стандартном C preprocessor). Может, поможет это
  9. RNDIS и CY7C68013A c FPGA

    Цитата(SFx @ Apr 29 2009, 18:34) Спасибо за подробный ответ! Теперь с интерфейсом стало относительно понятно. хотелось бы узнать по поводу дискрипторов: 1. обязательно ли иметь такую же адрессацию у Endpoint'ов, как описано в мануале на драйвер или эти значения могут быть другими ? к пример bEndpointAddress равно не 0x03 для Data Out Endpoint , а 0x06. 2. в USB Communication Class Interface Descriptor=>7 bInterfaceProtocol (Vendor-specific protocol) значение стоит 0xFF, а мой компилятор прошивки ругается на это значение? насколько оно критично? 1. Нет, адреса могут быть любыми. 2. Не знаю. У меня стояло USB_CDC_ACM_PROTO_VENDOR (0xFF). Будет ли работать при другом значении - не знаю.
  10. FYI: CC430

    Есть на wiki описание первых устройств. Кроме того, в бета-версии CCS v4 есть заголовочные файлы для CC430 устройств. Из интересного: Появился 'Port mapper', который (похоже) позволяет любой пин портов (P1, P2, P3) назначить на любой внутренний сигнал (выход с таймера, компаратора, ...). Доступ к радио сделан через отдельный модуль 'CPU-RF interface', команды CC1101 остались те же. Тем не менее (похоже), есть прямой доступ к RF FIFO, а также триггеры для DMA (RFRX, RFTX). RF кварц отдельный (26 MHz), без привязки к основной системе тактирования.
  11. RNDIS и CY7C68013A c FPGA

    Цитата(SFx @ Apr 28 2009, 10:24) Спасибо за ваш комментарий! Странно, я думал еще control нужно.... bulk я так понимаю это на передачу в FPGA, а interrupt - на прием из устройства? а формат данных принимаемых/передаваемых нигде не описан (кроме как в этом [attachment=32211:rndisspc.doc] файле из MS RNDIS USB kit 2005) ? дело в том, что хотелось бы устройство кросплатформенным сделать... "control", конечно, нужен. 'bulk' используется для передачи данных, 'interrupt' - для сообщения винде, что команда была выполнена. По сути, просто необходимо принимать команды (включить/выключить/запрос статистики/...) и положить четыре байта (или восемь - не помню) в 'interrupt' endpoint. Только после этого винда запросит результат команды. Пакеты(Ethernet frame) передаются с заголовком REMOTE_NDIS_PACKET_MSG, где надо все установить в нули, кроме след.: MessageType = REMOTE_NDIS_PACKET_MSG MessageLength = 44 + size DataOffset = 36 DataLength = size ------ Реализовать надо след. команды: REMOTE_NDIS_INITIALIZE_MSG REMOTE_NDIS_HALT_MSG REMOTE_NDIS_QUERY_MSG REMOTE_NDIS_SET_MSG REMOTE_NDIS_RESET_MSG REMOTE_NDIS_KEEPALIVE_MSG ------ Для REMOTE_NDIS_SET_MSG надо поддерживать 'OID_GEN_CURRENT_PACKET_FILTER', 'OID_802_3_MULTICAST_LIST' Можно просто вернуть статус 'OK', и ничего не делать. Читаем здесь и здесь Да, добавлю. Команды (REMOTE_NDIS_INITIALIZE_MSG, ...) идут через 'control' endpoint, где (для Setup): 'bRequest' = ('type' = 'CLASS', 'recipient' = 'INTERFACE') 'bmRequestType' = USB_CDC_SEND_ENCAPSULATED_COMMAND, USB_CDC_GET_ENCAPSULATED_RESPONSE. Т.е.: 1. устройство получает команду (допустим 'REMOTE_NDIS_QUERY_MSG') через ('USB_CDC_SEND_ENCAPSULATED_COMMAND', control EP). 2. устройство выполняет ее и кладет 8 байт в interrupt EP {RESPONSE_AVAILABLE, 0}. 3. устройство отдает результат (в виде 'REMOTE_NDIS_QUERY_CMPLT') через ('USB_CDC_GET_ENCAPSULATED_RESPONSE', control EP). Все. Сами данные передаются как есть, без всяких управляющих команд (c заголовком REMOTE_NDIS_PACKET_MSG).
  12. RNDIS и CY7C68013A c FPGA

    Цитата(SFx @ Apr 22 2009, 12:02) Назрел вопрос следующего рода: Имеется FPGA c подключенной к ней CY7C68013A, на эту FPGA приходят MII пакеты (Ethernet). С CY7C68013A реализован двухсторонний обмен данными. Могу записать в USB пакетик и считать могу данные из него. работает в CyConsole. режим bulk и slave fifo и два Endpoint'а под это выделены. Хотелось бы реализовать по сути сетевой интерфейс USB (с IP адресом, шлюзом, ну вообще, как обычная сетевая USB карточка) и пакеты Ethernet принимать и отправлять из FPGA в комп. Прочитал, что есть такая штука - RNDIS. И она как раз позволяет реализовывать Сетевые интерфейсы на USB. Кто может что сказать по реализации драйвера сетевого устройства RNDIS ? Может есть у кого какие Examples ? Поделитесь, плиз. Спасибо. RNDIS - Фактически туннель через USB для Ethernet фрэймов. Смотреть лучше в исходниках Linux (usb gadget). Кода там на тысячу/другую строк. "IP, шлюз, ..." - не важно. RNDIS этим не занимается. Понадобится один "bulk" и один "interrupt" endpoint.
  13. Цитата(AlexandrY @ Feb 26 2009, 00:29) А вы уверены что делали RNDIS и что вы сами его делали? Endpoint 0 вообще-то нужен всегда и для любых USB дивайсов к RNDIS-у это имеет малое отношение. А вот конечная точка типа interrupt там не нужна. Не те скорости. Обмен interrupt в USB слишком медленный. И рабочий канал и контрольный настроены как bulk. Ну и отладочный интерфейс не забыть через тот же USB. Вообщем точек 5-6 обрабатывать нужно. Мне не понятны ваши сомнения. Писал я, года 3 назад. Для чего 5-6 точек ? Отлаживать там нечего (при условии, что остальной код нормально работает). Естественно, что EP0(bulk) нужен всегда и везде. Поддержка RNDIS как такого занимает строк 200 крайне простого кода, т.к. делать там особо нечего. Самое сложное - обеспечить статистику (подсчет байтов/пакетов) - т.к. Винда (по крайней мере, XP) показывает статистику интерфейса, запрашивая его через RNDIS (а не считает сама).
  14. Цитата(Дмитрий Мазунин @ Feb 25 2009, 12:11) Уважаемый Concorde, прошу Вас ответить на вопрос - для реализации RNDIS/CDC в приборе требуется обработка контрольного эндпойнта (EP0), а также конкретные режимы других эндпойнтов ? Другими словами, необходим ли полноценный контроллер USB или можно обойтись конвертером RS232-USB (на стороне прибора UART) ? Нет, конвертор не подойдет. Да, обязательно надо обрабатывать EP0 - сообщения (кроме нагрузки) RNDIS идут через EP0. Кроме того, нужен один 'BULK' endpoint (данные), и один 'INTERRUPT' endpoint (для нотификации, что пришли данные).