Do you have a question? Post it now! No Registration Necessary
- Dimmy Timchenko
September 18, 2003, 3:10 pm

Hi Sergey.
18 Sep 2003, 12:00, Sergey Nazarkin writes to All:
SN> Продолжаю разбираться с гнутым инструментарием под авр.
По-моему, полезная статейка на эту тему:

Кстати, появилась идея: помещать "содержимое" h-файла в начало соответствующего
c-файла, обрамляя его, например, так:
/*BEGIN HEADER*/
...определения и описания...
/*END HEADER*/
Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя" из неё
h-файл. А утилиту эту вызывать с помощью make, объявив зависимость h-файлов от
соответствующих c-файлов.
Dimmy.
18 Sep 2003, 12:00, Sergey Nazarkin writes to All:
SN> Продолжаю разбираться с гнутым инструментарием под авр.
По-моему, полезная статейка на эту тему:

Кстати, появилась идея: помещать "содержимое" h-файла в начало соответствующего
c-файла, обрамляя его, например, так:
/*BEGIN HEADER*/
...определения и описания...
/*END HEADER*/
Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя" из неё
h-файл. А утилиту эту вызывать с помощью make, объявив зависимость h-файлов от
соответствующих c-файлов.
Dimmy.

Re: gnu make
Hello, Sergey!
You wrote to All on Thu, 18 Sep 2003 11:00:33 +0400:
[...]
SN> %.d: %.c #
[...]
SN> Если указать путь явно $(addprefix
SN> $(OBJ_DIR)/, $(DEP)), то выскакивает ошибка
SN> *#────────────────── begin of Windows Clipboard ──────────────────#*
SN> makefile:66: d:/projects/btnode/extract/obj/btnode/avr128_uart1.d:
SN> No such file or directory make: *** No rule to make target
SN> `d:/projects/btnode/extract/obj/btnode/avr128_u art1.d'. Stop.
SN> *#─────────────────── end of Windows Clipboard ───────────────────#*
SN> Почему не задано правило? Оно же существует?
Нет, правило существует для _конкретных_ файлов .d, которые удалось
найти на этот момент (%.d). А их нет.
SN> Как можно обойти такую тонкость?
Замени %.d:%.c на $(DEP): $(SRC), правда, правило тоже придётся
переработать, используя в нём только имя текущей цели, а соответствующий
исходник "добывать" из него.
Alexander Derazhne
You wrote to All on Thu, 18 Sep 2003 11:00:33 +0400:
[...]
SN> %.d: %.c #
[...]
SN> Если указать путь явно $(addprefix
SN> $(OBJ_DIR)/, $(DEP)), то выскакивает ошибка
SN> *#────────────────── begin of Windows Clipboard ──────────────────#*
SN> makefile:66: d:/projects/btnode/extract/obj/btnode/avr128_uart1.d:
SN> No such file or directory make: *** No rule to make target
SN> `d:/projects/btnode/extract/obj/btnode/avr128_u art1.d'. Stop.
SN> *#─────────────────── end of Windows Clipboard ───────────────────#*
SN> Почему не задано правило? Оно же существует?
Нет, правило существует для _конкретных_ файлов .d, которые удалось
найти на этот момент (%.d). А их нет.
SN> Как можно обойти такую тонкость?
Замени %.d:%.c на $(DEP): $(SRC), правда, правило тоже придётся
переработать, используя в нём только имя текущей цели, а соответствующий
исходник "добывать" из него.
Alexander Derazhne

gnu make
Hello Dimmy.
18 Sep 03 20:10, Dimmy Timchenko wrote to Sergey Nazarkin:
DT> Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя" из
DT> неё h-файл. А утилиту эту вызывать с помощью make, объявив зависимость
DT> h-файлов от соответствующих c-файлов.
gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных хидеpов.
подсовывая его гнyсномy мейкy, все полyчается кpасиво.
Alexey
18 Sep 03 20:10, Dimmy Timchenko wrote to Sergey Nazarkin:
DT> Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя" из
DT> неё h-файл. А утилиту эту вызывать с помощью make, объявив зависимость
DT> h-файлов от соответствующих c-файлов.
gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных хидеpов.
подсовывая его гнyсномy мейкy, все полyчается кpасиво.
Alexey

gnu make
Hi Alexey.
19 Sep 2003, 12:39, Alexey Musin writes to Dimmy Timchenko:
AM> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных
AM> хидеpов. подсовывая его гнyсномy мейкy, все полyчается кpасиво.
Собственно, многие компиляторы (и тот же IAR C) умеют выдавать список
зависимостей. А моя идея ещё немного расширяет такую автоматизацию.
Hеудобство тут в том, что мы пытаемся автоматизировать то, что в языке
реализовано как "ручное". А если б были модули, всё это обрабатывалось бы
компилятором совершенно прозрачно, и нам ничего не надо было бы знать про
"проекты", h-файлы, зависимости, линковку.
Dimmy.
19 Sep 2003, 12:39, Alexey Musin writes to Dimmy Timchenko:
AM> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных
AM> хидеpов. подсовывая его гнyсномy мейкy, все полyчается кpасиво.
Собственно, многие компиляторы (и тот же IAR C) умеют выдавать список
зависимостей. А моя идея ещё немного расширяет такую автоматизацию.
Hеудобство тут в том, что мы пытаемся автоматизировать то, что в языке
реализовано как "ручное". А если б были модули, всё это обрабатывалось бы
компилятором совершенно прозрачно, и нам ничего не надо было бы знать про
"проекты", h-файлы, зависимости, линковку.
Dimmy.

