[Rime]

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

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

[INFERION]

Rime, банальный хороший ОУ с компесацией смещения работает гораздо лучше, а они сюда летающие кондёры зафигачили! Именно этому факту мы обязаны всему тому говну, которое валит с "усилителя" (по факту умножителя). Квантование на 11кГц, адовые шумы, хренпоймической природы смещения (да, во множественном числе). Разрабы могли бы туда засунуть человеческий усилитель. То, что они описали в даташите - гораздо лучше того, что я имею на практике, поверь.
Стабилизация питания маскирует проблему, а не решает её. Просто искажения перестают плавать, но они продолжают присутствовать. Если речь идёт о стабилизации питания - AVR идёт лесом автоматом, поскольку именно отсутствие LDO при питании от Li-ion делает их привлекательнее ARM Cortex M3 в таких применениях. Да и если лепить какой-то внешний чип - лучше не LDO, а сразу усилитель токового шунта. Человеческий, не на летающих говнокондёрах. Это тоже решает проблему, но в целом да - нехрен требовать от тиньки работы на разрешениях в несколько бит...

[INFERION]

Почти монолог какой-то получается в теме. Ну да ладно, вот следующий квест:

Вчера долго пытался понять природу нестабильности выходной мощности фонаря от напряжения питания в мунлайте (3мА). На 4,2V 14 оптических попугаев, а на 3V уже 5. Этот эффект с самого начала присутствует в этой схемотехнике, но у меня всё руки не доходили исправить. Попробовал закостылить и в очередной раз убедился, что без нормального подхода не обойтись. Полез щупать осциллографом и тогда до меня дошло:

столь существенные потери именно в демпфирующей RC-цепи. На нормальных режимах её влияние незаметно, но когда речь касается единиц миллиампер у преобразователя на десяток ампер - влияние становится весьма заметным. ШИМ у меня тактируется частотой в 4МГц, т.е. на 250кГц я получаю 16 бит разрешения. Такие условия нужны для того, чтоб ограничить минимальную длительность импульса, поскольку потери с уменьшением реактивного тока катастрофически растут. Программно ограничение получается на 250ns, но из-за косяков архитектуры AVR ШИМ добавляет ещё 1 такт МК, и плюс ключ закрывается дольше, чем открывается (Выходную ёмкость, порядка 1,7nF, заряжает дроссель своим реактивным током около 0,4...0,5A, тогда как эту же ёмкость ключ разряжает импульсом в десятки ампер) - в результате имеем импульс порядка 400ns. На небольших заполнениях (<6.25%) ШИМ прекращает своё существование и заменяется на СДМ, поэтому импульсы фиксированной длинны начинают прореживаться. Вместе с ними начинают прореживаться и динамические потери, однако сами потери зависят от ряда не учитываемых программой факторов.

Вот так выглядит процесс:
1. Перед началом импульса на Cd напряжение равно Vin, поскольку импульсы проскакивают достаточно редко, чтоб система уравновесилась.
2. Открывается ключ, в дросселе начинает расти ток, а Cd оказывается замкнутым на Rd и разряжается. Постоянная времени RC-цепочки 300ns, а Vin пусть будет 3V. Тогда к моменту окончания импульса на Cd будет напряжение 3V*e^(-400ns/300ns)=0,79V, а реактивный ток дросселя у нас получается 3V*0,4мкс/3,3мкГн=0,364A.
3. Ключ закрывается, теперь дроссель зажат между Vin и Vout, и реактивный ток его падает до нуля за 3,3мкГн*0,364A/(Vout-Vin)=0,24мкс. Через резистор RC-цепи в начале течёт ток в (Vout-VCd)/Rd=(8V-0,79V)/20Ohm=0.36A.

А теперь внимание - токи сопоставимы, время тоже. Практически 100% потери! Если пересчитать всё на 4,2V - видно что потери существенно уменьшатся. Реактивный ток растёт, Toff тоже, а напряжение на Rd падает. Я не знаю как вычислить среднее значение протекающего через RC-цепь тока на произвольном участке кривой без интегрирования и всяких хитрых возведений в степень (МК не резиновый), да и такое количество потерь не радует. Поэтому я решил поступить следующим образом:

1. Необходимо попытаться ещё увеличить минимальную длительность импульса. Хорошо бы до микросекунды, это тактирование в 1МГц. Если ОС на нормальных токах сума не сойдёт от низкого разрешения ШИМ - будет хорошо. Иначе придётся городить переключатели режимов таймера, от чего я попытался уйти в новой версии программы. Как я уже говорил - архитектура AVR кривущая, и переключение режимов приводит к возникновению изменений всяких нелинейностей и смещений ШИМ, из-за чего ступенька вылазит.
2. На миллисекундных импульсах можно пренебречь переходной характеристикой RC-цепи, рассматривая её как прямоугольную, поскольку она целиком будет вписываться в импульс (5% хвостом пренебрегаем). Ну а дальше уже дорабатывать алгоритмы вычисления необходимого Ton и sqrt2TL. Добавить в формулы эквивалентное сопротивление цепи, а дальше уже пусть само учитывает потери под конкретные условия. Недостаток - это сопротивление зашивается в программу намертво, и никак не вычисляется (возможности замерить реальный ток нет). Однако это сопротивление коррелирует с параметрами остальных компонентов (индуктивности дросселя, мощности преобразователя и т.п.) и вполне ожидаемо, что расчёт схемы на другую мощность даст цепочку с подходящими программе номиналами.

В общем, всё упирается сейчас в намеренное уменьшение разрешения ШИМ в 4 раза. У меня то всего 24 бита сейчас, и 4 бита уже кастрированы. Если кастрирую ещё 2 бита - у меня всё равно в запасе парочка остаётся, но шум квантования на рабочей частоте регулятора (2кГц 9 бит - глаз этот шум увидит ещё не скоро) может привести к неприятным эффектам.

Всё, утопал проходить этот квест...

[Volosaty]

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

Почти монолог какой-то получается в теме

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

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

[Исправлено: INFERION, Сегодня в 06:07]

Ох уж эти увлечённые програмеры

[INFERION]

Ох уж этот CTC. Пишу в OCR1C 3, в ШИМ (OCR1A) 1, и тактирую таймер мегагерцем. Получаю нормальные 250кГц и заполнение... 2. 2мкс вместо расчётной 1мкс. Вот что за фигня? Опять с бубном искать пасхальные яички, оторванные (судя по всему) у разработчиков этого кристалла...

-------------------
А, вот ещё кое что. Смещение у ШИМ такое, что PWM=1=2, это вызывает "недоумение" ОС, поскольку речь идёт о битах, весом в 25%. Ошибка в 25%, да... Но есть возможность поплясать с бубном. Например проинвертировать ШИМ и записывать в него значения в формате OCR1A=0x04-PWMH, или попробовать другую тактовую частоту. От неё смещение может прыгнуть в другое место и изменить свой масштаб, да...

-------------------
Ещё одно обновление (дабы не плодить посты):
Поплясал с бубном, духи подсказали следующую ближайшую пригодную комбинацию:
Заводим таймер на 2МГц (предделитель на 4), заряжаем выход на "Set the OC1A output line", т.е. инверсно, CTC на 8 тактов (значение 7), и записываем в компаратор обратные значения, умноженные на 2: 2*(X-PWM). Придётся раскошелится на целую инструкция сдвига влево - 3,3% всех ресурсов МК. Табличка получилась следующей:
-0=0мкс
-1=0,5мкс
-2=1мкс
-3=1,5мкс
-4=2мкс
-5=2,5мкс
-6=3мкс
-7=4мкс
-8=0мкс
Последние 2 ступеньки глючные, и если благодаря сдвигу на 7 я не попадаю, то вот 8 даёт лажу, что делает невозможным вывод заполнения выше 75%. А это 12V максимум, в моей повышалке. Должно хватить, но только на трипл. Зато интересна ситуация при зашкаливании за 75% - модулятор начнёт уменьшать заполнение. Чем больше я буду поднимать - тем ниже оно окажется. Это второй рубеж защиты от КЗ через ключ, в случае каких-то ошибок в коде.

[Rime]

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

банальный хороший ОУ с компесацией смещения работает гораздо лучше, а они сюда летающие кондёры зафигачили! Именно этому факту мы обязаны всему тому говну, которое валит с "усилителя" (по факту умножителя). Квантование на 11кГц, адовые шумы, хренпоймической природы смещения (да, во множественном числе). Разрабы могли бы туда засунуть человеческий усилитель.

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

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

[INFERION]

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

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

