EugenyAM

А как сконфигурировать в CubeMX этот класс? В списке для USB Device его нет. Пытаюсь поднять USB_OTG_HS в режиме FS с внутренним phy. Нужно задействовать 5 конечных точек bulk и interrupt. До этого работал на F103 с SPL - проблем с реализацией USB не было. Сгенерил проект на F207 с классом CDC, под IAR, начал переконфигурировать конечные точки и получил интересный результат - конечная точка типа IN передает данные только в том случае, когда ее номер равен 0x81. Если изменить номер на 0x82, 0x83 и.т.д. данные не передаются. Если задать две точки 0x81, 0x82 передает данные только через 0x81. Выделенное прерывание на EP1 в проекте не используется. Есть ли известное решение данной проблемы?

МК STM32F107 + Ethernet Phy DP83848 + LwIP, SYSCLK=72MHz Запустил многоканальный драйвер светодиодов WS2812B на базе TIM->DMA->GPIO Использовал библиотеку https://github.com/g4lvanix/0xWS2812, Длина фреймбуфера 16Кб, цикл вывода запускается через 25мс после окончания предыдущего При приеме пакетов ethernet, даже при отсутствии записи во фреймбуфер наблюдается джиттер, который проявляется, как кратковременное моргание случайных светодиодов. Какие настройки DMA или Ethernet могут помочь? Или единственный путь - ждать паузы в Ethernet пакетах и после ее наступления запускать вывод фреймбуфера? Поможет ли замена МК на F207 или F407?

Какие есть модули с точкой доступа на 7-8 клиентов, чтобы работали при температурах до -40? USART/SPI - не приципиально... нужна беспроводная альтернатива RS485 и в то же время возможность подключения планшета/смартфона/ноутбука. Архитектура сети - звезда. Естественно, нужны встроеннные протоколы TCP и UDP. Или проще в этом случае поставить готовую точку доступа? (в центральном контроллере есть LAN).

А что с выбором индуктивности для низких температур? что конкретно известно про CW68 ?

Требуется светодиодный драйвер со следующими требованиями: желательно импульсный (выше КПД) Выходной ток 350/700мА Напряжение питания до 36В Вход для ШИМ-диммирования от МК (5 или 3,3В) Температурный диапазон -40 +85 что можно применить? какие рекомендации по выбору обвязки? китаец SD42525 в типовом включении по даташиту на ток 350 мА выходит из строя при подаче питания на низких температурах ( -30), хотя в даташите заявлено operating temperature -40..+85. похоже, пробивается силовой ключ. в обвязке присутствует дроссель CW68, как у него с работой на низких температурах? Если температура окружающего воздуха упала во время работы - продолжает работать до выключения и охлаждения. Плата находится в замкнутом объеме внутри светильника, который подогревается светодиодами.

если есть сигнал PPS - к нему привязывается момент записи (обнуления) секунд в RTC при коррекции. если нет сигнала PPS - точность синхронизации будет не более одной секунды возможно, в NMEA выдача значения времени в сообщении $GPRMC не плавает относительно начала секунды (может сработать для относительной синхронизации начала секунды на различных устройствах с приемниками одного типа) опять же желателен секундный сигнал запроса прерывания, синхронизированный со сменой секунд. например, если таймер локального времени считает с периодом 1 мс до 1000, затем обнуляется, то его значение в момент прерывания от (1) дает текущее отклонение в мс.

например так: (сервер взят из винды) AT+QNTP="time.nist.gov",123 должен прийти ответ: OK +QNTP: 0 если не 0 - ошибка синхронизации далее получаем время (UTC) из часов модема: AT+CCLK? +CCLK: "13/12/24,06:21:48+00" OK далее остается учесть таймзону и преобразовать в нужный формат источник - Документ M10_ATC_V1.2.pdf PS есть российский портал серверов точного времени http://www.ntp-servers.net/servers.html

