Вот возник вопрос о передачи данных из EEPROM в таблицу Excel. AVR считывая по нужным адресам данные из EEPROM пересылает их в UART,как я понял на стороне ПК управление берет на себя скрипт на VBA, который рассовывает принятые переменные в нужные адреса ячеек в Excel. Реализовывал ли кто подобное? Что можно почитать про особенности работы AVR с Excel? Спасибо.

Боюсь , ничего. Также как , про АВР с Ворд.
Подключате АВР к компорту , а дальше контролами , ВинАПи , короче "в меру своей испорченности" , ловите данные и пихайте в Ехель. Про это сами найдете, что почитать здесь и на др. форумах.

" ВинАПи "
Не надо ВинАПИ. Ставятся соответствующие разделители, принимается терминалкой, сохраняется в текстовый файл и импортируется в Эксель.

Можно сказать, что конечному пользователю, не мне) будет сложновато проделывать подобное.
Трудновато будет мне с VBA.
Почитал на подобную тему инфо, народ решает проблему с помощью макросов к Excel'ю. Видно для уменьшения проблем пользователю, прибавим проблем себе.

Год назад решал подобную-же задачу -- собирать с датчика данные и смотреть/обрабатывать в Excel'e.
Поскольку мне нужно было еще попутно смотреть в "режиме осциллографа" что там пишется в файл, то
задачу решил с помощью написания соответствующей проги на VC++ (6.0). Прога принимала данные
(двоично-упакованные числа) с СОМ-порта, распаковывала и сохраняла их в человеческом текстовом
формате в файле, попутно отображая в окошке динамику процесса. Это сложный и долгий путь.

Сделайть проще, как предлагает, Dog Pawlowa:
* МК передает по RS232 числа в текстовом формате; по сути, льет готовый отформатированный текст,
который Вы получаете с помощью sprintf(str, ...), в UART.
* На стороне компа Вы запускаете на выполнение команду
c:>copy com1 myfile.txt
* После окончания приема загружаете Excel и импортируете в него файл.

Спасибо за помощь. Посмотрел на зарубежных сайтах, там люди делали макросы в Excel для приема данных с АЦП AVR через UART и отображали полученное в графиках. Посмотрел структуру VBA на примере готовых решений, думаю осилю.Тем более, что надо расставить принимаемые данные в нужные ячейки, после прочтения, кажется уже не так сложно.Спасибо еще раз.

А других "страшных слов" кроме VBA ты не знаешь? Нужно нанять программиста и он сам решит, как это сделать. А аппаратчику (т.е. тебе) не мешало бы подумать, что использование UART в нынешнее время не то чтобы устарело - это 20-й век. Ты давно видел компы с этим портом? Они уже лет пять как не выпускаются, а вы упорно лепите свои уарты. Может о прогрессе подумать пора?

Мостик между 20-м и 21-м веком - переходник COM-USB. Т.е. вроде бы ты еще в 20-м, а с другой стороны, и отсутствие СОМ тебе не страшно...

А ведь некоторые люди еще письма руками пишут и по почте (не путать с e-mail) отправляют, это же даже не наша эра . А вот с выделенным +1.

"Мостики" эти придуманы для устройств, разработанных еще в 20-м веке. Но разрабатывать такие в 21-м и закладываться на переходники - это или глупость, или лень изучать USB.


Не знаю я таких людей. Сейчас бумажные письма используются только для переписки между предприятиями - и то, только потому, что бумажные письма это единственное, что принимают к рассмотрению арбитражные суды. А обычные люди даже в деревнях уже давно письма не пишут - они звонят по мобилке.

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

Я, например, очень даже не редко использую в качестве канала передачи инфы связку
UART-COMx и не считаю, что это есть моветон. Наоборот, там где есть возможность, я
использую именно этот тип связи, ибо это проще и следовательно быстрее реализуется.
Я отступаю от этого способа связи только в двух случаях:
1) если на компе нет СОМ-портов;
2) для коммерческих изделий, т.е. для изделий, которые будут юзаться не мной или
людьми не из моего ближайшего окружения.

Следует заметить, что я отступаю ни куда-нибудь далеко и радикально, а опять же в
направлении организации UART-COM канала через USB, устанавливая вместо микросхем
(или транзисторов) для RS232 микросхемы FT232х. При этом на стороне компа требуется
установить только FTDI-драйверы. Прикладное ПО на стороне компа и фёрмварь на
стороне МК почти не затрагиваются.

