KnightIgor

Доброго дня. Никто не имеет спецификации проводного пульта дистанционного управления видеокамер от Panasonic, а в частности - HC-X1500/2000? Чаще можно найти в этом контексте упоминание LANC - протокола для Sony и Canon камер, но вот найти Panasonic пока не смог. Как пример пульта приведу ссылку. Это пульт для камеры для управления zoom c кнопкой записи. Я "зареверсил" эту железяку и понял следующее. - питание 5V от камеры. - сигнальная двунаправленная цифровая линия с открытым коллектором: камера периодически (от 10 до 20мс) передает на 9600@8N2 8 байтов 0xFF как фреймы синхронизации. В ответ на это, если надо, пульт подставляет (синхронизирует) свои посылки. Раскопал, что первый байт - это код команды, а второй байт - данные. В пятом байте сама камера передает состояние записи: если идет запись, вместо 0xFF передается 0xFB. При zoom пультом первый байт становится 0xD7, а второй байт содержит "скорость" и направление zoom как число от 0xFF до 0xF1 для "zoom in" и 0xEF до 0xE1 для "zoom out", причем числа только нечетные. При нажатии кнопки "rec" команда будет 0xE7, а данные - 0xCC. Мой вопрос: какие еще есть команды и состояние камеры? Может, кроме zoom, можно управлять фокусом и другими оперативными настройками?

Прикол в том, что вставив команду чтения SR я, фактически, обеспечил считываяние его дважды: процедура bufio_IRQHandler(&FIFO); в результате вызывает что-то такое (см ниже), где и происходит " смысловое" считывание SR и анализ его битов. То есть, каким-то образом двойное считывание обеспечивает правильную работу, словно происходит синхронизация одного тактового домена с другим. // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // // Reading DR // static uint16_t Read_RX(void) { uint16_t st = READ_BIT(STDIO_DEVICE->SR, USART_RX_FLAGS), dr = USART_GET_DR(STDIO_DEVICE); if (st) // any RX related flag { if (READ_BIT(st, USART_FLAG_FE) && dr == 0) // BREAK - prepare for DMX { bufio_PurgeRX(stdioFIFO()); } } return dr; } А уверены, что на плате стоит натуральный F103, а не китайский G... как его там? Вообще-то с RC я до сих пор проблем не имел, UARTы работают достаточно стабильно.

