Отправлено: 10.05.09 19:34. Заголовок: Разработка осциллографа.

Конструирование осциллографа не за горами (пока одноканального).
До его начала, есть время, достаточное для обдумывания общей стратегии.
На мой взгляд, от внешней схемы синхронизации нужно отказаться.
Она громоздка и "геморройна", а устройство должно быть дешёвым, малогабаритным, простым и экономичным.
Значит, речь идет о пакетной записи данных в оперативную память.
То есть, после нажатия/отжатия кнопки "Пуск" (или "Пакет", или еще как-то. А можно подумать и над автозапуском), происходит серия последовательных АЦП, производимых через калиброванные интервалы времени, значения которых можно задать (горизонтальная развертка).
Результаты АЦП быстро (режим HS+PLL. Такт 40 Мгц) записываются в оперативную память, из которой их потом можно "не спеша" вывести на индикацию в виде осциллограммы.
На мой взгляд, на первых порах, емкости области оперативной памяти PIC18F252 вполне достаточно для того чтобы сформировать вполне приличный пакет даже тогда, когда горизонтально прокручивается достаточно "длинная" (условно) осциллограмма (кнопки "Вправо"/"Влево").
То есть, от внешней оперативной памяти можно отказаться, что упрощает конструкцию устройства и удешевляет его (да и порты не резиновые).
Кроме осциллограммы сигнала, на дисплее графического модуля должна отображаться его частота (встроенный частотомер).
А раз это так, то весь диапазон частот можно разбить на части и перейти к автовыбору горизонтальной развертки ("железяка" сама выберет).
При этом, необходимость во внешнем управлении выбором величины развертки, отпадает (еще раз напоминаю, что порты не резиновые).
Многое зависит от модуля АЦП. Он уже "на подлёте".
Пока хватит. Это "затравка".
Задача обсуждения - неспешный, основательный и профессиональный выбор оптимальной стратегии, с упором на как можно более низкую стоимость устройства и на как можно более высокие его качественные показатели и возможности (компромисс).
Окончательное решение будет принято по итогам обсуждения.
Ну а далее, по ходу работы, сложность можно постепенно нарастить.
Каковы мнения/идеи/предложения?

 Отправлено: 13.05.09 23:32. Заголовок: Viktor_VK пишет: Мо..

Viktor_VK пишет:

цитата:

Может Вам Альберто и проработать этот вопрос? Не сочтите за указание, просто я в этом вопросе любитель (профессионал я в другом деле).

В отличии от меня Вам повезло, Вы хоть в чем-то профессионал.

 Отправлено: 13.05.09 23:51. Заголовок: Альберт, "рыбак..

Альберт, "рыбак рыбака чует издалека".
Над сказанным подумаю. Не спеша. Как и положено в нашем деле.
Просто сейчас основные силы направлены на обеспечение НАШИХ программаторами PicKit2.
Это очень важно.
На счет профессионалов.
Очень "скользкая" тема.
Лично я, профи считаю тех людей, которые мыслят нестандартно, хулигански, душевно и доказывают это на практике.

 Отправлено: 14.05.09 05:49. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

На счет профессионалов. Очень "скользкая" тема. Лично я, профи считаю тех людей, которые мыслят нестандартно, хулигански, душевно и доказывают это на практике.

В свое время в фотографии было четкое разделение.
Фотографом-профессионалом считался тот кто делает фотографии (не всегда хорошо) за зарплату .
А любителями - остальные фотографы, в том числе и те кто участвует на фото-конкурсах и выставках. Вот и судите сами, где уровень выше.

 Отправлено: 08.04.10 03:36. Заголовок: Мужики, я тут пом..

