[lasers_Ryazanec]

Он и не собирается спать, отучил я его от этого кнопку человек попросил отключить, я и сделал напрямую всё Да, индикация не сразу, пока идет цыкл он только отображает индикацию так и задумывалось (ставка делалась на плавность анимации, при работе с аккумулятором скорость не нужна, он не будет просаживаться на 0,5 вольта каждые 2 секунды), аккумулятор мгновенно не садится, с этим и расчитвал. С кодом не возился, там неоптимизировано всё, просто идет код, стоит написать пару функций и количество кода уменьшится как минимум в 2 раза но там 85 тинька - экономить на чем? К тому же я поставил компилировать учитывая быстродействие, а не количество кода .
А вот вспышка при переходе с режима на режим... хм... надо посмотреть, откуда она берется.

(сейчас повалит критика)

Критиковать в данном случае нужно меня, я автор, так как это просто чуть подправленная прошивка, первая моя в жизни прошивка Если кину исходный код сюда, меня вообще тухлыми помидорами закидают, там всё на if ах и for ах написано, а шим генерируется на сонове библиотеки dalay.h , отсюда и низкая частота шима... но индикатора достаточно что бы нажав на кнопку увидеть что с аккумулятором кнопку выкинул вместе с засыпанием, в этом случае ему спать и незачем, если микроконтроллер выключается в момент когда нет индикации.
Давайте еще батарейку дюрасел вспомним с индикатором заряда из фольги, которую током разогревает до 80 градусов, и жрет тот индикатор под 100 милиампер

А эта схема хоть и не идеально, но работает, и со своей задачей справляется

[lasers_INFERION]

