Рассматриваю вариант подключения сенсора к микроконтроллеру для последующей передачи изображения по радиоканалу.

1. Наиболее дешевым на мой взгляд сенсором является сенсор от WEB-камеры. Сенсор "не мечта миллионов" и качество картинки оставляет желать лучшего, но его стоимость очень приемлема для экспериментов.

2. Исследовав несколько очень дешевых WEB-камер обнаружил наличие сенсора VA6241.
Достаточно легкая в отношении пайки, подключения питания и т.п. Нашёл на него самопальный датащит... http://www.vabolis.lt/stuff/VA6241.pdf

Вопросы.
1. Управление по I2C шине... Нет регистров.
- как вариант решения предполагаю "слушать" микроконтроллером в процессе работы камеры с компом.
? может у кого есть готовые регистры?
? регистры стандарт или у каждого чипа свой?

2. Как сжать полученную картинку? Даже на 8bit'ах из 10-ти возможных получается очень большой поток.
640 dot*480 line* 30fps * 8 bit = 74Mbit
предполагаю 320*240*15*8=9Mbit
- реализовать на микроконтроллере сложно, скорее даже не реально. Слишком большой поток - AVR Atmega не протянет...
? Или я ошибаюсь. Может кто делал?
- специальна микросхема JPEG-кодек. Большое изобилее судя по интернету.
? Существует ли какие-то более распространённые, употредбительные. Кто с какими работал?

3.? Может у кого есть ещё какие идеи?

