Dizel

рентабельность? А вы знаете чего сподвигло Elvees свой проц сделать? Может это их система Оруэл2K и сподвигла. Т.е. они не продают процессор - они продают системы видионаблюдения. А процессор - так, побочный продукт. Просто видимо этот Оруэл пахнет госзаказом (как с NeuroMatrix-ом к примеру) Вон камеры от НТЦ Модуль по всей Москве висят - видимо при такой серийности выгоднее было сделать свой процессор, либо ограничение на используемую номенклатуру изначально в госзаказе. Поверьте мне, сделать процессор это не такая уж и непосильная задача - 3 года работы коллектива в человек 10-15. Ну на софт еще человек 20. Дорогой готовый модуль на основе - это и есть их Оруэл 2K. Ну вот этот еще есть этот http://www.insys.ru/dsp/adp24pci.htm - но это видимо нишевое изделие для тех военных заказов которые не смогли пробить себе импортную номенклатуру. Т.е. здесь деньги зарабатывает скорее ИнСис, а не Элвис. Про дефекты это вы сильно загнули - вы первый блэкфины от АД наверное в руках не держали? Странно, но некто АД не пытался за это штрафовать :)

Ну и еще туда же можно добавить AMCC PPC440GX с гигабитным ethernet-ом на борту и TCP/IP Acceleration http://www.amcc.com/MyAMCC/jsp/public/prod...ductID=PPC440GX

Иксы к примеру висят на 6000 порте. А вообще cat /etc/services - там довольно много портов > 5000. Состояние портов можно глянуть с помощью netstat -a

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

1. OS_TASK_IDLE_STK_SIZE - это размер стэка для задачи IDLE, задачи которая есть всегда и выполняется во-время отсутсвия в очереди других процессов на выполнение. Строка OSTaskStkSize = OS_TASK_IDLE_STK_SIZE следовательно означает, что у вашего таска будет такой же размер стэка, что и у задачи IDLE. Скорее всего после OSInit() в вашем примере следует строка OSTaskCreate() в которую передается OSTaskStkSize в качестве параметра. Я предпологаю, что OSTaskStkSizeHard = OS_TASK_IDLE_STK_SIZE_HARD определяет тотже параметр, только для систем жесткого реального времени (возможно UCOS-II имеет какой-то дефайн для работы в режиме HARD REALTIME) 2-3. Как написано в книге OSInit() создает два таска (который IDLE, и для сбора статистики) , OSStart() запускает диспетчер. Я думаю инициализацию МК можно сделать и до OS_Init(), но вот прерывания нужно разрешить до OS_Start(), т.к. после операционка улетит на диспетчер. 4. Проще оставить тот ISR на ассмеблере добавив туда call на ф-ию на Си, и в этой ф-ии осуществить всю необходимую логику для обработки прерывания...

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

Вопрос в тему уважаемому QNX-гуру Olej: в QNX, если я ничего не путаю, в user-space приложение можно вставить все что душе угодно: обработчик прерывания, работу с портами ввода/вывода. Соответственно если воткнуть работу с сопроцессором прямо в прерывание что произойдет? т.е. она сохраняет контекст FPU перед входом в прерывание? Это я к тому, что может человеку проще QNX взять....

Эта брошурка (LKMPG) в каком виде только не существует... Только ИМХО старовата.... http://www.opennet.ru/docs/RUS/lkmpg/ http://oopweb.com/OS/Documents/LKMPG/Volum...ume/node11.html

Если уж на то пошло, то лучше сразу взять 3-ье издание... Ибо про 2.6, и многие на него уже перешли окончательно... Темболее там немного поменялось API, и если уж учить так сразу новое. http://lwn.net/Kernel/LDD3/

Нельзя там в ядре floating point http://www.ussg.iu.edu/hypermail/linux/ker...107.0/0757.html Нужно всю float point часть перенести на уровень приложения, которое к примеру все время будет весеть на драйвере с помощью select(). Т.е. оперативно реагировать на любые изм. в статусе железа, чего-то там считать и отдавать обратно железу. Или (если FP нужна в обработчике, к примеру, прерывания, или там для моментальной генерации управляющего воздействия во внешнюю среду) то можно нагородить эмуляцию на целых числах, которая возможно даже окажется быстрее (осбенно если заменить всякие синусы таблицами) Это будет проще чем заморачиваться с FPU. Думаю, советы были бы более дельными если вы описали как и где ваш драйвер должен считать.

В мск к сожалению....

Ну я вот занимаюсь... dizel5 <собака> mail.ru

Да, RTEMS - это весьма занятно. Собираюсь попробывать. Благодаря вам и узнал о ней. Спасибо.

Посмотрите здесь. http://tech-www.informatik.uni-hamburg.de/.../models/i80386/

Я тоже не считаю x86-архитектуру полноценной... И что с того? По части выбора процессора для встроенных применений для меня наверное важными являются эти факторы 1) Наличие нормального (оптимизирующего на приемлимом уровне) си-компилятор (gcc или платного, но лучше gcc). А ведь gcc далеко не на всех архитектурах генерит хороший код. Например, для blackfin он сильно уступает VDSP. 2) Работающий порт линукса Кстати этим двум параметрам x86 удовлетворяет более чем. Ну да ладно, не об этом речь. Так вот, спрашиваю как у LEON-а со всем этим? Удалось ли на самостоятельно сделанной плате с FPGA запихнуть этот ЛЕОН и раскрутить на нем линукс? Хм... А доделанные процы бывают? Что, х86 доделанный что ли? Это как доделанные программы. Вы их много знаете? <{POST_SNAPBACK}>