shamrel

На сколько я понимаю, нет. И об этом вам должен был сказать в предупреждении Quartus. Следует для каждой генерируемой частоты прописать типа такого: create_generated_clock -name {как ее назовем} -divide_by 2 -source [get_ports {от какого клока деленая}] [get_registers {откуда берется}]

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

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

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

Эклипс имеет открытые исходники. Возьмите их, исправьте то, что вам мешает и соберите для себя. А если по делу. То, заходите в настройки Window -> Preferences. Там убираете галочки с мешающих вам опций. Ищите вкладки связанные с ключевым словом "Editor". Если пишете на C/C++, тот С/С++ -> Editor P.S.: Намой взгляд, Eclipse -- одна из лучших IDE.

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

В Linux можно все, но не всегда целесообразно, а затраченные усилия, порой, не пропорциональны результату. В своей практике, я в ПО, будь оно на Си или на Bash, порты описывал просто константами. Если проект объемный, то делал конфигурационный файл с настройками. Если вам хочется рулить ножками руками из юзерспейса, то создайте скрипты. В большинстве своем, достаточно редко приходится работать с линиями через драйвер GPIO, обычно к линиям, подключены какие-либо устройства, это описывается в Device Tree, и в системе уже можно работать с драйвером устройства, а не GPIO. А вообще, если мне не изменяет память, посмотреть назначения GPIO можно где-то в /sys/kernel/debug/gpio . Считать файл, да распарсить.

Действительно. Перед началом работы с 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.: в командах могут быть ошибки, под рукой нет боевой системы.

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

Хотел пройти мимо, так как с таким семейством процессоров не работал, и не очень понятна ваша конфигурация. Но захотел разобраться. В качестве первичного загрузчика, что используется (u-boot, grub)?

Моя статья по теме: Быстро поднятое не считается упавшим. Повышаем отказоустойчивость встраиваемых систем Заодно и попиарюсь :1111493779: Будут вопросы, пишите.

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

Могу рекомендовать Создание задач и управление ими в операционной системе реального времени FreeRTOS Там вроде под AVR и предельно просто.

Все верно. Все в соответствии с вашей идеей. :) Только термин "значимость" слышу первый раз. CIC состоит из двух частей, первая часть работает на частоте DAC (50 МГц) . Вторая часть должна работать на пониженной частоте. Разработчик, который вел проект до меня, сделал это через тактирование. Клоки для второй части CIC брались от делителя (на счетчике) от клоков DAC. Проект был реализован в редакторе Schematic и без всяких sdc. Проект успешно (!) прошел тестирования и пошел в серию. Пока не понадобилось внести изменение в функционал и перевести на другую элементную базу. Небольшие изменения вносимые в произвольную часть схемы нарушали работоспособность. Когда добавил .sdc и прогнал в TimeQuest получил сплошные слаки. Исходная прошивка перестала быть работоспособной. Было принято решение переписать на Verilog. Что еще добавить? Пожалуй, то что я с ПЛИС до этого серьезно не работал. Возвращаясь к теме. Dmitriyspb предложил идею, которую сейчас прорабатываю. Первая и вторая часть тактируется одной, системной частотой, а понижение частоты происходит посредствам "пропускания" тактов. Типа: always @(posedge clk) .... if(sample)... где clk -- клоки высокочастотные (200МГц), а sample -- разрешение.

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

Vascom, имхо, мультиплексор внесет трудно прогнозируемую задержку. Особенно, если учесть, что исходные клоки (делитель 1) и клоки, после делителя (делитель на 2 и более) имеют всяко разную задержку. Да даже в идеале фаза будет смещена на 180. Dmitriyspb, спасибо! Что-то похожее крутилось в голове, но не могло сформироваться! Собственно, делитель не кратный 2, думаю, не составит труда сделать. Главное, что б на выходе длительность разрешающего импульса была равна периоду задающего такта. Внешний PLL -- наверное хорошо, но бюджет устройства крайне ограничен. Каждую лишнюю точку пайки считают. P.S.: Dmitriyspb, отдельное вам спасибо, за то, что показали как в ASCII на диаграмме единичку рисовать, а то я все символом 'T' :)

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

Рекомендую рабочий вариант с объяснениями: A serial interface is a simple way to connect an FPGA to a PC. We just need a transmitter and receiver module Правда, реализация на Verilog, но мне в свое время хорошо помог.

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

Сергей, zhevak, благодарю за советы! Удалось поднять дебаг в Эклипсе, причем дебаг по Си коду. Создал пустой файл crt0.S, доставил плагин "zylin". Отладка запустилась. Точки останова ставятся, код выполняется. Значения переменных можно отследить. Однако, для работы с регистрами периферии нужен специальный файл с описанием архитектуры в формате XML (плагин "EmbSys Registers" ), иначе, только по адресам, естественно, под мой чип такого файла не оказалось. Вся система вышла на удивление нестабильной и глючной, потому виртуалка и буду IAR осваивать. :( Резюме. Отлаживать MSP430 под Eclipse в Линух можно, но сложно. НЕ РЕКОМЕНДУЮ! Еще раз, всем спасибо. Тему можно считать закрытой.

В продолжение. Где взять crt0.S ? Где он должен лежать и для чего он вообще нужен? Почему в *.elf файле прописаны какие-то фантастические пути к crt0.S, типа: /home/pf/git/msp430eclipse/dk.xpg.msp430eclipse/scripts/src/gcc/libgcc/config/msp430/crt0.S Как Эклипс натравить на нужный файл?

Подойдут.

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

Один из способов снять напряжение с VBUS: для USB1: devmem2 0x47401460 b 0x00 devmem2 0x47401460 b 0x01 для USB2: devmem2 0x47401c60 b 0x00 devmem2 0x47401c60 b 0x01 Но это же не красиво. :( Ну как же так?! Хочется пользоваться драйвером, и не хочется верить, что с обновлением ядра сломали удобный механизм.

Спасибо за помощь, но нет. В этих файлах и так эти значения по умолчанию. Во все писаемые файлы из директории 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 нормально не работает.