Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 ... 145 146 147 [148] 149 150 151   Вниз
  Печать  
Автор Тема: Общаемся обо всём!  (Прочитано 1016832 раз)
0 Пользователей и 2 Гостей смотрят эту тему.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4410 : 20-08-2017 17:20 » 

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

Конкретный пример: я предпочитаю использовать GCC в своих собственных разработках. Почти все заказчики, которых я консультирую, используют либо KEIL, либо IAR. И та, и другая системы проприетарны, совершенно закрыты, но при этом вовсю используются для секретных разработок. И ответственные за режим в этих конторах не поднимают паники (может, конечно, по незнанию, но факт).

С другой стороны, я не перечитывал исходники GCC, как Библию; и далеко не факт, что я пойму смысл каждой строчки с первого прочтения. То есть теоретически у меня есть шанс найти там закладки, если они есть, но практически он близок к нулю - не хватит ни времени, ни сил, ни квалификации. Из того, что мегатонны исходников открыты, не следует, что их реально читают.

Закрытой для кого? Лётчик или астронавт, осознанно идёт на риск, ставит на кон жизнь в обмен на деньги или удовлетворение амбиций.

Опять таки, вопрос доверия становится ключевым, когда Вы им управляете не снаружи, а сидя внутри.

Та же военная/космическая авионика бесконечно далека от open source. Надежность достигается не открытием кода в надежде, что праздный читатель найдет там ошибку, а специальными методиками разработки и испытаний.

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

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

Так вот .. сеть-СС никак, НИКАК не может иметь контактов с внешним миром
Но есть данные, которые должны собраться с ДСП и быть переданы в СС...
Как? только повторный ручной ввод. Внешние носители - это  контакт с внешним миром.

Можно придумать что-то принципиально одностороннее. Например, набивать данные на перфоленту. Потом она считывается девайсом, который после прочтения тут же ее уничтожает.

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

Свободное ПО - это лишь шаг к свободному железу. Сейчас развивается куча вещей типа RPi, Arduino, и есть инструменты CPLD/FPGA.

RPi не свободна. Настолько не свободна, что Вы даже процессор к ней отдельно не купите.

Arduino открыт, но откровенно убог. Это как Бейсик в мире программирования: тем, кто ожидает получить навыки для перехода к профессиональной разработке, придется забыть и переучиваться.

CPLD/FPGA - это всего лишь мешок вентилей и коммутационная доска. Сами по себе они ни открыты, ни закрыты, как любой другой набор микросхем.

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

https://www.youtube.com/watch?v=gQq_E8gnH5k
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #4411 : 20-08-2017 18:23 » 

У пилота стальные нервы. И очень большой навык пилотирования. Вывести машину из штопора на малой высоте, плюс посадить ее. Мое ему почтение.
Записан

Не будите спашяго дракона.
             Джаффар (Коша)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4412 : 20-08-2017 18:29 » 

Конечно, пилоту респектище. Но если бы его аппарат не был способен висеть только за счет тяги винта, когда подъемной силы от крыльев нет вовсе, он бы ничего не смог сделать.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4413 : 20-08-2017 19:52 » 

И ответственные за режим в этих конторах не поднимают паники (может, конечно, по незнанию, но факт).
Гусь много чего думал пока не попал в суп. Суть нашего времени, как Вы раньше правильно заметили, когда система начнёт сыпаться, "эффективному" руководителю нужно словить момент и вовремя сбежать.

Та же военная/космическая авионика бесконечно далека от open source.
То есть, инженеры разработчики, включая главных, не имеют доступа к разработкам? Не надо всё в кучу смешивать. Давайте мерить всё относительно себя, тот же Windows со стороны Microsoft вполне себе open source.

CPLD/FPGA - это всего лишь мешок вентилей и коммутационная доска. Сами по себе они ни открыты, ни закрыты, как любой другой набор микросхем.
Я имел ввиду, что в будущем на базе CPLD/FPGA могут появиться вещи, аналогичные RPi, а может и более серьёзные. Вот есть например готовый процессор с ARM архитектурой, созданный на базе FPGA Altera - Nios. Это значит, что архитектура, заложенная в железе, уже не является непреодолимым для индивидуума препятствием.

PS: RXL, с вертолётами ты уже играл, будешь переходить к моделям самолётов собственного изготовления?
Записан
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4414 : 20-08-2017 20:04 » 

Но если бы его аппарат не был способен висеть только за счет тяги винта, когда подъемной силы от крыльев нет вовсе, он бы ничего не смог сделать.
Судя по видео, он и не висел. Переход потенциальной энергии в кинетическую позволяет набрать скорость. Большая проблема, которая у него была, и которую он решил - компенсация возникшего момента, когда отвалилась часть крыла. С конструктивной точки зрения у его самолёта очень маленький вес, что отражается на крайне малом значении скорости сваливания. С другой стороны, маленький вес - низкая прочность. Не делали бы его из "фанеры" может быть и крылья бы у него не отваливались.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4415 : 20-08-2017 20:29 » 

архитектура, заложенная в железе, уже не является непреодолимым для индивидуума препятствием.

