make (WinAVR vs MSYS)

2-Sep-04 09:10 Alexey Boyko wrote to Oleksandr Redchuk:

AB> Пробовал разные комбинации make/bash, из MSYS из WinAVR. make не всегда AB> хотел AB> запускать процессы. Говорит ошибка CreateProcess и все. Hо это было под AB> WinME. Угу, и такое тоже. Пока не добавил в начало PATH путь туда, куда считаю нужным, во многих местах приходилось писать, скажем, $(RM) или $(SED) и прописывать путь к тому, который нужен. Но экспорт PATH не работает для CreateProcess. Я просто насильно заставил make всегда и всё делать через shell.

AB> Вчера делал тоже самое из под WinXP - таких проблем не возникло. make и AB> bash были от WinAVR. Если всё от одного - то нет проблем (W2K, другого нет под рукой).

AB> Проблема возникла только с MED. При запуске из MED make не может запускать AB> программы. Если включить альтернативный режим перехвата вывода, то AB> работает, Да, альтернативный. AB> но вроде не все перехватывает. Подробно не разбирался, так как цель AB> такая не стоит. У меня вроде бы всё перехватывает, не жалуюсь. Где-то с MED 2.51 по 3.00 без проблем.

AB> ps: Я говорил, что листинг от avr-gcc я обрабатываю скриптом на sed-е, AB> который приводит его к более удобочитаемому виду? И даже в эху постил, и даже он у меня где-то лежит.

wbr,

Алексей, приветствую!

Ну раз уж сказал, то может поделишься? Видать тогда я с gcc не работал и полезные примочки в свои закрома не складывал.

Кстати, что есть из бесплатных (по-настоящему бесплатных) редакторов, которые можно использовать как IDE и которые очень желательно имели бы порт и под W32 и под Linux, чтоб потом можно было наработки перетащить под Linux?

С уважением, Сергей Борщ

3-Sep-04 12:17 Alexey Boyko wrote to Oleksandr Redchuk:

OR>> Я просто насильно заставил make всегда и OR>> всё делать через shell.

AB> А как? :-)

Точкой с зяпятой. foo: ls будет через CreateProcess moo: ls ; make увидел "не просто вызов программы" и уже будет вызван sh Но на самом деле я "раз так, то" подобавлял команду echo в духе

$(OBJDIR)/%.o : %.c echo ======== Compiling $< ;\ $(CC) -c $(CFLAGS) $(addprefix -I,$(INCDIRS))\ -Wa,-ahlmsd=$(LSTDIR)/$(notdir $(<:.c=.lst)) $< -o $@

и втулил .SILENT : Последовательности команд через ';' make однозначно принимает как "это к shell-у".