Мужики, я тут помыслил нестандартно/"неадекватно"/по-русски и внезапно додумался до, если так можно выразиться, статегической идеи.
Объясняю суть (это я про анализатор импульсных последовательностей).
Например, в 3-канальном режиме (взял наихудший вариант), сейчас, железяка способна отобразить всего 256 перепадов (в том канале, который имеет наибольшее количество перепадов).
Это маловато. А куда деваться, если опер. память не резиновая?
А что если работать "по кусочно-рваному принципу" (это из математики), ведь после "запуска в работу", "ломаемые железяки" начинают от одного и того же, и в большинстве случаев, повторяют одно и то же.
Можно сделать "ломалку", которая автоориентируется на наиболее высокочастотный канал (остальные "отсеиваются" по признаку наличия состояний 01h, то есть, предустановленных, лимитных маркеров).
При первой "добыче данных" (автопуск), "ломалка" считывает первые 256 уровней наиболее ВЧ сигнала (если речь идет о последовательных интерфейсах, то это линия такта), и в дальнейшем, ориентируется на этот канал.
Это Flash-запоминается (в ручную или авто).
Далее, "пытаемая железяка" не спеша приводится в исходное состояние, а затем осуществляется второй её пуск (от начала).
В этом случае (автопуск "ломалки"), считывание текущих данных автоначнется не от начала, а через 256 перепадов наиболее ВЧ канала (так как первый "кусок" ранее Flash-запомнен, он пропускается).
И т.д. В несколько "кусочно-рваных" приёмов (используется одна и та же область опер. памяти). На сколько Flash-памяти хватит.
Далее, эти "куски" авто(или ещё как-то)совмещаются и получается "комплексная портянка" приличной длины (в разы больше чем "мать").
Сие эквивалентно кратному увеличению "массы" оперативной памяти, хотя по факту, она не увеличивается, а просто многократно, последовательно используется. В этом случае, "центр тяжести", без ущерба для скорости, "кусочно-рвано смещается" во Flash-память программ (обмен одного на другое. Энергонезависимое запоминание - само собой).
С учетом её совсем не хилой "массы" (это я о ПИКах 18-й серии), может получиться "миниатюрная Memory-фантастика".
Как Вам такая задумка?
Реализовать ее трудно (это не звук "му"), но можно.
Если бред, то так и скажите. Не обижусь.
А если душевно и умственно одобрите, а тем паче подскажете/намекнёте на умные мысли, то серьёзно займусь.
Кстати, только что закончил работу по Flash-чтению-записи "эпюрных портянок" всех трёх "канальностей". Пока в "однократном виде". Соответствующая статья будет позднее.

 Отправлено: 08.04.10 11:24. Заголовок: Так и напрашивается ..

Так и напрашивается внешняя оперативная память. Ну и ладно, это другой случай.
Evgeny Korabelnikov пишет:

цитата:

Как Вам такая задумка?

По моему - замечательно. Во всяком случае, других вариантов не вижу... скоростных.
Разве что сделать, как дополнительный вариант, непрерывную запись низкочастотных сигналов (или сверхнизкочастотных :-) ?
Evgeny Korabelnikov пишет:

цитата:

При первой "добыче данных" (автопуск), "ломалка" считывает первые 256 уровней наиболее ВЧ сигнала (если речь идет о последовательных интерфейсах, то это линия такта), и в дальнейшем, ориентируется на этот канал.

Как вариант:
Надо "поймать" импульс неопределенной длительности (или пачку импульсов) - на первый канал.
Имеется тактовая частота, например от генератора - цепляем на второй канал.
Имеется сигнал синхронизации, пусть будет просто от кнопки пуска устройства, например одновибратора - сажаем на третий канал.

Автоподстройку частоты можно выполнить по второму каналу, от генератора.
Автопуск лучше сделать с третьего канала, по импульсу синхронизации. По переднему или заднему фронту, на выбор. т.е. по факту нажатия или отжатия кнопки.
А все остальное, запись данных - как Вы описали.

Мне вырисовывается такая картинка. Судить Вам.

 Отправлено: 08.04.10 16:36. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

Как Вам такая задумка?

Хорошая задумка.

Evgeny Korabelnikov пишет:

цитата:

(если речь идет о последовательных интерфейсах, то это линия такта), и в дальнейшем, ориентируется на этот канал.

Не понял.
А зачем мне такт нужен?
Мне бы данные посмотреть.
А то получится, что "ломалка" захватит такт а на данные внимания обращать не будет.

И ещё. Предположим, что на линиях всех каналов молчание.
Ждём прихода сигнала.
Вдруг откуда ни возьмись на одной из линий помеха. Так как на других линиях молчание, то помеха и будет самым высокочастотным сигналом.

Photographer пишет:

цитата:

Автопуск лучше сделать с третьего канала, по импульсу синхронизации. По переднему или заднему фронту, на выбор. т.е. по факту нажатия или отжатия кнопки.

А откуда узнать в какой момент кнопку нажать?

Думаю, что для "кусочно-рваного принципа" лучше использовать какой то один, специально назначенный для этого канал. Который нажатием кнопки может переводится или в обычный режим работы или в кусочно-рваный.

 Отправлено: 08.04.10 16:49. Заголовок: Так и напрашивается ..

Так и напрашивается внешняя оперативная память. Ну и ладно, это другой случай.

Правильно. Другой случай. По техзаданию, нужно обойтись только ресурсами 3-портового ПИКа.
Если "подпрягать" внешнюю, быстродействующую опер. память, то это "пахнет" высокоскоростным, параллельным интерфейсом, под который нужно выделить один порт, плюс несколько выводов другого порта.
Значит, как минимум нужно переходить на 4-портовый ПИК и использовать граф. модуль, работающий по I2C (уменьшение скорости обмена, между ПИКом и граф. модулем, в несколько раз). Если переход на I2C неприемлем, то нужно использовать нечто, имеющее бОльшее количество портов.