Может, я неправильный индивидуум, но для меня железная архитектура никогда не была непреодолимым препятствием. Да и не для меня одного. Например, полностью открытый Linux прекрасно реализован на абсолютно проприетарной платформе Intel x86.

Опять же, открытый Arduino делается на проприетарной платформе Atmel XMEGA, которая еще хуже в этом плане: у этих чипов, в отличие от тех же x51, нет альтернатив, а положение единственного поставщика в очередной раз вызывает множество вопросов.

Вполне можно выпускать открытое ПО, не разворачивая на кухне кустарное производство самодельного оборудования для него. Это интересно и познавательно само по себе, но вовсе не обязательно.

С конструктивной точки зрения у его самолёта очень маленький вес, что отражается на крайне малом значении скорости сваливания.

Если бы не мощная тяга, в отсутствие подъемной силы крыла (а ее не могло быть, при посадке оно висело вертикально вниз) вес не имел бы значения - любое тело переходит в свободное падение с ускорением g. Именно вертикальная составляющая тяги, компенсирующая вес, позволила управлять плавностью снижения, с чем пилот справился с честью.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #4416 : 20-08-2017 20:34 » 

как-то смотрел ролик, вид из современного Российского тепловоза. С начала старта и до почти окончания пути следования. У них в качестве приборной панели, вполне так стоит винда (IMHO XP). Т.е. закрытая для машинистов система. Поверх нее навешен интерфейс приборной панели. Также закрытый для машиниста. О качестве сего творения нужно спрашивать машинистов. На мой неускущенный взгляд жутко неудобно.

По самолету, насколько я понял, там "фанера" не виновата. Обрыв произошел на месте стыка крыла к корпусу. Скорее всего выбило болты крепления.
Записан

Не будите спашяго дракона.
             Джаффар (Коша)
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4417 : 20-08-2017 21:25 » 

Если бы не мощная тяга, в отсутствие подъемной силы крыла (а ее не могло быть, при посадке оно висело вертикально вниз) вес не имел бы значения - любое тело переходит в свободное падение с ускорением g.
Самолёты для аэробатики имеют в среднем вес от 300 до 600 кг, при этом на них действительно стоит серьёзный двигатель в 200...800 лс, который может дать тяговооружённость более 1. Но Вы распространяете это мнение на всю авиацию в целом. А я больше сетую на причину: в данном конкретном случае у него жертвуют весом, исключая всё, даже запас топлива на мало мальский перелёт. Это можно рассматривать, как типичный случай в спорте, когда спортсмен за десять лет карьеры истощает свой организм на сорок лет, и иногда организм отказывает досрочно.

... вполне так стоит винда (IMHO XP).
Обычно в таких системах ставят Windows CE.

Впрочем, ушли от темы: готовы ли Вы доверить самую ценную информацию чёрному ящику? Хотя, ответ я уже тоже получил.

По самолету, насколько я понял, там "фанера" не виновата. Обрыв произошел на месте стыка крыла к корпусу. Скорее всего выбило болты крепления.
Не могу судить о конструкции по видео. В этом месте возникает максимальный изгибающий момент. Во время движения по кругу возникает перегрузка, вот и результат - конструкция не выдержала. Вообще, эти самолёты способны выдерживать до 10g - столько пилот не выдерживает, а это значит имеет место усталостное разрушение, либо брак.
Записан
Sla
Модератор

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #4418 : 20-08-2017 21:47 » 

Насколько я помню, это фейк с крылом..
ага вот
https://www.youtube.com/watch?v=naSZBdJoEbM

А вы тут.. перегрузках..

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


Мне пришлось исписать около 10 листов как пользоваться программулиной написанной на тикле. Хотя все было просто. Готовый инсталляционный пакет и запуск скрипта.

Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4419 : 20-08-2017 22:31 » 

Но Вы распространяете это мнение на всю авиацию в целом.

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

Впрочем, ушли от темы: готовы ли Вы доверить самую ценную информацию чёрному ящику? Хотя, ответ я уже тоже получил.

Не просто готов, но и делаю это весь рабочий день кряду. Информация поступает через сетевую инфраструктуру, построенную на черных ящиках Cisco, хранится на черных серверах баз данных Oracle и обрабатывается программами, написанными в закрытой Visual Studio на проприетарных персоналках под Windows. Да, и хранятся эти данные на специальных навороченных хранилищах, тоже весьма черных.

Ну никак не поспевает открытая Ардуина за нашими потребностями... Да и отечественные "Байкалы", которые встающая с колен промышленность отчаянно пытается нам впарить за чисто отечественный продукт, пока далеко не айс. А все фирменное оборудование закрыто за семью замками, причем лицензионное соглашение недвусмысленно запрещает даже ковырять гвоздиком в замочной скважине, вплоть до юридической ответственности.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4420 : 20-08-2017 22:55 » 

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

"... у некоторых современных самолётов ..." обобщением бы не было, так как есть отдельный класс СВВП, например,  https://ru.wikipedia.org/wiki/Hawker_Siddeley_Harrier, который выпускался серийно с 1967 года. И то, это не делает их кирпичами.

