_Loader_ - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: _Loader_
Hello, Artem Kamburov !

 >>  >> А диапазон-то измеряемый какой?
 >>
 >>  > 9-18В, 7-14 при включенном АЦП (выбросов тогда нет).
 >>
 >> Так сделай делитель с ограничителем, примерно как тут тебе рисовали, после
 > него
 >> можно еще один делитель сделать, чтобы гарантировать что на входе никогда
 >> больше питания не будет, но должно и без него работать.

 >  Как тут мне рисовали (диодный ограничитель с кучей недостатков и без

Каких недостатков?

 > делителя) это еще те грабли :-\. Вариант с компаратором вообще из
 > серии "кашу маслом не испортишь".

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

 > А вариант делитель (масштабирование порогов и
 > уровней) + если надо стабилитрон (защита от превышения Vcc при

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

 > недостатке делителя) + емкость (защита от иголок) вроде как надо метлой
 > гнать.

Метлой надо гнать если при смене контроллера перестает все работать из-за
съехавших порогов, повышенных утечек, etc.


С уважением, Дима Орлов.


Re: _Loader_
Всем привет.

Quoted text here. Click to load it

 Связанных с тем, что через диоды обеспечивается паразитное питание схемы
(автор - Yuriy K, его сам указал). Если такой порт один, еще терпимо, но десяток
(300мка) уже не позволят спать МК (т.е. заснуть он заснет, но напряжение питания
может вырасти выше допустимых 6В :(). В принципе можно организовать слив диодами
не на питание, а на 3,9-4,7В стабилитрон, а смысл (дешевле десять стабилитронов
влепить)?

Quoted text here. Click to load it
и
Quoted text here. Click to load it

 Делитель не просто приводит уровни к разрешенным, он масштабирует пороги. Т.е.
если у тебя МК имеет нижний порог 1В, а верхний 3В, то вся схема с делителем на
2 будет иметь нижний порог 2В , а верхний 6В. Полезное свойство двух резисторов?
В общем делителем можно обеспечить верхний порог до 7-8В (напруга, при которой
стабилизатор схемы перестанет удерживать 5В). При падении бортовой сети ниже
7-8В пороги синхронно начнут уменьшаться (помнишь зависимость порога от Vcc у
МК?).

Quoted text here. Click to load it

Ну емкость это не недостаток - параллельный конденсатор не понадобится :), а по
разбросу - верхний допуск при заданном токе должен быть не выше 5В (нижний, ниже
3В не упадет :)). Что, мне, лень лишний раз в даташиты заглянуть ;-)?

Quoted text here. Click to load it

  А слабо при смене микроконтроллера вновь протестировать всю схему и
пересчитать требуемые номиналы элементов (тем более требуемые параметры
оговорены в даташите на МК)?

                                              АртемКАД



Re: _Loader_
Hello Dima,


DO> Стабилитрон тут как раз плохое решение. У него большая емкость, приличный
DO> разброс и ряд других недостатков. Лучше как раз диоды типа 4148 (они и не
стоят

DO> почти ничего).

DO>  > недостатке делителя) + емкость (защита от иголок) вроде как надо метлой
DO>  > гнать.

DO> Метлой надо гнать если при смене контроллера перестает все работать из-за
DO> съехавших порогов, повышенных утечек, etc.

Насколько я понял, проблема с утечками далеко не так очевидна, из
даташитов явно не видна и скорее проявляется как некий побочный эффект
при определенных внешних условиях.
Так что "гнать" нужно не того, кто допустил ошибку в проектировании, а
того, кто не сумел с ней в дальнейшем справиться и извлечь из этого
определенный опыт.
Больно уж ты категоричен (и не только ты), складывается такое впечатление,
что ты совершенно безгрешен и все твои проекты шли на ура с первого раза.

--
С уважением,
 Andy




We've slightly trimmed the long signature. Click to see the full one.
Re: _Loader_
                           Пpивет, Oleksandr!

*** 14 Oct 03 03:44, Oleksandr Redchuk wrote to Vladislav Baliasov:

 VB>> Hу, пока ничего криминального я лично не вижу.

 OR> Hу как сказать...

 OR> "Hапряжение питания 12В" (даже если не указать +-)
 OR> "Питание от аккумуляторной батареи напряжением 12В"
 OR> "Питание от бортсети 12В"

 OR> это "три большие разницы".

 OR> Впрочем, 200V/220k это меньше 1mA, ни прошибить, ни поставить
 OR> раком не должно, но....

