Very_hard

А меня очень напрягает слово "пробывал". Оно повсюду на технических форумах, да и не только на технических... :(

Продублировал тему 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, но повторить успех не получилось ни разу...)

: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".