Разве что сделать, как дополнительный вариант, непрерывную запись низкочастотных сигналов.

Это уже есть (в приложении к "однократной" записи. То есть, к тому, что сделано на данный момент). Можно отображать сигналы с очень низкими частотами. Вплоть до нулевой (я это называю длинными уровнями).
Даром я что-ли "рогатился" с "лимитОй" ? Это легко можно "распространить" и на "многократную" запись.


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

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

 Отправлено: 08.04.10 17:21. Заголовок: Не понял. А зачем м..

Не понял.
А зачем мне такт нужен?
Мне бы данные посмотреть.
А то получится, что "ломалка" захватит такт а на данные внимания обращать не будет.

А как же он не нужен, ведь данные "фазово привязаны" к такту. Если речь идет, например, о I2C, то любой "чих" на линии данных, "фазово привязан" к тому, что происходит на линии такта.
Если такт не нужен, то к тактовому сигналу можно просто не подключаться.
"Ломалка" будет "обращать внимание" на все каналы (все они будут выводиться на индикацию). Просто наиболее ВЧ-сигнал ("опертаблица" полностью заполнена рабочими данными) будет использоваться в качестве "кусочно-рваного" критерия начала следующего автопуска, и не более того.


И ещё. Предположим, что на линиях всех каналов молчание.
Ждём прихода сигнала.
Вдруг откуда ни возьмись на одной из линий помеха. Так как на других линиях молчание, то помеха и будет самым высокочастотным сигналом.

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

А откуда узнать в какой момент кнопку нажать?

Речь идет не о подрежиме ручного пуска, а о варианте подрежима автопуска.

В моем вИдении, основная трудность заключается в чётком совмещении конца предыдущей "эпюрной портянки" с началом следующей. Первый "кадр" последующей "эпюрной портянки" должен быть продолжением последнего "кадра" предыдущей "эпюрной портянки". Без "наездов" и "разрывов".
Поэтому правильный выбор критерия автопуска (начиная от 2-го и далее) важен.
Всё остальное, как говорится, дело техники (трудно, но вполне реализуемо. Стратегия "состряпанного" позволяет).

 Отправлено: 08.04.10 18:31. Заголовок: igor пишет: Думаю, ..

igor пишет:

цитата:

Думаю, что для "кусочно-рваного принципа" лучше использовать какой то один, специально назначенный для этого канал.

Об этом я и пишу. Так, по порядку.
igor пишет:

цитата:

А откуда узнать в какой момент кнопку нажать?

В любой...
Упростил задачу до нЕльзя. Это всего лишь пример... например, надо поймать пакет на радиоприемнике автосигнализации:

На первом канале идут "чужие" пакеты и когда придет "свой" пакет - неизвестно.
На второй канал подаем сигнал с брелка. Этот сигнал нужен только для автопуска.

Далее, надо будет найти другой сигнал/событие для автопуска, уже на плате приемника. Под это дело можно использовать третий канал.

Так вот, это частный случай и возможно "не жизненный". Но в этом случае, автовыбор канала для автопуска не подойдет.
Надо оставить И ручной выбор канала для автопуска.
Одно другому не мешает, а только расширит возможности устройства.

 Отправлено: 08.04.10 18:49. Заголовок: Многообразие идей ..

Многообразие идей очень даже приемлемо, но не всё сразу. Сначала нужно отработать что-то одно (ориентация на взлом протоколов последовательных интерфейсов), а затем, после тщательного изучения (в автосигнализациях я пока не силён. Принято к сведению), предложенное (напоминаю про "принцип разгрома вражины по частям").
По здравому разумению, это упирается в "ветвление" меню (а иначе пункты замучаешься перебирать). То есть, в разделение меню на 2 специализированных подменю. Это вполне реально.
Предлагаю изначально сконцентрироваться на "маторгобеспечении" взломов протоколов последовательных интерфейсов, а далее жизнь покажет.
Какие будут замечания/предложения по поводу того, что выше я выделил синим цветом?
Есть другие, более эффективные критерии "автопускопривязок"?

 Отправлено: 08.04.10 18:59. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

Первый "кадр" последующей "эпюрной портянки" должен быть продолжением последнего "кадра" предыдущей "эпюрной портянки". Без "наездов" и "разрывов".

