alik_tv

Привет всем. Да, дело именно в НЕ сбросе WDT после его сработки. Вот же ребята фичу сделали, так сделали. Спасибо всем за помощь.

после тщательного изучения матчасти вроде нашел ответ. Завтра проверю. Note: If the Watchdog is accidentally enabled, for example by a runaway pointer or brown-out condition, the device will be reset and the Watchdog Timer will stay enabled. If the code is not set up to handle the Watchdog, this might lead to an eternal loop of time-out resets. To avoid this situation, the application software should always clear the Watchdog System Reset Flag (WDRF) and the WDE control bit in the initialization routine, even if the Watchdog is not in use.

Привет всем Хотел сделать перезагруз проца по команде, для этого по флажку перестаю сбрасывать собаку. При этом проц. не перезагружается, а типа виснет. Ни на что не реагирует, кроме аппаратного сброса. Процедуру для включения собаки делаю в main, саму процедуру взял из его описания. void WDT_On(void) { __disable_interrupt(); __watchdog_reset(); WDTCSR |= (1<<WDCE) | (1<<WDE); WDTCSR = (1<<WDE)| (1<<WDP0)| (1<<WDP1)| (1<<WDP2); // 2s __enable_interrupt(); } Сбрасываю так if (ucFlagReset == StatusFlag_Off) __watchdog_reset(); У этого проца появилось прерывание WDT, поэтому на всякий случай сделал пустое прерывание по WDIF, не помогло. Пробовал команду сброса делать в прерывании и в бесконечном цикле(зачем?), в main-е, никакой разницы. В отчаянии полез на столб прочитал errata, ничего похожего там нет. Явно проблема с головой, не могу понять с чьей. Прошу помощи. Олег

Привет всем Заработало, спасибо за помощь. Причина, ADEN был всегда в 1, я его не сбрасывал. Поэтому после выхода из прерывания АЦП, проц быстренько уходил в следующий слип и соотв. опять запускалось АЦП. Выбрал около 100кГц тактовую АЦП, ближе к нижней границе, понятно, тут баланс. Сейчас пришлось поднять в 2 раза, чтобы обеспечить время преобразования, а это уже верхняя граница. Но, что тут сделаешь, я бы в триггерном режиме запустил АЦП, но тогда нужно задействовать еще один таймер. (upd. пардон, бес попутал, триггерный режим в этом ничем не поможет.) Ставить 5В опорное не получится, питание от двух батареек потому оно сейчас и опорное, я бы даже попробовал 1.1В установить, чтобы на малых сигналах динам. диап. не терять. Но это пока только мысли. Надо посчитать, чем мне это грозит. "Напряжение смещения компаратора АЦП" это Offset Error в "ADC Characteristics" ? Олег

Привет всем. Частота тактирования влияет на хар-ки преобразования. Линейность и прочее, как я понимаю. Но, ваш вариант мне больше понравился. Он как-то прямее. 0) Только зачем в main-е устанавливать ADEN? Я по умолчанию ADCSRA устанавливаю в b00001110; Жду прерывание от таймера, оно установит ADEN, выйдет в main(), а после обязательно доберется до sleep.

Привет всем Да, спасибо. Я пытался этот пункт проверить, у меня не получилось запустить АЦП без ADSC. Вернусь к этому вопросу. Но, если я буду так делать я получу 25 тактов на все преобразования. Я сейчас отключаю ADIE, не даю АЦП прерывание делать(и соотв. просыпаться процу), хотя АЦП конечно работает при этом. Олег

Привет всем ADC работает в режиме прерывания. Инициализация ADC: ADCSRA b10001110 ADCSRB b00000000 ADMUX b00100000 Запуск одиночного преобразования - ADCSRA |= (1<<ADSC) Запуск энергосбер. режима SMCR = 0x01, __sleep(); Управляет запуском АЦП - Таймер2. Запуск каждые 2мс. Если не включаю энергосберегающий режим, то все работает как надо. Если включаю, то прерывания АЦП получаю в темпе Free Running mode. Проверял частотомером по короткому импульсу в обработчике прерывания АЦП. Более того, пробовал включить ADC Auto Trigger - Trigger Source (Analog Comparator). При этом компаратор отключен - ACSR = (1<<ACD); Если без энергосберегающего режима, то АЦП запускается каждые 2мс. Если использовать энергосберегающий режим, то Free Running mode. При этом таймер срабатывает _всегда_ с периодом 2мс. Проверял частотомером (как с АЦП). Проверял состояние бита ADATE, в обработчике прерывания АЦП, не установлен. АЦП вполне корректно работает при этом, результат преобразования достоверен. Но хотелось бы все таки понять с чего вдруг, да и потом, это лишняя потребляемая мощность. Смотрел Errata вер. DS80000855A ничего даже близко похожего там нет. Олег

Нашел как обработчик USART3_6_IRQHandler отключить (вкладка NVIC Mode, code generation), при этом инициализация прерывания не выключается. В файле startup_stm32f030xc.s записал свой обработчик(Куб его не трогает). Красиво все работает. Куб и Иар друг другу не мешают. Спасибо за поддержку.

