Да... одна вода... и ни о чём...

Угу... "Как правильно кормить лошадь для преодоления межгалактического пространства"...

urry, девочка тестеровщица для того и сидит. А голову пеплом, если вместо девочки тестеровщицы окажется пользователь.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Опять мы с Вами не совсем друг друга понимаем. Я говорил не о соотношении в конечном продукте, а о соотношении навыков. Возвращаясь к приведенному Вами примеру, можно пояснить, что мне вряд ли придет в голову браться за написание самой обработки звука, зато я смогу разработать и вывести в производство железо, а также дать программисту-прикладнику HAL API для чтения того же АЦП и вывода в ЦАП, написать каркас, обеспечивающий работу аппаратуры и вызов функций из модуля обработки, написанного программистом.

Так вот, при этом можно до определенной степени забыть, что обработка выполняется не на ПК - программист может руководствоваться моими рекомендациями (например, использовать только фиксированную точку, ограничения по памяти) и использовать API, тестируя код на ПК с применением любого арсенала средств. Но вот сам низкоуровневый API следует отлаживать только в железе. ICD придумали далеко не зря.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Я же специально указал размер pdf - 26 Мб, перед открытием он должен закачаться. Вот ссылка на оригинал: avr course book.

Это мануал, по которому обучает школьников и студентов один товарищ из Новой Зеландии:

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Смотря как гасить. Про исключения - это о программах для ПК насколько я понял? Если без уведомления каким-то способом, то плохо, а если с умом, то очень даже хорошо. Я, к примеру, так и делаю. "Гашу" все исключения какие могу, но при этом пишу их очень подробно автоматически в журнал ошибок, а ссылку на журнал завожу в меню. Если что-то не так, то прошу мне показать этот журнал (простой текстовой файл с логом). Я считаю ненормальным, когда пользователю выскакивает окно с ошибкой, все ошибки должны быть "тихими", а если что-то не так работает, то нужно обратиться к журналу ошибок (логу) или показать этот лог разработчику.
Мне это очень помогает, где бы и на чём бы я не писал. Нужно просто завести себе простые модули для удобного логирования и набор вариантов кодов обработчиков исключений.

Вот пример. Даже, когда я пишу простой командный скрипт, он у меня тоже пишет лог (в консоль) при помощи простого логгера:

Спойлер

Код:

// Пространство ClassLogger.
function ClassLogger() {

    // Метод getTimeStamp().
    this.getTimeStamp = function( date ) {

        var Day = date.getDate();
        var Month = date.getMonth();
        var Year = date.getYear();

        var Hour = date.getHours();
        var Minutes = date.getMinutes();
        var Seconds = date.getSeconds();

        return ( ( Day > 9 ) ? Day : "0" + Day ) + "." +
                ( ( Month > 9 ) ? Month : "0" + Month )+ "." +
                Year + " " +
                ( ( Hour > 9 ) ? Hour : "0" + Hour ) + ":" +
                ( ( Minutes > 9 ) ? Minutes : "0" + Minutes ) + ":" +
                ( ( Seconds > 9 ) ? Seconds : "0" + Seconds ) + "." +
                date.getMilliseconds();

    }

    // Метод info().
    this.info = function( str ) {

        WScript.StdOut.WriteLine( this.getTimeStamp( new Date() ) + " [INFO ]: " + str );
    }

    // Метод error().
    this.error = function( str ) {

        WScript.StdOut.WriteLine( this.getTimeStamp( new Date() ) + " [ERROR]: " + str );
    }

}

Я когда-то начинал с ассемблера AVR, потом перешёл на С, а когда поработал в одной фирме, где всё пишется на C++, в том числе и ядро прошивки для МК, перешёл на C++. Сейчас пропагандирую этот подход (с разумными ограничениями). Как это я делаю? Я показываю исходный код с примерами и шаблонами (они есть у меня в подписи) и мне не нужно при этом ссылаться на какие-то с кем знакомства. Если человеку это надо, то мне не нужно его уговаривать, он может просто взять и скачать шаблонный проект и посмотреть как это работает живьём. Ещё я делаю сопровождающие ролики на youtube, где показываю тестовые примеры в работе. Вот, к примеру, простой файловый менеджер на ATmega16@16МГц: ATmega16 File Manager . Написать такое на асме или Си, чтобы было удобно сопровождать, очень трудно (для асма, я думаю, даже невозможно). Если кого интересует размеры кода, то весь менеджер уложился в 14,5 кб флеша и где-то 800-900 байт ОЗУ (последняя ревизия). При этом там есть простой просмотрщик текстовых файлов и заготовка для проигрывания wav-файлов (ещё не доделана). После этого любой желающий может прикинуть как бы похожий проект выглядел в его интерпретации на асме или Си и сделать соответствующие выводы. Этот проект демонстрирует модуль для работы с удалённым терминалом при помощи ESC-последовательностей.

