Ruslan1

У меня очень хорошо прижился C++ Builder. Так как на микроконтроллерах разработка тоже идет на Си, то без проблем переношу туда-сюда некоторые функции и структуры данных, которые должны быть одинаковыми с двух сторон (например, контрольные суммы, структуры передаваемых пакетов....). Очень удобно. Иногда даже получалось общий путь расположения некоторых *.h-файлов указывать для реализации в контроллере и поддержки в PC. То есть хедер вообще один для обоих. Причем плюсатыми возможностями и не пользуюсь (имеется в виду свой код, а не сгенеренный билдером), так как в емеддедах с++ все-таки перебор. Хватает и обыного ANSI. А в общем случае уверен, что хорош любой известный программисту язык программирования :)

Вот возник пока чисто теоретический вопрос, куда можно навострить лыжи, чтобы съездить на курсы. Срок - до месяца. Тематика- интересует очень широкий спектр вопросов, касающихся разработки Embedded-устройств. От элементной базы до программирования и разработки печатных плат. В-общем, интересует почти все, что обсуждается в разделах форумов электроникса. География- не ограниченно. От Диксона до Сиднея, но предпочтительней наверное США. Интересно конечно совместить приятное с полезным. Язык - русский или английский. С информативной точки зрения лучше конечно завалиться в Москву/Питер/итд и несколько различных курсов на родном языке послушать. Но иначе чем в родной среде английский и не подтянешь. Да и вдруг дело выгорит, в Москву я и на свои как-нибудь проехать смогу, а вот в Калифорнию- дудки. :) Уровень- а черт его знает. В каких-то вопросах наверное и сам могу лекции читать, а в каких-то плаваю. Это уже смотреть нужно конкретную тематику. Время проведения- первая половина наступившего года. Может быть чуть позже, но точно этот год. Где в инете такое копать? Может быть, кто-нибудь может порекомендовать лично им прослушанный курс?

Я уж подумал, что это кто-то по дороге рубит ( у меня оно аж через всякие германии идет) ОК, спасибо. Я на всякий случай письмишко им черкнул. Сейчас заглянул на их сайт- уже исправили! :-)

У меня при доступе к http://www.megratec.ru/ возникает ошибка вида: [an error occurred while processing this directive] И так к практически всем разделам сайта. Скажем, http://www.megratec.ru/news/ вообще состоит из трех сообщений об ошибке. Это только у меня такое? Пробовал с двух разных машин (трейсы до России вообще разные), и из разных операционнок- все повторяется. Жалко. :(

