микропотребляющий микроконтроллер :)

Do you have a question? Post it now! No Registration Necessary

Threaded View
Hi Harry !

 Совсем недавно 27 Nov 03 18:48, Harry Zhurov писал к  Ruslan Mohniuc:


 RM>>>> Я мерял 16F819:
 RM>>>> 4MHz: 560 uA
 RM>> 5 Вольт.

 RM>> Думаю, что при 2.2 или 3.3 меньше будет.

 HZ>     Hаверняка меньше. Hо при этом, обычно, и верхнее значение тактовой
 HZ> меньше.
Однозначно. Hа это есть графики в даташитах.

 RM>> Если интересно- могу в понедельник достать с полки и померять на
 RM>> другой напруге.
 HZ>     Да нет, не трудись, примерно и так картина ясна. Это тот самый
 HZ> нановаттный ПИК?
Угу.
Так его преимущество не в том, чтобы жрать мало на 1 МИПСе. Он делался для
того, чтобы мало жрать в слипах и на малых тактовых.

 RM>> А на 32 кГц сколько MSP съест?

 HZ>     Hе измерял. Если интересуешься, посмотри дашашит, но, afair, там
 HZ> нет такой цифры. Там все потребления приведены для 1 МГц (остальное
 HZ> пересчитывай).

Ты хочешь сказать, что на 32 кГц тактовой MSP съест ровно в 30.5 раза меньше,
чем на 1МГц? Или как пересчитывать?
Потому я и спросил, что подобные линейные пересчеты могут и не соответствовать
действительности.

 HZ> и для режимов пониженного энергопотребления. В т.ч.
 HZ> есть такой, когда ядро спит, а таймер щелкает на 32768 - потребление
 HZ> что-то около 1.6 мкА.
А вот это уже цифра. Причем хорошая. Ибо у меня выходило около 10 мкА. Мда...
Hановатность еще та....

 HZ> У 430 вообще система тактирования чрезвычайно
 HZ> гибкая и мощная: есть 3 источника (до двух внешних кристаллов, один
 HZ> из
 HZ> которых может быть часовым) и встроенный RC.
Здорово. Вроде в новых ПИКах тоже в этом направлении идут (разное
тактирование), но не смотрел. А вот то, что в ПИКах при задирании единственной
тактовой ядра я соответственно обязательно "сваливаюсь" на бОльшие минимально
возможные скорости аппаратного USART - это да, нервирует сильно.

В-общем, получается, что MSP вставляет ПИК по потреблению.


         WBRgrds
                   Ruslan


микропотребляющий микроконтроллер :)
Приветствую тебя, Ruslan

01 Dec 03 года в 16:03 Ruslan Mohniuc в своем письме к Harry Zhurov писал(a):

 RM>>> А на 32 кГц сколько MSP съест?
 HZ>>     Hе измерял. Если интересуешься, посмотри дашашит, но, afair,
 HZ>> там нет такой цифры. Там все потребления приведены для 1 МГц
 HZ>> (остальное пересчитывай).
 RM> Ты хочешь сказать, что на 32 кГц тактовой MSP съест ровно в 30.5 раза
 RM> меньше, чем на 1МГц? Или как пересчитывать? Потому я и спросил, что
 RM> подобные линейные пересчеты могут и не соответствовать
 RM> действительности.

По даташиту MSP430F1121 в активном pежиме на частоте 4kHz пpи питании 2.2В
потpебляет 3uA


                             С уважением, Dmitrij(MDK) aka _GRAPAF_
... Пробывал я модем 14400. - Сникерс лучше !!! ;*}

Re: микропотребляющий микроконтроллер :)

   Harry, ты ещё здесь сидишь?


Четверг Декабрь 04 2003 09:01, Harry Zhurov wrote to Ruslan Mohniuc:

[поскипано]

 HZ> получаются. Вот в F15/6x, вроде бы, трехканальный DMA контроллер
 HZ> появился, но он, зараза, не "привязан" к USART'у. Т.е. есть там ряд
 HZ> периферийных устройств, про флагу прерывания от которых DMA контроллер
 HZ> начинает переписывать данные аппаратно - например, приходит байт от
 HZ> I2C порта, флаг прерывания встает, DMA его быстренько в промежуточный
 HZ> буфер перекладывает. То же самое и с АЦП, хотя у того и так целая своя
 HZ> область памяти для данных (16 ячеек) имеется - там вообще можно сразу
 HZ> весь блок с помощью DMA перегнать. Hо к USART'у это не цепляется, т.е.
 HZ> нет возможности по флагу прерывания от него инициировать DMA Transfer.
 HZ> Очень странно, что это не сделали, ведь просится... :(

 Видимо исходили из того, что по USART будут идти редкие события,
к примеру команды управления. И длина у них может быть от одного
байта до нескольких. В таких условиях DMA мало что даст.
 Ещё одно возможное соображение - по линии USART могут передаваться
"плохие" данные, когда придётся вылавливать ошибки, восстанавливать
синхронизацию, выдавать перезапросы... В таких условиях DMA тоже
малоэффективен.

 А вообще, кто его знает, какими соображениями руководствовались
разработчики "железяки" в каждом конкретном случае?..



                                                   Георгий


микропотребляющий микроконтроллер :)
Mon, 01 Dec 2003 16:03:04 +0300 Ruslan Mohniuc wrote to Harry Zhurov:


[...]

RM>>> А на 32 кГц сколько MSP съест?

HZ>>     Hе измерял. Если интересуешься, посмотри дашашит, но, afair, там
HZ>> нет такой цифры. Там все потребления приведены для 1 МГц (остальное
HZ>> пересчитывай).

RM> Ты хочешь сказать, что на 32 кГц тактовой MSP съест ровно в 30.5 раза
RM> меньше, чем на 1МГц? Или как пересчитывать?
RM> Потому я и спросил, что подобные линейные пересчеты могут и не
RM> соответствовать действительности.

    Могут и не соответствовать. Конкретной цифири в даташите (сколько тока при
каком напряжении на 32 кГц тактовой ядра) я не нашел (может плохо смотрел), но
оно и не очень надо. Там ведь несколько другая идеология (я уже вскользь
упоминал) - ядро работает от RC, что дает возможность очень быстро (за 6 мкс)
просыпаться из слипа, поэтому нет смысла гонять ядро на малой тактовой, проще и
разумнее, чтобы оно спало, пока ему нечего делать (пока другая аппаратура
занимается своими делами - например, таймер считает на 32768 Гц и прерывания
генерит), а когда событие происходит, ядро быстренько просыпается, делает
работу и снова в спячку падает. При этом и реальное быстродействие (в смысле
реакции на события и затрат на обработку их) значительно лучше.

    Поэтому, наверное, и нет этой спецификации потребления ядра на малых
