GenaSPB

Ну что делать, если топикстартера на гугле забанили? Вот я и сложил сюда рабочий проект. Вот оригинал из двух функций: http://faq.embedders.org/_examples_code/re...www.markh.de).c

приём rc5 и складывание в буфер.

Не вникая в доставаемость - параметрический поиск от АналогДевайсов выдал AD7356 и AD7357. Ещё немного поискал - вообще на ваш случай AD7626. Интересный момент - до 3 MS/S выбор гораздо больше. Ваш случай (4 MS/S) сильно ограничивает в выборе микросхем. Осталось узнать, выдержит ли требуемую тактовую (32 МГц для 8 бит АЦП) SSC. Ещё подумал о внешнем перобразователе паралельного кода в последовательный. PS: только сейчас заметил, что Вам надо 2 MS/S. Всё проще будет. Нет, в данном случае формировать сигналы для запуска перобразования пришлось бы программно.

Для этого процессора - частота работы процессора и частота тактирования периферии равны. Варианты применения внешнего АЦП с последовательным интерфейсом и приспособить для передачи данных от него SSC или SPI рассматривали? А так - без прерываний, с запрещёнными прерываниями, в цикле - считывать с паралельного порта. И то, озаботиться о первых командах - пока заполнится конвеер.

Генерацию прерывания с частотой 4 МГц на этом процессоре - зачем? (не успеть обработать). Или какие-то ещё побочные эффекты будут использоваться? Просто выход с частотой 4 МГц получить при тактовой частоте, кратной 8 МГц (или 16 МГц в случае если требуется меандр на выходе) вполне возможно - минимальный предделителдь для таймера 2. Вот вам кусок кода из проекта - может, поможет? /* инициализация внутреннего умножителя частоты. Вход - 12 МГц, кварцевый резонатор внутренняя тактовая - 48 МГц, частота генератора - 96 МГц Частота сравнения PLL = 12 МГц */ static void lowlevel_init_pll_clock_48_xtal12(void) { enum { osc_mul = 8, osc_div = 1 }; // 12 MHz / 1 * 8 = 96 MHz // before reprogramming - set safe waitstates AT91C_BASE_MC->MC_FMR = AT91C_MC_FWS_2FWS; /////////////////////////////////////////////////////////////////////////// // Init PMC Step 1. Enable Main Oscillator // Main Oscillator startup time is board specific: // Main Oscillator Startup Time worst case (3MHz) corresponds to 15ms // (0x40 for AT91C_CKGR_OSCOUNT field) /////////////////////////////////////////////////////////////////////////// AT91C_BASE_PMC->PMC_MOR = (((AT91C_CKGR_OSCOUNT & (0x40 << 8)) | AT91C_CKGR_MOSCEN)); // Wait Main Oscillator stabilization while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MOSCS)) ; /////////////////////////////////////////////////////////////////////////// // Init PMC Step 2. // Set PLL to 96MHz (96,109MHz) and UDP Clock to 48MHz // PLL Startup time depends on PLL RC filter: worst case is choosen // UDP Clock (48,058MHz) is compliant with the Universal Serial Bus // Specification (+/- 0.25% for full speed) /////////////////////////////////////////////////////////////////////////// AT91C_BASE_PMC->PMC_PLLR = AT91C_CKGR_USBDIV_1 | AT91C_CKGR_OUT_0 | (AT91C_CKGR_PLLCOUNT & (16 << 8)) | // PLL lock signalling delay (AT91C_CKGR_MUL & ((osc_mul - 1) << 16)) | (AT91C_CKGR_DIV & osc_div); // Wait for PLL stabilization while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_LOCK)) ; // Wait until the master clock is established for the case we already // turn on the PLL while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)) ; /////////////////////////////////////////////////////////////////////////// // Init PMC Step 3. // Selection of Master Clock MCK equal to (Processor Clock PCK) PLL/2=48MHz // The PMC_MCKR register must not be programmed in a single write operation // (see. Product Errata Sheet) /////////////////////////////////////////////////////////////////////////// AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2; // тактовая частота процессора 96 / 2 = 48 // Wait until the master clock is established while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)) ; AT91C_BASE_PMC->PMC_MCKR = (AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_PLL_CLK); // Wait until the master clock is established while (!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)) ; // as final stage - set desired waitstates AT91C_BASE_MC->MC_FMR = AT91C_MC_FWS_1FWS; // 1 Wait State to work at 48 MHz }

Прошу прощения, обознался.

В листинге было одно предупреждение, советую проанализировать, что бы это значило. Смените тип процессора с ATMEGA16A на ATMEGA16 или смените название обработчика с USART_TXC_vect на USARTTXC_vect Ну хоть немного понитересуйтесь содержимым заголовочных файлов компилятора (что происходит после включения файла io.h), ещё раз - ну загляните наконец в чужой работающий проект! Про скорость: Регистр широкий, в зависимости от тактовой и скорости надо грузить значение в обе половины: UBRRH = (value >> 8) & 0xff; UBRRL = value & 0xff;

Судя по всему, какая-то библия... о которой все должны и так знать, без разъяснений.

В атмеге 16 UCSRA, например. И ISR(USART_TXC_vect) Но у Вас ATMEGA168, как я понял из тем других Ваших тем?

CS единицей. В том проекте, что в другой теме я Вам подсказал, как раз программный SPI сделан.

Не Вы пересечётесь (хотя, можете вполне). Это используется в заголовочных файлах стандартной библиотеки, чтобы не пересечся с Вашими оперделениями, которые не должны начинаться с подчёркивания, например.

Если не боитесь утонуть - посмотрите в проект в первом сообщении темы http://www.cqham.ru/forum/showthread.php?t=13856 - файл TC1-Aug-10-2011.zip‎ Там есть target для atmega32 - аналогичен atmega16. Инициализация всякой периферии, во многих местах русские комментарии. И конечно, даташит от производителя. За точными значениями битиков, названий SFR - только туда.

В исходном коде написано, что использует аппаратные ресурсы AT90S8515, а компилируете как для процессора atmega16a. В Вашем случае просто выкиньте эту строчку.

Можете заархивировать в .zip или, как обычно, .7z ? Раньше работало...

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_font.o ../uc1601s.o ../twi.o ../t c1.o -mcpu=arm7tdmi -flto -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref,--no-warn-mismatch -lm -o tc1_rom.elf lto1.exe: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: arm-kgp-eabi-gcc returned 1 exit status c:/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.7.0/../../../../arm-kgp-eabi/bin/ld.exe: lto-wrapper failed collect2.exe: error: ld returned 1 exit status make.EXE: *** [tc1_rom.elf] Error 1 Заранее предупреждаю, старого каталога с бинарниками не существовало, всё разархивировано начисто (WinRAR, из-за такого экзотического формата архива). Старые .o тоже были стёрты. Это проект под at91sam7 Без -flto не сыпется, результат на работоспособность не проверял.

Исходники функци передачи символа покажите. 0) не очень хорошая идея свои переменные (имена) начинать с подчёркиваний. Теоретически можно нарваться. В заголовочных файлах такое применяется для того, чтоьы с пользовательскими define не пересечься. Все приведённые Вами примеры располагают массив символов в ОЗУ. Формулу зависимости количества мусорных символов от параметра -O выводить не надо. Надо с причиной разбираться. Имейте в виду, что у других всё работает.

