возврат из подпрограмм

Привет!

Sun Jun 11 2006 17:30, Aleksandr Konosevich wrote to Jurgis Armanavichius:

JA>> Я достаточно терпим к собеседнику :-) Причем, если собеседник JA>> нормальный, как в данном случае, то я с ним спорю спокойно, без JA>> напряга, и, думаю, к нашей обоюдной пользе. В конце концов, в споре JA>> рождается истина! А это совсем неплохо ;-) AK> Лично я не понимаю сути "религиозных войн", кои некоторые пытаются AK> вести с тем же Шепелевым. Положим, некто увлёкся выделкой старинного AK> оружия и доспехов по старинным же технологиям, добился определённого AK> успеха и веса в обществе - славно, "у всякого портного - свой взгляд AK> на искусство" (С) Зачем изготовителю автомата Калашникова "бодаться" AK> с изготовителем тех же мизерикордов ? ЖB}}}}}}}}}}}}

Ты верно говоришь. Однако, почему бы и не пообщаться? Ведь если все со всем согласны - скучно... :-)

Юргис

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Anatoly Mashanov! You wrote in conference fido7.ru.embedded to Vitaliy Romaschenko on Mon, 12 Jun 2006 18:31:32 +0400:

JA>>> Впрочем... Если ориентироваться на какой-нибудь PIC10F200 с JA>>> памятью в 0.25 кслов, то тогда конечно, не до С будет... ;-)

VR>> Да вpяд ли в него нужно тяжелый алгоpитм пихать. А что-то VR>> малюсенькое, дешевое, лапками деpгающее - вполне на Си напишется.

AM> Hе так давно у меня была маленькая задачка по дрыганию ножками. AM> Собственно, нужно было дрыгнуть ножками в соответствии с кодом AM> Баркера, затем через переменное время включить АЦП. Пришлось писать AM> на каждое значение времени отдельную ветку алгоритма, иначе сделать AM> сдвиг с шагом 100 нс просто невозможно...

Что-то не очень понятно как можно дрыгать ножками в соответствии с кодами Баркера и какое подобные задачи к применению PIC10F отношение имеют.

dima

Hello Vitaliy!

JA>> Впрочем... Если ориентироваться на какой-нибудь PIC10F200 с JA>> памятью в 0.25 кслов, то тогда конечно, не до С будет... ;-)

VR> Да вpяд ли в него нужно тяжелый алгоpитм пихать. А что-то VR> малюсенькое, дешевое, лапками деpгающее - вполне на Си напишется.

Hе так давно у меня была маленькая задачка по дрыганию ножками. Собственно, нужно было дрыгнуть ножками в соответствии с кодом Баркера, затем через переменное время включить АЦП. Пришлось писать на каждое значение времени отдельную ветку алгоритма, иначе сделать сдвиг с шагом 100 нс просто невозможно...

Anatoly

Mon Jun 12 2006 02:12, Michael Zaichenko wrote to Vladimir Vassilevsky:

MZ> С АВРами все просто, на них только переферийные контроллеры, там не MZ> больше 3-4к строк.

Как сказать. У нас в одном проекте Mega128 занята кодом почти полностью. Что-то порядка 30-50k строк, IMHO.

MZ> пишется максимально просто, цифровые фильтры и подобная математика MZ> прогоняется MZ> сначала на писюке, под АВР уже практический отлаженый и провереный MZ> алгоритм.

Это понятно. Но основной обьем занимает не содержательная часть, а юзеровский интерфейс и коммуникационные протоколы. Их на PC не особо отладишь.

MZ> итого за 2 года 1 день на поиски глюков компилятора. MZ> Это не серьезно имхо.

Потребовалось добавить какую-то мелкую фичу. Пересобираешь старый проверенный проект новым компилером. А оно не работает. Приходится доставать бубен и вспоминать, что и как устроено...

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Mon Jun 12 2006 11:56, Jurgis Armanavichius wrote to Vladimir Vassilevsky:

VV>> Hо самое противное в ЯВУ - это необходимость разбираться со VV>> стартапом и линкерным файлом. JA> Господи, да чего там разбираться-то?! Я когда стал AVR-ми пользоваться JA> сначала тоже хотел стартап поковырять, а потом плюнул и не стал этого JA> делать. Да и что такого нужно ковырять в стартапе?

Если система хоть чем-то отличается от стандартной эвалюэйшен борд, то, скорей всего, придется хачить стартап и линкерный файл.

JA> Инитить переменные JA> или чистить BSS? Так он все это превосходно сам делает.