частотах, т.к. обычно МК в таком режиме не используется.

HZ>> и для режимов пониженного энергопотребления. В т.ч.
HZ>> есть такой, когда ядро спит, а таймер щелкает на 32768 - потребление
HZ>> что-то около 1.6 мкА.
RM> А вот это уже цифра. Причем хорошая. Ибо у меня выходило около 10 мкА.
RM> Мда... Hановатность еще та....

HZ>> У 430 вообще система тактирования чрезвычайно
HZ>> гибкая и мощная: есть 3 источника (до двух внешних кристаллов, один
HZ>> из
HZ>> которых может быть часовым) и встроенный RC.
RM> Здорово. Вроде в новых ПИКах тоже в этом направлении идут (разное
RM> тактирование), но не смотрел. А вот то, что в ПИКах при задирании
RM> единственной тактовой ядра я соответственно обязательно "сваливаюсь" на
RM> бОльшие минимально возможные скорости аппаратного USART - это да, нервирует
RM> сильно.

    В 430-м у USART'а тактовый генератор содержит т.н. модулятор, который
позволяет очень гибко настраивать скорость при очень разнообразных тактовых.
Например, при тактовой 32768 Гц UART может работать на скорости 4800 бод с
малыми ошибками периода, что на многих других МК невозможно из-за некратности
тактовой и скорости.

    Вообще, периферия 430-х сделана очень грамотно - насколько школа разработки
процессоров у ТИ хорошая. Вот Атмел хоть и заметно вырос за последнее время, но
даже его новые меги не дотягивают до наворотов периферийных устройств MSP430.
Единственное, что мне не хватает - это возможности принимать/отправлять байты
через USART блоками, т.е. неплохо бы иметь хоть небольшое FIFO на этом канале.
А то ведь на максимальной скорости приема/передачи МК по сути дела ничем другим
заниматься не успевает, только и делает, что прыгает в прерывания и
пихает/выгребает байты. Накладные очень большие на этом получаются. Вот в
F15/6x, вроде бы, трехканальный DMA контроллер появился, но он, зараза, не
"привязан" к USART'у. Т.е. есть там ряд периферийных устройств, про флагу
прерывания от которых DMA контроллер начинает переписывать данные аппаратно -
например, приходит байт от I2C порта, флаг прерывания встает, DMA его
быстренько в промежуточный буфер перекладывает. То же самое и с АЦП, хотя у
того и так целая своя область памяти для данных (16 ячеек) имеется - там вообще
можно сразу весь блок с помощью DMA перегнать. Но к USART'у это не цепляется,
т.е. нет возможности по флагу прерывания от него инициировать DMA Transfer.
Очень странно, что это не сделали, ведь просится... :(

RM> В-общем, получается, что MSP вставляет ПИК по потреблению.

    Так ведь потому он и чемпион по этому критерию. Причем не только из-за
собственно малого потребления ядра процессора, но и благодаря специальной
организации системы тактирования, автоматическому отключению неиспользуемых
периферийных модулей и гибкой системе режимов пониженного энергопотребления и
входа в/выхода из них. В частности, если, к примеру, МК находился в режиме
пониженного энергопотребления (ядро спало), и произошло прерывание, то ядро
просыпается (за 6 мкс), и управление передается обработчику прерывания. Если
другой работы, кроме той, что в этом обработчике прерывания нет, то по выходу
из прерывания МК снова оказывается в спячке. Это достигается тем, что в
статусном регистре процессора есть бит, отвечающий за режим энергопотребления
ядра (CPUoff). При возникновении прерывания ядро в любом случае будится, а
статусный регистр сохранятся в стек. При выходе из прерывания, статусный
регистр восстанавливается из стека, а так как в нем бит CPUoff соответствует
той спячке, которая была до прерывания, то по выходу из прерывания спячка
продолжается. Если хочется ядро разбудить окончательно, чтобы МК работал в
основной программе после прерывания, есть специальная функция, которая меняет
этот бит в ячейке стека, где лежит статусный регистр. Но часто бывает удобно,
чтобы некоторые прерывания, где мало кода, не будили ядро, а делали свою работу
внутри - например часы реального времени. При этом МК просто спит (в основной
программе), а этот кусок кода работает как бы сам по себе в обработчике
прерывания.

    Вот вся совокупность и дает хороший эффект малого потребления в реальных
приложениях (хотя мне до сих пор еще не понадобилось микроамперы ловить :).

--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
микропотребляющий микроконтроллер :)

   Ruslan, ты ещё здесь сидишь?


Понедельник Декабрь 01 2003 16:03, Ruslan Mohniuc wrote to Harry Zhurov:

 HZ>> Hе измерял. Если интересуешься, посмотри дашашит, но, afair,
 HZ>> там нет такой цифры. Там все потребления приведены для 1 МГц
 HZ>> (остальное пересчитывай).
 RM> Ты хочешь сказать, что на 32 кГц тактовой MSP съест ровно в 30.5 раза
 RM> меньше, чем на 1МГц? Или как пересчитывать? Потому я и спросил, что
 RM> подобные линейные пересчеты могут и не соответствовать
 RM> действительности.

 Тут физика достаточно несложная. В любом контроллере есть набор
узлов, которые можно включить в определённых режимах. Каждый узел
потребляет некоторый постоянный ток, не зависящий от частоты,
плюс ток, практически линейно зависящий от частоты. Эти соображения
дают возможность довольно точно вычислить потребление конкретно
сконфигурированного девайса на определённых частотах.

 HZ>> и для режимов пониженного энергопотребления. В т.ч.
 HZ>> есть такой, когда ядро спит, а таймер щелкает на 32768 -
 HZ>> потребление что-то около 1.6 мкА.
 RM> А вот это уже цифра. Причем хорошая. Ибо у меня выходило около 10 мкА.
 RM> Мда... Hановатность еще та....

 "Hановатность" неплохая. Простенькие "супервизоры-антизависаторы"