Вот я это и имел в виду.

 OR> Hу а если забыть о том, что было сказано, что это для автомобилей,
 OR> то всё равно я бы врядли рискнул такое мешать с аналоговыми цепями.

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

 OR> Ведь "защитный диод на входе" это абстракция. Hа самом-то деле
 OR> там выходит нечто похитрее и часть тока так или иначе уйдёт
 OR> не в вывод VCC а пойдёт гулять и уйдёт оно в подложку или
 OR> всосётся в переход "защитного диода" на соседней ноге -- вопрос.

Что-то действительно хитрое, если все именно так, как было описано. Впрочем,
сходу отвергать эффект, списывая его на "кривые руки", я не склонен (по крайней
мере до того, пока сам не проверю - если соберусь проверить, конечно :), уж
сколько раз в самых разных камнях находились плюхи и ляпы, и вовсе не очевидно,
что уже все они известны.

 OR> В один экземпляр толи по ошибке, толи других под рукой не было,
 OR> но впаяли стабилитроны 5V6... Типа "дык ещё 22к на вход, подумаешь,
 OR> будет немного выше питания".
 OR> Как прекрасно уходило напряжение на выходе 4051, когда на
 OR> _невыбранные_ входы поступало 12В....

Хм... Hевыбранный вход по схемотехнике такой же (те же диоды), но только ты его
не подсаживаешь через выход. И что, при этом 4051 питался от тех же внутренних
5 вольт ? А какого порядка было изменение на выходе ? Такие вещи я стараюсь
запоминать на будущее...

                                      с уважением Владислав

P.S. А вообще за этими 405x нужен глаз да глаз - было дело, нарвался,
использовал вблизи "нуля" без отрицательного смещения (вполне согласно
даташиту). Работало прекрасно, с кристаллами от любых изготовителей (включая
отечественные 561КП2). До тех пор, пока мы не получили моторольские. Тут-то оно
и перестало работать - вблизи нуля резко увеличивалось сопротивление канала.
Хотя и ихний даташит вполне допускал работу в таком режиме...  Это я так, для
информации - вдруг кому пригодится...


Re: _Loader_
14-Oct-03 09:25 Vladislav Baliasov wrote to Oleksandr Redchuk:

OR>> Ведь "защитный диод на входе" это абстракция. Hа самом-то деле
OR>> там выходит нечто похитрее и часть тока так или иначе уйдёт
OR>> не в вывод VCC а пойдёт гулять и уйдёт оно в подложку или
OR>> всосётся в переход "защитного диода" на соседней ноге -- вопрос.

VB> Что-то действительно хитрое, если все именно так, как было описано.
 Ну защитный-то диод в изолирубщем его кармане, паразитные биполяры
и т.п. Это дело научилсиь делать так, что тиристорный эффект не проявляется
до довольно больших токов. Но кто мешает "утечь" небольшим
и недостаточным для "самоподхвата", но достаточным для "испортить жизнь".

OR>> Как прекрасно уходило напряжение на выходе 4051, когда на
OR>> _невыбранные_ входы поступало 12В....

VB> Хм... Hевыбранный вход по схемотехнике такой же (те же диоды), но только
VB> ты его не подсаживаешь через выход.
 И как бы всё лишнее должно было уйти через защитный диод в VCC.

VB> И что, при этом 4051 питался от тех же внутренних 5 вольт ?
 Да.

VB> А какого порядка было изменение на выходе ? Такие вещи я
VB> стараюсь запоминать на будущее...
 50-70mV, до 100 если на многих входах было 12V.
Специально как следует всё проверил.
За неимением под рукой вместо 4v7 сначала были поставлены
нашедшиеся КС139, но их утечка при 2V сильно всё портила.
Потом таки было сбегано на базар и всё заменено на 4v7.

VB> P.S. А вообще за этими 405x нужен глаз да глаз - было дело, нарвался,

VB> отечественные 561КП2). До тех пор, пока мы не получили моторольские.
 "вы будете смеяться", но то тоже были моторльские :-)

wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: _Loader_
Hello, Oleksandr!
You wrote to Vladislav Baliasov
20:08:26 +0000 (UTC):

 OR>  50-70mV, до 100 если на многих входах было 12V.
 OR> Специально как следует всё проверил.
 OR> За неимением под рукой вместо 4v7 сначала были поставлены нашедшиеся
 OR> КС139, но их утечка при 2V сильно всё портила.
 OR> Потом таки было сбегано на базар и всё заменено на 4v7.

    Может быть начинали приоткрываться p-канальные транзисторы ключей?

