[jcxz 181]

Вверх присылает данные по TCP первому контроллеру, а тот их дальше гонит по SPI как мастер уже на LPC1768. С верху приходят пакеты от 1 до 513 байт длинной, такими я их и шлю дальше обвешав контрольной суммой и длинной. Разбивка на пакеты потребует ответов о статусе каждого пакета - усложнение трафика. То есть пока не вижу большого бонуса в этом. Разьве только прерывание по окончанию пакета вместо поллинга длинны. А мусорные байты в канале так и остаются мусорными и так же гадят обмен и переполняют буфер...

Если мастеру не нужен ответ на предыдущую посылку, то зачем ждать? Мастер шлёт следующую, а в обратном канале ему возвращается состояние о полученной ранее посылке

(нормально получена или с ошибкой) и на основании этого он решает - повторить с какой-то позиции или гнать дальше. В слове состояния можно хранить например какой-то номер последовательности

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

 

Если как Вы пишете - Вы обвешиваете контрольной суммой и длиной данные, то получается у Вас уже должна быть разбивка на пакеты.

А как Вы её делаете если у Вас пакет не обрамлен CS? В моём способе CS как раз служит для определения границ пакета (стандартно для большинства SPI-микросхем памяти и пр.).

В Вашем случае Вам нужно предпринимать ещё какие-то действия для определения границ пакета (делать канальное кодирование).

У вас передача получается подобно UART, т.е. - байтовый поток. А в таком случае из потока байт нужно выделять пакеты.

А раз Вы вводите контрольную сумму, значит - возможны помехи, значит метод выделения границ пакетов должен быть устойчив к этим помехам.

Тут получается излишнее усложнение на ровном месте.

 

В чем преимущество burst? Я понимаю если идут 32 битные данные которые надо разом записывать в память, тут я понимаю смысл burst, а если данные 1 байтные в чем бизнес?

Вы забываете, что шина через которую DMA обменивается с памятью - сильно загруженный ресурс. Её же может в это время интенсивно использовать CPU, исполняя код.

Если-б она была всё время свободна, то не было бы разницы как писать - побайтно или пакетом.

Но она свободна очень редко. Вот в эти то дырки и должен влезть DMA. FIFO в 4 слова в DMA, в 4 раза снижает требования по доступности шины.

И к тому же думаю, что транзакции обмена по шине идут в пакетном режиме (типа как с SDRAM-памятью): вначале - адрес, упр. инфа, потом - неск. слов данных.

И к тому-же DMA должен сперва считать эти данные в своё FIFO по шине, а потом ещё записать (опять по шине) в ОЗУ.

[Golikov 0]

ну теперь разбивкой на пакеты будет сигнал CS, который о благо в CHPA=1 режиме можно опускать на весь пакет. До этого я делал это через дополнительный проводок, синхронизовал кадр, а разбивка по длине, как и в ТСР который по сути тоже байтовый поток. Единственное что пакеты не постоянной длинны, потому что они такие приходят сверху и добивать короткие до полного - тяжко для обмена, а резать длинные на коротки - тяжко для меня)

 

Проблема в том что не известно сколько слейв будет готовить ответ на запрос, то есть нельзя утверждать что сразу будет готов ответ. Для этого тот же проводок что синхронизовал кадр использовался в другую сторону для индикации готовности данных. И только тогда мастер по SPI вычитывал ответ. С более короткими пакетами все тоже самое. То есть либо надо чтобы слейв гарантированно мгновенно отвечал - а это невозможно у него есть приоритетная задача, либо отвечал через гарантированный таймаут - что задержет обмен когда слейв не занят.

 

потому такое решение...

задаем конец кадра - слейв сбрасывает все буферы и ждет

приходить сообщение, слейв по длине определяет что оно пришло целиком, обрабатывает, готовит ответ, дает сигнал

мастер забирает и сообщает о конце кадра обмена.

 

Максимальная скорость, без накладных и задержек, и достаточно просто, как мне показалось...

 

 

И к тому же думаю, что транзакции обмена по шине идут в пакетном режиме (типа как с SDRAM-памятью): вначале - адрес, упр. инфа, потом - неск. слов данных.

И к тому-же DMA должен сперва считать эти данные в своё FIFO по шине, а потом ещё записать (опять по шине) в ОЗУ.

А я думаю что DMA пишет все фифо за раз, не зависимо от того как оно его набивало по 4 символа или по 1. Потому burst или нет тут роли не играет. Важнее как часто ДМА пытается занять шину для сброса данных в память. В burst эти акции в 4 раза реже, вроде как, может это лучше при конкуренции с другими ДМА и процом....

 

Ну надеюсь 2 канала, работающие по очереди не нагнут невозможно проц:)

 

 

 

 

 

 

