Если посмотреть бэкграунд статьи, то автор только начинает изучать встроенное программирование. Но выбранный им путь довольно странный, аргументация тоже.
А задачи, где требуется 100% предсказуемый код, — это все же далеко от DIY. И там готовы оплатить сложность разработки такого кода, но зачем это в хобби, мне не понятно.
Это все конечно интересно и увлекательно, ковыряться в нутре у процессора, но вы же отдаете себе отчет, что на таком низком уровне вы не использутее и 10-й части потенциала процессора в своих программах — просто жизни не хватит разобраться во всех его модулях и написать все необходимые драйверы. Новичкам такой путь я точно не стану рекомендовать.
Кстати, говоря о доверии к чужому коду — вы недооцениваете помощь сообщества в выявлении багов. Уверяю, вы наделаете гораздо больше ошибок, чем имеет фреймворк, который используют тысячи пользователей и который развивается не один год.
Сейчас можно писать сложнейшие программы, вообще не вникая в то, что фреймворк делает на низком уровне, в 99% случаев этого не потребуется. И только когда программа не работает как надо и в своем коде вы уверены — есть смысл поискать ошибку во фреймворке, библиотеке, заглянуть в errata на процессор и в крайнем случае, в компиляторе.
Ну регистрировать может и не было смысла, а разве недостаточно просто опубликовать архив в подтверждаемых источниках, тем самым зафиксировав свое первоочередное авторское право? может это они и имеют ввиду под регистрацией. Тогда не так важно, что там есть уже чьи-то мелодии, главное что там есть новые и они уже «сочинены».
С двумя моторами колесные тележки обладают отличной маневренностью, что согласуется с числом измерений на плоскости. Неужели нет шагающей кинематики с двумя степенями свободы?
LDO нужен для точного регулирования с небольшим перепадом вход-выход. Большой перепад (с 12 до 3 В например) выделится в виде тепла, и даже если вход расчитан на большие напряжения, — это плохая идея. Снижайте импульсным DC/DC и потом уже дайте поработать LDO в нормальном режиме.
Все верно, главная проблема даже не низкое освещение или штатив, а именно плохое освещение — иногда неполный или смешанный спектр и практически всегда неравномерное, с посторонними бликами и засветкой. Хотя я встречал книги по искусству, в которых на разворот печатались джипеги в ужасном разрешении. Видимо, издатели не заморочились с получением официальной репродукции в хорошем качестве.
С одной стороны, он же проявлял заботу об этом произведении, и если бы не это — с картины нельзя было бы снять копию. Выкуп произведений из частных коллекций, хранение, экспонирование — это все стоит денег, и логично попытаться это компенсировать доступными способами, тем более у нас есть такой закон. С другой стороны, в цифровой век можете, хранение и распространение цифровой копии уже не может стоить каких то ощутимых денег. И законы пора пересмотреть.
Ещё вспомнил, что разряд конденсатора на катушку, это не один импульс, а колебательный процесс. Из-за гистерезиса железа, чем выше частота, тем меньше КПД так как некоторое время сила действует в обратном направлении, пока железо не перемагнитится. Интересно это тоже прикинуть в расчетах, и логично в начале разгона выбирать более индуктивную катушку. Ещё интересно, были ли попытки сделать пушек по принципу асинхронного линейного двигателя, у них КПД очень приличный.
Вместо одного мощного, но короткого импульса, который вгоняет сердечник в насыщение и расходуется впустую, лучше сделать серию мелких, разрядив каждый конденсатор из сборки отдельно. и намотку сделать распределенной, чтобы поле всегда опережало пулю. И этот убойный тиристор не понадобится, и КПД в разы вырастет.
Eclipse как IDE на голову выше и бесплатный. Компилятор — gcc для ARM, не сравнивал с Keil по качеству но на больших проектах вполне успешно справляется.
Еще в разработке для встраиваемых устройств иногда идет битва за каждую лишнюю инструкцию или место в стеке. И иногда goto остается единственным решением, когда и код красив и понятен, и работает оптимально.
Конечно, разница с вашим примером огромная, но и это доказательство «верно для 99% чисел» противоречит духу чистой математики и больше подходит физикам, о чем я и написал.
Но если задача слишком сложная, а решить очень хочется — то делают :) Вот данная статья — пример. 1% оставили недоказанным. Если бы она имела практическое значение — это все еще много. Так что в чем смысл и радость от такого «физческого» доказательства, не очень понятно.
сорри, ошибся стрелочкой, хотел плюс поставить. Но отсутствие опровержения вполне очевидно — тогда бы эту задачу давно вычеркнули из списка нерешенных. И также можно предположить, что начало множества уже все перебрали, насколько позволяет современная вычислительная техник, так что «попробовать скриптом» не прокатит.
Про разница в 2 порядка не знал, но это всего лишь задержка в несколько секунд.
А вес — ну не на лампах же собирают сейчас, по сути линза + матрица + спец. процессор много весить не должны. Да и датчик один из самых важных, нельзя на нем экономить.
PS: под экономить имел ввиду затраты на разработку, т.е. не брать проверенные решения из 60х, а сделать быстрее, точнее и надежнее на современной элементной базе.
А задачи, где требуется 100% предсказуемый код, — это все же далеко от DIY. И там готовы оплатить сложность разработки такого кода, но зачем это в хобби, мне не понятно.
Кстати, говоря о доверии к чужому коду — вы недооцениваете помощь сообщества в выявлении багов. Уверяю, вы наделаете гораздо больше ошибок, чем имеет фреймворк, который используют тысячи пользователей и который развивается не один год.
Сейчас можно писать сложнейшие программы, вообще не вникая в то, что фреймворк делает на низком уровне, в 99% случаев этого не потребуется. И только когда программа не работает как надо и в своем коде вы уверены — есть смысл поискать ошибку во фреймворке, библиотеке, заглянуть в errata на процессор и в крайнем случае, в компиляторе.
Вспомнил, у Lego mindstorm был условно шагающий робот с двумя моторчиками. Есть совсем простые, а вот посложнее: https://youtu.be/v6O-cvE7aDM
С двумя моторами колесные тележки обладают отличной маневренностью, что согласуется с числом измерений на плоскости. Неужели нет шагающей кинематики с двумя степенями свободы?
Все верно, главная проблема даже не низкое освещение или штатив, а именно плохое освещение — иногда неполный или смешанный спектр и практически всегда неравномерное, с посторонними бликами и засветкой. Хотя я встречал книги по искусству, в которых на разворот печатались джипеги в ужасном разрешении. Видимо, издатели не заморочились с получением официальной репродукции в хорошем качестве.
С одной стороны, он же проявлял заботу об этом произведении, и если бы не это — с картины нельзя было бы снять копию. Выкуп произведений из частных коллекций, хранение, экспонирование — это все стоит денег, и логично попытаться это компенсировать доступными способами, тем более у нас есть такой закон. С другой стороны, в цифровой век можете, хранение и распространение цифровой копии уже не может стоить каких то ощутимых денег. И законы пора пересмотреть.
Закрутить снаряд можно и до выстрела в отдельном блоке, в том числе и вращающимся магнитным полем.
Ещё вспомнил, что разряд конденсатора на катушку, это не один импульс, а колебательный процесс. Из-за гистерезиса железа, чем выше частота, тем меньше КПД так как некоторое время сила действует в обратном направлении, пока железо не перемагнитится. Интересно это тоже прикинуть в расчетах, и логично в начале разгона выбирать более индуктивную катушку. Ещё интересно, были ли попытки сделать пушек по принципу асинхронного линейного двигателя, у них КПД очень приличный.
Вместо одного мощного, но короткого импульса, который вгоняет сердечник в насыщение и расходуется впустую, лучше сделать серию мелких, разрядив каждый конденсатор из сборки отдельно. и намотку сделать распределенной, чтобы поле всегда опережало пулю. И этот убойный тиристор не понадобится, и КПД в разы вырастет.
А вес — ну не на лампах же собирают сейчас, по сути линза + матрица + спец. процессор много весить не должны. Да и датчик один из самых важных, нельзя на нем экономить.
PS: под экономить имел ввиду затраты на разработку, т.е. не брать проверенные решения из 60х, а сделать быстрее, точнее и надежнее на современной элементной базе.