Перейти к содержанию
    

NikolyaN

Участник
  • Постов

    20
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о NikolyaN

  • Звание
    Участник
    Участник

Посетители профиля

1 815 просмотров профиля
  1. И судя по всему никто не делает :laughing: Или это большой секрет?
  2. Просто по параметрам очень похож, правда нагреватель там не платиновый. А название у этого "российского сенсора" есть? Или хотя бы кто делает?
  3. И еще у человека был вопрос а можно ли вообще так делать. Вот я и предупредил человека, чтобы у него не возникло других глюков. А в зависимости от критичности его приложения пусть сам решает, стоит ему так делать или нет. Я у себя так делать не стал, хотя тестирование показало, что все замечательно переписывается много-много раз и ничего не портится.
  4. Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок. И если суммарное время этих записей превысит tCPT то может произойти большой облом - похерится не только что он пытается записать, но и то что было записано до этого. Хотя я экспериментировал и не смог такого добиться даже переписывая по одному биту меняя из 1 в 0 весь блок. Но флэшь имеет свойство стареть, и при разных температурах результаты могут отличаться. А потом я просто дал человеку совет как сделать это просто и надежно, и не превышать это время. Теперь подумайте, что будет если сделать так как посоветовали вы, если после стирания флэша произойдет какой-то сбой. Вы останетесь без настроек :-). В моем варианте в случае сбоя у вас останутся хотя бы старые настройки. А вот с этим по моему большие проблемы, потому что когда пишется флэш все остальное стопорится (наверняка утверждать не буду, но по экспериментам мне так показалось).
  5. Тут пришел Ржевский и все опошлил :-) В свое время тоже реализовывал подобную задачу. И байтики можно дописывать и в байтиках битики менять с 1 на 0. И все это замечательно работало. Но от использования в коммерческом проекте меня остановил один абзац в SLAU208: То есть, как я понимаю это дело. Есть какое-то накапливающееся время подачи программирующего напряжения. При каждой записи байта/слова это время увеличивается. И если оно превысило tCPT (можно посмотреть в даташите на кристалл) то результат становится непредсказуемым. В итоге было реализовано поочередная запись в 2 сегмента. В сегменте выделен специальный байт в качестве флага. Сначала этот флаг ставится в состояние что данные устарели, потом новые настройки пишутся в другой сегмент, проверяется правильность записи и только потом сегмент со старыми настройками стирается.
  6. Добрый день! Чтобы прерывания происходили их надо разрешить в этой сторочке TBCTL=MC_2+TBSSEL_1+TBCLR+TBIFG Вместо TBIFG нужно поставить бит TBIE И описание прерывания немного по другому выглядит, потому что у таймера В 2 прерывания (хотя может для какого-то кристалла может быть и так, как у вас) #pragma vector=TIMER0_B0_VECTOR __interrupt void TIMER0_B0_ISR(void) Удачи в изысканиях :-)
  7. Дополню то что написал Василий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ххх семейства.
  8. RTC_B & Backup Supply

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

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

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

    Тут не совсем понятно чему равен 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); Удачи
  12. RTC_B & Backup Supply

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

    А из описания 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.
  14. RTC_B & Backup 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 при выключении основного питания, хотя вроде все пороги настроены, и судя по описанию должен это делать? Мож кто с таким сталкивался разбирался, а мож из общих соображений и знания архитектуры чего подскажет. Заранее спасибо.
×
×
  • Создать...