Дополнительный код (дополнение до двух)
Я посмотрел на эту таблицу, и решил, что для перевода из доп. кода в беззнаковый достаточно проинвертировать старший бит числа, дополнительного кода.
Хотя это уже не актуально, вроде бы разобрался со своим джампером, при правильном порядке диф. пар переключение режимов работает.)




Большое спасибо! Буду разбираться.

дополнительный код - старший бит определяет знак. Если он 1, то для получения модуля надо инвертировать число и прибавить 1, если он 0 то ничего делать не надо.

Но это нужно для получения модуля, для вывода синуса это все делать не надо. При выводе графика у вас нет координат -N, Вам надо преобразовать ваш сигнал из диапазона [-(N+1) : N] в диапазон [0 : 2N+1], как не сложно видеть это делается прибавлением (N+1) к каждому значению. Прелесть дополнительного двоичного кода в том что он прекрасно складывается и сам учитывает знак.

Ко всем значениям прибавляете N+1, и на графике в 0 у вас будет минимум -(N+1), в точке (N+1) у вас будет 0, а в точке 2N+1 у вас будет максимум N.

Хотя это и базовые знания программиста...


По передачи данных в память и вычитыванием их из памяти процом. Обращаю ваше внимание что 2 портовая память все же имеет коллизии, и всегда надо следить что вы не пишите и не читаете в одну область памяти. С другой стороны есть железные элементы FIFO, где с одной стороны пишет ваша АЦП, а с другой стороны читает ПРОЦ. Элементы FIFO как раз и созданы для сопряжения и выравнивания частоты чтения и записи. Эти элементы есть как стандартные IP корки на внутренней памяти, но могут быть созданы и ручками на внешней памяти, с них выходит единый сигнал что в FIFO есть данные, при этом можно настроить что сигнал появляется при достаточном пакете, чтобы вас не дергали каждый отсчет. Строго рекомендую обратить внимание на эти элементы прежде чем вы начнете делать свой автомат записи в двойной буфер. Ибо читая что вы имеете трудности с SPI, я представляю что у вас будет при работе с памятью и кучей флагов....

При этом я уверен что самым правильным решением будет АЦП - FIFO - ПРОЦ (если езернет ,будет успевать передавать даныне) или АЦП - FIFO - DMA - DDR - ПРОЦ (если все таки придется данные буфферизировать), Эти цепочки делаются из стандартных компонентов и не изобилуют кучей флагов и прерываний...

если же надо дать максимальную скорость то надо делать АЦП - FIFO - UDP (руками реализованный на железном уровне) При этом надо использовать свойства FIFO что битность входных и выходных данных может быть разная. То есть АЦП может передавать по 16 бит, а UDP забирать и отправлять по 128 или 256 бит, например (там не все сочетания возможны, но их много)

Можно и fifo конечно, но предложенный вариант не отличается от варианта с fifo ни сложностью ни чемто другим, это уже кому как нравится. Не понял о каких флагах идёт речь, нет там никаких флагов, сигнал синхронизации только формируете, сигнал записи и инвертируемый каждый период сигнал выбора записываемого буфера (плюс мультиплексор выходной переключает). По фронту сигнала записи прерывание на процессор. Далее хотите ДМА подключайте, хотите просто читайте, всё тоже самое.



Максимальная скорость тут уже будет зависеть не от того, исполизуем мы fifo или буферы RAM, а от того сможет ли процессор прокачать необходимый нам поток, ну и, возможно, придётся отказаться от использования процессора и реализовать отправку UDP в железе.

Для RAM битность входных и выходных данных также может быть разная, так что тут тоже кому как удобно.


Тут могу сказать, что два варианта имеют место быть, одинаковы по сложности реализации и скорость можно и там и там нормальную обеспечить.

Это, насколько я понимаю преобразование в прямой код, так же в знаковый формат, а я предложил проинвертировать старший бит числа в дополнительном коде, чтобы получить беззнаковое число из дополнительного кода. Если посмотреть на таблицу, это видно:










АЦП - fifo - GPIO_ПРОЦ я пробовал, записывал в fifo по 1 байту, а считывал по 64 бита. Но как fifo c процессором правильно соединить? Я пока пробовал только через GPIO передавать 64 битную шину и флаг заполнения Fifo заводил на внешнее прерывание процессора. Мне показалось, что это не оптимально. Тогда решил попробовать через двухпортовую BRAM на plb шине. Вроде бы получается, но возможно, действительно возникают коллизии, когда я пишу туда и читаю одновременно. Если понизить частоту АЦП, раз в 10, то сигнал приходит нормальный, а при частоте 125 МГц, сигнал приходит порезанный на 7 кусков в разных фазах.

С DMA я еще не работал, будет интересно с ним разобраться. Спасибо!




Это я, конечно, немного утрирую, у меня просто на спартан-3 стартер ките, spi-АЦП и spi-ЦАП были привязаны одним CLK, причем данные в ЦАП нужно было пихать по фронту тактового сигнала, а с АЦП считывать по спаду или наоборот. Еще мне тогда английский труднее давался, проще было сделать методом тыка ))
Но, действительно, не спорю, мне еще учиться и учиться. Спасибо за поддержку!

Сообщение отредактировал Ar-han - Jul 3 2014, 20:00

неправильно понимаете...
дополнительный код для положительных чисел совпадает с прямым кодом. Отличие прямого и дополнительного кода только в виде отрицательных чисел. Отрицательные числа сформированные дополнительным кодом при инверсии знакового бита выворачиваются наизнанку
-1 становиться максимумом, минимум (-максимум) становиться нулем. Не уверен что это полезное преобразование.




Принципиальная ошибка! Зачем вы делаете проц в ПЛИС, если используете его как обычный внешний. Лучше тогда сразу к плис пределать снаружи проц, протестированный и не кушающий ресурсы.

Прелесть проца ПЛИС в том что у него выведена наружу его шина. Вам надо сделать FIFO не native, а то которое выходом имеет подключение на шину проца. Фифо войдет в адресное пространство проца как доп периферия, как и все другие модули что вы будите делать. В этом случае вам не нужна разная ширина записи-чтения, максимум что писать по 16 а читать по 32 бита. Главное забудьте про GPIO в ПЛИСовом проце, они не очень быстрые, и главное нужны только если вам реально надо пошевелить ножкой ПЛИС. Для всего остального надо использовать ввод-вывод данных через шину проца, а для прерывания есть контроллер. Нет никакого смысла заводить сигнал на ногу, а с ноги прерывание в контроллер, с которого оно пойдет на проц. Даже обработка входных сигналов должна делаться вашим модулем, и через шину отдавать процу значение

Иначе это все чесание левого уха через правое плечо...

Ну если через GPIO читать данные из FIFO или RAM, то да, решение конечно не верное, но если использовать прерывание от GPIO, как сигнал для считывания этих данных, то почему бы и нет. По прерыванию запускаете DMA, говорите что, сколько, откуда и куда положить.



Ну и кто же использует в процессоре GPIO для чтения внешней памяти (фифо). У любого проца (более-менее функционального) есть в наличии external memory interface, который и используется для этих целей. А для процессора в ПЛИС он и реолизуется возможностью вытянуть шину наружу.

Потому что, как говорит мой знакомый - это долбанная матрешка получается!

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



далеко не у всех... и далеко не полная шина выведена в этот интерфейс, и далеко это не внутренняя шина проца, это ее некий рудемент. В случае проца внутри ПЛИС вы имеете полноценную внутреннюю шину, это гораздо более удобно и функционально.

Это мне понятно, но я пишу про преобразование не в прямой код, а в беззнаковый формат, в котором самое маленькое число - это 00000000, и дальше оно растет до 11111111. И мне показалось, что удобным из дополнительного кода преобразовать в этот формат путём инвертирования старшего бита. На таблице выше это видно. Прошу прощения, что застрял на этой теме, она этого не стоит.
Просто, со стороны компьютера чтение UDP пакетов пока что через LABVIEW, которое читает пакет данных и преобразует его в массив беззнаковых байтов.

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

Вы нашли режим ФИФО корки который вешается на шину проца?

Нет, еще не нашел. Хочу, всё же, для начала попробовать добить свою двупортовую память, сделал ногу внешнего прерывания на процессоре, и хочу её дергать флагом заполнения памяти. Посмотреть, не будет ли ошибок, и померить скорость, с которой процессор сможет её прочитать.
Уже почти доделал, потом попробую с коркой ФИФО.
Спасибо.