gnu make
Hi Dimmy!
You wrote to Alexey Musin on Fri, 19 Sep 2003 11:44:03 +0400:
AM>> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных
AM>> хидеpов. подсовывая его гнyсномy мейкy, все полyчается кpасиво.
DT> Собственно, многие компиляторы (и тот же IAR C) умеют выдавать список
DT> зависимостей. А моя идея ещё немного расширяет такую автоматизацию.
DT> Hеудобство тут в том, что мы пытаемся автоматизировать то, что в языке
DT> реализовано как "ручное". А если б были модули, всё это обрабатывалось бы
DT> компилятором совершенно прозрачно, и нам ничего не надо было бы знать про
DT> "проекты", h-файлы, зависимости, линковку.
Все же непонятно, как же будет осуществляется раздельная компиляция?
Вот есть функция:
void slon(int x, char* pC) { ... // }
Она, к примеру, в src1.c.
Теперь в src2.c мы хотим ее использовать:
void f()
{
char buf[16];
... //
slon(2, buf);
}
Hо для этого мы должны объявить прототип, чтобы компилятор мог проверить
правильность использования. Механизм #include упрощает и устраняет проблемы
синхронизации при задании прототипа. А ты как предлагаешь решить эту задачу?
Bye.
P.S. Кстати, если заглянуть сюда: http://sourceforge.net/projects/avr-ada/ и
http://avr-ada.sourceforge.net/, то можно предположить, что скоро и на твоей
улице будет праздник! :-)
### Обидно, когда твои мечты сбываются у других!
You wrote to Alexey Musin on Fri, 19 Sep 2003 11:44:03 +0400:
AM>> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных
AM>> хидеpов. подсовывая его гнyсномy мейкy, все полyчается кpасиво.
DT> Собственно, многие компиляторы (и тот же IAR C) умеют выдавать список
DT> зависимостей. А моя идея ещё немного расширяет такую автоматизацию.
DT> Hеудобство тут в том, что мы пытаемся автоматизировать то, что в языке
DT> реализовано как "ручное". А если б были модули, всё это обрабатывалось бы
DT> компилятором совершенно прозрачно, и нам ничего не надо было бы знать про
DT> "проекты", h-файлы, зависимости, линковку.
Все же непонятно, как же будет осуществляется раздельная компиляция?
Вот есть функция:
void slon(int x, char* pC) { ... // }
Она, к примеру, в src1.c.
Теперь в src2.c мы хотим ее использовать:
void f()
{
char buf[16];
... //
slon(2, buf);
}
Hо для этого мы должны объявить прототип, чтобы компилятор мог проверить
правильность использования. Механизм #include упрощает и устраняет проблемы
синхронизации при задании прототипа. А ты как предлагаешь решить эту задачу?
Bye.
P.S. Кстати, если заглянуть сюда: http://sourceforge.net/projects/avr-ada/ и
http://avr-ada.sourceforge.net/, то можно предположить, что скоро и на твоей
улице будет праздник! :-)
### Обидно, когда твои мечты сбываются у других!

gnu make
Hi Harry.
19 Sep 2003, 21:37, Harry Zhurov writes to Dimmy Timchenko:
HZ> Все же непонятно, как же будет осуществляется раздельная
HZ> компиляция?
Точно так же, как и раньше, только "исходник" h-файла будет находиться в начале
c-файла. В одном флаконе. Просто для удобства восприятия и редактирования. И
на паскалевский юнит будет смахивать. :)
HZ> Вот есть функция:
HZ> void slon(int x, char* pC) { ... // }
HZ> Она, к примеру, в src1.c.
Вот в src1.c и пишем
/*HEADER BEGIN*/
extern void slon(int x, char* pC);
/*HEADER END*/
В эту секцию помещаем всё, что поместили бы в h-файл. Можно таких секций
делать несколько, если надо сформировать несколько h-файлов, относящихся к
одному исходнику.
HZ> Теперь в src2.c мы хотим ее использовать:
А тут пишем, как обычно, #include src1.h. Ведь этот файл будет сгенерирован
make с помощью специальной утилитки.
Я вообще люблю такие доработки. Hапример, ещё когда в 80-е работал с
ассемблером i8080, написал для него "структурные" макросы. Потом переносил их
и на ассемблеры x86 и x51.
HZ> P.S. Кстати, если заглянуть сюда:
HZ> http://sourceforge.net/projects/avr-ada/ и
HZ> http://avr-ada.sourceforge.net/
:) Спасибо. Только там, как я понял, всё в зачаточном виде...
Dimmy.
19 Sep 2003, 21:37, Harry Zhurov writes to Dimmy Timchenko:
HZ> Все же непонятно, как же будет осуществляется раздельная
HZ> компиляция?
Точно так же, как и раньше, только "исходник" h-файла будет находиться в начале
c-файла. В одном флаконе. Просто для удобства восприятия и редактирования. И
на паскалевский юнит будет смахивать. :)
HZ> Вот есть функция:
HZ> void slon(int x, char* pC) { ... // }
HZ> Она, к примеру, в src1.c.
Вот в src1.c и пишем
/*HEADER BEGIN*/
extern void slon(int x, char* pC);
/*HEADER END*/
В эту секцию помещаем всё, что поместили бы в h-файл. Можно таких секций
делать несколько, если надо сформировать несколько h-файлов, относящихся к
одному исходнику.
HZ> Теперь в src2.c мы хотим ее использовать:
А тут пишем, как обычно, #include src1.h. Ведь этот файл будет сгенерирован
make с помощью специальной утилитки.
Я вообще люблю такие доработки. Hапример, ещё когда в 80-е работал с
ассемблером i8080, написал для него "структурные" макросы. Потом переносил их
и на ассемблеры x86 и x51.
HZ> P.S. Кстати, если заглянуть сюда:
HZ> http://sourceforge.net/projects/avr-ada/ и
HZ> http://avr-ada.sourceforge.net/
:) Спасибо. Только там, как я понял, всё в зачаточном виде...
Dimmy.

