ARV

Не работает туплю Разобрался - с указателями зашился... Спасибо за помощь!

И все-таки не очень понятно: а как расшифровывать? Зашифровал по этому алгоритму. При расшифровке просто меняются местами "Открытый текст" и "Зашифрованный текст"? На каком этапе делать XOR предыдущего этапа с очередным?

Спасибо, что-то проясняется.

Не могу разобраться в принципе шифрования/дешифрования блочными алгоритмами. Вот берем, например, XTEA - реализация алгоритма обрабатывает блок в 64 бита (8 байт). Но если брать, допустим, файл, и зашифровать его блоками по 8 байт, то в результирующем файле будут четко прослеживаться 8-байтовые блоки, особенно хорошо заметные на областях, заполненных одинаковыми значениями байтов... При этом если я шифрую при помощи онлайн-сервисов, результат совсем другой - никаких закономерностей не просматривается. Видимо, что-то не так делаю я, но что?!

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

Слишком сыро. Дисплей высотой 768 точек (ноут) - главное окно не влезает целиком по вертикали, часть "кнопок" просто недоступна. Размер окна меняется, но можно сделать только хуже.

Вопрос-то был про переменное количество аргументов в функции, а не про парсинг строк...

А вот за это - благодарю! Хотя не на каждом компе есть права админа... но пока есть.

Вряд ли существует альтернатива... Так что это пока единственный вариант. Аналогично. Но на работе IDE не стоит :) приходится носить ее с собой... Думаю, вы легко можете повторить мою проблему, если вставите в компьютер несколько флешек, чтобы ваша с воркспейсом стала другой буквы диском... Только у вас IDE не найдет сам воркспейс, и вам придется его указывать вручную... И в списке воркспейсов у вас будет два одинаковых, но с разными дисками. В общем, если бы Eclipse заставить не сохранять абсолютные пути проектов, а только относительные (хотя бы относительно воркспейса), то проблема была бы решена...

Так с воркспейсом проблемы и не было! Проблема с проектами, которые в этом воркспейсе хранятся. То есть IDE видит упоминание моих проектов в воркспейсе, но когда пробует их открыть, не находит нужных путей. Название проекта и путь к его файлам, как я понимаю, разделены - первое видно в окне воркспейса, а второе - в свойствах самого проекта. Но вот как в пути к проекту избавиться от буквы диска?

Ну, когда Workspace создавал, я принудительно убрал букву диска из пути, поэтому все Workspaces у меня "относительные". Когда создаю проект - это не помогает, буква все равно подставляется Eclipse и где-то сохраняется. И Workspace со всеми проектами и IDE Eclipse у меня на том же самом диске, напоминаю.

@AleksBak, по шагам: запускаю Eclipse с USB-диска, вижу в окне Workspace свои проекты. Кликаю на проекте и вижу сообщение о том, что проект не найден. Смотрю свойства проекта и вижу, что там указана "не та буква" диска.

Коллеги, есть такая проблемка, прошу помощи. Workspace у меня хранится на съемном USB-диске, который я таскаю между разными компьютерами. На нем же Eclipse и необходимые тулчейны. Т.е. этакое переносное хранилище рабочего места. Все было бы замечательно, но Eclipse упорно сохраняет где-то (не могу понять, где именно) проекты с абсолютными путями, поэтому если вдруг винда захочет присвоить моему USB-диску другую букву (не ту, что была в прошлой сессии), проект не открывается. Нужно как-то эту проблему решить... Если невозможно "по уму", т.е. средствами Eclipse или каким-то плагином для него, то хотя бы ткните носом в то место, где эта гадюка сохраняет пути к проектам в Workspace - я их вручную исправлю на относительные.

Судя по наличию DPTR в коде либо тема выбрана не верно, либо топикстартер вообще не понимает, о чем ведет речь.

Жаль...

Создал тему Сделал ссылку на неё на другом форуме - и с той ссылки нельзя зайти в тему. Пишет, недостаточно прав для просмотра публикации. Этот раздел форума закрытый, что ли?

Если узлы у вас скомпонованы и пронумерованы разумно, то "по порядку" и будет "по узлам". Например, 1** - это входной узел, 2** - это основной усилительный каскад, 3** - блок питания, 4* - защита. и прекрасно, даже не глядя в схему, просто по списку можно все расставлять. Сомневаюсь, что при ином подходе вы вот так сразу (даже) для своей схемы вспомните, в одном или разных узлах находятся С23 и С101.

Ну, на безрыбье... хватило бы, да. Но вы только представьте себе расстановку пары сотен конденсаторов, пары сотен резисторов и нескольких десятков ОУ... Одного выделения будет маловато для комфорта.

Скажите, коллеги, а нет ли плагина какого-нибудь для облегчения ручной расстановки компонентов на плате? В древнем DOS-овском OrCAD была очень удобная фишка: при расстановке командой Place задается маска (например, L* или L1*) и на "курсор" сразу цепляется первый подходящий компонент. После того, как его в нужное место поставишь, просто нажимается кнопка N (команда Next) и сразу выбирается следующий компонент по этой маске, и так до исчерпания подходящих компонентов. Само собой, если ввести не маску, а полное обозначение - выберется только один компонент (как сейчас в pcbnew). В pcbnew же существует только единственный вариант - вручную вводить полное обозначение каждого компонента или выбираеть его из списка - по сравнению с описанным алгоритмом очень неудобно. В списке никак не помечаются компоненты, которые уже расставлены, в итоге постоянно его надо скроллить... при количестве компонентов в пару десятков с этим еще можно мириться, но когда их количество переваливает за сотню - уже утомительно весьма. Может кто сможет скрипт-плагин для этого сделать?