Смотрю на датчики, скажем от ST, и грустно мне от их термоухода. Разрешение у датчика хорошее, шума мало, но вот термоуход все перечеркивает. Попробовал экспериментально определить, можно ли его в общем случае скомпенсировать/поправку ввести, но оказалось, что он не только зависит от положения датчика относительно вектора g, но и может иметь разный знак для разных экземпляров. Однако! :( Интересно, ни у кого нет опыта борьбы за исключение влияния температуры на измерения? Пока что только приходит в голову сигнализировать о необходимости проведения перекалибровки при отличии текущей температуры от температуры, при которой происходила калибровка. Прибор батарейный, термостат ставить не могу. Разве что придумать термос какой-нибудь, куда датчик сувать, чтобы уменьшить болтанку?

Ключевым во всем этом является то, что оно тебе подходит. Все зависит от предъявляемых требований. Просто убедись наверняка, что оно тебе ДЕЙСТВИТЕЛЬНО подходит.

Дык это и так присутствует всегда и везде, природа позаботилась. Наша задача- свести эти смещения-уходы-старения к допустимому минимуму, вводя свои "антисмещения и "антиусиления". :) Имелось ввиду что подстраиваемые параметры : размах входного диапазона и его начало. Например: 0...10 в, 1...5 в, 0... 1.5 в и т.д. Да я понял. Это так, шутка была.

Дык это и так присутствует всегда и везде, природа позаботилась. Наша задача- свести эти смещения-уходы-старения к допустимому минимуму, вводя свои "антисмещения и "антиусиления". :) PS. Я бы тоже у Деда Мороза такой универсальный вход попросил. Только ведь или зажмет, или такой стишок попросит рассказать, что до пенсии не выучить.... :)

Какая-то странная у Вас хотелка. Это что, для демонстрации студентам? Больше такое, по-моему, ни на что не сгодится :) Это в первую очередь касается двухпроводного подключения RTD. Внимательно посчитайте. Дело в том, что характеристика датчиков, во-первых, нелинейна, во-вторых, в указанном диапазоне температур Вы имеете не от 0 до Umax, а от U1 до U2, что заведомо меньше, чем диапазон АЦП. Кстати, скорость опроса датчиков какая? Универсальный вход ВСЕГДА будет дороже и сложнее, чем специализированный. В запущенных случаях он будет хуже специализированного по параметрам. Универсальный вход хорош для производителя (не нужно номенклатуру раздувать) и плох для конечного потребителя, у которого гирлянды известных датчиков как повесили 20 лет назад, так и не будут ни на что менять еще долго. Например, мы для такого случая имеем плату, поддерживающую сколько-то входов измерения напряжения 0-30мВ (для термопар) плюс еще сколько-то входов измерения сопротивления 10-250 Ом (для RTD) с 3- и 4-х проводным включением. То есть обеспечивается универсальность (любой RTD или любая термопара), но не такая как вам нужно. Ну а перевод миливольт и ом в градусы происходит уже в системе сбора. Следующая ступень универсальности - это контроллеры, работающие с нормированным сигналом (-5...+5 Вольт). Таких входов как правило на производстве очень много нужно. Кстати, если речь идет о универсальности, рекомендую подумать о гальванической развязке хотя бы для термопар. Видел варианты, когда сигнал от одной термопары используется в нескольких независимых системах обработки, в таких случаях гальваноразвязка очччень пользительна.

Ну что ж, таковы значит местные условия, хотя и интересно, как так может получится (дырку можно, а кусок трубы заменить нельзя). Но к сути разговора это не относится. В корректорах ничего сложного нет, кроме однажды разработанных формул. Если интересно- у меня где-то даже лежит документация с перечнем покупных библиотек, примененных в одном таком корректоре. Никаких ноу-хау в этой области и не придумаешь, формулы вообще-то чуть ли не в ГОСТе прописаны. Есть корректоры, где все расчеты происходят вообще таблично. А деньги берутся потому, что это промышленность, тут деньги никто не считает. Особенно газовая- мне рассказывали, что даже в наших краях в советское время на шашлыки вертолетом летали, я уж не говорю про Тюмень всякую. :) Насчет с нагревом- видел такой экспериментальный датчик: термометр1-нагреватель-термометр2. Расход есть функция от температур и количества тепла, сообщенного нагревателем газу. Насколько такие вещи реально работают и применяются в промизмерениях расхода газа- не знаю, но зависимость там точно была, в крайнем случае наверное можно переводить таблично.

Ну хоть убей, не могу себе представить ситуацию, когда трубу МОЖНО сверлить, но одновременно НЕЛЬЗЯ вставить в нее вертушку или калиброванное сужающее устройство. :) Минимально приходящее в голову- это есть: 1. труба известного диаметра (назовем ее сужающим устройством, СУ) 2. Ввернут датчик температуры газа 3. Ввернуты датчики давления до и после СУ. Далее путем математических вычислений (зная еще кучку параметров о самом веществе) можно вычислить скорость потока и расход газа. Именно таким образом сделан (был сделан?- я последний раз с этим сталкивался лет семь назад)) расчет газа на границах республик СНГ: установленные корректоры вычисляют объем, пользуясь вышеприведенными измеренными характеристиками. При изменении расхода как правило происходит переход на СУ другого диаметра. Реально- просто закрывают одну из параллельностоящих ниток учета и открывают другую, где стоит свой корректор, уже настроенный на это СУ. Точность- абсолютно достаточная. Но и аппаратура недешевая (комплект 10 лет назад стоил порядка 10к$).