Дык а при чём кнопка к слипу? Слип в данном случае даёт две вещи:
- МК меньше жрёт, т.е. он уходит в спячку после выполнения действительно необходимой работы, до возникновения следующего события, требующего обработки. Чтоб обработать тот же светик, скажем с частотой в 1кГц, необходимо потратить явно не 8000000/1000=8000 тактов. Справится можно и за 1-2 десятка тактов (даже с программной модуляцией всех светиков), и дальше снова жрать 0,2мА (и-то в основном ИОН'ом). Зачем экономить? на АЦП меньше помех, проще фильтровать само питание МК. Можно, к примеру, втулить на его Vcc резистор на 100 Ом, тогда и переполюсовка чипу будет не страшна. Да и жрать индикатор в целом будет боле чем в 2 раза меньше.
- Второй момент, это освобождённый от неблагодарной работы АЛУ, который может в свободное время делать что-то другое, пока за него считает таймер...

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

[lasers_Ryazanec]

 Сообщение от INFERION :

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

Именно по этому я и не стал реагировать мгновенно. Делал еще лдно устройство, на заказ, там было плавное перетикание, вот там, то и было мгновенное реагирование, так как оттенок легко прослеживался.

Я не думаю, что индикатор всё время включен будет, пока работает устройство, я так понимаю, предполагается проверять заряд время от времени подключая его к аккумулятору.

на АЦП меньше помех, проще фильтровать само питание МК

когда МК просыпается, эти помехи обычно и бывают, нужно выждать время, пока он окончательно не проснется, пока не выровнится всё, и уж потом только делать замеры. Если взять любые функции на С, то они прежде чем делать измерение выжидают время, как раз, таки, что бы не ошибиться в замерах (// Delay needed for the stabilization of the ADC input voltage). Так, что это спорное утверждение. Вместо резистора, можно и понижалку собрать с хорошим кпд, он от 1,8 вольта заводится (хотя надо в даташите уточнить), а потреблять будет еще меньше при этом напряжении Тут много чего сделать можно.

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

[lasers_INFERION]

Понижение частоты экономичность не повышает. На неё влияет только объём вычислений и напряжение питания. Благодаря снижению частоты можно уменьшить напряжение питания, и только тогда добиться экономии. А с одинаковым напряжением питания потребление не изменится. Толку от того что операций за единицу времени будет производится меньше? Сами операции будут обрабатывать задачу в столько же раз дольше. Вывод: если питаем литием - ниже 8МГц частоту опускать смысла просто нет. Только латентность поднимем...

Я не понял при чём к RC-фильтру, на Vcc МК, понижалка с высоким КПД. Смысл то не в понижении напряжения, а в фильтрации и защите от переполюсовки (вместо полевика). Высокоомный резистор с этим справляется лучше, чем низкоомный, но на нём проседает недопустимо высокое напряжение при таком потреблении. Тут более оптимальный код позволил бы упростить схему и улучшить её характеристики.

Задержка АЦП нужна при устаканивании переходных процессов, да, но они ведь далеко не всегда происходят. К примеру если ты выходишь из режима "Idle", то просыпается только АЛУ, при этом все таймеры, питание, АЦП и т.п. как работали, так и продолжают работать. В этот момент просто начинается очередная пачка помех от АЛУ, пока он не обработает задачу. Остальное же время МК работает, АЦП снимает семплы, таймер считает время, но помех уже гораздо меньше (жрёт то МК импульсами, и почти всё хренпоймическое потребление приходится на АЛУ, остальные узлы потребляют более менее равномерно) и задержки тут только навредят, т.к. оверсемплинг никто не отменял. Усреднение зашумленных семплов повышает эффективную разрядность АЦП. Шум полезен, но его всё же желательно сводить хотя бы к половине LSB (а ещё лучше, если шум всегда известен, чтоб его затем вычесть). И чем больше семплов усреднишь - тем качественнее получишь сигнал, поэтому всякие там выжидания, задержки и т.п. в ряде случаев даже нежелательны...
Я с этого АЦП спокойно и 16 бит получаю...

[lasers_Ryazanec]

Если от RC цепочки работает - то да. Он всё равно на 8 мегагерцах, но разве, микроконроллер еще что то делает, когда частота делится на 8? он что то делает каждые 8 тактов а не каждый, потребление хоть и не сильно значительноо, но уменьшится.

А шумы - это да, обычно делаю 8 выборок и усредняю. От сетевой помехи 50 церц вообще избавиться легко, делая замеры за 1 период, и она автоматом вычитается.

Потребление кстати снижается, при снижении напряжения питания МК не на одном форуме народ об этом пишет. Правда я не проверял это утверждение.

[lasers_INFERION]

 Сообщение от Ryazanec :

разве, микроконроллер еще что то делает, когда частота делится на 8? он что то делает каждые 8 тактов а не каждый, потребление хоть и не сильно значительноо, но уменьшится.

Попробую объяснить по-другому. К примеру МК жрёт 16мА на 8МГц при напряжении питания 5V. Это значит, что один такт жрёт в среднем 5V*0.016А/8000000Гц=0,00000001Дж, или 10нДж. Почему я перевёл потребление в такие единицы? Да потому что МК тратит энергию на перезаряд затворной ёмкости своих ключей, а энергия эта зависит только от ёмкости и напряжения (причём в квадрате). Время тут никаким боком не вылазит. На общее потребление, соответственно, влияет не частота, а количество потраченных на обработку задачи инструкций. Если код тупой и в нём всё построено на циклах, тогда действительно кое как уменьшить потребление частотой можно, но нормальный код всё равно будет есть в разы меньше, и от частоты потребление зависеть уже не будет, т.к. объём программы от тактовой частоты не зависит.
Поехали дальше. Есть у нас прерывание, обработка которого требует 100 тактов: 10нДж*100=1мкДж. Если МК успевает всё обработать вовремя, то на в 8 раз более высокой частоте он будет справляться в 8 раз быстрее, и среднее потребление останется на прежнем уровне.
Снижение частоты позволяет ключам работать более устойчиво, и снизить напряжение питания. Вот оно уже значительно сокращает затраты на перезаряд паразитной ёмкости этих ключей...
Остальная же периферия хоть и вносит заметное влияние на потребление, в зависимости от частоты - всё же напряжение влияет куда больше...

Спать ты его не отучил - ты его и не научил. Получил семпл, обработал его, заснул в ожидании следующего события. Получил прерывание от таймера - О! Надо переключить светик. Сделал - опять уснул...
Или получил любое событие - проснулся и пошел высматривать что же там произошло, увидел флаги, которые после себя оставили прерывания, и принялся за работу. Т.е. всё выполняется в одном цикле, но его надо построить так, чтоб на анализ уходило минимум ресурсов. В таком случае код получается последовательным и понятным.

Я пробовал на Си написать программку под МК - ассемблер мне показался на порядок функциональнее, более удобным, компактным и быстрым.

[lasers_Denis]

Проверял новую прошивку вчера в попыхах в самом конце рабочего дня. Вроде работает. Думаю задействовать вторую ногу всё-таки надо, чтоб при включении фары включалась индикация (на нее подавался сигнал с платы управления драйвера). Думаю не очень удобно будет ставить отдельную кнопку для включения индикации.

[lasers_Ryazanec]

Если код тупой и в нём всё построено на циклах, тогда действительно кое как уменьшить потребление частотой можно

про это я и говорил кстати.

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

я говорю за свой код, и его недостатки я знаю. Я же говорил, что в этой версии вместо sleep я использую delay для генерации ШИМ, или я об этом не говорил?

а энергия эта зависит только от ёмкости и напряжения

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

[lasers_Ryazanec]

 Сообщение от Denis :

Проверял новую прошивку вчера в попыхах в самом конце рабочего дня. Вроде работает. Думаю задействовать вторую ногу всё-таки надо, чтоб при включении фары включалась индикация (на нее подавался сигнал с платы управления драйвера). Думаю не очень удобно будет ставить отдельную кнопку для включения индикации.

А кнопка что делает? только драйвером рулит? или подает на него питание? если второе, то просто параллельно драйверу и врубить индикацию.

Если всё же делать дополнительную кнопку, то на какой сигнал она должна реагировать? на высокий или на низкий?

Сейчас прошивка при подачи питания работает всё время, я думал использоваться будет изредка, для проверки напряжения на аккумулятороах. Если всё время, о потребление действительно для индикатора многовато.

[lasers_INFERION]

Ryazanec. Зачем нервничать? Читал я это все, просто перетрактовал по-своему и более разжевано, т.к не был уверен в том, что ты понимаешь недостатки своего кода в полной мере.
У тебя не возникает желания причесать свой код хотя бы для спортивного интереса? Учиться юзать прерывания и слип тут стоит начинать как можно раньше. Это ведь не компьютер из большого мира, в котором все разруливает ОС. Индикатор для образовательных целей не плохо подходит. Тут сталкиваешься и с ШИМ, и с АЦП, и с прерываниваниями, и со спящими режимами... При этом все наглядно работает и нет ничего заумного.

[lasers_Ryazanec]

 Сообщение от INFERION :

Ryazanec. Зачем нервничать? Читал я это все, просто перетрактовал по-своему и более разжевано, т.к не был уверен в том, что ты понимаешь недостатки своего кода в полной мере.
У тебя не возникает желания причесать свой код хотя бы для спортивного интереса? Учиться юзать прерывания и слип тут стоит начинать как можно раньше. Это ведь не компьютер из большого мира, в котором все разруливает ОС. Индикатор для образовательных целей не плохо подходит. Тут сталкиваешься и с ШИМ, и с АЦП, и с прерываниваниями, и со спящими режимами... При этом все наглядно работает и нет ничего заумного.

Я и не нервничал, пытался сказать, что понимаю недостатки, а ты начинал опять развернуто объяснять них.

Этот код причесать желание возникло. Думаю сегодня этим и займусь. Мне отлаживать только не где, это в протеусе не отладить, там можно только понаблюдать за внешней реакцией, энергопотребление не замерить. Прерывание я всё же использовал, когда из спячки его пробуждала кнопка, а вот в простое вместо спячки у меня МК nop ами занимался (думаю библиотека delay.h расчитывает в зависимости от частоты МК только количество простоя).

Реакцию мгновенную на АЦП всё же делаьт не буду, хотя это и не сложно, в моем случае проседание напряжения аккумулятора не будет таким быстрым.

[lasers_Denis]

 Сообщение от Ryazanec :

Если всё же делать дополнительную кнопку, то на какой сигнал она должна реагировать? на высокий или на низкий?

Индикация должна включатся при подаче на вторую ногу высокого уровня.

[lasers_Ryazanec]

Тогда нужно еще один резистор в схему иначе он от наводок включаться будет. Прошивку я ради интереса доработаю.
Отлаживать пока только не на чем, кроме протеуса.

[lasers_Denis]

Резистор так резистор) Спасибо за все старания!

[lasers_Ryazanec]

INFERION
Переделал немного прошивку. Полностью не оптимизировал, можно еще поднастроить, но можеш проверить на реальном МК, стало лучше? На твой взгляд. надо еще подумать как его полностью усыпить когда он не активен (кнопка не нажата).
Тут кстати теперь задействована кнопка.
Шим попрежнему генерируется в цыклах, но в простоях засыпает (IDLE MODE - только в нем тинька просыпается от переполнения таймера) отсюда и куча ненужного кода (а то опять помидоры полетят). Кстати разные версии компилятора по разному выдают код, причем разница приличная, с чем связано не пойму, настройки проекта и компиляторов одинаковые.

[lasers_INFERION]

Без помидоров всё равно не получится. Я ведь так люблю ими бросаться ...
Опять сейчас много текста будет. Скучно мне тут сидеть, с солдафонами и поговорить не о чём. В голове у них только сиськи, пиво ...

3,14мА на 3,9V. Уже гораздо лучше, но можно ведь и ещё меньше.
А почему не слепишь нормальный ШИМ, где переполнение таймера зажигает сразу все светики, а его компаратор тушит необходимые? Это вообще практически аппаратная реализация. Или сигма-дельта модулятор, вобще интересная и простая штука. Разве что требует прерывания с частотой в десятки килогерц. Посему Сишный код нежелателен, ибо количество команд критично.
Суть заключается в простом добавлении заданного значения к регистру, который является как бы накопителем ошибки. При переполнении зажигать светик, если переполнения нет - тушить (командой условного перехода, проверяющей переполнение). Я не знаю как такое вообще в Си нормально построить, а на ассемблере всего 4 такта для 16-ти бит (плюс код, который что-то включает, или выключает).

Килогерцевый 8-ми разрядный ШИМ будет заметно мерцать при взмахах, в то время как СДМ, затактированный частотой в 256кГц (такая же частота требуется и таймеру ШИМ), на этой частоте будет шуметь только 8-м битом, что в 256 раз меньше чем у ШИМ, а с дальнейшим снижением частоты этот шум будет и дальше падать. И на десятках герц разрядность будет куда выше чем у ШИМ. Вывод из этого простой - СДМ может работать на гораздо меньших частотах, чем таймер ШИМ. К сожалению в АВР он реализуется программно, и требует не мало тактов. У меня получилось на всё прерывание 28 тактов (вроде, или 32, не помню что симулятор показал), это на три 16-ти разрядных канала:

;Сигма-Дельта Модуляторы RGB каналов
;==========================================================================

	;R2:R1   - Red_SDM
	;R4:R3   - Green_SDM
	;R6:R5   - Blue_SDM

	;R8:R7   - Red_error
	;R10:R9  - Green_error
	;R12:R11 - Blue_error


compA1:	push	R16
	in	R16, SREG

red:	add	R7, R1		;error+=X
	adc	R8, R2
	brcs	on_r
	sbi	PORTB, 1	;off red
	rjmp	green
on_r:	cbi	PORTB, 1	;on red

green:	add	R9, R3		;error+=X
	adc	R10, R4
	brcs	on_g
	sbi	PORTB, 2	;off green
	rjmp	blue
on_g:	cbi	PORTB, 2	;on green

blue:	add	R11, R5		;error+=X
	adc	R12, R6
	brcs	on_b
	sbi	PORTB, 0	;off blue
	rjmp	outsdm
on_b:	cbi	PORTB, 0	;on blue

outsdm:	out	SREG, R16
	pop	R16
	reti

Хотя команды sbi и cbi, которые жрут по 2 такта, можно попробовать заменить какой-нить однотактной альтернативой, и сэкономить ещё такта три. Ещё на пару тактов можно похудеть, если копировать регистр с флагами в отведённый для этого регистр (например R0), чтоб не таскать его в стек и обратно. Но это я уже под конец реализую, если заваляются лишние регистры.

P.S. Прелесть ассемблера - чётко видишь что и как работает, где, что и как можно оптимизировать. А компиляторы не люди, порою лепят не то что не оптимальный, а вообще неработающий или криво работающий код, т.к. им ещё надо уметь правильно объяснять что ты от них хочешь. В данном случае вместо половины регистров, зарезервированных под нужды СДМ, компилятор бы расположил переменные в ОЗУ, и сожрало бы это более чем на 26 тактов больше (достать, а потом ещё и спрятать), плюс все использующиеся регистры он бы прятал в стек, даже если их содержимое никому неинтересно. Ещё я хз как юзать там флаги, и пришлось бы проверять переполнение более костыльными, арифметическими действиями. Сколько это съело бы тактов - я и предположить не могу. Я полистал листинги GCC и решил ещё немного посидеть на ассемблере. Не умею я нормально кодить на ЯВУ под МК ...

[lasers_Ryazanec]

Можно, чем я и занимаюсь. На С сложно подгонять интервалы, так как код на выходе иногда работает дольше, чем ожидается. Но и в ассемблер пока лезть не хочу, своих сложностей в нем хватает.

Новая прошивка. Уже что то менять лень...
Program size: 416 words (832 bytes), 20,3% of FLASH

[lasers_INFERION]

2,8мА, в спячке 0,25мА. В принципе разве что спящий режим допилить, отключать ИОН перед уходом в глубокий сон. Тогда МК меньше микроампера жрать будет...

2,8мА против 15-ти + более компактный код. Как бы уже ощутимо . Интересно, что у меня получится с ассемблерным кодом на моём RGB v2.0 .

[lasers_Ryazanec]

Ион не вырубается, возиться надо.

MCUCR=0b10110000;
MCUCR=0b10110100;
#asm("Sleep");

надо с режимами поиграться, соберу на макетке, тогда отлажу и это.

Denis
Могу тестовую прошивку выложить.
Меня попросили сделать для автомобильного аккумулятора такой же индикатор, буду дорабатывать этото проект. Сегодня печатку попробую сделать.

[lasers_INFERION]

Вот пример функции, отвечающей за слип в старой версии моего индикатора:

loop:	cli
	sbis	PINB, 5
	rjmp	pon
	sbic	PINB, 4
	rjmp	pon
	sbis	PINB, 3
	rjmp	pon
	sbic	GPIOR1, 2
	rjmp	pon
	tst	R7
	brne	pon
	tst	R8
	brne	pon
	tst	R9
	brne	pon

	clr	R16		;Выключить АЦП
	out	ADCSRA, R16
	ldi	R17, 0b10110000
	ldi	R16, 0b10110100	;BOD Sleep, Sleep, режим Power-down, BOD Sleep Enable
	out	MCUCR, R16
	out	MCUCR, R17	;BOD Sleep, Sleep, режим Power-down
	sei
	Sleep
	cli

pon:	ldi	R16, 0b00100000	;Sleep, режим Idle
	out	MCUCR, R16
	ldi	R16, 0b10000110	;Включить АЦП, тактовая clk/64
	out	ADCSRA, R16
	sei
loop:	Sleep
	rjmp	loop

По-сути это главная функция, всегда работающая в фоновом режиме. После любого события она проверяет активность кода и выбирает соответствующий режим сна. Тут есть пример отключения ИОН. Обрати внимание на команды sei и cli. На время отключения ИОН нужно запрещать прерывания, т.к. у тебя всего несколько тактов, чтоб его отключить и уснуть. Си врятли в них укладывается, слишком он уж костыльно всё выполняет. Ещё один важный момент - BOD это не ИОН, а супервизор. ИОН отключается, если его ничего не использует. Для того чтоб он заглох - обычно приходится глушить 3 вещи - АЦП, компаратор и супервизор. Они у тебя точно отключаются все?

P.S. Сократил число тактов модулятора до 18 (почти в 2 раза):

compA1:	in	R15, SREG
	ldi	R24, 0b00000101

	add	R7, R1		;error+=X
	adc	R8, R2
	rol	R24

	add	R9, R3		;error+=X
	adc	R10, R4
	rol	R24

	add	R11, R5		;error+=X
	adc	R12, R6
	rol	R24

	out	PORTB, R24
	out	SREG, R15
	reti

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