Ну, знаете ли, по ошибке можно и Off вместо On написать.
Цитата:
И можно всё-таки пояснить зачем нужно знать ассемблер, чтобы программировать на МК?
В частности, чтобы понимать, почему C++ под такие мелкие системы неприменим.
Чтобы иметь возможность оценить эффективность кода, глянув в дизассемблер. Чтобы понимать, почему GCC лучше, чем mikroBASIC, и почему mikroBASIC лучше, чем AlgorithmBuilder. А также почему IAR порой лучше всех перечисленных компиляторов вместе взятых.
А еще есть вещи, которые невозможно/трудно/нецелесообразно писать на том же Си. Например, софтовую реализацию 1-Wire, где каждый такт на счету. Очень полезно писать работу со сдвиговыми регистрами на ассемблере, ибо разница в скорости существенна. И так далее, и тому подобное.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Я ведь уже приводил дизассемблированный код для ООП-варианта и чистого Си. Видно, что в ООП-варианте для каждой строки генерируется отдельный блок одинакового кода. Зачем? Это бесполезная трата памяти и времени. И это в самом простом проекте, проще которого не бывает.
Представляете, что произойдет, если вдруг захотеть породить экземпляр класса?
Еще раз призываю - поглядите на Arduino. Там как раз упрощенный C++. Дизассемблируйте что-то, написанное на Wiring, и ужаснитесь.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.
Я ведь уже приводил дизассемблированный код для ООП-варианта и чистого Си)
Код не аналогичный. Чтобы код был аналогичный, вместо LED_PORT^=(LED1_PIN | LED2_PIN); должно быть LED_PORT^=LED1_PIN; LED_PORT^=LED2_PIN. К тому-же мне никто не мешает написать класс Pins для работы с несколькими пинами одновременно (вместо Pin как в первом примере). Тогда мой пример будет выглядеть как
подтверждения ненужности C++ для МК так и не получил
Мне за Вас погуглить сравнение эффективности Wiring (упрощенный C++ для AVR) и pure C?
Цитата:
|Ассемблерный код тогда станет полностью аналогичный с Pure-C
Уверены?
Потом, мы же говорим не о светодиодной мигалке, а о чем-то приличном? Напишите, например, вывод в регистр HC595, и сравним. Хотя это тоже на уровне мигалки.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Я ведь даже в скобках на всякий случай указал, что такое Wiring. Кстати компилятор там - тот же GCC, так что сравнение корректно.
Только не говорите, что использующий плюсовые фичи остановится на их применении к портам. Хотя, в общем, и тут особых преимуществ перед дефайнами не видно.
Смысл дефайнов в том, что большинство операций, ими описанных, должно выполниться препроцессором либо оптимизатором и не войти в результирующий бинарник. А вот ООП-фишки такого преимущества лишены.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Я ведь даже в скобках на всякий случай указал, что такое Wiring. Кстати компилятор там - тот же GCC, так что сравнение корректно.
Не вижу логической связи между утверждениями "Wiring генерирует тормозной код" и "Компилятор C++ генерирует тормозной код"
YS писал(а):
Только не говорите, что использующий плюсовые фичи остановится на их применении к портам.
Не совсем понял
YS писал(а):
Смысл дефайнов в том, что абсолютное большинство кода, ими описанного, должно выполниться препроцессором либо оптимизатором и не войти в результирующий бинарник. А вот ООП-фишки такого преимущества лишены.
Тоже не понял. Код (бинарный) выполняется процессором. Если имелся ввиду исходный код, то он не выполняется ни оптимизатором, не препроцессором И почему ООП-фишки лишены такой возможности? (кстати, какой именно возможности?)
2ArtDen Если вы совсем не в теме, то и не стоит так нервничать... И если у С++ есть неоспоримые преимущества, так покажите их... И любовь/ненависть тут совсем не при чём... есть такие понятия как "целесообразность" и "наилучший/быстрый результат"...
_________________ "Я не даю готовых решений, я заставляю думать!"(С)
Не вижу логической связи между утверждениями "Wiring генерирует тормозной код" и "Компилятор C++ генерирует тормозной код"
Wiring ничего не генерирует. Wiring - диалект C++, который компилируется GCC...
Цитата:
Не совсем понял
Я имел в виду, что скорее всего, парадигма ООП будет распространена на всю программу. : )
Цитата:
Тоже не понял. Код (бинарный) выполняется процессором. Если имелся ввиду исходный код, то он не выполняется ни оптимизатором, не препроцессором
Тогда я Вас очень удивлю. Если Вы напишете
Код:
a=((2+3)+4*8) | (1<<2);
то компилятор на этапе разбора (!) вычислит значение (((2+3)+4*8) | (1<<2)), и в код пойдет
Код:
a=37;
Да-да, компилятор выполнит написанный Вами код. А еще он может оптимизировать повторяющиеся части выражений. И при написании макросов вовсю этим пользуются. Макрос - не переменная. Он подставляется в исходник в виде строки.
***
Тов. ArtDen, не обращайте внимания, тов. HHIMERA просто перенервничал.
А в целом - я ни в чем Вас не обвиняю и не призываю прям щас верить мне на слово и отказываться от С++ (более того, есть области, где он незаменим). Вы написали код, вложили усилия, что-то узнали. Вы молодец. Просто почитайте про Wiring, внутреннюю кухню объектов, оптимизации компиляторов и принципы разбора кода. И все-таки поглядите на ассемблер. : ) А я, пожалуй, закончу тут проповедовать.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
2ArtDen Если вы совсем не в теме, то и не стоит так нервничать...
В какой именно я "не в теме": C/C++, работа с портами ввода/вывода или программирование для МК?
HHIMERA писал(а):
И если у С++ есть неоспоримые преимущества, так покажите их...
Ещё раз повторяю. Тема не про преимущества/недостатки С++ перед си и ассемблером. Тема про конкретную библиотеку для работы с портами.
HHIMERA писал(а):
И любовь/ненависть тут совсем не при чём... есть такие понятия как "целесообразность" и "наилучший/быстрый результат"...
Есть конечно. Буду рад услышать "целесообразность" и "наилучший/быстрый результат" применительно к данной теме
ILYAUL писал(а):
Так Вы нам не доказали чем она лучше традиционного подхода.
Повторюсь: 1. Нога определяется только в одном месте (1 строка). На си ради этого надо писать три строки: #define XXXXX_PORT PORTA #define XXXXX_DIR DDRA #define XXXXX_BIT 0x01 2. Меньше вероятность допустить ошибки перепутав порты или биты 3. Лучшая читаемость 4. Проще переносить код между аппаратными платформами
YS писал(а):
Тогда я Вас очень удивлю. Если Вы напишете
Код:
a=((2+3)+4*8) | (1<<2);
то компилятор на этапе разбора (!) вычислит значение (((2+3)+4*8) | (1<<2)), и в код пойдет
Код:
a=37;
Да-да, компилятор выполнит написанный Вами код. А еще он может оптимизировать повторяющиеся части выражений. И при написании макросов вовсю этим пользуются. Макрос - не переменная. Он подставляется в исходник в виде строки.
Про выполнение исходного кода компилятором написан бред. Он ничего не выполняет. Далее по пунктам:
YS писал(а):
компилятор на этапе разбора (!) вычислит значение (((2+3)+4*8) | (1<<2)),
Бред. На этапе разбора компилятор строит AST-дерево. При этом он ничего не вычисляет. Значение (((2+3)+4*8) | (1<<2)) будет вычислено на этапе многостадийной оптимизации в одной из стадий свёртки констант. Повторю ещё раз: компилятор ничего не выполняет!
YS писал(а):
И при написании макросов вовсю этим пользуются. Макрос - не переменная. Он подставляется в исходник в виде строки.
Повторюсь: 1. Нога определяется только в одном месте (1 строка). На си ради этого надо писать три строки: #define XXXXX_PORT PORTA #define XXXXX_DIR DDRA #define XXXXX_BIT 0x01
Надуманно... одной строкой больше, одной меньше... не впечатляет... При групповой инициализации может быть и наоборот...
Цитата:
2. Меньше вероятность допустить ошибки перепутав порты или биты
Надуманно... есть статистические данные по этому поводу, которым можно верить??? "Капитана Очевидность не предлагать!"(С)
Цитата:
3. Лучшая читаемость
Надуманно... для этого есть абстракция...
Цитата:
4. Проще переносить код между аппаратными платформами
Надуманно... С++ не пользуюсь, а трудностей с переносом не ощущаю... "Что я не так делаю?" (С)
_________________ "Я не даю готовых решений, я заставляю думать!"(С)
Ещё раз повторюсь: речь идёт не про С++, а про библиотеку работы с портами. Вопросы по С/С++ обсуждаются в соседней теме.
Ладно... пусть будет так... вам виднее... Но тема, вообще то, называется "Пример работы с I/O портами AVR на C++"... может просто пример был неудачный...
_________________ "Я не даю готовых решений, я заставляю думать!"(С)
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 31
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
