CodeVisionAVR vs AVR Studio

[HHIMERA]

Ох и дофигища получилось...

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

[HHIMERA]

Основные навыки, которыми должен владеть специалист в области программной инженерии, весьма четко определены в SWEBOK. IEEE Computer Society - достаточно авторитетная организация, чтобы хотя бы обратить внимание на ее образовательный стандарт, да и участие в его разработке таких фирм, как Boeing, Rational, SAP, Construx Software и других кое-о чем говорит.

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

[vem566]

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

[YS]

(именно такая пропорция вытекает из соотношения "80% аппаратура / 20% код, не так ли?)

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

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

[uni]

Увы, не открывается... Возможно, временные трудности. Не подскажете автора и точное название? Может, у меня уже есть такая, я их давно собираю.

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

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

This is a textbook that I have written to support my high school students learning using the AVR for their technology projects. We have 300 students who learn to program the AVR and some do neat things.
The book is no charge, its almost 1000 pages of learning.
It starts with Bascom and does some C and C++
(I am interested in any C++ gurus feedback on what I have written)

The complementary software I have written is also free.
And there are a lot of students projects on my website as well.

Bill
Auckland
New Zealand
http://www.techideas.co.nz

[uni]

Интересная ситуация - в этом случае возникает соблазн перехватить все ексепшены и погасить их внутри. Как бы наверх ничего показываться не будет, но хорошо ли это ? Не думаю.

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

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

Спойлер

Код:

// Пространство 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 );
    }

}


[uni]

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

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

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

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

[Goldsmith]

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

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

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

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

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

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

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

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

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

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

[uni]

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

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

Когда (если вообще когда-нибудь) дорасту до уровня школьника из Новой Зеландии...

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

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

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

[HHIMERA]

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

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

[Goldsmith]

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

Не увидел логической связи. То есть в процессорах с архитектурой 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 под большим вопросом...

[HHIMERA]

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

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

[uni]

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

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

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

[urry]

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

Код:

   try
   {
      if (!registrator.GetCount())
      throw new CLazyException(_T("delete"));
      if (strDictionaryID.IsEmpty())
      throw new CLazyException(_T("delete"));
   }
   catch (CException* e)
   {
      e->GetErrorMessage(m_strError.GetBuffer(MAX_PATH), MAX_PATH);
      m_strError.ReleaseBuffer();
      e->Delete();
      return FALSE; //RESULT_ERROR;
   }
   //----------
   TRY
   {
      n = cfile.Read(buf,(int)st.m_size);
   }
   CATCH(CFileException, pEx)
   {
      cfile.Close();
      LOG ("не могу открыть файл base.ini!");
      strBuffer.ReleaseBuffer();
      return FALSE;
   }
   END_CATCH
   //----------
   try
   {
            ADOX::_CatalogPtr m_pCatalog = NULL;
            m_pCatalog.CreateInstance(__uuidof (ADOX::Catalog));
            strTest.Format(ConnectData.Defaul_cs,ConnectData.Defaul_path);
            m_pCatalog->Create(_bstr_t(strTest));   
            dbReport->Open(strTest,"admin");
   }
   catch(CADOException& e)
   {
            strError=e.GetErrorMessage();
            LOG(strError);
   }
   //----------



[YS]

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

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

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

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

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

[Goldsmith]

Стандарт Си вроде не вчера придумали? Вы что-то от нас скрываете?

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

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

Так где те проекты на C, который должен выдавать Гугл при запросе об этом подходе? У меня практика критерий и в этом сила

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

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

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

Очевидно, что я не первый, кто это заметил, иначе бы этот CException и не появился, так ведь?

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

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

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

Goldsmith, интересный подход, я такого не знал.

Но это скорее субъективная причина. Теперь знаете.

Вам правильно указывают спуститься с небес на землю.

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

[Goldsmith]

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

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

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

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

[uni]

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

[Goldsmith]

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

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

Потом, к примеру, расскажите о минусах этого подхода с CException. Можно ли этот блок использовать в ISR? Да, нет, почему?

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

When you download the package, you also get some docs and some tests that we have used to verify that everything is working peachy.

Скорее всего, необходимость в импровизированной лекции тут же отпадет.

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

[YS]

идеальное соотношение для эмбеддера должно быть иным: 100% схемотехники / 100% программирования.

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

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