Стало быть, надо последние ( из запомненных 256) импульсы не только посчитать, но и сравнить с их близнецами принимаемыми и считаемые в данный момент. Если они полностью совпадают (например последние пять), то начинаем записывать следующую посылку. Если имеются отличия, то повторяем попытку с начальной точки.

 Отправлено: 08.04.10 19:25. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

В моем вИдении, основная трудность заключается в чётком совмещении конца предыдущей "эпюрной портянки" с началом следующей. Первый "кадр" последующей "эпюрной портянки" должен быть продолжением последнего "кадра" предыдущей "эпюрной портянки". Без "наездов" и "разрывов".

Можно было бы попробовать запись с наложением кусков и анализом совпадения накладки.
Но боюсь, даже это гарантирует цельность только в частном случае. В случае, когда "записываемый длинный пакет" стопроцентно повторяется в каждой сессии рваной записи.

Кроме прочего, совмешению кусков может помешать "плавание" частоты (?).

Есть еще идея.
Раз уж пакеты на всех трех каналах абсолютно идентичны во всех сессиях.
Может так и записать их целиком тремя одноканальными непрерывными сессиями?
Записать первый канал во всю оперативку и сбросить в память программ.
Потом так же второй и третий каналы.
Результат получим почти тот же, но проще.

Позже, для "успокоения совести", можно организовать трехканальную запись кусков для проверки записанного в памяти программ.

Чудовищно сложную работу Вы придумали

 Отправлено: 08.04.10 19:26. Заголовок: Игорь, спасибо. Оч..

Игорь, спасибо. Очень дельная мысль (верификация).
"Глаз на нее положен".

 Отправлено: 08.04.10 20:07. Заголовок: По "автопускопри..

По "автопускопривязкам" предложений больше нет.
Но есть еще один комплексный вариант, по кусочно-рваной записи.

Записать один из каналов во всю оперативку и сбросить в память программ.
Потом начать трехканальную запись кусками.
Эти трехканальные куски можно точно вписать в участки памяти программ, относительно записанного цельного канала.
Это гарантирует стопроцентную цельность хотя бы одного канала и стопроцентную привязку кусков к цельному каналу.

 Отправлено: 08.04.10 20:35. Заголовок: По поводу верификаци..

По поводу верификации. Мысль посетила. К чему бы это?
Мысль такая.
Последние один-два импульса, сравнивать не надо. Просто принять на веру, что и они тоже совпадут, если предыдущие 5-10 импульсов совпали.
Почему?
Думаю, что можно не успеть "подхватить" идущий за последним импульсом первой посылки, первый импульс следующей посылки. Всё таки верификация, тоже занимает какое то время.

 Отправлено: 08.04.10 20:52. Заголовок: Я до конца не понял ..

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

 Отправлено: 08.04.10 21:24. Заголовок: Можно было бы попроб..

Можно было бы попробовать запись с наложением кусков и анализом совпадения накладки.

Можно, но в тех случаях, когда речь идет не о "наладках", а о "разывах", это неэффективно.
И зачем их "порождать", если как следует подумавши, можно совместить идеально (условно. Возможна небольшая погрешность, которую, кстати, можно математически минимизировать), ведь речь идет о таблицах данных фиксированной "массы" (имеется ввиду количество ячеек памяти), да еще и с идентификаторами (01h) их "частичной пустоты".
Стратегия "состряпанного" такова, что это можно сделать.

Кроме прочего, совмешению кусков может помешать "плавание" частоты (?).

Ничего страшного. Введение, в процесс верификации, небольшого (обычно, сигналы "закварцованы") числового гисерезиса/допуска (его значение определяется экспериментально), и все дела.

Может так и записать их целиком тремя одноканальными непрерывными сессиями?
Записать первый канал во всю оперативку и сбросить в память программ.
Потом так же второй и третий каналы.
Результат получим почти тот же, но проще.

А зачем, если под все каналы выделена опер. память? Проще/выгоднее "оптово" записать данные всех трёх (или двух, если речь идет о 2-канальном режиме) каналов, а далее работать с этими "тройками" (или "двойками").

В случае, когда "записываемый длинный пакет" стопроцентно повторяется в каждой сессии рваной записи.

Это и имеет место быть в подавляющем большинстве случаев. А существенные расхождения (верификация. Выход за "границы" числового гистерезиса) можно обнаружить (а заодно и предупредить пользователя), причем, достаточно просто.

Чудовищно сложную работу Вы придумали

Ничего чудовищно сложного не вижу. Обычная, нормальная работа.
Сложно? Это да, не отрицаю, но ведь "не лаптем щи хлебаю". Авось, с Божьей и Вашей помощью, "завалю зверюгу". Лишь бы в наличии был стратегически наиболее эффективный критерий этого "завала" (без него, лучше даже и не начинать).
Поэтому Вас и беспокою.