Это как раз не проблема.
1. У типичного ОУ подавление синфазного сигнала, и помех по питанию - 70...>100Дб. Это десятки тысяч...миллионы раз. Нам хватило бы для задачи и тысячи, совершенно другие масштабы, да?
2. Типичный ОУ просто режет всю ВЧ грязь. Это естественный фильтр ВЧ. Если бы у МК был такой усилитель, то значение в "4кГц" читалось бы как "всё что выше 4кГц - срезается встроенным в МК фильтром", а на 4кГц и ниже ну нет грязи практически. ИОН же как-то работает в таких условиях? И его вполне себе аналоговый усилитель на 2,56V...
3. На практике 4кГц значит, что если в сигнале появятся гармоники с более высокой частотой - они не срежутся, т.к. усилитель квантует сигнал во времени (11кГц - замерил осциллографом, и где-то ещё смог вычитать). Мы получим альясинг, и кучу проблем с ним. Вот в такой то как-раз ситуации ВЧ помехи и страшны, а их в преобразователе действительно вагон.
4. Летающие кондёры периодически подключаются к источнику сигнала, подобно устройству выборки/хранения АЦП. Догадываешься чем это грозит? Если источник сигнала имеет сопротивление хотя бы сотню Ом - осциллограф фиксирует удары отбойным молотком, в несколько милливольт, на частоте около 11кГц. Результат - RC фильтр просто обязателен. Нет там ОУ, там есть редуктор, который повышает напряжение за счёт уменьшения входного сопротивления. Все эти особенности просто критичны для схемотехники, но узнавать я об этом почему-то должен не из даташита...
А может там и ОУ, просто с настолько хреновой схемой компенсации смещения.

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

Так что всё имхо вполне ожидаемо...

Да нет таких проблем с сигнальными цепями в нормальной импульсной схемотехнике, какие тут.

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

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

Я не сторонник подхода "довольствуемся говном и радуемся, если альтернативы нет". Я буду довольствоваться, но не радоваться...

[Rime]

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

Да нет таких проблем с сигнальными цепями в нормальной импульсной схемотехнике, какие тут.

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

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

Я не сторонник подхода "довольствуемся говном и радуемся, если альтернативы нет". Я буду довольствоваться, но не радоваться...

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

[INFERION]

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

Ты имеешь в виду спец микрухи? Типа той же ТПС-ки?

Да нет, вообще всю силовуху. На рассыпухе тоже. На кристалле можно развести нормально, нет там таких уж страшных помех, с которыми невозможно бороться. Откуда в МК взяться грязи? Там условия стерильнее того же TPS, поскольку по кристаллу единицы ампер со спектром в сотни мегагерц не летают...

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

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

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

По теме:
ШИМ без боя не сдаётся. С трудом нашел со скрипом подходящий режим, он потребовал влепить в прерывание целых 2 инструкции, и занять один GPIOR константой. При этом заполнения выше 75% физически недоступны, а как только я настраиваю ШИМ (даже не включаю его, а просто настраиваю "Set the OC1A output line") - происходит КЗ. Теперь нужно побороться с высоким логическим на пине по умолчанию, когда ШИМ ВЫКЛЮЧЕН... Главное, значит, настраивать пин на выход нужно в обязательном порядке, а принимать значение с PORTB как значение по-умолчанию (при выключенном ШИМ) - нифига...

-----------------------
Два дня ушло на то, чтоб заставить ШИМ корректно работать. Заставил - ПИД скрипит, свистит, дрожит, но жрёт кактус... Ток стабилит, но меня такая работа не устраивает. В прерывание пришлось добавить 2 инструкции, но с таким раскладом я могу другими инструкциями реализовать плавающее разрешение. Чтоб таймер тактировался от 8 или даже 64МГц, а минимальная длительность импульса ограничивалась уже на месте. Все необходимые ресурсы я нашел (разгрёб для них место, скорее), так что пробую... Хм, даже на 1 такт меньше исходного варианта сожрёт.

[INFERION]

Ну что... Провозился 3 дня с этим ШИМ, пришел к варианту с тактированием от 8МГц, использования всего разрешения таймера, и хитропопого ограничителя минимального заполнения, начинающего прореживать импульсы с НЕ минимальным заполнением ШИМ. В результате имею и повышенное разрешение, и пониженные потери. Без учёта потерь алгоритмами стабильность и эффективность значительно возросли. Если раньше я получал 5...14 попугаев яркости, то сейчас в тех же условиях получаю 45...52 попугая. Думаю после внедрения в код модели демпфирующей цепи стабильность и точность поднимутся до вполне красивого значения.

