Микроконтроллеры, АЦП, память и т.д Темы касающиеся микроконтроллеров разных производителей, памяти, АЦП/ЦАП, периферийных модулей... |
20.10.2006, 14:02
|
|
Прописка
Регистрация: 11.06.2005
Сообщений: 266
Сказал спасибо: 9
Сказали Спасибо 13 раз(а) в 12 сообщении(ях)
|
О стилях программирования на C для МК
Этот вопрос возник с переходом на новую работу. До этого я вырабатывал свой стиль программирования на языке СИ, состоящий в следующем: мой проект (создаваемый в среде IAR) состоит всегда из одного файла с расширением .c, все остальное, такое, как работа с модулем I2C, USART и т.п., подрубается к нему при помощи файлов .h, подключаемых директивой #include. Эти файлы потом удобно переноситьв другие проекты, ничего не переделывая и не добавляя.
На новой работе мне показали новый стиль программирования - работа с отдельным модулем описывается в файле *.c, к нему, если надо, подключается файл с таким же названием *.h. Потом везде, где надо, вставляются всякие ссылки на внешние переменные и процедуры (через extern). Вобщем мудохня...Хотелось бы узнать, какой стиль программирования у вас, форумчане, чтобы однозначно определиться, как удобнее писать программу. Пока же остановился на том, что было вначале, считая, что удобнее стиля не нашел.
|
|
|
|
20.10.2006, 15:32
|
|
Супер-модератор
Регистрация: 13.03.2004
Адрес: Minsk
Сообщений: 2,378
Сказал спасибо: 1,948
Сказали Спасибо 1,327 раз(а) в 578 сообщении(ях)
|
Re: О стилях программирования на C для МК
Сообщение от Prime
|
До этого я вырабатывал свой стиль программирования на языке СИ, состоящий в следующем: мой проект (создаваемый в среде IAR) состоит всегда из одного файла с расширением .c, все остальное, такое, как работа с модулем I2C, USART и т.п., подрубается к нему при помощи файлов .h, подключаемых директивой #include.
|
Я ни в коей мере не считаю себя крутым знатоком С, что, в общем, не мешает мне писать работающие программы Так вот, у меня выработался примерно такой же стиль.
Во первых, мне категорически не нравятся всякие extern. А поскольку программист я один, то стиль мне никто не навязывает.
Во вторых, без extern почти всегда код строится более красивый и компактный - за счет того, что компилятор знает, где какая переменная, и загружает Z регистр так, чтобы "достать" максимальное количество переменных без его перезагрузки (я работаю с AVRками).
|
|
|
|
20.10.2006, 19:23
|
|
Гражданин KAZUS.RU
Регистрация: 21.02.2005
Сообщений: 685
Сказал спасибо: 14
Сказали Спасибо 84 раз(а) в 44 сообщении(ях)
|
Я тоже не являюсь супер программистом. (И алгоритмы у меня корявые выходят ) Но использую подход номер 1.
Думаю что на выбор стиля влият командная это работа или ты одиночка.
Может при командной работе использование внеших переменных более оправдано? Незнаю, самому в команде писать не приходилось.
|
|
|
|
21.10.2006, 11:44
|
|
Прописка
Регистрация: 11.06.2005
Сообщений: 266
Сказал спасибо: 9
Сказали Спасибо 13 раз(а) в 12 сообщении(ях)
|
Даже не знаю, что ответить. Командный подход для написания программы для МК...Думаю, это реально только для мощных контроллеров, например, при написании какой-нибудь RTOS. Тогда уже модульность необходима, это точно.
|
|
|
|
21.10.2006, 12:27
|
|
Прохожий
Регистрация: 31.07.2006
Сообщений: 9
Сказал спасибо: 0
Сказали Спасибо 0 раз(а) в 0 сообщении(ях)
|
а вобще в чем заключается смысл extern
(извините за дурацкий вопрос я программирую около полугода)
|
|
|
|
21.10.2006, 13:34
|
|
Гражданин KAZUS.RU
Регистрация: 16.12.2004
Сообщений: 587
Сказал спасибо: 13
Сказали Спасибо 23 раз(а) в 9 сообщении(ях)
|
Народ! Главное не какой стиль, а чтобы программы работали без ошибок и писались при этом быстро, но....
я пишу следующим образом: каждый модуль отдельно, в *.c исходник и объявление глобальных переменных, в *.h только интерфейс модуля, подключение через extern, но теперь библиотечные модули находясь в отдельной папке подключаются к проекту как исходники, а не объектниками или библиотеками. Этот подход был мною "выстрадан" за долгое время. Аналогично работаю с классами.
Почему так: я работаю в компании, где много программистов, есть иногда и командная работа, но я не могу добиться от начальства приведения всех разработок к единой среде и стилю. У нас разные люди иногда пишут одинаковые модули, но при этом каждый "дрочит как хочет", из-за этого теряется уйма времени на написание и отладку программ + если я комуто даю свои наработки или обратно, каждому приходится всё подстраивать под свой проект.
Я несколько лет назад начал переводить старые проекты написанные на asm на IAR C, для единой стандартизации мною же написанного. Ведь разработки нужно бывает ещё и сопровождать или изменять, а сделать это через длительное время бывает затруднительно. Сейчас я как из кубиков леплю любую программу, достаточно быстро, при этом использую старые наработки без изменения и отладки. Мало того, время от времени у нас любят переходить с одного процессора на другой (менять платформу), вследствии отсутствия старых и у меня переход занимает сравнительно короткое время, а народ у нас визжит визгом по этому поводу - ну как например перейти с AVR на ARM LPC2xxx (особенно если проект на асме или с таковыми вставками). Так-же легче при таком построении отлаживаться, хотя и сложнее получается структура проекта. Или например необходимо одинаковые модули использовать в IAR C и в Borland C++. Вот хотелось бы перейти на единую ОС, то мы такие вещи не используем, да только времени нет и руководство меня в этом не поддерживает. Так что думайте сами.
Правила примерно такие:
1) исходники лежат в файлах *.c, *.cpp, (*.asm, *s,...)
2) интерфейс модуля описан в *.h, *.hpp и без внутренних переменных, только то что надо для использования модуля, там - же задания констант; отдельными файлами лежат определения структур, типов преременных, задания для констант и определение физических портов оборудования.
3) т.к. во всех файлах *.h определения функций и переменных лежит через extern, то такой файл просто включается в разные модули инклюдом, там где его необходимо использовать.
4) программа (соответственно и модули) должны иметь несколько уровней детализации: физический - модули работы соборудованием, инитерфейсный - где реализуются протоколы и функции APIO, логический - где формируется логика работы программы, главный - где определяется работа всей программы и соединяются все "кубики" в единое целое.
Это основные постулаты. Кстати "extern" обозначает, что символ (функция, переменная или константа) являются ВНЕШНИМИ и их надо искать во всех подключаемых модулях программы. Без extern при множественном объявлении функции или данных в разных модулях компилятор будет ругаться. А вообще лучше почитать умную книжку по программированию на C, тк. я не претендую на глубокие познания и этакую правильность. Сам учил всё это не по книжкам а на практике, потом пришлось кое что почитать и Вы не поверите - помогло!
Всем респект!
|
|
|
|
21.10.2006, 15:27
|
|
Прохожий
Регистрация: 31.07.2006
Сообщений: 9
Сказал спасибо: 0
Сказали Спасибо 0 раз(а) в 0 сообщении(ях)
|
и вам большой респект за такое дельное объяснение
|
|
|
|
24.10.2006, 13:39
|
|
Прописка
Регистрация: 27.05.2005
Сообщений: 127
Сказал спасибо: 0
Сказали Спасибо 3 раз(а) в 2 сообщении(ях)
|
Полностью согласен с NemoCut32.
Свои 5 копеек:
1. Если использовать неприплюснутый Си, то легче отслеживать соблюдений концепции платформы программистами. Если модуль1 может вызывать модуль2 но не может вызывать модуль3 то и в модуле1 не может быть *.h файлов от модуля3.
2. Наглядность. Если для важных мест программы для каждой функции заводить свой файл, то в таком случае легче искать её. И опять таки см п1.
3. По другому никак если используется система контроля версий и в проекте несколько программистов. (Всем рекомендую SVN).
Вообщем это единственный правильный способ. Остальное всё от полуграмотности.
З.Ы. Даже если ты пишешь программу один, попробуй поставить SVN. Это такая штука от которой просто невозможно отказаться. В сети есть подробные русскоязычне мануалы.
|
|
|
|
25.10.2006, 18:16
|
|
Прописка
Регистрация: 29.08.2005
Сообщений: 139
Сказал спасибо: 7
Сказали Спасибо 5 раз(а) в 5 сообщении(ях)
|
Сообщение от deCoder
|
Всем рекомендую SVN.
|
Можно поподробней что это и где ее взять?
|
|
|
|
25.10.2006, 18:33
|
|
Прописка
Регистрация: 27.05.2005
Сообщений: 127
Сказал спасибо: 0
Сказали Спасибо 3 раз(а) в 2 сообщении(ях)
|
Если на пальцах, то это система контроля версий )
На сервере (можно и у себя, локально) организуешь репозитарий.... Кароче можно хранить, например, исходники. Хоть каждые пять минут фиксируешь изменения. То есть можно откатиться к любой версии. Отлично работается в команде. Также можно делать боковые ветки проекта. Например у тебя линейка устройств, а реально 80% кода объединены. Исправляешь в одном месте - исправляется везде. Использую её пару месяцев. Морда довольная ) Например сейчас у нас 4 программера работают на одним очень большим проектом. Ни разу не подрались ) Также я использую её для всего и для вордовских и оркадовских файлов. Также - лишний и удобный бекап.
http://ru.wikipedia.org/wiki/Subversion
Вот отличное описание на русском для серверной и клиентской части:
http://tortoisesvn.net/docs/nightly/..._ru/index.html
http://svnbook.red-bean.com/nightly/ru/
|
|
|
|
Ваши права в разделе
|
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
HTML код Выкл.
|
|
|
Часовой пояс GMT +4, время: 11:34.
|
|