Тут на форуме есть тема, где я предлагал всем желающим ознакомиться с данным вопросом (C++ в МК): Шаблоны проектов на C++ для AVR [GCC, IAR] .

Самое простое убеждение - это собственный практический пример.

То есть, если я правильно понял, основная задача труъ эмбеддера в данном случае - припаять MOSI к MOSI, MISO к MISO ("и смотри не перепутай, Кутузов!" (С)), затем свистнуть программера, дать ему пример в пять строчек из даташита, как с этим интерфейсом работать, и на этом все? И пока тот будет корпеть над кодом, на досуге жаловаться всем вокруг, как тот тупит со своими double'ами и printf'ами, которые бездумно сует куда ни попадя?

Если да, тогда я тоже хочу такую работу, где эти волшебные вакансии?

Эмммм... как бы это помягче выразиться... Я уже читал "Windows для чайников", представляю, что такое "файл" и как с ним работать. И pdf'ы ранее уже читал, честное слово.

Ссылка нерабочая, выдает Error 404. Знание, что там лежит (точнее, когда-то лежало) 26 Мб, лишь умножает скорбь, но никак не помогает в деле.

(выделение мое - Goldsmith)

Понятно, большое спасибо, что вовремя предупредили. Сэкономили мне 26 Мб трафика

Когда (если вообще когда-нибудь) дорасту до уровня школьника из Новой Зеландии, возможно, пойму, как на самом деле сложна проблема дребезга контактов и как сильно программирование микропроцессора в одном ящике с периферией (сиречь микроконтроллера) отличается от программирования другого микропроцессора, засунутого в жестяную коробку побольше и называемого ПК. Хотя, учитывая ориентацию на Bascom, возможно, автор действительно прав, а я заблуждаюсь.

Я проверил обе ссылки и обе рабочие, проблема на вашей стороне.


Вот увидите пособие, то поймёте когда именно достигните их уровня, а пока загадывать рано.


Самое банальное отличие - на МК нет соглашений по обработке исключений (ошибок). Это очень, очень большое отличие от программирования на любых больших ПК, я уж не говорю про то, что отсутствие ОС - это тоже нормальное явление.

Отличается... и сильно...
Вот такие понтовитые говнокодеры и создают потом темы... типа... "у NXP неправильно прерывания сделаны, не могу привязать к своей проге"... или "у STM самая отстойная документация"... как недавно на элхе было...
Нет ума - нехрен вообще за МК браться... продолжайте втирать заказчику "эта прога не под AMD, а только под Intel", "у вас памяти мало, надо 32гигабайта минимум", "с видеокартой Radeon работать не будет" и т д. ...

Не увидел логической связи. То есть в процессорах с архитектурой 80x86, на которых строятся PC, обработка исключений изначально присутствует, а на МК ее не может быть, потому что не может быть никогда?

Обработка исключений - функция исключительно программной среды, в которой выполняется приложение. Например, в языке C она отсутствует, хотя в конкретных реализациях средства для этого могут быть (разумеется, нестандартные и непортируемые): например, в MS Visual C под Windows поддерживаются ключевые слова __try, __except и __finally для использования SEH, но другие компиляторы их не понимают, поэтому это не лучший вариант. В общем случае программа, написанная на ANSI C для PC, никаких специальных средств для обработки исключений не имеет.

В C++ исключения уже встроены в язык (хотя еще кривоваты, но по крайней мере уже юзабельны), в Java и C# более отшлифованы; но в любом случае это никак не заслуга микропроцессора, на котором они выполняются.

