Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Запись данных из RAM на uSD-карту #21

Closed
EvilLord666 opened this issue Feb 13, 2017 · 19 comments
Closed

Запись данных из RAM на uSD-карту #21

EvilLord666 opened this issue Feb 13, 2017 · 19 comments
Assignees
Labels

Comments

@EvilLord666
Copy link
Member

На данный момент данные складываются в оперативную память, для того, чтобы мы могли их проверять или как-то в дальнейшем работать с ними, их необходимо сохранять на uSD-карту в Standalone-приложении.

@EvilLord666
Copy link
Member Author

Данная задача будет перенесена на бета версию (она для нас не является основной), сейчас все данные было принято выводить в консоль через UART.

@boyarincevAlex
Copy link
Contributor

Судя по структурной схеме, на Zynq есть встроенный контроллер для SD карты. У меня несколько вопросов: данные можно передавать в режиме DMA или с помощью процессора?
С помощью чего связываются RAM и SD контроллер?

@EvilLord666
Copy link
Member Author

Перебросом данных из RAM в SD требуется управлять из процессорного кода, при работе AXI VDMA генерируются прерывания, которые нужно обрабатывать и в процедурах обработки прерываний нужно написать код, который будет отвечать за формирование файлов-видео,.
Для этой задачи нужно разобраться с форматами видеофайлов и предложить формат, в котором стоит выводить данные.

@boyarincevAlex
Copy link
Contributor

В какой программе можно это реализовать? Я так понял, Vivado работает только с ПЛИС.

@EvilLord666
Copy link
Member Author

Сам код под процессорное ядро пишется в vivado sdk, запускается из vivado, методику тестирования нужно придумать:

  1. Выбрать формат в котором сохранять картинку и видео, т.е. желательно иметь два режима (мгновенный снимок и потоковое видео).

  2. Создать в Visual Studio проект и написать енкодер, который будет из произвольных данных (мы подложим тестовые данные) без использования сторонних библиотек кодировать эти данные в картинку.

  3. Написать также в Visual Studio проект, который соединит в себе запись данных на флэшку через библиотеку fatfs и проект из п.2.

  4. Перенести проект из п.3 в этот (OpticalMeasurementsSystems/ImageCaptureSystem
    ) проект, собрать под Vivado SDK.

@boyarincevAlex
Copy link
Contributor

Я правильно понимаю, что на входе с драгстеров идут 8-битные данные, которые кодируют цвет пикселя, а на выходе после AXI VDMA уже 32 битные данные? Получается, что в одном слове содержится информация о 4 пикселях? Нам как то нужно будет их разделить?

@EvilLord666
Copy link
Member Author

Вообще с драгстера у тебя будет картинка серых оттенков, т.к. используемая модель драгстера дает инофрмацию только об интенсивности, см. полную спецификацию на драгстер из папки docs.

@boyarincevAlex
Copy link
Contributor

Посмотрев разные форматы видео, у меня возникла идея, а можно использовать gif формат? В нем как раз можно создавать картинку или анимацию. У нас же нет аудио дорожки, да и gif, по-моему, легче, чем любые видео форматы.

@VeryNiceGuy
Copy link
Contributor

Прошу обратить внимание на тот факт что мы работаем с линейкой. Её конечно можно воспринимать как одномерную матрицу очень маленького по нынешним меркам разрешения, тем не менее. Мне кажется писать одну линию в видеофайл это оверкилл. Глазами такое видео не посмотришь, а если писать только чтобы данные эффективно сохранить, то тут возникает сразу две проблемы: потери в качестве и необходимость в интерполяции при каждом чтении, что требует вычислений как и само кодирование. Я бы предложил писать без сжатия в сырьевом формате. Единого стандарта подобного формата нет, да и нам он в принципе не нужен. Поскольку нам известен размер куска данных который мы выдираем, мы можем просто заталкивать его в один толстый файл пока не посчитаем нужным удалить/извлечь его или создать новый. В любой момент времени мы будем гарантированно иметь N сохраненных кусков. N можно будет посчитать просто разделив текущий размер файла на размер куска.

@EvilLord666
Copy link
Member Author

Думаю, что надо писать пачкой строк типа 1024х768 т.е. например 768 строк размером по 1к пикселов.

@EvilLord666
Copy link
Member Author

Ребята, что у вас с этой задачей?

@boyarincevAlex
Copy link
Contributor

Мы были заняты на той неделе по учебе, поэтому ничего не делали, в эту неделю нам нужно срочно сдать 2 предмета до пятницы, поэтому тоже заняты будем. Есть много вопросов, но первые наработки попытаемся предоставить на следующей неделе.

@EvilLord666
Copy link
Member Author

Что будут включать в себя первые наработки?

@boyarincevAlex
Copy link
Contributor

Постараемся разобраться в RAW формате и сформировать изображение из произвольных данных

@boyarincevAlex
Copy link
Contributor

Залил проект с++ в отдельную ветку. Мы решили формировать изображение не в RAW формате, а в формате bmp, так как он наиболее простой. Рассматривали формат DNG, он показался нам непонятным, другие RAW форматы специфичны для определенной камеры. Да и вообще насколько я понял, в RAW формате содержаться только первичные данные с фотоматрицы, и не содержится ничего о размерах изображения, сколь бит на пиксель и т. д. Поэтому мы и решили записывать в формате bmp.

@EvilLord666
Copy link
Member Author

BMP это конечно хорошо, но нужно:

  1. Закодировать одно из стандартных изображений и сохранить его в файл

  2. Сделать поддержку RAW формата

  3. Еще нужно видео в режиме строка за строкой до формирования кадра и дописывание кадра в видеофайл.

@EvilLord666
Copy link
Member Author

P.S. в ближайшее врея проведу код ревью, напишу где и что мне не нравится.

@EvilLord666
Copy link
Member Author

Что у вас по этой задаче?

@EvilLord666
Copy link
Member Author

Проект заморожен, задача прекращается в связи со сворачиванием 218-го.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants