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

Разовая работа программисту. dump потока данных (20МБ/с) на SATA HDD

Основные задачи - запрограммировать

- сохранение 8 битного потока данных (сопровождаемого клоком 20МГц) на SATA HDD.

- выдача 8 битного потока данных с HDD по внешнему клоку 20МГц

 

SATA HDD - основное требование, из-за существенного объема отдельного лога в несколько десятков минут. (12-36ГБ)

 

Аппаратная платформа не выбрана и ограничения в ее выборе практический отсутствуют.

На чем реализовывать задачу согласуется с исполнителем (предыдущий опыт + срок готовности платформы)

 

Реализация аппаратной платформы после согласования может быть и отдельной работой.

В идеальном случае - это если существует отдельная готовая плата с некоторыми доработками.

(возможно ее дополнить отдельной платой FPGA/CPLD для удобной стыковки с доступным интерфейсом основного процессора)

 

 

Вопросы и дальнейшее обсуждение в личных сообщениях форума.

Изменено пользователем NiOS

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

SATA HDD - основное требование, тк максимальный объем отдельного лога вплоть до 1ГБ.

 

MMCTR08G3ACH

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

MMCTR08G3ACH

Всего 6 минут лога, а нужно объем до 1-2 ТБ.

Подкорректировал сообщение, неправильно изначально написал объем отдельного дампа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Всего 6 минут лога, а нужно объем до 1-2 ТБ.

Подкорректировал сообщение, неправильно изначально написал объем отдельного дампа.

Я бы взял вот такую штуку Laguna GW2388-SP213 (SATA) ребята могут по желанию на неё допоято что нужно плюсом взять карту с FPGA для PCI

Либо взять вот такойй борд Laguna GW2380 и карту 2 Port Mini PCI Express Internal SATA II Controller Card только CPU запаять который 600 MHz. Бонус этого процессора в том что там встроенный контроллер который будет ворочать ваши данные и есть возможность переварить ваш поток информации. Бонусом идет в поставке допиленный OpenWRT и драйвера. Если захочется софта плюсом то ребята достаточно легко дают NDA. Переработка платы под ваши требования будет стоить $40К - 16 недель. Только сомниваюсь, что вам необходимо перерабатывать.

Если интересно пишите в ЛС

Изменено пользователем Mihail Gluhowchenko

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Всего 6 минут лога, а нужно объем до 1-2 ТБ.

Подкорректировал сообщение, неправильно изначально написал объем отдельного дампа.

CY7C68013A + обычный писюк практически все уже сделано.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

CY7C68013A + обычный писюк практически все уже сделано.

 

В принципе и такой вариант можно обсудить - нетбук/ноутбук + плата захвата/выдачи по USB

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

подумайте может взять USB 3.0 (будет запас по скорости)

есть и отладочный кит

есть готовое описание на xHDL для FPGA

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В принципе и такой вариант можно обсудить - нетбук/ноутбук + плата захвата/выдачи по USB

Снизу уже про USB3 написали. Я не помню точно, но это цайпресовский чип толи 30, толи 60 мегабайт в с секунду давал. И можно не только ноут но и PC-104. Можно и PCIe/PCI плату сделать. Но это сильно дольше будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

подумайте может взять USB 3.0 (будет запас по скорости)

Такой вариант возможен и обсуждаем. Как уже было сказано - ограничений по аппаратной реализаций нет.

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

 

С USB только один вопрос- надежность передачи, пропуск в логе не допустим.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

CY7C68013A + обычный писюк практически все уже сделано.

5051 на 48 МГц поток 20 МБайт в секунду не потянет.

 

С USB только один вопрос- надежность передачи, пропуск в логе не допустим.

Тогда вариант только один - отправлять пакетами с CRC, да еще с подтверждениями, повторами. Требования по скорости резко возрастают. Об этм надо было сразу сказать. Может вы еще о чем-то умалчиваете и так и будете по крупицам инфу выдавать?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5051 на 48 МГц поток 20 МБайт в секунду не потянет.

А там он вообще "с боку".

 

Тогда вариант только один - отправлять пакетами с CRC, да еще с подтверждениями, повторами. Требования по скорости резко возрастают. Об этм надо было сразу сказать. Может вы еще о чем-то умалчиваете и так и будете по крупицам инфу выдавать?

Не то чтобы резко, но буффер и шустрый процессор понадобится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тогда вариант только один - отправлять пакетами с CRC, да еще с подтверждениями, повторами. Требования по скорости резко возрастают. Об этм надо было сразу сказать. Может вы еще о чем-то умалчиваете и так и будете по крупицам инфу выдавать?

Требование сохранения/выдачи потока в 20МБ/с подразумевает, что целостность потока важна.

Хотя в принципе даже некоторые случайные сбои не приведут к проблемам, но они не должны быть систематическими.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Требование сохранения/выдачи потока в 20МБ/с подразумевает, что целостность потока важна.

Хотя в принципе даже некоторые случайные сбои не приведут к проблемам, но они не должны быть систематическими.

bulk режим в USB обеспечивает целостность данных на уровне протокола USB. Абы буффер не переполнился. .

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5051 на 48 МГц поток 20 МБайт в секунду не потянет.

5051 не потянет, а GPIF - запросто.

Из требований автора не очень понятно только есть-ли требование одновременной передачи в нескольких направлениях. Как я понял ожидается 3 стороны обмена: источник данных, винт, ПК.

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

 

Тогда вариант только один - отправлять пакетами с CRC, да еще с подтверждениями, повторами. Требования по скорости резко возрастают. Об этм надо было сразу сказать. Может вы еще о чем-то умалчиваете и так и будете по крупицам инфу выдавать?

Контроль целостности пакетов обеспечивается USB.

 

bulk режим в USB обеспечивает целостность данных на уровне протокола USB. Абы буффер не переполнился. .

Если есть необходимость передачи потока данных с определённой скоростью, это само собой подразумевает isochronous, а не bulk.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если есть необходимость передачи потока данных с определённой скоростью, это само собой подразумевает isochronous, а не bulk.

 

isochronous - пакеты могут теряться.

bulk - быстрее в 2 раза чем isochronous

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

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