Стек в Quectel M10 поддерживает NTP, все работает. Вполне жизнеспособный вариант при отсутствии приема спутников

В quectel L10 точно выдается? В сообщении $GPRMC или в другом? а признак валидности при этом устанавливается?

Необходимо поддерживать системное время в удаленных контроллерах с точностью до 1 секунды. Основная синхронизация - GPS приемник Quectel L10 в каждом контроллере, связь с центром по GPRS. Если нет данных времени от GPS, RTC фактически может уходить за сутки до 1 минуты. Можно ли вытащить время из GPS при 1-2 активных спутниках? Как можно реализовать синхронизацию через GPRS от сервера (сервер синхронизирован с интернетом, но время доставки пакета к контроллеру по GPRS недетерминировано и обычно более 3 секунд) ?

Вроде бы пункт про несовместимость сигнала MCO с требованиями Ethernet в Errata на STM32F4 отсутствует (в отличие от STM32F2), значит можно в режиме RMII использовать проверенное решение от STM32F107 - тактировать REF_CLK частотой 50 МГц от MCO. Или я ошибаюсь?

Есть прибор, работающий в режиме 24/7, используется lwip для обмена по TCP. Сейчас работает со статическим IP. Если включить получение адреса по DHCP, все тоже работает (пока в тестовом режиме). Возникает вопрос - что произойдет, когда закончится срок выдачи адреса у DHCP сервера? Нужно ли предпринимать какие-либо действия со стороны ПО прибора для перезапроса адреса или стек все сделает сам? Если нужно инициировать запрос DHCP, как узнать, когда это нужно делать?

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

Розетка с трансформатором J00-086NL (1,414/1)

На сайте микрочипа был пример эмуляции FT2232 "в образовательных целях" на Си, там вроде все основные функции D2XX обрабатывались. Гугл в помощь...

Возникла необходимость сделать эмулятор EDID. Достаточно ли в случае с DVI/HDMI просто подключить микросхему EEPROM (с записанными данными) к линиям DDC входного разъема, подать +5V на HotPlug и запараллелить все остальные сигналы на входном и выходном разъемах? Или нужен активный буфер для остальных линий? Реально монитор должен подключаться "на горячую", при этом видеокарта не должна замечать подключение/отключение. Для подключения по VGA вроде еще требуется организовать нагрузку 75 Ом на линиях RGB, чтобы видеокарта увидела "монитор", в этом случае, получается, их буферизация обязательна? В этом случае схемотехника сигнальных линий аналогична одному каналу VGA-сплиттера?

Поможет STM32 ST-Link Utility Зашивает из HEX-файла через ST-Link. В том числе от любого Discovery. В ней также можно активировать защиту от чтения.

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

Спасибо, нашел пример от ST для F207, посмотрел, как там сделано... с tcp_recved() все заработало!