На всякий случай формулирую смысл задумки.
Длинная (условно. Короче, гораздо длиннее "матери") "эпюрная картинка" (в приложении ко всем канальностям. А может быть и только к 2-х или 3-канальным режимам. Еще не решил) по-умному (в этом и сложность) "рвётся на материнские куски", и эти "куски", в порядке возрастания номера сессии (в каждой сессии, "ломаемое" работает от начала), энергонезависимо запоминаются во Flash-памяти программ.
После этого, в таком же порядке (или в том порядке, который "взбредёт в голову" пользователю), их можно извлечь, из Flash-памяти программ, и просмотреть, что, в комплексе, эквивалентно задействованию большего (по отношению к "матери") объёма опер. памяти (за счет многократного, повторного её использования, а заодно и Flash-памяти программ), без ухудшения скоростных качеств устройства.
Короче, в итоге, можно энергонезависимо запоминить "объём" инфы, кратно превышающий "материнский объём" ("кусочно-рваный" массив данных).
В принципе, если подсуетиться, то можно оформить его в виде "неразрывной эпюрной картинки", но это уже "макияж". Пока не до него. Сначала нужно решить принципиальные вопросы.

 Отправлено: 08.04.10 22:00. Заголовок: MAZ пишет: Почему д..

MAZ пишет:

цитата:

Почему два куска по 256, если они равны, один не надо "показывать".

Ну и как, разобрался?
А то, я не успел ответить, как все разложили по полочкам

 Отправлено: 08.04.10 22:34. Заголовок: Нет, не разобрался...

Нет, не разобрался.

 Отправлено: 08.04.10 23:03. Заголовок: В чем? MAZ пишет: П..

В чем?
MAZ пишет:

цитата:

Почему два куска по 256, если они равны, один не надо "показывать".

Этого по моему не говорили.

В кратце:
Подключаемся к трем каналам ломаемого устройства.
При появлении пачки импульсов, надо сигналы с этих каналов на максимальной скорости считать в оперативную память.
В оперативной памяти удобно разместятся только по 256 байт с каждого канала.
По окончании записи, эти 3х256 байт неспеша скидываем во флеш память программ.
И начинаем сначала.
При появлении пачки импульсов, пропускаем записанный кусок и начинаем запись в оперативную память второго куска.
Скидываем во флеш.
Потом считываем третий кусок и так далее, пока не кончится свободная область памяти программ.

Задача (вопрос) состояла в том, чтобы:
выбрать оптимальный канал для автоподстройки частоты считывания;
каждый раз начать считывание пачки импульсов с одного и того же места;
точно совместить конец первого куска и начало второго, а потом второй кусок с третьим и т.д.

Примерно так, если я правильно понял.

По моему в этом устройстве не хватает только миди плеера (под озвучку) для блезира.

 Отправлено: 08.04.10 23:50. Заголовок: Всё таки верификация..

Всё таки верификация, тоже занимает какое то время.

Это в общем виде ("на вскидку". Вполне возможны "рихтовки").
С учетом того, что верификация занимает какое-то время (это само собой разумеющееся), процесс "оперсчитывания" контрольных данных, которые требуются для нее, должен занимать только первую часть времени повторного (по отношению к предыдущему) считывания данных "ВЧ-матери" (она ранее запомнена во Flash-памяти программ).
В течение остального времени, должна быть отработана процедура чтения соответствующего "куска" Flash-памяти программ и произведено сравнение "матери" и "мамкиной дочери".
С учетом того, что процедура чтения Flash-памяти программ довольно-таки "резва", результат верификации вполне можно получить (а соответственно и среагировать на него) даже на самой высокой скорости работы устройства. До перехода на отработку следующего "куска эпюрной картинки".
На всякий случай, напоминаю о пока еще не задействованном 5-м банке. Правда в нём "лежат" RRы отладчика, но в случае чего, он выручит (резерв).
Для того чтобы не ухудшать скоростных качеств основных архиваторов, можно "сваять" и вспомогательные ("заточенные" под эту верификацию). PC позволяет.
Это я к тому (речь идет о сути. В детали не вдаюсь), что если как следует подумать, то вполне можно избавиться от "паразитной верифозадержки" (она может загубить всю затею).

Почему два куска по 256, если они равны, один не надо "показывать". Бывают случаи, что и повторяющиеся куски кода необходимы в данном интерфейсе, для синхронизации, например.
Если он не будет показан, то получится не объективная информация.
Если конечно я правильно понял.

