Перейти к содержанию
Поиск
    

Vitaliy_ARM

Свой
 Профиль  Обзор контента

  • Постов

    508

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные Vitaliy_ARM

  1. Опубликовано · Пожаловаться

    Дабы ограничить размер топика :biggrin: , дарю - http://electronix.ru/forum/index.php?showtopic=49195

     

    Ваш проект заслуживает уважения.

    Еще пока не совсем разобрался оцифровкой изображения, как я понимаю TDA8708A может цифрануть только чернобелое изображение. Можете ткнуть на АЦП для цветного, если есть? Или надо самому городить демодулятор цвета?

  2. Опубликовано · Пожаловаться

    Нужно получить 1.5-2 Мбайта/с используя tcp на lpc2378 так чтобы осталось время на другие задачи(требуется собирать данные с двух устройств по двум ком портам используя несложный протокол и отправлять их по сети в PC, иметь небольшой веб сервер для настройки устройств и доступ по фтп к файлам с настройками). Используя операционку от micrium и их стек tcp/ip можно получить такие скорости? Или стоит взять проц мощнее?можно выбирать только из lpc2378 или аt91sam92600.

     

    Вашу задачу решить можно. У меня сейчас утсройство работает на 30 Мбит/с по UDP, при загрузке процессора 30% (частота ядра 60 МГц) (поток в одну сторону). Причем раскачивал до 70 Мбит.

    Сразу говорю - порты uIP в примерах IAR не берите за основу, они просто кошмарно неоптимальны!

    Портируйте сами или пишите конкретно под этот процессор свой стек. Просматривая uIP, в принципе если его немного переписать, то можно увеличить скорость в несколько раз на этом ARMе.

  3. Опубликовано · Пожаловаться

    А нафига? Ещё и драйвер переписывать EE-315

    http://www.analog.com/processors/blackfin/...otes/index.html

     

    Я драйвер на арме уже под 2 мака написал. Хотел узнать, нет ли подводных камней. KSZ8001 мне больше нравится. И стек самописный есть. К сожалению он на блекфин не совсем хорошо ложится, если использовать линейные списки DMA, а вот с массивом дескрипторов было бы ок.

  4. Опубликовано · Изменено пользователем Vitaliy_ARM · Пожаловаться

    Для BF537+100Mbit Ethernet, если верить Ethereal, 102.7 MBit/s:

     

    Стек самодельный..

     

    Интересно, чето он там насчитал. Попробуйте в Shark проверить (улучшенный изреал).

     

    Сейчас разбираюсь с BF537 EZKIT. Там стоит какой-то грамоздкий PHY, который в примерах работает по MII. А кто-нибудь к блекфину цеплял что-то вроде KSZ8001 по RMII?

     

    И раз уж про сети заговорили, можно ли DMA для EMAC использовать в режиме массива дескрипторов?

  5. Опубликовано · Пожаловаться

    Недавно тестил передачу и приём пакетов UDP между BF-537, TMS320C6455 и PC:

    ADSP-BF537 -> PC = 51 Mbit/s

    PC -> ADSP-BF537 = 38 Mbit/s

    Такие же скорости получил и при связывании TMS с BlackFin-ом.

     

    TMS -> PC ~ 95 Mbit/s (быстрее, виндовый стек начинает терять пакеты)

    PC -> TMS ~ 69 Mbit/s (винда почему-то не захотела передавать быстрее)

     

    TMS c TMS все 100 Mbit/s

     

    Очень хотелось бы упочитать коментарии тех кто тестировал.

    P.S.: передавал пакеты по 1472 байта (далее виндовый стек начинает фрагментацию, а LwIP и NDK не поддерживают, вроде как, фрагментацию при использовании UDP), следил за содержанием пакетов и колличеством принятых, соединял кроссовым кабелем и через свич.

     

    А что вы за стек использовали?

     

    Я на оптимизированном самописном стеке для ARM7 LPC2378 ради эксперимента выжимал от процессора к ПК 70 МБит, при загрузке процессора 70%. Думаю, что на блекфине можно без проблем передать больше 100 МБит (жаль нет аппаратной поддержки гигабитных PHY)

  8. Опубликовано · Изменено пользователем Vitaliy_ARM · Пожаловаться

    Да почему же тушить? Вся сеть не встанет на 100 мегабит из-за отдельных устройств.

    Поставьте свич с 1 гигабитным портом и N 100 мегабитными.

     

    Не знал про это. Это выход!

    А что за свичи такие 1000 ->100? Встречал только либо 1000 либо 100.

  9. Опубликовано · Изменено пользователем Vitaliy_ARM · Пожаловаться

    К DSP какие требования?

     

    Почти никаких, они дешевле (например блекфины) и пошустрее в разы в отличии от ARM9.Главное расчкачать гигабитный изернет.

     

    А зачем Gigabit, если только 30Mbit нужно?

    Gigabit MAC есть у TMS320DM6455, 100Mbit - у младших 64-х.

     

    Сеть, где работает устройство гигабитная и тушить ее 100 мегабитами не хотелось бы, в ней еще куча компов сидит. К тому же устройств будет около 5,

    поэтому ширины 100 мегабит недостаточно.

    TMS320DM6455 дороговат, хочу найти что-то в районе 20-30 баксов

  10. Опубликовано · Пожаловаться

    Нужно поднять такую систему. Реально нужно передавать до 30 МБит по UDP.

    Подскажите какой процессор и PHY можно применить, чтобы было как можно дешевле.

     

    Пока смотрю в сторону блекфина.

  11. Опубликовано · Пожаловаться

    PS: VS6724 мне понравилась, жаль раньше не видел. И дока подробная.

     

    Для полного счастья не хватает примеров работы. Нашел только какие-то обрывки кода для получения данных на STR9... Жудко нехороший процессор

  14. Опубликовано · Пожаловаться

    Очинь апасна fear.gif

     

    Но все же, если не секрет, для чего такое разрешение?

    Эти все поделки на армах и камерах идут, в основном, в системы наблюдения, видеофоны всякие.

    А ваше разрешение подразумевает нечто монструозное. Неужели фотоаппарат? :biggrin:

     

     

    Не совсем секрет. Устройство, очень похожее на хороший фотоаппарат. Ничего монстроузорного в 2 Мпикселях нет.

  15. Опубликовано · Пожаловаться

    А Вам обязательно такое разрешение? Имейте в виду, что понадобится ОЗУ для хранения всего кадра, и время упаковки растет пропорционально площади изображения (единица измерения - пиксель^2) - так что картинка с такой камеры будет жаться не 4, а 100 миллионов тактов (это чб, с цветом - в полтора-два раза дольше, как выберете).

     

    Рекомендую, кстати, искать камеру, которая умеет сразу выдавать YUV, а не RGB - минус матрицирование, тоже требующая времени операция.

     

     

    Собственно озу предолагалось метров на 64. Теперь буду думать над оптимизацией.

  16. Опубликовано · Пожаловаться

    Ну, IAR-то уж во всяком случае не виноват. Или области памяти накладываются, или память глючит, если внешняя.

     

     

    Процессор LPC2468. Flash находнится в диапазоне адресов 0X00000000 - 0X0007DFFF. Все правильно.

    Считаю CRC нескольких страниц внутренней флеши (никаких ремапов нет).

  17. Опубликовано · Пожаловаться

    События развиваются так быстро, что не успеваю переваривать. :)

     

    Может тогда осветить вопрос наиболее подходящих камер для подобных проектов?

     

    Выкладываю даташит на одну из них.

    LZ0P39HA_SPECIFICATIONS_20071108.part1.rar

    LZ0P39HA_SPECIFICATIONS_20071108.part2.rar

  18. Опубликовано · Пожаловаться

    Написал стандартную функцию табличного вычисления CRC32.

     

    const DWORD CrcTable[256] = {
0x400C0000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, 0xE963A535,
0x9E6495A3, 0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988, 0x09B64C2B, 0x7EB17CBD,
0xE7B82D07, 0x90BF1D91, 0x1DB71064, 0x6AB020F2, 0xF3B97148, 0x84BE41DE, 0x1ADAD47D,
0x6DDDE4EB, 0xF4D4B551, 0x83D385C7, 0x136C9856, 0x646BA8C0, 0xFD62F97A, 0x8A65C9EC,
0x14015C4F, 0x63066CD9, 0xFA0F3D63, 0x8D080DF5, 0x3B6E20C8, 0x4C69105E, 0xD56041E4,
0xA2677172, 0x3C03E4D1, 0x4B04D447, 0xD20D85FD, 0xA50AB56B, 0x35B5A8FA, 0x42B2986C,
0xDBBBC9D6, 0xACBCF940, 0x32D86CE3, 0x45DF5C75, 0xDCD60DCF, 0xABD13D59, 0x26D930AC,
0x51DE003A, 0xC8D75180, 0xBFD06116, 0x21B4F4B5, 0x56B3C423, 0xCFBA9599, 0xB8BDA50F,
0x2802B89E, 0x5F058808, 0xC60CD9B2, 0xB10BE924, 0x2F6F7C87, 0x58684C11, 0xC1611DAB,
0xB6662D3D, 0x76DC4190, 0x01DB7106, 0x98D220BC, 0xEFD5102A, 0x71B18589, 0x06B6B51F,
0x9FBFE4A5, 0xE8B8D433, 0x7807C9A2, 0x0F00F934, 0x9609A88E, 0xE10E9818, 0x7F6A0DBB,
0x086D3D2D, 0x91646C97, 0xE6635C01, 0x6B6B51F4, 0x1C6C6162, 0x856530D8, 0xF262004E,
0x6C0695ED, 0x1B01A57B, 0x8208F4C1, 0xF50FC457, 0x65B0D9C6, 0x12B7E950, 0x8BBEB8EA,
0xFCB9887C, 0x62DD1DDF, 0x15DA2D49, 0x8CD37CF3, 0xFBD44C65, 0x4DB26158, 0x3AB551CE,
0xA3BC0074, 0xD4BB30A2, 0x4ADFA541, 0x3DD895D7, 0xA4D1C46D, 0xD3D6F4FB, 0x4369E96A,
0x346ED9FC, 0xAD678846, 0xDA60B8D0, 0x44042D73, 0x33031DE5, 0xAA0A4C5F, 0xDD0D7CC9,
0x5005713C, 0x270241AA, 0xBE0B1010, 0xC90C2041, 0x5768B525, 0x206F85B3, 0xB966D409,
0xCE61E49F, 0x5EDEF90E, 0x29D9C998, 0xB0D09822, 0xC7D7A8B4, 0x59B33D17, 0x2EB40D81,
0xB7BD5C3B, 0xC0BA6CAD, 0xEDB88320, 0x9ABFB3B6, 0x03B6E20C, 0x74B1D29A, 0xEAD54739,
0x9DD277AF, 0x04DB2615, 0x73DC1683, 0xE3630B12, 0x94643B84, 0x0D6D6A3E, 0x7A6A5AA8,
0xE40ECF0B, 0x9309FF9D, 0x0A00AE27, 0x7D079EB1, 0xF00F9344, 0x8708A3D2, 0x1E01F268,
0x6906C2FE, 0xF762575D, 0x806567CB, 0x196C3671, 0x6E6B06E7, 0xFED41B76, 0x89D32BE0,
0x10DA7A5A, 0x67DD4ACC, 0xF9B9DF6F, 0x8EBEEFF9, 0x17B7BE43, 0x60B08ED5, 0xD6D6A3E8,
0xA1D1937E, 0x38D8C2C4, 0x4FDFF252, 0xD1BB67F1, 0xA6BC5767, 0x3FB506DD, 0x48B2364B,
0xD80D2BDA, 0xAF0A1B4C, 0x36034AF6, 0x41047A60, 0xDF60EFC3, 0xA867DF55, 0x316E8EEF,
0x4669BE79, 0xCB61B38C, 0xBC66831A, 0x256FD2A0, 0x5268E236, 0xCC0C7795, 0xBB0B4703,
0x220216B9, 0x5505262F, 0xC5BA3BBE, 0xB2BD0B28, 0x2BB45A92, 0x5CB36A04, 0xC2D7FFA7,
0xB5D0CF31, 0x2CD99E8B, 0x5BDEAE1D, 0x9B64C2B0, 0xEC63F226, 0x756AA39C, 0x026D930A,
0x9C0906A9, 0xEB0E363F, 0x72076785, 0x05005713, 0x95BF4A82, 0xE2B87A14, 0x7BB12BAE,
0x0CB61B38, 0x92D28E9B, 0xE5D5BE0D, 0x7CDCEFB7, 0x0BDBDF21, 0x86D3D2D4, 0xF1D4E242,
0x68DDB3F8, 0x1FDA836E, 0x81BE16CD, 0xF6B9265B, 0x6FB077E1, 0x18B74777, 0x88085AE6,
0xFF0F6A70, 0x66063BCA, 0x11010B5C, 0x8F659EFF, 0xF862AE69, 0x616BFFD3, 0x166CCF45,
0xA00AE278, 0xD70DD2EE, 0x4E048354, 0x3903B3C2, 0xA7672661, 0xD06016F7, 0x4969474D,
0x3E6E77DB, 0xAED16A4A, 0xD9D65ADC, 0x40DF0B66, 0x37D83BF0, 0xA9BCAE53, 0xDEBB9EC5,
0x47B2CF7F, 0x30B5FFE9, 0xBDBDF21C, 0xCABAC28A, 0x53B39330, 0x24B4A3A6, 0xBAD03605,
0xCDD70693, 0x54DE5729, 0x23D967BF, 0xB3667A2E, 0xC4614AB8, 0x5D681B02, 0x2A6F2B94,
0xB40BBE37, 0xC30C8EA1, 0x5A05DF1B, 0x2D02EF8D
};

