Fish

Мне соответственно хочется попробовать присоеденить gcc 4-ой версии к keil. Вопрос как это сделать, что-то ничего кроме этой строчки касаемо выбора в качестве компилятора gcc я не нашел. Из интерфеса самой среды это тоже как-то мне неочевидно. Не подскажете как это делается? Куда копать? http://www.keil.com/support/docs/3127.htm но мне прикрутить пока не удалось - тупит, не может найти исполняемый файл компилятора. Сильно не расстраиваюсь правда, т.к. не планировал использовать Keil'овское IDE, использую только его отладчик

Спасибо! Это оказалось камнем преткновения :a14:

Те же яйца :( А ГДЕ эта библиотека располагается? Какой указать путь для ее поиска?

Предыстория: Установил GCC-4.1 toolchain для Cygwin, изучаю новую для себя среду разработки. Этап "Hello world!" прошел успешно. Решил собрать тест с плавающей точкой, в котором присутствует вот такая функция: float foo(float a) { a += 40.0; return (a * 2.1); } Я прочел, что функции для работы с плавающей точкой имеются в библиотеке libgcc.a. Но, первым делом я запутался в какой директории ее искать? Из какого бы места я не пробовал бы ее подлинковать, получаю такое сообщение линковщика: "C:/Program files/GNUARM"/bin/arm-elf-ld -L"C:/Program files/GNUARM"/lib/gcc/arm-elf/4.1.0/interwork -lgcc -Map D:/Projects/test1/Debug/list/test1.map -TD:/Projects/test1/src/linker.ld D:/Projects/test1/Debug/obj/main.o D:/Projects/test1/Debug/obj/crt.o -o D:/Projects/test1/Debug/bin/test1.out D:/Projects/test1/Debug/obj/main.o: In function `foo': D:/Projects/test1/src/main.c:155: undefined reference to `__addsf3' D:/Projects/test1/src/main.c:156: undefined reference to `__extendsfdf2' D:/Projects/test1/src/main.c:156: undefined reference to `__muldf3' D:/Projects/test1/src/main.c:156: undefined reference to `__truncdfsf2' gnumake: *** [test1.out] Error 1 Причем в map-файле вижу следующее: Linker script and memory map LOAD C:/Program files/GNUARM/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a 0x00000000 ROMSTART = 0x0 0x00010000 ROMSIZE = 0x10000 -------------вырезано--------------- startup *(.startup) .text 0x00000000 0x794 *(.text) .text 0x00000000 0x6a0 D:/Projects/test1/Debug/obj/main.o 0x0000040c put 0x0000068c UNDEF_handler 0x0000049c print 0x00000000 InitHW 0x00000254 DAC_setup 0x00000678 SWI_handler 0x00000664 FIQ_handler 0x0000060c IRQ_handler 0x000001b0 UART0_setup 0x00000284 ADC_setup 0x0000015c InitVIC 0x000005b0 AD0_ISR 0x00000354 T1_setup 0x00000560 main 0x000004e8 foo 0x000005a0 DefDummyInterrupt .text 0x000006a0 0xe0 D:/Projects/test1/Debug/obj/crt.o 0x000006a0 _startup *(.rodata) .rodata 0x00000780 0x14 D:/Projects/test1/Debug/obj/main.o *(.rodata*) *(.glue_7) *(.glue_7t) 0x00000794 _etext = . .data 0x40000200 0x0 load address 0x00000794 0x40000200 _data = . *(.data) 0x40000200 _edata = . .bss 0x40000200 0x0 0x40000200 _bss_start = . *(.bss) 0x40000200 . = ALIGN (0x4) 0x40000200 _bss_end = . 0x40000200 _end = . Многоуважаемые, где грабли? Я в растерянности...

Компилятор с ключом -MD автоматически фомирует файлы зависимостей. В исходном файле присутствует строка: #include <string.h> а соответствующем файле зависимостей: цель ... : пререквизиты ... /cygdrive/d/Program\ files/GNUARM/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/sys-include/string.h \ По сему вопрос: что за странный путь получился?

Спасибо. Я почитал документацию на библиотечные FIFO и понял, что видимо dcfifo не удасться применить. Занялся прикручиванием scfifo.

1. Нужно формировть rdclk постоянно и оперировать лишь rdreq? Но ведь внешний процессор не знает скорости поступления данных! Разве что формировать rdclk из wrclk? 2. Я конечно еще поэкспериментирую и, возможно, эта проблема отпадет при замене эпизодической генерации rdclk постоянной генерацией, но ведь сигнал rdempty сбрасывается в ноль с задеркой в несколько тактов rdclk после появления wrfull, значение rdusedw тоже отстает от wrusedw. И, как указывал уважаемый Jenik, пока rdempty = '1' читать не полагается. 3. Большой глубины буфера не требуется, поэтому реально обойтись dff

Уважаемые ГУРУ! Совсем еще зелен в этом деле, помогите советом, пжалста. Имеется такая задача: Есть CPLD, в которую снаружи последовательно вдвигаются/выдвигаются данные по клоку, формируемому устройством-хостом. С CPLD связан процессор, который забирает/подсовывает данные, клок формирует процессор, т.е. клоки чтения/записи совершенно асинхронны. Можно ли применить библиотечный dcfifo, чтобы обеспечить следующий алгоритм работы: устройство-хост формирует сигналы wrreq, wrclk и заполняет FIFO; при появлении сигнала wrfull процессор формирует сигналы rdreq и rdclk и вычитывает данные из FIFO. Можно ли победить задержки с появлением сигналов wrfull и rdempty? Можно ли формировать клок эпизодически, т.е. только на время вычитывания данных?

Получается, конечно. :) Спасибо всем.

