Jump to content

    

ARV

Свой
  • Content Count

    1163
  • Joined

Community Reputation

0 Обычный

About ARV

  • Rank
    Профессионал
  • Birthday 03/30/1968

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3745 profile views
  1. Раньше было так: исполняемый код DLL грузился в память 1 раз при первом обращении к системной функции загрузки DLL, а затем при каждом следующем вызове этой функции просто увеличивался счетчик загрузок, а код оставался в одном экземпляре. А область данных для нужд DLL выделялась в области вызывающего приложения, т.е. для каждой загрузки DLL получала память основного приложения. Разные приложения могли загружать одну и ту же DLL, и при этом код DLL был для них в одном экземпляре, а данные DLL - разные. Поэтому какая-то экспортируемая функция DLL могла вернуть указатель на данные, и основная программа могла с данными по этому указателю работать, как будто это её собственные данные. Сейчас и код, и данные при каждой "загрузке" DLL изолируются от памяти основного приложения, и никакие указатели без особых ухищрений передать из DLL в основной код нельзя. Так понятно объяснил?
  2. Затем, что современные виндовсы совсем не те, что были раньше. Раньше подобный вопрос и не возникал бы вообще. А сейчас... Вот недавно я выяснил, что современные версии винды (семерка и новее) для DLL выделяют свою память данных (раньше данные выделялись в сегменте данных главного приложения), поэтому просто так взять, и передать указатель на данные DLL нельзя, надо с бубном плясать... Поэтому и спрашиваю у профессионалов или хотя бы просто знающих программистов, как решать подобные моей задачи. Если я не очень детально описал свои вопросы - так задайте мне наводящие, чтобы я понял, что надо пояснять.
  3. Ну... Я, как бы, вижу все иначе... Поскольку получение новых данных буфферизируется на уровне драйвера, а потом еще и у меня в программе, вероятность потери данных минимальна, сколько бы долгой обработка ни была... Ну, а если их придет больше, чем вмещает буфер в драйвере, данные потеряются, как и любые другие в любой другой периферии. Я стремлюсь сделать минимальной задержку, грубо говоря, между тем, как мигнул светодиод "данные приняты" до момента, когда эти данные будут визуализированы (текст, график, анимация, звук или еще что-то подобное).
  4. Это ведь будет сильно зависеть от того, на каком компьютере будет запущено, с какой скоростью порт будет принимать данные и т.п. непредсказуемых вариантов использования. Задачу я понимаю так: сделать самым оптимальным способом, чтобы во всех случаях работало (ну или хотя бы приблизиться к идеалу). Я описал проблему так, как я сам её понимаю. Я оперирую функциями: функция получила на входе данные (из порта), что-то сделала с ними и вызывает аналогичную функцию следующего "фильтра", передавая ей данные. Получается, именно следующему пихаются данные, а не следующий тянет их. Т.е. у меня поток данных течет по обработчикам, а не обработчики, высасывающие откуда-то данные. Возможно я не прав, но я не профессионал, и мне простительно
  5. FIFO уже на уровне драйвера порта сделано: оттуда уже приходит от 1 до 0xFFFF байтов. Считаете, проблема "медленной обработки" за счет постоянного копирования туда-сюда данных, надумана?
  6. Заголовок темы краткий, поясняю смысл вопроса на примере последовательного порта. Из порта поступают байты, которые надо обработать. Для обработки используются т.н. фильтры - модули, получающие на вход поток байтов и содержащие список следующих фильтров, куда направляют поток данных со своего выхода. Например, есть фильтр, инвертирующий регистр символов и вырезающий из потока символы перевода строки: получил на входе "AbC\n", выдал на выход "aBc". К выходу этого фильтра подключены еще три фильтра, т.е. после того, как фильтр отработал, строку "aBc" он посылает поочередно на эти три фильтра, каждый из которых тоже может послать результат на следующие фильтры, те - на следующие и т.д. То есть поток входящих байтов так или иначе проходит по дереву фильтров, и в конце получается N "конечных" точек, где данные уже реально используются (например, выводятся в консоль). Логически все просто, но есть вопрос быстродействия: если каждый байт будет бродить по дереву, то для обработки следующего байта из порта придется ждать, пока все эти вложенные циклы передачи с выхода на вход (обход ветвей дерева) не закончится. С учетом того, что на самом деле поток обрабатывается не побайтово, а условными строками, т.е. блоками данных 1...X байт (где X в 64-битных системах практически не ограничено, пусть будет 0xFFFF), проблема имеет место быть. К тому же обработка данных внутри фильтра может быть не тривиальной, т.е. длительной. Напрашивается такой вариант: фильтр, получив данные, копирует их себе в буфер, после чего "возвращает управление" предыдущему фильтру, а обработку и "рассылку данных" далее по своим подветкам дерева делает уже в своём потоке, не мешая работе других фильтров. Но тут тоже предвижу проблему: это ж сколько памяти надо будет под все эти потоки и промежуточные буферы? Как это все синхронизировать потом, при выводе в "конечных точках"?! В общем, то ли я сам себе нагоняю мороза в труселя, то ли и вправду проблема есть, и её надо решать. Как вообще концептуально это следует делать? Пока думаю только в приложении к Windows, но теоретически есть задумка и на счет кроссплатформенности... Да, пока мне приходит в голову максимум 2 параллельных ветки из цепочки последовательных фильтров для практического применения, но, разумеется, предсказать реально, какие потребности могут возникнуть со временем, я не могу, и поэтому обдумываю именно универсальное решение с наихудшим сценарием сильноразветвленного дерева.
  7. stm32f LCD I2C menu

    Не всегда
  8. В протеусе даже возможно связать через USART МК с программой в винде и отлаживать сразу обе :)
  9. Планируется, что один раз и забыл. Но, вероятно, как у любой домашней самодельной автоматики, процесс усовершенствования затянется на неопределенный срок... т.е. определенное количество циклов вспомнил-отсоединил-присоединил-забыл все-таки будет...
  10. Такое, да вот только бы с шагом 2,54 мм... иначе все равно получается громоздко... мне для себя, для поделки...
  11. Я не настаиваю на винтах, просто ничего альтернативного на ум не приходит... У китайцев есть однорядные с шагом 2,54 мм зажимные - вот бы в 3 ряда такие... Особенно удачны те, что в центре фото 8pin - с боковым подключением проводов...
  12. Это что такое? Спасибо! Ищу, где именно такое теперь купить...
  13. Посоветуйте клеммничек или направьте в поисках... Хочу сделать некое устройство с большим количеством внешних подключений. То есть предполагаю к нему подклчать большое количество всяких проводных линий. Токи и напряжения на этих линиях мизерные - не более 20 вольт и ток до 100 мА, т.е. сечение проводов будет маленькое. Большинство линий двухпроводные, но и немалая часть трехпроводная, всего линий планируется порядка 40-45, и.е. общее количество контактныйх соединений можете себе представить - далеко за сотню. Хочется, чтобы все устройство было максимально компактным... Поэтому ищу клеммничек (винтовой или [быстро]зажимной), предназначенный для впаивания в плату, чтобы контакты были в три горизонтальных ряда... Ну примерно так как-то... Такое вообще бывает? Еще б и не дорого...
  14. Кстати, если кого-то вдруг интересует мой вопрос о том, надо ли ждать "промпта" при вводе СМС... Так вот, в документации на команду AT+CMGS модуля SIM800L написано: То есть текст сообщения следует сразу за <CR> без какого-либо упоминания промпта.
  15. Спасибо, это значительно облегчает мои муки.