DWORD Crc32(BYTE *Buf, DWORD len)
{
    DWORD Crc;

    Crc = 0xFFFFFFFFUL;    
      for(int i=0; i<len; i++)
      {
        Crc = (DWORD)((CrcTable[((BYTE)(Crc)) ^ *Buf++])^((Crc >> 8)));
      }
    return (Crc^0xFFFFFFFF);
};

     

    При рачете нескольких байт, например до 100 штук, работает нормально.

     

    Если рассчитывать несколько килобайт, получается все время разное значение CRC.

     

    Вызываю функцию так:

     dCrc32 = Crc32((BYTE*)0x8000, 0x0006FFFCUL);

     

    Не могу разобраться, перепробовал кучу вариантов. На ПК работает функция без проблем, в процессоре же не работает. Перепробовал компиляторы как C так и C++. Результат один и тот же.

     

    В чем может быть дело, кто виноват, я или IAR?

  21. Опубликовано · Пожаловаться

    Спасибо всем откликнувшимся!

    Почитал топик и решил попробовать LPC2468 + 3*AD1871.

     

    Устройство будет использоваться и для записи и для проигрывания записей, поэтому нужно ли использовать ОС или можно обойтись библиотеками для файловой системы и USB?

     

    USB flash будет съёмной, для переноса файлов на другие компы, поэтому для универсальности от MMC/SD/microSD карт придётся отказаться.

     

    Обычно оценивается так, если при установке ОС вы сделаете это быстрее и работать оно будет так же, то используйте. Если нет, тогда пишите сами :) . До сих пор обходился без осей с тем же успехом. Ваше устройсво не такое сложное, а вот процессор скорее всего и без оси будет работать на пределе. Думаю что ось использовать не стоит.

  22. Опубликовано · Изменено пользователем Vitaliy_ARM · Пожаловаться

    USB Host'а на борту нет, как и интерфейсов к карточкам. Вот если подождать, пока выпустят ADSP-BF54x...

     

    Можно глянуть в нетоптанные степи на этом форуме, Marvell Orion. Сильно не вдавался в подробности,

    но вроде как есть в свободном полете все средства программирования, интегрированные в Eclipse. Цену обещали представители от 15$

     

    http://electronix.ru/forum/index.php?showtopic=45557

  23. Опубликовано · Пожаловаться

    У меня одна система была построена на двухканальном кодеке PCM3002 и LPC2148, диапазон частот - тот же. Но не записывал, а передавал на комп через юсб. Подключил на SSP, синхронизировал 48 КГЦ от внешнего генератора - делил на таймере/счетчике, чтобы получить сигналы переключения каналов. Но - производительность не очень, лучше брать процессоры с встроенным I2S. Если магнитофон - и будет воспроизведение - то кодек лучше - он и АЦП и ЦАП. На 6 каналов - не знаю, в LPC2368 один I2S, т.е. 2 канала, как запараллелить - может кто поделится идеей?

     

    Можно проц, если не арм, взять к примеру BlackFin. Он точно с этой задачей справится и стоит не дорого

  24. Опубликовано · Пожаловаться

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

     

    :a14: Точно! Как я сразу не догадался. Спасибо за ответы

  25. Опубликовано · Пожаловаться

    Объект состоит только из данных. Когда вы обращаетесть к функции-члену, то компилятор по имени объекта определяет, какую именно из функций надо вызвать. Поэтому каждая (невстраиваимая) функция-член встречается в коде ровно один раз. Если это унаследованная функция для данного класса, то будет вызвана функция базового класса. Поэтому накладных расходов по коду при наследовании нет никаких.

     

    Единственные накладные расходы, которые могут возникнуть - по памяти данных на архитектурах с выравниванием. Размер struct a_t будет округлен в бОльую сторону до параметра выравнивания (чтобы если из них сделать массив, следующий элемент оказался выровненным), и это округление может оставить пустое место между data_a и data_b в b.

     

    Отлично. Получается можно использовать преимущества ОПП и при этом размер кода практически не увеличивается.

    Задам последний вопрос на отвлеченную тему:

    Если делать класс например для всех COM портов на контроллере LPC2468. При создании в конструкторе прописывать номер порта. При этом есть проблема, у каждого порта свои регистры. Думал как вариант: создать поля указателей на эти регистры. В конструкторе поставить switch и присваивать здесь этим указателям адреса соответствующих регистров, а в остальных функциях обращаться непосредственно к указателям. Достоинсва: быстродействие, недостатки: лишняя память на поля указателей.

     

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

     

    Можно ли обойтись (а нужно ли?) без операторов switch() при обращении к регистрам ввода/вывода, которые для каждого COM порта могут находиться в любом месте области памяти?

×
×
  • Создать...