Цифровая видеокамера Опции

[Ynicky]

Долго думал и решил создать новую тему.
Полтора года назад мое начальство дало задание проработать проект цифровой видеокамеры,
но потом от него отказалось. А мне это до сих пор не дает покоя.
На тот момент у меня уже был опыт создания SOC (систем на кристалле) на своих процессорах.
Был даже проект векторного 64 разрядного сопроцессора (SIMD). Правда он так и не был реализован в ASIC-е.
С тех пор, занимаясь "плановой" работой, я нахожу немного времени для проекта цифровой видеокамеры.
Уже сделано почти все, кроме вывода изображения на ЖК экран. Но надежда на то, что камера когда-нибудь
будет востребована, с каждым днем "тает". Конечно я понимаю, что это коммерчески не выгодно.
Тягаться с известными зарубежными фирмами, выпускающими видеокамеры, бессмысленно.
Но для души такой проект - то что надо. Даже если он и не будет реализован. Наработанный опыт не
пройдет даром. Мысль о том что проект никому не нужен заставила меня обратиться на форум.
Выложить его, как есть, всем желающим я не могу по причине того, что это собственность предприятия.
Тем более что ассемблер к RISC процессору и векторному сопроцессору написан не мною.
Так вот, чтобы не нарушать коммерческую тайну и право собственности, я решил разработать новый RISC
процессор и векторный сопроцессор к нему в свободное от основной работы время (т.е. дома). Так как
опыт и наработки уже есть, это займет не очень много времени. Их то я (RISC и VCP) и мог бы выложить на форуме.
Проблема только в программном обеспечении. Чтобы быстро отладить процессор и сопроцессор, нужен как минимум
ассемблер с простейшей функцией разделения кода и данных, так как RISC ядро имеет гарвардскую архитектуру.
А как максимум, не мешало бы иметь gcc или binutils для разработки прикладного ПО.
В принципе, написать ассемблер мог бы и я, но тогда это займет много времени и не будет стимула
выкладывать все на форуме, да и заниматься этим. Может найдется среди вас энтузиаст,
который бы взялся хотя бы за ассемблер. Если таких нет, может кто знает к кому обратиться?
"С" компилятор на основе LCC мог бы написать и я в дальнейшем (если не будет gcc или binutils).
Чтобы иметь представление о RISC ядре, выкладываю пока не полное описание.

Николай.

Прикрепленные файлы

 torisc32.pdf ( 94.58 килобайт ) Кол-во скачиваний: 235

 

[x736C]

Чем вас не устраивает готовые открытые RISC процессоры? Средства разработки под них есть.

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

[x736C]

Еще немного почитал о вашем r32core.. И совсем стало понятно. Тут процессор ради камеры, камера ради процессора и куча наработок. Поэтому вопрос снимается.

[des00]

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

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

[DRUID3]

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

Кстати о них - неплохо бы администрации форума сделать раздел для такого рода - некомерческие поекты. Параллельно от "предлагаю работу"...

[des00]

От меня Вы помощи не дождетесь!

Советом помочь это всегда пожалуйста, а вот делом нельзя объять необъятное %)

[asoneofus]

Проект камеры, пользовательской, имеет примерно следующую "разблюдовку" по трудозатратам:
Конечный дизайн 10-15%
- корпусные
- оптика
- компановка
- EU ПО
Комплект разработчика 30-35%
- железяки (включая чипы)
- SDK/DDK
- ПО обработки видео с датчиков
- массштаблёр
- кодеры-декодеры
База - всё остальное(%) от 50%
- ASIC+
- инструментальное ПО, включая модели разных уровней
- базовые фишки в виде оптимизированных библиотек

Всё это вместе, по самым скромным оценкам, стоит от ярда. Экономика невпихуемая.

Теперь по ходу работ, Николай, есть масса вопросов. Непонятна сама система, для чего тот или иной узел нужен в ней. Нет лёгкой модели высокого уровня чтобы проверить, отладить, моделить ...
Т.е. выполнение работ менее чем на %
Можно примкнуть к массе свободных или полусвободных проектов процессоров и на них "зарезать ценник" для достижения цели - потом сделать специализированное ответвление.

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

PS Мой совет: "закопайте" инвестицию и забудьте ... Проект стоящий ярд не сделать за миллион. Чесотку рук можно унять на основном месте работ или в целевой команде как "хобби"

[yes]

А как максимум, не мешало бы иметь gcc или binutils для разработки прикладного ПО.

и как минимум gcc, иначе баловство

какую задачу с использованием VFP можно запрограммировать на асм-е или на чистом C?

-----------------------

вобщем, чем больше хороших проектов, тем лучше.

но на всякий случай:
знаете ли про OpenSPARCT1/T2? btw: DmitryR на опенкоресах SoC проект с таким спарком выложил
ну или LEON3
про камеры: http://www3.elphel.com/ сорцы дают

[Ynicky]

какую задачу с использованием VFP можно запрограммировать на асм-е или на чистом C?

Сделал и отмоделировал кодек JPEG. Управляющую программу написал на С, остальное на асме для VCP.
Полученные результаты можно посмотреть в файле для разных коэффициентов квантования.

Николай.

Прикрепленные файлы

 lady64x64.rar ( 497.9 килобайт ) Кол-во скачиваний: 70

 

[Leka]

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

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

Переменных, массивов, и тп - в выложенной версии нет (есть в версии для софт-процессоров).

Прикрепленные файлы

 asm.zip ( 38.77 килобайт ) Кол-во скачиваний: 40

 

[Ynicky]

Есть в интернете проект процессора XR16.
К нему прилагается исходник ассемблера.
На его основе вполне можно сделать ассемблер почти для любого процессора.
Первая задачка состоит в том, что надо добавить директивы data и text.
И чтобы счетчиков адреса было 2 - один для секции text, а другой для data и bss.
Прилагаю проект ассемблера XR16 с тестовой программкой на асме.
Если решить первую задачку, то остальное уже "дело техники".
Толковому программисту эта задачка на несколько часов.
Настроить затем ассемблер на свой процессор я могу и сам (проходил на ST16).

Николай.

Прикрепленные файлы

 XR16.rar ( 51.24 килобайт ) Кол-во скачиваний: 35

 

[yes]

Сделал и отмоделировал кодек JPEG. Управляющую программу написал на С, остальное на асме для VCP.
Полученные результаты можно посмотреть в файле для разных коэффициентов квантования.

да и я когда-то MJPEG на асме написал - но кому это сейчас надо?

хочу сказать, что нужен С++ компилятор (с полнофункциональным фронтэндом и более-менее разумной оптимизацией) для каких-то коммерческих проектов и использования ядра где-то вне круга энтузиастов.
для энтузиастов есть forth

проблемы написать ассемблер/линкер - я вообще не понимаю, если нету Jump-ов разного размера (спасибо интелу за х86), то вообще табличная перекодировка, ну и через С-шный препроцессор прогнать #define и т.п.
но всегда лучше binutils-ы портировать - все умеют пользоваться, документации полно, ну и утилиты типа objcopy всем нужны

[Leka]

Есть в интернете проект процессора XR16.
К нему прилагается исходник ассемблера.
На его основе вполне можно сделать ассемблер почти для любого процессора.

~1К строк на ЯВУ - можно и программу посложнее ассемблера замутить, например - компилятор "автокода" (~1100 строк на Паскале).
http://electronix.ru/forum/index.php?showt...st&p=605442
На основе личного опыта и предлагаю сразу делать компилятор урезанного ЯВУ(минуя ассемблер), а также оптимизировать ядро под компилятор(а не наоборот).

[Ynicky]

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

С ЯВУ никогда дело не имел, но мысль заманчивая.
С чего начать?

Николай.

[Leka]

Пожалуй, с разбора длинных логических выражений if-else по сокращенной схеме, все остальное проще, имхо.
if( (a==1) && (b==2) || (c==3) && (d==4) )... и тп.

[Leka]

Если увижу смысл в выкладывании исходника "автокода" - выложу. Пока-что никакого смысла не вижу - открытые проекты вне mainstream - не развиваются.

[Leka]

Вот что пришло в голову.

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

Код

// a = b+c*d+e;
int local;
local = c*d;
local += b;
a = local + e;

Длинный if-else упростить без явного использования условных "goto" в общем случае нельзя. Для примера можно взять:
if( (a==1 && b==2 || c==3 && d == 4 ) && ( e == 5 || f == 6) ) { ... } else { ... }

