Нужно получить некоторое подобие 2-х битного ЦАПа на частоте ~10МГц. Для этого есть идея использовать параллельно 2 SSP, т.е. выводить синхронно два битовых потока. Встает вопрос - как их синхронизировать. Сначала хотел сделать 1 SSP мастером, второй слейвом (с объединением клоков). В таком случае синхронизация получилась бы автоматически. Но оказалось, что


Может быть, есть еще какие-нибудь варианты? Желательно, конечно, обеспечить одновременность начала битовых потоков, но в крайнем случае можно рассмотреть варианты постоянного сдвига на целое число бит.

Конечно - использовать естественным образом I2S на удвоенной частоте добавив к нему примитивный дешифратор битового потока на два.

Дешифратор может и примитивный, но все равно громоздкий. Как минимум сдвиговый регистр+триггер.

Вот если бы SSP поддерживал бы слова 2 бита, то триггер бы не понадобился, хватило бы только сдвигового регистра и сигнала FS.

Сдвиговый-то зачем? Пара D триггеров запоминающие каждый свой бит из потока и триггер делящий для них частоту. Можно одним корпусом, можно из "одногейтовых" набрать...

И работать не будет, так как без линии задержки на выходе будем иметь две последовательности, сдвинутые на один период двойной частоты
Нажмите для просмотра прикрепленного файла

Уж не знаю, что Вы там себе нарисовали, что такое str и почему оно идет на 1/4 частоте клоков, ибо:
- на I2S имеется чередующийся битовый поток, естественно, c частотой 1/2 клоков;
- имеется клок по rising edge которого поток семплируется;
- делим этот клок на два;
- получившимся клоком rising edge семплируем (записываем в первый триггер) нечетные биты для первого
выходного потока
- falling edge (rising c инверсного выхода тригера делящего частоту) семплируем четные биты во втором триггере для второго битового потока.
В результате получаем два битовых потока на половинной частоте исходного клока.
Единственно, что в результате получаем от I2S два потока максимум на 72MHz/4. Это соответствует озвученному ранее "~10MHz"?

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



Получать-то мы их получаем, но не синхронными! Более того сдвиг не равен одному биту, а равен половине, что тоже не годится.




Не успеваю отвечать, как сообщение изменяется.
str - это и есть поток, 2 единицы, 2 нуля подряд
он и есть 1/2 а не одна 1/4 (clk2 = clk1*2)


На всякий случай прикладываю осцилограму, что надо получить:
Нажмите для просмотра прикрепленного файла

Т.е. сплошной поток на удвоенной частоте 11001100 синхронно преобразуется в два потока 1010 на одинарной частоте. На самом деле такое легко реализуется сдвиговым регистром и триггером.



А если я просто соседними командами запишу в буфер SSP0 и SSP1 (с настроенными DMA), насколько детерменированным/постоянным будет сдвиг между выходными потоками?

Это хорошо.

Не знаю, что там у Вас дальше, но полученные потоки можно/нужно семплировать сложенным по ИЛИ прямой и поделенной тактовыми - фронт на 3/4 тактовой соответствует установившимся значениям по обеим каналам.

Полный произвол, тем более, что "две соседних" команды относятся к периферии висящей на меееедленной периферийной шине.

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

Ладно, из удвоенного потока тем или иным способом два одиночных выделить можно.
Но может "как-нибудь так"?

Неа....

как же я до двух уменьшу, когда там 2 единицы подряд идут

То, что там идет подряд или не подряд, это дело десятое - рисуются БИТЫ, а не их значение. Длительность бита в I2C один период CLK а не два.
Если у Вас почему-то ВСЕГДА идут биты по одинаковым парам, то я вообще перестал понимать что мы тут вообще обсуждаем, ибо это прото два совершенно одинаковых потока....

К сожалению, квартус стирает границу между двумя битами, если они имееют одинаковое значение.
Вот, поправил в паинте.


Нажмите для просмотра прикрепленного файла

Теперь осталось 0 и 1 расставить правильно в соответствии с КАНАЛАМИ а не значениями битов и задание готово

Если у Вас CPLD/FPGA подключается, то тогда вообще проблем '0' . Делайте двойную скорость и не морочте голову!

так оно так и расставлено 1100 в двойной последовательности соответсвует 10 в первом канале и 10 во втором, но уже на пониженной частоте




Как раз всеми силами стараюсь CPLD не подключить (всмысле обойтись).


Ладно, этот вариант я понял.

Может быть есть какие-то шансы воспользоваться контроллером SD/MMC и его 4-х битной шиной?
А это у всех LPC ограничение максимального клока в pclk/12 для режима slave?

Расставлены зачем-то конкретные значения битов, а не номера каналов.

На и на шустрой рассыпухе все получится...

Нет, бывает и 1/8 у тех, которые 60MHz.....
Вы там особо за SSP*2 не переживайте, если непрерывные потоки на 10Mbit гнать надо, ибо байтики медленно подносятся из-за скорости шины, если только оба GPDMA под это не отдать.

Да его непрерывно и не надо, пакетами по 52мкС. Устройство - генератор Pal сигнала для телевизора. Хочется получить 4 цвета - черный, серый, серый, белый. Будет использоваться 7" китайский LCD, родное разрешение которог 480х234 пиксела. Вот эти 480 в строке и определяют частоту 9.2 МГц. Т.е. я себе представлял это дело так - прерывание от таймера - строчный импулс - запускаем SSP на 480 бит.



Раньше с ARM имел дело только эпизодически, сюда хотел применять самый мелкий циклон3. Но цена LPC просто убивает (особенно, если вспомнить, сколько на этот циклон еще стабилизаторов питания надо)



Отдать оба GPDMA не жалко, ибо от сего девайса нужно только по нажатию на кнопочку брать конкретную картинку из dataFlash, класть ее себе в ОЗУ а из ОЗУ рисовать на телевизор.