В проекте используется lwip RAW API без RTOS TCP клиент, соединяется с сервером и обменивается данными после приема 2920 байт данных от сервера (в нескольких сообщениях) с момента соединения, прием прекращается. На передачу стек продолжает работать нормально. После дисконнекта и повторного коннекта, все снова работает, пока не будет принято 2920 байт. код функции обработки приема err_t tcp_client_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) { u8 data; u32 i; if(p!=NULL) //Защита при дисконнекте { for(i=0;i<p->len;i++) { data=((u8 *)p->payload)[i]; RxBuf[RxNum++]=data; } RxTotal+=p->len; //это тот самый счетчик, который считает принятые байты с момента коннекта до 2920 pbuf_free(p); LAN_RxProcess(); } return ERR_OK; }

Устройство на STM32F107 с собственным источником питания. Для диагностики используется USB интерфейс в режиме Peripherial Device only (виртуальный COM) Подключение к хосту непостоянное: пришли - подключились - выполнили действия - отключились. Контроллер USB OTG использует VBUS для определения момента подключения к хосту. Если просто соединить +5V с USB и ногу VBUS - при отключенном БП можно получить фантом. Каким образом правильно завести VBUS с USB? Может кто знает про аппноту по этому вопросу? Обмен сделан на базе примера Virtual COM Port от ST, нижний уровень работы с USB не трогался. Бывает, что устройство при длительном подключении самопроизвольно уходит в SUSPEND. (ранее замечал подобное за STM32F103, там вопрос решился примением кабеля с ферритовым фильтром). Сейчас программно отслеживается ситуация: (Кабель_подключен && bDeviceState==SUSPENDED) и выполняется USB_Cable_Config(DISABLE), затем USB_Cable_Config(ENABLE). В принципе помогает, но процедура коннекта активно вызывает прерывания и на это время отваливается прием данных по UART (нарушаются таймауты приема очередного байта). Как корректно перевести USB в рабочее состояние?

В Хабаровске на Билайне заработало нормально (раньше с новыми симками не подключалось к серверу по TCP). В Красноярске на МТС аналогично. В Московской области (Билайн, Мегафон) связь стала заметно устойчивее (раньше устройство могло после разрыва сутками не выходить на связь, пока ему не передернут питание)

Путем внимательного изучения документации по M10 и ряда экспериментов был найден работоспособный алгоритм инициализации для установления связи с TCP-сервером Проверить сигнал STATUS, если 0, перейти на включение питания Выключение питания Ожидание STATUS=0, если за 1 минуту не дождались, выполнить отключение по аварийному сигналу Ожидание 5 секунд Включение питания Ожидание STATUS=1, если не дождались - неисправность модема Ожидание 1 секунда ATE0 - запретить эхо AT+IPR=115200 - зафиксировать скорость обмена AT+IFC=0,0 - отключить управление потоком (если оно не используется) AT+CMEE=2 - установить расширенный формат вывода сообщений об ошибках AT+QSIMSTAT? - запросить наличие SIM-карты - ожидаем ответ +QSIMSTAT: 0,1 AT+CIMI - запросить код сети (первые 5 цифр в ответе), далее используется для выбора из таблицы параметров APN,username,password AT+CSQ - запросить уровень сигнала сети - ожидаем ответ, отличный от +CSQ: 99,99 AT+CREG? - ожидаем ответ +CREG: 0,1 - если не дождались - ошибка регистрации в сети AT+CGATT? - ожидаем ответ +CGATT: 1 - если не дождались - ошибка подключения GPRS далее, если нужно, проводим настройку параметров стека TCP/IP (AT+QIPROMPT=0 и.т.д.) AT+CSGP=1,"APN","username","password" - задать параметры подключения к APN AT+QISTAT - получить состояние стека TCP/IP - далее, в зависимоcти от состояния: - IP INITIAL, IP STATUS, IP CLOSE - устанавливаем соединение: -- AT+QIOPEN="TCP","xxx.xxx.xxx.xxx",port - ждем CONNECT OK, если CONNECT FAIL, переходим на QT+QISTAT -- AT+QISEND=... передаем данные на сервер - IP START, IP CONFIG, IP IND, IP GPRSACT - деактивируем контекст -- AT+QIDEACT, переходим на AT+QISTAT - TCP CONNECTING - отменяем предыдущую попытку соединения -- AT+QICLOSE, затем сразу на AT+QIOPEN... - PDP DEACT - если получили такой ответ - идем на начало Работает с симками МТС, Билайн, Мегафон в Омске, когда будут результаты из других регионов - сообщу.

Тогда сформулируем вопрос по другому - у какого модема самый безглючный встроенный TCP/IP стек? Звонки не нужны, SMS только входящие, GPRS - основной канал для TCP/IP

M10 новые симки Билайн - Хабаровск МТС - Красноярск всегда CONNECT FAIL В Омске разное поведение при подключении на несуществующий сервер на Билайн/Мегафон CONNECT FAIL, дальше надо его выводить пинком из состояния CONNECTING, на МТС выдает CONNECT OK, но естественно потом на отправку данных SEND FAIL