С другой стороны, имеется продукт под названием CException, написанный все той же командой из Atomic Objects для ANSI C; он позволяет использовать механизм исключений в программах, написанных на стандартном C, в любой среде. Он, конечно, уступает по мощности реализации C++ (поскольку все-таки "настоящие" исключения используют объектные средства, которых нет в ANSI C), но вполне функционален и, главное, не тащит за собой особых накладных расходов; я без проблем применял его даже на младших моделях МК (разумеется, кроме тех случаев, когда любое применение исключений противопоказано в принципе, что тоже бывает).

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

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

Я даже не упоминаю про тот же Embedded Linux... Да, среда не для елочной мигалки, согласен. Но приложения для домашних маршрутизаторов или медиа-центров - это тоже эмбеддинг. Да и новомодные платы на ARM размером с кредитную карту попадают больше в сегмент встраиваемых систем, нежели персональных компьютеров.

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

Занавес...
Все медленно, не толкаясь, переползают на АСМ...

Goldsmith, интересный подход, я такого не знал. Привык видеть в C проектах стандартный приём с HRESULT или его аналогах. Как же это программисты Windows оказались настолько тупыми, что использовали какой-то мутный HRESULT с его битовыми полями вместо такого изящного try-catch блока? Стандарт Си вроде не вчера придумали? Вы что-то от нас скрываете? При любом усложнении каких-либо методов всегда идут на компромисс - что-то находим, а что-то теряем. Так где те проекты на C, который должен выдавать Гугл при запросе об этом подходе? У меня практика критерий и в этом сила

Логическая связь очень простая. Я специально указал эту болевую точку любого проекта, который состоит из многих частей. Вы, как я понял, пишите всё лично и сами, каждый модуль, каждый драйвер и каждую ОС под свой проект, иначе никак не объяснить такую недальновидность. Я же использую части от разных проектов, которые нахожу в сети. Первое, что бросается в глаза - это несовместимость методов обработки ошибок. Хотя они все в общем исповедуют а-ля HRESULT, но выглядит это как самопал в каждом отдельном случае. При этом, если я хочу иметь от системы какую-то степень надёжности, я должен обработку ошибок всего программного комплекса сделать единообразной. Вот в чём фишка. Если проект состоит из множества частей, то обработка ошибок или исключения являются системной скрепой, которая влияет на проект в целом. Если нет единообразия, как я указал, то проект выглядит как Франкенштейн. Нарушение целостности, отсутствие единообразия влияет на сопровождение проекта. Очевидно, что я не первый, кто это заметил, иначе бы этот CException и не появился, так ведь?

На больших ПК есть ресурсы для поддержки работы с исключениями, на МК в общем случае их нет. Её нет не потому, что не может быть никогда, а потому что, если взять конкретные мк и конкретные компиляторы, то можно увидеть, что обработка исключений там не поддерживается, а сферических коней в вакууме мы не обсуждаем. Вам правильно указывают спуститься с небес на землю.

хз, что здесь разнообразного

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

В-третьих, предполагается совместная работа над проектом. О каком "досуге" речь?



Могу скинуть в личку адрес конторы, в которой работаю, если интересно.

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

Стандарт C, к сожалению, придуман даже не позапозавчера, это очень архаичный язык с более чем 40-летней историей. Для своих 1970-х вполне современный, сегодня не вполне отвечает требованиям времени. В развитии очень консервативен, поскольку гарантирует очень хорошую совместимость с прежними версиями. Отсюда и нехватка многих востребованных сегодня средств вроде исключений. Керниган и Ритчи не смогли заглянуть так далеко вперед, а сегодня уже поздно махать кулаками после драки. Поэтому приходится применять внешние "костыли и подпорки" для поддержки тех же исключений. Кстати, Cexception - не единственный инструмент такого рода, есть и аналогичные.

Я не могу ответить за Гугл, могу лишь высказать свое предположение.

Попробуйте ввести в Гугл слово "извЕни", получите: "Результатов: примерно 13 700 000 (0,21 сек.)". И виноват не Гугл, а те, кто засоряет интернет. Спросите у Гугла про учебник по программированию микроконтроллеров - получите Шпака и подобных. Учит Шпак подобным вещам? А ведь многие относятся к этой книге чуть не как к священному писанию. Вот Вам и ответ.

Как говорится, "каков вопрос - таков ответ". Я же нашел и CException, и среду для автоматического модульного тестирования, и автоматический генератор мок-объектов, и фреймворк "квантового программирования", и еще прорву полезнейших инструментов, очень облегчающих программирование МК и повышающих качество кода (вроде тех же исключений). Что читаешь - о том и знаешь.

