Arlleex

А, понял. Ок. На листы разбивать хорошо - даже поощрительно: название листа отражает то, что на нем находится. У меня тоже есть проекты с десятками листов - очень удобно.

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

Насколько я помню - itoa ограничивает длину строки 33 и 65 символами для int и long long, соответственно. Буквально вчера отказался от монструозных sprintf(), чтобы ужать first-bootloader под МК на нужный размер.

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

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

Почему при введении шаблона функции нужно обязательно присутствие всех параметров шаблона в качестве формальных параметров функции? Т.е. допустимо template<class A, class B> void func(A a, B b) { ... } и недопустимо template<class A, class B> void func(A a) { B b; ... } несмотря на то, что тип B используется в теле функции. Учебники пишут только декларативно, зачастую (как в моем случае) не объясняя причин.

20 лет назад выпадали, и щас зашел посмотреть - ничего не изменилось...😆

Я беру максимальную размерность прямоугольника, в который можно вписать плату. Для прямоугольной платы - максимальная сторона. ИМХО, по-другому просто не имеет смысла.

Посмотрите еще hirose df-12, df-40...

https://developer.arm.com/documentation/ka002915/latest/ Не понятно, какие команды отладчику дает IDE-шка при запуске сеанса отладки, как таковых настроек я не вижу. Но, видимо, флешка таки обновляется перед входом в отладку.

Load Application at Startup почему установлен? И что в настройках J-Link во вкладке Settings?

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

Что с галками Load Application at Startup, Update Target before Debugging и Download to Flash по кнопке Flash -> Configure Flash Tools... -> Debug/Utilities?

Вы что, под дебаггером смотрите либо? Так он подгружает из сгенерированного elf, а не из вашего измененного бинарника.

Я к тому, что эта конструкция должна приводить к ошибке компиляции.

Это вообще что? Какой компилятор такое компилит?

Пишу шаблон структуры и задаю все необходимые мне специализации enum Command { SPI_SEND_FLASH, SPI_SEND_RAM, SPI_SEND, SPI_FILL, SET_PIN, RESET_PIN, WAIT, CALL }; template<Command> struct Descriptor; template<> struct Descriptor<SPI_SEND_FLASH> { Command cmd : 3; bool dc : 1; u32 addr : 19, size : 9; }; ... template<> struct Descriptor<CALL> { Command cmd : 3; u16 arg; }; Теперь самое важное: создаваемые структуры должны быть упакованы, чтобы компилятор не вольничал. Для экономии памяти мне обязательно нужно, чтобы все структуры занимали одно 32-битное слово. Если я укажу атрибуты в объявлении template<Command> struct __attribute__((packed)) Descriptor; , то "распространится" ли этот атрибут на определения специализаций? Или мне в каждой специализации теперь писать этот атрибут? P.S. Отвечаю себе сам. Нет, не распространяется и, судя по всему, просто игнорируется молча. Каждой специализации нужно задавать атрибуты отдельно.

Это ток в цепи приемного оптрона, не передающего. Т.е. передатчик у меня выдает в петлю примерно 33 мА, из них 24 мА идет в оптрон, а остальные поглощаются резистором, параллельным светодиоду. С передающим все отлично - осциллограммы привел. Там не нужен большой ток от МК - он через оптопару лишь управляет источником тока. Я сейчас делаю передатчик и приемник по схеме, данной заказчиком в качестве "у нас так реализовано и работает". Как по мне, странная схема. Потому что это никакая не токовая петля, на мой взгляд.

Понял. Про коэффициент передачи помню, сейчас ток в цепи светодиода 24 мА при лог. 1. Значит, на выходе максимум 12 мА. Резистор 300 Ом подойдет, но тогда будет вопрос с задержкой. Идиотизм, если честно))) И ведь в аппноуты иногда пихают схемы на этих оптронах (обычных), которые в реале не работают нихрена.

А можно ли током светодиода как-то предотвратить насыщение? Я бы мог резистор, параллельный светодиоду, взять поменьше тогда. Но модель показывает, что это вообще ни на что не влияет. P.S. Резистор 100 Ом подтяжки выхода оптрона совсем плох - сигнал прыгает от 2 до 3.3 В, т.е. транзистор в "закрытом" состоянии не совсем и закрыт))) Поэтому поставил 220 Ом. В итоге: в идеальном UART 19200 длительность битов 0 и 1 равны 52 мкс. У меня получились 46 и 58 мкс. Ну, не знаю, насколько это стабильно будет работать.

Вот меня интересует этот самый пологий "разбег" фронта. Это транзистор оптрона в жестком насыщении, что ли?

Нет, стандартного 232 там нет. По неизвестным мне причинам, заказчику нужен был именно UART, прокинутый по токовой петле. Т.е. информация передается током, принимается тоже ток. Возможно, связано с какими-то историческими причинами, мне не ведомо🙂 P.S. Поснимал осциллограммы, есть надежда что нужно будет поправить только входную часть (цепи приема)

Вот с такими номиналами получаю Зеленый - сигнал на ножке TX микроконтроллера. Желтый - напряжение между выводами защитного ограничителя на приемной стороне. Все идеально, я бы сказал, посмотрите на задержки по курсорам. Щас поисследую, что на выходе оптрона. Ну как мне казалось, что токовая петля как раз нужна для того, чтобы работать от тока и никакие емкости ей не страшны P.S. Вот что на выходе оптрона, но до инвертора с триггером Шмитта (зеленый). Желтый - по-прежнему напряжение на входных контактах токовой петли Вот где основновная собака порылась.

Не понимаю, что Вы имеете в виду? Push-Pull на TX от МК.

В данном случае без разницы, думаю. У меня вопрос встал только с изоляцией - вот оптрон и подвел)))