На какво решение се спря за бързото ADC ?

Оф, не мога да седна да го помисля, мамка му.

Камерния интерфейс май няма да стане. Той иска външен клок. Айде аз мастер клок за семплирането ще подсигуря, ама то онова иска и VSINC и HSINC сигнали за да работи. Явно подрежда в паметта данните направо по ред и страница. Може и без тия сигнали, ама иска софтуерни маркери за целта вътре в данните, което пак не става. Въобще иска си някак си да се синхронизира редово и по страница... демек просто да го закача към АЦП-то ще е трудно.

Засега мисля да пробвам вариант просто да вържа АЦП-то на FSMC шината и да си го чета като нормален РАМ от един и същи адрес. Проблема върху който не съм мислил особенно е как да синхронизирам с честотата на дискретизация. Мислех с някой от таймерите да му избачкам един клок, който да си превключвам според скоростта на която искам да семплирам. АЦП то се стартира по предния фронт, а аз по същия да генерирам прекъсване и после просто да го прочета. Това е малко тъпо решение на пръв поглед особенно при скорости на семплиране около и над 1MHz, ама така става флексибилно и независимо от честотата на семплиране. Щото идеята е да мога да семплирам на 100KHz, 1MHz и нагоре до колкото може, като 10MHz са таргет максимума който гоня...ама не виждам как ще стигна.

Мисля си не мога ли някак си да се изхитря и да запускам DMA-то да чете по една дума вместо процесора на всеки клок. Ама при мемори-мемори трансфер - старта е само софтуерен и то се обезмисля, по добре просто да го прочета... по малко процесорно време ще глътне.

Въртят ми се някакви луди идеи... от типа да вържа клока на кепчър модула и да го настроя да реагира на заден фронт. Ако има DMA за кепчъра (не съм го проверил дали има), ама вместо адреса на кепчъра да дам на DMA-то адреса на който отговаря АЦП-то... ама едва ли ще стане Някакви подобна ми се ще да измисля, щото ми се види глупаво да цъкам прекъсвания на 1MHz и нагоре...

Камерният интерфейс има и мод "JPG", при който си чете стрийм без да се интересува от редове / кадри. А DMA може да се сложи в cyclic режим и тогава данните ти се появяват в SRAM без грижа. Само не си спомням дали DMA можеше да прави прекъсване при 50% изчерпаване на трансфера, за да имаш време да преглътнеш резултатите и да ре-инициализираш DMA. Външен клок ще трябва да има, евентуално можеш от таймер да го направиш. Май че 10 MHz си е съвсем достижима цел при 168 на ядрото.

Цецо, най-лесно ще стане ако кажеш какво е АЦП-то или още по-добре какъв му е интерфейса...
Тия идеи да правиш софтуерни трансфери звучат мнооого налудничево

На теория или ЦПУ-то командва парада или периферията (АЦП-то). Под "командване" имам предвид кой налага ограниченията, не е задължително да е мастер при трансфера. Сега тоя интерфейс за камерите ти е единствения читав начин да е "мастер" периферия. Демек неговата цел е когато периферията каже "имам данни" проца да ги поеме, иначе данните се губят...
Ако АЦП-то ти има FIFO може да мислиш за други варианти, но ако нямаш FIFO по-добре още веднъж огледай тоя интерфейс. Имаш клок, който казваш не се изработва от AЦП-то, значи ти ще го изработваш. Как точно си е твой проблем. Имаш и два enable-a. Два са щото при камерите са два. Ако не ти трябват и двата може да ги окъсиш или ако има софтуерна възможност да изключиш единия (При Атмел може софтуерно да шунтираш кой да е). Но ги огледай първо, защото може да има странични ефекти. Обикновено има синхронизация при кепчърите, т.е. за да семплира трябва и двата сигнала да са асертнати. Обаче като го пуснеш за първи път дори и да са асертнати не почва, докато не види фронт на VSYNC. Това е с цел да не почне от средата на картината...
Сега, дали ще са два сигналите или един или накъсо, или нито един (софтуерно) вече ще си видиш документацията. Ако АЦП-то ти има сигнал кога може да изкарва данни е ясно. Ако няма такъв, не би трябвало да ти е проблем да си изработиш такъв