gnu make
Sat Sep 20 2003 11:05, Dimmy Timchenko wrote to Harry Zhurov:
HZ>> Все же непонятно, как же будет осуществляется раздельная
HZ>> компиляция?
DT> Точно так же, как и раньше, только "исходник" h-файла будет находиться в
DT> начале c-файла. В одном флаконе. Просто для удобства восприятия и
DT> редактирования. И на паскалевский юнит будет смахивать. :)
Как было справедливо замечено AD, на Сях это можно сделать через
условную компиляцию. Только в начале зависимых файлов
надо будет писать не "#include *.h" а "#include *.c",
и откусывать ненужные части.
VLV
HZ>> Все же непонятно, как же будет осуществляется раздельная
HZ>> компиляция?
DT> Точно так же, как и раньше, только "исходник" h-файла будет находиться в
DT> начале c-файла. В одном флаконе. Просто для удобства восприятия и
DT> редактирования. И на паскалевский юнит будет смахивать. :)
Как было справедливо замечено AD, на Сях это можно сделать через
условную компиляцию. Только в начале зависимых файлов
надо будет писать не "#include *.h" а "#include *.c",
и откусывать ненужные части.
VLV

Re: gnu make
Hello, Vladimir!
You wrote to Dimmy Timchenko on Sat, 20 Sep 2003 15:51:35 +0400:
VV> Как было справедливо замечено AD, на Сях это можно сделать через
VV> условную компиляцию.
Я не это имел в виду! :-)))
VV> Только в начале зависимых файлов надо будет писать не "#include *.h"
VV> а "#include *.c", и откусывать ненужные части.
В проекте, который мне сейчас приходится сопровождать, некий нехороший
человек написал так (во всех местах :-( ):
=== <db.h> ===
/* ... */
#ifdef _DB_C_
#define GLOBAL
#else
#define GLOBAL extern
#endif
/* */
GLOBAL int prarm;
GLOBAL uint32 get_db_first_byte();
/* */
#undef GLOBAL
=== </db.h> ===
=== <db.c> ===
#define _DB_C_
#include "db.h>
#include "wr.h"
=== </db.c> ===
Найти место где определяется переменная и её тип бывает очень непросто.
Глубина вложенности хидеров тоже внушаИтЬ. Они мне скоро сниться будут.
В мейк-файле работа начинается с копирования одного из h-файлов в
другой - в зависимости от указанной цели. А целью является _бренд_ под
который идёт сборка. Поскольку этот файл потом включается всюду, всякий раз
идёт полная перекомпиляция. Спрашивается - а на фига такой мейк?!
Повбывав-бы...
With best regards,
Alexander Derazhne.
You wrote to Dimmy Timchenko on Sat, 20 Sep 2003 15:51:35 +0400:
VV> Как было справедливо замечено AD, на Сях это можно сделать через
VV> условную компиляцию.
Я не это имел в виду! :-)))
VV> Только в начале зависимых файлов надо будет писать не "#include *.h"
VV> а "#include *.c", и откусывать ненужные части.
В проекте, который мне сейчас приходится сопровождать, некий нехороший
человек написал так (во всех местах :-( ):
=== <db.h> ===
/* ... */
#ifdef _DB_C_
#define GLOBAL
#else
#define GLOBAL extern
#endif
/* */
GLOBAL int prarm;
GLOBAL uint32 get_db_first_byte();
/* */
#undef GLOBAL
=== </db.h> ===
=== <db.c> ===
#define _DB_C_
#include "db.h>
#include "wr.h"
=== </db.c> ===
Найти место где определяется переменная и её тип бывает очень непросто.
Глубина вложенности хидеров тоже внушаИтЬ. Они мне скоро сниться будут.
В мейк-файле работа начинается с копирования одного из h-файлов в
другой - в зависимости от указанной цели. А целью является _бренд_ под
который идёт сборка. Поскольку этот файл потом включается всюду, всякий раз
идёт полная перекомпиляция. Спрашивается - а на фига такой мейк?!
Повбывав-бы...
With best regards,
Alexander Derazhne.

Re: gnu make
20-Sep-03 17:36 Alexander Derazhne wrote to Vladimir Vassilevsky:
AD> В проекте, который мне сейчас приходится сопровождать, некий нехороший
AD> человек написал так (во всех местах :-( ):
AD> === <db.h> ===
AD> /* ... */
AD> #ifdef _DB_C_
AD> #define GLOBAL
AD> #else
AD> #define GLOBAL extern
AD> #endif
М-мать!
Видать человек попытался сунуть int param в h-файл, получил
от линкера "многократное определение" и "с честью вышел из ситуации" :-)
Даже если считать, что компилятор не умеет нормально отрабатывать
extern int param;
int patram;
(что-то я таких компиляторов не видел или уже давно и счастливо забыл),
можно было всё-же переменную определить в c-файле а в h-файле написать
#ifndef _DB_C_
extern int param;
extern uint32 get_db_first_bute();
#endif
AD> Найти место где определяется переменная и её тип бывает очень непросто.
AD> Глубина вложенности хидеров тоже внушаИтЬ. Они мне скоро сниться будут.
AD> В мейк-файле работа начинается с копирования одного из h-файлов в
AD> другой - в зависимости от указанной цели. А целью является _бренд_ под
AD> который идёт сборка. Поскольку этот файл потом включается всюду, всякий
AD> раз идёт полная перекомпиляция. Спрашивается - а на фига такой мейк?!
КrЮт0й хакер работал :-) Хадействовал возможности на всю катушку :-))
AD> Повбывав-бы...
Угу. От "трудов" таких потом во все стороны идут мифы о ненужности
make и глупости C.
wbr,
AD> В проекте, который мне сейчас приходится сопровождать, некий нехороший
AD> человек написал так (во всех местах :-( ):
AD> === <db.h> ===
AD> /* ... */
AD> #ifdef _DB_C_
AD> #define GLOBAL
AD> #else
AD> #define GLOBAL extern
AD> #endif
М-мать!
Видать человек попытался сунуть int param в h-файл, получил
от линкера "многократное определение" и "с честью вышел из ситуации" :-)
Даже если считать, что компилятор не умеет нормально отрабатывать
extern int param;
int patram;
(что-то я таких компиляторов не видел или уже давно и счастливо забыл),
можно было всё-же переменную определить в c-файле а в h-файле написать
#ifndef _DB_C_
extern int param;
extern uint32 get_db_first_bute();
#endif
AD> Найти место где определяется переменная и её тип бывает очень непросто.
AD> Глубина вложенности хидеров тоже внушаИтЬ. Они мне скоро сниться будут.
AD> В мейк-файле работа начинается с копирования одного из h-файлов в
AD> другой - в зависимости от указанной цели. А целью является _бренд_ под
AD> который идёт сборка. Поскольку этот файл потом включается всюду, всякий
AD> раз идёт полная перекомпиляция. Спрашивается - а на фига такой мейк?!
КrЮт0й хакер работал :-) Хадействовал возможности на всю катушку :-))
AD> Повбывав-бы...
Угу. От "трудов" таких потом во все стороны идут мифы о ненужности
make и глупости C.
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */

Re: gnu make
Hello, Oleksandr!
14:07:36 +0000 (UTC):
OR> КrЮт0й хакер работал :-) Хадействовал возможности на всю катушку
OR> :-))
Это что... Он смешал "обычное" написание программ (не знаю как это по
научному называется) с event-driven model. Это надо видеть!
AD>> Повбывав-бы...
OR> Угу. От "трудов" таких потом во все стороны идут мифы о ненужности
OR> make и глупости C.
В другом проекте (C++, Java) дела пошли на лад только после того как
вычистили последние следы его деятельности. Так-что это языковонезависимо
:-)).
With best regards,
Alexander Derazhne.
14:07:36 +0000 (UTC):
OR> КrЮт0й хакер работал :-) Хадействовал возможности на всю катушку
OR> :-))
Это что... Он смешал "обычное" написание программ (не знаю как это по
научному называется) с event-driven model. Это надо видеть!
AD>> Повбывав-бы...
OR> Угу. От "трудов" таких потом во все стороны идут мифы о ненужности
OR> make и глупости C.
В другом проекте (C++, Java) дела пошли на лад только после того как
вычистили последние следы его деятельности. Так-что это языковонезависимо
:-)).
With best regards,
Alexander Derazhne.

gnu make
Hello Harry.
19 Sep 03 21:37, Harry Zhurov wrote to Dimmy Timchenko:
HZ> P.S. Кстати, если заглянуть сюда: http://sourceforge.net/projects/avr-ada/
HZ> и http://avr-ada.sourceforge.net/, то можно предположить, что скоро и на
HZ> твоей улице будет праздник! :-)
а пока: :)
=== Begin Windows Clipboard ===
The compiler crashes very often!
=== End Windows Clipboard ===
Alexey
19 Sep 03 21:37, Harry Zhurov wrote to Dimmy Timchenko:
HZ> P.S. Кстати, если заглянуть сюда: http://sourceforge.net/projects/avr-ada/
HZ> и http://avr-ada.sourceforge.net/, то можно предположить, что скоро и на
HZ> твоей улице будет праздник! :-)
а пока: :)
=== Begin Windows Clipboard ===
The compiler crashes very often!
=== End Windows Clipboard ===
Alexey