Не совсем понятно, что такое "не имея контакт непосредственно с веществом". Не имея контакт чего? Если вы можете измерять давление и температуру, значит все-таки врезаетесь в трубу. Укажите: 1. Диаметр трубы 2. Минимальный и максимальный расход. 3. Мин/Макс давление 3. Точность измерения. 4. Условия эксплуатации. 5. Бюджет? Если речь идет о том, чтобы не трогать трубу вообще- то, по-моему, никак. :) А если о том, как обойтись без движущихся частей (турбинок) в трубе- так можете посмотреть, как это делается с применением сужающих устройств, скажем в корректорах Суперфло. Но точность таких конструкций падает с уменьшением расхода, при низких расходах турбинка все-таки лучше. Везде свои плюсы и минусы. Зависит-зависит. На этом перепаде экономика России держится. :)

Ну, во-первых, хочется широкоформатности, чтобы разные окошки открывать правее-левее от основного. Во-вторых, уж очень это много по деньгам, не дадут. :)

Ну, ничего сложного там нет, нужно только немного внимательности и полдня работы. (правда, это я не про сам PQFP, а про рисование УГО в приятном мне виде и создание элемента). А собственно PQFP- пожалуйста. Это для P-CAD2001. pqfp208.rar

Разобрался. Нужно после включения дать ему RESET (чихнуть в DIN пачкой не менее 32 лог"1"). Дальше все работает согласно документации. PS. Спать все-таки надо побольше, а работать-поменьше. :)

Всем доброго времени суток! Вроде все как в даташите делаю, но не читаются регистры и все. Уже и SPI аппаратное отключил, вручную диаграмму выпиливаю- не выходит каменный цветок :( При включении, если CS уронить, то RDY успешно болтается согласно дефолтовым установкам (16 SPS), то есть сам АЦП работает. А больше ничего добится не могу. Странно как-то. Там есть какие-то хитрости? Пользую при питании AVdd=Dvdd=5V. Кроме питаний и шины CS/DIN/DOUT/SCLK остальные ноги висят ни к чему неподключенные. Может быть, кто-то поделится исходным текстом программы, предназначенной для этих АЦП. Буду очень благода.

Это который 1600x1200? А не мелковато изображение получается? И как его матрица вам? Там вроде TN? А по цене- у нас стОит как и Вьюсоник на MVA. Я тоже смотрел на него, думал.... В обзорах хвалят. Про ощущения поподробнее, пожалуйста. :)

Я проходил AT91RM9200+S1D13A04, особых подводных камней не было, кроме расставленных мною же :). По собственному опыту: 1. Попробуйте уменьшить тактовую частоту шины и увеличить количество циклов ожидания - вдруг где-то шина не позволяет. 2. Убедитесь, что правильно подключились. У меня, например, раздельно управлялись WE0 и WE1, пока не соединил вместе- не работало нормально. 3. Аналогично для софта. Выпиливаемые процессором диаграммы должны совпадать с требуемыми для S1D в выбранной схеме подключения. 4. Если есть косвенные пути проверки факта записи в камень и правильности чтения- попробуйте ими воспользоваться. Например, чтение известного значения, или управление чем-то, что можно проследить осциллографом (изменение частоты на выходе S1D и т.п.). Если у вас действительно читается слово конфигурации, то ответ где-то рядом. 5. Чтение-запись сторонними средствами. Так как S1D сидит в общей памяти, то у меня получалось доступаться к нему из-под дебаггера просто как к памяти, в отладочном окне "мемори". Конечно, предварительно нужно сконфигурировать контроллер шины в процессоре.

В-общем, разочаровался я в магазинах. У них уже новый год, епрст. Ничего путного не везут, продают то, что берут пачками. Результат- салоны завалены всевозможными TN-ками. Я уже почти определился. Хочу широкий, 20", не TN. Конкретно высмотрел Вьюсоник VX2025WM. Это 1680x1050, матрица MVA. Несколько зашкаливает по цене (490$), но народ вроде хвалит. Кто что скажет, вроде для КАДов и текстов MVA подходит? Живьем жалко нету, обещают после праздников. Ладно, будем поливать шампанским старый монитор... Насколько хуже все-таки TN ? Я походил, посмотрел- углы нормальные, ничего не темнеет при взгляде сверху-снизу-сбоку. Понял, что статьи о низкокачественности TN в большинстве устарели. Народ, кто сидит на TN и софт пишет-платы разводит, пожалуйтесь! Иначе не выдержу и таки возьму какую-нибудь не самую дешевую TN...

Всем спасибо, все прочитал. Я тоже хочу широкоформатный монитор взять, но они дороже. Подумаю,поищу. Два монитора- это идея хорошая. Купить два монитора я не потяну. Как вариант- оставить мой ЭЛТ 17" как второй (место на столе позволяет :). То есть его подключаю к встроенному видеоконтроллеру, в AGP втыкаю видеокарту с DVI, и работаю. Основной экран- LCD, а вспомогательный- ЭЛТ. Кстати, очень давно не проводил эксперименты с двумя мониторами. Во времена PCI карт S3- работало только при установке двух одинаковых видеокарт. Сейчас с этим как? Если два LCD- это что, две видеокарты, или купить на вырост одну, но с двумя выходами? Насчет матрицы. Я читал, что в IPS большое межпиксельное расстояние, поэтому видна (некоторым видна) "сетка". Это так?

Заранее извиняюсь. Если отклонился от темы данного Форума- пинайте. Но где еще спросить, как не у собратьев-конструкторов. Итак, чешу репу, выбираю монитор. Основное применение- это P-CAD и всевозможные IDE вроде Quartus и IAR, текстовые редакторы еще. Нужно побольше размерами. 20" от 19" разницу заметно? Или там разрешение уже меняют? Денег немного, скажем, до 450$. Пока вижу, что нужно: 1. Наличие DVI (ну и видимокарта с DVI, кстати любая ли подойдет?) 2. Отсутствие битых пикселей. 3. Регулируемая подставка, чтобы подвернуть-наклонить куда нужно. Что еще смотреть? Контраст? Яркость? Разрешение, как я понимаю, у них у всех одинаковое при одинаковой диагонали. От каких матриц у народа лучшие личные впечатления? (MVA/PVA/IPS) ? От каких фирм?

Тогда ВЫНУЖДЕН напомнить свой ответ ПОЛНОСТЬЮ: Это похоже?????? на Вашу интерпретацию моего ответа: Тогда ВЫНУЖДЕН привести еще один Ваш ответ: Извините, Вы действительно не говорили, что "PDC- это фигня по сравнению с FIFO". Вы сказали, что "в Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO". Вероятно, моя интерпретация этой фразы оказалась слишком вольной. Зачем тогда сожаление об отсутствие пересылок память-память? Я полагаю (уже писал), что имеет место быть необходимость после того, как отработало DMA c железом наконец переслать несколько обработанную принятую информацию в "правильное" место. Есть еще какие-то причины? Я лично могу назвать еще только одну - ошибки в проектировании системы приводящие к необходимости такой лишней пересылки. Ну зачем так прямолинейно? Предствьте себе более сложную картину мироздания. У меня для работы с некоторой периферией есть PDC, которые я успешно использую. Но также есть и другие устройства, для которых этих PDC нет, а правила работы с устройствами навязаны их производителем. Конкретно- NAND FLASH. Вот для нее-то мне и не хватает аналогичного контроллера, облегчающего жизнь. Еще пример- пересылка больших объемов (размером с экран) из SDRAM в контроллер дисплея. Тоже очень помогло бы наличие аппаратного "насоса". Вышеупомянутое- пример устройств, так или иначе отображенных на память, и если бы у меня был аппаратных контроллер для пересылок "память-память", он бы довольно хорошо уменьшил требуемое на эти операции время. О тривиальных пересылках внутри той же SDRAM я не говорю- это действительно вызвано часто не необходимостью, а применением плохого программиста. Нравится/не нравится это НЕ МОЙ ПОДХОД. Если есть выбор, то я выбираю наиоптимальнейший вариант не руководствуясь понятием "нравится" и стереотипами ( например, по отношению к затронутому здесь DMA). Согласитесь, под "нравиться" можно подразумевать комплекс причин, влияющих в том числе и на "оптимальность". А под "оптимальностью" можно подразумевать и банальную скорость достижения результата, что запросто может определяться личными предпочтениями программиста. Но это философский вопрос, не будем развивать. Спасибо!

