STM32F1xx, UART на 10МБит - осуществимо? Опции

[AHTOXA]

Всем привет.
STM32F1xx, 72МГц, UART3 (тактируется от 36 МГц). Пытаюсь достичь высоких скоростей. И что-то не получается.
Отправляю блоки ~512 байт, через DMA.
Инициализация:

Код

    RCC->APB1ENR |= RCC_APB1ENR_USART3EN;
    USART3->BRR = 36000000 / BAUDRATE;
    USART3->CR1 =  USART_CR1_TE;      // transmit enable
    USART3->CR2 = 0;
    USART3->CR3 = USART_CR3_DMAT;   // no flow control, enable TX DMA
    USART3->CR1 |= USART_CR1_UE;      // enable USART

    // UART interrupt
    NVIC_SetPriority(USART3_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(), 2, 2));
    NVIC_EnableIRQ(USART3_IRQn);

    // DMA
    RCC->AHBENR |= RCC_AHBENR_DMA1EN;
    DMA1_Channel2->CPAR = (uint32_t)&USARTx->DR;
    DMA1_Channel2->CCR = 0
            | DMA_CCR1_MINC             // Memory increment mode
            | DMA_CCR1_DIR               // Read from memory
            | DMA_CCR1_PL_0             // Channel Priority level
        ;

Отправка блока:

Код

void sendBuf(const void* buf, size_t size)
{
    // clear all interrupts on DMA TX channel
    DMA1_Channel2->IFCR = DMA_ISR_GIF2;
    // set memory address and size
    DMA1_Channel2->CMAR = (uint32_t)buf;
    DMA1_Channel2->CNDTR = size;

    // Clear USART transmission complete flag:
    USART3->SR &= ~USART_SR_TC;
    // enable DMA channel
    DMA1_Channel2->CCR |= DMA_CCR1_EN;;
    // enable UART TC interrupt
    USART3->CR1 |= USART_CR1_TCIE;

    // wait for transfer complete
    txDmaDone_.wait();
    // disable DMA channel
    DMA1_Channel2->CCR &= ~DMA_CCR1_EN;;
}

Ну и прерывание от UART:

Код

void USART3_IRQHandler()
{
    uint16_t status = USART3->SR;
    if (status & USART_SR_TC)
    {
        // clear interrupt
        USART3->SR &= ~USART_SR_TC;
        // disable it
        USART3->CR1 &= ~USART_CR1_TCIE;
        // and flag transmission done
        txDmaDone_.signal_isr();
    }
}

Вот. Всё весьма незамысловато. И до скоростей порядка 2МБит это замечательно работает. А вот после - начинается нечто странное. Чем больше скорость, тем больше время отправки блока. На скорости 3.6МБит отправка блока длится несколько (около 4х) секунд. При дальнейшем увеличении скорости отправка вообще перестаёт завершаться.

Такое впечатление, что обмен по DMA становится слишком интенсивным, и полностью забивает шину.
Поэтому у меня вопрос: это я натолкнулся на ограничения железа? Или я что-то делаю не так?
Кто-нибудь имел дело с такими скоростями UART, и насколько успешно?

[AHTOXA]

К сожалению, шину, на которой сидит UART, нельзя разгонять выше 60 МГц.

То есть, максимум 7.5 МБит? Это хуже чем 15, но лучше, чем 2.25

Интересная интерпретация, но формула BRR = Fbus / BaudRate говорит о том, что регистр всё-таки задаёт частоту битов UART. Поэтому какая-та заморочка с тактированием там должна быть, чтобы получить дробные частоты. Сигма-дельта или что-то такое.

Скорее, там где-то есть неявное предварительное умножение F_BUS на 16. Дробные - сильно сомневаюсь. (Нечто похожее на дробные скорости встречал только у MSP430, и то, там это надо было задавать руками в виде битовой маски добавочных тактов по битам.)

[_pv]

То есть, максимум 7.5 МБит? Это хуже чем 15, но лучше, чем 2.25
Скорее, там где-то есть неявное предварительное умножение F_BUS на 16. Дробные - сильно сомневаюсь. (Нечто похожее на дробные скорости встречал только у MSP430, и то, там это надо было задавать руками в виде битовой маски добавочных тактов по битам.)

максимум 4.5 на 72МГц.
нет там умножения, просто при делении на 16 разрешили выбирать скорость не как обычно после деления на 16: F/16/N, а просто как F/N, при N>16.
что позволяет более гибкую настройку частоты.