Здесь специалисты уже посоветовали. Я вставлю свои пять копеек. Отлаживая UART коммуникацию, я начал сталкиваться со спорадическими потерями байтов как на STM32F10x, так и (и особенно) на STM32F0xx. В процессе отладки, когда я хотел глянуть по шагам, что там с битами в SR происходит, я вставил команду чтения SR сразу на входе в прерывание: void STDIO_IRQHandler(void) { STDIO_DEVICE->SR; // unbelievable but reading SR before bufio_IRQHandler(&FIFO); // helps to avoid byte loss. 28.04.14. } И о, чудо! - ошибки ушли навсегда! Я не стал глубоко копать, почему так происходит, и объяснить не смогу. Работает, и работает (и весьма надежно). Чистая эмпирика и удача, я и оставил, как есть. F10x вообще, как первая Cortex серия от STM, имеет весьма глючную периферию. Например, запустить разумно I2C на нем весьма нетривиально, о чем писано-переписано на форуме, в том числе и мной. Попробуйте трюк 17. Хотя проблема в TX? Может быть, немного не совпадают скорости? RC генератор (HSI) не точный, или где-то +/-1 в делителе...

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

Тогда только нейтральный сигнал остается. Вообще мне не ясен момент быстродействия. Если программа в принципе успевает готовить буферы, то программный доступ к элементам массива значительно быстрее выборки элементов DMA: надо же не просто скопировать данные, надо их высчитать. То есть цикл, который готовит очередной буфер, значительно быстрее времени передачи этого буфера с помощью DMA. Поделив времена на размер буфера получим, что за время между шагами со стороны DMA (период дискретизации как обратная величина частоты дискретизации) процессор должен быть в состоянии исполнить довольно большое количество команд. В этом случае, как только DMA выбрал последний элемент и выработал прерывание TCIF, до выборки им очередного элемента остается время (период дискретизации), за которое процессор уж явно успеет ворваться в прерывание и передернуть пару флагов. Иначе как?

Для USB 1.1 можно не заморачиваться по поводу 20-30мм и завести USB сигналы на оба чипа: переходные контакты в разъемах USB гораздо хуже, чем лишние 30мм на плате. Если CP2102 стоит, GPIO STM32, на которые заведены сигналы USB, нужно оставлять несконфирурированными. Можно даже замутить firmware, которое автоматически определит, есть ли CP2102: надо просто при старте сделать RXD пин STM32 (к какому подключен TXD от CP2101, разумеется) как GPIO вход с PullDown и проанализировать уровень; если уровень "0" - CP2101 отсутствует, а если "1", то CP2101 есть, поскольку его TXD перетягивает вход "наверх".

Несколько сображений. 1. Если основной цикл может не успеть подготовить очередной буфер, то в целом дела плохи. 2. Если можно жить с "нейтральным" сигналом, то что такое " ошибки в генерации выходного сигнала"? 3. Как идея (безотносительно темы): буферы не нужно переключать в TCIF, если запустить DMA на длину всего двойного буфера, а какие-то решения можно принимать по прерыванию HTIF. 4. Ваш DMA срабатывает по готовности какой-то периферии либо тактируется таймером. Может можно остановить эту компоненту, которая пихает DMA?

Вы меня спрашивали тоже по теме четырех входов, ребята ответили уже, что никак, поскольку считает только CNT, а capture registers - только для "слизывания" текущего значения CNT в момент какого-то события. Но STMы имеют много таймеров, старшие камни - вообще очень много, и можно вполне набрать 4 штуки. В одном моем проекте я должен выдавать 4 разных таймерных сигнала, причем стартовать это дело должно синхронно, так я взял 5 таймеров: четыре для генерации сигналов и один как "мастер" для них для синхронизации. И в камне еще остались таймеры (STM32F103RFT6). Не экономьте.

Знакомое дело: у меня на F051 два таймера считают импульсы (частоту) с LC-измерителя. Я пользую вперемешку STL, а также прямой доступ к регистрам. Инициализация таймеров выглядит так: TIM_TimeBaseInitTypeDef TIM_TimeBaseInitStruct = { 0, // TIM_Prescaler TIM_CounterMode_Up, // TIM_CounterMode DIV_Divider -1, // TIM_Period, ARR register 0, // TIM_ClockDivision 0 // TIM_RepetitionCounter }; TIM_ICInitTypeDef TIM_IC1InitStructure = { TIM_Channel_1, TIM_ICPolarity_Rising, TIM_ICSelection_DirectTI, TIM_ICPSC_DIV1, DIV_EdgeFilter, // setting }; // Input: an external signal at CH1 clocks the timer counter: TIM_INIT (tp, TIM_TimeBaseInitStruct); TIM_IC_INIT (tp, TIM_IC1InitStructure); TIM_SelectSlaveMode (tp, TIM_SlaveMode_External1); TIM_SelectInputTrigger(tp, TIM_TS_TI1FP1); TIM_ARRPreloadConfig (tp, ENABLE); TIM_ENABLE (tp); TIM_INIT, TIM_IC_INIT, TIM_ENABLE - просто макросы, инкапсулирующие STL функции, плюс пара своих констант как DIV_Divider и DIV_EdgeFiler. tp - это у меня, например, TIM3. Вы вроде так и делаете. Я надеюсь, мой код даст канву, что и как именно надо проинициализировать. Я приткнул к этому сообщению еще help file на STL для F051. stm32f0xx_stdperiph_lib_um.chm Еще следует не забыть сконфигурировать соответствующий GPIO на альтернативную функцию как вход таймера, т.к., в отличие от F1xx, которые были первой серией cortex от ST, для F0xx даже входы надо конфигурировать на альтернативные функции. Предполагаю, что для STM32L475 дело обстоит похоже.

Привет коллегам. Почитал некоторые темы формума, например, и понял, что многие используют уже готовые USB-Z свистки, которые предоставляют шлюз к Z-WAVE, а сама поддержка идет на "Малине", на которой и работает программа "Controller". У меня же задача - интегрировать контроллер в охранное устройство, которое запилено на STM32 (с достаточными ресурсами и свободным UART). Конечно, я скачал от Silabs все, что можно, имеется Z-WAVE development tools, Simplicity Studio. Загрузил в насадку на ZGM130S (который и будет использован) бинарник SerialAPI, поигрался с ней через встроенный в Simplicity Studio PC Controller и... призадумался. Оказалось, что описание SerialAPI весьма скудное, описаны лишь несколько команд (типа FUNC_ID_ZW_GET_VERSION или FUNC_ID_SERIAL_API_GET_INIT_DATA). Ребята, мне нужен толчок, куда глянуть чтобы понять workflow Контроллера для поиска устройств, их Inclusion, коммуникации с устройствами/узлами и прочее. Еще раз: я не могу запустить готовое из "Малины" или PC; мне нужно, по сути, склонировать их функциональность на STM32. TIA.

Привет коллегам. Может кто знаком с темой? Меня интересует спецификация протокола по этой совмещенной (питание и коммуникация) двухпроводной шине, но не столько для его реализации в своем устройстве, а сколько в смысле "влезть, но не навредить". Поясню: мне надо просто запитать датчик от напряжения на этой шине (мне нужно максимально 3mA при 24V), и хотелось бы знать, как отфильтроваться от коммуникации, и как, в свою очередь, не навредить ей самой. TIA.

Тема I2C с STM32 стара как мир. Серии F10x и F4xx имеют схожие I2C (для F0xx их переделали). Здесь ссылка на мой пост (один из многих) на тему. Надеюсь, поможет.

Я делал на DS2484 именно для общения с DS18B20. Делал упрощенно, в смысле, что исходил из единственного устройства на шине 1-Wire, и не на STM32 HAL, а на, скажем, собственном HAL.

От пиков нет панацеи.

Извините, что встреваю. Просто хочу поделиться граблями. Я неоднократно наблюдал, что (предположительно при пиках питания) может произойти рассинхронизация ADC и DMA, если их отпустить работать самих в циклическом режиме. То есть, может случиться, что в буфере данных произойдет циклический сдвиг: на месте ожидаемой первой выбоки будет вторая, вместо второй - третья, и так по циклу. Это заставляло меня отказаться от полной автономии связки ADC-DMA и пинать ее в прерывании от TC DMA, перезапуская ADC.