esaulenka

Ну... Надо учитывать, что Шенжень находится достаточно далеко от Оксфорда :-) Соответственно, язык там знают неидеально... Правильное описание алгоритма этого датчика, кстати, есть в разделе product features. А как трактовать "not suggested to connect directly to electric"... Видимо, "не втыкать при наличии питания" (и это правильно!)

За неимением осциллографа можно пользоваться лог.анализатором. Самый дешёвый вариант - китайский. Тем не менее, работает хорошо, периодически заменяя осциллограф ценой в несколько тыс. $. Аналоговые подробности сигнала там не видно, конечно. Но просто посмотреть, как ножки контроллера дёргаются - очень полезно. А собственно осциллограф... 200..300$ - это самое-самое начало... Не понял, что это. Полная документация есть? Могу предположить, что "длительность высокого уровня на выходе echo". Почему в описании предлагают измерять длительность от входного сигнала... Видимо, ошибка.

Как нарисовано, так и работает. По входу "триггер" датчик формирует пачку импульсов. По окончанию отправки пачки датчик выставляет "эхо" в единичку (у него это занимает ПРИМЕРНО 468 мкс). По окончанию приёма пачки датчик выставляет "эхо" в ноль (длительность импульса - именно то, что нам надо). Слово "примерно" я подчеркнул не зря - скорее всего, за цифру 468 производитель не ручается. Соответственно, ПРАВИЛЬНЫЙ алгоритм - померять время обоих фронтов (благо, Вы это делать умеете - нужно задействовать ещё один канал таймера) и вычитать одно из другого.

Осциллографа под рукой нету? Моргания светодиода в 0.5 миллисекунды глазом увидеть никак не получится, значит, это явно не то значение. Может быть, через 468 микросекунд этот сигнал echo переходит в единицу, а потом, собственно, по получению эха, обратно в ноль?.. Быстрый способ проверки - поменять полярность срабатывания capture. Правильный способ - почитать документацию (и нам показать).

Ещё б документировать его не только на форуме... И вообще, мне кажется, стоит добавить табличку с комментариями в target_cfg.h: CORE_PRIORITY_BITS = 4 для STM32F1xx, F2xx, (F3xx ?), F4xx, LPC17xx, LPC18xx CORE_PRIORITY_BITS = 3 для LPC13xx, LM3S CORE_PRIORITY_BITS = 2 для STM32L0xx, LPC11xx Значения для этой таблички может выдать grep __NVIC_PRIO_BITS по базе с заголовками на процессоры. У меня таковой нет, к сожалению... И да, принудительно привести тип будет аккуратнее: enum { SYS_TIMER_PRIORITY = (uint8_t)(0xFEUL << (8-(CORE_PRIORITY_BITS))) };

Подходят, наверное. Но TI-ную отладку можно незадорого купить и почти сразу использовать, а с первого раза сделать наноамперный измеритель... Я лично не готов.

У Texas'а занятная получилась отладочная плата, спасибо за наводку. Чтобы проще искалось: статья-описание из Радиолоцмана (по-русски фиг найдёшь, только со всякими супер-файлохранилищами, которые деньги вымогают); руководство на саму плату (схема в конце, интересен лист 5). Собственно, вопрос к тем, кто работал с TI'шными демо-бордами. Там можно без использовать ТОЛЬКО этот измеритель? Аппаратно, насколько я понимаю, легко (даже перемычки специальные есть), а вот программно... Задачи "померять что-нибудь этакое малопотребляющее" в хозяйстве всплывают периодически, сейчас решаются... с невысокой точностью.

И что, даже картинку "Download" из правой колонки странички IAR ARM убрали? Вот редиски...

цитаты из исходников кейла: * - 'Maximum Communication Device Send Buffer Size' specifies the maximum * value for \em len in \ref USBD_CDC_ACM_WriteData // <o>Maximum Communication Device Send Buffer Size // <i>Specifies size of buffer used for sending of data to USB Host. // <8=> 8 Bytes <16=> 16 Bytes <32=> 32 Bytes <64=> 64 Bytes // <128=>128 Bytes <256=>256 Bytes <512=>512 Bytes <1024=>1024 Bytes #define USBD_CDC%Instance%_SEND_BUF_SIZE 1024 Буфер, в который пишет USBD_CDC_ACM_WriteData() (ну и ваши тысячи USBD_CDC_ACM_PutChar()) организован в основной памяти контроллера, и оттуда библиотека перекладывает в контроллер USB кусочками по 64 байта.

Если USBD_CDC_ACM_PutChar () не смог сделать этот самый putchar, он вернёт -1. Соответственно, ничего страшного не случится, если попросить его сделать это ещё раз. И ещё. А настроек там немного совсем. Во всяком случае, таких, которые может крутить пользователь. Размер пакета там уже установлен в 64 байта, что ещё можно поменять, не знаю. Как оно устроено внутри, кейл не говорит.

