Hадежный контроллер нужен........

for(int i = 0; i < N; i++)

----^^^^ a[i] = 0; int i = 5; ^^^

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

Hello, Sergey Davydov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 06 Aug

2006 23:12:58 +0400:

DO>>>> Да видеть-то можно что угодно, а ноpмальной документации, как и DO>>>> ноpмальной готовой сpеды pазpаботки в gcc как не было, так и нет. SD>>> Hе, я с вас худею, мужики. В gcc не то что "ноpмальной" или SD>>> "готовой" сpеды pазpаботки нет - в ней нет ее по опеpеделению. SD>>> Мало

DO>> Я не знаю таких опpеделений. Кто-то же собиpает это все до кучи,

SD> Собиpает. Пpимеp я пpивел в поскипаном тобой.

DO>> почему делать полдела?

SD> Вот ты, напpимеp, беpешь готовый контpоллеp, дpугие "детальки" и SD> собиpаешь свое изделие. Так почему же ты пол-дела делаешь и не SD> pазpабатываешь и не пpоизводишь собственные pезистоpы :)

Неправильная аналогия. Получается, что все время сравнивается готовая система с набором деталей для нее. Происходит это потому, что одни собранную обычно самостоятельно (или хотя бы им понятно как) из этих деталей систему все равно называют этими деталями, что связано с тем, что масштаб работы по этой сборке несопоставимо меньше масштаба работ по созданию деталей. Другие, те, что пользуются другими, обычно не ими самими собранными готовыми системами в них не видят деталей, из которых они собраны (знают, что где-то внутри они есть, но это и все), а в наборе деталей они видят лишь набор деталей, которые каким-то малопонятным образом нужно во что-то, что они с трудом себе представляют собрать и как-то заставить работать. Наборы деталей хороши для тех, кто профессионально или в силу личного интереса связан с подобной сборкой и представляет что он хочет получить и как ему этого достичь. Готовые системы хороши для остальных. Будучи иногда в первой, но все же чаще во второй группе, я предпочту готовое профессиональное решение самоделке, пусть и из очень хороших, вручную подогнанных деталей, но требующей высокой квалификации пользователя и не прощающее ошибок. Иными словами, я препочитаю надежный серийный автомобиль со всеми положенными системами безопасности спортивному снаряду, способному сделать меня со светофора и впердолиться в разделительную стенку у следующей развязки из-за ненужной и мешающей настоящим профессионалам системы стабилизации. В конце концов я не гонщик, у меня другая профессия.

dima

Привет Anatoly!

06 Авг 06 года (а было тогда 20:53) Anatoly Mashanov в своем письме к Dmitry Orlov писал:

AM> И в результате получаются чудовищные тормоза, избавиться от которых AM> можно с помощью нормальной реализации управления потоком, вывалив на AM> устройство все команды сразу и отсчитав на приеме нужное к-во ОК.

А какой в этом усложнении смысл в таком простом девайсе ? Что по очереди, что все вместе "Ok", все равно ждать. И в сложном устройстве, пачкой команды можно отправлять только до того момента, когда следующая команда будет зависеть от ответа "Ok" или "Error".

С уважением, Andrey 07 Авг 06 года

E-Mail:a_biv<саба>list,ru Jabber:Andrey_B@jabber,ru |СQ:226793191

Hello Arcady.

07 Aug 06 03:27, you wrote to Dmitry Orlov:

Поcмотрел скопом, tup/tdown =1/6 на 8МГц tiny45. Nicolas

AS>

AS> for(int i = 0; i < N; i++) AS> ----^^^^ AS> a[i] = 0; AS> int i = 5; AS> ^^^ кстати в стандарте C99 такой код уже можно писать, так что gcc должен его компилировать, не знаю как IAR

Hello, Anatoly Mashanov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 06 Aug

2006 19:53:52 +0400:

DEO>>> TON=20<CR>TOFF=30<CR>

DO>> Дело в том, что устройство на каждый принятый байт отдает эхо, а DO>> введенную (и исполненную) команду подтверждает выдачей "OK\n". DO>> Потому человек или другая программа должны не слать все подряд не DO>> глядя, а ждать правильной реакции. Если ожидание превысит некий DO>> таймаут - начинать с начала.

