ViKo

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

Из компьютера. Вот такой функцией Keil_Temp.ini, запускаемой при отладке func void Setup (void) { SP = _RDWORD(0x20000000); // Setup Stack Pointer PC = _RDWORD(0x20000004); // Setup Program Counter _WDWORD(0xE000ED08, 0x20000000); // Setup Vector Table Offset Register } map 0x64000000, 0x6407ffff read write map 0x6c000000, 0x6c03ffff read write // map Load Keil_Temp.axf incremental // Download Setup(); // Setup for Running G , main

В тестовом примере путем урезания памяти LR_IROM1 0x20000000 0x00010000 {; load region size_region ER_IROM1 0x20000000 0x00010000 {; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20010000 0x00010000 {; RW data .ANY (+RW +ZI) } } Добился, что uint16_t ExtDpyBuf[0x0010] __attribute__((at(0x64000000))); вываливается с ошибкой Keil_Temp.axf: Error: L6985E: Unable to automatically place AT section keil_temp.o(.ARM.__AT_0x20000208) with required base address 0x20000208. Please manually place in the scatter file using the --no_autoat option. Нет! Все не так. Оно уже и без буфера то же пишет! Надо добавить памяти. Там в другом дело было. Пока убрал. Дальше вожусь...

Обычный ; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_IROM1 0x20000000 0x0000D000 {; load region size_region ER_IROM1 0x20000000 0x0000D000 {; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x2000D000 0x00003000 {; RW data .ANY (+RW +ZI) } } Располагаю в ОЗУ, экономлю ресурс флэш. А вот из map куски Load Region LR$$.ARM.__AT_0x64000000 (Base: 0x64000000, Size: 0x00000000, Max: 0x00006c00, ABSOLUTE) Execution Region ER$$.ARM.__AT_0x64000000 (Base: 0x64000000, Size: 0x00006c00, Max: 0x00006c00, ABSOLUTE, UNINIT) Base Addr Size Type Attr Idx E Section Name Object 0x64000000 0x00006c00 Zero RW 214 .ARM.__AT_0x64000000 sledk_main.o Code (inc. data) RO Data RW Data ZI Data Debug 18166 1432 7206 516 37700 328496 Grand Totals 18166 1432 7206 264 37700 328496 ELF Image Totals (compressed) 18166 1432 7206 264 0 0 ROM Totals Total RO Size (Code + RO Data) 25372 ( 24.78kB) Total RW Size (RW Data + ZI Data) 38216 ( 37.32kB) Total ROM Size (Code + RO Data + RW Data) 25636 ( 25.04kB) Тут какая-то декомпрессия присутствует...??

точнее, блоки называются begin - end

Добавил атрибут uint16_t ExtDpyBuf[0x9600] __attribute__((at(0x64000000), zero_init)); не помогло, все по-прежнему. Ошибка линковки, естественно. Но с размерами там все в порядке. Start 0x64000000, Size 0x80000 Внутреннее ОЗУ я разбил на 2 части: 48KB под код, 16KB под данные. Попробую изменить пропорцию. Пробовал через scatter файл, да что-то "ниасилил". Что любопытно. Пишет А секция .ANY - это ж для кода (+RO). И что там делает агрегат? Не влазит что-то другое? Там перед этим много чего написано, что не влазит... Передвинул беду на размер массива 0x3600 (этот линкуется, 0x4600 - уже нет), сдвинув пропорцию код/данные в отношение 0xD000/0x3000 Похоже, при объявлении массива во внешней памяти какой-то код все-таки создается. И чем больше массив, тем больше кода. Чудеса?

STM32F103ZE, ARM 32-bit Cortex-M3 Microcontroller, 72MHz, 512kB Flash, 64kB SRAM, Flexible Static Memory Controller for SRAM, PSRAM, NOR and NAND Flash. Stack_Size EQU 0x00000400 Heap_Size EQU 0x00000200 Все должно работать из внутренней Flash, на время отладки гружу код во внутреннюю SRAM - отвел половину для кода в настройках проекта в Keil. Адреса для внешних устройств формирует FSMC. Адрес нормальный. ОЗУ тестировал раньше. Да дело и не в этом. Код не компилируется.

Буду смотреть, что творится с массивом во внешней памяти при определении. Но возникла идея побочная - а зачем мне именно массив определять. Буду по указателю гонять данные в ExtDpyBuf. Адрес и размер задам с помощью #define, компилятор во внешнюю память сам ничего не положит. Другие области этой памяти буду импользовать аналогично. Т.е. возьму роль линкера для внешней памяти на себя. :)

Обычно инженеру хватает 3-х тау (точность 5%), ошибку посчитаете e-t/RC

В тестовом проекте Keil создаю массив во внешней памяти uint16_t ExtDpyBuf[0x9600] __attribute__((at(0x64000000))); и больше ничего не требуется - ни scatter файл править, ни свойства в визарде менять. Код генерируется. Хотя нигде даже не упоминается про этот регион. В рабочем проекте задаю тот же массив, меняю свойства, и - никак! Выдает Уменьшаю массив до 0x2600 - пожалуйста! Все влазит. Что делать? Кто съел мою память? upd. Еще добавлю - если атрибут уберу, компилируется. Потому что не используется. upd2. Еще. Имею 2 Project Targets - ROM и RAM. Во втором разделил ОЗУ на две части для кода и данных. Вот именно в нем и не работает. А в ROM - влазит. Как будто для инициализации массива используется память?

Понял. Признаю - такое полиномом не восстановить. :(

Может. Эталон шумит во всей полосе частот, согласно плотности распределения шума. Если мы ограничим полосу, то получим менее шумный сигнал (или питание в данном случае). Представим здоровенный LC фильтр с полосой 0.000001 Hz. Что останется от шума? No pasaran :)

Помимо шума существует проблема помех, и решать их нужно комплексно - схемотехнически, конструктивно. Источник питания здесь далеко не на первом месте. Вот интересно, у phantom уже есть неудачный опыт проектирования своего усилителя, или пока только планы? Может, имеет смысл показать схему, которая требует такого малошумного источника питания?

Про "рыбу" так и не понял ничего. :) А возник один вопрос. Если мы знаем, что у нас оцифрован синус, так почему бы нам и не интерполировать точки синусом!? Не полиномом каким-то "левым"... Только как это сделать?

Так дайте ему эту функцию! Я вот - дал. :) И не один вариант, а целую кучу. А он еще и свою придумал, которая для него будет "стандартной" (будем надеяться, не надолго).

Но от этого он не становится "не-синусом"? Разве нельзя интерполировать ("восстановить сигнал") синус, оцифрованный по 2,00...1 точкам на период? Котельников говорит, что можно. А мы не можем... :( Так какой вывод следует? Правильно - плохо восстанавливаем :)

В книжках есть, в библиотеках же, увы, далеко не во всех. Потому как не является стандартной. К ней применимы все вышеперечисленные термины, кроме самого главного - стандартизованный :)

Неправильно поняли (как и vadimuzzz чуть раньше). Поднимите верхнюю полуволну вверх - получите синус. Ваш старший бит все время в нуле. Или все время в единице.

Теорема Котельникова никогда не отдыхает :) То, что здесь именуется рыбой - это резкие скачки на интерполированном сигнале, вроде хвоста рыбьего? То есть, вместо того, чтобы соединить точки плавной кривой (полиномиальной, синусоидальной), вдруг - скачек. При чем здесь Котельников? Реализация алгоритма кривая.

А как вы думаете, почему? Может быть, не соблюдаются требования теоремы Котельникова?

Теперь вам нужно удостовериться, что выполняются все временные требования для ЦАП - частота тактов, времена предустановки и удержания и т.п.

Уважаемый господин sergeeff Уж вам-то следовало бы знать, что нет стандартной функции itoa(). Она может присутствовать в некоторых компиляторах в виде подарка. Конкретно, есть ли она в WinARM - большой вопрос. Мне казалось, вы были в курсе, судя по "бойкому" ответу вот здесь http://electronix.ru/forum/index.php?showt...st&p=674374

Будет, все будет... Только идеальный фильтр НЧ может подавить спектр в областях fold, 2fold, и так до fnew (которая останется). Так как идеального фильтра сделать невозможно, эти области не подавятся полностью. Нужно ограничиться необходимой точностью.

Особенно, если вспомнить, что коэффициент ослабления помех по питанию у операционных усилителей равен около 100dB

А до интерполяции ваш сигнал похож на рыбу? Даже соединив точки синусоиды отрезками (линейная интерполяция), вы не получите сигнал, похожий на рыбу.