Very_hard
Свой-
Постов
177 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о Very_hard
-
Звание
Частый гость
- День рождения 10.04.1980
Контакты
-
Сайт
Array
-
ICQ
Array
Информация
-
Город
Array
-
"Группа новичёк"
Very_hard ответил =AK= тема в Архив предложений и замечаний
А меня очень напрягает слово "пробывал". Оно повсюду на технических форумах, да и не только на технических... :( -
Продублировал тему http://electronix.ru/forum/index.php?showtopic=64928, кажется не туда запостил сначала, прошу сильно не пинать за это. Столкнулся со следующей проблемой. Есть устройство, в котором предусмотрена возможность заливать загрузчик(u-boot) по протоколу xmodem-1k. До этого момента все было хорошо, он действительно загружался как положено и стартовал на устройстве. Все это было в Windows XP с использованием TeraTerm или Hyperterminal(да и сейчас из винды устройство без проблем прогружается подобным образом). Но вот понадобилось повторить подобную процедуру в Linux(Ubuntu 9.04). И ничего не вышло. Более того, не вышло также и в Windows XP запущенной под VirtualBox 2.2.4, с теми же TeraTerm или Hyperterminal. В линуксе пытался использовать minicom с разнообразными настройками xmodem, загрузка начинается вроде как положено, доходит до конца и выдает что-то наподобие Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: Retry Count Exceeded Transfer incomplete Пробовал просто использовать команду sx -X -k /file > /dev/ttyS0 </dev/ttyS0 с различными комбинациями ключей, но с тем же результатом. В виртуалбоксовой windows передача тоже начинается, но прерывается в произвольный момент(гипертерминал выводит сообщение, что устройство прервало сеанс связи). Вобщем, помогите :1111493779: , куда копать, что настраивать. (...Один раз устройство таки приняло xmodem-овую передачу из миникома, перед этим изменял в нем настройки порта - четности, количество бит и т.д. Успешная попытка случилась, когда после экспериментов вернул все на место: 115200 8N1, но повторить успех не получилось ни разу...)
-
С днем радио, дорогие!
Very_hard ответил _Pasha тема в Встречи и поздравления
:beer: :beer: :beer: -
Большое спасибо за помощь, amw! :)
-
Вопрос такой. Хочется собрать пару утилит для устройства с линуксом на борту. Для этих целей делаю приблизительно так: ./configure --host=mips-linux --prefix=/home/my/targetfs/qwerty и т.д., затем make и make install. В общем, хотелось бы чтобы это так было :). Но на целевой файловой системе пути, взятые при сборке и установке из prefix, уже не актуальны, и некоторые программы не находят библиотеки или свои доп. файлы. Пока что решаю это созданием символьных ссылок там, где что-то должно быть, "по мнению" собранной программы(в терминах хостовой файл системы), туда, где это действительно лежит в терминах файловой системы таргета. Есть ли возможность при кросс-компиляции через последовательность ./configure[--options]->make->make install как-то решать этот вопрос? Прошу извинить, если такой вопрос уже поднимался. Или если он излишне простой. :)
-
Мы используем *.bin файл - все нормально загружается. Вроде у bit-файла нужно заголовок удалять перед загрузкой, не пробовал.
-
В xapp098 хорошо описана именно такая загрузка. Поищите на сайте Xilinx. Возможные проблемы - обратная последовательность бит в байте, не выдержаны требуемые тайминги. Файл Вы используете правильный. Ничего больше загружать не нужно. В начале вроде бы выставляется в 0 PROG_B, потом ожидается 0 на INIT, потом 1 в PROG_B, ждем 1 на INIT, задержка (100 мкс) и дальше данные с клоком.
-
sazh Эквивалентно, конечно. Написал так просто для того, чтобы было понятно соответствие конструкций if else elsif внутри процесса и описания того же вне процесса. Вообще, даже так: strob <= we and not ch;
-
Вне процесса нужно писать по-другому: strob <= '1' when we='1' and ch='0' else '0';
-
Это все хорошо, но неправильно, во всяком случае для реализации на ПЛИС, где все по возможности желательно тактировать одной системной частотой. Как посоветовали выше, лучше использовать вход разрешения тактирования триггера.
-
Maverick, IEEE.STD_LOGIC_ARITH и IEEE.STD_LOGIC_UNSIGNED желательно заменять на IEEE.NUMERIC_STD. И уж точно не следует смешивать их во избежание проблем(в них, вроде, по разному переопределены операторы - и неизвестно, что в конечном счете будет применено). А синтез будет, если пользовать IEEE.NUMERIC_STD, правда нужно писать немного по-другому.
-
Объясните, пожалуйста, подробнее.
-
makc, ну например, в представленном коде через elsifы есть довольно неочевидная завязка сигнала rst на разрешение выходного регистра. Не страшно, конечно, но все же... не знаю планировалось ли это, но вряд ли... И вообще, по-моему, даже для большого процесса неплохо разделять конструкции формирования сигналов(и ошибок меньше и читать проще). Можно было бы написать почти то же, например, так: process (clk, subst_store) variable i:integer; begin for i in 15 downto 0 loop iSubst(i) <= subst_store(i*4+3 downto i*4); end loop; -- Load if rising_edge(CLK) then if rst='1' then subst_store <= (others => '0'); elsif (load='1' and start='0') then for i in 15 downto 0 loop subst_store <= subst_store(59 downto 0) & K; end loop; end if; end if; if rising_edge(CLK) then if (load='1' and start='0') then reg <= reg(14 downto 0) & S_in; end if; end if; -- Out if rising_edge(CLK) then if (load='0' and start='1') then for i in 15 downto 0 loop reg_out(i) <= reg(conv_integer(iSUBST(i))); end loop; elsif (load='1' and start='1') then reg_out <= reg; end if; end if; end process;
-
makc, точно, я ошибся, латчи не причем... :) Просто в данном случае слишком уж все перемешано у автора в одном месте... имхо
-
В процессе в одном блоке if rising_edge(CLK) then end if; для всех подблоков if описывайте один и тот же сигнал или набор сигналов, иначе у Вас вместо триггеров получатся латчи. Если не получается, разделяйте описание на несколько блоков "if rising_edge(CLK) then".