Совершенно верно. Но только я его целенаправленно искал, чтобы решать эту и подобные проблемы, он был мне реально нужен, равно как и прочие перечисленные инструменты. Без них я вообще не взялся за программирования МК, поскольку основная работа у меня на противоположном "полюсе" - разработка распределенных многосерверных систем, а к комфорту быстро привыкаешь, и аскетизм стандартного C сильно напрягает. Оказалось, для эмбеддинга тоже есть все необходимое, нужно только хорошенько поискать (разумеется, не запросом "хочу всего побольше и сразу" в Гугле, это заняло некоторое время.

Вы ведь только что своими собственными глазами увидели обратное - есть, причем именно в общем случае (ANSI C частным решением назвать трудно). Лежит себе-полеживает в интернете, доступный всем желающим безвозмездно, то есть даром. Более корректный ответ на самом деле другой:Но это скорее субъективная причина. Теперь знаете.

Кто указывает-то? Вроде в нашей беседе таких нравоучений пока еще не проскакивало. И еще немаловажно: откуда конкретно указывают? Если из болота, я вежливо, но твердо откажусь от этого радушного приглашения. Я вряд ли впишусь в тамошнюю экосистему.

Ну само собой, это была лишь шутка. Но в ней, как и в любой другой, лишь некоторая доля шутки, скажем так, любимые нами 80% (а может, даже и 20%).

Я в несколько утрированной форме лишь показал, что можно позволить себе 80/20 лишь в том случае, если за спиной есть поддержка в виде достаточно подготовленного программиста, который напишет проблемно-ориентированную часть на основе грамотно подготовленного HAL. Лично у меня такой поддержки нет, я един во всех лицах - и паять, и кодить. Второй компаньон по бизнесу - машиностроитель-конструктор, занимается другим "железом", более железным и тяжелым. Поэтому "скилл 20-го уровня" попросту не позволит мне решать подобные задачи.

По моему глубокому убеждению, идеальное соотношение для эмбеддера должно быть иным: 100% схемотехники / 100% программирования. Одно другому ну никак не помеха (разве что нехватка времени, но кому сейчас легко?). Тем более в наше-то время качай из интернета хоть черта лысого бесплатно, не нужно шарить по библиотекам, как в еще недавнем прошлом.

Мда, столько мудрствований, а простой pdf по двум разным ссылкам скачать не можете. И как после этого ко всему этому написанному относится? Может начнёте с простого - скачивания файлов из сети? Потом, к примеру, расскажите о минусах этого подхода с CException. Можно ли этот блок использовать в ISR? Да, нет, почему?

ОтноситЬся лучше философски, с учетом того, что ресурсы сети бывают-таки временно недоступны, и в этот момент даже Тим Бернерс-Ли вряд ли что-нибудь скачает, да и ссылка на тот момент была единственной. Сегодня файл доступен, проверил из спортивного интереса (мало ли, а вдруг и правда разучился?). Другое дело, что теперь я доподлинно знаю, что там находится, и необходимость в скачивании отпала.

"Может, начнете с простого (C)" - к примеру, скачаете (Вы ведь умеете, не так ли?) и прочтете документацию, которую разработчики предоставляют вместе с продуктом?Скорее всего, необходимость в импровизированной лекции тут же отпадет.

Если с чтением дело обстоит еще хуже, чем у меня со "скачиванием файлов из сети", могу намекнуть: переход из точки, где возникло исключение, в обработчик реализован через стандартный механизм setjmp/longjmp (собственно, а как иначе это сделать в ANSI C?); представьте, как это будет работать в ISR (в зависимости от того, в каком блоке находится обработчик исключения).

У-у-у, это Вы загнули. Я вот интересуюсь техникой вообще с трех лет, конкретно электроникой - с первого класса, в пятом уже ходил на кружок, а с первого по третий курс университета сам таковой вел (международные грамоты брали, между прочим), и то не могу сказать, что осилил схемотехнику на 100%. Ну, максимум, 80% самых популярных случаев, не включая СВЧ. А еще есть и программирование, которое, вообще говоря, отдельный предмет... Его я тоже ковырял, и в школе всерьез (с одобрения препода!) подумывал, не свернуть ли туда совсем (потом понял, что это все же не мое). Но там я вообще не могу похвастаться особыми заслугами, хотя общее представление имею.

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