gnu make
Привет!
DT>> Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя"
DT>> из неё h-файл. А утилиту эту вызывать с помощью make, объявив
DT>> зависимость h-файлов от соответствующих c-файлов.
AM> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных хидеpов.
AM> подсовывая его гнyсномy мейкy, все полyчается кpасиво.
Hе вводи пользователей Softune в заблуждение. Формат файла зависимостей
Softune несколько отличается от gnu make, чтоб все было красиво необходимо
выполнить пару операций.
Еще существует забытая утилита makedepend из комплекта X11. Она формирует
файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
компиляторами, которые не умеют создавать списки зависимостей. Если кому надо,
сообщите - выложу на ftp.
_______
Сергей.
DT>> Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя"
DT>> из неё h-файл. А утилиту эту вызывать с помощью make, объявив
DT>> зависимость h-файлов от соответствующих c-файлов.
AM> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных хидеpов.
AM> подсовывая его гнyсномy мейкy, все полyчается кpасиво.
Hе вводи пользователей Softune в заблуждение. Формат файла зависимостей
Softune несколько отличается от gnu make, чтоб все было красиво необходимо
выполнить пару операций.
Еще существует забытая утилита makedepend из комплекта X11. Она формирует
файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
компиляторами, которые не умеют создавать списки зависимостей. Если кому надо,
сообщите - выложу на ftp.
_______
Сергей.

gnu make
Пpивет Sergey !
SP> Еще существует забытая утилита makedepend из комплекта X11. Она
SP> формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо,
SP> сообщите - выложу на ftp.
Вот что я нашел в портированном дистрибутиве winavr(gcc)
*#────────────────── begin of Windows Clipboard ──────────────────#*
# Automatically generate C source code dependencies.
# (Code originally taken from the GNU make user manual and modified (See
README.txt Credits).)
# Note that this will work with sh (bash) and sed that is shipped with WinAVR
(see the SHELL variable defined above).
# This may not work with other shells or other seds.
%.d: %.c
set -e; $(CC) -MM $(ALL_CFLAGS) $< \
| sed 's,\(.*\)\.o[ :]*,.o .d : ,g' > $@; \
[ -s $@ ] || rm -f $@
# Remove the '-' if you want to see the dependency files generated.
-include $(SRC:.c=.d)
*#─────────────────── end of Windows Clipboard ───────────────────#*
Делает тоже самое. Хотя makedepend был бы удобнее в том контексте, что не
нужно переделывать makefile каких-нибудь уже готовых проектов под *nix.
Поэтому, будь добр, выдожи на ФТП.
With best regards,
Sergey
SP> Еще существует забытая утилита makedepend из комплекта X11. Она
SP> формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо,
SP> сообщите - выложу на ftp.
Вот что я нашел в портированном дистрибутиве winavr(gcc)
*#────────────────── begin of Windows Clipboard ──────────────────#*
# Automatically generate C source code dependencies.
# (Code originally taken from the GNU make user manual and modified (See
README.txt Credits).)
# Note that this will work with sh (bash) and sed that is shipped with WinAVR
(see the SHELL variable defined above).
# This may not work with other shells or other seds.
%.d: %.c
set -e; $(CC) -MM $(ALL_CFLAGS) $< \
| sed 's,\(.*\)\.o[ :]*,.o .d : ,g' > $@; \
[ -s $@ ] || rm -f $@
# Remove the '-' if you want to see the dependency files generated.
-include $(SRC:.c=.d)
*#─────────────────── end of Windows Clipboard ───────────────────#*
Делает тоже самое. Хотя makedepend был бы удобнее в том контексте, что не
нужно переделывать makefile каких-нибудь уже готовых проектов под *nix.
Поэтому, будь добр, выдожи на ФТП.
With best regards,
Sergey