:) До недавнего времени, пока у меня не появился LPC2142, "дерганье пинами" не позволяло оценить время выполнения небольших фрагментов кода - уж больно медленно работали(ют) LPC с GPIO. Видимо, как и раньше буду пользоваться неиспользуемым таймером, который инкрементируется на каждом такте PCLK. Перед анализируемым фрагментом программы сбрасываю и запускаю таймер, а сразу по завершению останавливаю. Где-нибудь чуть дальше ставлю точку останова и в отладчике смотрю содержимое счетчика плюс время на инициализацию таймера.

Имеется горячее желание в симуляторе посмотреть время выполнения того или много куска программы. Как я понял нужно правильно настроить Memory Access Configuration. Интересуют настройки для LPC2000 девайсов. P.S. если кто ответит RTFM, восприму как должное ;-) , но хотелось бы всё же заполучить готовый рецепт

Вероятно, это уже не актуально, но все же S3F441FX от самсунга! На складе в КТЦ-МК лежит. LQFP-64. http://www.samsung.com/Products/Semiconduc...FX/S3F441FX.htm <{POST_SNAPBACK}> Спасибо большое за ссылку - интересный проц, возможно пригодится. Сейчас остановил выбор на LPC214X, использую его внутреннее ОЗУ

А хотел бы обойтись без цепей, болтающихся в воздухе, может это, конечно, эстетство, но мне не нравится. Я избегаю этого и в P-CAD. vetal предлагал засунуть сигналы в трубу для наглядности, но conduit может соединять лишь pins and blocks, blocks and blocks, следовательно туда нельзя подключить symbols pins и nodes Может моя проблема надуманная? Просто хочется сделать схему максимально читабельной

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

Продолжаю строить свой первый проект на CPLD :smile3009: Изначально было принято решение делать первый проект в графике, потому как появление микросхемы ПЛИС в проекте не планировалось и времени на изучение языков HDL соершенно нет :( Библиотечных компонентов вполне хватает для реализации и все вроде ясно, но схема разрослась... Пока удавалось обходиться без шин и всяких труб, но, видимо, пришло время применить всю мощь схемного редактора. Возникли вопросы по применению всех видов соединений. Из Quartus handbook и встроенного tutorial'а внятных ответов не получил :( Вопросы следующие: 1. Имеются два компонента, которые нужно соединить. У одного, например, 8-миразрядный выход выполнен в виде отдельных линий Q7, Q6,..,Q0, а вход второго подразумевает подключение шины in[7..0]. И как их связать? Я сделал компонент-переходник SUBDESIGN to_bus8 ( in0 : INPUT; in1 : INPUT; in2 : INPUT; in3 : INPUT; in4 : INPUT; in5 : INPUT; in6 : INPUT; in7 : INPUT; out[7..0] : OUTPUT; ) BEGIN out[0] = in0; out[1] = in1; out[2] = in2; out[3] = in3; out[4] = in4; out[5] = in5; out[6] = in6; out[7] = in7; END; но, как мне кажется, это кривое решение и можно обойтись без всяких переходников. 2. Например, 2 элемента связаны 8-миразрядной шиной. Как сделать отвод от какого-нибудь разряда шины?