Arduino.ru

Спасибо за совет!

Ну тогда "конкретика" - не очень имеет смысл. Это как учится на велосипеде за партой :) В реальности - все проблемы будут чуток к другими. Не теми к которым "готовились". К каким-бы не готовились. Так что сейчас сильно лезть "в детали" - не имеет смысла. Как раз наоборот - пошире обзор сделать. Прочитать ВЕСЬ раздел Программирование. Можно бегло. Просто что-бы знать "какие строительные блоки у вас вообще есть". Хотя-бы "смутно". Когда понадобится - уже полезете детально читать. Примеры/туториалы посмотреть. Про кнопки и диоды почитать. Примеры и прикрепленные ветки. Так, обзорно, что-бы понять принципы. Вернее что-бы "потом знать где искать".

Можно конечно на эмуляторах... но это не совсем то. Хотя, если нужно вспомнить что такое for, типы данных и т.п. - можно и эмуляторы. Если "совсем базу нужно вспоминать" - можно на http://processing.org/ посмотреть. Среда язык "родственные ардуине", только это "для компа". Правда есть и небольшие отличия в синтаксисе/типах, но циклы/if-ы и т.п. - работают точно так же.
 

Я же писал вам "пошаговость". Может вы будете вообще с цифровыми пинами работать. А вы сейчас заморачиваетесь на аналоговый заранее. Ну кто же заранее знает что вам будет выдавать ваш конкретный датчик? Какое у вас будет напряжение питание и проч. 

Воткнули, померяли... если он у вам дает, при импульсе изменение показаний с 300 до 1000 попугаев. - то вообещм-то вам фиолетово, сколько "в милливольтах" означают эти 300 "попугаев". Главное что вы точно можете отличить одно состояние от другого. Если же импульс, на аналоговом входе вы видите в виде изменения в 20-ть попугаев, при этом шум ацп составляет 10-ть попугаев - тут уже репу чухать нужно.

А может вы возмете сразу датчик со встроенным цифровым компаратором и усилителем (кстати, тут где-то в соседней ветке про автомобильный тахометр пробегала ссылка на такой). Который вам будет тупо возвращать либос GND либо VCC. Тогда вам никаких аналоговых - вообще не нужно. digitalRead и все. Будет у вас только 1 или 0.

Почему бы avovana не использовать связку LabView + Arduino?  LabView - отличнейший инструмент для обработки данных, есть уже готовая библиотека для связи с ардуиной, большое комьюнити. В связке с arduino UNO частота опроса у меня была 100 раз/секунду

> LabView - отличнейший инструмент для обработки данных

Зачем плодить лишние сущности? Порог входа в LabView - далеко не нулевой. И еще сильно зависит от того "какие мозги входят". Аналоговы или цифровые  :)  "Геометрические" или "Алгебраические" :)  (вообщем от стиля мышления человека который "входит").

В любом случае вначале нужно:

1. Подключить датчики
2. Прочитать датчики
3. Отправить на комп.
4. Принять на компе
5. Обработать на компе.

LabView - последние два пункта. Одно из возможных вариантов (на "мой вкус" - далеко не самый простой, если ты с ним раньше не работал). В любом случае хмурить мозг по поводу приема и обработки - ОЧЕНЬ рано. Вначале нужно увидеть их через вульгарный Serial.print, на вульгарном Serial Monitor.

В том то и дело, что прочитать датчики с ардуины в labview проще простого. Никакого скетча писать не нужно даже.

2. Прочитать датчики
3. Отправить на комп.
4. Принять на компе

Это всё делается за тебя.

https://decibel.ni.com/content/docs/DOC-16067

>Это всё делается за тебя.

Ага. Только "шаг вправо-влево" - и сразу ступор. Когда не понимаешь "как эта магия работает".

Вот предположим (а скорее всего так и будет) мне нужно ловить фронты импульса и замерять время между ними. Смогу я, ни разу в жизни не видим LabView поменять сходу эту Block Diagram?  Да ни вжизть.  Я вот даже, сходу не пойму что нарисованно на то что уже есть. Что это за Stop, DBL,V, TF, красный квадратик??  Да разобраться можно, но сколько времени это займет?  По сравнениею с тем что-бы клацнуть кнопку в ArduinoIDE и увидеть как "цифры бегут в Serial мониторе". Что-бы понять там "что-то около нуля" или "что-то около 1024" - этого уже достаточно. Что-бы понять работает ли датчик вообще. И не нужно ставить LabView, какие-то его дрова, какаой плагин к нему, какой-то тулкит. Разбиратся что это за VISA resource terminal.

