А соглано описания на датчик, если в средине передачи придет высокое на выборку кристалла - то начинай все сначала.
У кортекса на всех картинках по краям фреймов выборка высокая.
Извините, не удержался. Больше не буду.

Или нет. Как сделаете. Вариантов сделать целых два. Один годится для любого количества фреймов, другой для количества не превышающих размер FIFO. Дальше самостоятельно.

Переключите сигнал CS в режим софтового управления, и дёргайте его так, как необходимо.

Вы совсем новичок в контроллерах?
Такие элементарные вещи спрашиваете...

Вы наверно вопрос не поняли.
Я не справшивал, как SPI программно сделать.
Я спрашивал - можно ли задействовать аппаратный SPI.
Если мне программно дергать выборкой кристалла, то и сдвиг битов тогда проще задействовать програмный.

Как и обещал, сообщаю - очередная дежурная глупость.
SPI, как был, так и остается аппаратным и при "софтовом управлении" CS. В этом смысле управление CS ничем не не софтовей той-же записи в регистр данных. Кроме того, лично я поминал ДВА способа.

Это Вы про slave режим контроллера?
Вроде на картинках нет мастера при котором выборка вначале выдачи выставляется а при опустошении очереди - снимается.
Там все режимы - во первых с пропуском между фреймами во вторых со снятией выборки между фреймами.
Или у нас разные описания?

Master. Описания одинаковые. Способность к пониманию написанного разная . Если чего не понятно, и мучают сомнения, то можно проделать небольшую лабораторную работу - очень помогает разобраться в нюансах поведения в конкретных условиях.

vallav, вам объясняют про использование аппаратного SPI и программного управления сигналом CS. Ну не программируйте вы пин SSELx, соответствующий сигналу CS на альтернативную функцию от SPI! Оставьте его как пин, выполняющий функцию GPIO, программно сбрасывайте перед началом фрейма и устанавливайте по окончании передачи фрейма по SPI. SCKx, MISOx, MOSIx используйте аппаратные, SSELx аппаратный не используйте, ферштейн?

Да в курсе я - что именно мне объясняют.
Меня интеоесовало - аппаратно, на собственных пуговицах без программных помочей SPI штаны от lpc17xx на данном датчике
носятся?
Ответ, как я понял такой - нет, не носятся.
И только после этого следующий вопрос - а какие именно программные помочи нужны?
Мне же почему то на первый впрос отвечают мысленно, мысленно же слышат от меня второй вопрос и начинают сразу отвечать
на него.
Я второго вопроса не задавал!
Я на него ответ знаю. Вернее, почти знаю.
Так как в железе еще не проверял.

Но мне интересней другое - почему никому не интересен предложенный способ связи контроллера с компьютером по USB?
Такой вариант - ОЗУ контроллера как стандартный диск компьютера - когда в общую область ОЗУ контроллера компьютер пишет и читает
как в обычный диск а контроллер пишет и читает как обычное ОЗУ - чем то не удобна или давно реализована и широко используется?
Но тогда зачем повсеместно применяется это уродство - эмуляция UARTа?
Это примерно то же самое, что использование JTAGа для заливки во флешь - неудобно, но работает...

Ответ, как всегда, не воспринят. Третий раз уже , да именно SSP в LPC может.
Хотя стандарный вариант для любых SPI контроллеров это именно софтовая отметка фрейма. Сюрприз для ламеров!. Режим работы с фреймом произвольного размера очень очень распространен - любое более-менее сложное или быстрое Slave устройство на SPI или поддерживает, или прямо требует такой режим работы. В этом случае отмашка SSEL совершенно естественно отмечает начало фрейма произвольного размера. Аппаратная байтовая махалка, не более, чем полезный, но один из многих, режимов работы. Лично я в своих периферийных SPI устройствах предпочитаю использовать вариант, когда SSEL может быть снят в любой момент во время передачи полного фрейма, ибо за начало фрейма принимается переход SSEL в Lo. Если протокол не содержит размер фрейма, то тогда снятие SSEL разрешается производить и в любой момент передачи последнего байта.

