Перейти к содержанию
Поиск
    

shamrel

Свой
 Профиль  Обзор контента

  • Постов

    166

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные shamrel

  1. Опубликовано · Пожаловаться

    В качестве констрейна указана только "основная" тактовая частота. Этого недостаточно ?

    На сколько я понимаю, нет. И об этом вам должен был сказать в предупреждении Quartus.

     

    Следует для каждой генерируемой частоты прописать типа такого:

     

    create_generated_clock -name {как ее назовем} -divide_by 2 -source [get_ports {от какого клока деленая}] [get_registers {откуда берется}]

  2. Опубликовано · Пожаловаться

    Делаю так:

    Tools -> IP catalog -> Basic functions -> Clocks; PLLs and Resets -> PLL -> Altera PLL

     

    Дальше заполняю формы нужными мне параметрами, потом нажимаю кнопку "Finish". Quartus генерирует множество файлов, и среди них - код на VHDL. А кода на Verilog нету. Это можно как-то исправить ?

     

    Зачем это нужно ? Я хочу поделить частоту приходящего в ПЛИС тактового сигнала в 2, 3, 4 и 5 раз, и эти выходы использовать для тактирования различных узлов в проекте. Можно, конечно, получить эти сигналы с выходов счетчика, но мне кажется, что использовать PLL корректнее ...

    Простите, такой не скромный вопрос. А на последней вкладке Summary нужную галочку установить не забыли?

     

  3. Опубликовано · Пожаловаться

    Насколько я понимаю принцип работы журналирования (безотновительно UBIFS или какой-либо другой конкретной FS), при операции, допустим, стирания блока:

    1. в журнал записывается информация о планируемой операции;

    2. выполняется собственно стирание;

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

     

    ....

    Так что говорить "журнал - не панацея" без привязки к конкретной реализации я бы не стал...

    Интересно, применяется ли аналогичный подход (принятие решения о валидности данных на основании контрольного чтения) в jffs2...

    Согласен, реализация имеет огромное огромное значение. В данном случае проблема в ней.

    Подлость "нестабильных" бит, в том, что при первом после сброса доступе они ведут себя адекватно. В результате транзакция будет закрыта. UBIFS имеет оптимистичный поход к данным, она доверяет проверке памяти. То-есть, например, захотела стереть блок, внесла пометку в журнал, начала стирать. Когда уже все стерла, но не "закрыла" LEB, отключается питание. И после перезагрузки, высмотрев в журнале незавершенное действие, файловая система сканирует это блок, видит, что там все единицы (то есть память стерта) и делает запись в журнал о счастливом завершении. Нет, чтоб, наивной еще разок стереть. А в результате может образоваться область нестабильных бит, последующая запись в которую, приведет к порчи данных.

    Аналогично и при других операциях. UBIFS доверяет CRC и если все Ok, то не производит операцию повторно.

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

    Разработчики знают о проблемах. Надуюсь на обновление.

  4. Опубликовано · Пожаловаться

    Понимаю эмоции ТС, но мне больше всего мешает в CoCoox (на базе Eclipse) задержка, возникающая после введения одного-нескольких символов. С увеличением объёма текста задержка увеличивается, и когда в программе больше 2000 строк, "замирание" достигает нескольких секунд. Как от этого избавиться?

    Смею предположить, что время затрачивается на контекстный индекс. То-есть, IDE ищет по всему проекту, как вам помочь, какое автодополнение предложить, какой класс, какая структура и прочее прочее.

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

  5. Опубликовано · Пожаловаться

    Сабж. Как отключить все то, что пытается ёклипсъ делать за меня. Скобки закрывать, скобки в циклах открывать и тд. Бесит люто бешено. Формальное издевательство! Как можно такой продукт выпускать вообще?

    Эклипс имеет открытые исходники. Возьмите их, исправьте то, что вам мешает и соберите для себя.

    А если по делу. То, заходите в настройки Window -> Preferences. Там убираете галочки с мешающих вам опций. Ищите вкладки связанные с ключевым словом "Editor".

    Если пишете на C/C++, тот С/С++ -> Editor

     

    P.S.: Намой взгляд, Eclipse -- одна из лучших IDE.

  6. Опубликовано · Пожаловаться

    Интересно, каким образом удалось убить FS, просто отключая питание. Вы что, использовали нежурналируемую файловую систему?

     

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

    Причины сбоев и потери информации в NAND

     

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

    Отключение питания происходит в момент начала работы со страницей NAND. После перезагрузки, страница может быть прочтена корректно: считаются все единицы (0xFF), но иногда, после перезагрузки можно из этой области считать только нули. Кроме того, если потом опять записать эту страницу, иногда может возникнуть ошибка ECC. Причина – опять нестабильные биты.

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

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

    Во всех случаях, после аварийного отключения питания область памяти может быть прочитана корректно, в результате система журналирования не увидит подвоха. Но при последующим доступе к этой области данные могут быть повреждены. Количество таких «нестабильных бит» может быть больше, чем алгоритм ECC сможет скорректировать. Поэтому, ранее читаемые страницы становятся нечитаемыми, или наоборот, ранее нечитаемая страница может стать вдруг читаемой. Проблема усугубляется тем, что нестабильные биты могут возникнуть в журнале файловой системы, так как статистически, эта область NAND наиболее часто модифицируется.

     

    P.S.: Чего-то спойлер не работает.

  7. Опубликовано · Пожаловаться

    Большое спасибо за разъяснения. А можно ли, допустим, назвать пин UsbOnGpio, и потом с ним работать из линукса, не экспортируя его каждый раз и не вспоминая, что же такое у нас GPIO125 ?

    В Linux можно все, но не всегда целесообразно, а затраченные усилия, порой, не пропорциональны результату.

    В своей практике, я в ПО, будь оно на Си или на Bash, порты описывал просто константами. Если проект объемный, то делал конфигурационный файл с настройками.

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

    В большинстве своем, достаточно редко приходится работать с линиями через драйвер GPIO, обычно к линиям, подключены какие-либо устройства, это описывается в Device Tree, и в системе уже можно работать с драйвером устройства, а не GPIO.

    А вообще, если мне не изменяет память, посмотреть назначения GPIO можно где-то в /sys/kernel/debug/gpio . Считать файл, да распарсить.

  8. Опубликовано · Пожаловаться

    Действительно. Перед началом работы с GPIO из userspace, соответствующий вывод должен быть прописан в DTS. Это нужно для того, что бы ядро знало, что с этой ножкой нужно/можно работать через gpio-драйвер.

    Я это делаю так:

     

    usergpio_pins: pinmux_usergpio_pins {
	pinctrl-single,pins = <

		/*button*/
		0x05C (PIN_INPUT_PULLUP | MUX_MODE7) 		/* SW1 gpmc_a7.gpio1_23 MODE7 */
		/*Vif vif_12v_fixed*/
		0x16C (PIN_OUTPUT_PULLUP | MUX_MODE7)		/* uart0_rtsn.gpio1_9 MODE7 */
		/*3V3_plc vif_3v3_plc_fixed*/
		0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE7)		/* mcasp0_aclkx.gpio3_14 MODE7 */

	>;
};

    Соответственно, потом указатель на usergpio_pins помещаю в секцию pinmux.

    Собственно, для процессора из примера MUX_MODE7 -- режим работы вывода процесса, соответствующий GPIO. Что такое PIN_INPUT_PULLUP и PIN_OUTPUT_PULLDOWN, думаю, понятно и так.

    Единственная проблема с адресом. Это нужно смотреть документацию на процессор. Причем, следует отметить, что используется не абсолютный адрес, о смещение относительно блока pinmux.

     

    Как работать с этим в userspace. Допустим, хотим вывести 1 в gpio1.9. (объявлен в примере).

     

    1. Инициализируем устройство gpio1.9:

     

    echo 41 > /sys/class/gpio/export

     

    Тонкий вопрос, как gpio1.9 превратился в 41 ?. В процессоре параллельные порты объединены в 32-битную шину. В обозначении gpio1.9 первая цифра "1" -- номер порта, вторая -- номер ножки в порту. Таким образом, абсолютный номер порта будет 32 + 9 = 41.

     

    2. Устанавливаем направление порта.

    После экспорта в директории /sys/class/gpio/ появляется директория gpio41. Там много чего интересного, но сейчас нам нужен файл direction. Записываем туда направление.

     

    echo "out" > /sys/class/gpio/gpio41/direction

     

    Понятно, что для входа, значение будет "in".

     

    3. Устанавливаем уровень.

    Теперь, через запись в файл value значения, мы управляем выводом:

     

    echo "1" > /sys/class/gpio/gpio41/value

     

    P.S.: в командах могут быть ошибки, под рукой нет боевой системы.

     

     

     

  9. Опубликовано · Пожаловаться

    Если под начальными настройками подразумевается возврат всей системы в исходное состояние, в котором оно было выпущено с завода, то напрашивается вариант хранить rootfs дважды: первая копия записывается на заводе и никогда не модифицируется, вторая копия - рабочая. Для возврата к начальным настройкам вторая копия переписывается первой.

    Для этих целей придумали каскадно-объединенное монтирование. Идея следующая: создаем «виртуальный» раздел из двух физических разделов на носителе. Один раздел содержит образ rootfs, доступный только для чтения, а во время работы операционной системы все изменения заносятся во второй раздел, который доступен для чтения и записи. Для каскадно-объединенного монтирования разделов использована вспомогательная файловая система UnionFS, AUFS или OverlayFS.

    В статье (ссылка в предыдущем сообщении) подробный пример и объяснение создание такого пирога по технологии AUFS.

     

    Как уже говорилось выше, происходит объединение двух физических разделов. Первый раздел, в который изначально записан образ рабочей КФС, доступен только для чтения (RO – read only), второй раздел, изначально пустой, служит для хранения изменений, соответственно, он доступен как для чтения, так и для записи (RW – read write). В терминах aufs первый и второй разделы называются ветвями (branch). Объединение ветвей происходит в процессе монтирования. В результате операционная система видит смонтированную область как единое целое. Доступ к данным осуществляется драйвером ядра. Запросы на чтение файла драйвер в первую очередь направляет к RW ветви; если данные там присутствуют, то выдаются они, если там данных нет, то файл читается из ветви RO. При записи, данные попадают в ветвь RW. При удалении файла, в ветвь RW добавляется метка о том, что данный файл был удален (создается соответствующий пустой скрытый файл с определенным префиксом в названии). Физически файл остается в ветви RO целым. Такой подход позволяет избежать операций записи в разделе с критической информацией. Кроме того, так как ветвь RO доступна только для чтения, появляется принципиальная возможность добавить дополнительный контроль целостности данных. Реализовать это можно средствами UBIFS, сделав создаваемый раздел статическим. Статический раздел доступен только для чтения и данные там защищены контрольной суммой (CRC-32).

     

    При необходимости отката, или в случае повреждения данных, просто форматируем раздел с ветвью RW.

  12. Опубликовано · Пожаловаться

    Можно обратить внимание на стандартную библиотеку stdio.h. Функция printf вам в помощь.

    В зависимости от настроек компилятора, может получиться вполне приемлемый код.

    Нежели, нужно быстро обрабатывать, или мало свободного ОЗУ (подключение stdio откушает довольно таки много RAM), то по методу Сергея Борща.

  14. Опубликовано · Пожаловаться

    Мне кажется, без минимальной схемы - тут никуда. Я имею ввиду функциональной.

    Если у вас частота на АЦП неизменна(50 МГц) - какой клок вам нужен на CIC? По идее данные заходят на CIC с частотой работы (дискретизации) АЦП. А вот выходят из CIC - на меньшей частоте. Но обычно это реализуется не другой частотой, а значимостью сигнала. То есть на входе - каждый такт значимый, а на выходе есть некий отдельный признак значимых данных. Который возникает раз в 1/2/4/8 и т.д. тактов.

    Все верно. Все в соответствии с вашей идеей. :) Только термин "значимость" слышу первый раз.

    CIC состоит из двух частей, первая часть работает на частоте DAC (50 МГц) . Вторая часть должна работать на пониженной частоте. Разработчик, который вел проект до меня, сделал это через тактирование. Клоки для второй части CIC брались от делителя (на счетчике) от клоков DAC. Проект был реализован в редакторе Schematic и без всяких sdc. Проект успешно (!) прошел тестирования и пошел в серию. Пока не понадобилось внести изменение в функционал и перевести на другую элементную базу. Небольшие изменения вносимые в произвольную часть схемы нарушали работоспособность. Когда добавил .sdc и прогнал в TimeQuest получил сплошные слаки. Исходная прошивка перестала быть работоспособной. Было принято решение переписать на Verilog.

    Что еще добавить? Пожалуй, то что я с ПЛИС до этого серьезно не работал.

    Возвращаясь к теме. Dmitriyspb предложил идею, которую сейчас прорабатываю. Первая и вторая часть тактируется одной, системной частотой, а понижение частоты происходит посредствам "пропускания" тактов. Типа:

     

    always @(posedge clk)

    ....

    if(sample)...

     

    где clk -- клоки высокочастотные (200МГц), а sample -- разрешение.

     

  15. Опубликовано · Пожаловаться

    Я не совсем понимаю схему (недостаточно данных), но если на АЦП клок заходит с плис то делаем следующую вещь: Опорный клок-> Делитель на целое число с учетом DDR триггера на выходе -> выходной DDRC триггер.

     

    Отсутствие PLL (и выходного триггера (обязательно расположенного в блоке ввода вывода, у Xilinx это называется iob, у Altera возможно по-другому) даст более качественную выходную частоту нежели с PLL (хотя наверное чуть-чуть хуже, чем при использовании внешних компонентов). Использование DDR триггера позволит делить клок на числа некратные двойке.

     

    По идее должно быть сильно лучше чем с PLL. Насколько возможно отсутствие PLL - Не совсем понял из условий задачи.

     

    Ещё не совсем понял, как вы выбираете частоту дискретизации извне? У вас гарантированно только полезный сигнал приходит на АЦП? Уже отфильтрован внешними условиями/схемами?

    Собственно, система такая. Есть 4 АЦП, каждый АЦП работает на 50МГц. Тактируется с ПЛИС (Altera). Частота АЦП неизменна. Внутри ПЛИС на каждый канал установлен дециматор CIC. После фильтра данные идут на мультиплексор. Выходы 4 каналов складываются в один большой FIFO. С другой стороны FIFO данные передаются в компьютер. Для работы CIC нужна опорная частота, которая будет определять коэффициент децимации, а по сути эквивалентную частоту дискретизации канала. Этот коэффициент децимации скидывается управляющей программой с компьютера. Таким образом, управление мультиплексоров должно выполнятся на частоте в 4 раза больше, чем частота CIC, и достигать максимума в 200МГц, когда децимация не требуется. На плату приходит 50МГц с внешнего генератора.

    В кристалле 2 PLL, одна используется для High speed USB, вторую планирую использовать для опроса АЦП.

    По поводу DDR триггера. Я не знаю как это реализовать. С ПЛИС работаю недавно.

  16. Опубликовано · Пожаловаться

    Vascom, имхо, мультиплексор внесет трудно прогнозируемую задержку. Особенно, если учесть, что исходные клоки (делитель 1) и клоки, после делителя (делитель на 2 и более) имеют всяко разную задержку. Да даже в идеале фаза будет смещена на 180.

     

    Dmitriyspb, спасибо! Что-то похожее крутилось в голове, но не могло сформироваться! Собственно, делитель не кратный 2, думаю, не составит труда сделать. Главное, что б на выходе длительность разрешающего импульса была равна периоду задающего такта.

     

    Внешний PLL -- наверное хорошо, но бюджет устройства крайне ограничен. Каждую лишнюю точку пайки считают.

     

    P.S.: Dmitriyspb, отдельное вам спасибо, за то, что показали как в ASCII на диаграмме единичку рисовать, а то я все символом 'T' :)

     

     

  17. Опубликовано · Пожаловаться

    Приветствую!

    В системе есть тактовая частота Fclk = 200МГц. От этой частоты нужно тактировать АЦП, ЦАП и цепочки фильтров. Причем, частота выборки устанавливается из вне (передается параметр) и может быть любой из Fclk/N , где N -- целое число 16-битное число (включая 1).

    Как можно это сделать? Делитель на счетчике с загрузкой? Выход не будет синхронным с основной частотой, да и минимальный коэффициент деления 2, а нужно 1 (нет деления). Использовать перестраиваемый PLL? Сильно громоздко получается (в Altera), или может я не до конца разобрался как это сделать. Или смириться с асинхронностью схемы?

  18. Опубликовано · Пожаловаться

    Рекомендую рабочий вариант с объяснениями:

    A serial interface is a simple way to connect an FPGA to a PC. We just need a transmitter and receiver module

     

    Правда, реализация на Verilog, но мне в свое время хорошо помог.

  19. Опубликовано · Пожаловаться

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

    Собственно, если еще актуально, то вот пример Термометра на LabVIEW.

    Там же модули для работы с FTDI и исходники, правда на Си для DS18B20 под атмегу. При необходимости можно запилить и под ПЛИС.

     

  20. Опубликовано · Пожаловаться

    Сергей, zhevak, благодарю за советы!

    Удалось поднять дебаг в Эклипсе, причем дебаг по Си коду.

    Создал пустой файл crt0.S, доставил плагин "zylin".

    Отладка запустилась. Точки останова ставятся, код выполняется. Значения переменных можно отследить. Однако, для работы с регистрами периферии нужен специальный файл с описанием архитектуры в формате XML (плагин "EmbSys Registers" ), иначе, только по адресам, естественно, под мой чип такого файла не оказалось. Вся система вышла на удивление нестабильной и глючной, потому виртуалка и буду IAR осваивать. :(

     

    Резюме. Отлаживать MSP430 под Eclipse в Линух можно, но сложно. НЕ РЕКОМЕНДУЮ!

    Еще раз, всем спасибо. Тему можно считать закрытой.

  21. Опубликовано · Пожаловаться

    В продолжение.

    Где взять crt0.S ? Где он должен лежать и для чего он вообще нужен? Почему в *.elf файле прописаны какие-то фантастические пути к crt0.S, типа:

    /home/pf/git/msp430eclipse/dk.xpg.msp430eclipse/scripts/src/gcc/libgcc/config/msp430/crt0.S

    Как Эклипс натравить на нужный файл?

  23. Опубликовано · Пожаловаться

    Приветствую!

    Собственно, в описании темы проблема озвучена. В настоящий момент развернут Toolchain для MSP, успешно подружен с Eclipse.

    Из командной строки работает mspdebug.

    Первый вопрос, как научить Eclipse дебажить код?

    Уважаемый мною (читал ваш блог и не только на технические темы) zhevak в одной из тем на форуме рассказал как дебажить контроллер в консольном режиме. В связи с чем вопрос, как с этим работать? Как имея программу на Си произвести ее отладку? Как узнать адреса для точек останова, выполнить пошагово код, прочитать регистры периферии? Или для этого нужно сначала дизассемблировать?

     

  24. Опубликовано · Пожаловаться

    Один из способов снять напряжение с VBUS:

     

     для USB1:
devmem2  0x47401460 b 0x00
devmem2  0x47401460 b 0x01

для USB2:
devmem2  0x47401c60 b 0x00
devmem2  0x47401c60 b 0x01

     

    Но это же не красиво. :(

    Ну как же так?!

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

  25. Опубликовано · Пожаловаться

    [url=http://electronix.ru/redirect.php?http://sysadm.pp.ua/linux/usb.html]http://sysadm.pp.ua/linux/usb.html[/url]

    В комментариях тоже полезное есть.

    Спасибо за помощь, но нет.

    echo "0" > /sys/bus/usb/devices/2-1/power/autosuspend

    echo "auto" > /sys/bus/usb/devices/2-1/power/level

    В этих файлах и так эти значения по умолчанию.

    Во все писаемые файлы из директории power уже писал все что угодно, и по исходникам смотрел, что туда вообще писать можно.

    # ls -l /sys/bus/usb/devices/1-1/power/
-r--r--r--    1 root     root          4096 Oct 29 10:40 active_duration
-rw-r--r--    1 root     root          4096 Oct 29 10:32 autosuspend
-rw-r--r--    1 root     root          4096 Oct 29 10:32 autosuspend_delay_ms
-r--r--r--    1 root     root          4096 Oct 29 10:33 connected_duration
-rw-r--r--    1 root     root          4096 Oct 29 10:33 control
-rw-r--r--    1 root     root          4096 Oct 29 10:32 level
-rw-r--r--    1 root     root          4096 Oct 29 10:40 persist
-r--r--r--    1 root     root          4096 Oct 29 10:40 runtime_active_time
-r--r--r--    1 root     root          4096 Oct 29 10:40 runtime_status
-r--r--r--    1 root     root          4096 Oct 29 10:40 runtime_suspended_time
-rw-r--r--    1 root     root          4096 Oct 29 10:40 wakeup
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_abort_count
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_active
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_active_count
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_count
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_expire_count
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_last_time_ms
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_max_time_ms
-r--r--r--    1 root     root          4096 Oct 29 10:40 wakeup_total_time_ms

    Да, эти же манипуляции проводил и с /sys/bus/usb/devices/usb1/power/

    Проверил саму физическую возможность отключения питания. В device tree ножку, отвечающую за USB0_DRVVBUS,

    объявил как GPIO. в результате в "ручном" режиме питание отключается, однако при загрузке, естественно, ошибка с

    VBUS. Ну, и конечно, USB нормально не работает.

     

     

     

×
×
  • Создать...