AM> И в результате получаются чудовищные тормоза, избавиться от которых

Окстись, какие тормоза? Ты решаемую задачу еще помнишь? Это делается для прежде всего ручного ввода пары чисел. Кому нужна эта скорость?

AM> можно с помощью нормальной реализации управления потоком, вывалив на AM> устройство все команды сразу и отсчитав на приеме нужное к-во ОК.

И что делать, когда потеряется или исказится символ где-то в начале этой бессмысленной операции?

DEO>>> то что "все работает" связано лишь с имеющимися паузами между DEO>>> подачей команд.

DO>> Которую должен обеспечить или оператор или программа, если DO>> устройство связано с другим устройством.

AM> У меня в одном дивайсе имеется буфер на 8 байт. Соответственно, AM> команды терминалка выдает с паузами после каждых нескольких байт, но AM> HЕ анализирует никаких ОК (Состояние будет прочитано в конце всей

А у меня команды выдает человек, и анализирует их по мере выдачи. Для межпрограммного взаимодействия разумней делать передачу защищенных чексуммами и таймингом пакетов, а не символов.

AM> серии команд). В другом дивайсе сделано проще: поскольку дивайс

Возможно в твоей задаче это и оправдано, тут - ничего не дает. Впрочем, предложение тоже самое. Сделай и покажи как работает.

dima

DT> Значит, надо говорить "основная программа", "процедуры/функции", "прерывания". DT>

DT> Кто-то из классиков программирования сказал, что программист должен прежде DT> всего в совершенстве владеть своим родным языком... думаю, это справедливо DT> и DT> для любой другой научной или инженерной дисциплины. терминология со временем просто меняется. когда я учился программировать (~86 год), у процессоров прерывания располагались в конце адресного пространства, на рисунке это выглядело так

+------------+ FFFF адрес | | | | | прерывания | | | +------------+ | | | | +------------+ 0000 адрес

и потому в литературе говорилось "прерывания расположены в верхней области, основная программа в нижней" или упрощенно "вверху и внизу".

вот с тех пор и не могу отвыкнуть. PS: из за того что прерывания располагались в верхней области, у тогдашних устройств RAM делался с нулевых адресов, а ROM располагался в конце. иногда все пространство не заполнялось никакой памятью :)

DEO>>> TON=20<CR>TOFF=30<CR>

AM>

DO>> Дело в том, что устройство на каждый принятый байт отдает эхо, а DO>> введенную (и исполненную) команду подтверждает выдачей "OK\n". Потому DO>> человек или другая программа должны не слать все подряд не глядя, а DO>> ждать правильной реакции. Если ожидание превысит некий таймаут - DO>> начинать с начала. AM> И в результате получаются чудовищные тормоза, избавиться от которых можно с AM> помощью нормальной реализации управления потоком, вывалив на устройство все AM> команды сразу и отсчитав на приеме нужное к-во ОК. там всего-то нормализовать менеджер процессов в функции main - убрать тупые циклы ожидания и система сможет начать работать асинхронно: прием сам по себе передача сама по себе :)

DEO>>> то что "все работает" связано лишь с имеющимися паузами между DEO>>> подачей команд. DO>> Которую должен обеспечить или оператор или программа, если устройство DO>> связано с другим устройством. AM> У меня в одном дивайсе имеется буфер на 8 байт. Соответственно, команды AM> терминалка выдает с паузами после каждых нескольких байт, но HЕ анализирует AM> никаких ОК (Состояние будет прочитано в конце всей серии команд). буфер разумеется должен быть, но коль процессор у него озадачивается выполнением длительных команд (например когда он передает он ни на что не реагирует, когда он переводит числа в строки и строки в числа опять в таком же состоянии, когда он тупо ждет когда доработает АЦП, работающее насколько я понял на 62Кгц, то есть частота преобразования ~ 6кГц - опять сравнимо с тактом, он опять же ни на что не реагирует.

DO тут кричит что мол ему фиолетово что сколько работает, что если понадобится он сюда весь math.h притащит, а я говорю что math.h сюда тащить не надо, потому что уже сейчас проблемы с потерей данных имеются.

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

Hello, Arcady Schekochikhin! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 6 Aug 2006 23:27:52

+0000 (UTC):

AS> Кстати - какая шинрина импульса на семистор получается максимальная AS> (сколько времени занимает прерывание)?

Около половины периода прерываний.

AS> Какой там запас остался для фоновой задачи?

Соответственно порядка 50%, хотя хватило бы и 5%, но это требует уже чрезмерно аккуратного программирования всего.

dima

AM>> И в результате получаются чудовищные тормоза, избавиться от которых DO>

DO> Окстись, какие тормоза? Ты решаемую задачу еще помнишь? Это делается для DO> прежде всего ручного ввода пары чисел. Кому нужна эта скорость? DO>

это задача на AN и делать ее надо правильно

AM>> можно с помощью нормальной реализации управления потоком, вывалив на AM>> устройство все команды сразу и отсчитав на приеме нужное к-во ОК. DO>

DO> И что делать, когда потеряется или исказится символ где-то в начале этой DO> бессмысленной операции? DO>

сбросили кучу данных, потом запросили статус :)