"Железяке наплевать" на то, что будет во 2-м (и т.д.) "куске". Если это будет повторение предыдущего "куска", то оно и будет запомнено.
В идеале, должны показываться все "куски". Вне зависимости от их повторяемости. В порядке возрастания номера сессии.

PS: Альберт, Вы мыслите в правильном направлении.

 Отправлено: 09.04.10 05:21. Заголовок: Я не очень в курсе в..

Я не очень в курсе всей темы, но мелькнула мысль/вопрос. Используется ли CCP модуль для считывания логического сигнала ? CCP для анализа логических посылок - самая "скорострельная" штука в МК. При 40 МГц разрешение - наносекунды.

 Отправлено: 09.04.10 05:27. Заголовок: Используются прерыв..

Используются прерывания по входам INT. Это не хуже.

 Отправлено: 09.04.10 07:21. Заголовок: Теперь понял. :sm38:..

Photographer пишет:

цитата:

В оперативной памяти удобно разместятся только по 256 байт с каждого канала. По окончании записи, эти 3х256 байт неспеша скидываем во флеш память программ. И начинаем сначала. При появлении пачки импульсов, пропускаем записанный кусок и начинаем запись в оперативную память второго куска. Скидываем во флеш. Потом считываем третий кусок и так далее, пока не кончится свободная область памяти программ.

Теперь понял. Не понял почему "не спеша" складываем. Т.е. тут предусматривается, что пачка импульсов бегает по кругу циклично? А если она никогда не повторится? И пока не спеша складывали, пропустили целую часть. И первая часть никогда не повторится. Что тогда будет? Как продолжать?

 Отправлено: 09.04.10 11:26. Заголовок: MAZ пишет: Не понял..

MAZ пишет:

цитата:

Не понял почему "не спеша" складываем.

Потому что запись во флеш память в тысячи раз тормознее чем в оперативнуб память.MAZ пишет:

цитата:

Т.е. тут предусматривается, что пачка импульсов бегает по кругу циклично?

Нет, это никому не надо. Во всяком случае такое редко бывает.
Имеется ввиду или ручной перезапуск ломаемого устройства, или придется как то инициализировать многократные попытки передачи одних и тех же данных по "пытаемому" протоколу/каналу. А куда деваться?
Оперативка не бесконечная. В каждой сессии получишь несколько кадров ломаемого кода. Если разберешься с ними - в новой сессии получишь еще несколько кадров.
Как это удастся реализовать на практике - посмотрим.MAZ пишет:

цитата:

И первая часть никогда не повторится. Что тогда будет? Как продолжать?

Тогда капут!

 Отправлено: 09.04.10 11:45. Заголовок: Тема осциллографа, д..

Тема осциллографа, думаю, волнует многих, и меня в том числе, но я пока не готов давать дельные советы. Тем не менее, выскажу свое мнение, или, если хотите пожелание. Мне кажется, что продумывать и отрабатывать нужно ДВЕ конструкции осциллографа: малогабаритный и "стационарный" (условно) осциллографы. Помоему, подобная мысль была и у КЕА. Кроме того, Evgeny Korabelnikov пишет:

цитата:

Задача обсуждения - неспешный, основательный и профессиональный выбор оптимальной стратегии, с упором на как можно более низкую стоимость устройства и на как можно более высокие его качественные показатели и возможности (компромисс).

Не знаю, как на счет компромисса, но удешевление первой (малогабаритной) конструкции возможно, если создавать его на базе старого (или не очень) мобильного телефона, используя его корпус, батарею и ИНДИКАТОР. Затем схемотехнические и программные наработки использовать во второй ("стационарной") конструкции с более широкими возможностями. Мне так кажется.

 Отправлено: 09.04.10 13:55. Заголовок: Bigor пишет: создав..

Bigor пишет:

цитата:

создавать его на базе старого (или не очень) мобильного телефона

Честно признаюсь, я бы такой и собирать не начал. Только -за размеров индикатора

 Отправлено: 09.04.10 15:56. Заголовок: Вот так можно. Тольк..

Вот так можно. Только научится индикатором управлять, копаем.


Photographer пишет:

цитата:

Имеется ввиду или ручной перезапуск ломаемого устройства, или придется как то инициализировать многократные попытки передачи одних и тех же данных по "пытаемому" протоколу/каналу. А куда деваться?

Что-то болезнь напоминает, на букву г.
Photographer пишет:

цитата:

Потому что запись во флеш память в тысячи раз тормознее чем в оперативнуб память

Это я еще помню. Я про "капут"

 Отправлено: 09.04.10 16:55. Заголовок: wws63 пишет: Честно..

wws63 пишет:

цитата:

Честно признаюсь, я бы такой и собирать не начал. Только из-за размеров индикатора

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

 Отправлено: 09.04.10 17:08. Заголовок: Описываю цепочку р..

Описываю цепочку рассуждений.
На данный момент, во всех "канальностях", имеется Flash-чтение/запись (работаю над соответствующей статьей. Когда закончу, разошлю) пока по одному запоминанию данных каждой канальности (можно с автопуском или с ручным пуском. На выбор).
Этого мало.
Возникает закономерный вывод: "Если, в каждой из канальностей, можно запомнить одну картинку, то можно запомнить и большее их количество".
По этой простой и незамысловатой причине, в дальнейшем, "масса" Flash-запоминаемого будет увеличена. Например (цифра взята от балды), в каждой канальности, можно будет, на усмотрение пользователя, сохранить данные до 3-х "несостыкованных" между собой замеров, а проще говоря, 3-х "материнских кусков", "вырванных" из длинного (условно) "набора" сигналов.
Они могут быть "вырваны" и из разных "наборов" сигналов. Или ещё как-то. Это как пользователь решит.
На мой взгляд, польза, от такого "блокнота" (или "записной книжки"), очевидна, и поэтому сие будет сделано (с конкретными объемами памяти определюсь по ходу дела).
А если эта "база" будет создана, то почему бы с ней и не поэкспериментировать?
Печень от этого не отвалится. Попытка не пытка.
В смысле "автофазостыковок сессийных кусков".
При этом, безошибочный результат верификации данных предыдущей сессии (ломаемая железяка работает от начала) разрешает отработку последущей сессии (значит, "куски состыковываются"), а если он ошибочен, то возникает предупреждалка типа "Куски одного и того же различны. Продолжать или нет? Или можно попробовать еще раз" (плюс, предлагается набор вариантов действий).
В принципе, можно заверифицировать данные всех каналов или на выбор (ручной), или авто, или по умолчанию. Это трудно, но можно.
Все это пока сыро (Москва не сразу строилась) и планы Наполеоновские, но в случае успеха, открываются захватывающие Memory-перспективы.
И в самом деле, имеется возможность, без использования внешней опер. памяти, заполучить такой результат, который, если мыслить стандартно, возможен только в случае ее использования.
Кстати, по скорости, работа с опер. памятью ПИКа ничем не хуже, и даже лучше (особенно в приложении к двоичной разрядности большей чем 8, что в большинстве случаев и требуется) работы в внешней опер. памятью. Единственный недостаток первого - малый ее объем.
Против этого и "воюю". Легких путей не ищу.
Спасибо за информацию к размышлению. Учту.
Если еще что-то подскажете, то тоже учту. В хозяйстве все пригодится.
Команда "фас" дана и "охота на кролика" началась. Теперь пахать нужно.
В результате этой работы, по-любому, "на гора будет выдано" то, с избытком скомпенсирует даже неудачу.

 Отправлено: 09.04.10 17:24. Заголовок: Для стационарного ва..

Для стационарного варианта оптимальным было бы задействование в качестве индикатора экрана компьютера, при реализации связи по USB например. Для этого достаточно RX/TX выводов и переходника USB/COM. В таком случае ЖК вообще не нужен, но "тяжесть программирования" ляжет на компьютерную программу. Эта мысль уже озвучивалась раньше, может со временем окажется востребованной.

 Отправлено: 09.04.10 18:36. Заголовок: Вполне может оказа..

Вполне может оказаться.
Что касается меня, то я "заточен" на полностью автономные, малогабаритные, малоэнергозатратные устройства (без внешних "помогалок" типа компьютера), которые можно запитать от батареек и положить в карман.
У других людей может быть другая специфика, и это хорошо, так как в комплексе, получается очень солидно.
Это огромный плюс коллективной работы.

 Отправлено: 09.04.10 22:18. Заголовок: Петр, мне тут в ..

Петр, мне тут в голову очередная мысль "долбанула".
Суть.
После записи, в ПИК-Flash-память программ, "эпюрных портянок", эти данные (память программ можно считать в программаторе) оформляются в виде файла.
Под это дело, создается спецпрограмма (в Виндах), в которой этот файл и открывается, в виде эпюр, которые можно прокрутить туда-сюда.
Экран монитора это не дисплей граф. модуля. Он больше и удобнее. И у компа возможностей больше.
В этом случае, основную "взлом-работу" комфортнее производить "в компе", а граф. модуль использовать либо для контроля, либо в "полевых условиях".
Если это возможно, то есть над чем подумать. На мой взгляд, в приложении к конструируемой железяке, это очень перспективно.
С алгоритмом этого "сооружения" проблем не будет. Предоставлю.
Петр, как Вы на это смотрите (это на будущее, так как еще не все адресные привязки "нарисовались". Времени для "обмозговывания" сути полно)?
Лично к Вам обращаюсь потому, что Ваши программы качественны и прекрасно зарекомендовали себя в работе.
Если нет, то никаких обид. Вы и так многое сделали. Буду искать другой вариант.
Я бы и сам попробовал, но в этом деле я не соображаю (специализация не та).
Поэтому и обращаюсь к профи.

 Отправлено: 09.04.10 23:17. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