Утомили своей детской радостью дежурного "первооткрывателя". Ответ простой - потому, что он дебильный.

Давайте, после того, как наконец-то нашли кнопку в IDE скомпилировать некий проект, заканчивайте писать кипятком от радости, даже не поднимая RAM диск попробуете пообщаться с компьютером через имеющийся Flash диск. Узнаете еще много интересного о том, как строятся файловые системы, оптимизация обращений и кэширования. Чем и насколько серьезно отличается поддержка системами, например, сетевых дисков от поддержки флешек-свистков.

Вы вроде собирались только мои ошибочные заявления отмечать?
Или все же поучить сильно тянет?

Похоже с реализацией USB RAM диска и общения через него придется самому заниматься.
Непопулярный это вариант оказался...
По каким то причинам туда и назад по UART считается более удобным, быстрым и надежным...

Вы видимо не очень хорошо знакомы со спецификацией USB и со спецификой работы ОС с USB-устройствами класса MassStorage.

Ага. Не очень хорошо знаком.
Вот поэтому и спрашиваю.
То. как работает код из аппноты - очень понравилось.
В чем Вы видите подводные камни, в случае, если в файлы будет отображаться не флешь а
ОЗУ контроллера?
Контроллер будет писать/читать в ОЗУ напрямую, комп писать/читать туда через файлы.
Преимущества - приличная скорость, простота подключения, отсутствие специальных драйверов.
Недостаток - израсходуется аж челых 8 килобайт флеши из имеющихся 512.
Других недостатков пока не вижу.
Хотя бы пару конкретных примеров реальных заморчек, если не трудно.
Ответы общего плана, типа - ты ламер, у тебя уши холодные, я супер а ты хто - не интересны...
Варианты - а если контроллер или комп не то и не туда запишут - тоже...

Кстати, не могли бы присвести для справки - сколько времени пишется и читается файл в 400 килобайт в флешь контроллера
через столь любимый здесь JTAG?
У меня получилось - читается около секунды, пишется около 5 секунд.

Сообщение отредактировал vallav - Jun 3 2010, 13:47

Пытаюсь разобраться, почему родной бутлоадер не запускает прогу, у которой startup слинкован в ОЗУ ( второе слово в флеше указывает
на ОЗУ ) а бутлоадер из аппноты запускает.
Пока докопался до такого - это происходит похоже из за ошибки в бутлоадере из аппноты.
Там вместо *((int *)0x2000+1) стоит 0x2000+1.
И вместо вызова подпрограммы по адресу, равному содержимому в ячейке флеша по адресу 0x2004 ( то есть, уход в неинициализированное
ОЗУ ) делается вызов подпрограммы
по адресу 0x2000. Процессор продирается через таблицу прерываний и попадает в код за таблицей, который и делает то, что нужно
для запуска.
Пользовательская прога грузится в флешь начиная с адреса 0x2000 и там - начало таблицы прерываний.
Дебагер в Кейле меня уже достал. Он такой из за того, что я его пока еще не крякал или он и по жизни такой?

Вообщем разобрался. На самом деле такая история, как в предыдущем посте описано.
Так что ответ на вопрос о начальной загрузке такой - не линкуйте startup в ОЗУ - нечего ему там делать. Только ОЗУ зря занимает.
Вдруг или бутлоадер будет без ошибки или в таблице прерываний попадется значение, которое или зациклит проц или выкинет его куда
подальше и до кодов иничиализации он не дойдет.

А загрузка происходит так - бутлоадер, сделав необходимые проверки ( заливалась ли флешь в первые 8 слов из правильного
заливщика, и несколько других, передает управление по значению во втором слове флеша. Этот код ( а начинается он сразу после окончания
таблицы прерываний ) делает нужные пересылки и инициализации ( например, загружает sp значением из первого слова флеша, пересылает
код и данные в ОЗУ ) и предает
управление на main - которая, кстати может быть слинкована в ОЗУ.

Очередной вопрос по USB. Кто нибудь проверял - какой диапазон отклонения тактовой от 48 мегагерц допустим?
Не по спецификации а в реалии? Интересует - можно ли не ставить внешний генератор а работать на IRC?