jcxz

Ясно. "Чукча не читатель, чукча писатель". Тогда ничего не поможет, продолжайте в том же духе.....

Вроде как должно быть очевидно, что отлаживать нужно начинать не с МК<->МК, а с МК->ПК и МК<-ПК. Дабы не валить всё в одну кучу, а решать задачу по частям. И выкинуть всё это безобразие с кучей контактов (непонятного качества), а нормально распаять соединения. Чтобы не плутать в 3-х соснах из-за плохого контакта в куче соединений.

"Манёвренность"? Правда что-ли??? А как же тогда малоподвижные жабы, с удовольствием лопающие этих "манёвренных мух" со всеми их ганглиями, а не мрущие с голодухи в своём малоподвижном болоте? Да и обычной человеческой рукой можно наловчиться их ловить. Не говоря уже об обыкновенной резиновой мухобойке, которая ни разу не "живой организм"?

Какой размерности?? sin(x % 360); где x - ваше большое число (если угол в градусах). Какая тут размерность аргумента функции sin()?

Кроме напряжения, утечка ионистора также сильно зависит от температуры. Ионистор - не лучший выбор. Лучше использовать какие-либо конденсаторы с малым током утечки.

Читал-читал, но так и не понял - в чём именно проблема у ТС? Какая-то каша в сообщениях. Для хранения чисел со 150-ю десятичными знаками достаточно: ln(10^150)/ln(2)/8 = 63 байта. Каким образом для хранения и обработки числа размером в 63 байта ТСу не хватает 100Гб - не могу представить. И в чём именно состоит проблема - посчитать синус от числа 10^150??? Вообще непонятно... Синус - функция периодическая (что должно быть известно из школьного курса математики). Значит его значение можно посчитать от чисел практически любой разрядности. PS: Надеюсь делить и брать остаток от деления ТС умеет? Если да, то и посчитать синус от числа любой разрядности - не должно составлять труда.

Если не поняли, повторю вопрос ещё раз: Как предлагаете определять эту утечку? Хоть ток хоть энергию.

И как предлагаете ток потребления от ионистора отделять от его тока утечки?

Интересно - все тут чукчи-писатели что-ль? ТС в самом начале вроде ясно написал: +-10V

1. МК с АЦП с ШИМ + 2 ключевых транзистора + RC. 2. МК с АЦП и с ЦАП + ОУ. Только один корпус - вряд-ли получится. Хотя-бы 1 транзистор нужен.

Это ещё ерунда. Хуже что она не позволяет контролировать переполнение буфера. И не позволяет перегрузить функцию записи выходного потока символов на пользовательскую. А семейство printf это всё умеет. PS: Бесконтрольный sprintf (без контроля переполнения) имхо - моветон.

Зачем их исправлять если они у вас и так разные?

Если гора не идёт к Магомету, то может Магомету пойти к горе? Если нельзя отказаться от линуха и он обязательно нужен, то может тогда заменить контроллер на такой, в котором есть подходящая периферия, которая позволит реализовать нужную диаграмму работы SPI? (и при этом не мешать работе линуха на нём же). Или хотя-бы есть отдельное ядро, которое можно выделить исключительно для эмуляции SPI?

Так в том то и проблема, что у ТС не IAR. С IAR-ом всё просто - в свойствах подключения эмулятора указываешь нужный серийный номер и IAR работает только с этим эмулятором. Т.е. - с J-Link-ами так точно работает. ST-Link я уже давным-давно не использовал, может с ним есть какие-то проблемы. Но все ST-Link-и следовало уже давно заменить на J-Link-и (или хотя-бы перешить). PS: Меняем Кубепрограммер на IAR, а ST-Link-и на J-Link-и. И получаем стабильную и безглючную работу хоть с пятью устройствами одновременно.

Серийный номер нужно смотреть не в кубепрограммерах, а в свойствах USB-устройства (дескрипторе USB). Так как именно сер.номер USB используется при энумерации системой. А там видимо USB-сер.номера одинаковые (раз конфликтуют). И не факт, что после изменения сер.номера в кубепрограммере, USB-сер.номер изменится.