LPC1768 + AT45DB с использованием SSP Опции

[TAutomatic]

Добрый день, коллеги.
Волею судьбы пришлось использовать ARM в разработке. Столкнулись с такой проблемой. Нужно связать LPC1768 и AT45DB321. Опыт работы с этой датафлеш есть предостаточный, но все на PIC. Так вот, в чем проблема. Если использовать модуль SPI, вопросов не возникает, рабочий код для PIC был портирован практически без изменений и работает. Все бы ничего, но скорость обмена не более 12МГц. Датафлеш позволяет обмениваться быстрее, что собственно и нужно. При использовании SSP возникают нюансы, а именно: включается буфер FIFO глубиной 8 слов. Пока он не заполнен до верху, получается, невозможно считать данные. Допустим, кто знаком с работой датафлеши, на запрос о статусе надо принять всего единственный байт. Невозможно его получить, пока 8 раз не запросишь. Это разве удобства? А если выполнить блочное чтение, значит, нужно читать на 8 байт больше, что бы считать на вершине буфера свой нужный последний? Или я чего-то не понимаю? Почему у модуля УАРТ можно указать глубину буфера Фифо, тут нельзя. Как дали, так и кушать? Может кто подскажет, как проще выкрутиться? Заранее спасибо.

[DmitryM]

Допустим, кто знаком с работой датафлеши, на запрос о статусе надо принять всего единственный байт. Невозможно его получить, пока 8 раз не запросишь.

А какже следующее замечание для AT45DB321?
"After the one byte of the status register has been clocked out, the sequence will repeat itself (as long as CS remains low and SCK is being toggled). The data in the status register is constantly updated, so each repeating sequence will output new data."
Читайте себе на здоровье пока фифо не заполнится без перезапросов.

[TAutomatic]

А какже следующее замечание для AT45DB321?
"After the one byte of the status register has been clocked out, the sequence will repeat itself (as long as CS remains low and SCK is being toggled). The data in the status register is constantly updated, so each repeating sequence will output new data."
Читайте себе на здоровье пока фифо не заполнится без перезапросов.

Это замечание справедливо, и я им пользуюсь. После выдачи команды я в цикле посылаю только байт синхронизации 0xFF уже без команды, в отличии от коллеги, который привел кусок кода. Спасибо ему. Ну так и у меня заполняется буфер фифо, и рано или поздно я получаю искомый байт статуса. Считаете, это нормально? Вот таким образом неэффективно строить обмен? Вместо одного байта посылать 8 для получения результата? Это не мой метод. Должно быть красивое решение. Наверняка оно есть. Я знаток пиков, там все работает гуд, программируется и настраивается легко. Наверно и в ARM тоже все нормально, простоя пока мало знаком с ним.

Дык один раз подождал пока фифо не заполнилось и ушел заниматься полезным, если условие не удовлетворило, потом еще раз прочитал. Наверняка там еще и прерывание по заполнению фифо можно задействовать, если уж так пендитно ко времени простоя.

Не все так просто. Если бы можно было бы изначально заполнить и не париться- вопросов не возникло бы. Дело в том, что отправка команд и данных в сторону датафлеши вызывает прием в буфер данных типа 0xFF. Поэтому перед каждой операцией получения данных надо заново перезаполнять буфер. Или читать на 8 байт больше, чем нужно. Это хорошо с чтением данных или статуса, который можно прочитать в цикле несколько раз подряд и им заполнить буфер. А что делать с другими командами? несколько раз подряд их запрашивать? Нет, это неэффективно. Коллега прав, если у него работает, значит работает вообще, и у меня будет работать. Вот только где ошибка?