Не просто готов, но и делаю это весь рабочий день кряду.
Поэтому я и написал, что ответ получил.

Ну никак не поспевает открытая Ардуина за нашими потребностями...
Один паломник поинтересовался у мудреца:
- Долго ли ждать перемен к лучшему?
- Если ждать, то долго! - ответил мудрец.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4421 : 20-08-2017 23:55 » 

"... у некоторых современных самолётов ..." обобщением бы не было

Да, действительно, проглядел. Оставил лазейку, и отсутствие явного обобщения "у всех самолетов" тут не оправдание, каюсь.

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

- Если ждать, то долго! - ответил мудрец.

Ну а вот если не ждать? Столь же долго, или есть реальная и конструктивная альтернатива, кроме как нетерпеливо ерзать?
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4422 : 21-08-2017 07:44 » 

PS: RXL, с вертолётами ты уже играл, будешь переходить к моделям самолётов собственного изготовления?

Конструкции самолетов — это моя специальность, по которой ни дня не работал. В середине 90-х молодые специалисты отечественной авиации были не нужны. А на модельки времени нет.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4423 : 21-08-2017 07:56 » 

Еще в это момент вспомнился трюк на публику, когда на выставочных аэросалонах здоровенную реактивную дуру ставят на хвост неподвижно, наглядно демонстрируя, что и без крылышек она неплохо обходится. Кажется, "кобра" называется, но не уверен. Воистину состязание "кирпичей"...
Не совсем, данная фигура может выполняться в очень узком интервале скоростей конкретно СУ-27, про остальных не знаю, что-то вроде 350-400 км/ч, но могу ошибаться. В противном случае он свалится, и тут уж как повезёт, не всегда пилотам удаётся вывести самолёт в случае штопора.

Вообще, у нас тоже делали СВВП, но позже в 80-х, и потом канул он как-то тихо и незаметно. Суть в том, что подобный режим дорого обходится.

Примерные параметры:
Харриер / СУ-27 / Боинг - 737

Максимальный взлётный вес в кг: 7 900 (верт.) / 33 000 / 79 000
Максимальная тяга двигателей в кгс: 9 500 / 15 000 (бесф.) - 25 000 (форс.) / 25 000
Соотношение тяга/вес: 1,20 / 0,45 - 0,76 / 0,32
Масса двигателей в кг: 1 700 / 3 000 / 6 500
Соотношение масса дв./вес: 0,22 / 0,09 / 0,08

Может немного и врут, но соотношения примерно верны - относительный вес двигателя более чем вдвое выше у самолётов с тягой превышающий вес в сравнении с самолётами обычной компоновки. И всё равно вертолёт они не заменят. Был такой проект у американцев - Оспри - это конвертоплан, но как-то вяло его показывают.

Ну а вот если не ждать?
Что-то создавать, или говорить о том, что стоит создавать. Лично мне не так важно осуществлю ту или иную идею я лично или нет, меня больше интересует само знание и построение системы, которая обладала бы необходимым описанием для сравнения с альтернативными и существующими решениями.
Записан
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4424 : 21-08-2017 07:58 » 

Конструкции самолетов — это моя специальность, ...
А моя это конструкция двигателей самолётов, а остальное почти также.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4425 : 21-08-2017 09:49 » 

Что-то создавать, или говорить о том, что стоит создавать.

Вот лично мне для счастья очень не хватает программно-аппаратного комплекса для функционального и приемочного тестирования встроенных систем.

Аппаратура: интерфейсная плата, подключаемая к PC (по USB) и к испытуемой системе (ИС) через ее интерфейсы. Получает от PC команды для генерации воздействий на ИС (цифровые и аналоговые сигналы), регистрирует отклик ИС и передает в PC.

Программное обеспечение: драйвер интерфейсной платы; система тестирования, позволяющая описывать тестовые сценарии на специальном проблемно-ориентированном языке (DSL) и проверяющая соответствие поведения реальной ИС описанному на DSL идеалу.

Наличие такой системы позволило бы перенести идеи разработки, управляемой спецификацией поведения (BDD), в мир разработки оборудования. Сначала описываем требования к устройству на языке, понятном как разработчикам, так и нашему комплексу. Затем начинаем разработку, а комплекс периодически производит автоматическое тестирование, тут же давая знать, как только что-то пошло не так.

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

Обсуждали эти идеи с коллегами из США, они проявили живой интерес, но к разработке подключаться не торопятся, ссылаясь на высокую занятость в собственных проектах (это на самом деле так, не просто вежливый отказ). Соотечественники традиционно к идеям тестирования относятся прохладно, ибо тестирование плохо совместимо с генетически закодированным "авосем".

Вот такая потенциальная тема для разработки.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4426 : 21-08-2017 11:01 » 

