Ghost2

Используем для обработки в радиолокаторе С6678. Проц - супермощный. Брали восьмиядерный именно исходя из предыдущего опыта ЦОС на ADSP-21469. Рассчитывали задействовать 4+ ядра, но все работает на одном и при этом не вылезает за 30% загрузку. ISA у ядер С66x гораздо лучше заточена для ЦОС, чем у AD. Проблемы: 1. Нужно отводить тепло, т.к. печка пипец. Даже когда на него просто подано питание жрет 7 Вт. 2. На морозе нужно греть. Ниже -40 загружается нестабильно. Поэтому греем транзистором до -40, а дальше он нормально грузится. 3. Документация. Ее тонны, информация размазана по даташитам, поэтому представить картину целиком бывает непросто. 4. Куча ошибок в даташитах, которые не исправляются годами. В одном только EMIF наткнулись на 3 ошибки. 5. Если не собираетесь использовать драйверы и ОС от TI, приготовьтесь к мукам. Периферия реально сложная, а в документации бывает написано что-то типа "не пытайтесь это запрограммировать, используйте наш драйвер". Нас спасло то, что како-то продвинутой функциональности от нее не требовалось. 6. Если собираетесь использовать драйверы и ОС от TI, приготовьтесь к глазному кровотечению. Код реально писали индусы с целью повышения WTF per minute по всему миру. Проект не серийный, 5 штук только изготовили. В продолжении проекта (который, надеюсь, станет серийным) наверное будем брать Keystone II (66AK2H06 или 66AK2L06).

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

fopen, fread, fclose думаю хватит

С непредсказуемыми глюками компилятора не сталкивался. Сталкивался с несоответствиями стандарту С/С++ в плане вычислений на этапе компиляции и жизни "до main".

А откуда ей, собственно, взяться?

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

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

Может typedef поможет.

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

Хочется создать примерно такую систему из 4-х TigerSHARC TS201: Вполне возможно, что программа у всех будет одинаковая, а разбираться кто что делает они будут при помощи сообщений от главного процессора. Host может шарить с первым в цепочке процессором память. И тут возникает большой вопрос - как загрузить оторванные от шины процессоры? Ни один из описанных у ADI методов напрямую не подходит. Модификация boot kernel немного пугает. Какие вообще возможны способы загрузки такой системы? Очень хотелось бы прошивать все (включая host) с одной "розетки". PS. Извините, если что-нибудь непонятно.

>Как сделать, чтобы выравнивание при доступе к элементам структуры было правильным? Располагать поля нужно по увеличению размера. Но даже в этом случае адрес следующей структуры будет выровнен на 4 байта.

С.З. Кузьмин. Основы проектирования систем цифровой обработки радиолокационной информации. Это азбука. Погуглив по ней можно айти все остальное. Из зарубежных: Yaakov Bar-Shalom. Estimation with Applications to Tracking and Navigation.

Спектр периодический - высокочастотные гармоники на самом деле совсем не высокочастотные, просто частота через pi перевалила. Для получения нормальной картинки можно воспользоваться функцией fftshift. Получится, что частоты теперь идут от -pi до pi. Реальную ось частот можно вычислить так: % N - количество отсчетов. % T - время наблюдения. f=(-N/2:N/2-1)*1/T; PS. А лучше использовать fft - вторым аргументом можно добить последовательность нулями и получить большее разрешение (на пилу как-то неудобно смотреть).

А зачем typedef? Можно просто /** foo.h */ struct foo { int i; }; extern foo foo_var; /** foo.cpp */ #include <foo.h> foo foo_var;

Универсалы рулят, когда нужно много ковыряться в данных. А вот если нужно получить хорошую пропускную способность или обрабатывать большие потоки данных (радиолокация например), то для этого только DSP. Вот, кстати, боян от AD. Еще вопрос с условиями эксплуатации. Высокие частоты и современные типы памяти - это не всегда можно (в авиации точно). А на частотах TS201 любой универсал ему проиграет. PS. Еще не знаю насчет ЭМС.