GenaSPB

Зачем "однородно" настраивать? Выделите в порту те биты, которые работают шиной - в регистр PIO_OWER запишите единицы в эти биты. Это сделать при настройке. А в "быстрой" части программы писать в регистр PIO_ODSR нужное значение. Битики стробов и адресов дёргать через PIO_SODR и PIO_CODR

Блин, zheka, ну ведь дал же я образец переноса проекта... скачайте, посмотрите как сделано... Эти все вопросы там сделаны... typedef uint32_t prog_uint32_t; typedef char prog_char; #define PROGMEM /* */ #define pgm_read_byte(val) ((unsigned char) (* (val)))

О! а попробуйте такой вариант расчёта - const int top = timeUS * 1625 / (CPU_FREQ / 100000); Макрос RAMFUNC_NONILINE запрещал подстановку (инлайн) функции и требовал размещения кода в ОЗУ. Это нужно для работы в конфигурации с основным кодом в более медленном ПЗУ для того, чобы не изменялись расчётные времена. Так что не убирайте, а замените на то, что в Вашем компиляторе делает те же действия. pgm_read_byte в AT91SAM7S заменить на соответствующее обращение к памяти по указателю - этот процессор фон-неймановский, в отличии от гавардского ATMega. (или правильнее писать гарвардский?).

Скажите пожалуйста, есть какое-нибудь лекарство от exception handling при выполнении 64-битной арифметики (например, деления)? Для сведения, yagarto стал теперь arm-none-eabi и заболел тем же самым... Линковать stubs для getpid и isatty не предлагайте.

если нет необходимости отдавать время други тредам (процессам) - я при переносе проекта с ATMega на AT91SAM7S сделал просто так: // for 48 MHz CPU clock, execute from RAM rom with 1 read wait state // void RAMFUNC_NONILINE _delay_us(int timeUS) { // CPU_FREQ / 6500000 = 7 const int top = timeUS * 25 / (CPU_FREQ / 6500000); volatile int n; for (n = 0; n < top; ++ n) { } } // exactly as required // void _delay_ms(int timeMS) { volatile int n; for (n = 0; n < timeMS; ++ n) { _delay_us(1000); } } а вообще - пример переноса проекта в аттачменте (продолжает работать и на атмеге и на ARM).

А мне очень понравилось это расширение от привычной по AVR схемы. Вот как выглядят привычные подпрогаммы выдачи полубайтов: #define LCD_TARGET_PORT_S (AT91C_BASE_PIOA->PIO_SODR) #define LCD_TARGET_PORT_C (AT91C_BASE_PIOA->PIO_CODR) #define LCD_DIRECTION_PORT_S (AT91C_BASE_PIOA->PIO_OER) #define LCD_DIRECTION_PORT_C (AT91C_BASE_PIOA->PIO_ODR) #define LCD_INPUT_PORT (AT91C_BASE_PIOA->PIO_PDSR) // was PINA #define STROBE_BIT AT91C_PIO_PA31 #define WRITEE_BIT AT91C_PIO_PA1 #define ADDRES_BIT AT91C_PIO_PA0 #define DATAS_BITS (AT91C_PIO_PA26 | AT91C_PIO_PA25 | AT91C_PIO_PA24 | AT91C_PIO_PA23) #define DATA_BIT_LOW 23 // какой бит данных младшй в слове считанном с порта // sent four bits from d7..d4 of argument v static void ws1602_send4_high(uint_fast8_t v) { LCD_TARGET_PORT_S = (v << (DATA_BIT_LOW - 4)) & DATAS_BITS; LCD_TARGET_PORT_C = ~ (v << (DATA_BIT_LOW - 4)) & DATAS_BITS; } // send four bits from d3..d0 of argument v static void ws1602_send4_low(uint_fast8_t v) { LCD_TARGET_PORT_S = (v << (DATA_BIT_LOW - 0)) & DATAS_BITS; LCD_TARGET_PORT_C = ~ (v << (DATA_BIT_LOW - 0)) & DATAS_BITS; } static uint_least8_t ws1602_pulse_strobe(void) { uint_fast8_t v; LCD_TARGET_PORT_S = STROBE_BIT; // activate EN signal ws1602_delay(); v = (LCD_INPUT_PORT & DATAS_BITS) >> DATA_BIT_LOW; LCD_TARGET_PORT_C = STROBE_BIT; // deactivate EN signal ws1602_delay(); return v; }