Да. Напоминаю: Я: спросил, как можно быстрее передать данные, чем через memcpy(), и еще посетовал на отсутствие PDC для этого процесса. Мне: PDC- это фигня по сравнению с FIFO. Я: не вижу, чем FIFO лучше чем PDC. Как? Где Вы экономите? Я так и не понял. Конкретный пример приведите, как FIFO экономит пересылки при подсчете контрольной суммы? Или как FIFO помогает определить битый пакет? Так уж получилось, что я постоянно решаю задачи, в которых обработка сырого потока до момента его полного приема бессмысленна. То есть есть критерии завершения, которые я могу описать контроллеру PDC до начала обмена, и просто ждать прерывания по событию "конец приема". У Вас же, наверное, ситуация обратная. Ну что ж. А у меня ситуация обратная. Мой протокол хорошо ложится на PDC, вот и все. И FIFO ну никак не облегчит мне жизнь. Ну а если у меня постоянно MODBUS-RTU, который хорошо ложится на имеющийся PDC? Что мне теперь, протокол менять, чтобы неудобно было? :) Это да. Нет в мире совершенства. Кому что нравится. Мне- PDC, Вам- FIFO. :cheers:

Это я чуть отколонился :-(. Речь вел не о том, что без DMA лучше - с DMA безусловно лучше чем без ничего. А о том, что а Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO. Плохость FIFO в том, что: 1. "резиновых" FIFO пока не наблюдается. Сколько байт дали (обычно меньше чем нужно)- через столько и прерывайся. DMA позволяет этого не делать. Одно прерывание на посылку. 2. PDC позволяет не перегружать данные из памяти в FIFO передатчика каждый раз полностью. Например, если у меня PDC и я опрашиваю по петле одно устройство- то просто запускаю еще раз передатчик, так как буфер у меня нетронут. Либо меняю несколько байт в передаваемом пакете и все. Либо просто указываю контроллеру новые указатели для буферов приема/передачи. В случае простого FIFO- все нужно заливать по новой перед каждой передачей. При приеме- тоже грустно. из FIFO обязательно нужно выгребать, а PDC уже сразу кладет данные туда, куда мне нужно. Хм... Чем дольше думаю, тем больше сомнений. Можете привести пример, когда FIFO позволит сэкономить количество обращений с памятью? А если я в качестве буферов для PDC назначу набортное RAM контроллера?

Это Вы на чем? На Pentium M? :-))))) Нет, я про многострадальный AT91RM9200. Что-то я не горю желанием "аккуратно" переписывать, скажем, работу с восьмью разными SPI устройствами. Или обмен на 115200 по Modbus-RTU, чтобы при каждом байтике прерывания возникали. Я заранее уверен, что лучше, чем с использованием PDC, у меня не выйдет. И даже осмелюсь подумать такую крамольную мысль, что выйдет хуже. У меня, разумеется. За других не скажу.