[Rime]

По видимому имелось в виду к программированию.

[INFERION]

Я понимаю что это имелось ввиду, но тем не менее программирование это имеет непосредственное отношение к этим же драйверам...

[ploop]

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

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

Ты про прерывание? Смотря что там за код внутри будет. Если надо строго уложиться в 11 тактов - делается ассемблерная вставка, если компилятор не в состоянии сам разрулить.
Если ты говоришь уложиться в 11 тактов: 8 тактов вход/выход в прерывание, итого получается 19 из 32х. 60% ресурсов МК тупо на ШИМ. Это ты называешь какой смысл его тушить на старших режимах?

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

[AVSel]

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

Ну вот тебе начало нормального варианта - расширение разрядности ШИМ до 16-ти бит на 976Гц.

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

[ploop]

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

Оно просто переключает два соседних значения 8 битного ШИМ

Про что я и говорю - на светляке и слабых это может быть полезно, т.к. скачки очень заметные (в два раза, затем в полтора, потом 1.25 и т.д. с ростом заполнения), но не такими жертвами. Гораздо проще поиграться с TOP таймера, он даст нужную плавность, и ресурсы тратить не нужно.

[INFERION]

AVSel, а на какой скорости оно это делает? ОС будет переключать на 250кГц? Ну и что мы получим в спектре, если сравним? То что видим - и получим. ОС будет переключать на частотах в сотни герц, заползая в видимый глазом диапазон своим шумом. Я это выше описал, и по-моему вполне доходчиво...

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

Если надо строго уложиться в 11 тактов - делается ассемблерная вставка, если компилятор не в состоянии сам разрулить.

Строго не надо, просто 11 тактов это уже максимально оптимизированный на ассемблере вариант. Там 4 такта расходуется на само расширение. Остальное - сохранение регистра статуса, переход на вектор и выход из прерывания. Осилит такое Си?

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

Если ты говоришь уложиться в 11 тактов: 8 тактов вход/выход в прерывание, итого получается 19 из 32х. 60% ресурсов МК тупо на ШИМ. Это ты называешь какой смысл его тушить на старших режимах?

Я же разжевывал свой алгоритм потактово: https://forum.fonarevka.ru/...
11 тактов НА ВСЁ. Из них 4 полезных, остальное мишура прерывания. Причём механизм сидит прямо на векторе, без дополнительных двух тактов на лишний прыжок куда-то там... Так что расходуется 40% процессорного времени тупо на ШИМ, да. Но остального времени хватает на всё остальное с головой, и эти 40% того стоят. Это то, на что я делаю максимальный приоритет с самого начала. Лучше пусть будет ущербное всё остальное, но самое проблемное место в преобразователе должно быть исправлено в первую очередь...

Но если ресурсы действительно так транжирятся не пойми куда - делайте ЧИМ. Он конечно совсем не такой мягкий, но всё же лучше 20-ти ступенек. Однако это опять же колхоз со всякими переключателями по условиям, которых в аналоговой схемотехнике просто нет, что и делает её работу мягкой...
Всё, я с темы удаляюсь. Всё что я хотел донести - уже перехотел пытаться доносить. Допиливайте программу, а мы потом на практике проверим кто был прав ...

P.S. Я психанул, ищите меня в других темах, если понадоблюсь...

[ploop]

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

Я же разжевывал свой алгоритм потактово

Упс, этого не видел.

[MOHAPX]

ploop,

[ploop]

Ух, вот это монстр

[ploop]

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

P.S. Я психанул, ищите меня в других темах, если понадоблюсь...

Тогда я в запой пошел. А то тоже психану

[AVSel]

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

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

От быстродействия ОС зависит. Если чуть добавить быстродействия, получим те-же 900Гц.
Да и не заметны будут эти дерганься на один бит даже на сотне герц. Хуже когда они смешиваются с помехами, генерацией и проч. Вот эти биения уже хорошо замены... Точнее именно они и заметны на глаз.

[MOHAPX]

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

Ух, вот это монстр

Нормально так запустился на прошивке V3.2-I, плавненько, разводка куда лучше старой, там всё рывками. Даже светляк работает!!! Так бы и оставил, но управление устарело.

[INFERION]

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

получим те-же 900Гц.

Нет, на "тех же" 900Гц мы получим 1...2 бита к имеющимся 8-ми. В то время как нормальный расширитель это организует уже на частотах в 60...120кГц. На 976Гц будет уже 16 бит, чего нельзя сказать об ОС. ОС будет эффективно добивать уже всё что ниже этих 976Гц, только ей и добивать будет уже нечего, чему она только обрадуется. Можно уменьшить эффективность расширителя, если она кажется излишней. Я предлагал расширять разрядность начиная с 31кГц. Потратить 11 тактов на 256 я думаю даже жмот согласится, а 16 бит на 122гц (13 бит на 976Гц) тоже не плохо. И ОС работать с этим будет значительно легче, хотя на глаз я разницу всё же заметил. Не в лучшую сторону, но не настолько, чтоб с этим нельзя было смирится...

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

Хуже когда они смешиваются с помехами, генерацией и проч.

Хуже если не использовать этот шум. А его проще использовать, чем давить. И эффективное расширение разрядности тут как раз является ключевым моментом, на пару с хитрой синхронизацией АЦП с ШИМ. Вместо того чтоб бороться с дрожью - вытесняем её в ВЧ и сглаживаем. Программно это делается, я в этом лично убедился уже в как минимум 5-ти разношерстных поделках...