Я про то, что это с минимальными проблемами позволило бы портировать счётчики из авровского проекта. uint_fast8_t вместо int_fast8_t - помню про архитектуры где беззнаковые сравнения дешевле чем знаковые. uint_fast8_t вместо int_least8_t - опять же про архитектуры и про то, что использование полного 32-х битного регистра при *fast скорее произойдёт, чем при *least (least более широкое множество типов может представлять, как мне показалось из текста стандарта Committee Draft — August 3, 1998 WG14/N843 - пункт 7.18 и его подпункты)

uint_fast8_t как раз для такого случая.

C:\user_old\ucc\sample>C32.EXE Cross-32 Meta-Assembler PC/MS-DOS Version 2.0S Copyright (C) 1992 Universal Cross-Assemblers Fatal Error -- No source file specified Это позволяло описывать обработку параметров и вставку их в битовые поля кода операции. Но ещё раз - свой собственный ассемблер, с генерацией бинарника, при желании дня за три написать можно. Мне-то проще, есть и линкер и заготовки кодогенератора... если не совмещаться с другшими системами разработки, можно под любой процессор.

Не смог найти нигде параметров (по спектру шумов) да и ничего вообще по ключевым словам оберон-2 в контексте генераторов. То, что шумы опорника в Вашем случае на рабочей частоте увеличатся как минимум на 30 дБ Вы в курсе? Может опорник обеспечивает -100 dBc/Hz @25 kHz - больше чем на -70 dBc/Hz @25 kHz рпасчитывать и не придётся.

Что работает опорником (его параметры) и какие частоты синтезируем - в каком диапазоне?

Какой уровень и на какой отстройке нужен? Даташит перед началом изготовления макета читали? Могу предложить отфильтровать ещё одной петлёй - но вопрос про скорость перестройки. КОроче, для ответа надо знать требования к синтезатору в цифрах - как минимум, диапазон частот, шаг, скорость перестройки, мощность, напряжение питания, требования по чистоте спектра. Морально готовьтесь выкинуть всё что сделано сейчас.

Взяли бы мегу восьмую и писали на WinAVR - достаточно эффективные встроенные функции деления 64/64 есть.

Коллеги, ничего не сдвинулось с места... Инсталирован openocd 0.3.1 _без каких_либо_изменений_в _конфигах (кроме адреса порта в parport.cfg). Запуск командной строки приведённой ниже что с rlink, что с parport с классическим wiggler выдяёт практически одинаковые сообщения: C:\user\dds2\TC1>openocd -d1 -f interface/rlink.cfg -f target/at91sam7sx.cfg -c init -c targets -c "halt" -c "flash write_image erase " -c "verify_image .\at91sam7s\tc1.elf" -c "reset run" -c shutdown Open On-Chip Debugger 0.3.1 (2009-11-13-16:13) $URL$ For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html debug_level: 1 srst_only srst_pulls_trst srst_gates_jtag srst_open_drain Warn : use 'at91sam7s.cpu' as target identifier, not '0' Error: 0 is not a supported speed TargetName Type Endian TapName State -- ------------------ ---------- ------ ------------------ ------------ 0* at91sam7s.cpu arm7tdmi little at91sam7s.cpu running Error: invalid mode value encountered 1 Error: cpsr contains invalid mode value - communication failure Runtime error, file "command.c", line 473: jtag_speed или jtag_khz ставил разные... При других debug level видно, что всё начинается после init. Тот же wiggler при работе из-под hjtag без проблем делает всё что надо и плата программируется. (не аппаратура виновата, похоже). Кто-нибудь может прислать работающий вариант конфигов и командного файла, прошивающего flash контроллера at91sam7s-какогоугодно или at91sam9xe512 ? Кроме того, будет интересно узнать с какой версией openocd идёт успешное программирование.

Проект не плюсовый? Вываливай... /DISCARD/ : { *(.eh_frame_hdr) *(.eh_frame) } (это в файле .cmd - скрипт линкера) Когда дойдёте до запуска программатора, поделитесь исправленными файлами .cfg от opencd.

До модификаций с комплектом Вашей сборки было около 50 килобайт, с yagarto 31 килобайт. Попробую добавить затычки на упомянутые функции - соберу и проверю, вечером. text 38172 - похожее значение было и с yagarto. Прошить прямо ваш elf не могу, так как плата существует в нескольких слегка отличающихся конфигурайиях.

Если библиотека собрана с поддержкой исключений - и вызывается такая функция (в моём случае, например, div или ldiv) - как с этим быть? Символы я определил (ондин из коллег здесь в теме выложил исправленный) в линк-скрипте. Можете выкинуть - тогда вообще не соберётся. Проекьт здесь в теме выложен - можете его "препарировать"? Я думаю, не только мне интересно. Или проблема только у меня?

