NikolyaN

И судя по всему никто не делает :laughing: Или это большой секрет?

Просто по параметрам очень похож, правда нагреватель там не платиновый. А название у этого "российского сенсора" есть? Или хотя бы кто делает?

А этот чудо сенсор не CCS801 случаем?

И еще у человека был вопрос а можно ли вообще так делать. Вот я и предупредил человека, чтобы у него не возникло других глюков. А в зависимости от критичности его приложения пусть сам решает, стоит ему так делать или нет. Я у себя так делать не стал, хотя тестирование показало, что все замечательно переписывается много-много раз и ничего не портится.

Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок. И если суммарное время этих записей превысит tCPT то может произойти большой облом - похерится не только что он пытается записать, но и то что было записано до этого. Хотя я экспериментировал и не смог такого добиться даже переписывая по одному биту меняя из 1 в 0 весь блок. Но флэшь имеет свойство стареть, и при разных температурах результаты могут отличаться. А потом я просто дал человеку совет как сделать это просто и надежно, и не превышать это время. Теперь подумайте, что будет если сделать так как посоветовали вы, если после стирания флэша произойдет какой-то сбой. Вы останетесь без настроек :-). В моем варианте в случае сбоя у вас останутся хотя бы старые настройки. А вот с этим по моему большие проблемы, потому что когда пишется флэш все остальное стопорится (наверняка утверждать не буду, но по экспериментам мне так показалось).

Тут пришел Ржевский и все опошлил :-) В свое время тоже реализовывал подобную задачу. И байтики можно дописывать и в байтиках битики менять с 1 на 0. И все это замечательно работало. Но от использования в коммерческом проекте меня остановил один абзац в SLAU208: То есть, как я понимаю это дело. Есть какое-то накапливающееся время подачи программирующего напряжения. При каждой записи байта/слова это время увеличивается. И если оно превысило tCPT (можно посмотреть в даташите на кристалл) то результат становится непредсказуемым. В итоге было реализовано поочередная запись в 2 сегмента. В сегменте выделен специальный байт в качестве флага. Сначала этот флаг ставится в состояние что данные устарели, потом новые настройки пишутся в другой сегмент, проверяется правильность записи и только потом сегмент со старыми настройками стирается.

Добрый день! Чтобы прерывания происходили их надо разрешить в этой сторочке TBCTL=MC_2+TBSSEL_1+TBCLR+TBIFG Вместо TBIFG нужно поставить бит TBIE И описание прерывания немного по другому выглядит, потому что у таймера В 2 прерывания (хотя может для какого-то кристалла может быть и так, как у вас) #pragma vector=TIMER0_B0_VECTOR __interrupt void TIMER0_B0_ISR(void) Удачи в изысканиях :-)

Дополню то что написал Василий123. В ADC12CTL1 задается источник тактирования (ADC12OSC (MODCLK) /ACLK/ MCLK/ SMCLK). И есть 2 делителя частоты от выбранного источника тактирования: ADC12PDIV в ADC12CTL2 и ADC12DIV в ADC12CTL1. В результате деления получается непосредственно частота тактирования ADC12CLK. Как с ADC12CLK связана частота 200кГц? Нужно чтобы соблюдалось следующее ADC12CLK / 13 < 200кГц, где 13 это количество тактов на преобразование для 12 битного режима. На самом деле максимальные допустимые значения ADC12CLK лучше смотреть в пдф на кристал в разделе "12-Bit ADC, Timing Parameters". Эти 200кГц это какая-то обобщенная цифра, не имеющая отношения к реальности. Похоже перекочевала из 2ххх семейства.

Извините, если задел Вас. Не со зла. Просто ваше безапеляционное утверждение, что "назначение PG не для сброса "проца", хотя сами TI рекомендуют его для этого использовать, заставило написать мой ответ в несколько язвительной форме. Да я в общем-то понимаю в чем между ними разница. Но согласитесь что и PG для ресета вполне подходит. Конечно он не столь безопасный как ресет с реализованными задержками и гистерезисами. Просто суть моей проблемы от этого не меняется. И даже если бы там был полноценный Ресет, все работало бы также. На этом предлагаю дискуссию завершить. Будут вопросы по существу - обращайтесь.

Я не могу, также уверенно как Вы, утверждать каково истинное предназначение Power Good. Но если посмотреть tps79733-q1.pdf p.10 microcontroller application, то там они рекомендуют сделать именно так, как было сделано у меня. И уже в нескольких устройствах это отлично работало, пока не понадобилось реализовать резервное питание.

Победил я таки эту проблему. Как и предполагал всему виной железо. В качестве стабилизатора питания для МК использую TPS79733, а его выход PG, как рекомендуют в даташите, подключил к ножке RESET МК. Ну и эта су... (замечательная микросхема) успевает сресетить МК до того, как SVSH сработает. Этот ресет и выключает RTC. Если используете Backup Supply не подключайте внешние Power monitor к RESET или переводите RESET в NMI !!! Осталось прояснить вопрос почему LOCKBAK ставится при SCG1=1. Надеюсь ребята их Техаса ответят мне на него на е2е :-)