Re: gnu make
Hello Sergey.
Понедельник Сентябрь 22 2003 07:43, you wrote to Alexey Musin:
SP> Еще существует забытая утилита makedepend из комплекта X11. Она
SP> формирует файл зависимостей в формате gnu make. Собрал ее win-версию
SP> для работы с компиляторами, которые не умеют создавать списки
SP> зависимостей. Если кому надо, сообщите - выложу на ftp.
Вот если бы она оказалась еще и С-препроцессором, было бы замечательно.
Почему-то отдельный препроцессор мне не попадался, а использовать тот же gcc в
виде препроцессора кажется неразумным.
Leha
Понедельник Сентябрь 22 2003 07:43, you wrote to Alexey Musin:
SP> Еще существует забытая утилита makedepend из комплекта X11. Она
SP> формирует файл зависимостей в формате gnu make. Собрал ее win-версию
SP> для работы с компиляторами, которые не умеют создавать списки
SP> зависимостей. Если кому надо, сообщите - выложу на ftp.
Вот если бы она оказалась еще и С-препроцессором, было бы замечательно.
Почему-то отдельный препроцессор мне не попадался, а использовать тот же gcc в
виде препроцессора кажется неразумным.
Leha

Re: gnu make
Привет!
SP>> Еще существует забытая утилита makedepend из комплекта X11. Она
SP>> формирует файл зависимостей в формате gnu make. Собрал ее win-версию
SP>> для работы с компиляторами, которые не умеют создавать списки
SP>> зависимостей. Если кому надо, сообщите - выложу на ftp.
LB> Вот если бы она оказалась еще и С-препроцессором, было бы замечательно.
Так оно и есть в некоторой степени, цитата из man:
(не С-препроцессором, а _с_ С-препроцессором)
DESCRIPTION:
Makedepend reads each sourcefile in sequence and parses it like a
C-preprocessor, processing all #include, #define, #undef, #ifdef,
#ifndef, #endif, #if and #else directives so that it can correctly
tell which #include, directives would be used in a compilation. Any
#include, directives can reference files having other #include
directives, and parsing will occur in these files as well.
Every file that a sourcefile includes, directly or indirectly, is
what makedepend calls a "dependency". These dependencies are then
written to a makefile in such a way that make(1) will know which
object files must be recompiled when a dependency has changed.
LB> Почему-то отдельный препроцессор мне не попадался, а использовать тот же
LB> gcc в виде препроцессора кажется неразумным.
Завтра постараюсь выложить на ftp.
_______
Сергей.
SP>> Еще существует забытая утилита makedepend из комплекта X11. Она
SP>> формирует файл зависимостей в формате gnu make. Собрал ее win-версию
SP>> для работы с компиляторами, которые не умеют создавать списки
SP>> зависимостей. Если кому надо, сообщите - выложу на ftp.
LB> Вот если бы она оказалась еще и С-препроцессором, было бы замечательно.
Так оно и есть в некоторой степени, цитата из man:
(не С-препроцессором, а _с_ С-препроцессором)
DESCRIPTION:
Makedepend reads each sourcefile in sequence and parses it like a
C-preprocessor, processing all #include, #define, #undef, #ifdef,
#ifndef, #endif, #if and #else directives so that it can correctly
tell which #include, directives would be used in a compilation. Any
#include, directives can reference files having other #include
directives, and parsing will occur in these files as well.
Every file that a sourcefile includes, directly or indirectly, is
what makedepend calls a "dependency". These dependencies are then
written to a makefile in such a way that make(1) will know which
object files must be recompiled when a dependency has changed.
LB> Почему-то отдельный препроцессор мне не попадался, а использовать тот же
LB> gcc в виде препроцессора кажется неразумным.
Завтра постараюсь выложить на ftp.
_______
Сергей.