А компилятор есть? :-) Какой? гулить pragma pack attribute aligned, packed

Чёрт, ну вот как, как до этого можно догадаться?! Есть обратная связь, получилось положить в буфер CDC или не получилось. Почему бы ей не пользоваться? Как ускорять кейловскую библиотеку, я не знаю. Подозреваю, что только выкидыванием и переписыванием.

Вроде б очевидно, что если функция не может отправить данные, надо чуть-чуть подождать, и это не ошибка, а вполне стандартная ситуация. PS всегда считал, что документацию кейл содержит в порядке. Ан нет - в код повсюду добавили параметр instance, а в описании на сайте его нет.

Подумал-подумал, и окончательно запутался. Два bulk-пакета подряд ведь повсеместно встречаются? Соответственно, если бы была проблема "теряется начало любого второго пакета", народ бы много где ругался. А в control можно ведь засунуть длинный пакет, чтоб оно "само" резало-склеивало?.. Вроде б не запрещают. Сейчас посмотрю, что происходит на границе второй-третий пакет...

Рекомендацию библиотеки ST спасибо. Знать, что оно таки работоспособно, это хорошо :-) Допилил этот CustomHID из крайней версии CubeMX (он там сломаный, просто куда-то потеряли кусок кода). Да, действительно, работает. Да, действительно, данные не теряет. При сравнении CubeMX и libopencm3 была обнаружена интересная особенность. Как известно, эндпоинт после завершения обмена становится неактивным, и его надо постоянно включать. Авторы libopencm3 делают это при первой же возможности (для OUT-транзакции - сразу после вычитывания из FIFO), а в "родной" библиотеке - после многочисленных действий (обработать пакет, подумать, какой будет следующим, какого он размера...). В итоге, в в libopencm3 в один фрейм попадает и SETUP с указанием "а сейчас будет SET REPORT" и собственно данные этого report'а. Точнее, не все данные, а сдвинутые на 4 байта (и дополненные мусором в конце). Подробности - с фоточками осциллографа (пардон за качество. флешки, которую он поймёт, под рукой нету..) и состоянием регистра прерываний, здесь (кликнуть по картинке, там две страницы). Если по приему setup пакета ничего не делать и не разрешать обратно эндпоинт в течении 1 мс, всё начинает работать корректно. Но меееедленно. Собственно, вопрос: 1) я правильно понимаю, что спецификация USB 2.0 Full Speed не запрещает посылать setup и out в один эндпоинт за один фрейм? 2) у кого-нибудь на этом FS OTG использовал возможность использовать несколько транзакций в одном фрейме? Возможно, это какие-то "электрические" проблемы. Если рядом есть грузовик, надо рассчитывать, что в любой момент с неожиданной стороны придёт помеха. Не понимаю, почему так сделали, но там уже почти всё готово для оборачивания этого poll() в прерывание. Собственно, эта часть заработала почти сразу. Дальше - аналогично, штатными callback'оми (правда, тут они динамические - через указатели).

Спасибо за подсказку. Действительно, господа из ST в кубовском примере CustomHID потеряли report descriptor. Подсунул следующее: _ #define USBD_CUSTOM_HID_REPORT_DESC_SIZE 34 _ALIGN_BEGIN static const uint8_t Custom_HID_ReportDesc[USBD_CUSTOM_HID_REPORT_DESC_SIZE] __ALIGN_END = { 0x06, 0x00, 0xff, // USAGE_PAGE (Vendor Defined Page 1) 0x09, 0x01, // USAGE (Vendor Usage 1) 0xa1, 0x01, // COLLECTION (Application) 0x09, 0x01, // USAGE (Vendor Usage 1) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) 0x95, 0x40, // REPORT_COUNT (64) 0x75, 0x08, // REPORT_SIZE (8) 0x81, 0x02, // INPUT (Data,Var,Abs) 0x09, 0x01, // USAGE (Vendor Usage 1) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) 0x95, 0x40, // REPORT_COUNT (64) 0x75, 0x08, // REPORT_SIZE (8) 0x91, 0x02, // OUTPUT (Data,Var,Abs) 0xc0 // END_COLLECTION } Также в USBD_HID_Setup() надо подправить запрос этого дескриптора: case USB_REQ_GET_DESCRIPTOR: if( req->wValue >> 8 == HID_REPORT_DESC) { len = MIN(sizeof(Custom_HID_ReportDesc) , req->wLength); pbuf = Custom_HID_ReportDesc; } else if( req->wValue >> 8 == HID_DESCRIPTOR_TYPE) { pbuf = USBD_HID_Desc; len = MIN(sizeof(USBD_HID_Desc), req->wLength); } У меня, правда, и после всего этого он по-прежнему определялся мышкой - что-то где-то виндовс закэшировал. Не стал заморачиваться, просто увеличил PID (define USBD_PID_FS) на единичку. Update. Ещё надо увеличить #define USBD_CUSTOMHID_OUTREPORT_BUF_SIZE 64 и в USBD_HID_Setup() (или, скорее, USBD_CUSTOM_HID_Setup() ) дописать обработчик GET_REPORT. Простейший (эхо): case HID_REQ_SET_REPORT: hhid->IsReportAvailable = 1; USBD_CtlPrepareRx (pdev, hhid->Report_buf, req->wLength); break; case HID_REQ_GET_REPORT: USBD_CtlSendData (pdev, hhid->Report_buf, req->wLength); break;