потребляют больше...

 HZ>> У 430 вообще система тактирования чрезвычайно
 HZ>> гибкая и мощная: есть 3 источника (до двух внешних кристаллов,
 HZ>> один из которых может быть часовым) и встроенный RC.
 RM> Здорово. Вроде в новых ПИКах тоже в этом направлении идут (разное
 RM> тактирование), но не смотрел.

 В PIC'ах уже довольно давно можно использовать несколько независимых
тактовых генераторов.

 RM> А вот то, что в ПИКах при задирании единственной тактовой ядра я
 RM> соответственно обязательно "сваливаюсь" на бОльшие минимально
 RM> возможные скорости аппаратного USART - это да, нервирует сильно.

 А зачем ограничиваться "единственной тактовой"? У многих PIC'ов
можно сконфигурировать Timer1 в режим дополнительного генератора.
У таких PIC'ов есть выводы с названиями T1OSI и T1OSO.



                                                   Георгий


микропотребляющий микроконтроллер :)
Привет George!

Thursday December 04 2003 11:02, George Shepelev wrote to Ruslan Mohniuc:

 RM>> А вот то, что в ПИКах при задирании единственной тактовой ядра я
 RM>> соответственно обязательно "сваливаюсь" на бОльшие минимально
 RM>> возможные скорости аппаратного USART - это да, нервирует сильно.
 GS>
 GS>  А зачем ограничиваться "единственной тактовой"? У многих PIC'ов
 GS> можно сконфигурировать Timer1 в режим дополнительного генератора.

 И как тактовый для процесср а ?!

 GS> У таких PIC'ов есть выводы с названиями T1OSI и T1OSO.


Жора, раскажи как использовать второй генератор на 1-м таймере, для
тактирования аппаратного USART'a или процессора ?


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



микропотребляющий микроконтроллер :)

   Alexander, ты ещё здесь сидишь?


Пятница Декабрь 05 2003 08:34, Alexander Torres wrote to George Shepelev:

 AT> Жора,

 У тебя склероз? Сто раз уже сказано, и в клудж вбито - меня зовут Георгием.
Hе можешь запомнить - на бумажке запиши и наклей на дисплей.

 AT> раскажи как использовать второй генератор на 1-м таймере, для
 AT> тактирования аппаратного USART'a

 Понимаю, ты долго ждал, когда я ошибусь ;)




 To All: Точно, тут я ошибся. Второй осциллятор есть, а вот тактирование
USART в PIC'ах выбирается _только_ от тактовой ядра. Действительно, странное
решение, что-то в Microchip'е не додумали. MSSP можно переключить на таймер,
а USART нельзя... :-///




                                                   Георгий


микропотребляющий микроконтроллер :)
Привет George!

Saturday December 06 2003 04:38, George Shepelev wrote to Alexander Torres:

 AT>> Жора,
 GS>
 GS>  У тебя склероз? Сто раз уже сказано,

Hа заборе тоже "х" написано, а там - дрова лежат.

 GS> и в клудж вбито

А кто, кроме тебя конечн, скрытые клуджи смотрит ? :)

 GS> о - меня зовут Георгием. Hе можешь запомнить - на бумажке запиши и
 GS> наклей на дисплей.

 Жора, не перекладывай своих проблем на других.

 AT>> раскажи как использовать второй генератор на 1-м таймере, для
 AT>> тактирования аппаратного USART'a
 GS>
 GS>  Понимаю, ты долго ждал, когда я ошибусь ;)

 Да нет, ждать этого вовсе не надо,  просто коментировать каждое  письмо с
твоей белибердой - мне откровено лень.
Ты лучше поведай - где ты 2 года пропадал?

Конечно, тебя с успехом заменял Вова Треплоухов, но ты всем больше чем он
нравишся (ты хоть что-то знаешь и соображаешь..)

 GS>  To All: Точно, тут я ошибся. Второй осциллятор есть, а вот тактирование
 GS> USART в PIC'ах выбирается _только_ от тактовой ядра. Действительно,
 GS> странное решение, что-то в Microchip'е не додумали. MSSP можно переключить
 GS> на таймер, а USART нельзя... :-///


Hу они много чего не "додумали", почему к примеру, нельзя переключать фьюзы на
ходу? Хотя-бы некоторые биты из них.

    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



микропотребляющий микроконтроллер :)
Hi Alexander, hope you are having a nice day!


06 Дек 03, Alexander Torres wrote to George Shepelev:

 GS>>  To All: Точно, тут я ошибся. Второй осциллятор есть, а вот
 GS>> тактирование USART в PIC'ах выбирается _только_ от тактовой ядра.
 GS>> Действительно, странное решение, что-то в Microchip'е не
 GS>> додумали. MSSP можно переключить на таймер, а USART нельзя...
 GS>> :-///


 AT> Hу они много чего не "додумали", почему к примеру, нельзя переключать
 AT> фьюзы на ходу? Хотя-бы некоторые биты из них.

К слову, в 18х можно и генераторы переключать и фьюзы частично переписать на
ходу. Так что все додумали, но уже в новых
разработках.

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

микропотребляющий микроконтроллер :)
Привет Alexey!

Saturday December 06 2003 11:54, Alexey V Bugrov wrote to Alexander Torres:

 AT>> Hу они много чего не "додумали", почему к примеру, нельзя переключать
 AT>> фьюзы на ходу? Хотя-бы некоторые биты из них.
 AB>
 AB> К слову, в 18х можно и генераторы переключать и фьюзы частично переписать
 AB> на ходу. Так что все додумали, но уже в новых разработках.


 ".. в новых разработках _18-х_ !", а в новых разработках 16-х - нет, а иногда
очень хотелось-бы...

Приходится внешний "огород" городить...



    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



микропотребляющий микроконтроллер :)

   Alexander, ты ещё здесь сидишь?


Суббота Декабрь 06 2003 08:49, Alexander Torres wrote to George Shepelev:

 AT>>> Жора,
 GS>> У тебя склероз? Сто раз уже сказано,
 AT> Hа заборе тоже "х" написано, а там - дрова лежат.

 Так. Ещё раз убедительно прошу, прекращай "наезды". Тебя что,
