Вообще-то "дробные" частоты получить очень просто: если записать в BRR 0x33, то UART на один бит отмолотит 3 целых 16 тактовых интервала, а потом еще 3 такта Fbus (всего 51). Т.е. если считать базовой частоту Fbus/16, то делитель действительно можно называть дробным (в данном случае 3.1875). А если базовой взять Fbus то никаких дробей нет, делитель просто считает от 0 до BRR, т.е. делитель - 51.

Это UART, а не SPI он не может так работать - ему надо 16 клоков на бит.

Кто ж ему помешает-то? 16 клоков нужны только для надежного обнаружения стартового бита ака ресинхронизации, так они на месте - меньще 0x10 в BRR писать нельзя.

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

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

А ножки на 50 MHz настроили?

Да, конечно. Не стал приводить для краткости.

По крайней мере SAM7 семейство от Атмел имеет для асинхронного режима дробный делитель.

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

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

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

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

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

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

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

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

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

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

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

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

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