Посоветуйте _приличный_ микроконтроллер
Привет, уважаемый All!
Не спеши пинать меня за банальность сабжа - есть у меня задачка,
и хочется сделать ее красиво, но в течение месяца не могу накопать
ничего интересного, вот и решил ее вынести на обсуждение.
Задачка такая - контроллер встраиваемого термопринтера. Этот
принтер относится к классу GDI-устройств (бо зело проще было
написать драйвера), то есть весь рендеринг графики производится
в недрах Windows, по интерфейсу принтера передается уже или текст
или компрессированная графика. Собственно, уже разработан
контроллер на базе Mega128-16МГц, но он хорошо (достаточно быстро)
работает только с узкими термоголовками (2", 3", 4").
А вот потом пришел _ОН_ - термоголова ширина 8"/200dpi (есть еще варианты
300 dpi) с улучшенной энергетикой. Эти головы, способны отображать данные
со скоростью не менее 2 Мбит/сек. При этом интерфейс загрузки у них
типа SPI (двухканальный) и пропускает до 8 МБит/сек.
Второе узкое место - интерфейс - сейчас есть варианты RS-232 (до
460800), USB (кривоватый FTDI232, в итоге тот же RS внутри, зато
быстро USB "освоил" :-( и Centronics, экономно (но медленно)
реализованный на сдвиговом регистре с параллельной загрузкой.
Третье узкое место - уже появляются требования к дополнительной
обработке графических данных, да и RLE декомпрессия на таких
скоростях тоже уже не бесплатна в смысле производительности.
Кроме того, для приличной обработки уже надо RAM, хорошо бы
пару мегабайт.
Короче, понятно - AVR 16МГц еле дышит (я это предвидел, но мне
никто не дал ни времени/ни денег реализовывать это нормально, да
и на узких форматах все более/менее шуршит). Скорость от 2 до 6
pps формата A4 в зависимости от картинки. Но это не самое плохое.
Еще хуже то, что процессор не успевает прогружать голову (одновременно
обрабатывая 50-100К прерываний от интерфейса и декомпрессируя данные),
при этом падает частота шагов на системе позиционирования (до 50-100
шагов/сек)
и в системе развиваются приличные механические колебания, мало того
что это дело начинает шуметь (с модуляцией по плотности поступаемой
графики), так и резко возрастает износ (шестерни-то капроновые).
Посему, чего же я хотел бы от нового микроконтроллера (в порядке
убывания приоритета):
- internal program flash memory - от 64К, ессно ISP;
- internal RAM - ну пусть от 8К минимум, хотя и напряг;
- непременно DMA или его аналог (типа DTC у Atmel для UART);
- SPI (SIO, SCI или чего еще), обязательно с DMA;
- external DMA channel (для Centronics);
- UART (DMA желателен, но FIFO тоже поможет, да
и скорости уже обычно не те);
- USB-device 1.1, обязательно c DMA, можно low-speed;
- от 10 МИПС (если будет DMA, то интерфейсы и голову уже
обслуживать почти не надо, а декомпрессия RLE это простой
и малокушающий алгоритм);
Ну еще пожелания (во губу раскатал-то :-)
- встроенный контроллер внешней DRAM/SDRAM памяти (пару метров RAM
были бы кстати на будущее);
- ARM архитектура (хорошо распространена - ИМХО это "аналог"
i51 среди 8-битников, тоже толпой производителей выпускается,
с разной периферией). Но с архитектурой уж как повезет, сгодится
любая другая, лишь бы периферия приличная была.
Вот такая проблема, месяц неспешно ищу - ничего не попадается, смотрел
Fujitsu/Hitachi/Mitsubishi/Siemens/ST/Philips/OKI/Samsung/Hynix/Sharp/Cirrus.
В-основном ARMы. Может, плохо смотрел, или еще где надо поискать?
Проблема в USB - все еще маловато чипов с ним. Но я уж готов и
внешний типа USBN9604 ставить. Монстры в >400 pin BGA тоже грустновато
как-то и у них с внутренним флешом обычно напряг.
Не спеши пинать меня за банальность сабжа - есть у меня задачка,
и хочется сделать ее красиво, но в течение месяца не могу накопать
ничего интересного, вот и решил ее вынести на обсуждение.
Задачка такая - контроллер встраиваемого термопринтера. Этот
принтер относится к классу GDI-устройств (бо зело проще было
написать драйвера), то есть весь рендеринг графики производится
в недрах Windows, по интерфейсу принтера передается уже или текст
или компрессированная графика. Собственно, уже разработан
контроллер на базе Mega128-16МГц, но он хорошо (достаточно быстро)
работает только с узкими термоголовками (2", 3", 4").
А вот потом пришел _ОН_ - термоголова ширина 8"/200dpi (есть еще варианты
300 dpi) с улучшенной энергетикой. Эти головы, способны отображать данные
со скоростью не менее 2 Мбит/сек. При этом интерфейс загрузки у них
типа SPI (двухканальный) и пропускает до 8 МБит/сек.
Второе узкое место - интерфейс - сейчас есть варианты RS-232 (до
460800), USB (кривоватый FTDI232, в итоге тот же RS внутри, зато
быстро USB "освоил" :-( и Centronics, экономно (но медленно)
реализованный на сдвиговом регистре с параллельной загрузкой.
Третье узкое место - уже появляются требования к дополнительной
обработке графических данных, да и RLE декомпрессия на таких
скоростях тоже уже не бесплатна в смысле производительности.
Кроме того, для приличной обработки уже надо RAM, хорошо бы
пару мегабайт.
Короче, понятно - AVR 16МГц еле дышит (я это предвидел, но мне
никто не дал ни времени/ни денег реализовывать это нормально, да
и на узких форматах все более/менее шуршит). Скорость от 2 до 6
pps формата A4 в зависимости от картинки. Но это не самое плохое.
Еще хуже то, что процессор не успевает прогружать голову (одновременно
обрабатывая 50-100К прерываний от интерфейса и декомпрессируя данные),
при этом падает частота шагов на системе позиционирования (до 50-100
шагов/сек)
и в системе развиваются приличные механические колебания, мало того
что это дело начинает шуметь (с модуляцией по плотности поступаемой
графики), так и резко возрастает износ (шестерни-то капроновые).
Посему, чего же я хотел бы от нового микроконтроллера (в порядке
убывания приоритета):
- internal program flash memory - от 64К, ессно ISP;
- internal RAM - ну пусть от 8К минимум, хотя и напряг;
- непременно DMA или его аналог (типа DTC у Atmel для UART);
- SPI (SIO, SCI или чего еще), обязательно с DMA;
- external DMA channel (для Centronics);
- UART (DMA желателен, но FIFO тоже поможет, да
и скорости уже обычно не те);
- USB-device 1.1, обязательно c DMA, можно low-speed;
- от 10 МИПС (если будет DMA, то интерфейсы и голову уже
обслуживать почти не надо, а декомпрессия RLE это простой
и малокушающий алгоритм);
Ну еще пожелания (во губу раскатал-то :-)
- встроенный контроллер внешней DRAM/SDRAM памяти (пару метров RAM
были бы кстати на будущее);
- ARM архитектура (хорошо распространена - ИМХО это "аналог"
i51 среди 8-битников, тоже толпой производителей выпускается,
с разной периферией). Но с архитектурой уж как повезет, сгодится
любая другая, лишь бы периферия приличная была.
Вот такая проблема, месяц неспешно ищу - ничего не попадается, смотрел
Fujitsu/Hitachi/Mitsubishi/Siemens/ST/Philips/OKI/Samsung/Hynix/Sharp/Cirrus.
В-основном ARMы. Может, плохо смотрел, или еще где надо поискать?
Проблема в USB - все еще маловато чипов с ним. Но я уж готов и
внешний типа USBN9604 ставить. Монстры в >400 pin BGA тоже грустновато
как-то и у них с внутренним флешом обычно напряг.
--
Best regards,
Vyacheslav mailto: snipped-for-privacy@helpco.kiev.ua
Best regards,
Vyacheslav mailto: snipped-for-privacy@helpco.kiev.ua

gnu make
What do you think about sharp blades, Leha?
[Answer on] [Leha Bishletov wrote to Sergey Pinigin at [22 Sep 03 14:04]]:
LB> Вот если бы она оказалась еще и С-препроцессором, было бы
LB> замечательно. Почему-то отдельный препроцессор мне не попадался, а
LB> использовать тот же gcc в виде препроцессора кажется неразумным.
gcc -- это ведь только драйвер. И он звоет внешний препроцессор cpp, который
выдирается влегкую.
Сам gcc вообще ничего не умеет, кроме как звать препроцессор, два компилятора
и линкер в правильном порядке и с правильными ключами :)
Remember, pain is part of pleasure, Leha.
... Что там колышется над твоей головой -/Северный Мост или Южный Крест?
[Answer on] [Leha Bishletov wrote to Sergey Pinigin at [22 Sep 03 14:04]]:
LB> Вот если бы она оказалась еще и С-препроцессором, было бы
LB> замечательно. Почему-то отдельный препроцессор мне не попадался, а
LB> использовать тот же gcc в виде препроцессора кажется неразумным.
gcc -- это ведь только драйвер. И он звоет внешний препроцессор cpp, который
выдирается влегкую.
Сам gcc вообще ничего не умеет, кроме как звать препроцессор, два компилятора
и линкер в правильном порядке и с правильными ключами :)
Remember, pain is part of pleasure, Leha.
... Что там колышется над твоей головой -/Северный Мост или Южный Крест?

gnu make
Sergey Pinigin wrote to Alexey Musin on Mon, 22 Sep 2003 07:43:23 +0400:
SP> Еще существует забытая утилита makedepend из комплекта X11. Она формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо, сообщите - выложу на ftp.
Конечно выложи! Только адрес ftp потом скажи? :))
...so long!
### Съисть-то он все ето - съисть, тольки хто ему все ето дасть?
SP> Еще существует забытая утилита makedepend из комплекта X11. Она формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо, сообщите - выложу на ftp.
Конечно выложи! Только адрес ftp потом скажи? :))
...so long!
### Съисть-то он все ето - съисть, тольки хто ему все ето дасть?

