GeorgK

По поводу дублирования с сишном и заголовочном файле - делал так: в описании сишного файла ссылаюсь на описание из заголовка: /** * \file * * \copybrief express::AGGREGATE_GENERIC::is_set_and_bag_instance_equal(const express::AGGREGATE_GENERIC&) const */ LOGICAL AGGREGATE_GENERIC::is_set_and_bag_instance_equal(const AGGREGATE_GENERIC& rhs) const { /** * Алгоритм: * * 1) Если какой-либо из операндов имеет неопределённое (\ref p11_s14_2 "?") значение, то результатом * сравнения является \ref p11_s14_7 "UNKNOWN" (см. \ref p11_s12_2 "п.12.2"). */ if (is_nil() || rhs.is_nil()) { return UNKNOWN; } А в заголовочном файле даю полное описание: /** * \brief Проверка равенства экземпляров (ГОСТ Р ИСО 10303-11-2009, \ref p11_s12_2_2_1 "п.12.2.2.1") * текущего \ref express::SET_GENERIC "набора" и указанного \ref express::BAG_GENERIC "пакета" * * \param [in] rhs \ref express::BAG_GENERIC "Пакет", с которым выполняется сравнение, * в виде константной ссылки на тип \ref express::AGGREGATE_GENERIC "AGGREGATE_GENERIC". * \retval TRUE если \ref express::SET_GENERIC "набор" и \ref express::BAG_GENERIC "пакет" равны; * \retval FALSE если \ref express::SET_GENERIC "набор" и \ref express::BAG_GENERIC "пакет" не равны; * \retval UNKNOWN если результат сравнения \ref express::SET_GENERIC "набора" и * \ref express::BAG_GENERIC "пакета" не определён. */ LOGICAL is_set_and_bag_instance_equal(const AGGREGATE_GENERIC& rhs) const; Тогда физически описание только в заголовочном файле, а в документации - и там, и там (в разных разделах про разные файлы).

Если уж очень нужны отступы, проще всего наставить нужное количество &nbsp. Да, в тексте будет смотреться не очень, зато в генерированной документации всё будет красиво.

Так можно же в поля загнать ёмкость и напряжение, а строку номинала формировать из этих полей.

Именно так. Пример: /** * \file * * \copybrief express::AGGREGATE_GENERIC::is_set_and_bag_instance_equal(const express::AGGREGATE_GENERIC&) const */ LOGICAL AGGREGATE_GENERIC::is_set_and_bag_instance_equal(const AGGREGATE_GENERIC& rhs) const { /** * Алгоритм: * * 1) Если какой-либо из операндов имеет неопределённое (\ref p11_s14_2 "?") значение, то результатом * сравнения является \ref p11_s14_7 "UNKNOWN" (см. \ref p11_s12_2 "п.12.2"). */ if (is_nil() || rhs.is_nil()) { return UNKNOWN; } ... /** * 2) Если размеры набора и пакета не совпадают, * то результатом сравнения является \ref p11_s14_3 "FALSE". */ if (length() != rhs.length()) { return FALSE; } ... /** * 3) По определению, экземпляр пакета 'a' равен экземпляру набора 'b' тогда и только тогда, * когда каждый элемент из набора 'b' присутствует в пакете 'a' только один раз, а пакет 'a' * не содержит элементов, которых нет в наборе 'b'. * * Для оптимизации будут определены вспомогательные массивы и реализован алгоритм, * описанный ниже. */ ... /** 3.1) Перебрать элементы набора левой стороны, при этом для каждого элемента: */ ... /** * * если элемент не равен себе (то есть результатом сравнения с собой является \ref p11_s14_7 "UNKNOWN"), * с другими элементами можно не сравнивать, результат будет такой же, поэтому * пометить его как "неизвестный", иначе пометить его как "посчитанный"; */ ... /** * 3.2) Перебрать элементы пакета с правой стороны, при этом для каждого элемента: */ ну и так далее.

Я, например, пришёл к тому, чтобы для понимания вложенности делать нумерацию через точку - типа 3.1, 3.2. А то доксиген просто числа (без точки) перенумеровывает по-своему, начинает нумерацию там где не надо. А так пробовал всё, что нашёл в документации по нумерованным и ненумерованным спискам. А так и в исходнике нормально смотрится, и в генерёной документации аккуратный алгоритм работы получается.

Есть ещё вариант параметрической генерации - паскалевский скрипт создаёт библиотеки графического обозначения, посадочного места, трёхмерной модели для всех номиналов (с правильными записями в параметрах и правильными надписями на трёхмерной модели). Пробовал так (правда, без графического обозначения) с OpenSCAD - в командном скрипте опенскадовская программа выдаёт через консольный вывод паскалевский скрипт, потом с другими параметрами создаёт набор трёхмерных тел (например, планарные корпуса разной ширины с разным количеством и шагом выводов), которые преобразуютсяиз stl в STEP, потом полученный паскалевский скрипт запускается в Альтиуме и создаёт библиотеку посадочных мест с корпусами.

У меня OpenSDAD, когда генерит скрипт для Альтиума, формирующий посадочные места с элементами, делает так: // Форма прогрес-бара echo(str(cmd, "object progressDlg: TProgressBarForm", ProgFnameF)); echo(str(cmd, " Left = 800", ProgFname)); echo(str(cmd, " Top = 500", ProgFname)); echo(str(cmd, " Caption = 'Please wait...'", ProgFname)); echo(str(cmd, " ClientHeight = 80", ProgFname)); echo(str(cmd, " ClientWidth = 500", ProgFname)); echo(str(cmd, " Font.Height = -11", ProgFname)); echo(str(cmd, " Font.Name = 'Tahoma'", ProgFname)); echo(str(cmd, " Position = poDesktopCenter", ProgFname)); echo(str(cmd, " TextHeight = 13", ProgFname)); echo(str(cmd, " object statusLabel: TLabel", ProgFname)); echo(str(cmd, " Left = 10", ProgFname)); echo(str(cmd, " Top = 10", ProgFname)); echo(str(cmd, " Width = 480", ProgFname)); echo(str(cmd, " Height = 24", ProgFname)); echo(str(cmd, " Caption = 'Processing'", ProgFname)); echo(str(cmd, " Font.Height = -11", ProgFname)); echo(str(cmd, " Font.Name = 'Tahoma'", ProgFname)); echo(str(cmd, " ParentFont = False", ProgFname)); echo(str(cmd, " end", ProgFname)); echo(str(cmd, " object ProgressBar: TProgressBar", ProgFname)); echo(str(cmd, " Left = 10", ProgFname)); echo(str(cmd, " Top = 40", ProgFname)); echo(str(cmd, " Width = 480", ProgFname)); echo(str(cmd, " Height = 17", ProgFname)); echo(str(cmd, " end", ProgFname)); echo(str(cmd, "end", ProgFname)); // Скрипт-обработчик прогрес-бара echo(str(cmd, "unit ProgressBarDialog;", PrognameF)); echo(str(cmd, "interface", Progname)); echo(str(cmd, "type", Progname)); echo(str(cmd, "TProgressBarForm = class(TForm)", Progname)); echo(str(cmd, " ProgressBar : TProgressBar;", Progname)); echo(str(cmd, " statusLabel : TLabel;", Progname)); echo(str(cmd, "end;", Progname)); echo(str(cmd, "var", Progname)); echo(str(cmd, " progressDlg : TProgressBarForm;", Progname)); echo(str(cmd, "implementation", Progname)); echo(str(cmd, "procedure ProgressInit(aMax : Integer);", Progname)); echo(str(cmd, "begin", Progname)); echo(str(cmd, " progressDlg.ProgressBar.Max := aMax;", Progname)); echo(str(cmd, " progressDlg.ProgressBar.Position := 0;", Progname)); echo(str(cmd, " progressDlg.Show;", Progname)); echo(str(cmd, "end;", Progname)); echo(str(cmd, "procedure ProgressUpdate(aCaption : String);", Progname)); echo(str(cmd, "begin", Progname)); echo(str(cmd, " if progressDlg.ProgressBar.Position ", scrchar, "< progressDlg.ProgressBar.Max then", Progname)); echo(str(cmd, " begin", Progname)); echo(str(cmd, " progressDlg.statusLabel.Caption := aCaption;", Progname)); echo(str(cmd, " progressDlg.statusLabel.Visible := true;", Progname)); echo(str(cmd, " progressDlg.ProgressBar.Position := progressDlg.ProgressBar.Position + 1;", Progname)); echo(str(cmd, " progressDlg.Refresh;", Progname)); echo(str(cmd, " end;", Progname)); echo(str(cmd, "end;", Progname)); echo(str(cmd, "procedure ProgressFinish;", Progname)); echo(str(cmd, "begin", Progname)); echo(str(cmd, " progressDlg.Hide;", Progname)); echo(str(cmd, "end;", Progname)); echo(str(cmd, "end.", Progname)); Инициализация: // Инициалзация прогрес-бара echo(str(cmd, " ProgressInit(", elem_num, ");", Scriptname)); Изменение: echo(str(cmd, " ProgressUpdate('", cname, "');", Scriptname)); И соответственно окончание работы с баром - ProgressFinish;

Большое спасибо за поддержку! Таки удалось решить эту проблему, теперь и пары создаются из любых механических слоёв, и видимость включается-выключается, и типы слоёв и пар назначаются. Проблема была в частности и в том, что Альтиум по своему усмотрению устанавливает тип переменных, иногда обращая внимание на объявление и ориентируясь на тип, передаваемый при первом присвоении.

Речь идёт о присвоении значения элементу Layer переменной например типа IPCB_track или другого типа-наследника IPCB_Primitive. Найденные доступные методы требуют enum, например eMechanical10, и не принимают типы, обозначаеные Альтиумом как Dispatch/IDispatch. Проблему с созданием пар удалось решить методом CreatePairByKind (у IPCB_MechanicalLayerPairs), который не требует указания образующих пару слоёв.

Здравствуйте! Не подскажет ли кто какой-нибудь способ скриптом размещать примитивы в механических слоях с 17 по 32? А то когда OpenScad создаёт файлы STEP и скрипт и он обрабатывается Альтиумом - всё нормально, в формируемой библиотеке стек слоёв создаётся, пары мех. слоёв назначаются и им присваиваются типы, примитивы переносятся куда надо, 3D модели приклеиваются - но кроме пар слоёв с номерами больше 16. Заранее спасибо за любые советы.

Тут и думать нечего - добавить заголовок с размером, CRC, адресом загрузки, номером версии и т.д . Загрузчик проверит корректность заголовка, целостность тела, выведет в консоль результат проверки, а потом загрузит тело и передаст ему управление.

Не ясно, где располагаются загрузчик с прошивкой (флеш NOR или NAND, флеш-диск и т.д.), т.е можно ли напрямую выполнять подпрограммы загрузчика из доступной области памяти или требуется копирование, разжатие, расшифровка и т.д. Можно собрать требуемые подпрограммы принципиально позиционно-независимыми и перемещаемыми, чтобы выдернуть их в ОЗУ, можно предусмотреть формирование в процессе сборки табличек для релокации (на основе соотв. сегмента из например ELF-файла, из которого формируется загрузчик - это зависит от используемой платформы, я делал такое для MIPS), которые используются для настройки подпрограмм после копирования в ОЗУ. Да, и достаточно ли будет ОЗУ для размещения в нём требуемого? Если же и загрузчик, и прошивка "прозрачно" читаются (то есть отображаются в адресное пространство) из флеша, достаточно предусмотреть формирование в известном месте списка адресов вызовов требуемых подпрограмм. По моему мнению, это "вкусная" задача для самостоятельной реализации, если же сроки поджимают, то да, согласен, целесообразнее искать готовое решение.

Возможен ещё вариант залоченных друг на друга синезубых приёмника и передатчика.

Классическое описание протокола: http://gallium.inria.fr/~doligez/zmodem/zmodem.txt Пользовался им в те времена, когда ваял свою терминалку.

Были ещё поляризованные реле с двумя обмотками - одна на включение, другая на выключение.