Соотечественники традиционно к идеям тестирования относятся прохладно, ибо тестирование плохо совместимо с генетически закодированным "авосем".
У нас тестирование аппаратной части производится, но для этого обычно ведутся отдельные разработки испытаний и стендов. Задача, которую Вы ставите слишком широка. Например, в каком скоростном диапазоне должно тестироваться то или иное устройство? Очевидно, что есть малые режимы - для отладки узлов, рабочие режимы - для отладки систем, испытания с повышенной скоростью - для сдачи систем. Так вот, спектр систем велик, есть устройства, которые ограничиваются величинами кГц, есть средняя категория в десятки и максимум сотню МГц, плюс СВЧ. Спрашивается, сколько стоят, например, осциллографы на 1 ГГц? А в Вашем устройстве сбора информации должно быть на портах ввода по одному осциллографу. Какова пропускная способность USB? Не такая уж и большая, значит осциллографы должны записывать данные синхронно в некий банк ОЗУ, откуда потом их извлекать и анализировать. Анализировать в реальном времени скорее всего будет невозможно, так как синхронизация всех узлов должна быть жёсткой.

Другой проблемой является сам принцип: есть тестируемое (Т1), а есть тестирующее (Т2) устройства. Как убедиться, что Т2 в данном режиме не имеет отклонений, получается ряд Т1 - Т2 - Т3 - Т4 устройств, хорошо, если он сходится на уровне доступном восприятию человека. А это значит, что можно миновать много шагов просто сразу разрабатывая модули необходимого устройства на микро уровне. Плюс отладка технологии производства - всё может быть верно, но что-то придёт с другой стороны.

Третья проблема, вот, например, сумматор - два числа A и B по 64 бит дают сумму. С точки зрения математики проблемы нет, а вот устройство следует проверить. Как это сделать, проверять все комбинации A+B?

Получается 2128 комбинаций, предположим, что скорость счёта будет на уровне 1 ГГц, что примерно 230, тогда потребуется 298 секунд, что составляет примерно 10 049 234 210 332 868 796 745 лет. Надеюсь, что не ошибся. А это означает, что некоторые аппараты невозможно тестировать целиком, удостовериться можно лишь в частных измерениях. Производители ИС, насколько знаю, делают внутренние блоки самоконтроля, которые могут проверить этот сумматор по частям внутри самой ИС.

Может я чего и не понимаю, но выразить всё через единый шаблон не получается.

Давайте попробуем взять типовую задачу - съём параметров работы транзистора от статического режима до ГГц в рамках Вами желанной системы.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4427 : 21-08-2017 12:06 » 

У нас тестирование аппаратной части производится, но для этого обычно ведутся отдельные разработки испытаний и стендов.

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

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

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

спектр систем велик, есть устройства, которые ограничиваются величинами кГц, есть средняя категория в десятки и максимум сотню МГц, плюс СВЧ. Спрашивается, сколько стоят, например, осциллографы на 1 ГГц? А в Вашем устройстве сбора информации должно быть на портах ввода по одному осциллографу.

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

Какова пропускная способность USB? Не такая уж и большая, значит осциллографы должны записывать данные синхронно в некий банк ОЗУ, откуда потом их извлекать и анализировать. Анализировать в реальном времени скорее всего будет невозможно, так как синхронизация всех узлов должна быть жёсткой.

Для сигналов достаточно жесткого реального времени планирую проверку реализовать в самой интерфейсной плате. Например, она получает команду проверить, что на такой-то вход поступают импульсы длительностью 1 мкс и периодом 10 мкс с допуском 5%. Плата по USB передает не оцифрованный сигнал, а лишь результат проверки "да/нет" (возможно, с конкретизацией, по каким критериям "нет"). Это должно принципиально снизить ограничения по скорости USB.

Другой проблемой является сам принцип: есть тестируемое (Т1), а есть тестирующее (Т2) устройства. Как убедиться, что Т2 в данном режиме не имеет отклонений

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

Третья проблема, вот, например, сумматор - два числа A и B по 64 бит дают сумму. С точки зрения математики проблемы нет, а вот устройство следует проверить. Как это сделать, проверять все комбинации A+B?

Получается 2128 комбинаций, предположим, что скорость счёта будет на уровне 1 ГГц, что примерно 230, тогда потребуется 298 секунд, что составляет примерно 10 049 234 210 332 868 796 745 лет. Надеюсь, что не ошибся. А это означает, что некоторые аппараты невозможно тестировать целиком, удостовериться можно лишь в частных измерениях. Производители ИС, насколько знаю, делают внутренние блоки самоконтроля, которые могут проверить этот сумматор по частям внутри самой ИС.

Это вечная проблема при диагностике схем с большим количеством комбинаций. Сумматор - это еще не самый худший случай. Если проверять, скажем, все состояния модуля оперативной памяти на 8 гигабайт, Ваши 298 секунд покажутся коротким мгновением. Поэтому перебором такие схемы не тестируют.

Для сумматора мы можем обойтись проверкой каждого двоичного разряда, а также формирования переносов. В каждом из разрядов всего 3 входа и 2 выхода, всего 8 тестов. Повторяем 64 раза, это не так уж долго.

Давайте попробуем взять типовую задачу - съём параметров работы транзистора от статического режима до ГГц в рамках Вами желанной системы.

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4428 : 21-08-2017 14:30 » 

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