если надо только передавать, а с другой стороны принимать будет кто-нибудь с УАРТом по-быстрее, то можно передатчик от SPI задействовать, только буфер нужен будет в два раза больше под 16ти разрядные данные и руками надо будет по нему пробежаться и стартовые биты в каждый байт добавить.
из него тогда и 72/2/2 = 18МБит вроде выжать можно.

[AHTOXA]

максимум 4.5 на 72МГц.

Это мы уже про F2xx.

нет там умножения, просто при делении на 16 разрешили выбирать скорость не как обычно после деления на 16: F/16/N, а просто как F/N, при N>16.
что позволяет более гибкую настройку частоты.

Ну как же нет? При делении F_BUS на BRR мы получаем BAUDRATE (время одного бита). Откуда тогда берётся частота семплирования 16 раз на бит?

если надо только передавать

Нет, к сожалению, принимать тоже нужно.

[_pv]

Ну как же нет? При делении F_BUS на BRR мы получаем BAUDRATE (время одного бита). Откуда тогда берётся частота семплирования 16 раз на бит?

ну меньше чем на 16 всё равно делить нельзя.
просто пользователю дали не поделенную как обычно на 16 частоту, которую дальше можно только поделить на 2,3, ... то есть baudrate будет F/16, F/32, F/48,
а позволили просто делить и на 17, 18, 19... тоже. при этом бит всё равно где-то примерно посередине сэмплируется, ну теперь не ровно по середине, а в 8/17 например, не велика разница, зато частота гораздо гибче настраивается.

Нет, к сожалению, принимать тоже нужно.

тогда максимум 4.5Мбит.

[AHTOXA]

ну меньше чем на 16 всё равно делить нельзя.

Ну да, вы всё очень хорошо расписали. В BRR оставили запас в 16, для того, чтобы можно было его поделить на 16 (и тем самым умножить частоту семплирования на 16 - это как раз то, о чём я и говорю ).

тогда максимум 4.5Мбит.

Или 7.5 у F2xx, или 10.5 у F4xx.

[Aner]

Ну да, вы всё очень хорошо расписали. В BRR оставили запас в 16, для того, чтобы можно было его поделить на 16 (и тем самым умножить частоту семплирования на 16 - это как раз то, о чём я и говорю ).

Или 7.5 у F2xx, или 10.5 у F4xx.

Все же ... зачем вам это нужно? ... не практично это, ... есть куча вариантов лучшиих решений по передаче данных на этих 4XX чипах.

[AHTOXA]

Мне надо быстро сливать большой объём данных с одного устройства на другое, кабель - метра три, жил - желательно поменьше. Вокруг будут помехи, так что USB не катит. Какие ещё у меня варианты, кроме быстрого RS-485?

[ViKo]

Мне надо быстро сливать большой объём данных с одного устройства на другое, кабель - метра три, жил - желательно поменьше. Вокруг будут помехи, так что USB не катит. Какие ещё у меня варианты, кроме быстрого RS-485?

Но сейчас вы экспериментируете без помех? А если не получили подтверждения о правильном приеме, передаете еще раз? Или как еще можно объяснить замедление передачи на высоких скоростях?
Что, если на время пересылки не разрешать процессору бегать по программе (обращаться к Flash программы), а оставить в цикле, проверяющем окончание передачи? Все команды будут читаться из буфера, нагрузка на шины меньше.
Там, где обсуждалось про F/N, я предлагал рассчитывать скорости с округлением результата. Не просто F/N, а (F + N/2)/N. Может, вы уже подобрались к скоростям, когда дробную часть от деления просто отбрасывать нельзя?

[AHTOXA]

Но сейчас вы экспериментируете без помех?

Да, сейчас помех нет.
Скорость падала потому, что я заносил в BRR значение меньше 16. Я не смотрел осциллографом, но, по всей видимости, скорость стала какая-то ооооочень маленькая от этого

Не просто F/N, а (F + N/2)/N.

Да, у меня именно (F + N/2)/N. В примере упростил для большей прозрачности.

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

Не только подобрался, но и перебрался))

Однозначно, без проблем - Ethernet 100M.

Да нет, проблема есть, и очень серъёзная. Я не уверен, что смогу быстро подобрать быстроразъёмные соединения и кабеля IP65 для Ethernet. (У меня ещё и агрессивная среда)

[ViKo]

Скорость падала потому, что я заносил в BRR значение меньше 16. Я не смотрел осциллографом, но, по всей видимости, скорость стала какая-то ооооочень маленькая от этого

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