...

Извинте на назойливость.... А можно windows-x86_32?

volatile uint16_t *poi = (uint16_t*) MAS_DAT; volatile uint16_t i = 0, l = 0; Хотелось бы узнать смысл квалификатора volatile во второй строчке. Ну и в первой, за одно. Ещё, по недоброй традиции копипэймта, и pPIO как volatile обявили? Так Вы всё сделали для замедления программы. разумнее было бы ловить фронт (через IRQx) и считывать конкретное количество сэмплов. Похожая (по ловле HSYNC) задача была при реализации on screen display. Подумайте о применении АЦП с последовательным интерфейсом - и использовании ПДП на SSC.

Не нулевое время требуется. Что интересно, это оказалось единственным перпятствием к завершению работ. Так же выяснилось, что _все_ делают полные алгоритмы, один я такой... Вот и взвешиваю - не послать ли. Заказчик обладает некоторым опытом программирования.

Теперь понятно, отчего горе? Именно _весь_ _код_ _должен_ _быть_ _документированы_. Блок-схемой алгоритма... Скорее всего, в архив. Как образец показали алгоритм embedded программы, работающей на PIC (байт 800 кода как результат трансляции "С"). Вот там рисунок алгоритма есть, есть обширное словесное описание. А то, что в виндовой части 90% это обслуживающая часть, не имеющая отношения к работе программы... Один контрол самописный и работа с com-портом + конфигурационный диалог без самодеятельности. Ну это так... вопль с тоски. Спасибо за помощь. Конкретнее - кто-нибудь документировал служебные функции MFC?

Грустно то, что куча функций фреймворка, не несущих никакого смысла для понимания функционирования задачи, находятся в исходниках проекта. И какой смысл описывать например такое: // The system calls this to obtain the cursor to display while the user drags // the minimized window. HCURSOR CIndicdDlg::OnQueryDragIcon() { return (HCURSOR) m_hIcon; } или такое: // If you add a minimize button to your dialog, you will need the code below // to draw the icon. For MFC applications using the document/view model, // this is automatically done for you by the framework. void CIndicdDlg::OnPaint() { if (IsIconic()) { CPaintDC dc(this); // device context for painting SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0); // Center icon in client rectangle int cxIcon = GetSystemMetrics(SM_CXICON); int cyIcon = GetSystemMetrics(SM_CYICON); CRect rect; GetClientRect(&rect); int x = (rect.Width() - cxIcon + 1) / 2; int y = (rect.Height() - cyIcon + 1) / 2; // Draw the icon dc.DrawIcon(x, y, m_hIcon); } else { CDialog::OnPaint(); } }

typedef struct { int x_numicons; int y_numicons; int iconnumber[10]; } imenu_icons_t; typedef const char *imenu_text_t[10]; typedef struct { imenu_icons_t *menu_idle; imenu_icons_t *menu_active; imenu_icons_t *menu_icon; imenu_text_t *menu_text; } imenu_t; imenu_icons_t main_icon = {1, 1, {2, 3, 4, 5, 6, 7, 8, 9, 10, 11}}; imenu_icons_t main_idle = {10, 1, {12, 13, 14, 15, 16, 17, 18, 19, 20, 21}}; imenu_icons_t main_active = {10, 1, {22, 23, 24, 25, 26, 27, 28, 29, 30, 31}}; const char * main_text[10] = {"STR1", "STR2", "STR3", "STR4", "STR5", "STR6", "STR7", "STR8", "STR9", "STR10"}; imenu_t mainmenu = {&main_idle, &main_active, &main_icon, &main_text}; int icon_menu(imenu_t *pmenu) { unsigned char current = 0, i; char *ptr; // Â ôóíêöèè ïîêàçàíî íå âñå, ïîýòîìó ïóñòü íå ñìóùàåò åå áåññìûñëåííîñòü for(i = 0; i < entries; i++) { ptr = (char *)pmenu->menu_text[i]; } return current; } unsigned char ic; void xmain(void) { ic = icon_menu(&mainmenu); }

Есть проект - обычное win32 mfc, dialog based. Отображает некий техпроцесс - используются own draw контролы, часть обмена с компортом... СОбственно, заказчик захотел блок-схему алгоритма. Есть некоторая растеряность (кто не знает - в проекте куча файлов, обеспечивающих "игру по правилам" применённого фреймворка, собственно отображалкпа - это процентов десять от объёма текст). Как может выглядеть "блок-схема алгоритма" таких событийно-управляемых приложений? ps: c MFC начал работать ещё в 1995-м году. Опыт работы программистом более 25 лет.

Вообще, раз видите ARM7TDMI 0x3F0F0F0F - всё уже нормально. Теперь сотрите процессор подачей сигнала на вход erase и припаяв кварц попробуйте ещё раз.