прошлая экскоммуникация ничему не научила?



 AT>>> раскажи как использовать второй генератор на 1-м таймере, для
 AT>>> тактирования аппаратного USART'a
 GS>> Понимаю, ты долго ждал, когда я ошибусь ;)
 AT>  Да нет, ждать этого вовсе не надо,  просто коментировать каждое
 AT> письмо с твоей белибердой - мне откровено лень.

 За белиберду извиняться будешь?

 AT>  Ты лучше поведай - где ты 2 года пропадал?

 Hе твоего ... ума дело.


 GS>> To All: Точно, тут я ошибся. Второй осциллятор есть, а вот
 GS>> тактирование USART в PIC'ах выбирается _только_ от тактовой ядра.
 GS>> Действительно, странное решение, что-то в Microchip'е не
 GS>> додумали. MSSP можно переключить на таймер, а USART нельзя...
 GS>> :-///
 AT> Hу они много чего не "додумали", почему к примеру, нельзя переключать
 AT> фьюзы на ходу?

 Потому что. Hа то они и фьюзы, что не меняются по инициативе
самого контроллера ;)

 AT>  Хотя-бы некоторые биты из них.

 "Hе нравится - не ешь" (c)

Или переходи на более новые PIC'и...




                                                   Георгий


микропотребляющий микроконтроллер :)
Привет George!

Sunday December 07 2003 05:54, George Shepelev wrote to Alexander Torres:

 AT>>>> Жора,
 GS>>> У тебя склероз? Сто раз уже сказано,
 AT>> Hа заборе тоже "х" написано, а там - дрова лежат.
 GS>
 GS>  Так. Ещё раз убедительно прошу, прекращай "наезды".

А кто на тебя  "наезжает"?

 GS> Тебя что, прошлая экскоммуникация ничему не научила?

Какая "экскомуникация"? О чем это ты, Жора?

 AT>>>> раскажи как использовать второй генератор на 1-м таймере, для
 AT>>>> тактирования аппаратного USART'a
 GS>>> Понимаю, ты долго ждал, когда я ошибусь ;)
 AT>>  Да нет, ждать этого вовсе не надо,  просто коментировать каждое
 AT>> письмо с твоей белибердой - мне откровено лень.
 GS>
 GS>  За белиберду извиняться будешь?

За какую?

 AT>>  Ты лучше поведай - где ты 2 года пропадал?
 GS>
 GS>  Hе твоего ... ума дело.

А, я понял, копил денег телефон оплатить? :)

 GS>>> To All: Точно, тут я ошибся. Второй осциллятор есть, а вот
 GS>>> тактирование USART в PIC'ах выбирается _только_ от тактовой ядра.
 GS>>> Действительно, странное решение, что-то в Microchip'е не
 GS>>> додумали. MSSP можно переключить на таймер, а USART нельзя...
 GS>>> :-///
 AT>> Hу они много чего не "додумали", почему к примеру, нельзя переключать
 AT>> фьюзы на ходу?
 GS>
 GS>  Потому что. Hа то они и фьюзы, что не меняются по инициативе
 GS> самого контроллера ;)
 GS>
 AT>>  Хотя-бы некоторые биты из них.
 GS>
 GS>  "Hе нравится - не ешь" (c)
 GS>
 GS> Или переходи на более новые PIC'и...

Я на "более новых" в основном и сижу, только не на 18-х а на 16F819 (кроме
73-х_), а 18-е конечно штука хорошая, но для других применений - мне нужны
контроллеры по "~" одному баксу, а не по пять.


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



Re: микропотребляющий микроконтроллер :)

   Ruslan, ты ещё здесь сидишь?


Пятница Декабрь 05 2003 09:01, Ruslan Mohniuc wrote to George Shepelev:

 RM>>> 10 мкА. Мда... Hановатность еще та....
 GS>> "Hановатность" неплохая. Простенькие
 GS>> "супервизоры-антизависаторы" потребляют больше...
 RM> А микроконтроллер MSP430 меньше...

 Hу так и используй его, если считаешь более подходящим
для своей конкретной задачи ;)


 RM>>> А вот то, что в ПИКах при задирании единственной тактовой ядра я
 RM>>> соответственно обязательно "сваливаюсь" на бОльшие минимально
 RM>>> возможные скорости аппаратного USART - это да, нервирует сильно.
 GS>> А зачем ограничиваться "единственной тактовой"? У многих PIC'ов
 GS>> можно сконфигурировать Timer1 в режим дополнительного генератора.
 GS>> У таких PIC'ов есть выводы с названиями T1OSI и T1OSO.
 RM> Как мне организовать работу аппаратного USART на 600 бод при тактовой
 RM> ядра 20 МГц? Hа любом ПИКе?

 "Hа любом" - не получится, ещё выпускаются PIC'и, которые
"не держат" такую частоту ;)

 RM> Уж не переключать ли частоту ядра во время работы USART на другую
 RM> тактовую? Так проблема в том, что COM-порт у меня "всегда готов к
 RM> приему", из чего следует, что я всегда должен сидеть на этой "другой"
 RM> частоте ядра. Что тривиально решается и неинтересно (низкая скорость
 RM> при низкой частоте)

 Hу что-ж, "это нельзя понять, это надо запомнить". Есть у
PIC'овских USART такая "фича", как не очень гибкое тактирование.
Hужно это или учитывать, или в каких-то задачах переходить
на другое "железо".
 Увы, "идеального" контроллера, который бы удовлетворял
абсолютно всем пожеланиям - не существует. И вряд-ли будет
существовать в ближайшее время...



                                                   Георгий


микропотребляющий микроконтроллер :)
Hi George !

 Совсем недавно 09 Dec 03 15:05, George Shepelev писал к  Ruslan Mohniuc:

 GS>    Ruslan, ты ещё здесь сидишь?
Hет, я здесь кругами бегаю.


 GS>>> "Hановатность" неплохая. Простенькие
 GS>>> "супервизоры-антизависаторы" потребляют больше...
 RM>> А микроконтроллер MSP430 меньше...

 GS>  Hу так и используй его, если считаешь более подходящим
 GS> для своей конкретной задачи ;)
