Аппаратные и программные

5.4.3 Пример makefile для Linux 
Так выглядит makefile в случае программирования учебного стенда 
SDK-1.1 в ОС Linux: 
# -------------------------------------------------------------------- 
# Имя проекта 
NAME = 
test_led 
# Настройки компилятора и линкера 
CC = sdcc 
CFLAGS = -I./INCLUDE -c --stack-auto 
LFLAGS = --code-loc 0x2100 --xram-loc 0x6000 --stack-auto --stack-loc 0x80
PROJNAME = ${PROJECT}-${VERSION}-${BUILD}-${TYPE} 
TARBALL = ${PROJNAME}.tar 
# Настройки M3P 
M3P 
= m3p 
COMPORT = /dev/ttyS0 
COMLOG = $(COMPORT)_log.txt 
BAUD 
= 9600 
# Каталоги с исходными текстами 
SRC_DIR = SRC 
# -------------------------------------------------------------------- 
all: test_led 
clean: 
-rm -f $(NAME).hex \ 
$(NAME).bin \ 
$(NAME).map \ 
$(NAME).mem \ 
$(NAME).lnk \ 
pm3p_*.txt \ 
com?_log.txt \ 
$(TARBALL).gz \ 
$(SRC_DIR)/*.asm \ 
$(SRC_DIR)/*.rel \ 
$(SRC_DIR)/*.rst \ 
$(SRC_DIR)/*.sym \ 
$(SRC_DIR)/*.lst

---

242 
load: 
$(M3P) lfile load.m3p 
term: 
$(M3P) echo $(COMLOG) $(BAUD) openchannel $(COMPORT) \ 
+echo 6 term -echo bye 
LIST_SRC = \ 
$(SRC_DIR)/led.c \ 
$(SRC_DIR)/max.c \ 
$(SRC_DIR)/test_led.c
LIST_OBJ = $(LIST_SRC:.c=.rel) 
test_led : $(LIST_OBJ) makefile 
$(CC) $(LIST_OBJ) -o test_led.hex $(LFLAGS) 
$(M3P) hb166 test_led.hex test_led.bin bye 
$(LIST_OBJ) : %.rel : %.c makefile 
$(CC) -c $(CFLAGS) $< -o $@
5.5 Система контроля версий 
Система контроля версий решает сразу несколько задач для разработчика 
встроенного ПО: 
• Позволяет сохранять в надёжном месте весь его проект (выполняет 
функции интеллектуального архиватора). 
• Позволяет предоставить доступ к проекту для всех его участников, а 
также регламентировать доступ для посторонних людей. 
• Позволяет отслеживать все изменения в проекте, возвращаться к 
старым версиям файлов и вести параллельно сразу несколько вариантов 
одного проекта. 
Большинство опытных монстров и зубров в области программирования 
могут возразить, что для сравнительно несложных программных проектов, 
существующих в области встроенных систем, система контроля версий – 
лишняя бюрократическая процедура, отнимающая время и не дающая ничего 
взамен. Хочу вас заверить, что это не так. Даже если вы работаете один, и вам 
не нужно совместно с кем-то работать над одним проектом, система контроля 
версий оказывается гораздо удобнее банального архиватора. С помощью такой, 
к примеру, команды: 
svn co http://vash_server.vash_domen.ru/repos/proect 
вы можете получить доступ к своим исходным текстам везде, где есть 
компьютеры и выход в Интернет. С помощью простой команды 
svn commit
вы 
можете отправить свои изменения обратно на сервер. Вам не нужно больше 
бояться, что вирусы уничтожат ваши файлы, или что у вас сломается жесткий 
диск. Все данные хранятся на удаленном сервере и всё, что вы можете 
потерять, – это несколько часов работы. Естественно, все это будет работать 

---

243 
именно так, если вы позаботитесь о регулярном резервном копировании вашего 
сервера. 
В настоящее время системы контроля версий интегрированы в различные 
интегрированные среды разработки (IDE). Наиболее распространенными 
системами контроля версий, широко применяемыми на момент написания этой 
книги, являются CVS и Subversion. Эти системы очень похожи. CVS появилась 
раньше, чем Subversion и хорошо себя зарекомендовала. Subversion в 
настоящий момент активно пробивается в лидеры, в ней исправлено несколько 
концептуальных ошибок, имеющихся в ее предшественнике SVN. Чем 
пользоваться вам – решайте сами. По сути, все системы контроля версий очень 
похожи, и чем пользоваться – дело привычки или каких-то иных предпочтений.