Python для си-шника

Я — разработчик микроконтроллерных систем. Я пишу программное обеспечение для МК на языке Си. При работе с проектами я предпочитаю использовать make-подход и командную строку, а не тяжеловесные IDE типа Code::Blocks и Eclipse.

С одной стороны, эти IDE требуют для своей нормальной работы очень мощные компы, а  с другой — я не очень понимаю (и принимаю)  тенденцию к наращиванию «жира».

На минуточку, проснитесь! Ведь чтобы создать программу для МК, размер которой не превышает несколько килобайт, привлекаются мощнейшие компы с гигагерцовыми процессорами и гигабайтами оперативной памяти. И мы ведь искренне гордимся тем, что «гора» нашего железа, стоящего у нас на столе, рожает мышь в каких-то 300-500 байт за полсекунды»? Эй! Алё! Что происходит?

Если на ситуацию посмотреть со стороны, то становится понятно, что мы не замечаем, что крепко сидим на крючке — нам втюкивают не функционал вещей, а ненужные понты. Здравый рассудок подсказывает, чтобы создать программу в один килобайт не нужен инструмент, размер которого превышает 100 килобайт. Вспомните времена DOS! Вспомните «Turbo-C 2.0». Что изменилось с тех пор? Почему мир пошел в этом направлении?

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

Оглянитесь вокруг! Разработчики озабочены не тем, что они делают на своих компах, а тем — какие у них компы. Выпускать посредственную 2-килобайтную гавно-программу на крутом 8-ми ядерном компе с 16 гигабайтами оперативы — ну да, это мега-круто!

Я не понимаю эту философию, поэтому предпочитаю немного другие инструменты.

Это было лирическое отступление. Далее пойдет техническая часть.

Я уже давно заметил, что по ходу работы над каким-нибудь проектом я иногда создаю новую пару .h и .c файлов для выделения той или иной функциональности.

Например, понадобилось мне включить в проект функциональный модуль для измерения температуры. Пока не важно на основе какого железа будет работать этот модуль, и что он будет делать. Важно только лишь то, что почти вся его функциональность будет находится в отдельном файле — точнее в двух — в temp.c и temp.h.

Что характерно — обычно я создаю сразу пару файлов (.c и .h) с одинаковым именем. В начале каждого файла я прописываю в комментариях его имя. Это нужно для распечатки файла на бумаге — потом сразу будет видно, содержимое какого файла представлено на этой распечатке. Гадать не придётся. Кроме того, в хэдерном файле я обычно создаю секцию для исключения повторного определения, а в си-шном файле обычно вставляю команду препроцессора для подключения хэдерного файла. Мне объяснять, а вам читать — утомительно, нагляднее показать содержимое этих файлов. Точнее заготовку содержимого для этих файлов.

temp.c

// temp.c

#include "temp.h"

temp.h

// temp.h

#ifndef __TEMP_H__
#define __TEMP_H__


#endif

Собственно, тут нет никакой революции. Обычные файлы, обычная рутинная операция. Но когда эту операцию приходится выполнять в порыве вдохновения при написании кода — это воспринимается весьма болезненно. Не скажу за всех программистов-разработчиков, ну, как минимум, я — я, лично, испытываю дискомфорт.

(Мечтательно) Да-а, было бы здорово, если бы можно было одним взмахом руки создать заготовку этих файлов.

Но ведь никто не запрещает это сделать. Только собственная лень останавливает от создания маленькой утилиты. И вот, похоже настал тот день, когда я сподобился написать её.

Вот она, перед вами. Я назвал эту утилиту незатейливо — mkch (имя вроде как не занято).

#!/usr/bin/env python

def create_hfile(hname, defname):
  hfile = open(hname, "w")
  hfile.write("// " + hname + '\n')
  hfile.write("\n")
  hfile.write("#ifndef " + defname + '\n')
  hfile.write("#define " + defname + '\n')
  hfile.write("\n\n")
  hfile.write("// Put here all your defines\n")
  hfile.write("\n\n")
  hfile.write("#endif" + '\n')
  hfile.close()

def create_cfile(cname, hname):
  cfile = open(cname, "w")
  cfile.write("// " + cname + '\n')
  cfile.write("\n")
  cfile.write("#include \"" + hname + "\"\n")
  cfile.write("\n\n")
  cfile.write("// Put here your codes\n")
  cfile.close()

def create_couple(modname):
  hname = modname + ".h"
  cname = modname + ".c"
  defname = "__" + modname.upper() + "_H__"
  create_hfile(hname, defname)
  create_cfile(cname, hname)

if __name__ == "__main__":
  import sys
  modname = sys.argv[1]
  #print modname
  create_couple(modname)

Это обычная Питоновская прога, которая размещается в поддиректории bin, в домашнем директории (если кому не понятно, то вот — /home/alex/bin). Путь в этот директорий в Убунте как правило уже прописан. Таким образом даже ничего специально не надо делать, нужно просто создать в этом поддиректории файл mkch и сделать его исполняемым.

Теперь мне не нужно отвлекаться на создание пары файлов, прописывать у них начальную структуру, следить за тем, чтобы они «срослись» по именам и прочее. Я просто набираю команду

$ mkch temp

, а затем вызываю текстовый редактор и начинаю «набивать» созданные файлы содержимым. Таким образом, творческий процесс полета инженерной мысли практически не прерывается.

Я не утверждаю, что утилита mkch — это какой-то шедевр программистской мысли или что это уже функционально-полная прога, — нет! Если вы способны ее изменять в лучшую сторону, то я могу это только приветствовать. Кроме того, я преднамеренно в проге на стал прописывать всякие-там try-except-ловушки, которые, конечно сделают утилиту более робастой, но при этом она потеряет в наглядности (в прозрачности работы). Мне сейчас важно поделиться идеей, а не выкатить на рынок уже готовый (на все случаи) инструмент. Хотя, похоже, я уже начал оправдываться… В общем, берите, пользуйтесь и получайте удовольствие, а жир-сало можно навешать потом, по мере надобности.

Ну и как обычно — если заметите ошибки или неточности, сообщайте, плиз!

 

UPDATE 31.05.2016

Продолжение темы: http://wp.me/p1H7g0-1q3

3 responses to “Python для си-шника

  1. Я пробовал всякие IDE, но emacs как-то привычнее, на нём и шаблоны можно сделать (подобные описанному здесь) и работает он на всём и файлы гигантские может прожевать, не задумавшись. В топку коммерческие поделки…

    • Софт — это как лесные ягоды. Кто не умеет или не имеет возможности самостоятельно ходить по лесам и собирать то, что ему нравится, вынужден идти на рынок и довольствоваться тем, что там есть — вынужден покупать и надеяться на порядочность продавца.

      Либо ты сам определяешь свою жизнь, либо за тебя это делают другие, причем за твои же деньги.

  2. Ну если уж идти дальше, то софт для МК надо разрабатывать на самом МК, например на Forth или ДССП.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s