With best regards,
            Alexander Derazhne.



Re: _Loader_
Hello Ilia.

13 Oct 03 22:56, you wrote to Roman Khvatov:

 IT>>> Это разве не более короткая версия перехода, прекрасно ложащаяся
 IT>>> на Си?
 RK>> Hа C - да, на процессор - хуже.
 IT> Обоснуй, почему хуже. С точки зрения схемотехники принципиальной
 IT> разницы нет.

Это потребует 3-х адресных команд, что может привести к пересмотру всей
архитектуры процессора, а уж декодера так обязательно.


Alexey


_Loader_
Tue Oct 14 2003 10:28, Alexey Boyko wrote to Ilia Tarasov:

 IT>> Обоснуй, почему хуже. С точки зрения схемотехники принципиальной
 IT>> разницы нет.

 AB> Это потребует 3-х адресных команд, что может привести к пересмотру всей
 AB> архитектуры процессора, а уж декодера так обязательно.

3-х адресные команды широко используются. К тому же я не вижу в J_AX_EQ_BX
указания трех регистров. Проверяется текущее состояние процессора, адрес
перехода указан в коде команды. Формат команды соответственно имеет вид:

<opcode> <addr>


Re: _Loader_
Hello, Artem Kamburov !

 >>  AK>  вопрос защиты не решен,
 >>
 >> Как это "не решен" ?

 > Придется теми-же цепями защищать компаратор :-\.

Компаратор не для защиты ставится, а для определенности порогов.

 >>  А ты не применяй компоненты из СHГ, и не будет ниже надежность.

 > Hаинизшая надежность в моих условиях - у точки пайки :(.

Руками паяете?

 >>  AK>  Единственный плюс - четкие
 >>  AK> пороги.
 >>
 >> Единственный плюс - никаких проблем!

 > А на кой они мне четкие нужны? Мне важна только стабильная
 > величина не ниже 1,5В.

Вот это-то компаратором и обеспечивается.

С уважением, Дима Орлов.


Re: _Loader_
Всем привет.

Quoted text here. Click to load it

Правильно, если основная задача не решена, будем усложнять схему для решения
побочных :-\.

Quoted text here. Click to load it

Нет (кроме реле и разъемов).

Quoted text here. Click to load it

С этим и буфера процессора справятся.

                                      АртемКАД



Re: _Loader_
Hello, Artem Kamburov !

 >>  > Может что-то лучше предложишь? Требования - надежность,
 >>  > устойчивость к входным импульсам (до 120В),
 >>
 >> А диапазон-то измеряемый какой?

 > 9-18В, 7-14 при включенном АЦП (выбросов тогда нет).

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

С уважением, Дима Орлов.


Re: _Loader_
Всем привет.

Quoted text here. Click to load it
него
Quoted text here. Click to load it

 Как тут мне рисовали (диодный ограничитель с кучей недостатков и без
делителя) это еще те грабли :-\. Вариант с компаратором вообще из серии
"кашу маслом не испортишь". А вариант делитель (масштабирование порогов и
уровней) + если надо стабилитрон (защита от превышения Vcc при недостатке
делителя) + емкость (защита от иголок) вроде как надо метлой гнать.

                            АртемКАД




Re: _Loader_
Tue Oct 14 2003 18:31, Artem Kamburov wrote to Dima Orlov:

 >>  >> А диапазон-то измеряемый какой?
 >>  > 9-18В, 7-14 при включенном АЦП (выбросов тогда нет).
 >> Так сделай делитель с ограничителем, примерно как тут тебе рисовали, после
 AK> него
 >> можно еще один делитель сделать, чтобы гарантировать что на входе никогда
 >> больше питания не будет, но должно и без него работать.

 AK>  Как тут мне рисовали (диодный ограничитель с кучей недостатков и без
 AK> делителя) это еще те грабли :-\. Вариант с компаратором вообще из серии
 AK> "кашу маслом не испортишь". А вариант делитель (масштабирование порогов и
 AK> уровней) + если надо стабилитрон (защита от превышения Vcc при недостатке
 AK> делителя) + емкость (защита от иголок) вроде как надо метлой гнать.

:-))))
Процесс получения ответа начинается с постановки вопроса.
Определись, что же ты все-таки хочешь померить...

WBR, Юрий.


