Vitaliy_ARM

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

Хорошо. Есть еще пара вопросов. Вы его на других ПЛИС пробовали? Если да, то как он себя ведет после компиляции (размер кода, тактовая частота)?

Еще и дешевле раз в 5

Раз так дело идет, может еще и JTAG сделаете :)

Класс! :)

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

Очень неплохо было бы посмотреть сигналы каким-нибудь осциллографом. Причем это надо сделать обязятельно! Хотя бы убедиться в том, что шина работает по спецификации. Скорее всего фаза не важна, если логика фпга тактируется хотя бы частотой процессора. Для таких вещей наиболее подходит LPC2468 если повесить к нему ФПГА через SDRAM контроллер.

А у вашей FPGA ФАПЧ'а случаем нету?

Простите за тупой вопрос. А откуда эти коэффициенты брать?

То же про MCI: страница 404 юзермануала: Clock Control Register (MCIClock - 0xE008 C004) Bypass Enable bypass of clock divide logic: 0 0 Disable bypass. 1 Enable bypass. MCLK driven to card bus output (MCICLK). Так что вроде можно выдать на MCICLK тактовую процессора

Ну тогда автору :a14: . Еще бы отладку сделать и будет блеск. Opencor'ный авр отдыхает. А кто-нибудь это ядро уже использует? Есть ли нюансы

Да потому что они скорее всего кривые и не по спецификации! Посадил как-то Lattice на LPC2468 на асинхронную шину и мучался потом две недели, пока не нашел, что шина работает не корректно, потом подкрутил прошивку и заработало. Где-то на форуме выкладывал осциллограммы. Наверняка и в 78-м может быть что-то подобное. На счет тактовой посмотрите, в MCI модуле вроде была возможность выдачи на ножку частоты.

Скомпилировал недавно opencore AVR на VHDL, получилось около 44 МГц при 3400 логических ячейках на самом маленьком втором циклоне. А какая у вас тактовая частота получилась?

Раз уж такое руководство, тогда дайте им MicroBlaze или NIOS.

Уже два дня как лежит даташит на новый процессор. http://www.nxp.com/search/?query=lpc17xx МТ-Систем обещает, что где-то в октябре появятся образцы :yeah:

Может бросите ссылку на исходники этого университета. И еще один нескромный вопрос, кто нибудь с MJPEG работал? Уже неделю не могу нормальной доки найти. Судя по тому что нашел он очень просто делается из JPEG-ов, но как при это формируется файл видео?

Есть плата BF-537EZKIT LITE (если не ошибаюсь она же STAMP) Потихоньку осваиваю этот блекфин и решил переползти на микролинукс. Опыт программирования процессоров под gcc неплохой. Вопрос такой. С чего и как начинать изучение линукса, дабы ускорить процесс? Если возможно, разложите по порядку (устроит все, ссылки, доки)

Отстой редкостный

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

Это обычный интел совместимый проц. Берете схему демоплаты и собираете комп. Потом ставите на него операционку типа виновс XP и запускаете на нем что хотите (п.с. сам пробовал)

Вот решил создать отдельную тему. Работаю с процессором недавно. Написал драйвер для своего самописного стека. Функции драйвера: int Init(BYTE *pMacAddr); int CheckRx(); int TxData(DWORD *Buf, DWORD Len); int RxData(DWORD **Buf, DWORD *Len); Пока DMA настроен так: DMA передатчика работает в режиме массива дескрипторов и отправляет только один буфер. DMA приемника работает в режиме больших списков, и имеет некоторый кольцевой буфер. Функция CheckRx() определяет наличие принятого пакета по полю Status в дескрипторе вот так: int bfEmac::CheckRx(void) { if((RxDescBuf[RxConsumeIndex].StatusWord & RX_COMP) !=0) if(RxDescBuf[RxConsumeIndex].StatusWord & RX_OK) return 0; // Возвращаем 0, если пакет принят return -1; } Функция приема RxData() после обработки пакета инкрементирует RxConsumeIndex (который не может быть больше количества дескрипторов). И возвращает указатель на принятый буфер и его длину. Проблема: работает только тогда, когда один приемный дескриптор. Если дескрипторов больше одного, начинаются глюки, причем такие, как будто дма по списку не в перед идет, а назад, хотя по смыслу такого не может быть. Если кто уже писал что-то подобное, посоветуйте, как сделать корректное обнаружение принятого пакета. Привожу так же функцию приема: int bfEmac::RxData(DWORD **Buf, DWORD *Len) { // определяем указатель на принятый буфер pETH_FRAME_BUFFER pRxEframe = (pETH_FRAME_BUFFER)RxBuf[RxConsumeIndex]; // возвращаем указатель и длину принятых данных *Buf = (DWORD*)pRxEframe->Dest; *Len = ((RxDescBuf[RxConsumeIndex].StatusWord) & 0x7FF) + 2; // обнуляем статус (без этой операции дма не станет больше писать в этот буфер) RxDescBuf[RxConsumeIndex].StatusWord = 0; // инкрементируем смещение в массиве дескрипторов ++RxConsumeIndex; if(RxConsumeIndex >= RX_BUF_NUM) RxConsumeIndex = 0; return 0; }

Что за баг? На резвизию 3 не нашел ничего встающего колом

Или скачайте виртуальный PDF принтер с интернета (гугл находит целую кучу). А дальше печатайте как на обычном принтере

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

Для этого блек фин изучаю :) , неплохая ссылка Даже и смотреть не стоит. Эта не камера, а металлолом. Очень плохое качество.