По моему до меня дошло. Я догнал этот пароход. 0) Не обязательно пользоваться HAL_UART_Receive_IT, можно инициализировать буфер приема и включить прием прямо в main-е. А дальше, как обычно, разбирать байты в USART3_6_IRQHandler. Но вопрос в полезности HAL_UART_IRQHandler остается.

Верно, только вызов HAL_UART_IRQHandler чем мне может помочь? я пока не знаю. А если он лишний, то правильный способ от него избавиться, переопределить обработчик прерывания. Вот только как это корректно сделать, чтобы можно было с кубом и дальше работать.

"Заказывать" один байт это тривиальное решение. Зачем мне лишний код и лишние вызовы. А какой более изящный путь не подскажите? Смотрел я исходники, ничего изящного не придумал. Я могу "нейтрализовать" HAL_UART_IRQHandler своим условным переходом, сохраняя возможность перегенерации исходников кубом, но это изврат. Вряд ли разработчики на это рассчитывали. Пока я вижу два варианта 1. Переопределить USART3_6_IRQHandler. Но хотелось бы этого не делать. Некрасивое решение. 2. Может быть предполагалось, что HAL_UART_Receive_IT на первом этапе "ловит" только заголовок кодограммы. Понятно он имеет одинаковую длину(и формат) у всех кодограмм, в одном канале. Т.е. я постоянно(в фоне) жду заголовок, скажем 4 байта, в этих байтах длина данных кодограммы. После того как словил заголовок, я ожидаю данные. Но тут проблема, у функции HAL_UART_Receive_IT нет таймаута. Если придут только три байта она "повесится".

Привет всем В общем цель описана в заголовке. Не могу понять каким образом подразумевалось это делать. HAL UARTа, в отличии допустим от TIM, не экспортирует функции обратного вызова(Callbacks) непосредственно прерывания (по приходу символа), смотрю файл STM32F070xB_User_Manual.chm в поставке куба). И как предполагалось написание обмена датаграммами _разной_ длины в фоне? Посмотрел пример: STM32Cube_FW_F0_V1.9.0\Projects\STM32F030R8-Nucleo\Examples\UART\UART_TwoBoards_ComIT\ это вообще не серьезно. Я не могу принимать решение сколько будет в первой датаграмме байт аж в main-е. Это должно быть при приеме конкретной датаграммы, в зависимости от значения в специальном ее поле. Как функцией HAL_UART_Receive_IT ( UART_HandleTypeDef * huart, uint8_t * pData, uint16_t Size ) и вызовом HAL_UART_RxCpltCallback ( UART_HandleTypeDef * huart ) такое написать? Я не против даже изменить концепцию(извините, очень уж слово нравится) работы с уартом, если мне расскажут как же с помощью таких ресурсов решить конкретную задачу. А как писать программу уровня "Здравствуй мир" я уже понял.

Привет всем Я знаю, есть куча библиотек к этому индикатору, но в тех которые я нашел, вывод информации реализован через полное обновление экрана. Я бы хотел "запустить" вывод графика через аппаратную функцию Scrolling left 0x27. Так быстрее намного. К сожалению мои попытки пока не увенчались успехом, сложилось впечатление, что эта функциональность была реализована только для того, чтобы красивые картинки прокручивать. 1. Нет возможности запустить сдвиг только на один шаг. Все функции сдвига работают "на постоянной основе". Никакой возможности синхронизации с сдвигом тоже нет. 2. Загадочная фраза в описании "After sending 2Eh command to deactivate the scrolling action, the ram data needs to be rewritten." При периодическом(по таймеру) использовании функции "Стоп сдвиг", появляется мусор на экране, причем в случайных местах. Но если я в буфер индикатора помещаю нулевой(ые) байт(фактически эмуляция вывода информации), то мусора на экране нет(т.е. индикатор пустой). При этом если прокручивать "статическую" картинку(без частого стопа и изменения данных в видеопамяти), то индикатор корректно работает многие часы, мусор не появляется. 3. Сдвиг информации в памяти происходит циклический, т.е. "вытесняемые" слева данные помещаются в крайне правый столбец. Это конечно мешает выводу графика. Два вопроса. Как бы все это побороть? и Какие еще есть типы индикаторов с функцией сдвига, реализ. аппаратно(желательно реализованные именно для вывода графиков)? Интерфейс желательно последовательный IIC(приоритет) либо SPI. Олег

Интересная идея, спасибо.

Нужен светофильтр согласованный с http://www.kingbrightusa.com/product.asp?c...id=PSA05-11SRWA Насколько я понимаю, в идеале, фильтр должен повторить график "Relative intensity Vs. Wavelength" этого индикатора. При этом должна быть достаточно высокая плотность(?) фильтра, т.к. рядом с индикаторами на плате стоит приемник ИК. Я бы не хотел, чтобы его было видно через фильтр. Да и саму плату с дорожками тоже. Про пленки я думал, но вот как это будет выглядеть. Не будет ли похоже на залипуху. Боюсь придеться экспериментировать.