ViKo

Скорее всего, для инициализации того, что выделено из кучи, используется стек.

В книжках (Г.Шилдт) она фигурирует, как стандартная. Вот первая же ссылка из Интернета, я понимаю так, что по крайней мере, в C99 она уже есть. http://www.thinkage.ca/english/gcos/expl/c/lib/atoi.html Вот еще: Standards The atoi function conforms to ISO/IEC 9945-1:1990 ("POSIX.1"), ISO/IEC 9899:1990 ("ISO C90"), and ISO/IEC 9899:1999 ("ISO C99"). Другое дело itoa - вот такой функции в стандарте нет.

Я думал, речь про передачу идет. Т.е., сначала вы строку преобразовываете в целое, а потом выводите целое в виде строки?! А просто строку вывести что-то мешает?

А если приглядеться внимательнее к передаваемому формату, то для 32-битового числа со знаком получается ±2147483648, итого 12 байтов. x10 = 120 битов. x8.7 = 1042us atoi как раз является... только она здесь не нужна.

А stdlib.h включен в исходный файл?

Проверил работу программы из Flash без отладчика. Вот такой код из Flash работает (в самой программе ExtDpy2LCD_copy проверку TCIF убрал). Причем, независимо, с отладчиком или без. while (1) { ExtDpy2LCD_copy(0, 320*240/2); if (FPI.FP_Rdy) { FPI.FP_Rdy = 0; FPI_Process(); // здесь пишу в EXTDPY } while (!(DMA2->ISR & DMA_ISR_TCIF1)); // ждать флаг прерывания } А из RAM (внутренней, естественно) такой код не работает. Независимо от того, вывожу в окне содержимое памяти, или нет. Если проверку TCIF поставить сразу после ExtDpy2LCD_copy, тогда работает и из RAM.

Если не ошибаюсь, полгода назад та же девушка задавала здесь вопрос, не успевала, плакала и т.д. Что ж, получается, всю жизнь за вас кто-то будет учиться, работать? Или вас так плохо учат, что ничего в голове не остается? нашел ссылку, чтобы не быть голословным. Правда, не о ПЛИС был вопрос, но "стиль" остался тем же. http://electronix.ru/forum/index.php?showtopic=82557

Что вы предлагаете мне проверить таким образом?

Это пишут про внутреннюю шину. Заметил странное явление. Добавил код , обращающийся к внешнему ОЗУ, к области, не используемой для буфера ЖКИ. uint8_t *pExtTest = (uint8_t *)EXTRAM; for (uint32_t i=16; i--; ) { *pExtTest++ = (uint8_t)pExtTest; } Когда запускаю программу, она работает, если в Keil не включаю окно с Memory 3, где смотрю EXTRAM (0x64000000). Как только переключаюсь, флаги DMA (0x40020400) становятся 0x0D (ошибка). Т.е. средства отладки отбирают пропускную способность шины. Если же смотреть, например, окно Memory 2, с адресами 0x40020400, вижу флаги 0x05, изредка 0x07. В-общем, программа работает.

Боюсь, тоже будут конфликты. Надо попробовать поработать с внешней памятью (с другой областью), когда идет процесс DMA.

Верно-верно. Дело не в микроконтроллере или ПЛИС, а в линии передачи. По RS-232 сигналы на сотни метров передаются. Мало ли что по дороге случится. И тактовые генераторы у передатчика и приемника разные. А если устройства рядом, тогда лучше по SPI послать.

Попытал счастья с кодом, выполняемым из Flash. Показываю время в ms для пересылки с помощью DMA и программной, для кода из Flash и RAM DMA Program RAM 19.5 21.5 ROM 19.75 21.0 Смотрел осциллографом, за точность до 1% не поручусь. Можно сказать, цифры остались примерно теми же. Подозреваю, что все дело во временах работы контроллера ЖКИ. Попробую в будущем уменьшить до предела допустимого. Еще у меня SysTick таймер раз в 1ms выполняет несколько команд. Пустое... При работе из Flash попробовал не делать проверку, что установлен флаг TCIF. То есть, записывать в буфер ОЗУ, когда из него читает DMA. Результат - по-прежнему вылазят ошибки.

Если из 3-х выборок бита хотя бы две находятся в состоянии "1", принимается решение, что бит равен "1". На основе "большинства проголосовавших".

Не будет. Теоретически, совсем ничего не будет слышно.

Из даташита на AD828, первого, что нашел. И у Burr-Brown найдется решение. Ищите.

1. Нет, это я упрощенно назвал "двигать картинку". Там меняется изображение. У меня Epson и есть, но не поможет. 2. Нет, то, что сделал - классическое решение. По скорости устраивает. Вопрос был про DMA. Нельзя одновременно обращаться к памяти по DMA и программно.

Правильно. На вопрос, зачем, отсылаю вас в эту тему http://electronix.ru/forum/index.php?showtopic=85989 о как ссылками перекрестными обложился :)

Ну какой конфликт, если работает? Частота процессора 72MHz. ОЗУ статическое IS62WV26516BLL-55. Контроллер ЖКИ S1D13706, работает от тактовой частоты 36MHz, старался настроить на наиболее быструю работу. Настройки работы с памятью: // -- Bank1 NE2 - RAM 256K x 16 -- FSMC_Bank1->BTCR[2] = 0x00001011; // 16-bit,NoMux,SRAM,En FSMC_Bank1->BTCR[3] = 0x000f0300; // Mode1 0(+1)\_3_/(+1) // -- Bank1 NE4 - LCD 128K + 128K(80K) -- // Читать-писать 16-битовыми или 8-битовыми словами FSMC_Bank1->BTCR[6] = 0x00009011; // ASWait,WrEn,WrapDis,FlashAccDis,16-bit,SRAM,NoMux,En FSMC_Bank1->BTCR[7] = 0x000f1200; // Mode1 0(+1)\_18_____ _/(+1) Да и не при чем это все. Качественное соотношение останется тем же, независимо от быстродействия устройств. Заглянул на вашу ссылку. Читаю... У меня контроллер ЖКИ медленный до безобразия. И память -55 Еще я не сказал - код выполняется из ОЗУ микроконтроллера. Тоже понижает быстродействие. У меня скорость пересылки по DMA получилась 3750 KB/s. Контроллер ЖКИ тормозит.

Сделал буфер во внешней памяти. Можно сказать, результат устраивает. Кое-что интересное предлагаю посмотреть здесь http://electronix.ru/forum/index.php?showt...st&p=886168

Правильно ли я понимаю, что во время работы DMA нельзя программе залазить в память, с которой работает DMA? Вот такую функцию исследую, пока не дожусь конца передачи, дальше не иду. (Не показана установка режима работы, и разрешение тактирования, это делается однократно в начальной установке). Тогда все работает. Иначе, если программа пишет туда, откуда читает DMA, появляется прерывание TEIFx Channel x transfer error flag. А прерывания, что дошло до конца, уже нет. Если все так, то ценность такого DMA уменьшается. Почти то же можно реализовать, как у меня в закомментированном коде. void ExtDpy2LCD_copy(uint32_t Offset, uint32_t Size) { LED_On(); DMA2->IFCR |= DMA_IFCR_CTCIF1; DMA2_Channel1->CCR &= ~0x00000001; // запретить пересылку DMA2_Channel1->CPAR = EXTDPY + Offset; // начальный адрес буфера экрана DMA2_Channel1->CMAR = 0x6c020000 + Offset; // начальный адрес памяти ЖКИ DMA2_Channel1->CNDTR = Size; // 16-битовые пересылки DMA2_Channel1->CCR |= 0x00000001; // разрешить пересылку while (!(DMA2->ISR & DMA_ISR_TCIF1)); LED_Off(); /* uint16_t *pSour = (uint16_t *)(EXTDPY + Offset); uint16_t *pDist = (uint16_t *)(0x6c020000 + Offset); LED_On(); for (uint32_t i=Size; i--; ) { *pDist++ = *pSour++; } LED_Off(); */ } Еще один факт для размышлений. Измерил осциллографом время работы показанной выше функции. Для Size = 320*240/2. С DMA имею 20ms, без DMA 21.5ms. Естественно, польза от DMA будет, если, пока байты перекидываются с места на место, процессор будет занят чем-нибудь другим. Например, принимать данные по другим интерфейсам и складывать во внутреннее ОЗУ. Надеюсь, это не притормозит работу DMA.

У меня, практически, такой же файл upd Такой, да не совсем. Посмотрите на мои 2 и 3 строки. По-моему, у вас ошибка. FUNC void Setup(void) { SP = _RDWORD(0x20000000); // Setup Stack Pointer PC = _RDWORD(0x20000004); // Setup Program Counter _WDWORD(0xE000ED08, 0x20000000); // Setup Vector Table Offset Register xPSR = 0x1000000; } // RESET // MAP 0x64000000, 0x6407ffff read write // MAP 0x6c000000, 0x6c03ffff read write // MAP LOAD Keil_Minimal.axf incremental // Download Setup(); // Setup for Running G , main А периферию я не использую, выкинул все. Может, перестарался :) Вот весь файл с майн #include "stm32f10x.h" uint32_t Cnt; int32_t main(void) { while (1) { Cnt++; } } А "Define" что? :) Ага, нашел. Нет, у меня такого нет. Работает и так. У меня: STM32F10X_HD upd2 И с Go разобрался - нужно писать G, а не GO. Исправил в файле, все работает! (ну и лох же я) :)

Спасибо, помогло. Теперь новая напасть вылезла. Не находится main функция в минимально простеньком проекте. LOAD Keil_Minimal.axf incremental // Download Setup(); // Setup for Running GO ,main ______^ *** error 34, line 26: undefined identifier Хотя main в проекте есть, и по командам симулятор доходит и до нее.

Do not use LCELL primitives to create an intentional delay or asynchronous pulse. The delay of these elements varies with temperature, power supply voltage, and device fabrication process, so race conditions can occur and create an unreliable circuit Нашел это. Ну, что сказать - не используйте... там где не надо :) Одно точно знаю - сигнал после LCELL будет задержан, после двух LCELL уже можно сделать приличный импульс, а после трех и волноваться не о чем. Так же, как в "рассыпной" логике.

Если последний вопрос ко мне, то я понял, что это не документ Altera, а книжка, например, Антонова. Если так, то мне этого недостаточно :) Уже говорил когда-то, пока проект можно делать синхронным, нужно делать. Если же потребуется более короткое время, чем такт, никуда не деться, придется использовать и учитывать внутреннее устройство ПЛИС.

Перефразируя ваш ответ, получаем: "Никогда не программируйте ARM на ассемблере! Используйте только готовые библиотеки!" :)