[Flexz 0]

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

[KRS 1]

А если базовой взять Fbus то никаких дробей нет, делитель просто считает от 0 до BRR, т.е. делитель - 51.

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

 

[Flexz 0]

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

[AHTOXA 18]

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

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

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

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

[ViKo 1]

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

[AHTOXA 18]

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

[Alecsej 0]

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

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

[_pv 79]

То есть, максимум 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 18]

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

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

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

что позволяет более гибкую настройку частоты.

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

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

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

[_pv 79]

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

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

просто пользователю дали не поделенную как обычно на 16 частоту, которую дальше можно только поделить на 2,3, ... то есть baudrate будет F/16, F/32, F/48,

а позволили просто делить и на 17, 18, 19... тоже. при этом бит всё равно где-то примерно посередине сэмплируется, ну теперь не ровно по середине, а в 8/17 например, не велика разница, зато частота гораздо гибче настраивается.

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

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

[AHTOXA 18]

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

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

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

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

[Aner 8]

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

 

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

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

[AHTOXA 18]

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

[Aner 8]

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

[ViKo 1]

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

Но сейчас вы экспериментируете без помех? А если не получили подтверждения о правильном приеме, передаете еще раз? Или как еще можно объяснить замедление передачи на высоких скоростях?

Что, если на время пересылки не разрешать процессору бегать по программе (обращаться к Flash программы), а оставить в цикле, проверяющем окончание передачи? Все команды будут читаться из буфера, нагрузка на шины меньше.

Там, где обсуждалось про F/N, я предлагал рассчитывать скорости с округлением результата. Не просто F/N, а (F + N/2)/N. Может, вы уже подобрались к скоростям, когда дробную часть от деления просто отбрасывать нельзя?