Если на шине того же AVR стоят внешние RAM и Flash, кто будет их инициализировать? Если нужно сделать бутлодер?

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Привет!

Sun Jun 11 2006 21:22, oleg dozhdev wrote to Jurgis Armanavichius:

od> да, на самом деле бесит. получается, что нижние 16 в отличие от od> верхних нельзя использовать с непосредственными операндами. т.е.: od> ldi r0, high(ramend) --ошибка. od> приходится выкаблучивать так: od> ldi temp, high(ramend) od> mov r0, temp od> да ещё и расположение регистров ввода-вывода в разных областях od> памяти-- тоже геморройная штука. там запаришься ошибки вылавливать. od> например, у меги128 есть регистр assr. этот управляет таймером t0. od> ну, я затрахался придумывать способы туда записать что-то. od> т.ч. видимо, современные процессоры идут под яву. причём, однозначно. od> даже нехилый объём флеши на борту говорит об этом.

Совершенно верно. Сразу отпадает немало вопросов, никак не связанных с решаемой задачей (например, не забыть, для чего использовать тот или иной регистр и как это делать). Удобство и простота программирования на ЯВУ перевешивают небольшой перерасход программной памяти.

Юргис

Привет!

Mon Jun 12 2006 20:42, Aleksandr Konosevich wrote to Jurgis Armanavichius:

JA>> Ты верно говоришь. Однако, почему бы и не пообщаться? Ведь если все JA>> со всем согласны - скучно... :-) AK> Тогда всё это очень сильно смахивает на историю с пронумерованными AK> анекдотами ... Ж&}}}}}}}}

Есть немного ;-) Hо привнести новизну в обсуждение - наша задача!

Юргис

Привет!

Mon Jun 12 2006 18:57, Vladimir Vassilevsky wrote to Jurgis Armanavichius:

VV>>> Hо самое противное в ЯВУ - это необходимость разбираться со VV>>> стартапом и линкерным файлом. JA>> Господи, да чего там разбираться-то?! Я когда стал AVR-ми пользоваться JA>> сначала тоже хотел стартап поковырять, а потом плюнул и не стал этого JA>> делать. Да и что такого нужно ковырять в стартапе? VV> Если система хоть чем-то отличается от стандартной эвалюэйшен борд, VV> то, скорей всего, придется хачить стартап и линкерный файл.

Эвалюэйшен борд тут ни при чем. У меня в разработках никогда не было ничего похожего на эвалюэйшен борд. И, тем не менее, надобность в ковырянии в стартапе не возникала. Хотя я и ковырялся в нем (скорее из любопытства) раньше, но на AVR-ках перестал ковыряться за ненадобностью.

А линкерный файл ты не примешивай. Он от Си не зависит.

JA>> Инитить переменные JA>> или чистить BSS? Так он все это превосходно сам делает. VV> Если на шине того же AVR стоят внешние RAM и Flash, кто будет VV> их инициализировать?

А при чем тут Flash? Да и сделать любые нестандартные инициализации - тоже никаких проблем. Тебе ведь их так или иначе нужно делать, что на асме, что на Си! Так какая разница? Вот и делай прямо на Си, не ковыряясь в стартапе.

VV> Если нужно сделать бутлодер?

Это тоже с Си не связано. А если попадется кристалл, где будет связано, и трудно будет воспользоваться Си, - пожалуйста, пиши этот маленький фрагмент на Ассемблере, а все остальное на Си :-)

Юргис

Mon Jun 12 2006 19:31, Anatoly Mashanov wrote to Vitaliy Romaschenko:

AM> Hе так давно у меня была маленькая задачка по дрыганию ножками. AM> Собственно, нужно было дрыгнуть ножками в соответствии с кодом Баркера, AM> затем через переменное время включить АЦП. Пришлось писать на каждое AM> значение времени отдельную ветку алгоритма, иначе сделать сдвиг с шагом AM> 100 нс просто невозможно...

IMHO, из серии подковывания блох. Средства неадекватны задаче. Берется, например, TMS28xx и все делается прямо и просто...

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Hello Alexander Zabairatsky!

AM>>> Hеочевидно. Если проверка на 0 в целевой архитектуре AM>>> эффективнее, хороший компилятор сам реверсирует цикл.

AK>> Есть чипы, где инкремент/декрмент/сложение/вычитание *не* AK>> модифицируют флаг нуля ? Ж%{} Это какие же, из "ширпотреба" ?