Тут не совсем понятно чему равен SMCLK. Предположим что == FSYS (7372800Hz вроде так у вас получается). И еще не понятно что такое "4МГц системной частоты" Вообще, можно попробовать так: #define BAUD 230400ul #define SMCLK_FREQ 7372800ul UCA0BRW = (SMCLK_FREQ + BAUD / 2) / (16ul * BAUD); UCA0MCTL = UCOS16 + UCBRF0 * (((SMCLK_FREQ + BAUD / 2) / BAUD) & 0x0f); Удачи

Тут еще подумалось, а может это все же железные проблемы. Если у кого-то реализован RTC на 5/6 серии и описанных проблем не наблюдается, откликнитесь пожалуйста. Не нашел как добавить это в первое сообщение.

А из описания slau208n.pdf p. 122 следует The high-side SVS (SVSH) that is located in the PMM module and supervises the primary supply (DVCC) controls the switching between primary and secondary supply.

Здравствуйте, коллеги MSP-шники! Столкнулся с тем что RTC_B перестает считать при переключении на питание от Backup батарейки. То есть регистры времени сохраняются, но время не тикает пока не появится основное питание. При этом кварц продолжает генерить (смотрел осциллоскопом). Чип MSP430F5358, но думаю это проблема не только этого чипа. Сначала сделал все сам по описаниям. Столкнулся с проблемой. Начал ковырять, ничего найти не смог, уже начал подумывать, что проблема в железе. Нашел у TI slaa665, скачал пример, подправил программу под свое железо и О ЧУДО!!! Выключаешь питание, а часы продолжают тикать. Начал разбираться чем отличается у меня и у них. Сначала обнаружил следующее if((BAKMEM0 == 0xDEAD) && !(RTCCTL01 & RTCOFIFG) && (RTCCTL2 & RTCCALS)) //backup not lost В этом условии (RTCCTL2 & RTCCALS) == 0. Хотя более логично было бы увидеть ошибку осцилятора (RTCCTL01 & RTCOFIFG) == 1 т.к часы просто останавливаются. Затем увидел более интересное, у них при входе в прерывание RTC всегда включен Backup Supply (кстати под JTAG этого не увидишь). Подумал, наверно это PMM у меня неправильно настроен. Повторил все как у них. Получил "Фиг вам". Не включается у меня Backup Supply. Поотключал все что можно, PLL убрал. Эффект = 0. И тут каким-то чудом наткнулся, что если в slaa665 lpm3 поменять на lpm0 (как у меня), то никакого переключения в Backup Supply не происходит, и при выключении основного питания RTC также перестает тикать. И даже если оставить lpm3, выключить питание когда активная мода (передача по UART) то часы останавливаются. Как выяснил lpm3, lpm2 включает Backup Supply, а lpm1, lpm0 не включает. То есть если выключить DCO (SCG1=1) то включается Backup Supply. Сейчас как временную затычку реализовал такой подход при работе с RTC: BAKCTL &= ~(BAKSW); while(BAKCTL & LOCKBAK) // Unlock Backup system for operation BAKCTL &= ~(LOCKBAK); ... // Read RTC registers BAKCTL |= (BAKSW); // Lock Backup system Понимаю, что это неправильно самому включать Backup Supply, и хоть и небольшой, но шанс попасть на выключение питания когда не в Backup Supply всеже остается. Поэтому хочется всеже разобраться. 1. Почему выключение DCO приводит к включению Backup Supply? В user manual и errata ничего такого не нашел. (но это так для общего развития) 2. Почему PMM не включает Backup Supply при выключении основного питания, хотя вроде все пороги настроены, и судя по описанию должен это делать? Мож кто с таким сталкивался разбирался, а мож из общих соображений и знания архитектуры чего подскажет. Заранее спасибо.

Да, это вы абсолютно точно поняли. И главная проблема здесь в том что в качестве С я не могу задать какую-то конкретную величину. Правильно ли я понял, что то к чему должна стремиться целевая функция, Вы предлагаете тоже использовать в качестве параметра оптимизации? Как говорится, все гениальное просто. Теперь удивляюсь почему самому не пришло такое на ум. Спасибо за подсказку, сейчас буду пробовать. У меня была идея считать кореляцию, между различными температурными точками, но как потом все это привязать к МНК для получения параметров у меня в голове так и не сложилось. Если под "сигналы достаточно частотно богаты" Вы имели в виду присутствие в них белого шума, то он там присутствует, местами даже больше чем хотелось бы http://electronix.ru/forum/style_images/1/...icons/icon1.gif В качестве эксперимента t можно менять и сигналы снимать хоть через градус, но в последствии при реальном производстве, температурных точек должно быть 4, в крайнем случае 5. Сейчас мне важно понять что данной цепочкой действительно можно скомпенсировать характеристику датчика.