Но если запретить в "урезанном ЯВУ" изменение приоритета "||" и "&&" скобками, то появляется возможность упрощения до "ассемблерного" вида без явного использования условных "goto":

Код

// if( (a & b) == 1 &&  (c & d) == 2 || (e & f) == 3 ) { ... } else { ... }
int local;
if(
  ( local = a & b,
    local == 1 )
&&
  ( local = c & d,
    local == 2 )
||
  ( local = e & f,
    local == 3 )
){
  ...
} else {
  ...
}

Т.о. появляется возможность делать основную компиляцию в рамках ЯВУ:
Си/Паскаль/... --> "ассемблерный" Си/Паскаль/... --> "автокод" (улучшение читабельности) --> машинные коды. Как насчет открытой разработки такой цепочки?

"Автокод" - синтаксис наподобие:

Код

if
  local = a & b
  local == 1
and
  local = c & d
  local == 2
or
  local = e & f
  local == 3
then
  ...
else
  ...
end

Сообщение отредактировал Leka - May 17 2010, 17:52

[Ynicky]

Си/Паскаль/... --> "ассемблерный" Си/Паскаль/... --> "автокод" (улучшение читабельности) --> машинные коды. Как насчет открытой разработки такой цепочки?

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

Николай.

[Leka]

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

Сообщение отредактировал Leka - May 18 2010, 21:04

[Andrey Filippov]

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

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

Андрей

[dinam]

Добрый день, Андрей. Что-то вас давно на форуме не было видно.

[Andrey Filippov]

Добрый день, Андрей. Что-то вас давно на форуме не было видно.

Добрый день. Или ночь - у нас пол-двенадцатого

Наверное, всюду успеть трудно, я и сюда через Referrer Log нашего сайта зашел.

Андрей

[Leka]

Т.о. появляется возможность делать основную компиляцию в рамках ЯВУ:
Си/Паскаль/... --> "ассемблерный" Си/Паскаль/... --> "автокод" (улучшение читабельности) --> машинные коды.

Все-таки есть польза от форума - обратил внимание, что текущий "автокод" очень похож на урезанный Си, в котором:
- отсутствуют типы, все переменные/массивы объявляются, как "static" (большой регистровый файл в памяти),
- только индексная адресация, массивы объявляются через "[ ]",
- упрощенная запись выражений - как в Паскале,
- нет структур, switch (взамен есть if-elsif-...-else).
Так что, пожалуй, выкину "автокод", а компиляцию сделаю с "ассемблерного" подмножества Си. Тогда будет цепочка: подмножество Си --> "ассемблерное" подмножество Си --> машинные коды.

Образец "ассемблерного" Си(кроме "printf") - на примере N-ферзей:

CODE

queens( static N ){
static
count,
arow[20],
aleft[20],
aright[20],
aposs[20],
poss,
place,
val,
pos,
pos1,
N1,
temp,
temp1;

count = 0;
N1= N & 1;
temp = 1 << N;
val = temp - 1;
temp = N >> 1;
poss = val >> temp;
arow[1] = 0;
aleft[1] = 0;
aright[1] = 0;
aposs[1] = poss;
pos = 1;
do{
if( poss != 0 ){
temp = -poss;
place = poss & temp;
temp = ~place;
poss = poss & temp;
if( pos == N1 && poss == 0 ){
count = count << 1;
}
if( pos != N ){
pos1 = pos + 1;
aposs[pos] = poss;
temp = arow[pos];
temp = temp | place;
arow[pos1] = temp;
temp = aleft[pos];
temp = temp | place;
temp = temp << 1;
aleft[pos1] = temp;
temp = aright[pos];
temp = temp | place;
temp = temp >> 1;
aright[pos1] = temp;
temp = arow[pos1];
temp1 = aleft[pos1];
temp = temp | temp1;
temp1 = aright[pos1];
temp = temp | temp1;
temp = ~temp;
temp = temp & val;
poss = temp;
pos = pos1;
}else{
count = count + 1;
}
}else{
pos = pos - 1;
poss = aposs[pos];
}
}while( pos != 0 );
if( N1 == 0 ){
count = count << 1;
}
return count;
}