[jcxz 181]

потому такое решение...

Максимальная скорость, без накладных и задержек, и достаточно просто, как мне показалось...

Ну: хозяин - барин ;)

 

А я думаю что DMA пишет все фифо за раз, не зависимо от того как оно его набивало по 4 символа или по 1. Потому burst или нет тут роли не играет. Важнее как часто ДМА пытается занять шину для сброса данных в память. В burst эти акции в 4 раза реже, вроде как, может это лучше при конкуренции с другими ДМА и процом....

Про какое FIFO Вы говорите? FIFO своё - да, думаю как только он обнаружит окно на шине, то сколько у него есть столько и передаст в ОЗУ.

А вот FIFO периферии он читает в зависимости от пришедшего сигнала (burst или single) и если burst - от заданного размера пакета в DMACCxControl.

Ведь он не знает сколько там данных. Если пришёл burst-запрос, он смотрит какой размер пакета задан у него в DMACCxControl и такую транзакцию чтения на шину и запускает.

 

Ну надеюсь 2 канала, работающие по очереди не нагнут невозможно проц:)

По общей средней пропускной способности - нет. Но могут быть кратковременные затыки.

Я когда разбирался с проблемами при работе SSP+DMA с SPI-FLASH и SPI-FRAM на частотах 20-30МГц с аппаратным SSEL (LPC1758 и LPC1778), обнаружил что общая пропускная способность обеспечивается

полностью на данных частотах, но изредка (раз в неск. секунд) на сигнале SSEL возникают короткие просечки порядка 1мкс и меньше. Поймал на осцилле.

Похоже, что иногда DMA не успевал подкачивать (или откачивать данные). Снижение частоты до 10МГц не решило проблемы, только стало реже проявляться.

Думаю, это из-за того, что CPU чаще работает из очереди предвыборки, заранее загруженной, но иногда читает из памяти (при ветвлениях в программе), и иногда могут быть

периоды времени, когда он длительное время читает только из памяти (вермишельный код из переходов).

После этого на LPC17xx я не использую больше аппаратный SSEL.

 

Но это помогает так как SSP работает в мастер-режиме. И при FIFO underflow просто приостанавливает клок. У Вас-же в слэйв это не поможет - клок слэйву не остановить,

Так что нужно быть очень аккуратным на таких частотах SSP. И вообще в слэйве.

 

У меня есть проект на LPC1758 где 7 каналов DMA могут быть заняты одновременно и 4 из них - для SSP (2 для ADS1298 и 2 для SD-карты).

И ничего - работает. Но там все SPI-слэйв с программным SSEL.

[Golikov 0]

Переписал, да чудо - чудесное. Наконец то заработало как надо, с фазой = 1 можно чип селект держать в 0 всю посылку, по нему засинхронизовал, моя довольна:)...

Теперь нет 2 стороннего проводка с медленным переключением, все полетело.

 

Попутно пересмотрел обмен и не включаю больше 1 канала ДМА, чтоб уж наверняка.

 

Пропущенные байты меня не пугаю, для того у меня и столько обвеса по детекции ошибки, сообщу на верх что обломс, пусть там принимают решение на повтор посылки.

 

 

Про ДМА вот я теперь в раздумьях... то есть между ДМА и периферией не проложены отдельные каналы, и ДМА 2 раза занимает одну и ту же шину

сначала на забор в буфер свой, а потом на выгрузку?

 

 

 

 

 

 

 

[jcxz 181]

Про ДМА вот я теперь в раздумьях... то есть между ДМА и периферией не проложены отдельные каналы, и ДМА 2 раза занимает одну и ту же шину

сначала на забор в буфер свой, а потом на выгрузку?

См. UM страница 12 (1.10 Block diagram).

А что-ж Вы думаете - к каждой периферии проложена не одна, а пачка шин по количеству bus-master-ов в МК???

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

Я только в DSP (C5502) помню двухпортовую внутреннюю ОЗУ, а 2-портовой периферии не видел нигде ;)

[Golikov 0]

однако ДМА поддерживается весьма небольшим числом блоков, потому думал может к ним проложили канал ДМА отдельно. Но не важно, даже если не так, то все блоки с ДМА за мостами AHB-APB. То есть чисто теоретически если проц не долбиться в периферию на этих шинах, ДМА может спокойно занять их и никому не помешать.

Я не прав?

 

Хотя ДМА контроллер с другой стороны и ответ будет в том как работает Multilayer AHB Matrix, если там все шины в кучу, то да пипец, конкуренция, а если есть слои, и шины коммутируемы, то все совсем по другому...

[jcxz 181]

однако ДМА поддерживается весьма небольшим числом блоков, потому думал может к ним проложили канал ДМА отдельно.