Re: gnu make
22-Sep-03 07:43 Sergey Pinigin wrote to Alexey Musin:
SP> Еще существует забытая утилита makedepend из комплекта X11. Она формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо,
SP> сообщите - выложу на ftp.
Она же есть в комплекте UnxUtils (GNU utilites for Win32,
что особо приятно, работает без cygwin), лежат на
http://unxutils.sourceforge.net/
Там есть make/grep/sed/gawk/zip/unzip/bzip2/which/less
и куча всякого другого добра типа indent (такая форматировалка
C-шных текстов в разных стилях) и uuencode/uudecode.
wbr,
SP> Еще существует забытая утилита makedepend из комплекта X11. Она формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо,
SP> сообщите - выложу на ftp.
Она же есть в комплекте UnxUtils (GNU utilites for Win32,
что особо приятно, работает без cygwin), лежат на
http://unxutils.sourceforge.net/
Там есть make/grep/sed/gawk/zip/unzip/bzip2/which/less
и куча всякого другого добра типа indent (такая форматировалка
C-шных текстов в разных стилях) и uuencode/uudecode.
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
Site Timeline
- » Подскажите что за компилятор
- — Next thread in » Microcontrollers (Russian)
-
- » BlowIT 2051 Programmer
- — Previous thread in » Microcontrollers (Russian)
-
- » По моему это гениально
- — Newest thread in » Microcontrollers (Russian)
-
- » kostenlos abzugeben
- — The site's Newest Thread. Posted in » Electronics (German)
-
- » Wide frequency range, arbitrary waveform DDS
- — The site's Last Updated Thread. Posted in » Embedded Programming
-