[Tamagotchi]

INFERION, Выдумки. Если программист не знает, что происходит в камне то это проблемы программиста, а не языка программирования.

[INFERION]

Tamagotchi,

Не выдумки. Программист, выбравший Си - чаще всего не знает что происходит в камне. Лишь поверхностно, именно поэтому ему Си и кажется удобнее. Он не видит всего того 3,14здеца, который заливается в МК. Точнее не понимает что там творится и кде именно он накосячил. Это взаимосвязанные вещи. Предпочтение языка - индикатор "проблемы" программиста. В Си приходится использовать костыль, чтоб вызвать ассемблерную инструкцию "Sleep". А многие даже не знают что это такое или зачем оно нужно во время работы программы. Прерывания для Си - функции, которые никогда никем не вызываются, и их нужно "оптимизировать" выпиливанием. До сих пор нормально с ними работать он не научился, насколько я понимаю, но Сишников это не парит. Арифметика в нём тоже не безпроблемная. Прямого доступа к регистру статуса нет, отследить переполнения сложно, из-за чего приходится использовать избыточную разрядность переменных. Непонимание Сишником разницы в производительности между делением через умножение и делением в лоб, или знаковой арифметикой с беззнаковой ещё больше усугубляют ситуацию. Этот язык не для железа разрабатывался. Ему самое место в сферической в вакууме среде вроде той, что создаёт операционная система.

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

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

[Tamagotchi]

INFERION,
Ладно, оставайся при своих заблуждениях. Проехали.

[DooMmen]

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

Ладно, оставайся при своих заблуждениях. Проехали.

Маловато здесь заблуждений.

INFERION, про курение листинга можно поспорить, но темные углы там действительно есть, да и не всегда есть возможность заставить компилятор собрать определенный участок кода так как тебе хочется.
Про прерывания: после кода данного драйвера - я вполне согласен. Особенно сильно компилятор любит впиливать в начало кода подпрограммку копирования табличных данных из памяти в оперативку, хотя из памяти с ними вполне спокойно можно работать.

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

уже к сожалению без исходников. но нам и это за счастье.

Так она под тактовую кнопку.

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

Если б я мог тестировать - я бы и сам программу написал. У меня нет такого драйвера, всё импульсное и на сотню ватт...

Извините, про тестирование это скорее всего было galex-у, как инициатору данного движения
Про контроллер: ATtiny45 есть в таком-же узком корпусе, но у нас цена его сравнима с полной ценой драйвера с фасттеча.

Посмотрел про BODSE, вы правы, остается только включить Sleep в Idle, и понизить частоту.

Поколупал код еще, получилось чуть оптимизировать некоторые моменты (выпиливанием библиотечных функций), и включил Sleep в светляке. Понизить битность ШИМ-а думаю в данном случае не получится, так что частота будет 4.7КГц. Про SDM по прерываниям WDT для данного случая это оптимально, но до этого думаю у меня не дойдет.

Прошивки выложу в следующем сообщении, может еще что найду и исправлю, да и не тестированные они.

[Tamagotchi]

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

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

Это легко лечится - PROGMEM Вам в помощь.

#include <avr/pgmspace.h>
const uint16_t bat_volt[5] PROGMEM = {...};
pgm_read_word(&bat_volt[i]);

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

Маловато здесь заблуждений.

В основном так считают ассмеблерщики, не читавшие доку к компилятору

[INFERION]

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

В основном так считают ассмеблерщики, не читавшие доку к компилятору

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

1. Как заставить прерывание выполнить 6 инструкций за 13 тактов (с учётом перехода на вектор и возврата из обработчика) в Си - я так и не понял.
2. Вопрос с переполнениями переменных меня тоже до сих пор волнует. Мне часто нужно при переполнениях записывать минимальное или макимальное значение в результат. Как это реализовать на Си без завышения разрядности промежуточных переменных? В ассемблере я могу просто выборочно контролировать флаг переполнения спец. инструкциями, что позволяет уменьшить разрядность переменных и ускорить вычисления.
3. Как мне расположить переменные в РОН, и не таскать их постоянно с ОЗУ и обратно, когда это лишнее? А если мне необходимо ряд переменных в разном порядке в разных участках кода извлекать - оптимизирует ли компилятор их в памяти так, чтоб доступ был максимально быстрым и компактным (без записи в указатель константы каждый раз перед загрузкой каждой переменной)?

[Tamagotchi]

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

А вот лично ты пробовал кодить на ассемблере?

Я это делал, когда ты еще в колыбельке лежал. для 8086 процессоров. Даже игры писал. Потом, когда компьютеры стали серьезней и языки пришлось применять посерьезней. Причем начинал на ПК Вектор-06Ц

