тут можно скачать среду от ARM: https://www.keil.com/demo/eval/arm.htm,
в ней уже есть встроен компилятор от самой ARM: https://developer.arm.com/tools-and-software/embedded/arm-compiler/downloads/version-6
А чем компилятор непосредственно от самой ARM "хуже лучшего компилятора для армов"?
критическую секцию на край можно поставить (не в прерывании, а в фоне кода).
да, конечно это - костыль, но для подобного построения кода это вполне допустимо, особенно в крохотных и примитивных проектиках
тем более, если переменная имеет размер больше, чем слово проца, т. е. атомарно за раз его не прочитать или не записать
Ну, если прораб начнет опытного каменщика учить как "правильно" класть кирпичную кладку, то будет закономерно послан на три буквы.
Такому прорабу придется крепко задуматься, что нужно и чего не стоит делать, чтобы сохранить должность и уважение рабочих ;)
А опытный прораб отлично понимает, что основная задача - построить здание и пройти успешно необходимые проверки прочности и т. п.
И потому он не станет соваться со своими "полезными" советами туда, куда не следует
Это - одна из самых вкусных фишек подобного подхода!
Только ради этого уже можно потратить чуток времени и сделать лучше жисть себе лично ))
Самое сложное тут - сразу грамотно создать интерфейс и модель взаимодействия, предполагающие расширение всего этого на будущее. Иначе переделывать придется все целиком, и порой не раз :(
Вот она и типична ошибка восприятия ООП как такового. ООП не делит объекты на конкретные реальные и абстрактные.
На первой странице я привел конкретный пример из реального проекта.
Самое ценное, что я ценю в ООП - инкапсуляция. Это то, что делает код масшабируемым, переносимым и понятным.
зы подозреваю, что мы сейчас толкуем о разные вещах ))
Меньше объем текста программы и проще в ней разбираться. Навык приходит только с опытом.
з.ы А тем временем тема постепенно превращалась в типичный холивар.... )))
"Разложили все по полочкам" все уже в первых постах, а Darth Vader вообще разжевал в кашу и практически ложку в рот положил. Жевать не надо. Вот уж удивительно будет, если и тут возникнут сложности )))
Не это - его основное преимущество, вовсе не это ))
Это происходит сверху вниз, а не снизу вверх ))
Другими словами, сначала следует спроектировать сам проект, а потом уже углубляться в его недры ))
Более того, коли проект работает, то лучше его не трогать. Тем более инструментарием, в котором опыта по свей видимости еще малова-то ) Без обид ))
Да, разработаны, причем давным давно и не только для подобных ситуаций.
Их можно найти в хороших книгах, но они относятся не только к С++, а вообще к методологии проектирования кода. Язык тут лишь это инструмент. Он может быть любой.
Вот отсюда и возникает логичный вопрос: зачем?
Впрочем, судя по очень высокой активности ТС в его же теме, этот вопрос переходит в разряд риторических :)
я с ходу подумал, что речь идет про один класс на все три юарта сразу:
Ну, типа один контейнер для всех юартов сразу.
to ТС:
Не совсем понятно, речь идет про:
1. некие косяки в коде или
2. это был обобщенный вопрос по методологии проектирования в целом?
Если первое, то код в студию. На второе - ответы прозвучали.
Как это сделано у меня:
1. Создаем экземпляр нужного порта
2. Настраиваем порт, подключаем обработчик прерываний и запускаем
3. Реализуем обработчики прерываний
Библиотечная часть (общая для всех проектов на выбранное семейство)
USART.hpp:
В USART.cpp находится реализация базового класса SerialPort, все возможные отличия (если они есть) различных юсартов друг от друга скрыты внутри.
Отличия если и есть, то сводятся к тому, на каких внутренних шинах висят те или иные юсарты. Другими словами разрешение тактирования, пересчет скорости обмена и т. п. происходит внутри.
Это позволяет очень просто переносить приложение или его части с одного проца камня другой, практически не меняя кода.