OR>> И даже в эху постил, и даже он у меня где-то лежит. AB> Hе пригодился? Ну почему. Изредка пользуюсь. Даже подправил что-то - снял удаление /* function , чтобы размер функции и её тела был виден) и убрал изредка встречающуюся какую-то мелочь, начинающуюся с .L. Просто я довольно редко сейчас на код смотрю.

AB> ps: Hасчет dlportio.sys:

AB> uisp из комплекта WinAVR использует драйвер givio.sys. Он размером 5 кБ AB> К нему loaddrv.exe на 11кБ и батничек для инсталляции. Hе хочешь переделать AB> avreal под него? А то dlportio.sys таскается в виде одномегабайтного AB> исталлятора. Хочу. Уже довольно давно :-) Более того, хочу переделать ещё и через альтеровский драйвер, который идёт с максплюсом да квартусом (у многих, включая меня, он всё равно стоит).

AB> К giveio.sys обращение через ioctl. Разрешается доступ к портам, а потом AB> обычные in/out. loaddrv.exe вроде есть с исходниками. avreal, в принципе, Ага, а потом окажется, что они с GPL и пошла поехала. В таком случае лучше уж я exec-ом буду этот loaddrv звать. Если я когда-то потеряю стыд настолько, что открою исходники avreal, они будт под BSD лицензией, чтобы народ голову себе не морочил по поводу границ допустимого и способов связывания.

AB> может сам загружать giveio.sys, если он еще не загружен. Оно (W2K) позволяет не-администратору это делать? Тю. Или рассчитывать, что будут работать под администратором? Ещё более тю.

Уже запланирован ключик -ad=driver

-ad=direct прямой доступ к портам (по сути для W98, чтобы и win32 программа, но вообще без драйверов)

-ad=dlportio

-ad=giveio

-ad=altera

Понятное дело, что тут главное в принципе сделать вариантность, а дальше добавление новых несложно.

wbr,

4-Sep-04 01:34 Kirill Frolov wrote to Alex Mogilnikov:

AM>> emacs, jed, vim (не в курсе, собирается ли последний под win32, но AM>> скорее AM>> всего да).

KF> Vim есть везде, Vim есть всегда.

И для win32 он есть и консольный, и графический. Только вот мне при наличии MED всё как-то недосуг разобраться, как же в vim сделать поиск слова во всех исходниках проекта (естественно, с выдачей в отдельном окне этих строк и с последующим хождением по исходникам тыкая в эти строки). Такое ощущение, что надо найти в palin text описание vim-а да в палм затолкать.

wbr, p.s. Да, MED не бесплатен, но и не дорог. А у меня уже накопились предложения к автору ... Проплатить, чтоли, да "честно" потрясти :-)

4-Sep-04 01:36 Kirill Frolov wrote to Alexey Boyko:

OR>>> Я просто насильно заставил make всегда и OR>>> всё делать через shell. AB>> А как?

KF> SHELL = sh.exe KF> MAKESHELL = sh.exe Для нескольких виденных мной разных make для win32 это только даёт то, что для *скриптовых* участков makefile таки вызывается найденный по PATH sh.exe, а не смотрится в COMSPEC

Но даже при

AVRGCC = c:/WinAVR-20040720 SHELL = $(AVRGCC)/utils/bin/sh.exe

*одиночные* команды в правилах выполняются не через sh, а через прямой вызов CreateProces() В принципе, это может быть эффективнее.

Сразу скажу - имеется ввиду вызов "нативных" make (пользующихся максимум msvcrt.dll) и MSYS-овского, цигвина не пробовал.

Ну так вот, foo: a где a не существует в природе - для "нативного" говорит "CreateProcess ... failed", для msys-овского make: a.exe: Command not found Т.е. делается одиночный вызовы команды без subshell (для двух a и b в смежных строках будет то же самое два раза). А вот для foo: a ; имеем d:\temp\make7202.sh: a.exe: command not found и /bin/sh.exe: a.exe: command not found соответственно.

Другое дело, что MSYS-овскому make и не надо ничего форсировать, так как PATH экспортируется сразу и даже одиночные команды отрабатываются при нужном состоянии окружения.

Но, как я уже сказал, на работе пока действует "работает - не трогай". Я сначала перетрясу все makefile пряча/восстанавливая "нативный" make, потом только уберу лишнее и оставлю только MSYS. Ну только zip/unzip из unxtools добавлю.

wbr,

4-Sep-04 04:45 Maxim Polyanskiy wrote to Alexey Boyko:

AB>> uisp из комплекта WinAVR использует драйвер givio.sys. Да и у mspgcc тоже. msp430-jtag через него работает. Собственно, через этот драйвер легко работать, портируя с линукса то, что работало через ioperm()

MP> Ты не мудри а просто ссылку дай ;) Если ты пробовал искать в гугле и не нашёл, то ищи giveio.sys. У Алексея описочка вышла. А у меня этот драйвер по всему винту бегает, он сейчас с чем не лень в комплекте идёт, так что я тебе тоже ссылочку дать не смогу :-)

wbr,

4-Sep-04 19:28 Roman Khvatov wrote to Oleksandr Redchuk:

OR>> Понятное дело, что тут главное в принципе сделать вариантность, а OR>> дальше добавление новых несложно.

RK> Тогда уж -ad=dll:my_driver[:bla-bla-bla] RK> my_driver.dll имеет стандартый (для AvReal) интерфейс для связи с RK> портами через Об этом я тоже думал, только не двоеточие (да, да, я понимаю, стандартный в линуксе разделитель :-), а запятая, больше похоже на остальные нынешние ключи. Какая ни есть, а система.

Но в конечном итоге решил пока сделать так. В смысле, пока пусть будет монолит. Я пока не решил, где лучше проводить грань dll/so. Почему-то мне кажется, что эта грань лучше ложится на линии "spi-контроллера с с некоторым количеством GPIO", а вот через что он сделан - на усмотрение его разработчика :-) Тогда выйдет

-ad=spi,some_spi.dll,bla-bla-bla

Но тут надо немного подумать на тему интерфейса с таким spi-контроллером, особенно в плане "какие GPIO поставить в 0/1, какой из них будет сброс", И вообще -- как отмапить SCK/MOSI/MISO для контроллера, который это может. Похоже, что это всё "не avreal-ово дело", а bla-bla-bla на самом деле имя файла, который будет передан в dll для использования в качестве ini-файла либо имя раздела в some_spi.ini.

wbr,