После записи, в ПИК-Flash-память программ, "эпюрных портянок", эти данные (память программ можно считать в программаторе) оформляются в виде файла.

Думаю, что эти данные удобней перегонять в ПК по какой-либо шине (I2C, CAN и т.п.), а не считывать программатором, ну, а затем создавать файл, и как пишет Евгений Александрович:

цитата:

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

 Отправлено: 09.04.10 23:52. Заголовок: Можно попрбовать. Ду..

Можно попрбовать.
Думаю что не возникнет больших сложностей в чтении данных из файла и построенни графика на их основе.

 Отправлено: 10.04.10 00:11. Заголовок: Думаю, что эти данны..

Думаю, что эти данные удобней перегонять в ПК по какой-либо шине (I2C, CAN и т.п.), а не считывать программатором, ну, а затем создавать файл.

Игорь, в данном случае, все выводы 3-портового ПИКа задействованы под более жизненные задачи, и возможности работы по I2C (и т.п.) нет. Поэтому, с учетом возможности подключения PicKit2, и предложено то, что предложено (ориентировка на PicKit2 Programmer).
Кстати, получается вполне комфортно, дешево и сердито. И без I2C, CAN и т.п.

Петр, спасибо. Графика - простейшая. "Перпендикулярная". Если будут вопросы о деталях, то пишите мне.

 Отправлено: 10.04.10 13:04. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

После записи, в ПИК-Flash-память программ, "эпюрных портянок", эти данные (память программ можно считать в программаторе) оформляются в виде файла.

А как быть с защитой прошивки? Ведь вместе с данными прочитается и вся прошивка. На сколько я знаю, нет возможности поставить защиту на часть памяти программ.

Так или иначе, два вывода контроллера выделены под PicKit2 и их можно считать выделенными для связи с компьютером.
Так что можно искать обходные пути. Например:
1) как предложил Bigor сделать переходник под какой то протокол;
2) поискать возможность через PicKit2 организовать передачу данных;
3) симулировать микроконтроллером микросхему памяти так чтобы PicKit2 видел вместо PIC18F252 какую нибудь 24C64 (общаться с ней вроде бы научились достаточно хорошо).
Возможно есть варианты и по лучше.

 Отправлено: 10.04.10 13:18. Заголовок: Photographer пишет: ..

Photographer пишет:

цитата:

2) поискать возможность через PicKit2 организовать передачу данных;

Впринципе, если хорошо подумать то это можно реализовать, т. е. получать данные непосредственно через PicKit2 без записи в файл.
Как связатся с PicKit2 и посылать/принимать данные я знаю.
Осталось выяснить какие команды нужно использовать для чтения произвольных участков памяти программ.

 Отправлено: 10.04.10 13:22. Заголовок: Думаю в готовом устр..

Думаю в готовом устройстве можно предусмотреть панельку под установку памяти. Нажимаем кнопку, и ПИК сливает в память принятые данные.
Лучше бы конечно передавать данные на компьютер по какому либо протоколу.
USART уже изучен довольно таки глубоко.

 Отправлено: 10.04.10 15:09. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

Суть. После записи, в ПИК-Flash-память программ, "эпюрных портянок", эти данные (память программ можно считать в программаторе) оформляются в виде файла. Под это дело, создается спецпрограмма (в Виндах), в которой этот файл и открывается, в виде эпюр, которые можно прокрутить туда-сюда. Экран монитора это не дисплей граф. модуля. Он больше и удобнее. И у компа возможностей больше.

Сергей Рослик в обмене рекомендовал программу PowerGraph2.1
Программа позволяет считывать через звуковую карту любую импульсную последовательность.
Запись идет в файл. На экране мы видим эту последовательность во всей красе. Ее можно измерять как угодно,
редактировать как угодно и т.д.
Я тут пробовал с ней работать.(описание на русском).
Приемник собирается из фотодиода(от телевизора) +пара резисторов.
Описание этого устройства есть в обмене.
Загонял в PowerGraph2.1 пульты ДУ,
благо их у меня много. Осцилограмма, как на ладони.
И если один выход ПИКа сориентировать на выход через ИК-диод, то можно перегнать в комп.
любые данные(такт не нужен).
`