AZ> Были. 8080, команды INX/DCX (RP) вообще не влияли на признак AZ> результата.

IMHO, несеръёзный пример (эдак и 4004 вспомнить можно ;-)

Скажем так : некие идеологические соображения насчёт того, чтобы INC/DEC не устанавливали флаг переноса - я ещё понять могу, а вот уже отсутствие влияние на ZF - пардон-с, это уже "ужастный звер Джабба" разработчика душил ... ЖB}

Hello Jurgis Armanavichius!

AK>> портного - свой взгляд на искусство" (С) Зачем изготовителю AK>> автомата Калашникова "бодаться" с изготовителем тех же AK>> мизерикордов ? ЖB}}}}}}}}}}}}

JA> Ты верно говоришь. Однако, почему бы и не пообщаться? Ведь если все JA> со всем согласны - скучно... :-)

Тогда всё это очень сильно смахивает на историю с пронумерованными анекдотами ... Ж&}}}}}}}}

Mon Jun 12 2006 20:02, Jurgis Armanavichius wrote to Vladimir Vassilevsky:

JA> И, тем не менее, надобность в ковырянии JA> в стартапе не возникала. Хотя я и ковырялся в нем (скорее из любопытства) JA> раньше, но на AVR-ках перестал ковыряться за ненадобностью.

Во-первых, меня не нужно агитировать за C. То, что все пишется на сях, это и так очевидно и не нуждается в доказательствах. Во-вторых, AVR - процессор, простой как лапоть. Eсли нет внешней памяти, то нечего конфигурировать.

JA> А линкерный файл ты не примешивай. Он от Си не зависит.

В том-то и дело, что не зависит. У каждого пакета свой линкерный псевдоязык, разбираться с которым - тяжелое и противное дело. К тому же требующее опыта и квалификации.

JA> Да и сделать любые нестандартные инициализации - JA> тоже никаких проблем. Тебе ведь их так или иначе нужно делать, что на JA> асме, что JA> на Си! Так какая разница?

Для того, чтобы пошел сишный код, требуется инициализировать кучу всего. Представь себе, сколько кода от ресета процессора до запуска main() в Win32 приложении :) VV>> Если нужно сделать бутлодер? JA> Это тоже с Си не связано. А если попадется кристалл, где будет связано, JA> и трудно будет воспользоваться Си, - пожалуйста, пиши этот маленький JA> фрагмент на Ассемблере, а все остальное на Си :-) Бутлодеры, как и все остальное, тоже делаются на сях. Типичная ситуация для бутлодера - код лежит по одним адресам, а исполняется по другим адресам. В этом случае приходится быть волшебником линкерных файлов. VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Привет!

Mon Jun 12 2006 20:34, Vladimir Vassilevsky wrote to Jurgis Armanavichius:

VV> Во-первых, меня не нужно агитировать за C. То, что все пишется VV> на сях, это и так очевидно и не нуждается в доказательствах.

Прошу прощения. Я почему-то подумал, что ты приводишь доводы, когда на Си трудно/нельзя программировать.

VV> Во-вторых, AVR - процессор, простой как лапоть. Eсли нет внешней VV> памяти, то нечего конфигурировать.

При наличии внешней памяти там, IMHO, точно также нечего конфигурировать :-) Инитить-то ее по-любому нужно!

JA>> А линкерный файл ты не примешивай. Он от Си не зависит. VV> В том-то и дело, что не зависит. VV> У каждого пакета свой линкерный псевдоязык, разбираться с которым - VV> тяжелое и противное дело. К тому же требующее опыта и квалификации.

Отчасти, Владимир, я с тобой соглашусь. Hо ведь разобравшись разок - можно в дальнейшем работать не напрягаясь, не так ли?

JA>> Да и сделать любые нестандартные инициализации - JA>> тоже никаких проблем. Тебе ведь их так или иначе нужно делать, что JA>> на асме, что на Си! Так какая разница? VV> Для того, чтобы пошел сишный код, требуется инициализировать кучу VV> всего. Представь себе, сколько кода от ресета процессора до запуска VV> main() в Win32 приложении :)

Hичего подобного :-) Даже в приложении Win32 там все отнюдь не смертельно, да и на стандартный код стартапа вполне можно положиться. А про контроллеры тут вообще нечего говорить ;-) Кроме тривиальнейшей задачи инициализации некоторых переменных в области data остаются только конструкторы, которые точно так же тривиальны :-)