Сижу в наушниках, гоняю на трассоискателе (он на 45-й тиньке и в нём есть выход под наушники) этот модулятор. Понял что таймеры синхронизировать - ещё пачку подводных камней выгребать. Придётся делать вложенные прерывания, чтоб модулятор мог исправно вызываться каждые 32 такта, даже если другое прерывание что-то делает. То другое прерывание выполнять работу модулятора в это время нормально не может, как бы я не считал такты. Вечно попадает не туда и не вовремя обновляет значение в компараторе.

Вот куски получившегося кода (эта штука должна компилиться и работать):

	rjmp	RESET
	reti
	reti
	reti
	reti
	reti
	reti
	reti
	reti
	rjmp	Comp1B
	reti
	reti
	reti
	reti
	reti

	;R6		- SREG
	;R9:R8:R7	- Ton
	;R11:R10	- Ton_error
	;R12		- PWM_MSB+PWM_step

Comp1B:	in	R6,	SREG		;Сигма-дельта модулятор PWM
	add	R10,	R7
	adc	R11,	R8
	brcs	PC+4
	out	OCR1A,	R9
	out	SREG,	R6
	reti
	out	OCR1A,	R12
	out	SREG,	R6
	reti

;-----------------------------

RESET:	Ldi	R16, HIGH(RAMEND-120)	;инициализация стека
	out	SPH,	R16
	Ldi	R16, LOW(RAMEND-120)
	out	SPL,	R16

	ldi	R16,	0b00000010	;Выходы
	out	DDRB,	R16

	ldi	R16,	0b11100001	;CTC1, PWM on, Clear the OC1A, clk/1
	out	TCCR1,	R16
	ldi	R16,	31		;CTC 250kHz
	out	OCR1C,	R16
	ldi	R16,	0b00100000	;OCIE1B
	out	TIMSK,	R16
	sei				;Разрешить прерывания

;------------------------------

	ldi	R18,	0xFF		;Ton_L
	ldi	R16,	0xFF		;Ton_M
	ldi	R17,	0x7F		;Ton_H
	rcall	pwmset
loop:	rjmp	loop

;------------------------------

pwmset:	cpi	R17,	64		;Согласование модулятора с Ton
	brcs	sdmode			;Ограничение минимальной длительности импульса
	lsr	R17			;Ton/8
	ror	R16
	ror	R18
	lsr	R17
	ror	R16
	ror	R18
	lsr	R17
	ror	R16
	ror	R18
	mov	R7,	R18
	movw	R8,	R16
	inc	R17
	mov	R12,	R17
	ret
sdmode:	lsl	R18			;Ton*4
	rol	R16
	rol	R17
	lsl	R18
	rol	R16
	rol	R17
	ldi	R18,	8
	mov	R7,	R16
	mov	R8,	R17
	clr	R9
	mov	R12,	R18
	ret

Прикола ради выведу синус. Послушаю. Ну или нотку фортепиано, тоже интересно...

[INFERION]

Осталась тяжелая тема - борьба с шумом. Прицепил вместо микрофона фоторезистор, сижу слушаю фонарь:

Слева - работа прямой связи. Видно что раз в 17 миллисекунд (60Гц) матан рассчитывает заполнение ШИМ под полученный семпл напряжения питания. Сам семпл сглаживается (64 выборки), но этого недостаточно для полного подавления шума, что я и наблюдаю. Мерцание это заметно на глаз, но мне пришлось ловить это неустойчивое состояние. Дальше прямая связь переключается на обратную - ток прежний (300мА при шунте на 6A). Видно что уровень шума резко снизился до шума звуковой карты, но продержалось это недолго - ОС пошла в разнос как только заполнение ШИМ начало хитро коррелировать с показаниями шунта. Результат - грязи ещё больше чем с прямой связью. Когда-то я уже пытался фильтрами задавить - понял что бесполезно. Сам АЦП шумит настолько слабо, что лучше бороться с этими корреляциями с ШИМ, об которые спотыкается ОС. Если прямую связь можно задавить фильтром - обратная находит неустойчивое состояние и цепляется за него, поскольку сигнал ошибки в этом месте инвертируется. Решил погуглить теорию на это дело - фиг. Гугл разводит руками. Похоже, борьба с паразитными связями в цифро-аналоговых цепях - тема не популярная. Нужно придумать как устранить такие колдобины. Шум намеренно белый ввести что-ли? Роснано - наши дороги уже в микроконтроллерах...

Да, на больших токах этого эффекта нет. Там разрядность АЦП выше, как и белый шум, скрывающий все дефекты.

[INFERION]

