roboforum.ru

задача оцифровывать сигнал с большой скоростью (>100Ksps) и приличной точностью (12bit)
нашел ацп позволяющий при точности 12бит измерять до 500К
интерфейс у ацп spi, передает по 16 бит
для такой высокой скорости программный способ реализации spi не подходит, значит необходимо воспользоваться аппаратным.
в atmega он есть, но только 8ми битный
как быть ? необходимо совместить скорость аппаратного и возможность принимать 16 бит программно
кто-нибудь делал подобное ? Очень не помешал бы пример реализации этого дела.

немножко коррелирует с темой, но там второй день молчание http://roboforum.ru/viewtopic.htm?t=2789

SID убераем из ссылки! <V>

p.s. постарался резюмировать тему в самом конце.

я непонимаю в чем проблема со спи 16 бит.
былабы проблема еслиб нужно было 12 бит (только 12 импульсов sck)

а так вам никто не мешает послать два байта не снимая CS

с атмегой сомневаюсь ...  если даже примет то куда денет ???

Обычно на плис делают сопряжение быстрого АЦП с буферной памятью. так в цифровых осциллографах. а потом не спеша считывают из памяти.

нужно принять, а не передавать



к сожалению надо долго снимать, никакой памяти не хватит

предполагается, что почти сразу скидывает в комп, не накапливая данные

Тогда вообще просто - берем ПЛИС и втыкаем в PCI. Примеры PCI-устройств в сети есть и довольно много.  :wink:  Контроллер тут не лучшее решение... Если лень возиться с ПСИ - то просто на Альтере сделай конвертер из SPI в параллельный и втыкай в LPT-порт. У него скорость что-то вроде 8 килобит в секунду - думаю покатит. Только вот успеешь ли ты на компе такой поток обработать?

нет скорости хватит только на usb пожалуй, lpt тут слабоват.
комп нужен только для хранения, он не обеспечит нужной скорости реакции обратной связи.
за ос как раз и должен отвечать контроллер по идее.

плис конечно хорошо, но совсем не знаком с ними.

ну ладно со скоростью посмотрим может и поменьше хватит,
но как принять на atmege 16бит задействовав аппаратные ресурсы ?

Люди да вы что???  :?  о чём речь??? 8 МБит по SPI при 16МГц кварце если не на что не отвлекаться... К тому же, скорость задаёт мастер, какую захотел - такую и поставил (не видел я ещё АЦП-мастер)...
Прими 2 по 8, потом положи их в 2-х байтную переменную - какие проблемы?

для SPI это не принципиально, т.к. прием и передача идет одновременно

introduction
возник ряд тривиальных вопросов (как теперь кажется) в реализации обозначенной выше задачи,
вопросы-то тривиальные, а вот ответы найти получилось не так просто (одни ссылки в поиск и т.п.).
чтобы съэкономить время идущих тем же путем хочу выложить то, что у меня получилось на данном этапе :

итак, напомню, стояла задача постараться довольно быстро (>100Кспс) оцифровывать сигнал и сохранять данные на компьютере.

для реализации были выбраны следующие микросхемы:

adc: 121s051, 12 бит, up to 500Ksps, spi (даташит http://www.national.com/ds/DC/ADC121S051.pdf#page=1 )
uC: atmel atmega16 (даташит http://atmel.com/dyn/resources/prod_doc ... oc2466.pdf )
usb: ftdi ft245bl, 8bit data bus, up to 1MBps, 384 FIFO Tx buffer (даташит http://ftdichip.com/Documents/DataSheets/DS_FT245BL.pdf )
(rs232: max233 - не пригодился, но я в начале просто не был уверен в успехе мероприятия ) )

схемотехнически обвязка ft245 была выполнена полностью в соответствии с даташитом (внешнее пинатие на 5В)
атмега16 тактировалась от внешнего кварца с частотой 16Мгц,
порт С был отдан под данные, порт А для управления и индикации работы,
4 пина порта Б под аппаратный spi.
входным сигналом для ацп служило переменное сопротивление 100 КОм.
мах233 по дашиту.
(.lay приложен )

для программмированя атмеги использовался cvavr.
при начальной инициализации включен spi как мастер на частоте 1/4 от частоты мк, задано прерывание по приему байта.
порты А, С, а так же управляющие линии spi (PB4,PB5,PB7) переведены в состояние выход с лог "0".

программа на первом этапе (горит диод на ножке PA.0) читает в разные переменные значения Hi и Lo бит ацп.
(для этого управляющий сигнал SS (PB.4) сбрасывается в "0" (по заднему фронту в ацп начинается преобразование напряжения),в регистр SPDR помещается произвольный байт (например "0") (т.е. запускается передача данных по spi), по окончании приема возникает прерывание (при этом в SPDR уже будет принятый из ацп байт) в котором значение регистра переноситься в переменную, НЕ поднимая в "1" управляющий сигнал, в SPDR записывается очередной произвольный байт (тот же "0") и по окончании приема снова в обработчике прерывания значение регистра присваивается переменной)

на втором этапе (горит диод на ножке PA.1) полученный байты поочередно пересылаются в ft245
(на порт С выводиться первый передаваемый байт, управляющая линия PA.6 устанавливается в "0", ставится задержка в 1us, линия PA.6 возвращается в "1" (последовательность соответствует временной диаграмме даташита на ft245, задержка увеличена для стабильности), аналогично передается второй байт)

третий этап (горит диод на ножке PA.2) - просто пауза в несколько us
(дело тут в правилах передачи данных по usb, хотя бы 64 байта буфера ft245 необходимо заполнить за опделенное время, иначе хост отменит передачу и возьмет паузу до следующего опроса, при передаче непрерывного потока с большой скоростью относительно небольшой буфер ft245 (384 для Tx) не может справиться с его хранением, возникает чередующаяся ситуация когда или данных еще мало для передачи или буфер уже полон, а хост еще не запрашивал новую порцию байт. реально у меня получилось без пропусков принимать поток в 175КБс, что примерно соответствует 85КГцам измерений ацп, на больших скоростях (а запас-то есть: а) удвоить скорость spi до 8Mhz б) поставить меньшие задержки при передаче данных к ft245 в) убрать искусственную задержку) начинаются потери последовательностей байт, по временной диаграмме состояния ножки PA.5 (TXE) и количеству потерянных байт видно, что они теряются как раз в силу того, что буфер ft245 полон и им просто некуда деваться.
обойти данную проблему, насколько я понял, можно использовав анисинхронный fifo буфер межку мк и ft245 на несколько КБ, т.о. создав управление потоком, но до этого пока руки не дошли... )
(проект приложен )

принимающий на pc софт написан с использованием прямого доступа к драйверу (работа с коммандами драйвера, а не через виртуальный ком порт) на LabView 8.5.
(.vi приложен )

стоял драйвер FTDI D2XX ver 2.02.04 ( http://ftdichip.com/Drivers/CDM/CDM%202 ... tified.zip )

А что если использовать ARM типа AT91SAM7S64 ??? Там Юсб встроеный, Что то около 12 Мбит/сек. Вполне подходит для решения задачи ...

И работать с ним не сложно. вот arm2day.narod.ru инструменты и макеточка простая.

за подсказку с arm спасибо, посмотрю
в действительности вариантов много(avr+ftdi,usb-avr,usb-arm,arm+cypress,fpga+cypress,...),
но я решил пойти от простого к сложному и начать с avr.
дальше конечно, если понадобиться, буду делать на чем-то еще (все на скорости fpga облизываюсь )
кроме того, полезно познакомиться с внешними решениями для usb, они наиболее универсальны и могут еще пригодиться не раз.

avr тоже есть с usb.
Вот микроконтроллеры avr с usb http://usbavr.narod.ru/
и примеры применения.

спасибо, я знаю про них, но под рукой были только 2313, атмега8, атмега 16, выбрал последний )

Браво !