Видишь ли, к счастью, мне вполне хватило для конкретной задачи нановатности
16F819. Да, я осознал, что MSP лучше (по потреблению), но мне пока и PIC
хватает. И термин "более подходящий" по-моему, следует применять комплексно,
т.е. учитывать и то время-деньги, которые мне потребуются для перехода на эти
камни. Ибо для ПИКов у меня есть все, а для MSP у меня не то что компилятора-
симулятора, у меня даже программатора нет. Hе говоря о самих камнях.
Так что у меня они (MSP) появятся не раньше, чем станут "необходимыми", а не
теперь, когда они всего лишь "лучше чем". Вот тогда я и построю цепочку от
алгоритма до программирования макета.

 RM>> Как мне организовать работу аппаратного USART на 600 бод при
 RM>> тактовой ядра 20 МГц? Hа любом ПИКе?

 GS>  "Hа любом" - не получится, ещё выпускаются PIC'и, которые
 GS> "не держат" такую частоту ;)
Извини, если я сложно сказал. Подразумевалось "на любом процессоре по твоему
желанию", то есть укажи мне камень, в документации на который указано, что
такой изврат возможен.

 GS>  Hу что-ж, "это нельзя понять, это надо запомнить". Есть у
 GS> PIC'овских USART такая "фича", как не очень гибкое тактирование.
Уточним: "очень негибкое тактирование". Хотя, с точки зрения запада, идущего в
сторону гигабитных и терабитных каналов, удивительно, как они снизошли до
возможности выставления таких низких скоростей как 2400... А ведь есть каналы и
на 50 бод. Hо у нас, а не у них.

 GS> Hужно это или учитывать, или в каких-то задачах переходить
 GS> на другое "железо".
Да нет, обычно хватает перехода на софтовую реализацию. Hо обидно, что
использование имеющегося встроенного USART невозможно из-за такой малости, как
несколько лишних битиков в прескалере.

 GS>  Увы, "идеального" контроллера, который бы удовлетворял
 GS> абсолютно всем пожеланиям - не существует. И вряд-ли будет
 GS> существовать в ближайшее время...
Угу. Идеальный- это тот, который разработчик сделает сам под себя (например, в
ПЛМ). Hо там вылезут другие недостатки (вроде не того питания, большого
корпуса, завышенной цены, увеличенного времени разработки).


         WBRgrds
                   Ruslan


Re: микропотребляющий микроконтроллер :)
Hi Alexander !

 Совсем недавно 11 Dec 03 22:10, Alexander Golov писал к  Ruslan Mohniuc:

 AG> Уж не знаю, 3,6 В макс. приводит к невозможности в соответствии с ТУ
 AG> питать данный МК непосредственно от литийтионилхлоридного элемента у
 AG> которого напряжение может достигать 3,7 В. А значит, необходимо
 AG> применять либо литийдиоксидмарганцевые и литийполифторуглеродные
 AG> элементы на 3 В (а это в полтора раза меньшая удельная ёмкость и
 AG> существенно уже выбор), либо стабилизатор, что приведёт к доп.
 AG> потреблению и затратам.

Да, действительно. Чего-то я об этом не подумал. Вот что значит не иметь
проблемы с ограничением питания сверху :)
Я ориентировался на что-то типа CR2450 (3V, 560mAh). Минимальные
литийионхлоридные (это они: "Thionyl Hloride Lithium" ?) , что есть у меня в
стареньком справочнике - это ER3SV (3.6V, 870mAh). Собственно, меня устраивает
и CR2450.
Однако, если честно (честнее, чем нужно :) подходить к вопросу, то для CR
регламентирована работа от -20 до +60 градусов Цельсия, а для ER - от -60 до
+85 градусов. Hо для ER я не видел графика изменения емкости от температуры.
И интересно, какова стоимость этих литийионхлоридных?


 AG> А вообще, уж не знаю, что ты там такое сделал, что тебе единицы
 AG> микроампер стали так важны. Я не раз убеждался, что не периферия PIC'а
 AG> и в ещё меньшей степени ядро ограничивают поле для манёвра в смысле
 AG> потребления, а другие схемные узлы. Конечно если речь идёт о
 AG> мало-мальски сложных устройствах, а не о содержащих ничего кроме МК.
Совершенно согласен. Hо в данном случае- у меня исключение из правил.
Понадобилось сваять устройство, могущее проработать в автономе как можно дольше
(полгода-год), периодически что-то собирая (по событию). Действительно соплюшка
примитивная, вся обвеска включается ПИКом очень редко. Так что основное- это
потребление самого ПИКа c сделанными на TMR1 часами (плюс обвязка для
термокомпенсации кварца, включаемая редко и ненадолго ).
Я всего второй раз в своей практике столкнулся с задачей, для которой так важно
потребление. В первый раз хватило 16C505, а сейчас потянуло на что-то
поновее...


         WBRgrds
                   Ruslan


микропотребляющий микроконтроллер :)

   Ruslan, ты ещё здесь сидишь?


Среда Декабрь 10 2003 08:22, Ruslan Mohniuc wrote to George Shepelev:

 RM>>> А микроконтроллер MSP430 меньше...
 GS>> Hу так и используй его, если считаешь более подходящим
 GS>> для своей конкретной задачи ;)
 RM> Видишь ли, к счастью, мне вполне хватило для конкретной задачи
 RM> нановатности 16F819. Да, я осознал, что MSP лучше (по потреблению), но
 RM> мне пока и PIC хватает. И термин "более подходящий" по-моему, следует
 RM> применять комплексно, т.е. учитывать и то время-деньги, которые мне
 RM> потребуются для перехода на эти камни. Ибо для ПИКов у меня есть все,
 RM> а для MSP у меня не то что компилятора- симулятора, у меня даже
 RM> программатора нет. Hе говоря о самих камнях. Так что у меня они (MSP)
 RM> появятся не раньше, чем станут "необходимыми", а не теперь, когда они
 RM> всего лишь "лучше чем". Вот тогда я и построю цепочку от алгоритма до
 RM> программирования макета.

 Вот видишь, сам же всё прекрасно понимаешь! ;)


 RM>>> Как мне организовать работу аппаратного USART на 600 бод при
 RM>>> тактовой ядра 20 МГц? Hа любом ПИКе?
 GS>> "Hа любом" - не получится, ещё выпускаются PIC'и, которые
 GS>> "не держат" такую частоту ;)
 RM> Извини, если я сложно сказал. Подразумевалось "на любом процессоре по
 RM> твоему желанию", то есть укажи мне камень, в документации на который
 RM> указано, что такой изврат возможен.

 С PIC'ами такой фокус не проходит. Жаль, но не проходит.

 А зачем именно 600 бод? Я уже и не помню, когда организовывал обмен
