SII

Пока -- небольшую пачку импульсов одной частоты, а дальше видно будет... Среда -- вода. Источник и приёмник условно неподвижны, объекты -- и неподвижные, и подвижные. Расстояние -- порядка нескольких десятков метров. Железо сделали без меня и до меня. Хотя там приходит чисто аналоговый сигнал, на его прохождение я повлиять не могу, моё -- организация захвата на АЦП и дальнейшая обработка, т.е. чисто программистская работа. Канал один-единственный: и излучатель, и датчик -- керамическая (?) пластина в единственном числе. Причём, сильно подозреваю, само подключение неправильное: у неё один конец сидит на земле, а другой сначала качают (два транзистора дёргают первичную обмотку трансформатора, вторичная -- на пластину), а потом принимают с него сигнал, который дальше идёт на усилитель и оттуда на АЦП. Лично мне кажется, что датчик к земле подключаться не должен (думаю, правильней оба конца датчика -- на вторичку трансформатора для излучения и на входы дифференциального усилителя при приёме или что-то в этом роде), но что дали, то дали... Ну, постановщиков помех как таковых точно нет: не ГАС для подводной лодки изобретаю, вероятность применения средств РЭБ не предусматривается :) Источники -- и природные, и всякие "бытовые". Спасибо, гляну. Но, как я уже сказал, хочется не просто готовое решение где-то стащить, а ещё и понять, как оно работает и почему именно так надо, а не иначе. И Вам спасибо. Проблема с умными словами одна: можно найти, как оно считается, но так и не понять, как использовать всю эту математику на практике. Почему, собственно, на форуме и спросил, а не стал тупо зарываться во всякий там матан.

Передо мной стоит задача программно обработать принимаемый ультразвуковой сигнал и выделить в нём "наблюдаемые" объекты -- т.е. отражения того сигнала, который был излучён перед началом приёма. Для каждого объекта надо получить расстояние до него (по сути, время от начала захвата сигнала до появления отражения от данного объекта), "плотность" объекта (амплитуду отражённого сигнала) и "размер" объекта (длительность отражённого сигнала). Сам сигнал оцифровывается с достаточно высокой скоростью (1--3 МГц при частоте исходного излучаемого сигнала до 200-250 кГц), работать надо уже с полученными от АЦП данными. Сигнал, понятное дело, не идеальный: помимо отражений излучённого сигнала, там могут быть всякие разные помехи и т.д. и т.п. Цифровой обработкой сигналов никогда не занимался, так что можно считать, что мои познания заключаются в нескольких умных словах вроде БПФ (но именно в словах :) ). Насколько понимаю, мне надо сначала "профильтровать" принятый сигнал, чтобы удалить из него помехи (сигналы с частотами, отличающимися от искомой -- что можно было бы сделать простым "железным" фильтром, но здесь задача обойтись чисто программными средствами; аппаратура лишь усиливает сигнал от датчика без какой-либо обработки), а затем в оставшемся наборе искать объекты по простому повышению амплитуды сигнала относительно некоего заданного уровня. Если понимаю суть правильно, то как эту задачу решить? Замечу, что меня как таковое интересует не готовое решение (которое можно скопипастить, не приходя в сознание), а более-менее внятное объяснение, что и почему я должен сделать и как всё это называется по-научному (желательно, конечно, со ссылками на умные книжки, где это более-менее понятным языком изложено). Программировать расчётную часть буду сам, с этим проблем не возникнет.

Это костыль, а не решение. Например, не удастся нормально работать в случае, если нужны разные языки -- не два (английский + какой-нибудь), а больше, т.к. возможности редактора требуют явного указания одного набора символов (кириллицы, например). Случай, конечно, маловероятный на практике, но, тем не менее, показывающий, что это решение -- костыль. Да, лучше костыль, чем вообще ничего, но правильным решением всё равно является полноценное использование Юникода, когда можно с любыми символами вообще работать -- но это требует приличной доработки программ. Кстати говоря, сам по себе ДМС вполне может работать с чем угодно, поскольку и Постгрес, и Жаба, на которых всё это сделано, нормально работают с Юникодом. Если там и нужны корректировки, то небольшие (скажем, в проверке значений параметров -- чтоб за буквы считались не только буквы английского алфавита, а всё, что попадает в эту категорию в Юникоде). А вот программы собственно Экспедишна требуют кардинальной переработки, чтоб всё это нормально работало...

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

