GenaSPB

За Watcom не скажу, но я 32-х битную часть в разное время компилировал Borland C 5.2, потом Visual C. 16-ти битный код - сперва Borland, а потом 16-ти битный кусок уменьшился до пары сотен байт (когда я перестал грузить в нём файлы) и он оказался ассемблерным. В проект, что я выложил, как инструмент входит линкер (что-то мне не удалось сделать стандартным, не помню). Кроме отладки через netboot я ещё делал загрузочные образы CD и с них тестировал... флоппи-диски уже начали вымирать. Да, найдите ассемблер от Microsoft - ml.exe. Он входит, например, в DDK. небольшая часть кода, запускающая ядро (и некоторые компоненты C run-time library), написаны на ассемблере. Не хотел, но все-таки напишу... Найдите отладочную плату с каким-нибудь ARM... и начните с нуля на нём. Когда я повторял путь многих людей, делавших то же самое (загрузчики, переход в protected mode, ядро), кроме просто изучения "а как устроенно ядро" предполагал использовать этот опыт для встроенных систем там, где не хватало мощности других микропроцессоров, где требовалась 32-х битная машина. Опыт остался, как побочный эффект - легче с драйверописанием для NT/XP, а во востраиваемых системах Intel386 так и не оказался.

Г.В. Орловский Введение в архитектуру микропроцессора 80386 Сеанс-Пресс LTD. Санкт-Петербург 1992 Одна из частей - сводная таблица команд процессора (это лучше смотреть в оригинале). ПОНЯТНО объяснена архитектура управления памятью. В приложении - ассемблерный код, который можно заставить (мне удалось) работать. Там заготовка, переводящая процессора в protected mode и оставляющая машину работать в V86. MMU не инициализируется. ВОбщем-то, все опечатки (их немного, до десятка) не мешают пониманию. Если Вы в Питере - могу подарить эту книгу. Поискал - нашёл немного напоминающее по стилю http://programmer.newmail.ru/programs/protect/PROTECT.HTM Погуглите насчёт UNREAL MODE - интересный трюк, разберитесь как он делается - будет понятнее, как работает x86. А дебажил - "двоичным методом". Самое безопасное - это ставить контрольные точки переходом "сам на себя". И смотреть - машина зависла или перезагрузилась (из-за двойного исключения). Я так свой загрузчик отлаживал. Лучше иметь "подопытную машину" - с NETBOOT через сеть - всё идёт быстрее. К сожалению не нашёл тех исходников - прикладываю то, чем всё кончилось...

klen, я привёл кусок функции. Естественно, никаких возвратов указателей из функции не происходит. Ключи компилятора в том проекте, что Вы уже один раз исследовали. На всякий случай выделяю минимальный код: unsigned long long v; unsigned char n; int main(void) { v <<= n; v >>= n; return 0; } Ключевм моментом являетмся неконстантный счётчик сдвигов. вы присваиваете константному указателю Вобще-то указатель не константный, а указатель на константу... Разница вот: const char * cp; и char * const pc;

AT91SAM7S64, ARM mode, проект (tc1*.zip) я выкладывал. Объём (от yagarto) стал меньше процента на 3-4. Код вот: void prog_dds1_ftw(const uint_least64_t * value, unsigned char freqpow, unsigned char ddsmult) { uint_least64_t val; if (freqpow != 0) { val = * value << freqpow; // собственно эта строка value = & val; } } А что насчёт прерываний скажете? Похоже на то, что не возвращается или не входит в прерывание. Можете сказать, какие регистры надо сохранять? (у меня ассемблерный кусок обработчика такой): IRQHandler: /* Save interrupt context on the stack to allow nesting */ sub lr, lr, #4 stmfd sp!, {lr} mrs lr, SPSR stmfd sp!, {r0, lr} /* Write in the IVR to support Protect Mode */ ldr lr, =AT91C_BASE_AIC ldr r0, [r14, #AIC_IVR] str lr, [r14, #AIC_IVR] /* Branch to interrupt handler in Supervisor mode */ msr CPSR_c, #ARM_MODE_SVC stmfd sp!, {r1-r3, r4, r12, lr} mov lr, pc bx r0 ldmia sp!, {r1-r3, r4, r12, lr} msr CPSR_c, #ARM_MODE_IRQ | I_BIT /* Acknowledge interrupt */ ldr lr, =AT91C_BASE_AIC str lr, [r14, #AIC_EOICR] /* Restore interrupt context and branch back to calling code */ ldmia sp!, {r0, lr} msr SPSR_cxsf, lr ldmia sp!, {pc}^

Наконец-то в одном месте собрались Jtag-программатор, я и отлажтиваемое устройство... Получаю от линкера undefined reference to `__aeabi_llsl' - в коде в указанном месте сдвиг 64-х битной переменной влево. Закоментировал. Часть кода заработала. В целом проект не заработал (прпрывания не запустились, что-ли?).

После того, как версия H-JTAG сменилась с 1.0 preview на 1.0 release поддержка LPT интерфейса вернулась.

Правильнее будет - дождаться окончания передачи всего что ждёт (должны быть флаги соответствующие у UART), а не таймаутом.

Оставить только //настройка предделителя частоты AT91C_BASE_US0->US_BRGR = baud; Разнести настройку режимов работы от настройки скорости.

void f(...) { static const unsigned char a [] = {0x01, 0x02, 0x03 }; } Если кто-то забыл static написать, так и будет.

в том проекте, на который я ссылаюсь, есть кусочек теста скорости. Находящийся в ОЗУ (тактовая - 48 МГц, 1WS) кусочек кода переключает состояние выхода. Минимальный интервал между изменениями состояния - около 55 наносекунд. Максимальный побольше (переход в цикле добавляет пару тактов). Частота сигнала на выводе получается 8 с чем-то мегагерц. Это в процессоре питаемом от 3.3 вольта - атмеги при этом тактовую 8 МГц позволяют. Надо бы конечно и потребление сраавнить. Но мне кажется, удобства программирования (фон-нейман! 32-бита арифметика!) велики.

Зачем "однородно" настраивать? Выделите в порту те биты, которые работают шиной - в регистр 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.