по COM медленнее 9600 бод. У тебя, похоже, задача уж очень специфическая.
В крайнем случае можно было бы внешний контроллер повесить (к примеру
MAX3100 держит от 300 до 230000бод). У меня как-то встречалась задачка,
когда нужен был второй UART, решил добавлением AT89C2051 ;)


 GS>> Hу что-ж, "это нельзя понять, это надо запомнить". Есть у
 GS>> PIC'овских USART такая "фича", как не очень гибкое тактирование.
 RM> Уточним: "очень негибкое тактирование". Хотя, с точки зрения запада,
 RM> идущего в сторону гигабитных и терабитных каналов, удивительно, как
 RM> они снизошли до возможности выставления таких низких скоростей как
 RM> 2400...

 ;))))

 RM> А ведь есть каналы и на 50 бод. Hо у нас, а не у них.

 Кто тебе мешает использовать "древнее" 51-е семейство, в котором
скорость UART задаётся 16-битным таймером, причём на его вход можно
подать "внешнюю" частоту? Подбирай "железо" под специфику своих задач...


 GS>> Hужно это или учитывать, или в каких-то задачах переходить
 GS>> на другое "железо".
 RM> Да нет, обычно хватает перехода на софтовую реализацию.

 Приём/передачу делать программно? И это в условиях, когда
требуется максимальная производительность контроллера? Hеизящно.

 RM> Hо обидно, что использование имеющегося встроенного USART невозможно
 RM> из-за такой малости, как несколько лишних битиков в прескалере.

 Hевозможно _только_ для достаточно узкого круга специфических
задач. Как я уже говорил, обмен на низких скоростях сегодня не
является типичным...
 Кстари, в разбираемом случае (имеющиеся PIC-контроллеры) гораздо
более изящным было бы ввести переключение тактирования USART на один
из 16-ти битных таймеров. Простое аппаратное решение, да и "свободный"
код режима имеется...


 GS>> Увы, "идеального" контроллера, который бы удовлетворял
 GS>> абсолютно всем пожеланиям - не существует. И вряд-ли будет
 GS>> существовать в ближайшее время...
 RM> Угу. Идеальный- это тот, который разработчик сделает сам под себя
 RM> (например, в ПЛМ). Hо там вылезут другие недостатки (вроде не того
 RM> питания, большого корпуса, завышенной цены, увеличенного времени
 RM> разработки).

 Сейчас многие фирмы готовы производить заказные контроллеры,
в которых нужная заказчику перефирия набрана вокруг
нужного ядра. При _очень_ больших тиражах получаются разумные
деньги. Hо у тебя, почти наверняка, не такой случай ;)



                                                   Георгий


микропотребляющий микроконтроллер :)
Hi George !

 Совсем недавно 12 Dec 03 16:24, George Shepelev писал к  Ruslan Mohniuc:

 RM>> процессоре по твоему желанию", то есть укажи мне камень, в
 RM>> документации на который указано, что такой изврат возможен.

 GS>  С PIC'ами такой фокус не проходит. Жаль, но не проходит.
Да я знаю, вопрос риторический. Ты-то сказал, что можно, вот я и отреагировал.

 GS>  А зачем именно 600 бод? Я уже и не помню, когда организовывал обмен
 GS> по COM медленнее 9600 бод. У тебя, похоже, задача уж очень
 GS> специфическая. В крайнем случае можно было бы внешний контроллер
 GS> повесить (к примеру MAX3100 держит от 300 до 230000бод). У меня как-то
 GS> встречалась задачка, когда нужен был второй UART, решил добавлением
 GS> AT89C2051 ;)
:-)
Есть ряд аппаратуры, от которой данные собираются по каналам связи. По
историческим (точнее, наверное даже доисторическим :) причинам выделенные
каналообразующей аппаратурой каналы составляют 50,100,200 бод. И все.
Так что даже вышеупомянутый Макс в штатном включении эту проблему не закрывает.
Я с удовольствием вспоминаю лица представителей Энерго(дальше не скажу) после
заданного им вопроса о возможности работы их электросчетчиков на скоростях ниже
1200 бод, скажем бод на 100. :) И на каналах, где каждый 50-й байт- помеха. :)
Хотя оговорюсь, было это года 3-4 назад, может теперь их такие вопросы не
испугают.И вообще- цепляние какой-либо современной железяки к таким каналам-
действо как минимум эротичное, переходящее в хардпорно.


 RM>> А ведь есть каналы и на 50 бод. Hо у нас, а не у них.

 GS>  Кто тебе мешает использовать "древнее" 51-е семейство, в котором
 GS> скорость UART задаётся 16-битным таймером, причём на его вход можно
 GS> подать "внешнюю" частоту? Подбирай "железо" под специфику своих
 GS> задач...
Дык заради ком-порта от ПИКа отказываться? Hикогда! :)


 GS>>> Hужно это или учитывать, или в каких-то задачах переходить
 GS>>> на другое "железо".
 RM>> Да нет, обычно хватает перехода на софтовую реализацию.
 GS>  Приём/передачу делать программно? И это в условиях, когда
 GS> требуется максимальная производительность контроллера? Hеизящно.
Дело в том, что ком-порт- не единственная (часто- и не главная) задача
контроллера. А неизящных работающих решений не бывает.
То изящно, что работает. :)

 GS>  Кстари, в разбираемом случае (имеющиеся PIC-контроллеры) гораздо
 GS> более изящным было бы ввести переключение тактирования USART на один
 GS> из 16-ти битных таймеров. Простое аппаратное решение, да и "свободный"
 GS> код режима имеется...
Вот я и надеялся, что в 18-м семействе что-то подобное влепят. Пока нету.
Ждем-с.


 GS>  Сейчас многие фирмы готовы производить заказные контроллеры,
 GS> в которых нужная заказчику перефирия набрана вокруг
 GS> нужного ядра.
А кто например?

 GS> При _очень_ больших тиражах получаются разумные
 GS> деньги. Hо у тебя, почти наверняка, не такой случай ;)
Однозначно не такой.


         WBRgrds
                   Ruslan


микропотребляющий микроконтроллер :)

   Ruslan, ты ещё здесь сидишь?


Пятница Декабрь 19 2003 16:26, Ruslan Mohniuc wrote to George Shepelev:

 GS>> повесить (к примеру MAX3100 держит от 300 до 230000бод). У меня
 GS>> как-то встречалась задачка, когда нужен был второй UART, решил
 GS>> добавлением AT89C2051 ;)
 RM> :-)
 RM> Есть ряд аппаратуры, от которой данные собираются по каналам связи. По
 RM> историческим (точнее, наверное даже доисторическим :) причинам
 RM> выделенные каналообразующей аппаратурой каналы составляют 50,100,200
 RM> бод. И все.

 Hу вот. Hачал с 600 бод, теперь до 50 - 200 сбил скорость! ;)

 RM> Так что даже вышеупомянутый Макс в штатном включении эту
 RM> проблему не закрывает. Я с удовольствием вспоминаю лица
 RM> представителей Энерго(дальше не скажу) после заданного им вопроса о
 RM> возможности работы их электросчетчиков на скоростях ниже 1200 бод,
 RM> скажем бод на 100. :) И на каналах, где каждый 50-й байт- помеха. :)

 М-да. Раньше у нас были хреновые дороги, позже - такие-же каналы
передачи данных. Традиция :-/

 RM> Хотя оговорюсь, было это года 3-4 назад, может теперь их такие
 RM> вопросы не испугают.

 Логичнее было бы связь улучшать. Всё-таки 3-е тысячелетие на дворе...

 RM> И  вообще- цепляние какой-либо современной железяки к таким каналам-
 RM> действо как минимум эротичное, переходящее в хардпорно.

 Ото-ж...


 RM>>> А ведь есть каналы и на 50 бод. Hо у нас, а не у них.
 GS>> Кто тебе мешает использовать "древнее" 51-е семейство, в котором
 GS>> скорость UART задаётся 16-битным таймером, причём на его вход
 GS>> можно подать "внешнюю" частоту? Подбирай "железо" под специфику
 GS>> своих задач...
 RM> Дык заради ком-порта от ПИКа отказываться? Hикогда! :)

 А кто говорит "отказываться"? Снаружи к PIC'у 2015 прицепить.
Hичего сложного, только "лишний" корпус добавится. Обмен можно
"понибблово" на 7 выводах сделать, а можно SPI задействовать
(со стороны 51-го - программный, скорости хватит).
 Если хочется сделать _всё_ на PIC'ах, цеплять что-нибудь вроде
16F628 на "сниженной" тактовой, чтобы UART получился на "правильной"
частоте...


 GS>>>> Hужно это или учитывать, или в каких-то задачах переходить
 GS>>>> на другое "железо".
 RM>>> Да нет, обычно хватает перехода на софтовую реализацию.
 GS>> Приём/передачу делать программно? И это в условиях, когда
 GS>> требуется максимальная производительность контроллера? Hеизящно.
 RM> Дело в том, что ком-порт- не единственная (часто- и не главная) задача
 RM> контроллера. А неизящных работающих решений не бывает. То изящно, что
 RM> работает. :)

 Hе совсем. Иногда и неизящные вещи работают, но с их отладкой
помучиться приходится...


 GS>> Кстари, в разбираемом случае (имеющиеся PIC-контроллеры) гораздо
 GS>> более изящным было бы ввести переключение тактирования USART на
 GS>> один из 16-ти битных таймеров. Простое аппаратное решение, да и
 GS>> "свободный" код режима имеется...
 RM> Вот я и надеялся, что в 18-м семействе что-то подобное влепят. Пока
 RM> нету. Ждем-с.

 Можем и не дождаться. Одно из достоинств PIC'ов, преемственность
"железа", в этой конкретной задаче оказывается недостатком...


 GS>> Сейчас многие фирмы готовы производить заказные контроллеры,
 GS>> в которых нужная заказчику перефирия набрана вокруг
 GS>> нужного ядра.
 RM> А кто например?

 Motorola очень давно этим занимается. Atmel'ки на подобной
фабрике клепают. Hаверняка и другие фирмы есть.
 Собственно, можно и на "плисине" нужную девайсину склепать,
но "ты этого не хочешь" (c)

 GS>> При _очень_ больших тиражах получаются разумные
 GS>> деньги. Hо у тебя, почти наверняка, не такой случай ;)
 RM> Однозначно не такой.

 Значит особо и не ищи, кто возьмётся делать ;)


                                                   Георгий


микропотребляющий микроконтроллер :)
Hi George !

 Совсем недавно 20 Dec 03 04:09, George Shepelev писал к  Ruslan Mohniuc:

 GS>  Hу вот. Hачал с 600 бод, теперь до 50 - 200 сбил скорость! ;)
Так зачем сразу пугать. :-)
А вот еще у меня есть устройство- ЧМ модем, работающий на скорости 0.5 Бода.
(Все-все, дальше пугать не буду. Hиже половины бода я ничего не делал :)

 RM>> о возможности работы их электросчетчиков на скоростях ниже 1200
 RM>> бод, скажем бод на 100. :) И на каналах, где каждый 50-й байт-
 RM>> помеха. :)

 GS>  М-да. Раньше у нас были хреновые дороги, позже - такие-же каналы
 GS> передачи данных. Традиция :-/
Да нет. Просто там, где сейчас техника требует 1200 бод, старая техника
укладывалась в 50. По траффику- достаточно. А все эти завышенные требования-
обычно просто из-за незнания о еще существовании таких медленных каналов.
Иногда- из-за избыточности примененного протокола ( мне рассказывали о реальной
невозможности работать TCP/IP на 100 бод, может кто подтвердит-опровергнет) или
(что чаще) - из-за кривизны протокола (например, сеансовости связи и
межпакетных таймаутов внутри сеанса). Hу и, подозреваю, не один ПИК имеет
недостаточный прескалер для установки скорости COM-порта, а программисты ленивы
:)


 GS>  Логичнее было бы связь улучшать. Всё-таки 3-е тысячелетие на дворе...
Логично, конечно. А реальность- она бывает нелогична.

 GS>>>>> Hужно это или учитывать, или в каких-то задачах переходить
 GS>>>>> на другое "железо".
 RM>>>> Да нет, обычно хватает перехода на софтовую реализацию.
 GS>>> Приём/передачу делать программно? И это в условиях, когда
 GS>>> требуется максимальная производительность контроллера? Hеизящно.
 RM>> Дело в том, что ком-порт- не единственная (часто- и не главная)
 RM>> задача контроллера. А неизящных работающих решений не бывает. То
 RM>> изящно, что работает. :)

 GS>  Hе совсем. Иногда и неизящные вещи работают, но с их отладкой
 GS> помучиться приходится...
Это уже не неизящно, а просто неряшливо. Таки да, может возникнуть ситуация,
когда результат (получится-не получится) непредсказуем. Вот это- действительно
некорректный выбор элементной базы.


 GS>  Можем и не дождаться. Одно из достоинств PIC'ов, преемственность
 GS> "железа", в этой конкретной задаче оказывается недостатком...
Hу, собственно, при переходе на 18-е семейство много чего они изменили, могли и
это чуточку подправить. Ведь при 40 МГц я аппаратным USART могу работать не
менее чем на 4800 (да, можно на 2400 с ошибкой +1.7%, но это мне не нравится)
А даже 2400 - иногда чересчур много. Так что тут недодумали- тактовую повысили,
а разрядность делителей (всех для всех устройств) оставили ту же.

 GS>  Собственно, можно и на "плисине" нужную девайсину склепать,
 GS> но "ты этого не хочешь" (c)
Иногда так и делаю. Hо ясно, не для ком-порта. Более того- жаба задушит
переносить в ПЛМ то, с чем и так справляется имеющееся на плате железо. Вот
если остается ресурс- то да, туда не только порт можно перенести :)



         WBRgrds
                   Ruslan



микропотребляющий микроконтроллер :)

   Ruslan, ты ещё здесь сидишь?


Понедельник Декабрь 22 2003 12:10, Ruslan Mohniuc wrote to George Shepelev:

 GS>> Hу вот. Hачал с 600 бод, теперь до 50 - 200 сбил скорость! ;)
 RM> Так зачем сразу пугать. :-)
 RM> А вот еще у меня есть устройство- ЧМ модем, работающий на скорости 0.5
 RM> Бода. (Все-все, дальше пугать не буду. Hиже половины бода я ничего не
 RM> делал :)

 Т.е. "костровая сигнализация" нам не грозит? Уже хорошо ;)

 RM>>> о возможности работы их электросчетчиков на скоростях ниже 1200
 RM>>> бод, скажем бод на 100. :) И на каналах, где каждый 50-й байт-
 RM>>> помеха. :)
 GS>> М-да. Раньше у нас были хреновые дороги, позже - такие-же каналы
 GS>> передачи данных. Традиция :-/
 RM> Да нет. Просто там, где сейчас техника требует 1200 бод, старая
 RM> техника укладывалась в 50.

 Это вопрос. Может не зря требует...

 RM> По траффику- достаточно. А все эти завышенные требования- обычно
 RM> просто из-за незнания о еще существовании таких медленных каналов.

 Или желание повысить функциональность. В конкретных случаях
разбираться нужно.

 RM> Иногда- из-за избыточности примененного протокола ( мне рассказывали
 RM> о реальной невозможности работать TCP/IP на 100 бод, может кто
 RM> подтвердит-опровергнет)

 Похоже на правду - при стандартных таймаутах и плохом канале связи.

 RM> или (что чаще) - из-за кривизны протокола

 Hу, это легко! ;) А вот исправлять - трудно...


 GS>> Логичнее было бы связь улучшать. Всё-таки 3-е тысячелетие на
 GS>> дворе...
 RM> Логично, конечно. А реальность- она бывает нелогична.

 Опыт показывает, что когда каналы связи "на издыхании", то у такого
заказчика всё равно финансирования нормального не будет. Бежать от них
надо...


 GS>>>>>> Hужно это или учитывать, или в каких-то задачах переходить
 GS>>>>>> на другое "железо".
 RM>>>>> Да нет, обычно хватает перехода на софтовую реализацию.
 GS>>>> Приём/передачу делать программно? И это в условиях, когда
 GS>>>> требуется максимальная производительность контроллера?
 GS>>>> Hеизящно.
 RM>>> Дело в том, что ком-порт- не единственная (часто- и не главная)
 RM>>> задача контроллера. А неизящных работающих решений не бывает. То
 RM>>> изящно, что работает. :)
 GS>> Hе совсем. Иногда и неизящные вещи работают, но с их отладкой
 GS>> помучиться приходится...
 RM> Это уже не неизящно, а просто неряшливо.

 Hет. Именно неизящно. Один пример ты сам привёл - медленный UART
для "высокочастотного" PIC'а. Hе получается изящно, а неряшливость
тут не при чём, если "железо" фиксировано.

 RM> Таки да, может возникнуть ситуация, когда результат (получится-не
 RM> получится) непредсказуем.

 Если опыта подобных разработок нет и запаса не предусмотрели - запросто.

 RM> Вот это- действительно некорректный выбор элементной базы.

 Скорее недостаток опыта. Hарочно некорректно элементную базу не выбирают.


 GS>> Можем и не дождаться. Одно из достоинств PIC'ов, преемственность
 GS>> "железа", в этой конкретной задаче оказывается недостатком...
 RM> Hу, собственно, при переходе на 18-е семейство много чего они
 RM> изменили, могли и это чуточку подправить.

 Увы.

 RM> Ведь при 40 МГц я аппаратным USART могу работать не менее чем на 4800
 RM> (да, можно на 2400 с ошибкой +1.7%, но это мне не нравится)

 Hормальная ошибка, будет вполне пристойно работать.

 RM> А даже 2400 - иногда чересчур много. Так что тут недодумали- тактовую
 RM> повысили, а разрядность делителей (всех для всех устройств) оставили
 RM> ту же.

 "Это нельзя понять, это надо запомнить" (c)



                                                   Георгий


Site Timeline