Я бы, конечно, полностью перешел на ЮСБ, но меня сдерживают следующие факты:
1) Организация передачи инфы через ЮСБ -- сложнее.
2) Передача инфы через ЮСБ кешируется, как следствие, нельзя полагаться на
временные параметры.
3) При тех же скоростях передачи данных, как и в случае с RS232, реализация
ЮСБ-канала получается дороже.
4) Косяков со связью по ЮСБ намного больше, чем со связью по RS232, и дебажить их
труднее.

Но есть один сильный аргумент в пользу ЮСБ -- халявное питание от компа.
Все остальные положительные стороны ЮСБ у меня как-то не очень востребованы.

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

Традиционный путь через ActiveX - http://aly.ogmis.lt/OpenProjects/ActiveX/ActiveX.htm
Но говорят в последнем релизе .NET появился уникально удобный компонент для COM порта.

Есть ещё один, наверное самый важный недостаток связи по USB: устройства, подключенные к компьютеру время от времени просто "теряются", комп. перестаёт их "видеть", пока коннектор банально не вынуть и не вставить снова. Уж не знаю, проблема ли это Винды или в самом протоколе что-то, но для ответственных задач эти "глюки" недопустимы. Хотя, наверное, побеждать эту ситуацию уже научились. Но что не все - так точно.

Для передачи данных в EXCEL можно воспользоваться старинной технологией DDE. Тогда на лету будут меняться значения в ячейках. Ну а если приложить ещё немного усилий, то на VBA можно сваять динамически меняющийся график переходного процесса...

Третьего варианта Вы совсем не допускаете? Я вот видимо глупый человек, или ленивый, потому что в свои системы закладываю RS-232. И компы у нас свежайшие (2009 год выпуска) и, не поверите, на каждом RS-232. На ноутах нет, согласен. Так может быть для приложений, который не требуют навороченного траффика, не предназначены для массового использования не будем навязывать USB (ну или ETHERNET), ставя в вину человека глупость или лень...
Все таки UART довольно старый, отработанный на много рядов интерфейс, имеющийся почти везде. Без драйверов легко доступен даже без установленной ОС. Это я, конечно, крайний случай загнул.

Но в целом могу с Вами согласиться, что USB нужен. В принципе, применение АРМ не мешает заложить хоть три интерфейса в девайсе (RS-232, USB, ETHERNET). Тогда будет совместимо с компами 20 летней давности и с локальными сетями, имеющимися в настоящее время.

Я думаю это проблема разработчика. И уж называть это "самым важным недостатком" - это явное преувеличение. Главным недостатком является сложность протокола - да, я с этим согласен, но это только в первый раз. С последующими устройствами проблем будет меньше. Еще один существеннцй недостаток - сложность получения Vendor ID, но он тоже решаем. А больше я проблем не вижу. Для UARTа сейчас осталось только одна ниша - использование его для связи между двумя микропроцессорами, да и здесь во многих случаях удобнее воспользоваться SPI.



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

А если необходимо свзять два узла оборудования, например систему управления и выносной пульт управления? Тут тоже USB необходимо городить?) Только зачем? Когда все полностью решает UART.

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

На самом деле главный недостаток - это офисный характер протокола.

Работает в пределах офисного стола.
На сотни (да хоть на десять) метров его не раскинешь.
А иногда (и очень часто) надо.

А UART - загнал в 485 - и получил промышленный стандарт.

Хотя, кому чего нужно. Кому рюшечки на столе, кому системы автоматизации...

USB это пижонство и совершенно лишний гемморой. Если скорости меньше мегабита.

Ну почему же, USB дает много пользы если знать в нем толк

USB в первую очередь интересен мультиинтерфейсностью.
Скорость и на UART современных можно достичь 3-4 мегабита.
И FireWire есть если нужно качать с дивайсов долго и нудно.

Однако вот делаю допустим медицинский дивайс, там раньше стоял здоровый RS232 для компа, еще один для принтера и еще один для сканера штрих кода.
Теперь ставлю один маленький OTG USB и он один заменяет все три интерфейса и даже больше. Дивайс становиться компактней и дешевле. Меньше мех. обработки

Даже если в дивайсе был один RS232, то замена его на USB функцию позволяет получит до 255 виртуальных COM портов при подключении к компьютеру.
Очень удобно под каждую задачу в микроконтроллере иметь свой диагностический канал в виде отдельного COM порта на компьютере.