Я намеренно не приводил здесь всю модель, т.к. на мой взгляд она не должна влиять на метод оптимизации. К тому же модель достаточно запутанная, берутся интерполированные значения для термокомпенсационных элементов из таблиц производителя для определенной температуры, все это подставляется в функцию, перемножается с показаниями датчика. Боюсь, если я тут все это изложу, то количество непонятного только увеличится. И с другой стороны, если я вдруг пойму, что у меня термокомпенсационная цепочка не совсем правильная и как-то поменяю целевую функцию в оптимизации, то что от этого должен измениться сам метод оптимизации? Для примера, сильно упрощенная модель. Если сможете предложить метод для нее, то для своей модели надеюсь я его смогу адаптировать. d(t)*(x1(t)*k1 + x2(t)*k2 + k3) -> Const d(t) - измеренный сигнал датчика от температуры x1(t) - значение 1-го термокомпенсационного элемента при температуре снятия показаний датчика (берется из одной таблицы) k1 - 1-ый оптимизируемый параметр x2(t) - значение 2-го термокомпенсационного элемента при температуре снятия показаний датчика (берется из другой таблицы) k2 - 2-ой оптимизируемый параметр k3 - 3-ий оптимизируемый параметр Оптимизация должна проводиться по критерию минимального отклонения значения функции во всех снятых температурных точках от какого-то константного значения. Константное значение не определено заранее. Т.е. идеальный график целевой функции это прямая параллльная оси температуры.

Здравствуйте уважаемые коллеги! Возникла не совсем стандартная оптимизационная задача. Нужно подобрать параметры некоей функции (линеаризирующей температурную характеристику датчика). F(t) -> Const То есть есть сигнал с датчика, измеренный при нескольких температурах. Есть таблица характеристик термокомпенсирующих элементов. И нужно подобрать параметры дополнительных элементов. Простейший вариант который пришел в голову и был реализован, вычисляется значение функции в какой-то температурной точке (Tconst). Затем берется сумма квадратов разностей между функцией и функцией в определенной температурной точке Sum((F(t) - F(Tconst)) Pow 2), и методом наименьших квадратов вычисляются параметры. Но результат сильно зависит от того, какая точка была взята за константную, при этом для разных датчиков получается сильно по-разному. Получается, что заранее выбранная константа это неправильно. То есть собственно задача: оптимизировать параметры чтобы выходное значение функции было максимально приближено к константе при том, что сама константа неопределена и может быть любой. Может есть какой готовый метод оптимизации, или может кто подскажет как это правильно математически выразить для МНК. Не знаю насколько прозрачно объяснил. Надеюсь кто в теме - поймет.

Ответил в мыло В этом направлении переговоры ведутся, тоже пока результатов нет. Но предпочтетельней тот вариант, что я написал.

Здравствуйте. Возникла проблема. Пытаюсь подобрать TFT модуль для нового переносного прибора. Основные параметры: - Industrial температурный диапазон (рабочая температура до -30С) !!! - 2.4 ... 3 дюйма видимая область, внешние габариты не более 50х70мм (не считая шлейфа) - не менее 128х128 точек, хотябы 16 цветов. Перерыв интернет и пообщавшись с поставщиками, выяснил несколько проблем: 1. Модулей с описанными характеристиками в принципе крайне мало. Почему-то модули с рабочей температурой до -30 в основном начинаются от 5 дюймов. 2. То что представлено у продавцов это как правило остатки от больших партий. У нас потребность около 5000шт в год. Такого количества у продавцов нет в принципе. И самое хреновое, что скорее всего выбранного модуля уже больше и не будет (не производятся). И даже если выбрать то что сейчас производится, то нет гарантии что оно будет производиться через год. Учитывая, что наши приборы проходят сертификацию, замена в последствии на другой модуль проблематична. 3. Минимальная партия, с которой готов связываться производитель, начинается от 10000. Это конечно на 2 года при нашей потребности, но ни наши подрядчики (кто собственно занимается комплектованием и сборкой) ни наше руководство не готовы держать несколько млн. руб. в качестве складских запасов. Кто что может посоветовать? Наверняка у когото есть успешный опыт аналогичных закупок. Нужен либо поставщик готовый гарантировать поставки модулей партиями 1-2т шт несколько раз в год в течении 3-4 лет, либо производитель готовый производить/продавать на аналогичных условиях. Как крайний вариант рассматривается AMOLED, но он слишком много кушает по сравнению с TFT, что при батарейном питании критично. Зато с температурным диапазоном у него все хорошо. Если есть аналогичный опыт закупок AMOLED, он тоже будет полезным. Заранее спасибо.