Подскажите как организовать правильно сигнал выборки для ведомого в 2012.
Делаю так засылаю "0" на ножку выборки. Потом засылаю байт в SPI. Поднимаю ножку выборки в "1".
После проверку скопом получаю что сигнал выборки и байт данных не совпадают по времени.
Байт по SPI прошел потом только прошла выборка.

Перд поднятием сигнала выборки надо дождаться завершения передачи, это можно сделать, анализируя TXIFG, либо UCBUSY.

Странно что эти биты не прописаны в Хедерах.
Да и самих регистров USCI_A тоже нет.

В MSP430F2012 нет модуля USCI. Там имеется только модуль USI. Отличия их в том, что USCI поддерживает как синхронные (SPI, I2C) так и асинхронные (UART, IRDA) интерфейсы, аналогично модулю USART в предыдущих сериях MSP430 (1xx, 3xx, 4xx) . В то время как модуль USI поддерживает только синхронные - SPI и I2C. Так что jorikdima просто ошибся. Перед тем, как снимать активный уровень CS нужно дождаться установки флага USIIFG в регистре USICTL1, который будет сигнализировать о том, что транзакция/обмен байтом/словом данных завершился. Ну либо считывать значение счетчика бит USICNT, дожидаясь, пока он не обнулится. Хочу напомнить, что SPI это интерфейс для обмена данными. Для того чтобы что-то получить, нужно что-то передать (фиктивная передача при приеме).

Спасибо пока остановился на проверке счетчика.
Помогло но не полностью. Проблема в том что проверку можно сделать после передачи.
А как ее сделать красиво до не понятно. Данные уходят быстрее чем я выборкой счёлкаю.
Пока остановился на таком решении опустил выборку, подождал, проверил, поднял.
Но цикл ожидание после выборки мне не нравиться.

Альтернативный опросу способ - работать по прерыванию от USI. Только вот непонятно вы по 1 байту/слову передаете или у вас некоторый фрейм (кадр) данных? Есть 1 байт/слово, то почему опрос смущает? Вы же сами пишете, что передача быстрее, чем цикл опроса происходит. Прерывание возможно будет излишним в таком случае, т.к. на обработку прерывания накладные расходы 9+ циклов MCLK.

Передаю только один байт.

Как оказалось все просто.
Но почему то сразу не получилось.
Вот таким вот кодом времянка получилась ничего.
Только один всплыл баг. Первая посылка имеет 8 синхро, а вот вторая и последующие 12.


вот кусок кода.

Вот это можно занести и в FAQ.
Проверять счетчик USICNT нельзя. Каждая проверка добавляет два синхро импульса.
Проверять нужно только USIIFG.

А баг под номером USI5 описанный в Errata разве не этот случай?

Нет не тот!!!
Этот баг добавляет один лишний синхро сигнал при первой посылке.
Если воспользоваться советом TI и заслать в счетчик n-1 данные портятся, смещаются.