Или допустим GSM модемы. Очень скоро они все станут с USB интерфейсом. Там реализуют сразу 3-и виртуальных COM порта. Один для отладки или GPS-а, один для AT команд, один для интернета. Очень удобно. Одновременно и с SMS и с интернет работать можно.

Еще интересная тема в том, что в USB стандартизирует доступ и использование таких дивайсов протоколы к которым были раньше в основном под строгим NDA.
Это и Wi-Fi, Wi-MAX, WEB камеры, FLASH накопители, принтеры, цифровые фотики, мобилы и т.д.

На самом деле трудно придумать где USB не дал бы конкурентного преимущества и скорость тут как бы не причем.

Уважаемый 777777, если бы я написал связка AVR c Excel через USB вам бы наверно нечего было сказать?
Я тоже ленивый и не хочу реализовывать USB , тем более, что планируется передавать меньше 1 кб информации и использовать переходник
RS232<>USB. Про длину на который можно вынести девайс от компа сказано по делу.Это тоже учитывается.
Спасибо всем за ответы и помощь. Теперь вот задумался, может написать в Visual C# програмку, которая в свою таблицу будет просто помещать принятое в нужные ячейки.А потом просто распечатывать поле и интерфейс простым получится, да логотип и законченность прибавится))

Упс! Про пиженство это Вы зря. Не красиво получилось

Конечно, в некоторых случаях лучше использовать USB, а не RS232. AlexandrY
хорошо описал, как он борется со своими проблемами. Я его понимаю. Более того,
я тоже так считаю, что в его частном случае использование USB более
оправдано, чем использование RS232.

Мне кажется, что MrYuran ближе всех подошел к истине. Сфера применения
USB -- это "настольное" его оспользование.

Возвращаясь к началу, следует наверно уточнить, что USB не предназначен для
замены RS232. Эти два протокола имеют общую территорию. Но у каждого протокола
есть свои области применения, и, надо сказать, далеко не малые, где один из них
будет более оправдан, чем другой. И я так думаю, что это определяется не модой на
новые технологии, и не пиженством, а в первую очередь экономическими, а во вторую
очередь -- техническими соображениями.

Извините за вредность , но не могу не поправить, RS232 это не протокол, а стандартный (стандартизованный) электрический интерфейс.

Ну почему же?

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

Хотя, спасибо за поправку. Заставил задуматься, полистать книжки.

Забавно, Дуглас Камер в книге "Сети TCP/IP: принципы, протоколы, структура" говорит
о RS232 не как о протоколе, и даже не как об "элетрическом стандартном интерфейсе".
Он отзывается о нем как стандарте. А вот Фред Иди в своей радиолюбительской книжке
"Сетевой и межсетевой обмен данными с МК" рассматривает RS232 именно как протокол.

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

Это и есть стандарт. Именно стантдарт - очень старый, 60x годов, когда рекомендации "ассоциации электронной промышлености" обозначали, как RS а не EIA. Сейчас это правильнее называть EIA-232E . А вобще ICCIT(МККТТ) V.24 более кошерен к поминанию в качестве стандарта. ISO тоже какой-то имеется на этот счет.

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

Вы вообще стандарт EIA/TIA-232-F видели? Нет там слов про протокол вообще! Про электрические характеристики сигналов написано. Про типы разъемов. Про соединения DTE<->DCE, про количество и способы соединения сигналов квитирования. Про емкость и длину линии. А вот про количество информационных битов в символе и бит паритета, там как раз нет ничего.
Вот одна из первых страничек стандарта с описанием разделов. А в этой апликухе краткий обзор по многим известным стандартным интерфейсам.

Да, сегодня явно не мой день. Даже не знаю, что и ответить... Одняко, попробую.

Я тоже умею гуглить и тоже умею читать. Первая же ссылка при поиске "Protocol EIA232" ведет на страницу
http://www.interfacebus.com/Design_Connector_RS232.html

, где читаем следующий текст:


Отлично! То, что доктор прописал!

Однако, на этой же странице первый рисунок имет подпись "EIA232 Protocol" (загрузите страницу с
отключенными изображениями), на котором показана временная диаграмма передачи бит. Оба-на!
И как это противоречие понимать? И таких мест в инете очень много.


Уважаемый rezident, я Вам буду очень благодарен, если Вы сможете ответить на два простых вопроса.
1. Чем объяснить, что очень многие употребляют неправильное сочетание терминов "Протокол RS232" и
при этом абсолютно точно понимают, о чем идет речь.
2. Какой нормативный документ (стандарт, протокола, ...) регламентирует порядок передачи битов, наличие
стартовых и стоповых битов при передаче инфы в стандарте RS232?