Как это - небольшим? Вы неправы. Любая точка адресного пространства, доступная CPU, доступна и DMA.

 

Но не важно, даже если не так, то все блоки с ДМА за мостами AHB-APB. То есть чисто теоретически если проц не долбиться в периферию на этих шинах, ДМА может спокойно занять их и никому не помешать.

А Вы посмотрите на сегменты шин к RAM. Если CPU непрерывно обращается к этой памяти, то DMA всегда будет получать отлуп.

Такая ситуация думаю может быть если CPU крутится в коротком цикле исполняя код из данного сегмента ОЗУ. Тогда он постоянно делает предвыборки из-за условных переходов.

но вобщем - всё это гадания на кофейной гуще....

[Golikov 0]

Доступ к периферии у ДМА ограничен, не знаю можно ли достучаться в нее как обмен память-память, но как обмен периферия - что и обратно, число блоков невелико,

на той же схеме желтеньким отмечено

 

 

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

 

 

 

 

[jcxz 181]

Доступ к периферии у ДМА ограничен, не знаю можно ли достучаться в нее как обмен память-память, но как обмен периферия - что и обратно, число блоков невелико,

на той же схеме желтеньким отмечено

Нет. Жёлтым отмечена периферия, которая может генерить сигналы DMA-запросов. Только и того.

А работать (осуществлять обмен) GPDMA может с любой периферией.

Я работал и с SPI и с GPIO через GPDMA.

 

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

Да, думаю - для того и задумывалось. Ну не считая того, что 32К блок отколючается в sleep (или наоброт - не отключается в sleep, запамятовал ;)

[Golikov 0]

написано что периферийный блоки поддерживающие GP_DMA

GPIO и SSP входит. SPI - нет. В таблице запросов тоже нет. Нет запроса нет передачи.

 

Конечно можно через адресное пространство, адрес - адрес и по какому, нибудь таймеру, но это уже извращения)

 

 

Ну в целом понятно.

[jcxz 181]

написано что периферийный блоки поддерживающие GP_DMA

GPIO и SSP входит. SPI - нет. В таблице запросов тоже нет. Нет запроса нет передачи.

Конечно можно через адресное пространство, адрес - адрес и по какому, нибудь таймеру, но это уже извращения)

Тем не менее SPI+GPDMA+таймер - работало на ура ;)

Это не извращение. По другому было никак - SPI-слэйв работает на большей частоте, чем SSP-слэйв. Нам SSP не хватало по частоте.

[Golikov 0]

а синхронизация как? Прерывание по первому пришедшему байту?

SSP - мастер быстрее SPI мастера, а SSP slave медленнее... чудно:)

 

я все думал зачем они 2 одинаковых модуля в проце держат...

[jcxz 181]

а синхронизация как? Прерывание по первому пришедшему байту?

Точно уже не помню.

Вроде так:

спад CS - в ISR от GPIO программируем цепочку SPI+GPDMA+таймер;

сигнал SCLK заводим на счётный вход таймера, его настраиваем на сброс и генерацию DMA-request каждый 16-й клок (16 битные слова).

Размер блока был фиксированный и заранее известный - по прерыванию от завершения DMA отключаем всё хозяйство.

Данные шли от FPGA с нашей прошивкой, так что была возможность в ней сделать увеличенную паузу от спада CS до начала SCLK, чтобы

всё успело запрограммироваться. Но при необходимости можно было сделать и предварительное программирование цепочки SPI+GPDMA+таймер

по фронту предыдущего CS.

 

SSP - мастер быстрее SPI мастера, а SSP slave медленнее... чудно:)

Так SPI - проще - транзисторов и паразитных емкостей меньше, поэтому наверное и быстрее :laughing:

[бомж 0]

Всем привет!

 

Есть такая проблемка на LPC1768 настроен SSP в режиме slave

...

 

Как почистить кроме входного еще и выходной SPP FIFO?

 

Я вот так справился с такой проблемой:

 

void clear_buffer_ssp0 (void)
{
    uint8_t Dummy;
    
    Dummy = Dummy;
    
    /* Clear all remaining data in TX FIFO */
    while (1){
        if (LPC_SSP0->SR & SSP_SR_TFE) break;
        Dummy = LPC_SSP0->DR;                  //equating the SPDR to Dummy Varaible
    }  
}

[Golikov 0]

Я вот так справился с такой проблемой:

ну плохо вы справились и не с той проблемой...

 

читая из регистра данных вы вычитываете входные данные а не выходные - это первая ошибка

while(1) - это вторая ошибка

делать такое для SSP-slave - третья ошибка

не утруждать себя попытками понимания задачи - четвертая ошибка

 

Ну а в целом вы молодец, спасибо что ответили...;)