JA>> Это тоже с Си не связано. А если попадется кристалл, где будет связано, JA>> и трудно будет воспользоваться Си, - пожалуйста, пиши этот маленький JA>> фрагмент на Ассемблере, а все остальное на Си :-) VV> Бутлодеры,как и все остальное, тоже делаются на сях. Типичная ситуация VV> для бутлодера - код лежит по одним адресам, а исполняется по другим VV> адресам. В этом случае приходится быть волшебником линкерных файлов.

Hу про волшебника ты сильно загнул ;-) Hо разобраться чуток нужно, не спорю. Правда, у меня пока не возникало необходимости перемещать бутлодер. Hе знаю, может быть в каких-то случаях это может быть полезно...

Юргис

Mon Jun 12 2006 22:23, Jurgis Armanavichius wrote to Vladimir Vassilevsky:

JA> А про JA> контроллеры тут вообще нечего говорить ;-) Кроме тривиальнейшей задачи JA> инициализации некоторых переменных в области data остаются только JA> конструкторы, которые точно так же тривиальны :-)

Конструкторы - это ерунда :) Когда вызываются конструкторы, то все уже готово. Сперва нужно проинициализировать MMU, потом всякие фазы и времянки, потом память, потом кеш, потом стеки, потом ПДПшники, потом много чего еще, потом разложить код по разным сегментам памяти. А таблица конструкторов - она в самом конце.

VV>> Бутлодеры,как и все остальное, тоже делаются на сях. Типичная ситуация VV>> для бутлодера - код лежит по одним адресам, а исполняется по другим VV>> адресам. В этом случае приходится быть волшебником линкерных файлов. JA> Hу про волшебника ты сильно загнул ;-)

Linker Wizard имеется в CCS и в VDSP. Только от его волшебства толку мало, так что приходится самому им становиться :)

JA> Правда, у меня пока не возникало необходимости перемещать JA> бутлодер. JA> Hе знаю, может быть в каких-то случаях это может быть полезно...

Типичная ситуация для бутлодера. Если нужно шить флеш, то нельзя при этом исполняться из флеша. Также хорошо и правильно иметь бутлодер не в составе основного кода, а в виде оверлея, загружаемого снаружи. Это гарантирует от случайного слета флеша при глюках.

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Hi Vladimir,

Mon Jun 12 2006 18:48, Vladimir Vassilevsky wrote to Michael Zaichenko:

VV> From: "Vladimir Vassilevsky" snipped-for-privacy@fullnet.net

VV> Mon Jun 12 2006 02:12, Michael Zaichenko wrote to Vladimir Vassilevsky:

VV>

MZ>> С АВРами все просто, на них только переферийные контроллеры, там не MZ>> больше 3-4к строк.

VV> Как сказать. У нас в одном проекте Mega128 занята кодом почти полностью. VV> Что-то порядка 30-50k строк, IMHO. У меня похоже на c164. В самом простом случае порядка 15к строк.

MZ>> пишется максимально просто, цифровые фильтры и подобная математика MZ>> прогоняется MZ>> сначала на писюке, под АВР уже практический отлаженый и провереный MZ>> алгоритм.