Я не хочу Вас "уколоть", это мне нужно лишь для того, чтобы знать, чем следует заменить мое
неправильное выражение "Протокол RS232". Пожалуйста, назовите правильный термин, которым можно
так же лаконично и понятно_для_всех называть передачу битов. Я не против поучиться.

Спасибо.

Это вопрос риторический что ли? Спросите у тех, кто употребляет такое словосочетание. Они видимо про RS232 только в применении к COM-порту PC знают
Это определяется конкретным UART (Universal Asynchronous Receiver / Transmitter), который подключен к интерфейсу RS232. Через RS232 теоретически можно и манчестер забульбенить. Только нафиг не нужно при такой низкой пропускной способности оного интерфейса.
Пишите корректно - "интерфейс RS232" и лично у меня не будет никаких претензий
"Передача битов" настолько размытое в понимании словосочетание, что под него просто невозможно дать конкретное определение или термин. Если вы про асинхронную последовательную связь пишете, то так и указывайте - последовательная асинхронная. Биты ведь и через параллельную шину тоже передаются, только одновременно по нескольку - параллельно А RS232 может и синхронным быть. В стандарте указана такая возможность.

ага, а некоторые МК это могут даже практически А еще могут работать
в режиме модема, RS485, IrDA. А если теоретически и чисто поизвращаться, то я
бы сюда еще и функции ШИМ приписал... и может быть еще что-нибудь. Так что?
Будем друг друга понтами валить?



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



Разумеется, я имел виду именно последовательную передачу битов, или мы еще какой-то
интерфейс здесь упоминаем?



Хотя, опять же, если поизвращаться, то, думаю, можно через RS232 параллельно по паре
бит передавать. Только зачем?


Да неужели?!!
Ну что уж так дурно думать-то о людях?


И давайте уже прекращать этот никому не нужный балаган. Обращаюсь к Вам, как к
модератору, удалите ненужные постинги. Я не возражаю.

Еще какое пижонство.
Кардиостимулятор работающий от компа. В одном случае 232, в другом - USB.
Спотыкаемся, вытаскиваем разъем. Засовываем обратно. В случае с USB можно и не дожить.

Жесткий дурацкий кабель. Да еще толстый.

В случае с программой для PC - она может быть хоть под Дос. Портируется на любой другой комп любой архитектуры и любой ОС. Легко
и с песней Лед Зеппелин Рок-н-Ролл.
Хуже того, вместо PC я могу ЛЕГКО подключить другой микроконтроллер (и удешевить систему кардинально).
В случае с USB - это тоже можно сделать.
Но уже под долгую и нудную песню битлов "I Want You (She's So Heavy)" Песня неплохая, но уж очень длинная и оттого - нудная.
Да еще эта беготня с драйверами... А за МКАДом про многие нововведения в области компьютеров еще и не слышали даже. Лично знаком с доктором, у которого диагностический комп не содержит USB. И не планируется. А на столе у него коробка с дискетами. Кто помнит, что это?

Если условно, то Солнце вращается вокруг Земли. Это ведь каждый видит собственными глазами каждый день.
Вы можете придумывать себе какие угодно условности, названия и абстракции. Никто не может вам в этом помешать. Вот только перед тем как их употреблять, договоритесь о них с другими. Если их примут, то замечательно, а если нет, то хотя бы будут иметь в виду, пытаясь понять, о чем вы им объясняете.
RS232 это интерфейс, а не протокол. Точка.

Никогда так не смеялся! Спасибо!
"По науке", RS232 -- это интерфейс. Никто и не оспаривает.

Когда люди говорят о том, как они собираются передвавть данные -- по SPI-ли, по I2C-ли, или еще как-то,
когда людей не интересуют ни типы разъемов, ни номера контактов, а только задействованные модули в МК
(или ПК), когда им важно подчеркнуть, что этот тип последовательной передачи данных будет именно такой,
а не какой-то другой, то они условно называют это -- "протокол 232". И все друг друга понимают, хотя такого
протокола ни в одном стандарте нет. Как нет и официального определения следующих выделенных мною
терминов, которые я надергал из Ваших же постов:

и еще много чего можно было насобирать. Дело не в этом, дело в том, что мне это ничуть не помешало
уловить суть Ваших мыслей. Было бы желание. А придраться можно к чему угодно. И тоже, было бы желание.

Стандартный и совсем неоригинальный способ - переход на личности. Читайте стандарт и просвещайтесь, господин придиральщик.

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