ну теперь разбивкой на пакеты будет сигнал CS, который о благо в CHPA=1 режиме можно опускать на весь пакет. До этого я делал это через дополнительный проводок, синхронизовал кадр, а разбивка по длине, как и в ТСР который по сути тоже байтовый поток. Единственное что пакеты не постоянной длинны, потому что они такие приходят сверху и добивать короткие до полного - тяжко для обмена, а резать длинные на коротки - тяжко для меня)
Проблема в том что не известно сколько слейв будет готовить ответ на запрос, то есть нельзя утверждать что сразу будет готов ответ. Для этого тот же проводок что синхронизовал кадр использовался в другую сторону для индикации готовности данных. И только тогда мастер по SPI вычитывал ответ. С более короткими пакетами все тоже самое. То есть либо надо чтобы слейв гарантированно мгновенно отвечал - а это невозможно у него есть приоритетная задача, либо отвечал через гарантированный таймаут - что задержет обмен когда слейв не занят.
потому такое решение...
задаем конец кадра - слейв сбрасывает все буферы и ждет
приходить сообщение, слейв по длине определяет что оно пришло целиком, обрабатывает, готовит ответ, дает сигнал
мастер забирает и сообщает о конце кадра обмена.
Максимальная скорость, без накладных и задержек, и достаточно просто, как мне показалось...
Цитата
И к тому же думаю, что транзакции обмена по шине идут в пакетном режиме (типа как с SDRAM-памятью): вначале - адрес, упр. инфа, потом - неск. слов данных.
И к тому-же DMA должен сперва считать эти данные в своё FIFO по шине, а потом ещё записать (опять по шине) в ОЗУ.
А я думаю что DMA пишет все фифо за раз, не зависимо от того как оно его набивало по 4 символа или по 1. Потому burst или нет тут роли не играет. Важнее как часто ДМА пытается занять шину для сброса данных в память. В burst эти акции в 4 раза реже, вроде как, может это лучше при конкуренции с другими ДМА и процом....
Ну надеюсь 2 канала, работающие по очереди не нагнут невозможно проц