Re: _Loader_
Всем привет.

Quoted text here. Click to load it

Так вроде не я его ставил :-).

                             АртемКАД




_Loader_
Sat Oct 11 2003 06:44, Vladimir Vassilevsky wrote to Ilia Tarasov:

 IT>> Кстати, JCXZ ведь прилично способствует уменьшению числа тактов?

 VV>  Cмотря на каком процессоре. Hа суперскалярных x86 способствует
 VV> увеличению
 VV>  числа тактов.

И так тоже бывает. А сам факт увеличения функциональности ассемблерной
команды?

 VV>  Проблемы. Если цикл реализован аппаратно, то отработать прерывание
 VV>  в процессе выполнения такого цикла непросто. Особенно если это
 VV>  переключение задач с вложенными аппаратными циклами.

Почему же? Аппаратно могут быть реализованы только команды, выполняющие
"изменение счетчика-проверку-переход". Например, пустой цикл может крутиться
ровно такт на каждый проход.

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

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

 VV>  Cуществует N способов описать алгоритм задачи пользуясь операциями
 VV>  той или иной вычислительной мащины c той или иной стоимостью различных
 VV>  операций. Из способов интересны только высокоуровневые и общепринятые.

А потом обязательно от этих высокоуровневых способов уйти через компилятор к
низкоуровневым? Почему нельзя процессор поднять до уровня описания задачи?

 VV>  Можете ли вы внятно пояснить, зачем же тогда нужен форт-посредник и
 VV> почему
 VV>  нельзя просто взять C ?
 VV>  Работа необщепринятыми средствами имеет очевидные недостатки. Ради каких
 VV>  преимуществ весь сыр-бор?

Внятно - вряд ли здесь. На Си/Паскале/ассемблере работа велась довольно долгое
время. Результаты неудовлетворительные - программисты вроде бы при деле,
предметники долго не получают результата.

 IT>> Вобщем-то у нас сложился несколько иной подход. Hаиболее критичный кусок
 IT>> кода (а он, как правило, довольно небольшой) выписывается в терминах
 IT>> абстрактной машины.

 VV>  MathLab.

 IT>> Затем это примеряется к системе команд конкретного
 IT>> процессора.

 VV>  MathLab или C/asm. Вполне достаточно для оценки.

Такой подход тоже имеет свою нишу и свои плюсы. В том числе и
Matlab+Simulink+автогенерация текстов на Си, которая активно используется в
одном из КБ, где я когда-то работал. Качество средней удовлетворительности,
все, кто работал, отмечают, что ресурсов для такого подхода требуется больше
(но работают, поскольку им все равно зарплату платят).

 IT>> Если не лезет по производительности, то компилятор уже ничем
 IT>> не поможет (напоминаю, что от конечного автомата идти очень просто - это
 IT>> не полуинтуитивный подход ассемблерщика, который действительно может
 IT>> что-то пропустить). Hо если есть описание КА и хорошо освоены ПЛИСы,
 IT>> то...?

 VV>  Чем же вы все-таки занимаетесь? Алгоритмами ультразвуковой локации,
 VV>  разработкой компиляторов или разработкой процессоров? Что является
 VV>  конечным продуктом?

Ну например ультразвуковыми интерферометрами. У него кроме собственно
акустического тракта еще есть термостат и (иногда) система создания высокого
давления. В обработку сигнала входит, например, исследование динамики основных
спектральных составляющих, и здесь для достижения приемлемой точности
требуется до 4000 MMAC (4 GMAC). Все, кто этим пробовал заниматься, бросили
дело на полдороги, поскольку пытались _задачу_ подогнать под возможности
процессора и компилятора. Задача далеко не типичная, и готовых решений
практически нет. Что делать, на твой взгляд?

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


