Тактовая частота МК (ядра) и частота, используемая для передачи данных по какому-нибудь интерфейсу - разные вещи.
Первая задается либо встроенным RC осцилятором (обычно, ниже максимально возможной и менее стабильна, чем от кварца), либо внешним кварцевым резонатором, а далее преобразуется делителями и/или PLL синтезаторами до нужных для конкретных блоков МК/периферии. Она означает только то, с какой скоростью ядро может выполнять отдельные инструкции или, точнее, сколько времени длится один такт (в некоторых архитектурах выполнение определенных инструкций занимает больше одного такта).
Вторая задается, собственно, протоколом/стандартом интерфейса. Интерфейс - это не только договоренность о стартовых битах, маркерах и т.д. в передаваемых данных, но и об уровнях напряжений, видах модуляции, допустимых уровнях шумов и, в т.ч. "частотах". Только о последних принято говорить "тайминг", т.к. стандарты задают допустимую точность соблюдения временных интервалов, а уже какие для этого нужны частоты - вопрос производный. А все это, вместе взятое, принято называть интерфейсом. Кроме того, для передачи данных само понятие "частота" вторично - гораздо важнее понятие
Baud rate, означающее (упрощенно!) "скорость передачи информации" по определенному протоколу, которая, согласно теореме Шеннона-Хартли, меньше или равна половине той самой реальной "частоты передаваемого сигнала"... кототрой, на самом, деле нет, как таковой. Попробую объяснить, что это значит.
"Попадание в такт" урегулировано протоколом интерфейса и не зависит от момента, когда включили приемник или передатчик, а только от того, когда передатчик решит начать передачу. Если совсем на пальцах... В простейшем случае кто-то из них (например, передатчик) в какой-то момент времени изменяет уровень на своем
выходном пине, например, с LOW на HI. К нему физически подключен
входной пин приемника. Он "видит" изменение уровня и этот факт либо отлавливается программой, постоянно опрашивающей состояние этого входного пина, либо, еще лучше, изменение уровня вызывает прерывание, в коде которого принимающая программа может соответствующим образом на это отреагировать... например, принять один бит. А передатчик, тем временем, изменит HI на LOW, и потом все повторится. Минимальное расстояние во времени между такими изменениями, которые, при цифровой передаче происходят совсем не равномерно, (как, например, в радио с амплитудной модуляцией) и будет означать ту самую "частоту передачи". Но в реальности нет никакой конкретной постоянной частоты - есть импульсы разной длительности, т.е. изменения уровня напряжения с высокого на низкий и наоборот, следующие через разные промежутки времени. Так что, при цифровой передаче данных говорить можно только о
теоретической максимальной частоте.
Для того, чтоб приемник и передатчик могли стабильно соблюдать тайминг, определенный стандартом интерфейса (т.е. успевать распознать эти изменения, ничего не пропуская), их собственная тактовая частота должна это в принципе позволять, т.е. быть больше "частоты передачи данных" (если протокол реализован в виде программы для ядра, оно должно, как минимум, успеть выполнить какие-то инструкции прежде, чем может произойти следующее изменение уровня, на которое нужно будет реагировать). Иногда, особенно, в простых МК, она, кроме того, должна быть кратной этой частоте с определенным коэфициентом. Ядро МК может работать на разных тактовых частотах - вплоть до максимальной, ему, собственно, почти безразлично, на какой именно. Но т.к. большинство частот внутри (на входе счетчиков таймеров или других схемотехнических блоков) получаются из основной тактовой, то если она не будет кратной "частоте передачи", в какие-то моменты времени приемник и передатчик будут рассинхронизироваться, т.е. не успевать распознать и прореагировать на какие-то импульсы, т.к. их ядро в этот момент будет занято чем-то другим. Это, конечно, в большинстве случаев будет отловлено и исправлено самим протоколом (для этого их и придумывают), но, на практике будет означать либо медленную, нестабильную передачу, либо вообще невозможность передачи. Таким образом, для простеньких МК, если они должны работать с UART, особенно, на больших скоростях, подойдет не всякий кварц с частотой меньше или равной максимальной, а только с определенными частотами. (А если они, например, должны максимально стабильно отсчитывать календарное время без синхронизации с внешним источником точного времени, подойдет другой кварц с т.н. "часовыми" частотами...) Короче, в определении того, какая конкретно тактовая частота МК будет достаточной/необходимой в каждом конкретном случае, нет никакой магии - только простая арифметика и внимательное изучение даташитов и application notes.
В современных МК периферия, реализующая стандартные интерфейсы (типа простых UART, USB, I2C, CAN и т.д.) давно уже отвязана от ядра. Именно для того, чтоб освободить пользователя, т.е. программиста МК, от всех этих заморочек... но "внутри" там все то же самое, только, конечно, сложнее, а в протоколах, типа Ethernet или Bluetooth, под чисто цифровым уровнем скрывается еще и навороченный физический, со всякими модуляциями и поляризациями, где понятие "частоты передачи" имеет прямой смысл... только туда без, хотя бы, поверхностных знаний физики, электро- и радиотехники, лучше вообще не соваться ))
Однако, наличие в МК готовой периферии не исключает возможность взять и самостоятельно реализовать некоторые из этих протоколов, для которых достаточно тактовой частоты МК, в виде программы для ядра... например, для того же UART. Сделать это совсем не сложно, но совершенно необходимо для понимания их устройства. На эту тему есть тонны статей, туториалов и разжеванных примеров (от
использования периферии, и вплоть до
самостоятельной реализации).