Раньше было так: исполняемый код DLL грузился в память 1 раз при первом обращении к системной функции загрузки DLL, а затем при каждом следующем вызове этой функции просто увеличивался счетчик загрузок, а код оставался в одном экземпляре. А область данных для нужд DLL выделялась в области вызывающего приложения, т.е. для каждой загрузки DLL получала память основного приложения. Разные приложения могли загружать одну и ту же DLL, и при этом код DLL был для них в одном экземпляре, а данные DLL - разные. Поэтому какая-то экспортируемая функция DLL могла вернуть указатель на данные, и основная программа могла с данными по этому указателю работать, как будто это её собственные данные. Сейчас и код, и данные при каждой "загрузке" DLL изолируются от памяти основного приложения, и никакие указатели без особых ухищрений передать из DLL в основной код нельзя. Так понятно объяснил?

Затем, что современные виндовсы совсем не те, что были раньше. Раньше подобный вопрос и не возникал бы вообще. А сейчас... Вот недавно я выяснил, что современные версии винды (семерка и новее) для DLL выделяют свою память данных (раньше данные выделялись в сегменте данных главного приложения), поэтому просто так взять, и передать указатель на данные DLL нельзя, надо с бубном плясать... Поэтому и спрашиваю у профессионалов или хотя бы просто знающих программистов, как решать подобные моей задачи. Если я не очень детально описал свои вопросы - так задайте мне наводящие, чтобы я понял, что надо пояснять.

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

Это ведь будет сильно зависеть от того, на каком компьютере будет запущено, с какой скоростью порт будет принимать данные и т.п. непредсказуемых вариантов использования. Задачу я понимаю так: сделать самым оптимальным способом, чтобы во всех случаях работало (ну или хотя бы приблизиться к идеалу). Я описал проблему так, как я сам её понимаю. Я оперирую функциями: функция получила на входе данные (из порта), что-то сделала с ними и вызывает аналогичную функцию следующего "фильтра", передавая ей данные. Получается, именно следующему пихаются данные, а не следующий тянет их. Т.е. у меня поток данных течет по обработчикам, а не обработчики, высасывающие откуда-то данные. Возможно я не прав, но я не профессионал, и мне простительно

FIFO уже на уровне драйвера порта сделано: оттуда уже приходит от 1 до 0xFFFF байтов. Считаете, проблема "медленной обработки" за счет постоянного копирования туда-сюда данных, надумана?

Заголовок темы краткий, поясняю смысл вопроса на примере последовательного порта. Из порта поступают байты, которые надо обработать. Для обработки используются т.н. фильтры - модули, получающие на вход поток байтов и содержащие список следующих фильтров, куда направляют поток данных со своего выхода. Например, есть фильтр, инвертирующий регистр символов и вырезающий из потока символы перевода строки: получил на входе "AbC\n", выдал на выход "aBc". К выходу этого фильтра подключены еще три фильтра, т.е. после того, как фильтр отработал, строку "aBc" он посылает поочередно на эти три фильтра, каждый из которых тоже может послать результат на следующие фильтры, те - на следующие и т.д. То есть поток входящих байтов так или иначе проходит по дереву фильтров, и в конце получается N "конечных" точек, где данные уже реально используются (например, выводятся в консоль). Логически все просто, но есть вопрос быстродействия: если каждый байт будет бродить по дереву, то для обработки следующего байта из порта придется ждать, пока все эти вложенные циклы передачи с выхода на вход (обход ветвей дерева) не закончится. С учетом того, что на самом деле поток обрабатывается не побайтово, а условными строками, т.е. блоками данных 1...X байт (где X в 64-битных системах практически не ограничено, пусть будет 0xFFFF), проблема имеет место быть. К тому же обработка данных внутри фильтра может быть не тривиальной, т.е. длительной. Напрашивается такой вариант: фильтр, получив данные, копирует их себе в буфер, после чего "возвращает управление" предыдущему фильтру, а обработку и "рассылку данных" далее по своим подветкам дерева делает уже в своём потоке, не мешая работе других фильтров. Но тут тоже предвижу проблему: это ж сколько памяти надо будет под все эти потоки и промежуточные буферы? Как это все синхронизировать потом, при выводе в "конечных точках"?! В общем, то ли я сам себе нагоняю мороза в труселя, то ли и вправду проблема есть, и её надо решать. Как вообще концептуально это следует делать? Пока думаю только в приложении к Windows, но теоретически есть задумка и на счет кроссплатформенности... Да, пока мне приходит в голову максимум 2 параллельных ветки из цепочки последовательных фильтров для практического применения, но, разумеется, предсказать реально, какие потребности могут возникнуть со временем, я не могу, и поэтому обдумываю именно универсальное решение с наихудшим сценарием сильноразветвленного дерева.