Ай ладно, отпишусь тут, чтоб не затерялось. Шум не помог. Я получил ту же фигню, но с наложенным поверх шумом (я его даже на слух узнал - это точно был шум генератора). Значит источник лагов АЦП сидит в другом месте, и у меня нет больше предположений. Я знаю что АЦП очень живо реагирует на помехи по питанию, но как мне на этот шум повлиять? В том месте, где ПИД шумит, используется быстрый алгоритм для прерывистого режима (законы регулирования другие - усиление ошибки нужно больше). Я могу легким движением руки сделать переключатель на медленный не только по достижении безразрывного режима, но и прекращения изменения опорного значения (напомню - необходимость в быстром регуляторе вызвал лагающий плавный пуск). Медленный регулятор в 8 раз эффективнее давит шум, возможно с ним разнос АЦП сорвётся (это какой-то возбуд, характер похож).

Отдельно хотелось бы оставить заметку по генератору шума. Слепить хороший генератор, оказалось, довольно сложно. И дело не в сложности алгоритма - он простой как двери. Проблема в поиске информации. Хорошей, годной, с большими таблицами примитивных полиномов. Пару дней мучился с алгоритмами, пока не наткнулся на этот пост: http://vrtp.ru/index.php?sh...
Самое главное тут - таблицы. Очень увесистые, есть с чего выбирать. Мне удобнее всего было использовать 8-ми битный генератор, однако периода его повторения оказалось очень уж мало, а выбор полиномов вообще никакой. Я мог получить что угодно, но только не шум. Поэтому я увеличил разрядность до 16-ти бит. К нему полиномов оказалось столько, что и перебирать всё в лом. Поэтому я выбрал наиболее удобные для ассемблера, занимающие только один байт (меньше инструкций требуется для выполнения XOR), и начал их прослушивать. Чего там только не было, вот результаты прослушиваний некоторых полиномов, которые более менее подходили:

;[16, 15, 12, 10] Более менее ровный
;[16, 13, 12, 11] Чуть больше низа, поскрипывает
;[16, 15, 14, 13, 12, 11] Немного рваный
;[16, 14, 13, 12, 11, 9] С фрагментом неразборчивой речи

Сам генератор выглядит вот так:

	ldi	R16,	1		;Стартовое значение (что угодно, кроме нуля)
	clr	R17			;Старшая часть слова с шумом
	ldi	R18,	0b01010011	;Полином (хитрая кривулька, взаятая с таблицы)
loop:	clt				;Синхронизация с таймером (его прерывание ставит флаг T)
lpt:	brtc	lpt

	lsl	R16			;Сдвигаем младшую часть шума
	sbrc	R17,	7		;Проверяем старшую часть на минус,
	eor	R16,	R18		;и XOR'им младшую с полиномом, если минус
	rol	R17			;Сдвигаем старшую часть шума

	movw	R8,	R16		;Копируем регистровую пару (R17:R16) в ШИМ (R9:R8)
	rjmp	loop

сам генератор кушает 4 такта и 8 байт, даёт аккуратную последовательность длинною 65535 значений, которые на слух воспринимаются как монотонный и почти не зацикленный шум (полностью избавится от заметных на слух артефактов получилось только в 24-х битном генераторе). Тут полином я отзеркалил, поскольку таблицы приспособлены под сдвиг вправо (как на картинках), однако такой сдвиг дал худший результат, по сравнению с текущим.

[Maksym]

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

[INFERION]

Финальную для завода отдал давно, т.е. я прошивку признал годной и законченной. Там в момент переключения с прямой связи на обратную PID регулятор странно ток роняет, потом выруливает, но я не понял пока откуда у косяка ноги растут. Это на глаз выглядит как кратковременное замедление набора яркости при плавном пуске с набором яркости (в обратном направлении работает как положено).

Для доступной версии прошивки интерфейс нужно свой написать, у меня просто руки сейчас до этого не доходят. Других дел хватает. Я не планирую сложный интерфейс, в этот раз автоматика за пользователя сама всё решает.

[INFERION]

Похоже, намечается 5.4 версия. 5.3 всё равно доделаю, поскольку интерфейс будет идентичен с 5.4. Сейчас я занят 6.0 (понижалкой), и у меня получилось удерживать ток со значениями на шунте в единицы микровольт (десятки тысяч раз меньше за максимальное значение). Т.е. прямая связь больше ненужна, как и матан, и демпфер паразитных резонансов. Можно существенно поднять эффективность драйвера в мунлайте и упростить алгоритмы, подняв надёжность и избавившись навсегда от "сшивок". Т.к. программа успешно работает на 4МГц (потребляя при этом 2мА) - минимальное напряжение питания можно опустить до 2,5V, и полностью высасывать батарею. Как-то вот так...