Иначе за софтуерните ти идеи.... както казах ако имаш 10-15К FIFO в АЦП-то нямаш грижи. Вързвай го някак, чети когато и както искаш... Ама що си мисля, че нямаш такъв разкош? Така че ако не искаш да убиеш проца не се вкарвай в тоя филм... Предполагам докато не дойдат данните проца не ти трябва много-много, ама все пак... Утре ще закачиш USB или друго и ще се окаже че няма да работят докато не си направиш измерванията. Като вица за Бил Гейтс - "чакай сине да се форматира дискетата и ще ти покажа многозадачност..."
Единствено, ако има фифо поне за няколко семпъла може да стане по външната шина за данни + ДМА. Но макар и малко пак ти трябва фифо, щото шините се арбитрират, имат собствено мнение на тема честоти и т.н.

Между другото каква е целта на упражението - тия данни ще ги обработваш ли в проца, или той е само за връзка с РС-то?

АЦП-то мисля да е ADS850 или ADS804 не съм решил още какво преследвам като точност, но като интерфейс са еднакви. Клока на АЦП-то трябва да е стриктен, вероятно процесора ще го прави, щото ми трябва да се превключва.

FIFO няма.

Идеята е да правя кепчър на сигнала за определено време. Мисля че 64К памет ще ми стигнат. Честота 100К/1М/10М. Една страница и спира/обработва си ги/праща ги на ПЦ. Получава нова заявка от ПЦ и повтаря процедурата. Засега докато кептчва няма да прави нищо друго ядрото, евентуално може да бръмчи UART -а, но ще е по DMA.

Като цяло системата е тестово оборудване за друг хардуер. Подава комбинация от цифрови и аналогови сигнали на тестваната платка и мери резултати и ги праща на ПЦ-то. Досега това се правеше от PIC и се справяше прекрасно. Но точно системата с АЦП-то си беше реализирана автономно с памет и броячи, PIC-а само я изчиташе. А сега ми се ще да опростя хардуера и да вържа АЦП-то директно на контролера.

Нещо ми е мътен тоя камера интерфейс, не съм го борил до сега, ама ще се зачета като ми остане дупка.

P.S.

Сега се позачетох. Значи до колкото разбирам той си работи само като слейв. Пиксел клока му набива по една дума. HSYNC като е активен кептчва всяка точка по пиксел клока, като не е активен си трае. VSYNC трябва да огражда една цяла страница.

Демек значи ли това, че аз мога да завъртя HSYNC и VSYNC към два порта на контролера. HSYNC го подържам постоянно активен, а с VSYNC да си стартирам и спирам кептчъра??? Че то ако е така, то ще е песен...
Другото което не ми стана ясно, е каква точно е разликата в отделните режими (RGB, YCb, JPEG)... От гледна точка на контролера това не са ли просто някакви данни, който той последователно тъпче в паметта? Какво точно се променя в механизма на сторване, при различните режими?

Доколкото аз разбрах, в JPEG игнорира синхроимпулсите и поема цялата информация като стрийм. Ама може и да не е така точно, де.

ми не е баш така, HSYNC пак се ползва като "enable" на стрима... Точно затова не виждам разлика между JPEG и останалите. Уж останалите ги редяло по редове и страници, ама то какво му реди - ръга ги последователно в паметта.

Но има нещо различно, щом има бит да превключва...

Да, това е идеята...
Въпросът е дали не може да се шунтират софтуерно тия сигнали. Прегледах набързо документацията май не може... Както и да е, едва ли ти е голям проблем отвън да направиш заглушка от друг пин на проца да ги клатиш...