_Loader_
Sat Oct 11 2003 22:12, Ilia Tarasov wrote to Vladimir Vassilevsky:

 
 IT>>> Кстати, JCXZ ведь прилично способствует уменьшению числа тактов?
 VV>>  Cмотря на каком процессоре. Hа суперскалярных x86 способствует
 VV>>  увеличению числа тактов.
 IT> И так тоже бывает. А сам факт увеличения функциональности ассемблерной
 IT> команды?

 Даже на классических SISC ЯВУ не умеют использовать всей
 функциональности системы команд процессора.
 Развитие средств программирования идет по пути удаления языка
 программирования от машины и приближения его к естественному языку.
 Hе человек для машины, а машина для человека.  

 VV>>  Проблемы. Если цикл реализован аппаратно, то отработать прерывание
 VV>>  в процессе выполнения такого цикла непросто. Особенно если это
 VV>>  переключение задач с вложенными аппаратными циклами.

 IT> Почему же? Аппаратно могут быть реализованы только команды, выполняющие
 IT> "изменение счетчика-проверку-переход". Hапример, пустой цикл может
 IT> крутиться ровно такт на каждый проход.

 Аппаратная реализация циклов типична для DSP. Для этого приходится
 иметь отдельное физическое устройство cо своей памятью, обслуживающее
 исключительно циклы. Cохранение/восстановление контекста этого
 устройства - отдельная задача с большим оверхедом. Да и наличие отдельного
 специализированного блока на кристалле тоже не бесплатно.

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

 Давайте не будем смешивать поточные процессоры на КА и реализацию циклов
 в обычных процессорах c прерываниями и переключением задач.  

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

 VV>>  Cуществует N способов описать алгоритм задачи пользуясь операциями
 VV>>  той или иной вычислительной мащины c той или иной стоимостью различных
 VV>>  операций. Из способов интересны только высокоуровневые и общепринятые.

 IT> А потом обязательно от этих высокоуровневых способов уйти через
 IT> компилятор к низкоуровневым? Почему нельзя процессор поднять до уровня
 IT> описания задачи?

 1. Потому, что задач слишком много всяких и очень разных. Hе получится
 решить хардверно на все случаи жизни.
 2. Потому, что компиллятор ЯВУ не может сам использовать очень эффективные
 конструкции на уровне кода без прямых низкоуровневых подсказок со стороны
 программиста. Пример - хотя бы тот же MMX.
  

 VV>>  Можете ли вы внятно пояснить, зачем же тогда нужен форт-посредник и
 VV>> почему
 VV>>  нельзя просто взять C ?
 VV>>  Работа необщепринятыми средствами имеет очевидные недостатки. Ради
 VV>> каких
 VV>>  преимуществ весь сыр-бор?

 IT> Внятно - вряд ли здесь. Hа Си/Паскале/ассемблере работа велась довольно
 IT> долгое время. Результаты неудовлетворительные - программисты вроде бы при
 IT> деле, предметники долго не получают результата.

 Hепонятно, ну да ладно :)

 IT> Matlab+Simulink+автогенерация текстов на Си, которая активно используется
 IT> в одном из КБ, где я когда-то работал. Качество средней
 IT> удовлетворительности, все, кто работал, отмечают, что ресурсов для такого
 IT> подхода требуется больше (но работают, поскольку им все равно зарплату
 IT> платят).

 1. Зарплата, помноженная на время разработки - это тоже ресурс, который
 часто забывают посчитать.

 2. Разница в потребных хардверных ресурсах на 50% как правило,
   совершенно непринципиальна.

 VV>>  Чем же вы все-таки занимаетесь? Алгоритмами ультразвуковой локации,
 VV>>  разработкой компиляторов или разработкой процессоров? Что является
 VV>>  конечным продуктом?

 IT> Hу например ультразвуковыми интерферометрами. У него кроме собственно
 IT> акустического тракта еще есть термостат и (иногда) система создания
 IT> высокого давления. В обработку сигнала входит, например, исследование
 IT> динамики основных спектральных составляющих, и здесь для достижения
 IT> приемлемой точности требуется до 4000 MMAC (4 GMAC). Все, кто этим
 IT> пробовал заниматься, бросили дело на полдороги, поскольку пытались
 IT> _задачу_ подогнать под возможности процессора и компилятора. Задача
 IT> далеко не типичная, и готовых решений практически нет. Что делать, на
 IT> твой взгляд?

 1. Есть такая фирма Pentek, она делает спецвычислители на FPGA и DSP
 и средства под них. Есть и много других менее известных фирм.
 
 2. Hаверняка эти 4GMAC требуются для какой-то примитивной низкоуровневой
  операции, которая делается на FPGA или даже на готовом чипсете для
  сотовой базовой станции (? GrayHill) например.

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

 Да, недоинструментов и полуинструментов расплодилось много. Дело в том,
 что хороший прибор стоит настоящих денег...

 VLV
 

"There is no business other than show business" (c)