main(){
static N;
for(N = 1; N < 15; N = N + 1){
printf("queens(%d)=%d \n", N, queens(N));
}
}

В "ассемблерном" подмножестве нет длинных выражений --> непосредственно транслируются в 3x-операндные машинные коды.

Предлагаю открытый проект софт-процессора с большим регистровым файлом в памяти(c Гарвардской архитектурой - Циклоны/Спартаны дадут ~100MIPS). Мне он не нужен(есть свой), но интересует развитие идеи компиляции в рамках ЯВУ(когда промежуточным языком является подмножество ЯВУ), и под этот проект готов взять на себя открытый компилятор с "ассемблерного" Си.

Сообщение отредактировал Omen_13 - Jun 1 2010, 19:26

Причина редактирования: Оформление кода

[Ynicky]

Предлагаю открытый проект софт-процессора с большим регистровым файлом в памяти(c Гарвардской архитектурой - Циклоны/Спартаны дадут ~100MIPS). Мне он не нужен(есть свой), но интересует развитие идеи компиляции в рамках ЯВУ(когда промежуточным языком является подмножество ЯВУ), и под этот проект готов взять на себя открытый компилятор с "ассемблерного" Си.

Замечательно!
Какого объема нужен регистровый файл?
PS. Может перейти в тему "Свои процессоры".

Николай.

[yes]

пока не перешли в свои процессоры...

про язык LISA кто-нибудь знает?
http://en.wikipedia.org/wiki/Language_for_...et_Architecture

ну и тулзы, которые синтезят процессор и софт(компилер, либы) для него
http://www.synopsys.com/Tools/SLD/Processo...es/default.aspx
бывший coware (софт есть в известном месте)
я сам не сталкивался - может кто-то расскажет, что там

[Leka]

Какого объема нужен регистровый файл?
PS. Может перейти в тему "Свои процессоры".

При большом регистровом файле константы удобно брать из регистров, а не из команды. Массивы - в отдельной памяти. Поэтому желаемое число регистров = число статических переменных + число констант.
Для Фон-Неймановской архитектуры логично все локальные переменные нерекурсивных(нереентрабельных) функций делать статическими - код все-равно занимает в разы больше места. Чем больше окно регистрового файла, тем лучше. У меня 1К при 36-разрядном коде: 6 бит - код операции, 30 бит - 3 операнда. Неиспользуемые регистры м/б заняты командами/данными(массивами). Для Гарвардской архитектуры лишние регистры никак не используются, но все-равно лучше взять по-максимуму (урезать проще, чем нарастить).

Можно продолжить в "Свои процессоры".

У меня отлаженная Фон-Неймановская архитектура(2 такта на инструкцию при ~100МГц), и незаконченная переределка на Гарвардскую(1 такт на инструкцию, кроме переходов) - задача отошла на задний план. Активное участие обещаю только в разработке компилятора (устрою перерывчик себе в "синтезе программ", а то "тихо шифером шурша, ...").

[Ynicky]

Уже прикинул архитектуру с большим регистровым файлом (2К).
Делаю краткое описание. В выходные выложу в другой теме.
Тогда можно будет говорить более предметно.

Николай.

[Leka]

В понедельник посмотрю.

[ArtemDement]

да и я когда-то MJPEG на асме написал - но кому это сейчас надо?

А что за проект, если не секрет ? Если Вам не надо, то можно взглянуть на реализацию ?

[yes]

А что за проект, если не секрет ? Если Вам не надо, то можно взглянуть на реализацию ?

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

[ArtemDement]

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

А насколько ресурсоемкий код получился ?

Разброс у семейства Blackfin большой - от ADSP-BF592 за 2$ до ADSP-BF535 за 32$.

[yes]

А насколько ресурсоемкий код получился ?

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

у аналога есть (был) индустский код кодера/декора со внешней памятью, но с характеристиками получше - то есть они его давали бесплатно, я его на BF533 "изиките" запускал

---------------

BTW: BF535 не значит, что лучше 592 , это самый древний камень, с большим количеством глюков. семейство 533/532/531 было вторым в них уже глюков поменьше, каких-то критических как в 535 я не встречал, да и ревизии чипов они активно делали - по паре за год