AM>> И в результате получаются чудовищные тормоза, избавиться от которых AM>> можно с помощью нормальной реализации управления потоком, вывалив на AM>> устройство все команды сразу и отсчитав на приеме нужное к-во ОК. AB>

AB> А какой в этом усложнении смысл в таком простом девайсе ? AB> Что по очереди, что все вместе "Ok", все равно ждать. AB> И в сложном устройстве, пачкой команды можно отправлять только AB> до того момента, когда следующая команда будет зависеть от ответа AB> "Ok" или "Error". во первых нормализация менеджера процессов в основной программе не даст усложнения (а возможно наоборот) во вторых суть данного девайса - AN на выходе.

То есть 4800 _может быть_ еще можно вытянуть и на твоей программе? Правда если пойдет прием совместно с передачей то возможно что и не сработает.

Hello, Arcady! You wrote to Alexander Terlyanskii on Sun, 6 Aug 2006 23:30:22 +0000 (UTC):

AS> for(int i = 0; i < N; i++) AS> ----^^^^ AS> a[i] = 0; AS> int i = 5; AS> ^^^

C99

WBR, AVB

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

Hello, Arcady Schekochikhin! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 7 Aug 2006 05:15:06

+0000 (UTC):

AS>>> Кстати - какая шинрина импульса на семистор получается AS>>> максимальная (сколько времени занимает прерывание)?

AS>>> Какой там запас остался для фоновой задачи?

AS> То есть 4800 _может быть_ еще можно вытянуть и на твоей программе?

Да, где-то на грани. Наверное можно, просто не нужно. Вот если скажем применение AVR на той же программе (ну с учетом аппаратных отличий) позволит ничего не делая получить 4800 - это уже аргумент в пользу их реального большего быстродействия. Причем реальный аргумент, в отличие от частоты махания ножкой.

dima

Hi Dmitry!

06 Aug 06 21:19, Dmitry Orlov wrote to Slav Matveev:

SM>> а что ты называешь "средой" ? возможность менять параметры SM>> компиляции-линковки путем выбора опций ветвистого меню?

DO> Менять параметры всего проекта и составных частей IDE согласовано, DO> интерактивно и с по-возможности осмысленными подсказками.

Килобайты текстового файла, куда уж более осмысленно?

SM>> А если эти параметры будут внутри текстового файла с SM>> комметариями, это сразу перестанет быть "средой"?

DO> Да, мало ли куда денутся или перепутаются комментарии из текстового DO> файла. Удобно, когда такой файл генерируется из гуевой программы DO> автоматически.

чем удобно? что шаг вправо, шаг влево - побег, прыжок на месте - провокация.

SM>> лет 20 назад в редакторе микромир, который ты наверняка SM>> "знать не знаю и знать не желаю",

DO> Hе знаю и не жалаю знать убийственная аргументация. "я этого не знаю, я этого не умею, поэтому это - говно".

SM>> раза <send> строчкой ниже и запустить на выполнение собраный SM>> проект, это нельзя считать "средой разработки"?

DO> А один раз нажать F9 и для того и для другого не будет удобней?

f9 на клавиатуре отсутствовало.

SM>> какая принципиальная разница между "монолитным" IDE, и SM>> той же функциональность, только набранной отдельными утилитами?