Не надо "писать на кокосе". Надо по-человечески, отделяя мух от котлет. Предлагаю организовать интерфейс с шиной SPI: - активация слейва - деактивация слейва - обмен одним байтом (чтение/запись) Для удобства можно организовать дополнительно: - запись байта (вызов функции обмена, считанный байт "забыть") - чтение байта (вызов функции обмена, записать ноль). Собственно, этот программный интерфейс "сам" рождается после изучения любой статьи, найденной в гугле по запросу "шина spi описание". А только потом из этого сооружать обмен с конкретной микросхемой.

Начал освоение GNU ARM Eclipse. Есть несколько вопросов, которые (из-за их очевидности, что-ли?) нигде не разжёваны. Хочу сделать несколько проектов, которые будут пользоваться одними и теми же исходниками. Типичное применение - загрузчик, который наполовину состоит из того же исходного кода, что и основное приложение. При этом вторая половина его - абсолютно другие файлы. В "обычных" средах в проект файлы заносятся руками, можно добавить только нужные. Тут оно "само" компилирует всё, что видит. Как это лучше организовать? Понятно, что можно вручную рисовать make-файлы, но пока я к этому не готов :-) Как сделать кнопку "download to flash and run" ? Отладчик работает, однако зачастую он мне не нужен - нужно просто запустить приложение. Как, кстати, сделать хоткей на отладку? По этой инструкции получается только через выпадающее меню в кнопке Debug.

Определяется стабильно. Прерывание тоже нормально работает вот с таким нехитрым кодом: extern "C" void OTG_FS_IRQHandler (void) { usbd_poll(usbd_dev); } Почему не взлетело сразу, я так и не понял... Сейчас борюсь с граблей - некорректно работает прием по control endpoint.

Ещё разик подниму тему. На эти грабли: https://my.st.com/public/STe2ecommunities/m...rrentviews=1592 никто не наступал? Прикрутил библиотеку libopencm3, сделал из неё HID. Обмен - по нулевому endpoint'у блоками в 32 байта. setup-пакеты ходят нормально, а от data out пропадают первые 4 байта. Странный костыль в библиотеке - добавить тысячу NOP'ов перед считыванием - не помогает. Да и выглядит он некрасиво...

Много лет назад наступил на грабли с AT45DBxxxD. Проблема в том, что для этих микросхем критично время фронтов на линии CLK. В принципе, эта цифирка указана в даташите, но среди всех остальных параметров её легко пропустить. Выглядит это как совершенно неадекватное поведение в зависимости от фазы луны, у меня даже регистр статуса не всегда корректно читался. Вылечилось отпаиванием отладочных проводов (там полметра было. так надо :-) ) от линии SPI.

Тут есть пользователи этой библиотеки? Первое впечатление - написано заметно приятнее, чем Cube/SPL. Можно читать и не плеваться каждые 15 секунд. Склонность, правда, авторов к созданию своих велосипедов (почему бы не использовать родные определения регистров?..) несколько удивляет. Ну да ладно... Собственно, у меня задача - сделать USB-Device. Что-то как-то работает, однако мне сильно не нравится реализация USB без прерываний, опросом. Попытка запихать usbd_poll() в прерывание с разрешением такового пока к результатам не привела...

Если я ничего не путаю, писать надо следующим образом: CS = 0 Write (WriteEnable_CMD) CS = 1 задержка, min. длительность - в даташите CS = 0 Write (Write_CMD, address) Write (data, data, data, ...) CS = 1 Читать, соответственно, без всяких "SPI_MasterTransmit(0b00000110); //wren".

Настройки окон лежат в файле ProjectName.uvopt, можно смело его грохать. И вообще можно грохать все ProjectName.*, кроме *.uvproj

Я извиняюсь за некропост, но там действительно полевик IRLI630 ? Гугл считает, что он n-type. Это небрежно составленная схема? Или я вообще не понимаю, как же оно работает? :-) PS. Для поднятия полезности поста. Разговор о "защите в автоэлектронике" следует начинать с ISO 7637 или ГОСТ 28751. Очень любопытные документы, рекомендую.