В принципе, самое важное это правильно выбрать тип интерфейса между хабом и удалёнными блоками. У самолётов, судов и зданий длина может быть довольно велика, поэтому расстояние надёжной связи должно быть около 500 м, но при этом достаточно скоростной - 9600 может быть маловато. Канал приёмный и передающий имело бы смысл объединить, так как при диком количестве проводов получается ситуация, как в старом АТС. По каждому каналу в независимости от команды с компьютера от хаба должны идти пакеты с чётким временным шагом в шапке которых должно передаваться значение главного таймера для синхронизации. Каждый блок должен самоидентифицировать свой тип, а вот порядковый номер блока одного типа лучше ставить вручную посредством какого-нибудь DIP переключателя. Таким образом, один канал представляет из себя четыре провода: два - это информационная витая пара и ещё два - это питание (24 V, max 500 mA) от общего источника, от которого, кстати лучше питать и компьютер. Вот вкратце моё видение. Ну и в шапке ответа также должно передаваться время, когда то или иное действие было выполнено.

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4429 : 21-08-2017 19:15 » 

Я выбрал для первой реализации частный случай - тестирование встроенной системы. Он в чем-то проще, а в чем-то сложнее универсального стенда.

Чем он проще:

1. Электронный блок компактен. Следовательно, не потребуется передавать информацию на большое расстояние. Можно обойтись USB, которая штатно присутствует на любом ПК.
2. Электронный блок сразу вырабатывает электрические сигналы, которые легко либо непосредственно ввести в интерфейсную плату, либо нормализовать простыми средствами (например, "сухой контакт" заземлить и притянуть резистором к логической единице; понизить большое напряжение делителем или маленькое поднять инструментальным усилителем, переменное - выпрямить пиковым/квадратичным детектором, в случае слишком большого динамического диапазона - логарифмировать; преобразовать ток в напряжение датчиком Холла, и т.п.).

Чем сложнее:

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

Что касается исследования свойств макросооружений вроде аэробусов, мостовых пролетов и т.п., тут явно придется городить целую распределенную систему сбора данных. В качестве первого кандидата на транспорт данных я бы рассмотрел стандартную сеть CAN, благо в моих закромах томятся несколько пригоршней специализированных микросхем для нее. Может быть, практичнее окажется двузвенная архитектура: сеть CAN из концентраторов, на которые скидывают данные радиочастотные датчики. Возможно, найдется подходящая open source SCADA, чтобы не городить велосипед.

Но это, как я уже говорил, несколько другая история, хотя и в чем-то родственная.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4430 : 22-08-2017 07:49 » 

Это значит, что ПО системы тестирования должно содержать интерпретатор языка для описания сценариев тестирования, чтобы описывать контекст поведения. Причем этот язык должен быть достаточно высокоуровневым, чтобы разработчик мог формулировать сценарии прямо на языке своей предметной области.
Вариант языка из систем HDL не рассматривался?

Может быть, практичнее окажется двузвенная архитектура: сеть CAN из концентраторов, на которые скидывают данные радиочастотные датчики.
Как только появится промежуточный концентратор - появятся его задержки и нюансы. Опять таки, всё упирается в исходную постановку задачи. Для моста в 1-10 км естественно придётся городить сеть, возможно и на базе радиосвязи, хотя это не так надёжно. Я как-то писал о том, что уже сейчас есть пластиковое оптическое волокно, но пока дорого оно и не очень далеко действует передача - затухание сильное в материале.

* LatticeTestbenchPrimer.pdf (65.42 Кб - загружено 10 раз.)
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4431 : 22-08-2017 13:32 » 

Вариант языка из систем HDL не рассматривался?

Я не знаю, как на нем можно описать сценарий взаимодействия с системой.

Первый (и пока основной) претендент на эту роль - Gherkin. Я уже приноровился описывать на нем приемочные тесты, и коллег на него подсадил прочно.

Например, если мы описываем поведение сигнализации при срабатывании датчика движения в помещении, получится нечто вроде (при использовании русского диалекта Gherkin):

Код:
Функция: охрана замкнутого помещения при помощи инфракрасного датчика движения.

Сценарий: подача сигнала тревоги при активации датчика.
    Пусть система находится в состоянии "охрана"
    Если сработал датчик движения
    То система должна перейти в состояние "тревога"
    И сирена должна включиться
    И панель тревоги должна мигать с частотой 2 герца с допуском 10%

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

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

Если с самого начала набор функциональных требований зафиксировать на Gherkin'е, впоследствии в любой момент времени можно получить полный объективный отчет о текущем состоянии проекта: такие-то функции работают, такие-то нет.

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

Если там будет большое количество видеотрафика, это может быть проблемой (хотя от меня до Youtube 20 хопов, и ничего). А та же температура вполне подождет секунду.

Я как-то писал о том, что уже сейчас есть пластиковое оптическое волокно, но пока дорого оно и не очень далеко действует передача - затухание сильное в материале.