p.s.
Проанализровав интернет
1. как вариант есть использоватик фотик от телефона, но это НЕ рассматривается. Потому как много камер от телефонов не найти.
2. Встроенный кодек в камере (VC0305) - к сожалению даёт выход только на USB(((
3. В цифровых фотиках как я понял всё зашито в осноной чип, т.е. кодек - это не отдельная микруха(((

Где-то я встречал на просторах инета проект сжатия в JPEG с помощью AVR, с какой-то аналоговой камеры + внешнего АЦП... Если ессно память не подводит.
Вот навскидку.

Спасибо. Полезная ссылка. На ARM никто не пробывал делать? Производительность действительно поболе будет!

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Братцы, такая хорошая тема пылится - воскресим?..

Сам недавно заинтересовался JPEG форматом, а именно декодированием силами AVR-ки с последующим отображением... да пускай тем же ls020 от всем известного Siemens S65. Прочесав просторы Интернета, наткнулся на это: http://habrahabr.ru/blogs/algorithm/102521/ . Курил несколько раз и даже почти во всём въехал. Автор, конечно, молодца! Всё разжёвано и разложено "по полочкам". Только вот, как он сам описывает, на "большом брате" по его алгоритму картинка 600х600 распаковывалась ок. 7 секунд. После оптимизации алгоритма, которой он самым "вежливым" способом не поделился, ок. 15мс. Тогда сколько же по времени будет длиться этот процесс на маленькой AVR-ке? Исходя из описанного алгоритма и по предварительным прикидкам, можно надеяться вместиться в 1 кил RAM, если обрабатывать по одному блоку 8х8 и сразу же плученный результат 3х8х8 (RGB) выбрасывать в дисп, освобождая место под новый вычисляемый блок. Только возникает ещё один вопрос, как оптимизировать вычисление AC составляющей, ведь именно в этом процессе лежит львиная доля всех вычислений.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

http://elm-chan.org/fsw/tjpg/00index.html

но про AVR, ессно, забудьте.
Кстати, среди кортексов хватает МК сразу с CIS интерфейсом за недорого.

Например, STM32F207 . небольшой корпус - 64 ноги, 150 MIPS (поржем вместе над AVRом -)) ), в России в наличии от 200р

Digital camera interface (DCMI)
The camera interface is not available in STM32F205xx devices.
STM32F207xx products embed a camera interface that can connect with camera modules
and CMOS sensors through an 8-bit to 14-bit parallel interface, to receive video data. The
camera interface can sustain up to 27 Mbyte/s at 27 MHz or 48 Mbyte/s at 48 MHz. It
features:
● Programmable polarity for the input pixel clock and synchronization signals
● Parallel data communication can be 8-, 10-, 12- or 14-bit
● Supports 8-bit progressive video monochrome or raw Bayer format, YCbCr 4:2:2
progressive video, RGB 565 progressive video or compressed data (like JPEG)
● Supports continuous mode or snapshot (a single frame) mode
● Capability to automatically crop the image

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Я в ARM-овских камушках и сам худо-бедно ориентируюсь, но интересует реализация именно на 8-бит AVR-ке На кортексе не прикольно - при помощи гранаты любой рыбы наловить сможет, но это же тоже не прикольно

Все-таки у атмеги 16 MIPS, с камерами и LCD по серьезному не развернешься.

Код этот http://elm-chan.org/fsw/tjpg/00index.html интересный, но на си. Вот если на ассемблере его переписать, будет раз в 5 быстрее всё делать. Только где найти такого мазохиста?

Вообще изначально надо понять какая задача. полкадра в секунду устраивает или нет?

Нет, вы не подумайте, я не извращенец, но заставил мегу 16 работать на 25МГц от 3,6-4В (ли-ион АКБ от мобилки). Я не говорил, что хочу камеру прикрутить - просто чтение из памяти и распаковка с выводом на экран. Кстати ни у кого нету готовой "полноценной" библиотечки для работы с FAT32? Желательно под КодВижнАВР? А то всё что я находил было или урезанным функционально или не рабочим...

А я и сам этим вопросом заинтересован, как на атмеге8, с прикрученным чипом USB CP2102 достичь нормальной отрисовки. На деле получается канал 90Кбайт/с, если кидать несжатые данные в дисплей, то у меня получилось 1.8 FPS, упирается в канал прежде всего (дисплей 128*128*12бит), потому что сам дисплей заводится на атмеге на 15 кадров в секунду. JPEG позволяет зажать примерно в 10 раз, но тяжелый для 8 битных контроллеров и написан не для них. Тут нужен какой-то упрощенный JPEG без хаффманов и прочих прожорливых вычислений, жмущий в 3-4 раза.
Сам жду почтой Cortex-M3 чип пока балуюсь с атмегой

TJpgDec is a generic JPEG image decompressor module that highly optimized for small embedded systems. It works with very low memory consumption so that it can be incorporated into tiny microcontrollers, such as AVR, 8051, PIC, Z80, Cortex-M0 and etc.

Ну вот, а говорите АВР-ка не потянет.

Потянет примерно так

Ну, как то не заметил в начале, что цель затрахаться за дорого, а не решить задачу за дешево.

"скомпилируется" и "потянет" - это две большие разницы.

Насколько помню, само сжатие по хаффману совсем не страшно на фоне конверсии цветового пространства и DCT, без которого никакого jpeg не будет.

cp2102 с атмегой как связан ?

Пользовал at90usb82 на 16Mhz с дисплеем 320x240x16bit - по USB он выводится ~1с.

По UART


Я о том же, нужно сжатие с потерями оптимизированное под всё это. JPEG не для атмег.

Я бы сказал иначе - эта задача не для атмег

Но сия тема именно о JPEG. Больше всего тянет обратное дискретно-косинусное преобразование, но автор приведённой статьи как-то решил эту проблему. Потом никто же не заставляет точно вычислять косинусы, тем более на 8бит машинке. Вполне достаточно будет "зашить" во флешку табличку на 256 значений.

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

достали вы со спорами AVR vs ARM. можно ломиться в стену на танке ARM, можно влезть в окно на AVR, но правильнее поставить задачу так, чтобы ее можно было решить не через жопу.

есть камера, которая отличненько по UART-у выдает изображения со скоростью 115 кбод, стоит около 350 рублей. такой поток отлично потянет не только AVR, но даже классический MCS51. если вы собрались передавать этот поток по радиоканалу, то можно построить схему так, что из камеры байты сразу попрут в передатчик - МК нужно будет только инициировать работу.

камера ищется по ключевым словам CoMedia Camera такая вот комедия, блин.

если на ARM или еще какой-то фигне можно получить более простое и дешевое решение - напишите.

Разумеется, речь не о передаче видео, а о статических изображениях. но это изначально подразумевалось, т.к. JPEG - это метод сжатия неподвижных изображений, в отличие от MPEG. в реале с этой камеры получается до 5 кадров в секунду (при малом разрешении и черно-белым - больше)...