Arduino.ru

Ты, в своей категоричности, тоже традиционен, и порой - без смысла ;) Отказ чего-либо принимать/понимать - не значит бессмысленность этого ;) Про первичный смысл разделения на заголовочные файлы и файлы с реализацией - я уже писал, если ты не заметил. Первичный смысл - это удобный и быстрый доступ к API, которое предоставляет тот или иной набор исходников: заметь, на несколько *.cpp-файлов может быть всего один *.h-файл ;)

Для меня (да и не для меня одного) - гораздо удобнее взглянуть на объявления, чтобы понять, как работать с этим добром. А уже при необходимости - в исходнички залезать. С#, кстати, отсутствием объявлений и вымораживает - в большой простыне хер соберёшь в кучку описание функционала, предоставленного исходником.

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

*пример из жизни: чел - отличник по физике, победитель республиканских олимпиад по физике купил аудиокабеля для своей аппаратуры по 100$ за погонный метр. когда я ему сказал, что он-дыбил и у него по физике в школе была твёрдая тупая тройка - оказалось, что я жестоко неправ. когда ему на на его глазах за полчаса спаяли кабель себестоимостью 10$, то на слепом аудио-тесте - он оказался жестоко не прав. и, мы оба задумались.

Вот тут-то как раз я с тобой согласен на 100500%.

Очень не всегда так. Зависит от распределения вероятностей. Общеприменимое (когда думать не хочется и исходных данных нет;) скорей статобработка - считаем СКО, три сигмы, отбрасываем что невписалось и снова считаем. Это для нормального распределения.  Для каждого  конкретного случая свой подход. Иногда и по первому большому значению нужно хватать кота и бежать, т.к. до конца цикла обработки уже некому будет решение принимать. (Пример - контролируем напряжение в цепи постоянного тока на предмет аварии при превышении порога допустим 24В, решили брать некое среднее, но в цепь попало 220В 50Гц, среднее 0, защита не сработала. А работали бы по мгновенному напряжении, то сработала бы.).  Медианное среднее - один из вариантов, а их вобще много. Добавлю для расширения кругозора еще и геометрическое среднее и фильтр Кальмана.

ПС. Когда данные поступают поочередно и с интервалами, лучше сортировать их по мере поступления, поддерживая массив отсортированым все время.

Ну вот как с вами трезвому жить?  

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

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

так, нафига ты написал про инклюды кпп и ха, если должен был писать про классы?, классы, Карл!

классы для дуино и детей - это вот это:

class test {};

void setup() {}

void loop() {}

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

Клапа, не злись, мы тя сиравно любим.  Описание класса мне куда-то пхать надо?  В проект? Дак нет, я щитаю надо учится сызмальства парадигме, что каждому классу - свое укрытие.  Иначе, несчастный .ino файл догонит и перегонит Войну и Мир по размерам. 

В след. серии будем размахивать Ржавой Секирой Ужоса, то есть millis()-а над головами незадачливых пользователей. 

шозанах - проект?

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

приехали. а, что, по твоему, инклюд файла класса делает, если не дописывает текст кода в ino перед компилляцией? ты кого собрался обмануть малым объёмом кода ino - детей или компиллятор?

дети будут понимать, почему 10 строк в ino не помещаются в контроллер.

правильно, красиво, спасибо, но для небольших проектов сложно и много писать :)

ЗЫ. С молодости не люблю классы....бр.....бяка :)

ЗЫЫ. Вспоминаю соседа по общаге в середине 90х, попросили его на Turbo Pascal написать какую то примитивную лабу из пары действий, так он умудрился из программы длиной максимум строк 20 написать целый проект через классы строк на 100 минимум, делающий то же самое. Естественно вопрошающий не сдал, т.к. не смог объяснить как это все работает.

Ну так вот - еще одна польза от применения классов.

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

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

естесственно, это будет написано дальше, в секции про устойчивость класса. 

int TSensor::Read(void)
{

  unsigned long now = millis();  // прочитаем время на сейчас
  if (now - flasttime < 2000) return fvalue;
...
  flasttime = now; // запомним время, когда мы последний раз читали 
..
}

Семен, тебя квон покусал что ли - на millis() экономишь...

В данном случае обращение к датчику будет происходить не раз в 2000 мс, а раз в 2000-<время на всякую фигню внутри if> мс. А если учесть, что внутри if() ты читаешь датчик, то он всяко будет опрашиваться чаще, чем раз в заданное время. Конечно это, скорее всего, будет быть снивелированно другими операциям вне процедуры чтения, но ржавое ружьё иногда и палит посреди ночи.

16 вызовов analogRead() на 328 Меге 16 Мгц выполняются ~2 мс.  Критичненько? Я же не звездолеты строю и не осциллографы реального времени, где за каждый такт надабароца, я такого пока и не осилю.  Мои поделки простые, как я. А в них и классы простые. 

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

Я не завожусь, не подумай плахова. :)

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

int TSensor::Read(void)
{

  unsigned long now = millis();  // прочитаем время на сейчас
  if (now - flasttime < 2000) return fvalue;
...
  flasttime = now; // запомним время, когда мы последний раз читали 
..
}

Вы фигню писать изволили. Как раз  приведеный код обеспечит время между чтениями не менее 2000мс. Т.е. равно и более 2 сек.  Для обеспечения времени в среднем 2000 пишем flasttime += 2000;.  И уж совершенно пофиг до или после чтения. Про экономию: а чё не так?! Экономить - не транжирить, к разорению не ведет. Я бы для экономии еще лонгинт убрал везде, там и инта с головой. И миллис бы один раз в начале лопа вызывал, сохранял бы и передавал бы всем заинтересованым.

Прогоните:

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

void loop() {
  uint8_t processSomething = 0;
  uint32_t now, flasttime, sensorPrevReadingTime, sensorRestTime;
  flasttime = sensorPrevReadingTime = millis();

  while (true)
  {
    now = millis();  // прочитаем время на сейчас
    if (now - flasttime < 2000) continue; // return fvalue;

    processSomething++;
    if (3 <= processSomething) {
      delay(1000);
      //Serial.print("Process something");
      processSomething = 0;
    }

    // int result = 0;

    sensorRestTime = millis() - sensorPrevReadingTime;
    Serial.print("Sensor polled after: "); Serial.print(sensorRestTime); Serial.println(" ms");
    sensorPrevReadingTime  = millis();

    flasttime = now; // запомним время, когда мы последний раз читали
    //flasttime = millis();

    // fvalue    = result >> 4; // и запомним, что прочитали при этом
    // return fvalue; // ну и то, что прочитали, то и отдадим.
    
  }
}

sadman, я то понимаю, что ты прав, я же запоминаю now ДО чтения, а у Логика с логикой проблемы. Но он это никада не признает. 

Люблю конструктивный подход !

Прогнал.

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

void loop() {
  uint8_t processSomething = 0;
  uint32_t now, sensorPrevReadingTime, sensorRestTime;
  int flasttime;
  flasttime=sensorPrevReadingTime = millis();

  while (true)
  {
    int now = millis();  // прочитаем время на сейчас
    if (now - flasttime < 2000) continue; // return fvalue;
Serial.print("now="); Serial.print(now);
Serial.print("delta="); Serial.println(now - flasttime);
    processSomething++;
    if (3 <= processSomething) {
      delay(1000);
      //Serial.print("Process something");
      processSomething = 0;
    }

    // int result = 0;

    sensorRestTime = millis() - sensorPrevReadingTime;
    Serial.print("Sensor polled after: "); Serial.print(sensorRestTime); Serial.println(" ms");
    sensorPrevReadingTime  = millis();

    flasttime = now; // запомним время, когда мы последний раз читали
    //flasttime = millis();

    // fvalue    = result >> 4; // и запомним, что прочитали при этом
    // return fvalue; // ну и то, что прочитали, то и отдадим.
    
  }
}

Не чувак, у меня проблема с тупыми мнящими из себя фигзнает что, вместо того чтоб учится. См пост выше.

ПС. Неужели трудно осилить что

A=B

и

некоторый код не изменяющий А и B и не передающий управления куда либо
A=B

обеспечат на выходе одинаковое А при том же В на входе. 

Время чтения 16 раз analogRead() и взятия среднего - 2 мс.  значить, время опроса самого датчика

2000 мс - 2 мс. = 1998 мс.  

Нет конечно. Просто взятие среднего завершится на 2мс позже чем сработало условие завершения интервала. И так каждый цикл. Сработало условие ровно через 2сек, пошол опрос рсачет среднего и завершился через 2мс. И между этими завершениями сново будет 2 сек. В первый коде время скачет т.к. делей еще и под ифом, иногда  в цикле он есть, иногда нет. Вы конечно дико удивитесь, но даже в таком случае среднее время опроса всеравно останется 2 сек )))

Коментируем  if (3 <= processSomething) и о чудо!