Това не съм го чел за ST, ама при Atmel имаш възможмост да правиш RGB<->Ycrb конверсии, ти просто трябва да изключиш подобни щуротии, както и crop-ването.
А пък за JPEG разликите би трябвало да са козметични само. Предполагам няма синхронизация на началото, което ежентуално би могло да ти спести двата шунта, ама не съм го видял черно на бяло, така че не те съветвам да рискуваш. Другото е може би ако има прекъсвания за редове да ги изключва, щото нямаш редове. Абе дреболии според мен.

А пък за проца те питах дали е само за украса, щото за 3-4$ може да сложиш SAM3U и през бързото USB да мяташ всичко в компютъра и няма да имаш ограничения от типа колко ти е паметта. Ама сега видях че пък точно 3U нямат капчер, само 3S имат, ама те пък са с бавно-то USB. Абе и Атмел са едни чукундури...

Абе ще взема един дисковери кит и ще пробвам, то се е видяло...

В тоя ред на мисли:

Как мислите е по-добре да генерирам клока за семплиране - посредством PWM или с външен чип + отделен кристал? В процесора честотата се вдига до 300Mhz, после се дели, ала, бала, дали няма да се появи джитер?

Ама от друга страна е по-добре тактовете да са синхронизирани, т.е. да идват от едно място...

Така е по принцип, но за конкретния случай едва ли е от значение DMA заявките дали ти идват синхронни. А и реалните камери май си бръмчат на собствен диригент.

Няма значение кой е диригента, стига клокът да е читав... Не знам ST-тата какви клоци могат да генерират, но едва ли ще има проблем. По-скоро бих се притеснявал от терминацията, защото имам впечатления от jtag-a на F1 и той има уникално яки драйвери. Толкова яки че и на 200MHz изкарва разбираеми сигнали. С друг АРМ не могат да се постигнат такива честоти. Страничният (д)ефект, обаче е, че звъни та се къса. Въпреки всичките ми усилия да екранирам и скъсявам кабела на 5м от мен телевизора губи картина
A пък при честотите на Ф4 горещо препоръчвам да се изчетат много внимателно всички препоръки на ST относно излъчвания и смущения. Не е шега при тия честоти, дори и само за вътрешни клоци. Примерно NXP за техните LPC43xx казват да не се ползват двуслойни платки...

Е то за JTAG-а май няма как, ама за другите I/O - та, драйвера може да се превключва за 4 скорости. Поне така беше на по-старите, незнам далi F4 го има.

До колкото схванах искаш да направиш "кепчър" за ПЦ, които да кепчва с макс. честота 10мХз и да препраща инфото към ПЦ.
Лог. анализатора от линка по-долу е точно това,което искаш да направиш. Реализиран е с микроконтролер с бързо УСБ и успява да предава към ПЦ 16 бита данни (8бит. АЦП + 8 лог. входа) с честота на семплиране 16мХз. Ако не държиш да е точно с АРМ процесор - можеш да заложиш на този вариант. Решението е "двучипово" - процесор + АЦП и със сигурност работи.
http://mcu-bg.com/mcu_site/viewtopic.php?f=22&t=10312

Предполагам, че и варианта на АРМ с видео-интерфейс може да се получи. Клока ще е добре да се генерира от таймер в процесора, за да можеш лесно да променяш семпъл рейта, както и ако се наложи синхронно да генерираш H или V SYNC сигналите, с още един (или два) компаратор(а) в проца.
Грубо казано разликата във форматите YCrCb и RGB е подреждането и значението на байтовете в срийма. Т.е. в твоя случай това не е от значение, защото софтуерно (в ПЦ-то) ще можеш да си ги преподредиш. Гледам, че на камерата която използваме клок-а на паралелния бъс е 27МХз. Та предполагам, че стандартно процесора с камера интерфейса си би трябвало да поддържа и такава скорост.

Като гледам задачата най добре би се справило едно RX на Renesas, ама като сте ги захапали тия армове няма пускане...
48Mhz външна шина и си качиш каквото искаш, кеф ти АЦП кеф ти рам. Ядрото е на 96Mhz. Може и на 100Mhz(външна шина 50) ама трябва да си намериш кварц 12.5Mhz.