Все равно это хозяйство придется запитывать электричеством, на одном свете далеко не уедем. Бегать по мосту с мешком батареек - удовольствие еще то. Пока что медная витая пара - наше все.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4432 : 22-08-2017 17:05 » 

Я не знаю, как на нем можно описать сценарий взаимодействия с системой.
Я прикрепил файл в предыдущем посте, который описывает блок тестирования. Verilog позволяет описывать аппаратные тесты.

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

Вообще, люблю "С" по большей части. Для меня было открытие, когда я перешёл с BP, который учил традиционно первым из языков высокого уровня, на BC. Пропала необходимость создавать непонятно какие конструкции. Но есть вещи, которые до сих пор не нравятся, в первую очередь, отсутствие работы с флагами. А также не хватает особого флага ошибки с аппаратной стороны, назовём его "e" флаг, который бы освобождал использование аккумулятора только для передачи полезных данных. Также был бы не плох флаг "ef", который бы поднимался бы при потере значимости в результате операции FPU. Заодно при этом установленном флаге, FPU мог бы аппаратно пропускать инструкции - какой смысл продолжать расчёт, если смысл вычисления уже потерян. Мне кажется, в конструкциях языков более высокого уровня, таких как: throw-catch, идёт перерасход вычислительных ресурсов.
« Последнее редактирование: 22-08-2017 18:24 от Aether » Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4433 : 22-08-2017 21:25 » 

Verilog позволяет описывать аппаратные тесты.

Тут главный вопрос: будут ли эти тесты столь же выразительны и понятны заказчику? Это реально очень важно.

Язык человека понятен заказчику, но непонятен машине. Даже если сделать особый парсер, который будет находить в тексте шаблоны и вызывать соответствующие функции, сами функции придётся писать на том же "С" например.

Парсер уже есть, и очень хороший. Это Cucumber (написанный на языке Ruby) и его многочисленные клоны на разных языках (я регулярно использую парочку, но оригинал все же нравится больше).

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

Более общий вариант - трансляция предметно-ориентированной конструкции "Если сработал датчик движения" в низкоуровневую "Если сигнал на входе B11 перешел из 1 в 0". Такую трансляцию можно делать динамически по таблице либо статически при помощи макроподстановки, дело вкуса.

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

Вообще, люблю "С" по большей части.

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

Еще ему долгое время принадлежала ниша встроенных приложений, но сегодня и оттуда его очень активно теснит оттуда C++, который объективно безопаснее и выразительнее. Редкий месяц обходится без вебинара о переходе с C на C++ для микроконтроллеров, я уже и посещать их перестал - одно и то же.

На сегодня его единственный плюс, пожалуй, простота, хотя порой он бывает обманчива.

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

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

также не хватает особого флага ошибки с аппаратной стороны, назовём его "e" флаг, который бы освобождал использование аккумулятора только для передачи полезных данных.

А что вообще аккумулятор делает в языке уровня выше ассемблера (пусть и совсем ненамного выше)? В стандарте языка C никаких аккумуляторов нет. Да и вообще - что это такое само по себе?

Также был бы не плох флаг "ef", который бы поднимался бы при потере значимости в результате операции FPU.

Это вообще лишнее - заводить зоопарк флагов на все случаи жизни. Ошибка FPU ничем принципиально не отличается от любой другой ошибки. Это наследие времен, когда Intel не сумел реализовать обработку реальной арифметики на том же кристалле и сделал отдельную нашлепку. Со временем физически нашлепка переехала в тот же корпус, а логически так и осталась торчать сама по себе.

Мне кажется, в конструкциях языков более высокого уровня, таких как: throw-catch, идёт перерасход вычислительных ресурсов.

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

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

Вообще на тему "перерасходов" как-то давно перевел замечательную статью "Оптимизация: ваш злейший враг". Очень правильная статья, рекомендую.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4434 : 23-08-2017 07:45 » 

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

Python style. Например, конец итерирования объекта и неудачный поиск в словаре оператором []. В Python исключение там норма.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4435 : 23-08-2017 08:04 » 

Если сохранить все необходимые для конкретной задачи трансляции в единый профиль, то загрузка этого профиля превращает универсальный стенд в специализированный.
Я делал себе в рамках хобби стенд для экспериментов с электроникой из специальной монтажной доски (не фольгированный стеклотекстолит толщиной 4 мм) с отверстиями и пазами, а за ней располагался силовой узел, дающий разные напряжения, и узел связи с ПК через USB средствами Arduino. Конечно, не лучшее решение, так как вся мощь USB состоит в пакетной передаче данных, а не в имитации последовательного порта, но драйверы в среде Windows я никогда не писал, а на ноутбуке не удобно держать две ОС, да и делать модуль, скажем на PIC 16F1454, для хоббийных проектов было лень. Сверху размещались тестируемые сборки на печатных платах. Разметка отверстий была выполнена так, чтобы можно было устанавливать платы разных размеров. (Файл разметки одной из досок прикреплю, её размер 380 х 360 мм.)

Есть битовые поля, которые позволяют реализовать любые наборы флагов. Для процессоров с поддержкой битовых операций C генерирует очень компактный код, без кувырканий с двоичными масками и логикой над ними.
Согласен, просто есть конструкции, например, конструктор возвращает указатель на структуру созданного объекта, либо "0" в случае ошибки. Так вот, в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна, а в других архитектурах возможна. Да и с точки зрения математики, код должен перерабатывать что угодно адекватно. Система возврата и обработок ошибок в рамках "С" запущена, код получается не компактным, а хочется читать суть, а не ряды проверок.

А что вообще аккумулятор делает в языке уровня выше ассемблера (пусть и совсем ненамного выше)? В стандарте языка C никаких аккумуляторов нет. Да и вообще - что это такое само по себе?
В рамках "С" речь идёт о соглашении о вызове, то есть обычно, когда мы пишем "return 0;" этот самый "0" попадает в eax (или регистр этой группы), который традиционно называется аккумулятором. С точки зрения железа, особенно в ранних архитектурах, под ним подразумевалось такое схемотехническое решение, чтобы обработка данных через него шла быстрее. Собственно, при программировании на ассемблере и сейчас стоит использовать его где только можно. Комбинация "xor eax, ex + push eax..." быстрее чем при использовании других регистров и намного быстрее и компактнее, чем заполнение нулевыми литерами.

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

И что тут страшного? Если возникло исключение, у приложения большие проблемы, и беречь наносекунды бессмысленно. Конечно, если использовать исключения правильно.
Исключение суть прерывание, мой анализ показал, что МП должен быть увлечён только одним прерыванием - это смена задач, а остальное от лукавого, так как вносит смуту. Отработка задач реального времени - это работа для МК.

Собственно, как например я вижу работу флага e. Представим, что у нас malloc не выделил память, тогда по возвращению e будет установлен (RETERR), а на запись в регистр нуля даже не надо тратить время.

Далее, все CALL инструкции при поднятом флаге ошибки пропускаются, а безусловные и условные переходы выполняются. Если мы обрабатываем ситуацию, то пишем переход через блок обработки, а если нет, то сам компилятор добавляет код при выходе из тела программы в месте "}" ставя выход из всей программы сразу. В итоге, значительный объём проверок просто будет не нужен. В версии DEBUG компилятор поставит сообщения об ошибке к каждой функции, а в RELEASE можно будет поймать ошибку по положению указателя на момент выхода из программы. Для управления не критичной ситуации с ошибкой потребуется нечто вроде "BCF E", которая сотрёт флаг ошибки и позволит продолжить выполнение функций.

* Панель.jpg (62.61 Кб - загружено 9 раз.)
Записан
Sla
Модератор

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #4436 : 23-08-2017 08:34 » 

Цитата
Язык человека понятен заказчику, но непонятен машине.

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

Ладно-ладно, не совсем точное сравнение.

Зачем парсер - если есть конструктор фраз
Взять с
Проверить там, через ... сек

Т.е. вполне вписывающаяся в структуру теста

Да, конечно, нужно обучать..

зы. Это моя первая работа - разработка диагностического комплекса.
Каждый блок прогонялся через тесты, которые были упорядочены в массиве
по принципу
PinUp -10
PinOut - 100
inputSignal - d1
outputSignal - a=0,4-0,45

ox 28лет...ДВК
И работало!!!!

Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4437 : 23-08-2017 09:55 » 

в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна

Разве Intel научился делать бесконечную память? И даже если так, как быть с конечной разрядностью адреса?

Система возврата и обработок ошибок в рамках "С" запущена, код получается не компактным, а хочется читать суть, а не ряды проверок.

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

когда мы пишем "return 0;" этот самый "0" попадает в eax (или регистр этой группы), который традиционно называется аккумулятором.

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

На x86, к счастью, свет клином не сошелся (хотя многократно пытался). В мире embedded правят бал другие архитектуры (ARM, PowerPC etc), в которых ничего подобного нет.

Проблема в стандарте IEEE 754, то есть FPU работает с такими категориями данных, которые трудно встречаются в реальных задачах. И программист их не отрабатывает, ссылаясь попросту на то, что их появление маловероятно.

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

Исключение суть прерывание

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

мой анализ показал, что МП должен быть увлечён только одним прерыванием - это смена задач, а остальное от лукавого, так как вносит смуту.

Какую же смуту вносит прерывание от сетевого адаптера, получившего фрейм, или от диска, завершившего операцию обмена данными?

Собственно, как например я вижу работу флага e. Представим, что у нас malloc не выделил память, тогда по возвращению e будет установлен (RETERR), а на запись в регистр нуля даже не надо тратить время.

Пробовали оценить реальную экономию времени?

Далее, все CALL инструкции при поднятом флаге ошибки пропускаются, а безусловные и условные переходы выполняются. Если мы обрабатываем ситуацию, то пишем переход через блок обработки, а если нет, то сам компилятор добавляет код при выходе из тела программы в месте "}" ставя выход из всей программы сразу. В итоге, значительный объём проверок просто будет не нужен. В версии DEBUG компилятор поставит сообщения об ошибке к каждой функции, а в RELEASE можно будет поймать ошибку по положению указателя на момент выхода из программы. Для управления не критичной ситуации с ошибкой потребуется нечто вроде "BCF E", которая сотрёт флаг ошибки и позволит продолжить выполнение функций.