Слов нет. Voltage со стрелочокой - это красиво и удобно. Если ты собираешься отдавать этот конечный продукт инженеру который "ничего знать не хочет про программы и ардуино". Но на этапе разработке.... бегущая колонка цифр - достаточно.

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

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

Вообщем как ни крути, но и в вашем случае нужно вначале:

1. Подключить датчики
2. Прочитать их и вывести Serial (то что вы нашли в примерах LabView как это сделать готовым - не означает что вы этого не делаете. просто путь - более длинный).

P.S. Кстати, а сам LabView он как  бесплатный или "ну есть же торренты и лекарства"? :)

P.S. Если бы мы были рядом физически, то можно было-бы даже "забится". Кто быстрее переделает базовый пример с одного датчика на 8-мь. Вы мышкой в своих "блоках диаграммах" или я обычным кодом ардуины:) А если еще учитывать время необходимое на Install и первоначальную настройку LabView

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

Винда у вас тоже небось купленная?. Или каждые 30 дней переустанавливаете? :) 

А по сути: в labview очень интересно это реализовано. Ардуина представляется как шина с данными, на которую параллельно навешиваешь библиотечные блоки чтения/записи. Так что переделать базовый пример очень просто, сам пробовал.

Хотя опять-же, автору можно читать com-port из Excel`я и писать значение в ячейку. Я это тоже в свое время делал. Частота опроса правда была около 15 раз/секунду. И в этом случае всё равно нужно сидеть и разбираться как это заставить работать.

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

Так вот к чему я это всё: если нужно просто числа с ком порта читать, то без вариантов - эксель со скриптом лучше всего. Если же хочется какую-то обработку(типа постройки 3d графика) - то стоит рассмотреть другие варианты. Хотя и в экселе 3д строить можно :) 

   Да, LabView продукт конечно мощьный и гибкий. Но вот так просто установить и пользоваться у меня не вышло (первое раздражение началось с установки - ну БОЛЬШАЯ программа). Дальше поиски книг и плюгинов. В общем пока изучал работу с ней, начал забывать зачем это всё затевалось. Бросил LabView, нашёл путь попроще. А топик стартеру действительно до графиков ещё далековато, leshak прав.

Да вы опять про то "как принимать и обрабатывать на компе". Ну что вы телегу впереди лошади запрягаете?
1. Читать датчики
2. Отправлять данные.

Все.

Убедится что "данные идут" - ну не придумаете вы ничего проще чем "нажать кнопочку в верхнем правом углу ArduinoIDE".

И только потом уже можно думать, пробовать  и выбирать Excel, LabView, Delphi, PHP, C# WPF или WebForms, PowerShell, веб-интерфейсы, Javscript, Processing, MegunoLink (кстати лично я его юзаю "глянуть по быстрому график"), Arduino Osciloscope, Xoscillo,  Листик миллимитровки, SUMP клиенты, Firmata клиенты, Matlab, R, Wolfram и еще сотни всяких "для визуализации и обработки научных данных" общего назначения, специализированные для "анализа работы двигателя..." и т.д. ит.п.

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

Я просто предложил свое видение обработки данных. Всё. Успокойтесь.

"Спокойно Кузя... спокойно....". Все. Успокоился. А ведь помогло :)

Спасибо за интересные мысли, все прочел))) Естественно, другу хочется получше сделать. Чтобы и ему было приятно и понятно работать с программой и я был довольный от ее реализации) Скорее-всего, ему будет проще строить графики в Excel. Поэтому, после минутных замеров хотелось бы вывести, наверное 8 таблиц, чтобы по строчкам легко было взять числа и забить в форму в Excel. Не подскажите как это сделать? После минуты просто вывести элементы массива на экран? Можно ли с экрана скопировать значения?

Скорее-всего, купит Arduino Leonardo с 12 аналоговыми выходами.

Нужно будет углубиться в недры Экселя, конкретно: VBA, еще конкретнее: гуглите MSCOMM32.OCX.

Будете читать ком порт(считай текстовый документ), брать с него данные и записывать в ячейки (типа  Worksheets("Лист1").Cells(2, 2).Value).

Нюансов много, будут возникать во время написания проги. Спрашивайте :)

>Нужно будет углубиться в недры Экселя, конкретно: VBA, еще конкретнее: гуглите MSCOMM32.OCX.

Не, ну легких путей мы не ищем никак :) Ну если уже "выбрали экселю". Зачем сразу так углублятся?

В начале скетча делаем Serial.println в котором перечисляем название колонок через запятую.

Потом в loop() выводим показания датчиков. Каждый "набор" в одной строке. Через запятую.

Потом делаем copy-past всего что вылезло в сериал монитор. И сохраняем в файлик с расширением .csv
Открываем его exce-лькой. И дальше делаем что хотим. Добавляем графики, фильтруем, добавляем вычислимые колонки и т.д. и т.п.

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

>После минуты просто вывести элементы массива на экран

Я вот никак не могу понять, ну почему так "после минуты"? Чем не устраивает "постоянно выводить, в режиме реального времени, а после минуты - прекратить". Ну не хотите смотреть на процесс "как данные поступают от ардуины". Ну отвернитесь на минуту от монитора ;) Посмотрите когда на экране будут данные за всю минуту. Зачем морочится с "сохранять, потом выводить", если можно сразу "прочитал, отослал на комп"?

А можно вместо всего этого открыть эксель, выбрать номер порта и нажать кнопку "прочитать данные". И всё. :=)

Ну так "вначале было слово. печали и тоски" :)

Как ни крутите, а вначале должно быть начало. Вначале должен быть "минимальный прототип". Без необходимости разбиратся с VBA, гуглить MSCOMM32.OCX, решать вопросы "как правильно открыть ком порт". Посмотрите сколько веток "как передать данные из ардуино в XXXX". На какое количество граблей люди умудряются наступить. Сколько времени занимает до "фух... заработало"?

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

Поэтому 10-ть минут на "скетч, click, ctrl-c, открыли текстовый редактор, ctrl-v, save as..., click для открытия" - все смотрим. Почти наверняка в этот момент у нас возникнут "новые хотелки", пересмотр понимания "что нам нужно". Что-то переделать - нам легко и быстро. Сделать новый замер - ну на десяток движений больше займет чем ваш вариант.

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

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

Никто же не спорит, что "нажать кнопку прочитать данные" - плохое решение. Хорошие. В идеале так и должно быть. Я потому программистом и стал, что рано ощутил кайф от "я вот три дня мучался, что-бы автоматизировать 5-ти минутную задачу, зато теперь нажал и оно само...". Вот это "ОНО САМО". Ощущение этого  и стало "движущей силой".

Но... жизнь показывает что не бывает все черно-белого. И зачастую нужно искуственно себя одергивать. Не уходить в "технологию ради технологии". Все время смотреть на баланс "результат"/"факторы расплаты".

Кстати поэтому люди которые в Excell умудряются рисовать диограммы ганта и вести проекты (лично видел), или которые 7-мь лет(!) перключает раскладку мышкой и прыгают от радости когда им показали "так можно же alt-shift" (лично показывал ;) - в итоге более эффективны. А вот "технарь", запросто уйдет "строить все по фен-шую, правильно и по уму". Потратить недельки две, на то что "по тупому" можно было за час сделать.

P.S. А еще есть такая штука как гугл. http://www.robertovalgolio.com/sistemi-programmi/arduino-excel-commander

Спасибо большое за информацию! Жду покупки и, соответственно, начала практической части)

Моя научная мысль дошла до вывода данных с 6ти портов и их запись в двумерный массив. Правильно ли его использовал??? Обязательно ли #define? Работает ли "/n" - перенос каретки?

Для 6ти портов

int analogPin[6] = {0, 1, 2, 3, 4, 5} ;
int val = 0;
int j = 0;

byte array [6] [60];       


unsigned long loopTime;      // для millis()

void setup()
{
  Serial.begin(9600);            //  установка связи по serial
  loopTime = currentTime;       //   записываем его в loopTime
}

void loop()
{
if(millis()>=loopTime+1000)
 {
for (int i=0; I <= 5; i++ )

    {
val = analogRead(analogPin[i]);
Serial.println (“\n”)
Serial.println(i);
Serial.println(“ sensor value is ”);
Serial.println(val);

array[i][j] = val;

      }
j++;               
if(i == 6) i=0;
loopTime = millis();                                      
 }
}

Пока что-то не разобрался что за команда за это отвечает... Здесь же - как остановить программу? Есть кнопка в самом интерефейсе? Просто у меня массив заполниться и дальше непонятно что будет...

Спасибо! На месте буду ставить, разбирать как вывести данные удобно для создания графиков для каждого датчика

define для одного порта удобно, или значения которое не изменяется

если 6 портов удобнее так как вы сделали. но я лично не проверял (хотя где-то попадалась такая инфа) что analogRead(0) соответветсвует analogRead(A0), так как 0 пин тоже есть в арудине. вроде как компилятор сам определеяет что имелось в виду, так как analogRead на нулевом цифровом пине просто работать не будет, так как на нем нет ацп

println уже делает перенос каретки после сообщения

попробуйте так, только немного переделал как мне бы было удобнее

//Для 6ти портов

int analogPin[6] = {0, 1, 2, 3, 4, 5};
int val = 0;
byte j = 0;

byte array [60] [6];       //для меня удобнее массив из 6 столбцов и 60 строк. тогда одна строка
//сооветствует каждой секунде. но тут кому как удобнее


unsigned long loopTime;      // для millis()

void setup()
{
  Serial.begin(9600);            //  установка связи по serial
  loopTime = millis();       //   записываем его в loopTime
}

void loop(){
  if(millis()>=loopTime+1000){
    for (byte i=0; i<6; i++ ){
      val = analogRead(analogPin[i]);
      Serial.print ("time ");
      Serial.print(i);
      Serial.print("s   sensor value is ");
      Serial.println(val);
      array[j][i] = val;
    }
    j++;               
    if(j == 59) j=0;
    loopTime = millis();                                      
  }
}

>analogRead(0) соответветсвует analogRead(A0),

Соотвествует.

>вроде как компилятор сам определеяет что имелось в виду

Компилятор про ардуину ничего не знает. Вся "магия" заключена в самой функции analogRead(). Если любопытно - загляните в ее исходик.

if(millis()>=loopTime+1000){

Это "плохо". На 49-тый день непрерывной работы возникнут проблемы.

if(millis()-loopTime>=1000){

Будер работать "вечно".

сомнительно что потребуется измерять 49 дней подряд измерять, поэтому считаю незначительно

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

почему последнее условие будет работатать вечно? то есть в любом случае срабатывать. ведь в теле условия есть looptime = millis()

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

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

Ну или просто, будете делать, скажем систему отопления газовым котлом, и напишите так "по привычке...". Лучше сразу привыкать "одевать шлем". Даже если едешь в магазин за 300 метров (кстати по статистике именно вот на таких коротких поездках получают кучу травм. Именно потому что не воспринимают ее "серьезно").

Нет. Вы не верно поняли. "Вечно" имелось ввиду оно будет "работать корректно" даже когда наступит момент переполнения и millis() опять начнет отсчет с нуля. Мой вариант будет срабатывать "раз в секунду", даже в этом случае.  А ваш вариант условия, на последней секунде перед переполнением, будеть давать давать "сработку" каждый проход loop().

А вообще, я вот упорно не понимаю. Ну зачем так сложно? Зачем тут массив 60x6? Толку от того что мы в него сохраняем, если потом нигде не используем? Зачем на вообще сохранять?  В этом случае нам не нужна и j.

Зачем тут конструкция, для неблокирующего переодического действия? Разве мы тут что-то делаем (или планируем) помимо чтения датчиков и отправки их компу?

Почему if(j == 59) j=0; если в условии задача говорилось "минуту меряем потом баста?". Где тут "остановка"?

Вообщем нужно, было все-таки начинать с "базовых примеров". Понять что такое setup() и loop(). Сколько раз они выполняют. Так как нам нужно "выполнить один раз", значит всю логику нужно писать в setup(), а loop() - вообще оставить пустым.

Второе что нам потребуется - самая вульгарная функция delay(). С которой познакомится можно в любом первом объяснении "что такое ардуино". Самый первый/базовый пример. Hello world. 

И две "продвинутые вещи": цикл for. И Serial.println. 
Все, больше ничего не нужно. Ну разве что analogRead. Что-опятаки "первое что нужно читать". После digitalRead.

Начинать нужно с "базовых кирпичиков". 

void setup()
{
  Serial.begin(9600);            //  установка связи по serial
  
  Serial.println("Start.....");
  for(byte time=0;time<60;time++){ // замер делаем 60-т раз.
  
        for(byte pin=0;pin<=5;pin++){ // проходим по 6-ти пинам
           Serial.print("Time=");Serial.println(millis());  // выводим время 

           Serial.print("A");Serial.println(pin);Serial.print("="); // Выводим A[pin]=
           Serial.println(analogRead(pin));// читаем пин и сразу выводим.
        }
        Serial.println(); // пустую строку - для визуального разделения замеров
        delay(1000); // секунду тупо ничего не делаем.
  }
   
  Serial.println("The end");

}

void loop(){
  // тут тоже - ничего не делаем, все что нужно - мы уже сделали.
}

За

if(millis()-loopTime>=1000){

Спасибо.

В том же первом примере прочитал что delay() использовать нежелательно

Т.е. если программу напишу в setup() , как в Вашем примере, то на монитор выведет что надо и программа остановиться? Я просто ту самую "басту/остановку" не знаю как делать. Да, сейчас нужно записать 1 минуту. Если воспользуюсь данным примером, то смогу после этой самой минуты скопировать данные с монитора, они не пропадут?

P.S. Понимаю, что вопрос может быть совсем обескураживающим, что, возможно, стоит подключить Ардуино, поставить среду и там все будет ясно. Просто, как уже говорил, на руках ее нет. Хочу прийти к другу и уже примерно представлять что к чему. Программирование читаю. Примеры разбираю)

... Двойной массив сделал в расчете на сохранение в какой-нибудь .txt файл для удобства копирования в Exel. Но, если и с монитора можно данные скопировать и они никуда не исчезнут после выполнения программы, то такой трюк уже не нужен.

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

Вот до сих пор не нашел считывание данных с клавиатуры. Было бы круто - нажать на клавишу - начать программу. К примеру крутиться минуту, останавливается, спрашивает - продолжить? Да - снова крутим минуту. Нет - стоп программы

>В том же первом примере прочитал что delay() использовать нежелательно

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

"Кто-то так сказал" - это не довод. Кстати это же относится и к моим утверждениям "вот так плохо", а "вот так - вечно будет работать". Тут подход должен быть не "спасибо, нужно запомнить так не делать". А нужно разобратся чем же отличаются эти два варианта (с точки зрения "школьной математики" ведь ничем же не отличаются ;), почему они будут работать по разному. И это нужно не от "тупого любопытства", а потому что в первом зарыта довольно распространненая (даже у "опытных") ошибка. Причем "ошибка общего вида". Которая может проявится в  1000+1 способом. И "проблемы с переодичностью действия" - всего лишь один частный случай ее проявления.

> и программа остановиться?

Нет. Программа не может остановится. Даже на компе (если не рассматривать относительно экзотические случаи) программа не останавливается. Она "выходит". Отдает управление операционной системе. В микроконтроллере  нам "выйти" - некуда. Некому передать управление процессором (рассматиривать случаи "остановить процессор" - не будем. это для других целей делается). Программа всегда "что-то" делает. Но в наших силах сделать что-бы "что-то" означало "нифига". То есть если мы привели програму в состояние "делаем нифига", то с точки зрения ПОЛЬЗОВАТЕЛЯ это и будет выглядит как останов. Никаких видимых проявления деятельности программы. Но програмист-то знает правду :) Она просто "ковыряется в носу" и даром жжет электричество;)

> то смогу после этой самой минуты скопировать данные с монитора, они не пропадут?

Ну а чего им пропадать? Тем более что я выше уже даже расписывал последовательность нажатия клавиш и мышки что-бы перенести данные из монитора в эксельку. А если взять не стандартный Serial Monitor, а любую более менее нормальную терминальную программу, то в ней почти наверняка будет функция "записывать все приходящие в файл". Так что даже ctrl-c, ctrl-v не потребуется. Но вначале нужно с ctrl-c, ctrl-v попрбовать.

> что, возможно, стоит подключить Ардуино, поставить среду и там все будет ясно. 

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

Ну, на крайняк - поставте какой-нибудь эмулятор и попробуйте. Даже онлайновые существуют вроде.

>Двойной массив сделал в расчете на сохранение в какой-нибудь

Без разницы на что вы расчитывали. Если вы в массив только пишите и нигде не читаете, то расчитывать можно и на "отправку данных братьяем по разуму в галлактике z8-GND-5296

> на сохранение в какой-нибудь .txt 

Загуглите формат csv. Научитесь его писать вначале руками. В блокноте (Notepad). Сформируйте его содержимое (руками!) так, что-бы он в Excel открывался без лишних проблем. И вот когда уже будете точно знать "как он должен выглядить внутри", тогда "руками", замените на "с помощью serial.print/println".

>то такой трюк уже не нужен.

Хм.. а я о чем распинался пол ветки?

Ну а кнопка "reset" чем не кнопка? Уже есть. Уже припаяна :)

Да и кнопкой - оно не всегда удобно тянутся. Гораздо проще "закрыть/открыть" Serial Monitor. Побочным эффектом будет "очистка Serial Monitor". А это значит что поступившие данные можно выделить банальным ctrl-a. Нет необходимости глазами/мышкой выделять данные "последнего замера".

ООО))) ну это прям философия программирования)) Эмоционально и насыщенно) Прям дух захватывает когда читаешь))

А вы как думали?? Куда же мы без философии?  ;)  

Вот вам еще одна философия: 

>Моя научная мысль дошла до вывода данных с 6ти портов и их запись в двумерный массив.

Зачем?  Если писалось "Когда с этим разберетесь, тогда будете думать про "как прочитать ОДИН датчик".  Зачем вам сейчас " до сих пор не нашел считывание данных с клавиатуры." и т.п.? Ну вот склепаете вы сейчас какой-то скетч. И не работает. Что дальше? Ждать милости от форума?

Вам, раз вы новичок (хотя и бы и сам начинал с этого), нужно забыть про "массивы, циклы, эксель, остановки, минуты, время и т.п.". Каждый дополнительный элемент - это место где можно "нахомутать". Все вместе - вы получаете "комбинаторный взрыв". Шансы что "заработает сразу" - стремятся к нулю. Если не работает - очень сложно выяснить почему. Так как у вас 10-ти элементов и ни в одном нет 100% уверенности.

Вам нужна "задача минимум". Результат. Увидеть хоть что-то работающие. Пусть и далекое от "конечных хотелок". Дорога в 1000-лье начинается с первого шага. 

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

void setup(){
  Serial.begin(57600);
}

void loop(){
 int val=analogRead(A0); // читаем
 Serial.println(val); // выводим
 delay(1000); // ждем. 
}

Все. Подобный код за час может написать даже самый "нулевый новичок". И понять. Просто дословный перевод "читаем-выводим-ждем". Все прозрачно и понятно. Нахомутать - негде. Если даже нахомутает - то только в синтаксисе. О чем компилятор сообщит.

Да это "не совсем что вы в итоге хотите". Нет остановки через минуту, нет множества датчиков. Зато:

Вы просто глядя на бегущую колонку цифр в Serial Monitor уже можете понять

1. Работает ли датчик вообще. ПРавильно ли подключен (в коде-то вы уже уверены).
2. Хватает-ли частоты опроса. Получается ли "заметить импульсы" (и очень легко ее поменять, посмотреть что будет если чаще замерять, если импульсы окажутся слишком коротки).
3. Нужен ли нам аналоговый пин, или можно перейти на использование цифровых (их и больше, и читать/обрабатывать их легче).

А с вашим кодом. Вот подключите и увидите "одни нули". Что будете делать в этом случае? Куда копать? Железо неправильное, импульсы короткие, слишком часто используем АЦП?

Дальше, переброс в Excell. С чем легче "разобраться освоится". С одной "голой колонкой цифр" или с 6-тью? Которые "рябят в глазах"?

А когда разберетесь с одним датчиком. Построите по нему график. Тогда уже и "отмаштабироваться на 6-ть " можно будет. Только опять-таки, в этот раз вы уже будете уверены и в коде, и в железе и в логике. Если "что-то не заработало", то вы уже знаете что причину нужно искать имеенно "в чем различие между одним и 6-тью". Область поиска проблемы - существенно сужена.

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

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