Я и он про то, что время между последним analogRead() прошлого цикла и первым analogRead() текущего цикла = 2000 - 2. Значит пин начинает читаться чаще, чем 2000 мс.  Только и всего. 

Если сделать так 

То точно пройдет время НЕ МЕНЬШЕ 2000 мс  между реальными обращением к пину. 

И это.  Извини, если обидел, я так больше не буду.  Сонный был. 

Та какие там обиды, проехали.

А я в #69 писал про два случая: НЕ МЕНЬШЕ и В СРЕДНЕМ. Это уже кому когда где что надо.  Еще обращу таки внимание что в примерах выще int вместо long int прописан. Экономия по мелочам, тут 100гр, там 100гр, а в итоге скетч влазит в память. 

А на вашем месте я бы про эти 2мсек чтения обработки вобще бы не вспоминал на фонее периода 2000. Дело в том что в большом скетче с прерываниями и крупными кусками кода обеспечить прокрутку лопа не реже 1мсек, чтоб сформировать точно 2000, очень сложно. Период будет плясать +-5мсек (и это еще очень хороше, может и 10 и 20 а с кривыми руками и 200 и более). На этом фоне те 2мсек не заметны. Если нужна реально высокая точность - прерывания таймера помогут.

Я на этот счёт вапще не парилса, я не Громозека, мне пофиг, 400 капель у меня налито, или 402

/**/
unsigned long mill; // переменная под millis()
typedef void (*pDo)() ;// тип -функция обработчик
//--------------------------------
// класс сенсор
class Cl_sensor {
  protected:
    const byte pin;
    const unsigned long inteval = 2000;
    unsigned long past;
    int val;
  public:
    /*конструктор*/
    Cl_sensor(byte p):  pin(p)  {}
    /*инициализация-вставить в setup()*/
    void init() {
      val = analogRead(pin);
      past = mill;
    }
    /*работа-вставить в loop()*/
    void run() {
    }
    /*прочитать значение с сенсора*/
    int read() {
      if (mill - past < inteval) return val;
      past = mill;
      return val = analogRead(pin);
    }
};
//--------------------------------
// класс вьювер
class Cl_viev {
  protected:
    pDo Do;//обработчик
    const unsigned long interval = 500;
    unsigned long past;
  public:
    /*конструктор*/
    Cl_viev(pDo D):  Do(D)  {}
    /*инициализация-вставить в setup()*/
    void init() {
      Do();
    }
    /*работа-вставить в loop()*/
    void run() {
      if (mill - past < interval) return;
      past = mill;
      Do();
    }
};
//---Компоновка-----------------------------
Cl_sensor Sensor(/*пин*/A0);
void DoViev() {
  Serial.println(Sensor.read());
}
Cl_viev Viev(/*обработчик*/DoViev);
//---main-----------------------------
void setup() {
  Serial.begin(9600);
  Viev.init();
  Sensor.init();
}

void loop() {
  mill = millis();
  Viev.run();
  Sensor.run();
}
/*Скетч использует 2104 байт (6%) памяти устройства. Всего доступно 32256 байт.
  Глобальные переменные используют 211 байт (10%) динамической памяти, оставляя 1837 байт для локальных переменных. Максимум: 2048 байт.
*/

Я понял, что увидел в посте Logic - симптомы дислексии. Все слова он узнал, а смысла написанного не понял.

Кстати, мне ведь 2мс не жалко. Обидно будет, когда люди по такому алгоритму будут читать что-то типа DHT или датчика с долгим временем конверсии. Вроде все работает, потому что остальные операции нивелируют, затем какой-нибудь деб... новичок ставит рядом два вызова функции readSensor() - один для чтения в переменную, а второй - для вывода на дисплей, а в if() появляется что-то с непредсказуемым временем выполнения - к примеру невовремя происходит вызов прерывания с каким-нить delayMicroseconds() внутри и готово дело. Несчастный жрет водку, плачет, попутно засерая окрестные форумы и тщетно пытается понять, почему температура 10 дней отдается нормальная, а потом хренак - и прыгает до небес. И, если у него ардуина не запустила газовый котел в экспедицию на Марс, то начинается замена сенсоров, перепайка, проверка неделями... Стоит эта круговерть одного лишнего вызова millis()?

sadman, я тебя понял, исправлю завтра. 

Справедливости ради надо отметить, что DHT и прочие Далласы к классу аналоговых датчиков нихрена не относятся, но дальше, когда я буду виртуалить Read(), это может быть критично.  Thanx. 

