В микроконтроллерах серии Atmel SAM-D21 многие периферийные устройства используют тактовую частоту, которая является асинхронной по отношению к основной тактовой частоте ЦП, и доступ к этим периферийным устройствам должен проходить через логику синхронизации; на периферийных устройствах, часы которых работают медленнее, чем время процессора, это может привести к большим задержкам. Например, если RTC настроен на использование тактовой частоты 1024 Гц (что, как представляется, является намерением проекта), а процессор работает на частоте 48 МГц, чтение регистра «текущего времени» приведет к тому, что логика шины вставит более 200 000 состояний ожидания (минимум из пяти циклов тактовой частоты 1024 Гц). Хотя процессор может выдать запрос на чтение, выполнить какой-то другой несвязанный код и вернуть более 200 000 циклов позже, чтобы извлечь время, похоже, нет никакого способа на самом деле прочитать время быстрее.
По моему пониманию синхронизации, однобитовая схема синхронизации будет задерживать сигнал на 2-3 такта тактового генератора; Синхронизация многобитовой величины немного сложнее, но существует множество подходов, которые могут гарантировать надежное поведение в течение пяти циклов тактового сигнала назначения, если он быстрее, чем тактовый генератор источника, и всего на несколько циклов больше, если это не так. Что бы сделал Atmel SAM-D21, для синхронизации которого потребовалось бы шесть тактов в исходной тактовой области, и какие факторы будут благоприятствовать конструкции, задержки синхронизации которой настолько велики, что требуют прерывания «сделано синхронизацией», а не того, который обеспечивает Задержки синхронизации достаточно короткие, чтобы сделать такие прерывания ненужными?