[DooMmen]

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

Это легко лечится - PROGMEM Вам в помощь.

#include <avr/pgmspace.h>
const uint16_t bat_volt[5] PROGMEM = {...};
pgm_read_word(&bat_volt[i]);

Попробовал, но где-то затесался 1 байт который копируется монстроидальным куском кода в оперативу и каждый вызов pgm_read_word забирает 12 байт памяти, хотя можно все предусмотреть и вложиться в 3 команды (6 байт) + один кусок кода для чтения памяти выполненный в виде подпрограммки.

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

[INFERION]

Tamagotchi, а, сорри. Было такое, помню. Только AVR явно не вписывается в категорию тяжеловесов с серьёзными программами, которые проще поднимать на ЯВУ. Меня интересуют попытки применительно к AVR, поскольку подобные камушки не имеют толкового Сишного компилятора (имхо), зато ассемблер для них почти сказка.

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

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

Мне нужно поднять цифровой усилитель с USB интерфейсом на STM32F4. Си меня харит, поскольку к ресурсам даже у этого камня требования жесткие. Прерывания каждые 1000 тактов, в каждом прерывании просто масса данных для обработки. Ассемблер это осилит, но что делать, когда камень не поддерживает его официально? Говорят в ту архитектуру лучше самому не лезть, в Сишном компиляторе учтена масса подводных камней. Есть DMA, куча аппаратных плюшек, которые позволяют закостылить унылость языка. Так что хочешь, не хочешь, а приходится писать программу на Си. И мне полезно было бы узнать у гуру, как обойти перечисленные мною выше косяки его компилятора, потому что именно они меня сейчас останавливают его осваивать серьёзнее. Мне необходимы отменные динамические характеристики системы. Я должен знать что делает камень, и в какие моменты времени он это делает. А качество звучания напрямую зависит от того матана, который туда влезет. И на ассемблере бы его наверняка влезло больше. Хочется верить, что глубокое изучение Сишного компилятора позволит писать терпимый код. Альтернативы просто уже не оставляют.

[DooMmen]

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

зато ассемблер для них почти сказка.

Ассемблер для PIC-ов сказка с их 32-мя инструкциями (хотя с работой с портами я толком и не разобрался и копировал кусок рабочего кода), а для новичка на АВР легче бейсик или если он знает - Си.

INFERION, я видел работу с портами на асме для STM8, и даже на Си с использованием библиотек код был громоздкий и ужастный в понимании, про STM32F4 я даже боюсь представить. Да еще и USB стек поднимать на асме (я уже таким занимался для AT90USB162 - исходников на Си было валом, но основной код был давно написан на асме, но я справился с задачей). Полезную информацию о Си и я не против узнать

Выкладываю две новые версии прошивки. Не протестированные!
LD_7135_v_2.6 - оптимизировал, добавил Idle в светляке.
LD_7135_v_2.6(LF) - то-же только частоту понизил еще в 2 раза, правда частота ШИМ-а то-же понизилась в двое.

[INFERION]

[DooMmen][/@],

Я PIC изучал, мне не понравился. Там такая же ситуация как и в Си - вроде операторов инструкций мало, а на практике хрень получается. Не хватает очень ценных и удобных инструкций из системы команд AVR, и приходится огородить полотна. Плюс заморочек много с банками памяти, условными переходами и т.п. Да и они не тянут конкуренцию ни по набору периферии, ни по быстродействию, ни даже по розничной цене...

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

про STM32F4 я даже боюсь представить.

