k000858
-
Постов
322 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные k000858
-
-
поделитесь пожалуйста кодом. имейл отпраил Вам в личку
к сожалению, не получится: разработка коммерческая, исходниками не делюсь
но если есть конкретные вопросы, постараюсь помочь чем смогу
-
как успехи? получилось довести до ума?
да, все работает
-
Будете одалживать свою плату? Если что, электроэнергию кушает не только МК, но и всё остальное на плате.
ну это и дураку понятно :smile3046:
-
Померить, нет?
если у кого то есть такая возможность (сделать точные измерения потребления устройством с GPIO LOW SPEED & GPIO HIGH SPEED) было бы здорово.
сам тоже проведу чуть позже такие исследования, но пока сомневаюсь в точности своих измерительных приборов.
-
Про осциллограф говорено неоднократно, самим ТС тоже. Смотришь форму тактов и данных. Если кривые, увеличиваешь скорость (ток переключения, будем считать) GPIO. Зависит от емкости нагрузок и самих цепей. Чем больше емкость, тем больше надо задать... Я думаю, скорости GPIO и частота сигнала соответствуют одно другому для некой стандартной емкостной нагрузки в цепи.
окей
спасибо за ответ. значит все так, как я интуитивно предполагал: заранее сказать, какая частота GPIO должна быть для работы SPI на определенной частоте нельзя, можно только методом тыка подобрать.
а вопрос потребления остается открытым: интересно будет почитать разные мнения и аргументы, потому как меня схемотехник заставляет затягивать гайки скоростью GPIO (для снижения потребления), а будь моя воля - я оставил бы скорость максимальной что б на все хватило.
-
Можно считать, что если написана скорость 1 МГц, то на такой скорости порт будет способен выдавать приемлемый меандр. Это определяется током, который будет выдавать порт, чтобы зарядить цепь, подключенную к нему.
А Куб при том, что в нем цифры частоты не указаны, а скрыты за абстракцией LOW и т.п.
блин, еще раз:
что 1 МГц ДЖПИО = "на такой скорости порт будет способен выдавать приемлемый меандр" мне итак слава богу понятно
мне не понятно, какая минимальная скорость ДЖПИО нужна для обеспечения скорости СПИ в 1МГЦ.
уточню: верно ли утверждение, что для работы спи в 1 МГц, минимальная необходимая скорость ДЖПИО тоже 1МГц ?
-
причем здесь куб
мне непонятно, частота 1Мгц GPIO = частоте 1MHz SPI?
то есть мне для понижения потребления необходимо закрутить гайки в виде скорости GPIO, но до такой скорости которой достаточно для работы периферии.
можно ли сказать что ноги SPI, работаюшего на 1 MHz будут щелкать с частотой 1MHz?
-
Понятно, какую (скорость). Не бойтесь скорости в пределах рабочих режимов. А вот превышать (нарушать) не надо.
ничего не понял..
какую же все такие скорость GPIO выставлять для SPI ног (SPI 1 MHz) ???
-
Имеем STM32L052, к которому подключен девайс по SPI, скорость SPI 1MHz, какую выбрать скорость GPIO для корректной работы SPI?
почему спрашиваю: при выборе GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; имеем глюки при работы SPI, да и видно по осциллографу что посылки кривоватые.
-
дождался обновления плагина OpenSTM32 с поддержкой eclipse 4.6 (Neon) и тоже обновил сам eclipse + проапгрейдил воркспейсы под новый эклипс
первые впечатления: возросла скорость загрузки и работы самой айдию. а это уже ощуитмый +. если еще зависать перестанет после половины дня работы, то я вообще обрадуюсь. Новых фишечек пока не ощутил, вероятно, потому что эклипс использую для C/C++ девелопинга.
Посмотрим как проявит себя в работе
-
кто уже обновился? какие фишечки/рюшечки добавились? какие минусы?
-
Опубликовано · Изменено пользователем IgorKossak
бездумное цитирование · Пожаловатьсяхм. ваш вариант подошел
именно в переменной-аргументе port содержался нужный номер порта
интересно, почему и в upcb->local_port и upcb->remote_port содержится один и тот же локальный порт, который открывает UDP сервер.
в общем заработало, спасибо
-
Поднял UDP сервер, отвечаю на входящие запросы.
Проблема вот в чем: открыл 1200 порт, поступают запросы с локального 1200 а удаленного **** порта, сервер должен был ответить с 1200 локального на **** удаленный порт, а в действительности отвечает с 1200 на 1200 порт.
Что я делаю ни так?
открыл порт
upcb = udp_new(); // Create a new UDP control block if (upcb) { // Bind the upcb to the UDP_PORT port // Using IP_ADDR_ANY allow the upcb to be used by any local interface err = udp_bind(upcb, IP_ADDR_ANY, 1200); if(err == ERR_OK) { udp_recv(upcb, udp_receive_callback, NULL); // Set a receive callback for the upcb } }отвечаю udp_send(upcb, ans); // Send data
либо udp_sendto(upcb, ans, &upcb->remote_ip, upcb->local_port); // Send data
в отладке вывожу upcb->local_port и upcb->remote_port которые оба якобы 1200, но в действительности это ни так - видно сниффером сети
-
Есть схемка: замкнутые ножки мк, 1) EXTI 2) ADC - соответственно, одной ловлю изменение фронта, другой мерию напряжение.
по отдельности функции работают корректно, однако, после инициализации АЦП-шной ножки (без инициализации самого АЦП) в режиме аналог - перестают ловиться прерывания на первой ножке. да даже чтение состояния GPIO не дает результата - состояние не меняется
Кто нибудь сталкивался с таким?
Может можно как то обойти...?
-
в общем сделал "будильник" на основе часов и столкнулся с новой незадачей (((
если выставить будильник 1 сек - просыпается через 1.5 сек, если выставить будильник 10 сек - просыпается через 10.5 секунд. проверили осциллографом
будильник завожу следующим образом:
- считываю текущее время
- приплюсовываю к текущему времени необходимое время (например 10 сек)
- записываю это время алярм_тайм
-
Проиницилизировал RTC от встроенного LSI. После первого чтения времени часы перестают идти: если перезагрузить контроллер (например отладчиком) (но не по питанию) часы сново будут идти до первого чтения.
Кто нибудь сталкивался с таким эффектом?
трабла разрешилась: помимо времени, пришлось считывать дату. часы пошли
-
ок начал делать вэйкАП по RTC_Alarm, столкнулся с проблемой: часы не идут. то есть 1 раз считываю значение часов - значение корректное (часы шли до этого мгновения), повторное чтение показывает, что часы остановились
после перезагрузки программы, проблема уходит.
-
А будильник разве не подходит для этого? Хоть через час, хоть через сутки..
будильник вроде ставится на конкретное время? + для этого должны быть настроены часы?
+ после срабатывания будильник надо переставлять будильник и так каждую секунду..
-
Есть девайс на вышеуказанном микропроцессоре, девайс периодически уходит в stop Mode. необходимо выводить его из этого состояния через определенное время. делаю это с помощью блока RTC, но удается только если счет на секунды (разбудить через 1-0 секунд) т.к. в регистре WUTR только 16 бит на WakeUpCounter
а если необходимо разбудить девайс через час? как быть?
-
Дык в первую очередь осциллом надо, вы словно не с "железом" работаете (:
В общем, сообщество, не будем мешать, "…пусть Володя помучается…"
осциллом пока не поймали. осложнение в том, что если слать 1 байт то все ок.
то есть посылка с ПК не отличает от посылки с МК
проблема наблюдается при посылке пачки байт: 1й ок а часть последующих коверкается.
проблема именно со стороны передатчика МК
Так же если замкнуть RX с TX, заметно, что получаем не то, что отправляли
Bit8 Possible parity bitP.S. длина пишется с одним "н".
WordLength сделал 9 бит - заработало.
вы намекали на это?
When the parity control is enabled, the computed parity is inserted at the MSB position (9th bit if M=1; 8th bit if M=0) and parity is checked on the received data. This bit is set and cleared by software.
как то не логично: если выбрал Even, то и выбрал 9 бит, а на ПК оставляешь 8 бит. как то не сходится. но работает.
можете разжевать? недопонимаю..
-
А M?
М????
длинна данных?
-
Джедаю надо или продолжать убиваться об Куб, или заглянуть в руководство и прочитать про биты M, PCE, PS.
Парити контроль инейбл + парити селекшин биты в контрольном регистре ЮАРТ ?
а как по-вашему я настраиваю ЮАРТ на 8E1/8O1 не юзая эти биты?
-
Флаг PE при приёме есть, да?
Осциллографом неправильность формирования паритета из передатчика видна?
осциллограммы пока не смотрел
пока тест такой: настроил ЮАРТ 8N1, отправил строку, ком-портом получил - все ок
настроил на 8E1, отправил в КОМ-порт, получил совсем не то (малая часть байт символом совпадает)
настроил на 8O1, отправил в КОМ-порт, получил аналогично не то
при этом на ПК формат менять не забываю (8E1, 8N1).
-
Странно: на UART_PARITY_NONE USART с COM-портом работает корректно.
на UART_PARITY_EVEN и UART_PARITY_ODD нет.
Даже если замкнуть Rx с Tx - получаю, не то что отправляю.
Глючит именно передатчик.
ктонибудь сталкивался с такой проблемой на данном контроллере?
STM32: HardFault
в STM
Опубликовано · Пожаловаться
на сколько помню, до 100 метров в нашем случае работает
схемы у меня толком нету (для меня, как для программиста, это просто ЮАРТ + 1 джио ножка для подтяжке питания на линию на время преобразования температуры), а если б и была то выложить по той же причине не смог бы