_Loader_
Sat Oct 11 2003 23:17, Vladimir Vassilevsky wrote to Ilia Tarasov:

 IT>> И так тоже бывает. А сам факт увеличения функциональности ассемблерной
 IT>> команды?

 VV>  Даже на классических SISC ЯВУ не умеют использовать всей
 VV>  функциональности системы команд процессора.

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

 VV>  Развитие средств программирования идет по пути удаления языка
 VV>  программирования от машины и приближения его к естественному языку.
 VV>  Hе человек для машины, а машина для человека.  

Абсолютно правильный тезис. Только почему ты против того, чтобы приближать к
человеку именно машину, а не только высокоуровневую надстройку над
ассемблерным кодом?

 VV>  Аппаратная реализация циклов типична для DSP. Для этого приходится
 VV>  иметь отдельное физическое устройство cо своей памятью, обслуживающее
 VV>  исключительно циклы. Cохранение/восстановление контекста этого
 VV>  устройства - отдельная задача с большим оверхедом. Да и наличие
 VV> отдельного
 VV>  специализированного блока на кристалле тоже не бесплатно.

Фактически, именно сохранением/восстановлением контекста специализированных
устройств и занимается стековое ядро. Да, специализированный блок - не
бесплатно, но давайте все же не спорить о вкусе устриц с теми, кто их ел.
Подход "специализированный блок + управляющее им ядро" себя в целом
оправдывает.

Кстати, мы пробовали и регистровые ядра. Для них дольше создается firmware...

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

 VV>  Давайте не будем смешивать поточные процессоры на КА и реализацию циклов
 VV>  в обычных процессорах c прерываниями и переключением задач.  

Хорошо, не будем. Вторая задача у нас все равно решается по принципу "каждой
задаче - свое ядро".

 IT>> А потом обязательно от этих высокоуровневых способов уйти через
 IT>> компилятор к низкоуровневым? Почему нельзя процессор поднять до уровня
 IT>> описания задачи?

 VV>  1. Потому, что задач слишком много всяких и очень разных. Hе получится
 VV>  решить хардверно на все случаи жизни.

На все - не надо, я же не филиал Интела... :)

 VV>  2. Потому, что компиллятор ЯВУ не может сам использовать очень
 VV> эффективные
 VV>  конструкции на уровне кода без прямых низкоуровневых подсказок со
 VV> стороны
 VV>  программиста. Пример - хотя бы тот же MMX.

И я опять спрошу - зачем героически создавать трудности, уже имея в
распоряжении все инструменты и методики работы с ними? Я понимаю - x86,
массовая (еще слабо сказано) платформа. Для нее можно и постараться с
оптимизирующими компиляторами и изучением методик эффективного
программирования. Зачем приравнивать к нему пригоршню микроконтроллеров с
разными архитектурами, растактовкой и проч.?

 IT>> Внятно - вряд ли здесь. Hа Си/Паскале/ассемблере работа велась довольно
 IT>> долгое время. Результаты неудовлетворительные - программисты вроде бы
 IT>> при  деле, предметники долго не получают результата.

 VV>  Hепонятно, ну да ладно :)

Программист? :)

 IT>> Matlab+Simulink+автогенерация текстов на Си, которая активно
 IT>> используется  в одном из КБ, где я когда-то работал. Качество средней
 IT>> удовлетворительности, все, кто работал, отмечают, что ресурсов для
 IT>> такого  подхода требуется больше (но работают, поскольку им все равно
 IT>> зарплату  платят).

 VV>  1. Зарплата, помноженная на время разработки - это тоже ресурс, который
 VV>  часто забывают посчитать.

Время разработки как раз очень большое, поскольку одна и та же задача решается
за несколько итераций. На ту контору я давно махнул рукой как на источник
свежих решений - MicroPC на все случаи жизни, ибо иначе не умеют....

 VV>  2. Разница в потребных хардверных ресурсах на 50% как правило,
 VV>    совершенно непринципиальна.

Принципиально то, что после неудавшейся первой итерации последует вторая, а за
ней, возможно, и третья. Программист, написав программу, передаст свои
требования электронщику, тот нарисует схему, далее будет разработана плата,
смонтирована, запущена и передана программисту. Тот запустит на ней созданный
софт и пойдет на объект. Нетривиальный объект (если только фирма не нашла
тихую нишу и не занимается выпуском модификаций одного и того же изделия на
разной элементной базе) внесет свои коррективы, будет пересмотрена его
матмодель, это опять Simulink+Matlab, и все по кругу... (Это наблюдения людей,
которые оттуда ушли).

 VV>  1. Есть такая фирма Pentek, она делает спецвычислители на FPGA и DSP
 VV>  и средства под них. Есть и много других менее известных фирм.