Да нормально там всё. Памяти хоть жопой жуй, архитектура 32-х битная, а её отлично переваривает компилятор. Подсматривал ассемблерный код в дебаггере, когда стандартная функция не могла кварц запустить, так вполне адекватно всё скомпилило - я бы и сам так написал. Но это пока процедуры простые и шаблонные, а если я захочу извратится - опять же не смогу построить СДМ на переполнении переменной так же просто и быстро, как на ассемблере. По крайней мере я не знаю как это тут сделать. С удовольствием бы и дальше писал под него на Си, если б не такие моменты. Но система команд - вот тут реально песня, куда там тому PIC? Почти каждая инструкция умеет выполнять действие и тут же переходить по условию. Указывается три операнда - что с чем скрещивать и куда ложить результат. Одной инструкцией можно обрабатывать или перетаскивать сразу целые массивы данных, есть аппаратное умножение и деление за 1 такт (вообще мечта AVR'щика, ещё и 32/32), даже с плавающей запятой! Периферия очень мощная, в регистрах можно утонуть. Но... По ассемблеру информации мало, а те ресурсы, где любители потихоньку раскрывали эту тему - заглохли. На периферии. Видать какие-то подводные камни, которые учитываются компилятором, но не задокументированы...

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

Да еще и USB стек поднимать на асме

На Си почти поднял, не думаю что на ассемблере было бы сложнее. Стандартную библиотеку я так и не вкурил, поэтому всё равно всю возню писал руками. Сложнее не поднять, а с компом подружить. Этот же как устроит допрос "кто такой? зачем пришел? что умеешь?...", а тебе уже и гугл разводит руками. Ещё и винда шлёт пакеты как ей удобнее. Вверх ногами, задом на перёд, шиворот навыворот, а ты сидишь и пытаешься понять что оно хочет. Говорю ему NACK, а он мне "сам дурак!" и обижается... Причём 7-ка хуже XP. Бедные разработчики стандартного оборудования...

Всё, прекращаю оффтопить...

[galex]

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

Не протестированные!

посмотрел.
светляк, общее потребление/ непосредственно светодиод
26 - 1,92мА / 0,32мА
26LF - 2,32мА / 1,32мА

видимо мультиметр не успевает отрабатывать. надо осциллографом глядеть чтоли..
а может успевает, просто стабы тоже успевать начали на более низкой частоте...
но померил потребление одного драйвера с 26LF по режимам от мунлайта до максимума,

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

добавил Idle в светляке.

1-1-1.09-1.42-2.32мА
светляк не отличается от младшего режима с шим. видимо не работает или не дает эффекта

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

[Tamagotchi]

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

добавил Idle в светляке

Если это заключается во вставке sleep_cpu(); в цикле, то работать не будет. Дальше не вникал.

[DooMmen]

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

Если это заключается во вставке sleep_cpu(); в цикле, то работать не будет.

Почему? SE я выставил при инициализации, но теперь контроллер просыпается по WDT и ADC (первый надо отключить), оставил для контроля АКБ.
galex, светляк и так в шиме работает, только в последней прошивке надо будет уровень понизить. Токи при каком напряжении замеряли? Если на заряженном АКБ - эффект есть. Если низкочастотная будет нормально работать - буду допиливать ее, и может себе поставлю.

[Tamagotchi]

[DooMmen][/@], , тогда может быть. Надо внимательнее посмотреть.

[galex]

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

светляк и так в шиме работает

я про то, что нет разницы в потреблении самого драйвера в светляке (с шим естественно) и со слабым режимом (который посредством ШИМ реализован).
если idle используется в светляке, но не используется в слабом (я не смотрел еще исходники, вы написали что только в светляке его прикрутили)- значит idle не работает или не дает эффекта.
либо он рабоатет и в других режимах

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

Токи при каком напряжении замеряли?

3.85В выставил на БП

перепроверил осциллографом (26LF), так и есть 2.3мА общее, 1.3мА диод
выставил 4.2В - то же самое.

[Tamagotchi]

[DooMmen][/@],
Bit 5 – SE: Sleep Enable
The SE bit must be written to logic one to make the MCU enter the sleep mode when the SLEEP instruction is executed. To avoid the MCU entering the sleep mode unless it is the programmer’s purpose, it is recommended to write the Sleep Enable (SE) bit to one just before the execution of the SLEEP instruction and to clear it immediately after waking up.

Хотя, если вдуматься - здесь обратная ситуация. А зачем его усыплять? Что я пропустил?

[DooMmen]

Tamagotchi, бит SE предназначен для защиты от случайного засыпания, а пытаемся усыпить для уменьшения потребления.

galex, а что такое слабый? Светляк переключается рампингом и стоит у меня по 3м кликам. Вечером еще код поколупаю, но уменьшение уже есть.

[galex]

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

а что такое слабый?

который идет перед постоянным включением 1х7135. 110ма примерно

[DooMmen]

galex, Idle работает только в светляке.

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

я про то, что нет разницы в потреблении самого драйвера в светляке (с шим естественно) и со слабым режимом (который посредством ШИМ реализован).

Так светляк максимум 50% ШИМ, а минимальный - 100%. Если в них нет разницы по потреблению - надо смотреть, а если сравнивать с светляком - разница в 1мА обычно не уловима.

Подкорректировал уровень ШИМ в низкочастотной версии. Проверяйте, только желательно проверить свечение светодиода в светляке во всем диапазоне напряжений. WDT отключать не стал, так как разница будет почти не заметна, но если есть желание проверить - могу вырубить. Если все нормально будет - более глобально переписываю с изменением таймингов (мне в SOS не нравилась пауза между пакетами, а памяти жалко, но сейчас можно будет исправить).