Перейти к содержанию
    

AnisimovSlava

Участник*
  • Постов

    41
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о AnisimovSlava

  • Звание
    Участник
    Участник
  • День рождения 20.05.1987

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. Да. Действительно упустил из виду. http://www.gifar.com.tw/Admin/ProductPDF/GFT035AB320240Y.pdf
  2. TFT + VCOM

    Привет всем. Есть TFT индикатор (3.5", 320*240). У него выход POL, и вход VCOM. Напряжение на VCOM-HI = 3.5V, VCOM-LO=-1.6V, VCOM-DC=0.97V. Ток потребления у VCOM не указан. Совершенно не понятно каим образом следует формировать сигнал VCOM. Подскажите какого порядка ток потребления на этом входе можно ожидать. Неужели придтся ставить еще один преобразователь для -1.6 при том, что один (слаботочный) на -10 уже есть?
  3. Добрый вечер всем. Я что-то не могу найти информации о максимальном потреблении LPC2478. Где-то, вроде бы встречал "мВт/Мгц", да вот сейчас найти не могу. Надо для того, что бы определиться с преобразователем в источнике питания. P.S. Стоило написать и сразу нашлось всё, что надо было: 125 ма максимальной частоте и со всей включённой периферией. Спасибо. Вопрос снимается.
  4. Может кому-либо будет интересно: сегодня, с чужой помощью, заработала следующая система: События сохраняются на SD карту памяти без всякой файловой системы вообще. Большой кольцевой буфер на всю карту памяти. USB устройство при подключении к виндовой машине требует своего драйвера. Дальше User Mode File System на базе Dokan обращается к устроству через DeviceIoControl и передаёт как команды управления, так и забирает данные (заголовки пакетов) из устройства. В результате каждая запись с SD карты представляется отдельным файлом (т.е. файлов столько, сколько событий, а не по числу потоков). Каждое событие можно прочитать как отдельный файл. Дата создания записи становится датой создания файла. Имя датчика, с которого приняты данные - становится именем файла (с добавлением нумерации). Всё получилось очень удобно и абсолютно так, как я хотел. Пришлось поставить WinXpDdk (требуется поддержка XP), WDK 7.1, WinDriver и Dokan. Ddk понадобился для собрки драйвера из WinDriver, WDK нужен для сборки Dokan. USB драйвер сделали с помощью "визарда" из WinDriver. Получилось быстро и просто. Заняло мероприятие минут 40-50 всего. Правда, потом добавляли команды управления и чтения данных. Это заняло практически целый день. Dokan заработал практически сразу. В результате рабочее решение получилось за 2-3 дня. Сейчас смотрю каким образом обойтись без WinDriver. Судя по всему, это не очень сложно. Мне дали IfsKit от MS. При инсталляции этого зверя появляется пример BulkUsb. Практически полная замена WinDriver для моего случая. Только добавляешь свои команды управления. P.S. драйвера типа "драйвер диска" или "драйвер устройства" действительно не достаточны. Докан действительно глюкав. Но его глюки не мешают исполнять ему главную задачу.
  5. Разрешите прерваться на сегодня. Меня взялись обучать User Mode File System-ам. С их помощью я смогу представить данные с карточки как миллион отдельных файлов, а не как один или 8 отдельных файлов. Обязусь отписАться по окончании.
  6. Такая ситуация объявлена в Т.З. Стало быть - возможна. Хранилище захлебнулось при использовании FAT. При тупой записи данных на карточку - нет. Цифры и Т.З. я опубликую как только получу. Я на должности совсем недавно и любые данные приходиться выпрашивать. Собственно меня попросили выяснить вопрос о подключении не FAT носителя к виндовой машине. Вопросы оптимизации будут обсуждаться если станет понятно, что не-FAT подключить не удасться. Именно это и имелось ввиду. Вы хоть намекните что имеете ввиду. Очень уж не хочется передавать весь образ. И, в идеале, хотелось бы каждую запись видеть как отдельный файл. Второе - по мере возможности. P.S. FAT реально не удобен. Данные дублируются в заголовках пакетов и в добавок надо будет думать о числе чтений-записей. Если, конечно, это не вариант resident-a с разбором образа на виндовой машине.
  7. Сразу аллоцировать 8 файлов размером на весь носитель и потом сразу писать в "середину" файлов? Но в этом случае для того, что бы отдать данные пользователю, надо будет вычитывать весь образ. В таком случае лучше сразу уж решение resident-а. Вообще забить на файловую систему и разбирать данные на виндовой машине. Было бы хорошо... P.S. Текущее вИдение таково - вычитывая данные из устройства выбрасывать те записи, которые не расшифровались. При этом расшифровка будет производиться на виндовой машине, а не в устройстве. В принципе, можно сказать, что это "решение resident-а".
  8. Понятно. Вы знаете - по мере обсуждения вИдение задачи и нужного решения несколько изменилось. Начиналось с одного, теперь - чуток другое. Соответственно и формулировки отличаются. Мне кажется, что это нормально. Но фиксированной длинны и фиксированного положения никак не получается. Получается либо запись в "хвост" файла либо в "середину" (в зависимости от того заполнен носитель или нет). Но я сейчас пробую разобраться с User Mode File System. Пока с трудом понимаю что там да к чему, но, похоже, что это решение проблемы. Смущают только цены. Там речь идёт о десятках тысяч долларов.
  9. Ну что Вы заладили "самоделка-самоделка"... Да - самоделка. Тем и кормимся. Я только не представляю себе как сделать автономное устройство, кототое может простоять год-два-три к примеру, а данные должно хранить за последние 2 недели. Вы знаете как обойтись без стирания старых записей? Я - нет. Это, насколько я понимаю, что-то типа варианта resident-а. только читать надо будет не весь образ, а лишь его часть? Уже изучается возможность. Это, наверное, интересно. Цены действительно впечатляют. Не совсем понятно нужны ли все компоненты или можно обойтись только одним? И Dokan, похоже, бесплатная штука? Этот срок отражает реальную сложность задачи или Ваше мнение о моих(наших) умениях? Если не сложно - объясните почему? Помимо того, что у карточки не хватает скорости, так у неё есть еще ограничение по циклам стирания-записи. И FAT в данном случае - самое тонкое место. Суть в том, что FAT в структура совершенно лишняя как таковая. P.S. Выяснить скорость передачи пока не удалось. Отпишусь чуть позже. Оказывается в абсолютных цифрах скорость потока никто не измерял. Измеряли задержки между цикламы записи пакетов при пиковой нагрузке.
  10. Сегодня уже некому задавать вопросы. Только завтра. Все нужные атрибуты есть и так. Ничего добавлять не надо. В том-то и суть. Проблема в том, что процесс чтения образа занимает офигенное время из-за того, что приоритет этой операции крайне низок. Но это решаемо. Другая проблема в том, что к пользователю поступают несанкционрированные данные. Пускай и в зашифрованном виде (ему допустимо расшифровывать только одни пакеты, а он видит все, какие только есть). Надо уточнять у заказчика допустимо ли это... Но, в целом, как я уже сказал, этот вариант принят к сведению. P.S. Поправка: чтение образа _может_ занять длительное время если поток данных в этот момент большой. В другом случае чтение себе как чтение.
  11. Вопрос не в "поезде", а в том, что мой статус таков, что вопросы подобного уровня от меня не ждут (надеюсь пока что). При сбоях данные складываются в циклический буфер в памяти. Успеет карточка разобраться - хорошо. Не успеет - часть данных будет утеряна. Это документированное поведение. Я уточню вопросы, если это принципиально. Сейчас не владею данными. Вопрос был принципиально другой. Так файлов-то не 8. Он либо один один на весь носитель (как предложил Resident), либо каждый пакет - файл (т.е. их миллион). Про кэширование думали. Это будет один из вариантов оптимизации FAT. Просто реализация другой файловой системы более эффективна в этом случае. С этого всё и началось. Данные на карте в одном виде, а надо их представить в другом. Да еще и выборочно... Сетка занята для коммуницирования с другим оборудованием (она - один из источников данных). Лезать туда со своими запрсами нельзя по Т.З. О втором контроллере речи (насколько я помню) не шло. Подключение к виндовой машине скорее исключение (для анализа сбоев), чем правило. А так - это тупое хранилище, которое живёт в труднодоступном месте где-либо. Данные циклически затираются после заполнения носителя. Объем современных карточек достаточен для Т.З. В общем, насколько я понимаю, плохи дела...
  12. 1) Пакет - данные фиксированного формата и размера. 2) Приемник пакетов - нечто такое, что может генерировать (принимать извне) последовательность пакетов. Последовательность не ограничена в длине. Т.е. может быть 10 пакетов и затем перерыв, а может быть 100 или 1000. Признака "окончания" передачи - нет. 3) Устройство - хранилище данных из 8 приемников на SD карточке. 4) Пользователь - некто, кому можно просматривать содержимое пакетов (не зависимо того, с какого приёмника они получены). Пароль пользователя даёт возможность проверить контрольную сумму пакета. Сошлась - можно показать данные. Нет - так нет. Устройство не хранит паролей вообще. Надо вводить с виндовой машины. 5) Устройство используется для хранения телеметрии. Т.з. на устройство чрезвычайно противоречиво. Т.е. изделие - компромис между многими требованиями. Изменение оборудования не входит в мою компетенцию. Т.е. я могу предложить что-либо, но не факт, что это будет принято. Даже, скорее, наоборот :unsure: Проблема: Когда все каналы начинают шарашить, данные только-только успевают записываться на карточку (но успевают). Производительности процессора хватает с большим запасом. Хранить данные негде (т.е. расширение RAM - полумера). Передача данных пользователю имеет несоизмеримо низший приоритет по сравнению с приёмом. Т.е. если устройство занято сохранением данных из источников, то запросы пользователя откладываются в долгий ящик. Предложения а-ля "уменьшить число каналов" не рассматриваются (они и так известны). Вроде бы все. P.S. Несколько раз уточнял текст.
  13. Совет, наверное, хорош. Вот только последовать ему сложно. Хорошо Вам как человеку опытному и всеми уважаемому. Ваше мнение сразу становиться законом. Я пока что до таких высот не дорос. Поэтому мне приходиться придумывать как сделать так как требует начальство. Или же объективно рассказать почему так сделать нельзя. Может быть как запасной вариант и прокатит... Хотелось бы что бы данные видились как отдельные файлы без (по возможности) выкачивания целого образа. Если это, конечно, вообще возможно.
  14. Добрый день всем. Есть (будет) некое устройство. В нем, соответственно, есть SD карточка. В силу некоторых причин формирования FAT на карточке хотелось бы избежать (не успеваем сохранять поток). При этом хочется, что бы с виндовой машины можно было управлять устройством (передавать команды "выбор потока", "чтение потока" плюс еще некоторые). Что и как сделать на устройстве вроде бы понятно... А вот на виндовой машине - нет. Собственно вопрос: Сложно ли сделать так, что бы с виндовой машины можно было: 1) Видеть выбранные потоки как "файлы". 2) Передавать команды выбора потоков, после чего список "файлов" должен будет измениться. При этом команда "выбор потока" может выполняться несколько минут. 3) С чем лучше бороться? Оптимизировать FAT или можно сделать дописку к виндам? P.S. Другие ОС типа Линукс не интересуют.
  15. Спасибо. Быстро, коротоко и по теме.
×
×
  • Создать...