Vitaliy_ARM
-
Постов
508 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Vitaliy_ARM
-
-
После длительной переписки со службой поддержки выяснилось, что надо было делать совсем подругому, нежели в IAR5.x.
MEMORY { /* Define each memory region */ CODE_MEM (rx) : ORIGIN = 0x0, LENGTH = 0x00003000 MAC_IP_MEM(rx) : ORIGIN = 0x00003000, LENGTH = 0x00002000 Ram32 (rwx) : ORIGIN = 0x40000000, LENGTH = 0x8000 /* 32k */ RAM_ETH_16 (rwx) : ORIGIN = 0x7fe00000, LENGTH = 0x4000 /* 16k */ RAM_USB_8 (rwx) : ORIGIN = 0x7fd00000, LENGTH = 0x2000 /* 8k */ RAM_RTC_2 (rwx) : ORIGIN = 0xe0084000, LENGTH = 0x800 /* 2k */ } .text : { KEEP(*(.isr_vector)); /*вектора прерываний*/ . = 0x000001FC; /*смещение указателя на адрес CRP*/ KEEP(*(.crp_key)); /*секция CRP*/ *(.text*) /*код программы*/ *(.rodata*) /*константы*/ } > CODE_MEM .MacIpMem : /*. = 0x00003000;*/ { KEEP(*(.macaddr)) /*размещаем по адресу 0x00003000*/ . = 0x00001000; /*переход на адрес 0x00001000;*/ KEEP(*(.ipaddr)) /*размещаем по адресу 0x00004000*/ } > MAC_IP_MEMВот так почти правильно размещать свой код в разные областя памяти.
Теперь про почти:
Инициализируемая константа находится в исходнике, задается следующим образом:
const BYTE OurMacAddr[6] __attribute__ ((section(".macaddr"))) = {0x00,0x01,0x02,0x03,0x04,0x06};
Инициализируется мусором!!! Почему???
-
Делаю стенд для исследования свойств цифровых фильтров в целях обучения.
Устройство имеет 16бит ацп и 16бит цап. На ацп подается тестовый сигнал, к выходу цапа подключается осциллограф или спектроанализатор.
Схема работы устройства приведена в приложении. CY-предполагается использовать в Slave FIFO. АЦП и ЦАП сидят на I2s.
Вопросы:
- Возможно ли на процессоре с 56-ногами? :)
- Если кто делал, какая, примерно, пропускная способность ожидается в обе стороны у такого девайса?
-
Можно ли как-нибудь создать один регион памяти из двух кусков,
например что-то вроде:
MFlash512 (rx) : (ORIGIN = 0x20000, LENGTH = 0x1000) OR (ORIGIN = 0x40000, LENGTH = 0x1000)
????Написал этот вопрос в поддержку. Посмотрим, что ответят.
Получил ответ :)
Hi,You just need to change ".boot" to ".text" in your linker script.
Full details on linker scripts can be found in the documentation at:
Help->Help Contents
Code Red Technologies Documentation
Tools Documentation
GNU Linker
Section 3 "Linker Scripts"
Best regards,
Попробовал поменять:
.text : /* .boot*/ { KEEP(*(.isr_vector)); KEEP(*(.crp_key)); KEEP(*(.macaddr)); KEEP(*(.ipaddr)); } > BOOTMEM .text : { *(.text*) *(.rodata*) } > MFlash512Не работает.
-
-
Можно ли как-нибудь создать один регион памяти из двух кусков,
например что-то вроде:
MFlash512 (rx) : (ORIGIN = 0x20000, LENGTH = 0x1000) OR (ORIGIN = 0x40000, LENGTH = 0x1000)
???? -
Какая-то ерудна с линкером. Вот не прошло и пол года: http://electronix.ru/forum/lofiversion/index.php/t58320.html
а вектора стали называться по другому :07:
-
у меня отладка работает на ура, даже в инлайн конструкторы заходить.
могу ВСЕ в кучу запаковатьь и выложить. сможете сравнить.
Выкладывайте, будет интересно. А джитаг какой вы используете?
Кстати вот еще интересная ссылка на исходники для их отладочной платы, много чего интересного: http://support.code-red-tech.com/CodeRedWiki/RDB1768Support
-
А может ли замена D-link'овского Wi-Fi на что-нибудь другое устранить неполадки?
Смотрю, проблема не решена до конца на этом форуме. У меня такое было недавно при подключении точки доступа к прибору с изернетом 100 мегабит.
Ошибка была в том, что точка доступа пропускает все пакеты, у которых мак адрес начинается с 0x00. У меня был 0x01 0x02 0x03 0x04 0x05 0x06 - не работала,
после замены мак адреса на 0х00 0x01 0x02 0x03 0x04 0x05 все стало гуд. Точка доступа от Asus, 802.11g.
-
Понял что вектора прерываний находятся полностью в KEEP(*(.isr_vector).
Однако .text должен находиться в в одной секции и после KEEP(*(.isr_vector).
.boot : { KEEP(*(.isr_vector)); *(.text*) *(.rodata*) } > BOOTMEMЕсли сделать так:
.boot : { KEEP(*(.isr_vector)); } > BOOTMEM .text : { *(.text*) *(.rodata*) } > MFlash512То дебагер улетает в undefine handler. Получается что вектор резета указывает не на начало .text, а непонятно куда.
В чем может быть дело, как правильно разнести вектора и основную программу?
-
ыыы :laughing:
мож попробуем выдрать "ихний плагин", поглядеть ... все остально даром ненадо.
Можно попробовать. У меня постоянно был геммор с отладчиком. GDB сервер постоянно вылетал, то сбоил, то еще чего нибудь выдавал, например жмешь перепрыгнуть
через функцию, а он туда залетает и потом вешается. Джитаг от Olimex. Сносно работал j-link со своим GDB сервером, но тоже не все было гладко. Короче говоря я надолбался с
бесплатным софтом, но так нормально и не настроил.
Думаю тут надо сначала состыковать это добро между собой, чтобы не глючило. А потом браться за плагин. В коде реде вроде бы свой GDB сервер, с их джитагом вроде работает
более или менее.
Как появится возможность, постараюсь залить на местный фтп эту среду.
Сейчас порюсь с такой проблемой, наверное это больше к линкеру относится. Переписываю свой бутлодер.
Где находятся вектора прерываний в этом коде? (перенос KEEP(*(.isr_vector)) в другую секцию, размещенную по нулевому адресу результата не принесло, может чего упустил?).
.text :{
KEEP(*(.isr_vector))
*(.text*)
*(.rodata*)
KEEP(*(.init));
KEEP(*(.fini));
} > FLASH
Вот еще нашел такой комментарий в скрипте линкера:
/*Note: (ref: M0000066)
Moving the stack down by 16 is to work around a GDB bug.
This space can be reclaimed for Production Builds.
*/
-
Стандартная цена на LPC1311FHN33 на 25% ниже стандартной цены LPC2101FBD48.
Супер, если так будет :) ! Avr'ам туговато придется.
-
Вижу плагин, котрый парсит регисты переферии - это гуд
но чето 1000$ как-то дороговато на мой взгляд.
IAR вообще не реальных денег стоит. Этот еще можно купить :unsure:
-
Полноценные - вопрос субъективный. Вот недавно на LPC1300 User Manual вышел
Сколько будут стоить эти процессоры в России? Будут ли кристаллы дешевле LPC2101?
-
за что собсно денги уплачены?
Мы купили пока джитаг. Среда работает с ограничением 8кБ.
Она продается отдельно и стоит порядка 1000$
Деньги берут за плагин эклипса и за то, что у Вас все будет работать сразу :)
за эклипс, а чем он отличается от бесплатного?Эклипс с их плагином полностью настроен на работу с их джитагом. Так же среда
позволяет полноценно просмтривать регистры процессоров, внутреннюю память и т.п.
в божеских окнах.
GCC 4.2.0gcc -v че выдает? чей сборки?
Выложил скриншот консоли gcc.jpeg
что в качестве libc предложено? собственное чтото как у CrossWorks ( в чем сомневаюсь) или newlib, если newlib то какой версии, какой версии GDB?Скажите как посмотреть, посмотрю. :rolleyes:
-
Вы устанавливаете оптимизацию по скорости, меняете проект и сравниваете обьем? Где логика?
Просто в этом компиляторе в комбобоксе нету -Os. Прописал в ручную, один фиг, все равно результат тот же.
-
Ну а вообще, раз купили, то можно напрячь продавца, наверное:)
Они сильно не напрягаются. В терре сказали что это еще пока группа интузиастов. Пробовал перед
покупкой написать им на маил, ответа не было. Потом раза три пытался позвонить. Трубку не брали.
Повторно написал на маил, с вопросом как купить? Написали, что покупайте джитаг в терраэлектронике и дали ссылку,
а лицензию на программу у нас :) .
А вообще впечатления от компилера: проект был скомпилирован в IAR, занимал 7кБ, (директива оптимизации - Speed)
после перенесения его на язык С и компиляции в этом компиляторе, проект стал занимать 10кБ (директива оптимизации -O3)
-
Приобрели эту среду, так как очень хотелось иметь среду на базе эклипса с нормальным дебагером.
Среда на базе эклипса 3.3 и гнушного компилятора gcc 4.2.0. Этот вариант гораздо бюджетнее IAR.
О нем можно почитать здесь: www.code-red-tech.com
В кратце о среде:
Джитаг собран на FT2232, максимальная скорость - 6МГц. По сравнению с IAR,
работает заметно медленнее.
Геммора с настройкой проекта практически нет (C-проекта).
На мой взгляд, очень удачное решение для тех, кому нравится эклипс.
Со средой вместе идут несколько проектов, в частности для LPC17xx и LPC23xx/24xx. и гигобайтная флешка :rolleyes: с фирменным лабелом.
Все проекты написаны на C, компилируются и работают сностно. При создании
проекта на С, автоматически генерируются 3 файла для компановщика.
При создании проекта на C++ так же генерятся три файла скрипта компановщика, в которых отсутствуют секции для конструкторов и прочее. :cranky:
При использовании обычного класса компановщик начинает ругаться непонятными ошибками:
make all Building target: BootCR.axf Invoking: MCU C++ Linker arm-none-eabi-c++ -nostdlib -Xlinker --gc-sections -Xlinker -Map=BootCR.map -mcpu=arm7tdmi -T BootCR.ld -o"BootCR.axf" ./src/DoCmd.o ./src/Emac.o ./src/Fldr.o ./src/PortIO.o ./src/Rc6.o ./src/Stip.o ./src/TestPins.o ./src/cr_startup.o ./src/main.o c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): In function `abort': abort.c:(.text+0xc): undefined reference to `_exit' c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_getpid_r': signalr.c:(.text+0x4): undefined reference to `_getpid' c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_kill_r': signalr.c:(.text+0x2c): undefined reference to `_kill' c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text+0x18): undefined reference to `_sbrk' collect2: ld returned 1 exit status make: *** [BootCR.axf] Error 1
Был у меня еще один проект, который собирался в gcc ранней версии (уже не помню в какой). Путем колдовства и добавления секций, таких как .сtors и .dtors результата не принесло,
только ошибки сменились. Потом засунул скрипт от старого проекта линкеру. Написал, что все скомпилилось с размером кода 0.
Вывод пока такой, что ребята не доделали поддержку C++ (генерятся неправильные файлы линковщика). Возможность вставлять свой файл есть.
Приведу изначальный скрипт компановщика.
Может кто знает, чего там не хватает, может кто-то уже использует эту среду с С++?
-
Но говорить - что это из-за того, что NXP ... - неправильный вывод.
Так скажите правильный вывод?
Компания NEC делает процессоры и трубит, что они лучше всех именно для автомобилей, мало подвержены сбоям, хорошо защищены от ЭМП и взломать их тоже не представляется возможным. Это они выдумывают наверное :)
Данные тоже могут испортиться, ну наверное когда у вас ОЗУ меньше, поэтому и вероятность меньше. Это только один фактор, подленность которого я сам не проверял.
Сбои процессора зависят не только от правильности разводки печатной платы, а также еще и от развотки на самом кристалле. Пусть если даже вы сделаете многослойную плату с хорошо разведенными землями, а разводка на самом кристалле будет плохая, то вы и получите в комплексе сбоящую систему, непонятно из-за чего, это может сильно сказываться на процессорах с большими корпусами, типа PQFP208 и тп. Ну наверное угадать от чего получаются сбои, от ЭМП или от других помех - задача непростая.
-
Я так понял, что "процессоры с Flash" - это МК с встроенной Flash, а "процессоры с RAM" - это МК с внешней шиной.
Все правильно вы поняли, это я неправильно выразился.
Почему сбоят микроконтроллеры с флешь меньше чем с озу, где-то попадалась статейка. Там было сказано, что изменить состояние прошивки, хранящейся во флешь гораздо труднее, чем в озу. Нампример где-то рядом произошел высоковольтный пробой, и от ЭМП в каком-нибудь месте кода программы изменился один битик, поэтому вместо какой-нибудь команды NOP получилась команда JMP, ну и дальше..... Так вероятность такого сбоя во флешь гораздо меньше. Из опыта знакомых и своего, могу сказать что раньше применяли ADSP-21xx в тех же условиях они часто сбоили :smile3009: . Сейчас применяем LPC23xx, сбоев пока не встречали.
От таких проблем собственно и придумали вочьдоги :)
-
Имеется опыт разработки устройств на LPC23xx, которые работают в среде, где происходят высоковольные пробои и т.п. В общем скажу следующее, процессоры с флешь гораздо меньше подвержены сбоям, чем процессоры с RAM. LPC23xx показал очень хорошие результаты, сбоев пока не наблюдалось. Прошивка без вочь догов. Однако у нас прибор переносной, поэтому на длительное время его никто в такой среде не оставлял. Максимум пару часов.
Зря народ так относится к этой теме. Это очень актуальный вопрос, где электроника стоит на моторах с потребляемой мощностью десятки и сотни киловат. Да и в других сферах.
Когда "наворачивается" электроника из-за сбоя одного контроллера за пару баксов и завод теряет миллион рублей :unsure: , уже не до смеха и шуток.
-
Нашел ответ на свой вопрос:
-
Тестировал два часа интерфейс I2s.
Кое-что порадовало, кое-что огорчило.
1. Может выдавать на ногу 72 МГц при PCLK = Fcclk, I2S_TXRATE = 0x00;
2. Реально не смог добиться скорости обмена в петле (соединение входа и выхода, когда Rx-Slave, Tx-Master) больше, чем Fcclk/4,
причем максимальная скорость обмена у меня заработала при настройках I2S_TXRATE = 0x01; PCLK = Fcclk/2. При остальных комбинациях вообще и это
не работает.
А очень хочется получить обмен при тактовой = Fcclk/2 (36Mbps);
Причем транслировался буфер с данными, при Fcclk/2 в буфере были забиты 0x01, вместо 0x00 0x01 0x02 и т.д. Это наводит на мысль, что не тянет внутренняя логика.
3. Скорее меннее интересно, но процессор у меня заработал на 74МГц без глюков.
Это все тестировал на примере, который идет с IAR в комплекте.
Теперь вопрос, кто-нибудь тестировал пункт 2, это действительно так?
Кто-нибудь подключал к этому интерфейсу DMA? А то примеров нет, и подключение нестандартное какое-то :unsure:
-
Задам такой вопрос:
16-битная шина, каждый разряд - LVDS(два сигнала). Тактовая частота 160МГц.
Шина подходит к ПЛИС EP3C16, PQFP240. Очень неудобная разводка LVDS линий у кристалла.
Получается, что шина окутывает ПЛИС с 3-х сторон. При этом длина проводников сильно отличается.
Вопрос, как правильно развести, надо ли выравнивать длины, жертвуя при этом местом на печатной плате, или достаточно удлинить сиглалы CLK+/CLK-? Или кто как поступает в таком случае?
-
Проверь приоритеты правил..
Спасибо всем. Проект выложить не могу.
Правило было одно на все полигоны!
В общем проблему победил криво. Создал новую плату,
туда скопировал эту. Создал там все теже самые правила.
Все залилось правильно. Не было вермени на разборки,
надо было срочно заказать. Как будет, постараюсь поковырять,
в чем было дело.
LPC23xx+CY7C68013A(Slave FIFO)
в ARM
Опубликовано · Пожаловаться
26 наверное маловато, тут на форуме читал, что Cypress в этом режиме способен выдать 12Мбайт в одну сторону.
А на филипсе скорость по 8-битной шине кто-нибудь тестировал?