IMHO довольно запутанно и хрупко. А если при оптимизации компилятор раскрыл код inline функции и убрал CALL?
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4438 : 23-08-2017 11:11 » 

Разве Intel научился делать бесконечную память? И даже если так, как быть с конечной разрядностью адреса?
Дело не в количестве памяти, а в том принципе, что любая функция, которая возвращает результат, не имеет нормальной возможности сообщить об ошибке. А попытки "уплотнения", которые используются в ряде случаев - это больше костыли. Битовые поля - это хорошо, но помним, что выделять придётся целую ячейку памяти или целый регистр под 1 бит. Регистр в этом случае получается дорогим, а обращение к памяти - это сразу потеря в производительности. И если это ещё и в цикле, то само собой торможение умножается.

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

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

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

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

IMHO довольно запутанно и хрупко. А если при оптимизации компилятор раскрыл код inline функции и убрал CALL?
Ничего не изменится.
Код: (C)
{
...
    {
        p = create_object(); // Заполняем указатель на объект, выделяя память.
        if (p == 0) {... Обрабатываем ошибку ...} // Вот этих обработчиков уйма.
        ...
        // Продолжаем работу с созданным объектом
        ...
    }
...
}
Код: (C)
{
...
    {
        p = create_object(); // Заполняем указатель на объект, выделяя память.
        if (_err) { // Если нам нужен свой обработчик ошибки.
        ... Сбрасываем флаг ошибки ...
        ... Обрабатываем ошибку ...}
        // А если обработчик не нужен, то ничего не пишем, так как в DEBUG компилятор должен добавить:
        if (_err) {
        ... Сброс флага ошибки ...
        dprintf("object1.c line 540 create_object error\n");
        ... Выход ...
        } // А в RELEASE этого не будет, он просто проедет до конца тела этого блока.
        ...
        // Продолжаем работу с созданным объектом
        ...
    }
    // Вот здесь идёт проверка, которую вставляет компилятор,
    // если при выходе из тела блока флаг поднят, то программа завершается.
...
}
Фишка в том, что в большинстве случаев обработчики собственного изготовления не понадобятся, и всё безопасно упростится до изложения собственно алгоритма. inline при раскладке предположим упростится до вычисления чего-то, которое не будет произведено из-за флага, и до системного вызова или вызова функции, которые тоже не будут производится. При этом не произойдёт никаких обращений к памяти данных, поэтому ни скорость не пострадает ни ресурсы.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4439 : 23-08-2017 14:11 » 

Дело не в количестве памяти, а в том принципе, что любая функция, которая возвращает результат, не имеет нормальной возможности сообщить об ошибке.

Ну как же не в количестве, когда:
Цитата
Так вот, в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна, а в других архитектурах возможна.
Менеджер памяти возвращает пустой указатель в случае, когда динамическое выделение запрошенного блока невозможно, т.е. "куча" исчерпана. Эта ситуация невозможна лишь при условии наличия бесконечной памяти. Непонятно только, почему "другие" архитектуры так оплошали.

Исключение - вполне себе нормальная возможность сообщить об ошибке, очень правильная конструкция.

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

Если выделять целую ячейку под бит, зачем тогда битовые поля?

А много программистов ставят условие на проверку бесконечности или ухода в область денормализованных чисел, когда точность результата становится сомнительной? Больно много выпороть придётся, а значит дело не в лени, а в системе.

Не вижу проблемы включить стандартный заголовок <fenv.h>, а в нужном месте вызвать fetestexcept(). Программистам, которым лень сделать такую малость в приложении, где это реально важно, лучше заняться чем-нибудь другим, например, мести улицу (хотя и мести они наверняка будут так же неаккуратно).

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

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

Исключение генерируется автором кода намеренно, возникает синхронно в строго определенных точках программы, необратимо прекращает выполнение процесса, передавая управление обработчику исключения (если есть) либо завершая работу приложения.

Как видим, общего совсем немного.

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

Разделение времени процессора между несколькими процессами - типичное решение, найденное еще на заре эры компьютеров.

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

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

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

Ваша статья есть по энкодерам, вот вопрос: что важнее: следить за каналами изменения следящих оптопар или за изменением состояния внешнего порта? А теперь представьте, что такую систему обяжут следить ещё за тремя объектами, и повесят их на прерывания - то, что рано или поздно он ошибётся в координате - гарантировано.

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

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

Это же всего две задачи. Нужно поставить на МК ОС реального времени и запускать независимые задачи под ее управлением. Можно сделать гораздо больше. Вот в былые времена дали бы Вам, скажем, СМ-1420 следить за двумя лампочками? А ведь тот же STM32 производительнее раз в сотню.

Ничего не изменится.

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

Обычный механизм исключений гораздо прозрачнее и удобнее в использовании.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Страниц: 1 ... 145 146 147 [148] 149 150 151   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines