Allregia

А КНИ какой допустим? Самое простое - компаратор, получить меандр, триггер поделить частоту пополам, и потом ФНЧ более-мене высокого порядка, получить синус, без всякой "пилы".

Есть много симуляторов, то-же Протеус или EWB (сейчас он как-кто по другому называется, Мультисим, кажется). Я предпочитаю МикроКап (тем более что он уже бесплатный) и ЛТСпайс.

Может учет входного опера? По идее, оно должно было быть в его модели учтено.

Делитель просто два резистора, или все-же с конденсатором? Можно буферок на ОУ поставить - тогда с делителя можно постаивть более жестокий RC-фильтр. И если это отлично работает для 24-х битных аудиоЦАПов, то для 10-12-битного ЦАПа в МК точно подойдет. P.S. А что если из-за какого-то разброса параметров (стабилизатора например), у Вас окажется не -15 а -14.5в? Я в качестве источника смещения брал бы не -15, с которым выходное напряжение ЦАПа МК никак не связано, а наприяжение аналогового питания (или референса, не знаю что у Вас за МК). Тогда смешение и напряжение с ЦАПа будут связаны друг с другом, и середина кода в ЦАПе будет давать точно 0в на выходе. Если это конечно важно...

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

Еще и гальваническая развязка может быть не помешала бы. У меня в условияз сильных помех, отлично на 30-40м работало по уарту с токовой петлей и развязкой.

А для чего тут белый светодиод, как зеннер?

Есть (были) пъезощпищики с тремя выводами (один - основание, и два на кристалле).

Однако, для работы на единицах килогерцах, 40 лет назад такая индуктивность легко помещалась в наручных часах.

ИАР. Вопрос-же был не в этом, все распределено, указано, и положено куда следует. Вопрос был - сохраниться ли все это когда часть проекта будет скомпилирована как либа, и в виде либы (без исходников) подключена к остальному. Уже отеветили что да, сохранится.

Ну я не IAR-щик, поэтому по привычке называю "скаттер", задачи-то теже.

Разумеется он так и собирается делать, Просто сначала отладка "в окрытом виде". Не, там заказчики дотошные - скаттер ихний, и они в мар-файл тоже смотреть умеют.

Как я понял из его рассказа, у него есть проект, с исходниками заказчика, к которму он добавляет свои исзходники. После отладки в таком "окрытом виде", он удалает все чужое и компилирует как либу. Затем берез чужую часть и пдключает своб полученную либу. Получается, то если него все работает и память распределяется праивльно "в открытом виде", то и потом с либой все будет ОК? Спасибо. P.S. Не знаю, почему тему перенесли в тему про IAR - тут как бы "общий вопрос" програмирования а не "среды разработкти", непосредственно никак не касающийся самого IAR-а. Ничего бы не изменилось, если бы это был Кейл или какая-нибудь гнусность.

Тут вопрос от колеги, так что, "мопед не мой", сам я ответа не знаю.

Теория даст. если у нее будут ВСЕ исходные данные. А поскольку ВСЕХ нет, то чем их добывать, проще ткнуть осциллограф.

Наддо идти в ногу со временем - делать уже сразу и MQA!

Это типа ADGM1144? Цена может не понравится.

Я не переписывал весь код, писал по памяти. Там структура на структуре и каждая по полторы страницы, и указатели на указатель на указатель. Но в общем, ответ уже дали, что да. тип и имя могут совпадать. Будем завтра искать дальше. Вот я кусочек скопировал: typedef struct { float expp; float varr; float cnt; } rAvgS; typedef struct { float y_prv[2]; float y_N[6]; float y_S[6]; } ED; typedef struct { float S_d[100]; rAvgS pmS; rAvgS pmN; ED ED; } TotAdpt; Это IAR. Да я там выше от фонаря писал, те мболее что это вообще не мой проект а соседней группы. Вопрос-же был не в синтаксисе. но некторым оязательно надо вместо прямого ответа начинать цепляться к сторонним вещам. Всем спасибо.

Его никто и не давал. Это я и хотел спросить. Тогда тем более непонятно откуда глюк возникает. Неважно, проблема не в нем. Я у себя так и делаю (или вначате большую "Т" ставлю), а у алгоритмистов кодогенератор Матлаба с их помощью много чего наворотить может. Рассмативемый проблемный кусок, не тот что я выше с головы написал, а настоящий - это автоматически сгенерированный матлабом сишный код.

Проект не только собрается, но и работает в железе, на STM32H7. Но ведет себя очень странно, пока не уберешь тот цикл. Прерывание с более низким приоритетом блокирует один вызов прерывания с более высоким, причем происходящее уже после того как первое закончилось.

Разумеется, я исправил. То я с планшета писал.

Именно, я бы так и сделал:

Вопрос такой - может ли совпадать тип и имя переменной? Наши алгоритмисты чего-то нагородили в Матлабе, потом сгенерировали сишный код (под STM32), и происходят какие-то совершенно непоняные эффекты. Там сделано примерно так: Определена структура1 с типом структура1. потом определана структура2, одним из членов котороя является массив типа структура1 типа так: typedef struct { type member1; type member2; } struct1; typedef struct { type member1; type member2; struct1 struct1[100]; } struct2; // Эффекты происходят при: const char arr[100]={чего-то тут}; ... void func(struct2 *pstr2_name){ int i; ... for(i=0;i<100;i++) pstr2_name->struct1[i]=arr[i]; ... } Делаешь char tmp[100]; ... for(i=0;i<100;i++) tmp[i]=arr[i]; И все работает. Что вообще компилятор себе надумает, когда имя переменной совпадлает с его типом?!

У меня еще с ЛОСовских времен привычка - никаких русских букв вообще не должно быть в именах файлов и директорий. Как и любых других не русских, кроме 1-я половинки ASCII-таблицы. Без спецсимволов, конечно, а иногда и без пробела (некоторым программам и пробелы в путях/именах не нравятся). Все это гарантирует работоспособность на любом компе, с любыми языковыми и региональными настройками, и работу с любым софтом, в том числе и консольным. (например FAR, в зависимости от установленной локали, на те или иные не латинские буквы рисует квадратики или вопросики).

А то еще и транзистор.