Jump to content

    

GeorgK

Участник
  • Content Count

    66
  • Joined

  • Last visited

Community Reputation

0 Обычный

About GeorgK

  • Rank
    Участник
  • Birthday 07/27/1968

Информация

  • Город
    Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Большое спасибо за поддержку! Таки удалось решить эту проблему, теперь и пары создаются из любых механических слоёв, и видимость включается-выключается, и типы слоёв и пар назначаются. Проблема была в частности и в том, что Альтиум по своему усмотрению устанавливает тип переменных, иногда обращая внимание на объявление и ориентируясь на тип, передаваемый при первом присвоении.
  2. Речь идёт о присвоении значения элементу Layer переменной например типа IPCB_track или другого типа-наследника IPCB_Primitive. Найденные доступные методы требуют enum, например eMechanical10, и не принимают типы, обозначаеные Альтиумом как Dispatch/IDispatch. Проблему с созданием пар удалось решить методом CreatePairByKind (у IPCB_MechanicalLayerPairs), который не требует указания образующих пару слоёв.
  3. Здравствуйте! Не подскажет ли кто какой-нибудь способ скриптом размещать примитивы в механических слоях с 17 по 32? А то когда OpenScad создаёт файлы STEP и скрипт и он обрабатывается Альтиумом - всё нормально, в формируемой библиотеке стек слоёв создаётся, пары мех. слоёв назначаются и им присваиваются типы, примитивы переносятся куда надо, 3D модели приклеиваются - но кроме пар слоёв с номерами больше 16. Заранее спасибо за любые советы.
  4. Тут и думать нечего - добавить заголовок с размером, CRC, адресом загрузки, номером версии и т.д . Загрузчик проверит корректность заголовка, целостность тела, выведет в консоль результат проверки, а потом загрузит тело и передаст ему управление.
  5. Не ясно, где располагаются загрузчик с прошивкой (флеш NOR или NAND, флеш-диск и т.д.), т.е можно ли напрямую выполнять подпрограммы загрузчика из доступной области памяти или требуется копирование, разжатие, расшифровка и т.д. Можно собрать требуемые подпрограммы принципиально позиционно-независимыми и перемещаемыми, чтобы выдернуть их в ОЗУ, можно предусмотреть формирование в процессе сборки табличек для релокации (на основе соотв. сегмента из например ELF-файла, из которого формируется загрузчик - это зависит от используемой платформы, я делал такое для MIPS), которые используются для настройки подпрограмм после копирования в ОЗУ. Да, и достаточно ли будет ОЗУ для размещения в нём требуемого? Если же и загрузчик, и прошивка "прозрачно" читаются (то есть отображаются в адресное пространство) из флеша, достаточно предусмотреть формирование в известном месте списка адресов вызовов требуемых подпрограмм. По моему мнению, это "вкусная" задача для самостоятельной реализации, если же сроки поджимают, то да, согласен, целесообразнее искать готовое решение.
  6. Возможен ещё вариант залоченных друг на друга синезубых приёмника и передатчика.
  7. Классическое описание протокола: http://gallium.inria.fr/~doligez/zmodem/zmodem.txt Пользовался им в те времена, когда ваял свою терминалку.
  8. Были ещё поляризованные реле с двумя обмотками - одна на включение, другая на выключение.
  9. Возможно, что-то не так с платформенно-зависимыми настройками, завязанными на многопоточность, мьютексы, почтовые ящики? Состояние портов получал MIIшными запросами к "физике" коммутатора, проблемы были только в результате ошибок в самодельном переключателе контекстов и при слишком частом их переключении (около 100000 раз в секунду). А так HTTP, DNS, DHCP, Telnet, NetConsole нормально работали. Делал по примерами из документации к lwIP.
  10. Кстати, в lwIP есть свой менеджер памяти - самостоятельно раздаёт память из выделенной области. Или это именно он глючный? Я-то с проблемами со стороны стека не сталкивался, возможно, из-за слишком щадящих условий.
  11. Вы совершенно правы, когда мне захотелось реализовать в загрузчике сетевую консоль (telnet, netconsole), именно по этой же причине пришлось переходить на lwIP - следующее поколение uIP и прикручивать многопоточность.
  12. Извиняюсь заранее, если это прописные истины.
  13. Там разве не по адресам-портам в том числе исходящим пакеты определяются? И по уникальному номеру соединения TCP. насколько помню, без проблем делал несколько "серверов" - DHCP, DNS, httpd.
  14. Первое, что приходит на ум - согласованный фильтр. Тем более на ПЛИС хорошо параллелятся обработки с разным сдвигом фазы.
  15. У lwIP есть свой менеджер памяти (это настраивается в заголовочном файле), ему просто выделяется область памяти, которой он будет распоряжаться. Так что в этой части вопросов возникнуть не должно. А если есть многозадачность, почему бы тогда не прибивать эту задачу и пускать заново? А что касается низкого уровня, ему нужны только функции "принять пакет" и "послать пакет", так что их можно и не трогать - ну придёт из очереди старый пакет и будет проигнорирован. А uIP многозадачность вообще не нужна, но возможно именно поэтому мне не удалось подружить его с телнетом - консоль выполнения команд всё-таки логично делать как отдельный поток.