Нет, обычный C код. Проект выкладывал в этой теме. А проблема в лишних 20 килобайтах которые явно не могут работать - всё на голом железе без имитации или заглушек на io. Вы собирались библиотеку перекомпилить для того, чтобы unwinding не использовался. В этой версии ещё нет? Проект выложен здесь: http://electronix.ru/forum/index.php?showt...st&p=712754

Как и в предидущем случае, затаскивается весь stdio. Даже не сравнить. .text 0x001066f0 0x1b0 c:/kgp_arm_eabi_20100226/bin/../lib/gcc/arm-kgp-eabi/4.5.0\libgcc.a(libunwind.o) 0x001066f0 __restore_core_regs 0x001066f0 restore_core_regs 0x0010670c __gnu_Unwind_Restore_VFP 0x00106714 __gnu_Unwind_Save_VFP 0x0010671c __gnu_Unwind_Restore_VFP_D 0x00106724 __gnu_Unwind_Save_VFP_D 0x0010672c __gnu_Unwind_Restore_VFP_D_16_to_31 0x00106734 __gnu_Unwind_Save_VFP_D_16_to_31 0x0010673c __gnu_Unwind_Restore_WMMXD 0x00106780 __gnu_Unwind_Save_WMMXD 0x001067c4 __gnu_Unwind_Restore_WMMXC 0x001067d8 __gnu_Unwind_Save_WMMXC После этого уже всё остальное.

Исходя из того, что reset из j-tag адаптера выходит (тестовая плата перезапускается) и остальные команды выполняются - о чём сообщает всякая диагностика подключёного к j-tag процессора. То есть, нижний уровень работает. Да, openocd + wiggler тоже не грузят программу. Только hjtag + wiggler. Вывод - я как-то не так обращаюсь с openocd. Но что ещё, кроме конфигурационных файлов, может влиять?

Сообщение об ошибке не изменилось... Как и в ручном режиме (через telnet) - после выдачи halt получаю сообщение о том, что с cpsr не то значение и так далее... C:\user\dds2\TC1>openocd -d0 -f interface/rlink.cfg -f target/at91sam7sx.cfg -c init -c targets -c "halt" -c "flash write_image erase " -c "verify_image .\at91sam7s\tc1.elf" -c "reset run" -c shutdown Open On-Chip Debugger 0.3.1 (2009-11-13-16:13) $URL$ For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html debug_level: 0 30 kHz srst_only srst_pulls_trst srst_gates_jtag srst_open_drain Error: invalid mode value encountered 1 Error: cpsr contains invalid mode value - communication failure TargetName Type Endian TapName State -- ------------------ ---------- ------ ------------------ ------------ 0* at91sam7s.cpu arm7tdmi little at91sam7s.cpu unknown Error: invalid mode value encountered 1 Error: cpsr contains invalid mode value - communication failure Error: invalid mode value encountered 1 Error: cpsr contains invalid mode value - communication failure Runtime error, file "command.c", line 473: Да, эта же плата через тот же 20-пин разъём шъётся wiggler-ом через h-jtag без проблем.

Кажется, скоро появится возможность исользовать Altera USB Blaster. Сконфигурировать UrJtag для записи в мне так и не удалось... Но новый openocd 0.4.0 теперь имеет поддержку адаптера Altera USB Blaster. Пока тренируюсь на плате с at91sam7s32 и Raisonance USB JTAG. Конфигурирование проходит, но для любой операции с flash требуется процессор приостановить... а в ответ получаю: Может кто-нибудь поделиться скриптом для openocd, который бы просто записывал во внутренний flash процессора файл? Отладка через jtag не интересует.

Я включал между выходом max3232 и входом RXD ATMega128L резистор на 1 килоом - и никаких проблем.

А чего тут криминального? Чтений из volatile ровно столько, сколько надо. А от чтения по указателю на простой (не volatile) тип - ничего, кроме знаачения не гарантируется. А откуда оно его взяло - целиком на усмотрение оптимизатора. Вообще, всё что не volatile, может быть "закешированно" при входе в функцию и записано перед выходом из неё или вызовом чего-либо.

Обновлся h-jtag, работает под Vista, Windows-7. Стал версия 1.0 release. LPT порт НЕ ОТРЕЗЛИ (автор в prerelease собирался отказаться от поддержки программатора на LPT).