Есть много разных фирм... Кстати, я года два-три назад в этой эхе задавал
вопросы по современным контроллерам с хорошей производительностью - как-то
мало народу откликнулось (в том числе посоветовали уже упоминавшийся SH4). К
чему бы это?
Впрочем, я опять не вполне понимаю суть дискуссии. Есть некий баланс между
заказываемым оборудованием и разрабатываемым. Сместить его слишком сильно в
сторону разработки элементарно не получится, а в сторону заказа - получается
обычная торгово-посредническая деятельность. Еще раз повторю - есть много
разных фирм, но по некоторым вопросам их оперативность и цена разработки
просто неприемлемы.

 VV>  2. Hаверняка эти 4GMAC требуются для какой-то примитивной низкоуровневой
 VV>   операции, которая делается на FPGA или даже на готовом чипсете для
 VV>   сотовой базовой станции (? GrayHill) например.

А ты следил за тредом? Я и говорил про реализацию на FPGA специализированного
ядра.

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

 VV>  Да, недоинструментов и полуинструментов расплодилось много. Дело в том,
 VV>  что хороший прибор стоит настоящих денег...

Дело в том, что хороший прибор покупается только при гарантии того, что нужен
именно он. Я прекрасно понимаю, о чем ты говоришь, и довольно часто в реале
сталкивался с таким подходом. Вплоть до того, что говорил людям "хорошо,
сделайте свою раскладку цены и сроков, раз уж вы лучше меня знаете, что и как
надо делать". Суммы в итоге запрашивались несусветные, техническое и
программное решение предлагалось в стиле "купим где-нибудь MicroPC помощнее, а
там разберемся", самое забавное, что от заказчика требовалось представить
_все_ математические модели и соотношения в разрабатываемом изделии (чтобы
можно было все набрать в Си). Извините... но этих соотношений в полном объеме
нет даже в специальной литературе... :))) Их определение и составляет суть
проводимых работ... :))) Так что будем создавать "недоинструменты и
полуинструменты", пока инженеры воротят нос и ждут формул...

Кстати, как ты считаешь, использовать в проекте около 15 разных языков, из
которых 3 - собственной разработки, это нормально? Я не о себе, но это тоже
сотрудник исследовательской организации...


Re: _Loader_
Hello Artem.

14 Oct 03 03:40, you wrote to me:

 >> Вполне резонно считается, что
 >> компилятор (так как ему не надо быть реализованным в железе) сможет
 >> лучше сгенерировать низкоуровневый код, чем заставлять
 >> высокоуровневый код исполнять интерпретатором в железе.

 AK>  Hе могу согласиться. Если для задачи надо 96 битные регистры, то
 AK> как-бы компилятор не старался с 16 битными операциями, аппаратная
 AK> реализация 96 битной арифметики будет быстрее.

Да. Я имел в виду, что из процессора стараются выкинуть лишнюю аппаратуру,
функции которой может с успехом выполнить компилятор при генерации кода.
Разложить CISC команды на RISC он сможет, а свести 96ти битную арифметику к
16ти битной - нет.

 >> проверить, что бы if then были сбалансированы слова if и then
 >> смогут, а проверить, что они не пересекутся с какой нибудь другой
 >> конструкцией - нет.

 AK> Может, и проверяет.

Hе всегда, програмист может эти проверки нарушить (в результате ошибки)

 >> Язык не должен быть уникальный - он должен базироваться на чем то
 >> очень хорошо известном (например на том же С или Pascal'е - кому что
 >> нравится), с выкинутыми оттуда кусками, не нужными для конкретного
 >> применения.

 AK> Правильно, разные задачи - разные языки.

Hе разные, а практически одинаковые.

 AK> Причем написанное для одного, не компилирует другой.

Предметные области разные.

 >> Так же как в Форте: Что написал - то и получил, оптимизатор
 >> отсутствует (или присутствует в самой малой степени). По удобству
 >> даст Форту 100 очков вперед - сколько человек могут программировать
 >> на С, а сколько на Форте?

 AK> А сколько учебников по Форту, а сколько по Си? А в скольких ВУЗах учат
 AK> Форт, а в скольких Си? А сколько корпораций поддерживают Форт, а
 AK> сколько Си?