И да. Ненастоящий звук мы слушаем, ибо он вообще однобитный валит с ЦАП, Ненастоящие оттенки мы видим и на мониторе, ибо реально там нет 8 бит на канал, а ещё в ненастоящие микрофоны мы говорим когда по телефону разговариваем, ибо там однобитный интерфейс. Чёрт, дорогие мультиметры ненастоящие показания снимают, там же однобитный АЦП! А я так верил в эти 4 нуля за запятой... И эти шикарные INA219 получается что, тоже врут? А что если наш мир... Бозон?.. Тоже однобитная симуляция!.. Все лгут, всё враньё, мы живём в иллюзиях, МЫ ВСЕ УМРЁМ!!! ))

[Tamagotchi]

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

P.S. Я психанул, ищите меня в других темах, если понадоблюсь...

Ага, заразился

[Rime]

Не хватает только чьей нибудь фразы - Чума на оба ваших дома!

[AVSel]

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

Нет, на "тех же" 900Гц мы получим 1...2 бита к имеющимся 8-ми.

Да ладно. Те-же 16 бит и получим. Только не за счет программного расширения, а за счет ОС. Если ОС будет дергать ШИМ на один бит с частотой 976Гц, а ШИМ работает на 250кГц, будет такое-же расширение разрядности на 8 бит.

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

[INFERION]

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

Если ОС будет дергать ШИМ на один бит с частотой 976Гц, а ШИМ работает на 250кГц, будет такое-же расширение разрядности на 8 бит.

Каким образом? Каким образом ОС дёргая на частоте не выше 976Гц сможет разместить избыточную информацию в окне между 976Гц и 250кГц? Можешь расписать попериодно? К примеру через сколько периодов ШИМ я получу значение 32769 (0x8001, 0b1000 0000 0000 0001)? В случае с расширением на 250кГц мне потребуется 256 периодов ШИМ, т.к. единичка будет выскакивать каждые 256 периодов. Т.е. на частоте 976Гц. А как ОС эту единичку на такой частоте будет выплёвывать? Причём длится эта единичка всего 1 период (32 такта), иначе её вес не будет соответствовать значению...

Это попытка меня затролить, или как?

[Rime]

Погонял прошивки комрада ploop'a, две чуть разные версии.
Не заметил мерцаний.
Всматривался, но так и не увидел.

Решил, может я не вижу? Подцепил осцилограф.

Сперва напрямую к амперметру:



Потом через RC фильтр, спасибо Инфериону за наводку:



Вполне нормально.. ничего криминального.

Вот развёртка 100мс:



Тоже в общем-то всё хорошо.

Потом решил так же прогнать драйвер с прошивкой от Тамагочи:


Чуть ровнее, да, но в целом схоже.

Про старшие режимы не пишу, там всё ещё ровнее на осциллографе.
Вот, к примеру:

Как то так.
Единственное до чего придерусь - в прошивке ploop'a, зависимость от питания достаточно сильная. При 4.2В ток был 70мА, а при 3В уже 85мА.
И если питание опустить, а потом поднять, то пару раз у меня ток срывался вверх. С 70мА до 100-120. Не всегда, но пару раз было.
Из двух прошивок, первая по току более стабильна. Там ток менялся в диапазоне 70...80мА, при питании 4.2....2.8В.

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

А вот мерцаний я не увидел.

Сначала.
А потом начался он - ПП.

В какой то момент, после переподключения щупов, (в самом драйвере ничего не менялось, абсолютно!), осциллограф стал выдавать такое:



Это минимальный режим на прошивке от Тамагочи.
Естественно появилось и видимоме мерцание.
Искал причину, всё что можно перепробовал, в итоге выключил нахрен лабораторные БП-шники, и подцепил к аккумулятору - естественно всё нормально снова заработало, никаких мерцаний.
Но ведь до этого, бляха муха, и от лабораторника всё нормально работало??!
Причём у нас их два, одинаковых, я к обоим подключал. Потом включил древний, трансформаторный, и на нём то же самое, только амплитуда поменьше.
Хорошо хоть этот гон после начался, а то бы я вообще всё забраковал.
Что это было, я не понял, но в 2 часа ночи у меня не было никакого желания разбираться.

В среду плотно этим займусь.

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

[AVSel]

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

Каким образом? Каким образом ОС дёргая на частоте не выше 976Гц сможет разместить избыточную информацию в окне между 976Гц и 250кГц? Можешь расписать попериодно?

Попериодно не буду, так на пальцах. Допустим выходной ток должен находится точно посередине между значениями ШИМ 100 и 101.
Текущее значение 100, и ОС накапливает ошибку и через 0.5мс переключает ШИМ в значение 101. Далее ОС накапливает ошибку уже в другую сторону, и через 0.5мс переключает ШИМ в значение 100. И так и будет щелкать на частоте 1кГц.
Если выходной ток должен находится не точно посередине между значениями ШИМ 100 и 101, то длительности сместятся и таким образом можно будет разместить еще 250000/1000 Гц значений. При этом разрядность естественно может быть не целой, и может быть как 7.9 бит, так и 8.001 бит, но нам это по барабану
Частота переключения, и соответственно дополнительное расширение разрядности, определяется быстродействием ОС.

[INFERION]

Ну так а я о чём? И быстродействие этой ОС на порядки меньше расширителя, который будет делать ТО ЖЕ САМОЕ на 125кГц, а ОС будет делать то же самое что расширитель на килогерце - аж на 8Гц. Есть разница?..

Речь идёт не о возможности ОС заменить расширитель, а о "качестве" такой замены. Если его достаточно - не вопрос. Вот только недостаточно его, ибо этот шум находится на такой мизерной частоте, что его заметно не то что камерой (многие используют как фотосвет), но и глазом, а LC-фильтр его и вовсе не фильтрует...