DO> Такая же, как между телевизором и жменей радиодеталей.

походу дела "пастернака не читал..." ?

Slav.

Hello Arcady.

Sun Aug 06 2006 00:41, Arcady Schekochikhin wrote to me:

AS> Да и не только - пять раз подумаешь и о том какие типы данных AS> использовать и прочее что на микро слишком дорого выходит.

Угу. Причём на 8-битке один подход будет оптимальным, а на 16-битке - другой.

AS> Оно возможно останется портабельным - но только снизу вверх.

Какие-то "вычислительные" или "протокольные" модули/функции...

AS> Hу и естественно любое использование периферии делает программу почти AS> не портабельной.

Именно. Hет, говорить о портабельности в случае МК смысла не имеет.

Dimmy.

Да? А если так нарисовать:

+---------+ 0000 адрес | | прерывания --------- | | +---------+ FFFF адрес

Где теперь прерывания? Опять сверху? Если у нас Z80 (как раз уровень 1986 года). Или всё-таки снизу? Или пусть вместо Z80 будет x51 или AVR -- без разницы.

KF> С другой стороны -- если говорить про libc, это касается только PC KF> версии. avr-libc тоже все по стандарту реализовано, только конечно реализовано не все. :)

KF>

KF> Меня на самом деле мучает другой вопрос. Как в большинстве этих сред KF> притащить исходник на другую машину, или просто хотя бы checkout другую KF> версию в более другой каталог -- потом файл проекта ручками же править, KF> для избавления от абсолютных путей, и так каждый раз. :-( KF> По-моему это очень актуальная проблема и мне даже удивительно, что KF> никого этот факт, вроде бы, не беспокоит. :-/ гылол меня этот факт не беспокоит т.к. я всякими IDE и не пользуюсь :)

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

Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Anatoly Mashanov on Mon, 07 Aug

2006 09:05:09 +0400:

DEO>>>> TON=20<CR>TOFF=30<CR>

DO>>> Дело в том, что устройство на каждый принятый байт отдает эхо, а DO>>> введенную (и исполненную) команду подтверждает выдачей "OK\n". DO>>> Потому человек или другая программа должны не слать все подряд не DO>>> глядя, а ждать правильной реакции. Если ожидание превысит некий DO>>> таймаут - начинать с начала. AM>> И в результате получаются чудовищные тормоза, избавиться от которых AM>> можно с помощью нормальной реализации управления потоком, вывалив AM>> на устройство все команды сразу и отсчитав на приеме нужное к-во AM>> ОК.

DEO> там всего-то нормализовать менеджер процессов в функции main - DEO> убрать тупые циклы ожидания и система сможет начать работать DEO> асинхронно: прием сам по себе передача сама по себе :)

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

DEO>>>> то что "все работает" связано лишь с имеющимися паузами между DEO>>>> подачей команд.

DO>>> Которую должен обеспечить или оператор или программа, если DO>>> устройство связано с другим устройством.

AM>> У меня в одном дивайсе имеется буфер на 8 байт. Соответственно, AM>> команды терминалка выдает с паузами после каждых нескольких байт, AM>> но HЕ анализирует никаких ОК (Состояние будет прочитано в конце AM>> всей серии команд).

DEO> буфер разумеется должен быть, но коль процессор у него DEO> озадачивается выполнением длительных команд (например когда он DEO> передает он ни на что не реагирует, когда он переводит числа в

Ну прием-то в буфер работает. Иначе программа вообще на ввод бы не реагировала.

DEO> строки и строки в числа опять в таком же состоянии, когда он тупо DEO> ждет когда доработает АЦП, работающее насколько я понял на 62Кгц, DEO> то есть частота преобразования ~ 6кГц - DEO> опять сравнимо с тактом, он опять же ни на что не реагирует.

DEO> DO тут кричит что мол ему фиолетово что сколько работает, что если

Именно. И такая архитектура программы именно для этого и делалась.

DEO> понадобится он сюда весь math.h притащит, а я говорю что math.h

Именно. И если от подачи команды до получения ее результата нужно будет полчаса ждать, значит столько и нужно ждать.

DEO> сюда тащить не надо, потому что уже сейчас проблемы с потерей DEO> данных имеются.

Выдуманные тобой, не более того.

dima