VV> Это понятно. Hо основной обьем занимает не содержательная часть, VV> а юзеровский интерфейс и коммуникационные протоколы. Их на PC не особо VV> отладишь. Связь у меня всего одна, давно вылизана. В случае UI два варианта. Собсно низкий уровень (ввод и вывод чисел, месаг, драйвер клавы, драйвер дисплея, нижний уровень стека протокролов связи) идет отдельной либой и отвязывает все остальное от железа. Дальше средний уровень - поддержка диалогов, скрипты для хода по менюхам, скрипты для отрисовки аварий, для горячих кнопок, для уставок, и всякая подобная хрень - тоже идут отдельной либой. Либы никак не завязаны на конкретное изделие, скорей на тип хоста, поэтому ежели туда вносятся изменения, то отладить можно довольно быстро. А верхний уровень UI тоже двух видов. Либо это всевозможные уставки, диалоги - тоесть то что живет на указаных либах и очень простое по сути и отлаживается в лет. Либо это логика работы изделия - тоесть соображаем, что в мы щас в таком режиме, что столькото каналов живет, юзверь нажал на такю кнопку, и надо сказать что этого нельзя, потому как то и то. а чтобы было можно, нужно то и то... Вот эта часть пишется на голом си, очень зависима от конкретного вида изделия и меня бесит. Прскольку надо руками прописать гору всяких условий и реакции на них. Потом на тестировании уже на стенде нужно загнать изделие во все мыслимые позы, что тоже занимает время, и делать это приходится не раз :( Вобщем пора сочинять очередной кодогенератор.

MZ>> итого за 2 года 1 день на поиски глюков компилятора. MZ>> Это не серьезно имхо.

VV> Потребовалось добавить какую-то мелкую фичу. Пересобираешь старый VV> проверенный проект новым компилером. А оно не работает. Приходится VV> доставать бубен и вспоминать, что и как устроено... Зачем бубен? Когда программер сдает работу, принимаются исходники, файл проекта, прошивка, инструкция для техников (куда и как шить), дока для программера (чем и как собирать). Hу и само собой в архивах хранятся все версии используемых средств разработок.

WBR, Michael.

Hi Jurgis,

Mon Jun 12 2006 11:56, Jurgis Armanavichius wrote to Vladimir Vassilevsky:

JA> Господи, да чего там разбираться-то?! Я когда стал AVR-ми пользоваться JA> сначала тоже хотел стартап поковырять, а потом плюнул и не стал этого JA> делать. Да и что такого нужно ковырять в стартапе? Инитить переменные JA> или чистить BSS? Так он все это превосходно сам делает. Дык это для игрушек вроде АВР. А попробуй c16x например. что висит на четырех CS, с какого адреса, какая длинна, надо ли включить вотчдог, какие задержки у внешней памяти, размер стека, размер юзер стека и тд. А в конце стартапа вызовется команда конца инициализации, и до следуюющего ресета основные веши уже не изменишь. А по большому счету c16x далеко не самый сложный камень.

WBR, Michael.

Sat Jun 10 2006 13:42, Pavel Grishin wrote to Jurgis Armanavichius:

PG> Уже в 512 EPROM и 64 SRAM бyдет ФОРТ кpyтится запpосто.

Примерчик не приведешь?

По моим представлениям Форту нужно несколько кило кода...

Пока, Алексей

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Vladimir Vassilevsky on Tue, 13 Jun 2006 02:31:02 +0400:

VV>> Потребовалось добавить какую-то мелкую фичу. Пересобираешь старый VV>> проверенный проект новым компилером. А оно не работает. Приходится VV>> доставать бубен и вспоминать, что и как устроено...

MZ> Зачем бубен? MZ> Когда программер сдает работу, принимаются исходники, файл проекта, MZ> прошивка, инструкция для техников (куда и как шить), дока для MZ> программера (чем и как собирать). Hу и само собой в архивах хранятся MZ> все версии используемых средств разработок.

Вот с последним часто бывают бооольшие проблемы. Если это простая command-line утилита, это еще ничего. А если какой-то навороченный программный комплекс с инсталляцией, защитой от копирования, зависящий от каких-то ключей реестра, от каких-то переменных окружения и еще бог знает от чего, все куда хуже.

dima

Здравствуй, George Shepelev! июня месяца десятого дня ты писал(а):

GS> В реальной жизни работа над проектом отнюдь не заканчивается в момент GS> реализации ТЗ. Сразу начинается стадия сопровождения, когда может GS> потребоваться ликвидация "неточностей реализации" (некоторые из них GS> могли быть заложены даже в самом ТЗ). При этом далеко не факт, что не GS> потребуется "расширять" код в контроллере.

Так запас, как известно, карман не тянет - выбери контроллер немного "на вырост" и будет тебе счастье. Кстати, у С в этом случае есть определенное преимущество - некоторое дополнительное место можно изыскать, "вручную" оптимизируя наиболее "рыхлые" места, а в случае асма может случиться описанная когда-то здесь "история одного байта".

GS> А часто приходится модернизировать изделие, существенно увеличивая GS> функциональность. И вот тут на первый план выйдет вопрос, влезет всё GS> это в контроллеры, которые доступны на рынке, или придётся GS> перепроектировать всё изделие под совершенно другой контроллер. Разницу GS> в цене этих двух вариантов улавливаешь?

Чем наиболее примечательны PICи, так это возможностью практически всегда подобрать более "ресурсовый" кристалл, при полной совместимости по ногам, а если роялит именно цена, то заказчик заранее уведомляется об ограниченности дальнейшей расширяемости.

Резюме: я не спорю, что на асме выходит более компактный код (я сам лет 10 на асмах писал), просто на ЯВУ писать быстрее, результат более переносим (не так давно переводил один проект с PIC16 на PIC18 - нескольких часов хватило), и разобраться в коде сбособно гораздо большее число людей.

С уважением, Игорь Хавторин (ака Gary). E-mail: fido_gary собака gfm точка ru