Ну, этой проблеме 100 лет в обед, как говорится. В этих ихних америках, похоже, до сих пор 3/4 программистов уверены, что в мире не существует никаких языков вообще, кроме английского :) (стандартный ASCII же в принципе не поддерживает никакие буквы, кроме 26 английских -- т.е. потенциально проблемы у всяких немцев с французами тоже будут, учитывая наличие у них всяких там é и ö).

Если кэшируется содержимое внутренней SRAM, то мало что теряем (а DTCM, как правило, и вовсе никогда не кэшируется, ибо работает со скоростью кэша -- но к ней DMA часто не имеет доступа). А вот если кэшируется внешняя память, особенно какая-нибудь там DDR2+, то кэши очень большой выигрыш дают (из-за большой латентности такой памяти). Кстати говоря, если включить MPU, то можно выделить под ту область, с которой DMA работает, отдельный блок с точки зрения MPU, и при этом назначить ему атрибут "некэшируемый". Тогда, понятно дело, проц не будет соответствующую область памяти кэшировать, а вот остальную -- будет, что представляется наилучшим решением (нет потерь скорости для работы с большей частью памяти и нет проблем с той областью, где надо взаимодействовать с DMA).

Есть, но это создаёт массу проблем с масштабированием системы. Для поддержания когерентности у тех же процов архитектуры IA-32 (в народе -- x86) есть специальная шина для обмена инфой между процами; а обмениваться должны все процы со всеми, поэтому есть предел числа процов, выше которого проблематично подняться технически. А есть и противоположная крайность -- где когерентности нормальной нет даже в рамках одного проца (проц записал команду самому себе для последующего выполнения -- но сам об этом не узнает, если принудительно не очистить кэш команд и очередь предвыборки). Ну и полно промежуточных вариантов с разной степенью удобства для программиста и для железа. Например, в IBMовских мэйнфреймах (хоть Системы 360, появившейся ещё в 1964-м, что у её современных потомоков, выпускаемых вот прям сейчас) проц видит собственные записи в память (за исключением некоторых ограничений, но вполне разумных), однако не видит записи со стороны других процов и канальной подсистемы (грубо говоря, DMA), поэтому там нужно соблюдать определённые правила при написании многопоточных программ (потенциально работающих одновременно на нескольких процах) и при вводе-выводе, но зато можно строить компы с сотнями и тысячами процов -- и всё будет работать. ARMы в этом смысле находятся где-то между совсем "некогерентными" архитектурами и означенными мэйнфреймами: кое-что обеспечивается, но бОльшая часть заботы о когерентности лежит на программисте.

Реально -- не поможет, если на компе, где просматривается pdf, нет этих шрифтов, т.к. внедрять шрифты в сам pdf экспедишновский экспортёр не умеет... Кстати, если память не изменяет, он не умеет и правильно ставить атрибуты символам (не знаю, как точно называется), что те -- кириллические, что тоже проблемы может создавать. Вообще, он ОЧЕНЬ плох, поэтому, если не нужен в обязательном порядке поиск внутри pdf, лучше "печатать" в pdf, а не экспортировать.

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

Можно и чисто вручную всё скопировать, переименовать файлы prj и pcb и изменить внутри этих файлов (они текстовые) их ссылки друг на друга (т.е. чтобы внутри имена соответствовали новым именам этих файлов).

Для этого ТС придётся перелопатить код работы с файловой системой, а я подозреваю, что ему этого делать очень не хочется :)

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

Но если тебе нужны строковые константы в 1251, то проблема-с :)

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

А у меня в ЦБ ничего не задаётся вообще, кроме абсолютно необходимого (вроде Part Number/Name/Label), всё остальное из базы (xDM Server) беру.