Форум РадиоКот

Сейчас задумал небольшой проект, в нем много чего будет, память меги 16 заполнится процентов так на 90, не меньше. Будут 1wire i2c все три прерывания задействованы, + жк, символьный, но возможно прикручу графический от мобильника.

Мысли вот о чем: есть ли смысл даже для небольших проектов тактовать мк на пределе возможностей - для данного мк это 16 мегагерц. Как посчитать, на какой частоте мк будет без тормозов справляться с какой-либо задачей. И что принципиально менятся с повышением частоты, кроме роста энергопотребления? Мк по идее должен сильнее изнашиваться, тогда как оценить его ресурс на разных частотах?

megasvintus писал(а): Как посчитать, на какой частоте мк будет без тормозов справляться с какой-либо задачей.

Чтоб посчитать нужно УМИЩЕ офигительный. Проще запустить прогу и убедится что она нормально колбасится в самых стремных местах

megasvintus писал(а): что принципиально менятся с повышением частоты, кроме роста энергопотребления?

А вы ПОДУМАЙТЕ чуток ...

megasvintus писал(а): как оценить его ресурс на разных частотах?

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

Так я спрашиваю что меняется потому что не знаю, а отвечать на вопросы-"подумай чуток", это не дело! :)))

За остальные ответы спасибо! :))

Про износ: изнашиваются любые полупроводники. Ресурс огромен в смысле количества переключений, но не бесконечен. Можно ли надеяться что какое-то устройство на мк, от которого требуется надежность, работая на предельной часторе уверенно прослужит годы. Естественно если мк будет работать "в режиме"- я вкладываю в это понятие- без перегрузок электрических и механических температурных. Короче в пределах, оговоренных производителем.

megasvintus писал(а): а отвечать на вопросы-"подумай чуток", это не дело!

А я и не отвечал. я ПРЕДЛОЖИЛ вам подумать - это полезно.
Еслибы я думал что вы знаете и забыли то посоветовал бы вспомнить.

megasvintus писал(а): Можно ли надеяться

Да.

Сейчас задумал небольшой проект, в нем много чего будет, память меги 16 заполнится процентов так на 90, не меньше. Будут 1wire i2c все три прерывания задействованы, + жк, символьный, но возможно прикручу графический от мобильника.

скорость и2ц максимум 400кГц (если память не изменяет)
на 1вайр можно повесить часы или датчики или и то и другое, но сам интерфейс медленный примерно 64кГц.... если будете часто опрашивать то, то что висит на и2ц может медленно обрабатываться...
screen от мобильника достаточно быстр... но опять же в подряд к примеру опрашивать датчики потом выводить букву потом опрашивать датчики имхо медленновато будет...
если вы будете делать кнопки, то что-то у вас точно будет логать... или вам придётся делать внешнюю защиту от дребезга контактов...

вопрос: а схему можно посмотреть?? а то я так придумал всё за вас...

з.ы. имхо критического ничего нет... если не требует еже микросекундного обрабатывания...

Вы правы, надо описать подробнее. Схемы как таковой целиком нет, пока разрабатываю и тестирую блоки по отдельности. На i2c будут висеть максимум 5 устройств с предельной чатотой 100 килогерц. МОЖЕТ БЫТЬ по этой же шине свяжу на небольшой скорости пару блоков на мк. Не исключаю такой потребности. Подумываю все устройства с интерфейсом 1wire упразднить, и заменить аналогами, использующими i2c(больше нравится эта шина)- Речь идет о термометрах конторы даллас. Прерывания будут использоваться для управления этим всем с пульта ду на rc-5, и для датчиков, с не очень частым срабатыванием. Больше всего в ПО будет жрать ресурсов такая веселая функция как sprintf. Только на нее одну уходит около 1000 слов при компиляции, это порядка 30% памяти вышеуказанного мк. Будет клавиатурка, кнопок на 10. Возможно так же будет 3-4 разрядный сегментный индикатор с динамической индикацией в дополнение к ЖК-шкам.

Больше всего в ПО будет жрать ресурсов такая веселая функция как sprintf. Только на нее одну уходит около 1000 слов при компиляции, это порядка 30% памяти вышеуказанного мк

в студию функцию!!!
если и так пойдёт то вам не хватит вообще ресурсов!!

temp=ds18b20_temperature(&rom_code[0][0]); /*Занесение в переменную temp значение температуры , первый 0 это нулевой эл. массива. Для датчика 1*/
sign='+';
if (temp>200)
{
sign='-';
temp=(4096-temp); /
};

sprintf(lcd_buffer," Teјѕ = %c%3.1f\xdfC",sign,temp);

После компиляции:
Program size: 2773 words (33,9% of FLASH)

Программа всего лишь опрашивает 1 DS18b20 и показывает темп на симлольном жк.

с 1000 слов ошибся. Давно уже писал. Это в другом проекте, где кроме вывода на ЖК переменной ничего более нет там 1000 слов

Кстати про защиту от дребезга: Я поступаю хитрее- мк после обнаружения лог.0 не отрабатывает тупо задержку, а отправляется дальше по своим делам, как n- раз исполнит код всей программы- проверит- если кнопка все еще нажата, тогда реагирует на нее. Для человека эти сотые доли секунды ничего не значат, а мк много чего может успеть. Количество проходов кода легчайшим образом можно изменить в зависимости от скорости его обработки.

Кстати про защиту от дребезга: Я поступаю хитрее- мк после обнаружения лог.0 не отрабатывает тупо задержку, а отправляется дальше по своим делам, как n- раз исполнит код всей программы- проверит- если кнопка все еще нажата, тогда реагирует на нее. Для человека эти сотые доли секунды ничего не значат, а мк много чего может успеть. Количество проходов кода легчайшим образом можно изменить в зависимости от скорости его обработки.

гений ага... это известный приём... но мне интересно тогда другое, сколько раз в секунду ты(вы) будешь опрашивать клаву??... а если у тебя прога где-нить зависнет???... интересно...

Mozart писал(а): а если у тебя прога где-нить зависнет ???...

Если прога зависает, то ИМХО плевать как хорошо и как часто она опрашивает книпки.

Ее полюбому ПРАВИТЬ надо !

megasvintus писал(а): Program size: 2773 words (33,9% of FLASH)

Это "вступительный взнос" за удобство от использования sprintf

Вы же можете "ручками" вывести все как вам надо без этой функции.

Ручками выводить значения переменных? Это, пардон, как осуществить без функции sprintf?

Кстати про такой способ подавления дребезга я ни у кого не узнавал. Сам догадался так сделать. Ведь только постигаю азы МК и Сей. Так что, не надо язвить! :))

По моему скоромному мнению опрашивать клавиатуру чаще одного прохода всей программы по кругу незачем. Особенно если вкатить 16Mhz.

Кстати, попутный вопрос: Можно ли мк в случае крайней надобности подразогнать, мегагерц так до 20, до какой частоты он будет стабильно работать. У кого-нибудь есть данные?

megasvintus писал(а):Ручками выводить значения переменных? Это, пардон, как осуществить без функции sprintf?

Ну например так, побайтно:

Код: Выделить всё

        
UDR=data;
while (!(UCSRA &(1<<TXC)));
UCSRA |= (1<<TXC);

Не, я лучше возьму мк с памятью побольше! Уж очень нравится эта функция!

megasvintus писал(а):Ручками выводить значения переменных? Это, пардон, как осуществить без функции sprintf ?

Способы вывода данных в UART в задачах 4 и 5 описаны в домашней страничке моей и В ДАТАШИТе примеры обычно даны на Си и на АСМ.

megasvintus писал(а):Не, я лучше возьму мк с памятью побольше!

Я так и советую начинающим - учиться надо с комфортом и ...

megasvintus писал(а):Уж очень нравится эта функция !

... и с удовольствием !

Читал! Понятно написано. Но UART пока не интересует. А ЖК кстати не работает с функцией printf...

Можно ли мк в случае крайней надобности подразогнать, мегагерц так до 20

у AtMega168 макс 20 мГц

Как посчитать, на какой частоте мк будет без тормозов справляться с какой-либо задачей

пиши на асемблере, там будит видно

Ага, на ассемблере 5-6 тысяч кодовых слов. Будет весьма весело, когда отфигачишь в поте лица на асме здоооооровую программу, и окажется чтобы завершить ее, не хватает процентов 5 памяти контроллера. А на другой не портируешь... Вот это будет секаса, насяльника... :)))

Вы еще предложите сразу HEX писать! :)))

ЗЫ. давайте воздержимся от религиозных войн, вроде асм vs Си, авр и пик... :)))

Форум РадиоКот

Про быстродействие AVR-ок и нужно ли оно так.

Про быстродействие AVR-ок и нужно ли оно так.

Re: Про быстродействие AVR-ок и нужно ли оно так.