[AVSel]

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

и у меня получилось удерживать ток со значениями на шунте в единицы микровольт

Ого!!! Это в понижалке? Усилитель внешний?

[Maksym]

А у меня, походу, еще 5.2 залита... или 5.2м. Те последние исправления что описаны еще не реализованы. Да и осталась проблема с просадкой . Когда в максе драйвер сигнализирует о нехватке мощности, хотя если включить-выключить то начинает хватать. Что-то слишком чувствительный измеритель мощности к качеству аккумуляторов (аккумы и в самом деле не фонтан - обычные Самсунги 2600, но и мощи я снимаю ватт 30 всего, а то и меньше, с 4-х банок). И это не просадка на подводке питания - я уже все что только можно зашунтировал.
Так что с нетерпением жду новую версию .

[INFERION]

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

Ого!!! Это в понижалке? Усилитель внешний?

Нет, встроенный. Неважно где, в повышалке тоже работать будет. Сейчас да, в 6A понижалке держу 1мА, но это не минимум. Во первых это без RC фильтра на усилителе, т.к. он мешает шить, а на шунте без всякой фильтрации гуляет реактивный ток (на светике нет конденсатора) во вторых я ещё не написал хороший фильтр смещения, и у меня просто интегрируется 64 семпла (я планирую фильтр второго порядка, с результатом эквивалентным 4096 семплам).

Раньше у меня была проблема с вытеснением шума вверх, относительно среднего значения, когда нижняя часть шума АЦП упиралась в "пол". Поэтому я не мог опустить опорный ток ниже 4LSB, на 3,5LSB регулятор постоянно получал завышенное значение и сбрасывал заполнение почти до нуля. Я решил перевести АЦП в биполярный режим. Потерял бит разрешения, зато решил проблему с вытеснением шума. Дальше начались проблемы с температурным дрейфом смещения. Доли LSB, но они в разы крутили ток под феном. Так что я сейчас делаю измерение смещения в каждом цикле (60Гц), с последующим сглаживанием в фильтре второго порядка, с постоянной времени около 1,4с, сглаживающим шум в 4096 раза. На термоконтроле такой используется, он работая с несколькими ступеньками не вносит ощутимой задержки и полностью давит шум. Надеюсь всё получится и я смогу получить нормальный мунлайт. И это ж всё на пониженном тактировании, 30% загрузке ядра и отключенном PLL - 2мА потребления.

Понижалка, кстати, необычная. Там нет RGB индикатора (просто один светик), потому что лапа МК занята дополнительным ключом на нагрузке, позволяющим быстро (250кГц) ШИМить нагрузку. С точки зрения регулятора у нагрузки трансформируется ВАХ. Я планирую повесить на этот ключ ОС, удерживающую заполнение основного ШИМ на уровне 98 или 99%. Т.е. понижалка будет уметь переходит в повышающий режим. Начинал с UcD топологии, на компараторе - драйвер отказывался переходить в безразрывный режим, и опускал частоту до покраснения. Пришлось делать чисто программный вариант, но похоже я от этого только выиграл...

Да, кое что важное - ADC0-ADC1 у 85-й тиньки работает без нареканий, в отличии от стандартных ADC2-ADC3. Т.е. лучше всё-таки отключить RESET и получить проблемы с внутрисхемной прошивкой. Встроенный усилитель позволяет качественно калибровать смещение, чего нельзя сделать с внешним, во время работы преобразователя. В конечном счёте это оказался решающий фактор в пользу мунлайта.

Maksym, пол вольта драйвер допускает. В 5.2 алгоритм хуже чем в 5.3, но там вроде бы уже учитывается дифференциальное сопротивление нагрузки. Т.е. должен работать корректно. Вот только внутреннее сопротивление батареи нормально инициализируется только со включенным "отмаргивателем" при регулировке яркости.

[Maksym]

Я уже даже согласен на моргание при регулировке яркости . Но в 5.2 и оно не особо помогает . Так что ждем 5.3-5.4 (кстати, в чем разница?).

[INFERION]

5.4 проще. Без прямой связи и хитрого ограничения просадки напряжения. Может быть с менее точным индикатором. Попробую вщимить в 4 килобайта, да и сам МК жрать будет 2мА. Короче мунлайт будет эффективный и полное отсутствие каких-либо калибровок (даже скрытых). Но и батарею угробить проще, а индикатор может врать при просадке напряжения. Это всё ещё видно будет...