Тока срачица не нада. 

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

Читай свой пост:

Выделено мной. Но ты требование "раз в 2000 мс" сам озвучил. 

И смотри вывод скетча

now=2000delta=2000

Он про него вспомнил т.к. време конверсии большое, до 750мсек. Некоторые идиоты его делеем формируют. Вобщем обсуждение кода слабоумных там.

Не дурно. указатель на функцию - правильно. Хотя наследованием в ООП правильней, но я чаще указатель на функцию пользую. Только зачем его вюеру передавать? Лучше у сенсора вместо/вместе с сохранением введеного сразу вызывать некую функцию-потребитель данных, переданую указателем в конструктор совершенно аналогично. И пусть она там дальше думает что делать с данными. Это уже не сенсора проблема.  Мможет выводить или еще чего. Там тоже свои классы и указатели будут;) 

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

Если завтра - то только через абстрактный метод принимаю ;)

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

Я написал в свой традиционной системе событийного программирования. Но если бы к своему новому пониманию, то текст был бы таким

/**/
unsigned long mill; // переменная под millis()
typedef void (*pDo)() ;// тип -событие
//--------------------------------
// класс сенсор
class Cl_sensor {
  protected:
    const byte pin;
    const unsigned long inteval = 2000;
    unsigned long past = 0;
    int val;
  public:
    /*конструктор*/
    Cl_sensor(byte p):  pin(p)  {}
    /*прочитать значение с сенсора*/
    int read() {
      if (mill - past < inteval) return val;
      past = mill;
      return val = analogRead(pin);
    }
};
//--------------------------------
// класс вьювер
class Cl_display {
  protected:
    pDo Do;//событие
    const unsigned long interval = 500;
    unsigned long past;
  public:
    /*конструктор*/
    Cl_display(pDo D):  Do(D)  {}
    /*вывести на экран)*/
    void viev() {
      if (mill - past < interval) return;
      past = mill;
      Do();
    }
};
//---Компоновка-----------------------------
Cl_sensor Sensor(/*пин*/A0);
void eventA() {
  Serial.println(Sensor.read());
}
Cl_display display(/*событие*/eventA);
//---main-----------------------------
void setup() {
  Serial.begin(9600);
}

void loop() {
  mill = millis();
  display.viev();
}
/*Скетч использует 2048 байт (6%) памяти устройства. Всего доступно 32256 байт.
  Глобальные переменные используют 211 байт (10%) динамической памяти, оставляя 1837 байт для локальных переменных. Максимум: 2048 байт.
*/

Можна конечно и так, но я имел в виду не это. В конструктор сенсора добавте pDo D, но pDo с параметром как  typedef void (*pDo)(int v).  А из сенсоровского read() сразу и Do(analogRead(pin)); Вызов конструктора станет Cl_sensor Sensor(/*пин*/A0, eventA); Это оч. символично - в конструкторе первый параметр "откуда взять", а второй - "куда отправить".

А можна и еще интересней! ;) 

Модератору, если позволите продолжать,  то просьба перенести эту графоманию в "Отвлеченные темы".

Подскажите какую нибудь литературу, с классами по Ардуине.

В гугле видать забанили меня или искать не умею, все с готовыми скетчами нахожу,читаю Лафоре, но чистый С++ не компилируется

NalisniyRoman, заканчивайте искать в твитере и читайте основателя С++  http://8361.ru/6sem/books/Straustrup-Yazyk_programmirovaniya_c.pdf

Ну и мои зарисовки http://arduino.ru/forum/programmirovanie/klassy-arduino-po-qwone-dlya-chainikov

Это как это?

скорей всего пишу неправильно,пытался пример со счетчиком переделать,но рано наверное в дебри полез. С реальными объектами, кнопками, получалось под себя подстроить, со счетом никак пока

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

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

Я тебе открою секрет - никаких "классов для ардуино" - нет. В Ардуино используется полноценный C++. Все примеры, что ты находишь в учебнике про классы С++ - должны компилироваться и на ардуино. Если у тебя не компилируется - значит просто у тебя код с ошибками, он не будет компилироваться и на "обычном С++". например в линуксе

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

Я правильно понял, что по сути на cpp пишем асмовские инструкции для ардуино?

неправильно, АСМ-овских инструкций в большинстве ардуиновских скетчей и близко нет.

Редко-редко где-нибудь попадется кусок, написанный на асме - обычно не больше 10-20 строк. И только там. где нужна адская производительность и С не справляется.