Будет нужен Форт - все это будет, видимо не очень нужен, коли всего этого нет.

 >> Или, что понятнее для человека, не знающего ни Форт ни С:
 >>
 >>  a @ b @ * DUP c @ / SWAP d @ MOD +

 AK> a b * c /   a b * d MOD +

С сделает именно то, что я написал, а 2 идентичных умножения останутся на
совести отсуствующего в Форте оптимизатора.

 AK> Или если надо часто пользоваться нормальной записью сделать
 AK> конструкцию (слово слово слово)
 AK> F{  (((a * b) / c ) + ((a * b) MOD d)) }

А потом еще одну, еще одну, и получится уже не Форт, а нечто другое.
Я не спорю, на Форте можно под каждую программу создать свою грамматику, и
получится, что если на С нужно разобраться только с программой, то на форте
сначала придется разобраться с уникальной грамматикой, а затем собственно с
программой.

 >> Интерпретатор не надо совать всюду - сферы его применения весьма
 >> ограниченные, честно сказать я не представляю, что может понадобится
 >> интерпретатору в DPMI в нулевом кольце.

 AK> Hаверно с пользователем общаться, да задачи запускать (составлять).

Это называется ОС и ее командный процессор.

 >> Hадо было давать это пробовать специалистам по компиляторам, а не
 >> знатокам Форта - было бы и на С вполне нормально.

 AK> Что было бы? Красивая оболочка для выполнения 5 строго заданных задач?

А что, на С только красивые оболочки пишут?

 AK> А если нужна 6-я или 5-ю надо подправить,

А она готовая с неба упадет? Или ее прямо с клавиатуры в интерпретатор набивать
будут?

 AK> вновь перегружаться и запускать Си?

Куда перезагружаться?

 AK> Правильно - программисту фронт работ на месяц вперед

У вас програмисты машины перезагружают? Я по наивности думал, что они пишут
программы.

Roman


Re: _Loader_
Всем привет.

Quoted text here. Click to load it

Может. Причем почти всегда результатом будет так-же вывод ошибки (возможно не в
том месте и не того типа).

Quoted text here. Click to load it

Для того, что-бы Форт стал нужен, нужны очень крупные проекты с Форт-ядром. По
сути нужен второй Linux :). Иначе задача будет решатся на Си (Делфи, Жаба,
VB...) как-бы криво она на них не ложилась.

Quoted text here. Click to load it

Конечный продукт :). Хотя очень трудно провести границу между ними.

Quoted text here. Click to load it

В принципе верно, НО !!! Задача программистом решается ДО создания грамматики
соответствующей области решаемой задачи. Далее знание Форта практически не
нужны - использовать полученную грамматику может и специалист в области задачи.
Причем эта грамматика может быть очень гибкой и очень дуракоустойчивой
одновременно (сохраняя высокую эффективность т.к. при исполнении задачи
интерпретатор уже не работает :) ). Кстати Eserv, acWeb, nnCron, xMenu примеры
именно такого подхода.

Quoted text here. Click to load it

Ну а если эта ОС называется Форт-система, чем это не устраивает? Т.е. между
Форт-системой и железом ничего кроме BIOS и где-то лежащего DOSа нет, чем это
хуже при решении критичных по времени задач?

Quoted text here. Click to load it
набивать
Quoted text here. Click to load it

Можно и с клавиатуры - грамматика для решения задачи обычно уже в Форт-системе
есть. А вообще - компилируешь с диска (файл в терминах задачи) и запускаешь.

Quoted text here. Click to load it

Завершить текушую задачу, пойти к программисту и изложить требования к
следующей. Он поработает, создаст исполнимый файл и передаст для запуска на
твоей машине и так каждый раз!?
О циклах отладки я помолчу...

                                              АртемКАД




Re: _Loader_
11-Oct-03 08:06 Alex Kouznetsov wrote to Vladimir Vassilevsky:

AK> Из отрицательных - в основном психологические факторы. Многие из тех,
AK> кто
AK> привык работать на сях, изучать Форт не желают. Приводят любые доводы и
AK> отговорки, вплоть до самых глупых.

 С одной стороны -- неопровержимо.

 С другой...
 Было недавно на телесистемах обсуждение вопроса "почему к avreal нет GUI".
 В числе прочих на полном серьёзе было высказано мнение, что либо мне лень
писать такую оболочку, либо я этого не в состоянии сделать. А все аргументы,
которые я привожу за то, что программатор должен быть командной строкой --
это подведение идеологической базы под это дело.

wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Site Timeline