Это имхо напоминает пословицу — пока толстый сохнет — худой дохнет. К моменту, когда исходно стройно написанная на чистом SQL система настолько обрастает костылями, что с трудом поддерживается, ее ORM-based брат уже обычно существует в состоянии зомби, не в силах переварить ни объем данных, ни интенсивность запросов к ним, ни конкурентность их модификации.
Очень классная идея для DIY-применений. Однако, если в системе, получающей информацию с такого датчика, нужно отслеживать не только динамику, но и абсолютные значения, то нужно предусмотреть калибровку — так как параметры светоизлучения диода и сопротивления фоторезистора сильно зависят от температуры.
И еще — если вы собирали трубку при комнатной температуре и герметично заткнули ее диодом и фоторезистором с обеих сторон, то при охлаждении внутри нее выпадет роса, что изменит ее светопроводящие свойства — нужно при сборке заполнять азотом :)
Вопросы по чиби:
1. Хватило ли вам возможностей HAL, или где-то все-таки пришлось залезать на уровень непосредственной работы с периферией?
2. Были ли нарекания к работе мультипроцессного ядра и синхронизационных примитивов?
3. Работает ли проект с включенным контролем режима вызова системных функций?
4. Были ли подозрения или явные признаки временных лагов из-за использования системных вызовов?
Еще можно отдать расчет момента включения на откуп аналоговой части — заряжать конденсатор через резистор от выпрямленного мостовым выпрямителем сетевого напряжения (приведенного к диапазону АЦП естественно) — тогда напряжение на конденсаторе примерно будет пропорционально площади (то есть мощности), «отрезаемой» от полного периода сигнала части. Если на кристалле есть компаратор с программно-устанавливаемым порогом, то нужно просто рассчитать его величину соответственно необходимой мощности в нагрузке, а выход компаратора соединить с управлением симистора. Если же компаратора нет, а есть просто АЦП — то тогда обрабатывать по прерываниям в однократном режиме, и проверять значения программно. Нужно только как-то обеспечить, чтобы после выдачи управляющего сигнала конденсатор оставался зашунтированным, готовым к интегрированию напряжения в следующем цикле (в двухполюснике, которым является ваш выключатель, такое условие соблюдалось бы автоматически, если бы не двухполупериодный выпрямитель, который не даст разрядиться конденсатору через открытый симистор)
Интересно, хватит ли свободных ресурсов, чтобы сделать программный ФАПЧ с приемлемой точностью (например, 5 градусов) на частоту 50Гц?
Например, оцифровывать аналоговый сигнал напряжения сети (достаточно будет порядка пары десятков измерений за период 20 мс), исходя из оцифрованных значений вычислять текущую частоту и фазу, и соответственно предсказывать переходы через ноль и соответственно заряжать PWM таймер на периодическое срабатывание с нужной скважностью? Нужен будет еще один свободносчитаемый таймер для временной оси (необязательно завязанный на прерывания), с него программно можно считывать показания в обработчике прерывания АЦП, сохраняя пары (время: значение)
Прошу прощения — неправильно выразился — следует читать не «скрыть RTOS'ом», а «скрыть HAL'ом кросплатформенного RTOSа».
Хорошая обертка-абстракция вокруг стандартной периферии позволяет унифицированно реализовывать типичные или рутинные действия — например, правильно инициализировать периферию при старте, конфигурировать систему прерываний и обработчиков, режимы таймеров, контроллеров аппаратных проводных интерфейсов итд.
Конечно, такой слой абстракции может чего-то стоить в плане объема кода и производительности, но может быть и абсолютно бесплатным — если сделан на макросах/условной компиляции
Я же совсем не против Си в процессе освоения новой для разработчика архитектуры — я всего лишь говорил, что Си закрывает только половину проблемы, а другую можно было бы закрыть кроссплатформенной RTOS — тогда «цена входа» была бы заметно ниже.
С другой стороны, полноценно использовать систему команд, только наблюдая ее элементы в отладчике или листинге, имхо невозможно. В программировании на ассемблере есть свои паттерны — передача управления, параметров, работа с прерываниями/контекстом, арифметикой/условиями/флагами, структурами данных итд — и только опыт позволяет эффективно и практически подсознательно реализовывать их имеющимися в том или ином ядре средствами. Система команд — как набор инструментов в руках автомеханика — можно легко перечислить ключи и головки, но что, как, и в какой последовательности применить — появляется только с практическим опытом.
Из этого вывод — хотите 100% представлять и осознавать, что делает контроллер, выполняя вашу программу — начинайте изучение с уровня ассемблера. Потом для экономии времени можно будет перейти на Си. Хотите начать с более общего уровня — начинайте с Си, причем периферию и библиотеки производителя можно скрыть RTOS'ом — будет проще и легче — но не факт, что вы когда-нибудь доберетесь до полного понимания деталей/особенностей архитектуры.
Проблема «кросплатформенности» (с точки зрения освоения нового ядра разработчиком) для МК имхо не столько в изучении соответствующего ассемблера, сколько в наборе периферии и способах работы с ней.
И здесь Си сам по себе сильно не помогает, так как обычно большинство реализуемой на МК программной логики так или иначе завязано на взаимодействие с периферией (напрямую, или с использованием макросов и подпрограмм из фирменных оберток). Если ресурсы позволяют, то хорошим дополнением к писанию на Си может быть использование какой-нибудь RTOS, имеющий платформонезависимый (ну, почти) HAL. Я в последнее время смотрю в сторону ChibiOS
Кошмар. Средствами SQL — два подзапроса или временных таблицы-генератора для месяца и диапазона лет, подзапрос с cross join с ними внутри, дальше inner join с occupation histories по datepart(year… и datepart(month… и затем count / group by — как-то так
В стандартном SQL-профайлере есть очнь важная вещь, которой здесь нет — оценка трудоемкости выполнения запроса в терминах CPU/disk/IO cost — это гораздо важнее, чем время выполнения, которое в однопользовательском режиме с тестовыми данными практически ни о чем не говорит. Вернее, как — все, что выполняется больше, чем за период тика системного таймера при разработке — скорее всего будет приносить проблемы с производительностью в продакшене.
С другой стороны, польза тула несомненно есть — хотя бы для того, чтобы показать, чего стоит на стороне бакенда «легкость» манипулирования данными средствами EF
Тут имхо фишка в простоте — используя только средства встроенной периферии, программно сделать счетчик эл. энергии. Тот факт, что нагрузка — резистор, имхо означает, что предназначение устройства — скорее всего измерение запасенной энергии элементов питания. Больше ничего из слаботочных устройств с постоянным сопротивлением не приходит в голову (разве что микромощный нагреватель :))
Другое дело, что встроенными средствами можно решить задачу и в более общем виде, если на кристалле есть программно-управляемый предусилитель и допустимо ставить шунт в общий провод
даже такой, казалось-бы простой девайс как электродвигатель, не может рассматриваться как активная нагрузка с постоянным сопротивлением из-за своей индуктивности
электродвигатель прежде всего не может рассматриваться как нагрузка с постоянным сопротивлением из-за своей сути преобразования электрической энегрии в механическую, а потом уже из-за электрических и механических потерь — все-таки его КПД гораздо ближе к 100%, чем к нулю :)
Применение очень узкое, если рассчитывать только на постоянное сопротивление нагрузки — лучше бы измерять ток по падению напряжения на шунте — правда сразу здесь будут проблемы — ставить шунт в нулевой провол не всегда допустимо, а в питающий — нужна схема сдвига уровня, причем прецизионная и с малым дрейфом нуля. Похожие проблемы будут и с внешним ОУ — вблизи нуля они обычно усиливать не умеют (придется городить двуполярное питание), и дрейфом обладают неслабым. Лучше всего использовать внутренний предусилитель на кристалле, если есть — его дрейф можно программно обработать и скомпенсировать.
И потом — интегрировать по времени имхо все-таки лучше в самом чипе, а не на хосте — для этого придется изобрести простенькую систему команд {сброс, начатьнакопление, остановитьнакопление, считатьтекущие} — тогда точность не будет зависеть от временных диаграмм совсем не риалтаймового десктопа
у Ильфа и Петрова в Двенадцати стульях есть фраза о том, что параллельно существуют два мира — маленький и большой. Условно говоря, в маленьком мире делают головоломки, а в большом — прокладывают дороги и строят ГЭСы. И та, и другая работа требует длительных умственных усилий и высокой концентрации внимания — но масштаб результата оказывается несопоставим.
Да, хорошо написанный ассемблерный код вызывает радость и уважение к создателю, но например, такое же уважение к создателю может вызывать и хорошо спроектированная ERP-система, причем просто при взгляде на блок-диаграмму (даже не на диаграмму классов, API, или сам код) — в последнем случае уровень обобщения скрывает не только регистры, но и архитектуры целиком ;)
Вы — практически последний из могикан, еще продолжающих писать большие системы целиком на ассемблере. Еще десяток лет — и этого исчезающего диалекта никто не поймет :(
...20 лет назад темой моего диплома был драйвер платы сигнального процессора TMS320, написанный на x86 ассемблере. На вводном занятии о «гайдлайнах» написания диплома я услышал предсказуемое «если ваш диплом — программа, вы должны обосновать выбор языка программирования», на что мой немного борзый вопрос был «если я собираюсь забить гвоздь, должен ли я аргументировать, что выбрал для этого молоток?». Преподаватель, читавший у нас курс по ОС, задумался лишь на секунду: «Если у Вас драйвер, вы можете не обосновывать, почему выбрали Ассемблер»
Это я к тому, что чистый асм в ядре ОС и драйверах и сейчас еще может быть понят и оценен, хотя я, написав когда-то целиком на асме свою простенькую дисковую ОС и утилиты к ней, не могу утверждать, что в современных условиях это все же стопроцентно правильный путь.
Тем не менее, усилия приложены огромные, и главное, очевидна последовательность в достижении цели (на Ассемблере иначе нельзя — все развалится). Автору за проделанную работу — огромное личное уважение!
Однако, если подобное качество проектирования использовать в разработке систем на языках высокого уровня, то масштаб полученной системы может быть воистине грандиозным — например, класса системы управления Вояджера и сопровождения его с Земли. Ведь умение программировать на Ассемблере — это отнюдь не знание инструкций, а скорее коренное понимание процессов в системе и необходимых для эффективной и надежной работы действий. И именно этот Ваш потенциал, как разработчика, можно использовать для создания гораздо более масштабных систем — надежных, компактных, быстрых.
Это то, чего сейчас хронически не хватает в коммерческом IT, заселенном попсарями-недоучками — образно говоря, вместо ладно скроенных легких и надежных деревянных парусных кораблей, современная коммерческая IT- индустрия пачками создает тяжелые дырявые посудины, текущие памятью так, что с трудом способны с помощью многоядерного двигателя с дойти из порта в порт, с риском потонуть, несмотря на помпы (GC) и приставленных специалистов, готовых в любую минуту начать рейс сначала.
Одним из методов увеличения вероятности обнаружения ошибок синхронизации может являться метод искусственного расширения критических секций, например, вставкой специальных вызовов, регистрирующих последовательность выполнения и/или осуществляющих временную задержку, после каждого оператора секции. Это можно сделать средствами условной компиляции (сильно визуально загромождает код), или специального препроцессинга.
И еще — если вы собирали трубку при комнатной температуре и герметично заткнули ее диодом и фоторезистором с обеих сторон, то при охлаждении внутри нее выпадет роса, что изменит ее светопроводящие свойства — нужно при сборке заполнять азотом :)
1. Хватило ли вам возможностей HAL, или где-то все-таки пришлось залезать на уровень непосредственной работы с периферией?
2. Были ли нарекания к работе мультипроцессного ядра и синхронизационных примитивов?
3. Работает ли проект с включенным контролем режима вызова системных функций?
4. Были ли подозрения или явные признаки временных лагов из-за использования системных вызовов?
Например, оцифровывать аналоговый сигнал напряжения сети (достаточно будет порядка пары десятков измерений за период 20 мс), исходя из оцифрованных значений вычислять текущую частоту и фазу, и соответственно предсказывать переходы через ноль и соответственно заряжать PWM таймер на периодическое срабатывание с нужной скважностью? Нужен будет еще один свободносчитаемый таймер для временной оси (необязательно завязанный на прерывания), с него программно можно считывать показания в обработчике прерывания АЦП, сохраняя пары (время: значение)
Хорошая обертка-абстракция вокруг стандартной периферии позволяет унифицированно реализовывать типичные или рутинные действия — например, правильно инициализировать периферию при старте, конфигурировать систему прерываний и обработчиков, режимы таймеров, контроллеров аппаратных проводных интерфейсов итд.
Конечно, такой слой абстракции может чего-то стоить в плане объема кода и производительности, но может быть и абсолютно бесплатным — если сделан на макросах/условной компиляции
С другой стороны, полноценно использовать систему команд, только наблюдая ее элементы в отладчике или листинге, имхо невозможно. В программировании на ассемблере есть свои паттерны — передача управления, параметров, работа с прерываниями/контекстом, арифметикой/условиями/флагами, структурами данных итд — и только опыт позволяет эффективно и практически подсознательно реализовывать их имеющимися в том или ином ядре средствами. Система команд — как набор инструментов в руках автомеханика — можно легко перечислить ключи и головки, но что, как, и в какой последовательности применить — появляется только с практическим опытом.
Из этого вывод — хотите 100% представлять и осознавать, что делает контроллер, выполняя вашу программу — начинайте изучение с уровня ассемблера. Потом для экономии времени можно будет перейти на Си. Хотите начать с более общего уровня — начинайте с Си, причем периферию и библиотеки производителя можно скрыть RTOS'ом — будет проще и легче — но не факт, что вы когда-нибудь доберетесь до полного понимания деталей/особенностей архитектуры.
И здесь Си сам по себе сильно не помогает, так как обычно большинство реализуемой на МК программной логики так или иначе завязано на взаимодействие с периферией (напрямую, или с использованием макросов и подпрограмм из фирменных оберток). Если ресурсы позволяют, то хорошим дополнением к писанию на Си может быть использование какой-нибудь RTOS, имеющий платформонезависимый (ну, почти) HAL. Я в последнее время смотрю в сторону ChibiOS
С другой стороны, польза тула несомненно есть — хотя бы для того, чтобы показать, чего стоит на стороне бакенда «легкость» манипулирования данными средствами EF
Другое дело, что встроенными средствами можно решить задачу и в более общем виде, если на кристалле есть программно-управляемый предусилитель и допустимо ставить шунт в общий провод
электродвигатель прежде всего не может рассматриваться как нагрузка с постоянным сопротивлением из-за своей сути преобразования электрической энегрии в механическую, а потом уже из-за электрических и механических потерь — все-таки его КПД гораздо ближе к 100%, чем к нулю :)
И потом — интегрировать по времени имхо все-таки лучше в самом чипе, а не на хосте — для этого придется изобрести простенькую систему команд {сброс, начатьнакопление, остановитьнакопление, считатьтекущие} — тогда точность не будет зависеть от временных диаграмм совсем не риалтаймового десктопа
Да, хорошо написанный ассемблерный код вызывает радость и уважение к создателю, но например, такое же уважение к создателю может вызывать и хорошо спроектированная ERP-система, причем просто при взгляде на блок-диаграмму (даже не на диаграмму классов, API, или сам код) — в последнем случае уровень обобщения скрывает не только регистры, но и архитектуры целиком ;)
...20 лет назад темой моего диплома был драйвер платы сигнального процессора TMS320, написанный на x86 ассемблере. На вводном занятии о «гайдлайнах» написания диплома я услышал предсказуемое «если ваш диплом — программа, вы должны обосновать выбор языка программирования», на что мой немного борзый вопрос был «если я собираюсь забить гвоздь, должен ли я аргументировать, что выбрал для этого молоток?». Преподаватель, читавший у нас курс по ОС, задумался лишь на секунду: «Если у Вас драйвер, вы можете не обосновывать, почему выбрали Ассемблер»
Это я к тому, что чистый асм в ядре ОС и драйверах и сейчас еще может быть понят и оценен, хотя я, написав когда-то целиком на асме свою простенькую дисковую ОС и утилиты к ней, не могу утверждать, что в современных условиях это все же стопроцентно правильный путь.
Тем не менее, усилия приложены огромные, и главное, очевидна последовательность в достижении цели (на Ассемблере иначе нельзя — все развалится). Автору за проделанную работу — огромное личное уважение!
Однако, если подобное качество проектирования использовать в разработке систем на языках высокого уровня, то масштаб полученной системы может быть воистине грандиозным — например, класса системы управления Вояджера и сопровождения его с Земли. Ведь умение программировать на Ассемблере — это отнюдь не знание инструкций, а скорее коренное понимание процессов в системе и необходимых для эффективной и надежной работы действий. И именно этот Ваш потенциал, как разработчика, можно использовать для создания гораздо более масштабных систем — надежных, компактных, быстрых.
Это то, чего сейчас хронически не хватает в коммерческом IT, заселенном попсарями-недоучками — образно говоря, вместо ладно скроенных легких и надежных деревянных парусных кораблей, современная коммерческая IT- индустрия пачками создает тяжелые дырявые посудины, текущие памятью так, что с трудом способны с помощью многоядерного двигателя с дойти из порта в порт, с риском потонуть, несмотря на помпы (GC) и приставленных специалистов, готовых в любую минуту начать рейс сначала.