Это делает не модуль, а это является задачей синхронизации. И совсем не сложно, пришло прерывание - знаем, что данные готовы и забираем их.
Ну тогда расскажите, каким способом Вы будете сообщать процессору, что нужно забрать данные, что накопилась нужная пачка в каком-то устройстве хранения. Даже если Вы используете FIFO, то это прерывание от сигнала достаточного уровня заполнения FIFO.

Я говорил только о том, что именно external memory интерфейс используется для подключения внешней памяти, через GPIO считывать данные с устройства хранения - это тот ещё изврат. Приведите пример подразумеваемого процессора у которого нет external memory периферии, мне кажется это будет что-то способное только на "поморгать лампочкой".

Да, более удобно, можно свои IP-ядра делать, которые будут для процессора, как его собственная периферия, но вопрос ведь был, каким образом данные забираются с внешнего носителя, и это уж точно не GPIO.




Напишите свой приёмник со стороны ПК или можете воспользоваться Matlab. В Matlab Simulink можно набросать схемку которая принимает UDP с заданного IP и порта, а потом можете любую обработку навесить.



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

LPC1768 в 100 ногом корпусе + Spartan6 Между процом и ПЛИС 2 SSP по 50 МГБит, и с десяток сигнальных ножек GPIO. Не только моргает лампочками, но довольно изощренно рулит сложной системой подвижек.


Сгенерю прерывание не дернув GPIO, который сгенерит прерывание через модуль обработки, а сразу напрямую подам сигнал на вход модуля обработки прерываний.

Двигаясь далее и развивая мысль: FIFO в этой схеме служит для накопления данных пока процессор занят чем то другим. Так что прерывание в этом случае как таковое и не нужно. В основном цикле работы проца (при супер лупе) или в отдельном потоке в случае операционки проверяем флаг наличия пакета данных FIFO, и как оно там есть забираем и отправляем. При этом автомат отслеживания аварийной ситуации как перехлест данных - это просто проверка флага что фифо переполнилось, не надо проверять что один буфер полон, а другой процом не считан и так далее...

Но я также не настаиваю, нет абсолютно верных решений, всегда есть компромиссы...

Но на него Вы внешний RAM и не вешаете и не пытаетесь вычитывать его через GPIO. Он как бы для этого и не предназначен.


Отправляем мы данные пакетами определённой длинны, т.е. если это FIFO, то читать его будем после того, как необходимое количество данных там накопилось, следовательно необходимо сообщить о наличии данных, прерывание тут и необходимо (вариант его реализации уже будет зависеть от того, кому что нравится).
Можно конечно и пулом мониторить наличие данного флага, но в чём преимущество? Два варианта реализации одной и той же задачи.


Тут Вы не разобрались в предложенном варианте решения, там нет никаких проверок на заполнение, всё полностью определено сигналами синхронизации.
В моём проекте использовал именно описанный вариант решения, но вариант с FIFO полностью принимаю.

Я про то что если захотим сделать защиту. Мало ли что было в сети, наелся кексов стэк, а данные валятся. Я предпочитаю иметь флаг ошибки на этот случай. В случае фифо - это флаг что фифо заполнилось, в случае 2 буферов, это более сложная проверка на заполнение первого и не опустошение второго. При этом ФИФО само следит за этим флагом, а тут придется еще процом симафорить.

Это не с целью что это мертвое решение, а так по придираться



вот тут я обращаю внимание на то что фифо умеет генерить флаг наличия не только данных вообще, но и конкретного их количества. То есть в этом случае пакет формирует само фифо не занимая процессор. Этот сигнал можно вывести на прерывание, но я бы не стал. Прерывание - это такая штука, что их лучше меньше чем больше.

Вы обрабатываете стэк езернета и грузите данные, хорошо бы чтобы один процесс не влезал в другой, значит прерывание не вариант, вот тут я вижу достаточно большую выгоду. Хотя 2 буфера можно так же обрабатывать полингом. Фифо просто как-то экономичнее кажется...

У меня есть рабочие проекты на Spartan-6 по приёму данных с АЦП LTC2157.

Есть даже в двух экземплярах - и на SERDES, и на IDDR.