Асмаллри
Солнце 10 декабря 2017 г. 20:03
Привет,
У меня есть требование использовать как режимы сна, так и режимы ожидания на чертеже. Я использую STM32Sleep.H Библиотека для резервного режима, и она работает, как и ожидалось, однако функция Gotosleep () в библиотеке не работает правильно - вместо этого ставит процессор в режиме ожидания. Я хочу положить процессор в глубокий сон в течение X минут, и когда он вышел из глубокого сна, засыпайте его, когда он ждет внешних задач. Процессор выходит из глубокого сна, либо в результате внешнего пробуждения на штифте WKUP, либо в результате тревоги RTC. Для спящего режима я использую второе прерывание RTC, чтобы разбудить процессор от сна каждую секунду. Мой код не использует никаких других функций прерывания.
Я посмотрел много кода на этом форуме для сна и обнаружил, что они не работают над моим оборудованием и во всех случаях просто продолжают выполнять сразу после оператора WFI. Во всех случаях, когда программное обеспечение, по -видимому, правильно кодируется, процессор просыпается сразу после выполнения команды WFI. Я наблюдал это поведение, используя логический анализатор и установил тестовые штифты перед инструкцией WFI и потом.
В моем Bluepill установлен USB -загрузчик, однако USB используется только для этой функции, он не используется для приложения. Я подозреваю, что процессор проснулся от основного прерывания или от загрузчика. Но я не могу найти ничего в других опубликованных примерах, которые пытаются устранить прерывания за пределами самого приложения. Я что -то упускаю?
У меня есть требование использовать как режимы сна, так и режимы ожидания на чертеже. Я использую STM32Sleep.H Библиотека для резервного режима, и она работает, как и ожидалось, однако функция Gotosleep () в библиотеке не работает правильно - вместо этого ставит процессор в режиме ожидания. Я хочу положить процессор в глубокий сон в течение X минут, и когда он вышел из глубокого сна, засыпайте его, когда он ждет внешних задач. Процессор выходит из глубокого сна, либо в результате внешнего пробуждения на штифте WKUP, либо в результате тревоги RTC. Для спящего режима я использую второе прерывание RTC, чтобы разбудить процессор от сна каждую секунду. Мой код не использует никаких других функций прерывания.
Я посмотрел много кода на этом форуме для сна и обнаружил, что они не работают над моим оборудованием и во всех случаях просто продолжают выполнять сразу после оператора WFI. Во всех случаях, когда программное обеспечение, по -видимому, правильно кодируется, процессор просыпается сразу после выполнения команды WFI. Я наблюдал это поведение, используя логический анализатор и установил тестовые штифты перед инструкцией WFI и потом.
В моем Bluepill установлен USB -загрузчик, однако USB используется только для этой функции, он не используется для приложения. Я подозреваю, что процессор проснулся от основного прерывания или от загрузчика. Но я не могу найти ничего в других опубликованных примерах, которые пытаются устранить прерывания за пределами самого приложения. Я что -то упускаю?
rem: ------------- use STLINK CLI
rem:stlink\ST-LINK_CLI.exe -c SWD -P %str% 0x8000000 -Rst -Run
rem: Using the open source texane-stlink instead of the proprietary STM stlink exe
texane-stlink\st-flash.exe write %str% 0x8000000Стивестронг
Пн 11 декабря 2017 г. 12:25
Вы питаете доску от USB? Если так, то неудивительно, потому что серийный USB запускается и работает на заднем плане.
Если вам не нужен сериал USB, то вам следует удалить директиву компилятора "-deserial_usb" с досок.Линия TXT, соответствующая таблеткам.
Если вам не нужен сериал USB, то вам следует удалить директиву компилятора "-deserial_usb" с досок.Линия TXT, соответствующая таблеткам.
Асмаллри
Пн 11 декабря 2017 г. 16:15
Спасибо. Я не питаю BluePill через USB, у меня есть модифицированный кабель, который отключен USB -провод отключен. Существует недостаток с Bluepill, который соединяет USB непосредственно к рельсу +5 -вольт, поэтому, если вы включите его снаружи и используете USB большие токи могут переходить от источника питания к прикрепленному USB -устройству.
Я попробую директиву для совета директоров.txt file.
Спасибо, Эндрю
Я попробую директиву для совета директоров.txt file.
Спасибо, Эндрю
Эдогальдо
Вт 12 декабря 2017 г. 7:47
Здравствуйте, Эндрю, проблема, вероятно, связана с прерыванием Systick, которое запускает каждый МС.
Лучший, e.
Лучший, e.
AG123
Вторник 12 декабря 2017 г. 13:40
Я не слишком уверен, можно ли замаскировать определенные прерывания, прерывания рук, недостатки & ISR довольно сложный / сложный
Между прочим обнаружил приложение также о режимах низкой мощности
http: // www.ул.com/content/ccc/resource/ ... 171691.PDF
Мне не нужно было спать, поэтому я просто держу RTC работать на VBAT от монетной ячейки, отключая питание, если это не нужно
Между прочим обнаружил приложение также о режимах низкой мощности
http: // www.ул.com/content/ccc/resource/ ... 171691.PDF
Мне не нужно было спать, поэтому я просто держу RTC работать на VBAT от монетной ячейки, отключая питание, если это не нужно
Асмаллри
Ср 13 декабря 2017 г., 5:40
Спасибо всем. Вот что я нашел,
Было два основных источника прерываний, которые разбудили процессор за пределами моего применения. Первым был USB от загрузчика. Я не хотел создавать пользовательский файл досок. Я видел, что этот подход слишком сложно со временем. Вместо этого самая первая инструкция в моей настройке была:
Было два основных источника прерываний, которые разбудили процессор за пределами моего применения. Первым был USB от загрузчика. Я не хотел создавать пользовательский файл досок. Я видел, что этот подход слишком сложно со временем. Вместо этого самая первая инструкция в моей настройке была:
#define RX1 PA0 //t2c1
void init_rx()
{
pinMode(RX1, INPUT);
Timer2.setPrescaleFactor(72);
TIMER2->regs.gen->CCMR1 = 0b010000001;
TIMER2->regs.gen->CCMR2 = 0b0;
TIMER2->regs.gen->CCER = 0b0001;
Timer2.attachCompare1Interrupt(ppm_input);
}
uint16_t last;
uint8_t chan = 0;
boolean newrc = false;
void ppm_input(void)
{
uint16_t diff,act;
act = TIMER2->regs.gen->CCR1;
......
Rogerclark
Ср 13 декабря 2017 г. 8:37
К вашему сведению
На данный момент сериал.end () не приводит вниз USB -сериал . Это известная «функция», и есть пиар, ожидающий этого, чтобы исправить это.
На данный момент сериал.end () не приводит вниз USB -сериал . Это известная «функция», и есть пиар, ожидающий этого, чтобы исправить это.
Mrburnette
Ср 13 декабря 2017 г. 14:57
[Rogerclark - Ср 13 декабря 2017 г. 8:37] - К вашему сведению... Конечно, такое «исправление» убьет серийное перечисление над USB ... Можно также отключить USB -кабель. Забавная часть этого заключается в том, что повторное возмещение может не принять тот же номер порта. О, радость ...
На данный момент сериал.end () не приводит вниз USB -сериал . Это известная «функция», и есть пиар, ожидающий этого, чтобы исправить это.
Луча
Эдогальдо
Ср 13 декабря 2017 г. 16:48
Разве этого не было бы достаточно, чтобы повторно рассказать о сериале.begin () в пробуждении?!
Rogerclark
Ср 13 декабря 2017 г., 19:09
По мере того, как IDE отправляет команду для перезагрузки (в загрузчик) через серийный USB, если вы называете сериал.End (), скорее всего, удалит возможность получения команды перезагрузки.
Ядро тайно называет серийным.Begin () как часть Core Init, чтобы включить эту функцию.
Я не проверил пиар, чтобы отключить мощность USB, когда сериал.end () называется, но это кажется логическим расширением того, что сериал.End () уже делает.
Ядро тайно называет серийным.Begin () как часть Core Init, чтобы включить эту функцию.
Я не проверил пиар, чтобы отключить мощность USB, когда сериал.end () называется, но это кажется логическим расширением того, что сериал.End () уже делает.
Mrburnette
Чт 14 декабря 2017 г. 12:51
[Эдогальдо - Ср 13 декабря 2017 г. 16:48] - Разве этого не было бы достаточно, чтобы повторно рассказать о сериале.begin () в пробуждении?!Возможно. https: // Поддержка.Microsoft.com/en-us/hel ... USB-Device
В Linux Mint 17.3/64, я был свидетелем загрузки на клен, сброс и другой порт перечислен. Затем мне нужно выбрать новый последовательный порт в ардуиноиде. Я действительно не заглянул в специфику, но помни, что это произошло с доской узлов ESP8266.
Луча
Гилхад
Чт 14 декабря 2017 г. 2:28
Heppens для меня каждый раз на Linux Gentoo - Alternatinig TTYATM0 и TTYATM1. Может быть, я добавлю правило, что все порты получат такое же символическое имя, как TTYSTM, если они «одинаковые» ... Imho то же самое было с avr и ttyusb0 / ttyusb1
Ахулл
Чт 14 декабря 2017 г., 7:18 утра
Похоже, это происходит из-за условия гонки, когда, если вы слишком быстро подключите/отключите (и это не должно быть очень быстро), старый/разработчик/имя не очистилось вовремя, чтобы порт повторно выметал со старым именем.
Я видел, что это случалось довольно много (я использую Ubuntu, поэтому, вероятно, влияет на большинство дистрибутов на основе Debian). Кстати, аналогичная проблема существует в некоторых версиях Windows, что может привести к тому, что множество Phantom Com Ports загромождают это место, как я узнал, пытаясь поставить новые изображения ROM на некоторые старые телефоны Android, используя виртуальную машину Windows.
Я видел, что это случалось довольно много (я использую Ubuntu, поэтому, вероятно, влияет на большинство дистрибутов на основе Debian). Кстати, аналогичная проблема существует в некоторых версиях Windows, что может привести к тому, что множество Phantom Com Ports загромождают это место, как я узнал, пытаясь поставить новые изображения ROM на некоторые старые телефоны Android, используя виртуальную машину Windows.