Вольтметр из Ардуино, делюсь опытом с Котами

[FantasyDD]

Решил поделится своим вольтметром с Котами.
Скетч проще не придумать, мерим напряжение на A0, можно поставить делитель два резистора в программе (SETUP) скорректировать (входное число с порта делим) input/ 20 можно скорректировать погрешность 20,0003 (20 выходит на входе делитель 1 к 20).
Указать минимальное 0 и максимальное значение шкалы .
Прошить скетчем с архива.
И все.

[FantasyDD]

[YS]

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

Зачем заводить отдельную переменную для номера пина (тем более, если не собираемся менять номер в процессе выполнения программы)? Она будет висеть в памяти, растрачивая ее попусту. Слово "const" тут бесполезно - архитектура AVR Гарвардская, и если мы просим компилятор завести переменную, он заведет ее в оперативной памяти. Не знаю, может новые версии GCC (а Ардуино использует GCC) уже научились это оптимизировать, но вряд ли. Тут дело все же в особенностях адресного пространства.

Правильно было бы написать что-то в духе

Код: Выделить всё

#define ANALOG_INPUT_PIN         A0

Второе. Использовать платформозависимые типы не стоит. Вы знаете, например, что int на AVR (при компиляции с помощью GCC) имеет размер 16 бит, а не 32, как на x86? Умные люди давно придумали stdint.h.

Зачем использовать знаковую шестнадцатибитную переменную там, где достаточно беззнаковой восьмибитной? В последних двух битах десятибитного АЦП у AVR в основном шумы. Вы не применяете ни калибровки, ни оверсемплинга, чтобы это исправить, так что лишние биты бесполезны.

Зачем использовать println, бесполезно преобразуя число в текст, а потом обратно в число (на стороне ПК)? Это только раздувает прошивку (и замедляет ее выполнение), не давая никакой пользы.


В общем, скетч - сборник типичных ардуиновых грехов.


Ниже привожу код скетча для интересующихся, но не желающих качать архив.

Спойлер

Код: Выделить всё

const int analogInPin = A0;  // Analog input pin 

int  sensorValue = 0;        // value read from the pot     

void setup() {
  // initialize serial communications
  Serial.begin(256000);
}

void loop() {
  // read the analog in value:
  sensorValue = analogRead(analogInPin);         
  // print the results to the serial monitor:                    
  Serial.println(sensorValue);  
  //delay(500);                    
}

[Morroc]

Да вы издеваетесь Зачем использовать вилку с 4-мя зубцами если достаточно 2х, а некоторым даже китайских палочек ? Использовать ардуину в качестве ацп с uart изначально жирно, тут скорее компьютер надо "оптимизировать"... прям совсем, подцепив какой нибудь симпатишный графический дисплей.

[FantasyDD]

Очень приятно услышать отзыв, код для ардуино я просто нашел.
Это второй скетч который я загрузил в ардуину, первый скетч поморгал светодиодом
Много интересного нашел на вашем сайте, решил подружится с вами.

PS
Можно не только вольтметр соорудить можно термометр, программа имеет прикладное значение.
exe читает цифры с ком порта и отображает их в стрелочноосцилографическом формате

[Vga]

Она будет висеть в памяти, растрачивая ее попусту.

Это С++, детка. Оптимизатор вышвырнет переменную на мороз, и слово const сильно облегчит ему эту задачу.
Собственно, вот что выдает компилятор:

Спойлер

Код: Выделить всё

Disassembly of section .text.loop:

00000000 <loop>:
   0:	8e e0       	ldi	r24, 0x0E	; 14
   2:	0e 94 00 00 	call	0	; reloc: analogRead
   6:	bc 01       	movw	r22, r24
   8:	90 93 00 00 	sts	0x0000, r25 ; reloc: .bss.sensorValie+1
   c:	80 93 00 00 	sts	0x0000, r24 ; reloc: .bss.sensorValue
  10:	80 e0       	ldi	r24, 0x00	; reloc: Serial
  12:	90 e0       	ldi	r25, 0x00	; reloc: Serial
  14:	4a e0       	ldi	r20, 0x0A	; 10
  16:	50 e0       	ldi	r21, 0x00	; 0
  18:	0e 94 00 00 	call	0	; reloc:  _ZN5Print7printlnEii
  1c:	08 95       	ret

Как видно, переменной analogInPin нету, а вот не-константная глобальная analogValue никуда не делась.
Впрочем, задавать константы как const в С/С++ и правда не принято. Но и дефайн - плохо. Для числовых типов лучше использовать enum:

Код: Выделить всё

enum{analogInPin = A0};

stdint, конечно, использовать стоит. Но в данном случае использование однобайтовой переменной только увеличивает размер скомпилированного кода функции. Правда, использование uint8_t или uint16_t сокращает скетч в целом примерно на 100 байт - вероятно, это связано с функцией Serial.println.

Впрочем, в данном случае переменная не нужна вообще и тем более не нужна глобальная. Достаточно написать:

Спойлер

Код: Выделить всё

enum{analogInPin = A0};  // Analog input pin 

void setup() {
  // initialize serial communications
  Serial.begin(256000);
}

void loop() {
  // read analog value and print it to the serial monitor:                    
  Serial.println(analogRead(analogInPin));  
  //delay(500);                    
}

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

P.S. Впрочем, любые оптимизации скетча, который тратит менее 2.5кб из минимум 6, доступных на ардуино (и то, ардуину на меге8 ныне поди найди, обычно 16-32кб) - бессмысленное занятие. Нет никакой разницы, будет память занята ненужными данными или просто рандомным и столь же ненужным мусором. Актуально это станет только при расширении функциональности скетча.

[YS]

код для ардуино я просто нашел.

Тогда мне не совсем понятно название темы. Каким опытом вы делитесь?

решил подружится с вами.

Это радостно. Вливайтесь в форум, будут вопросы - задавайте, будут ответы - отвечайте.

Это С++, детка. Оптимизатор вышвырнет переменную на мороз, и слово const сильно облегчит ему эту задачу.

Я бы не сказал, что это как-то связано именно с C++. Просто GCC в данном конкретном случае оказался немного умнее, чем я думал.

не-константная глобальная analogValue никуда не делась.

Гм, странно.

Но и дефайн - плохо. Для числовых типов лучше использовать enum:

Дефайн - нормальный, удобный и признанный способ задавать все, что угодно. А enum нужен совсем для другого.

Я уже не говорю о том, что элементы enum по умолчанию имеют тип integer, и попытка задать, скажем, unsigned long провалится. Так что нет, константы надо задавать дефайнами. Это спасет от головной боли.

Дефайны - очень мощный инструмент Си.

Нет никакой разницы, будет память занята ненужными данными или просто рандомным и столь же ненужным мусором.

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

[FantasyDD]

Тогда мне не совсем понятно название темы. Каким опытом вы делитесь?

Опытом подключения микропроцессора к компьютеру по управлением windows, простой обработкой и отображением информации.
VoltMeter написан мной на Delphi думаю он будет полезен.
Этот сегмент был для меня очень важен (передача информации большому брату для последующей обработки).

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

[YS]

VoltMeter написан мной на Delphi думаю он будет полезен.

Так а исходники-то где тогда?

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

Оптимизация важна по моему мнению только при необходимости

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

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

[Morroc]

Только иногда до маразма доходит в БД как раз - поля под название организации по 30 символов, идентификаторы числовые с ограничением разрядности (лишние проблемы с переносом данных), таблицы так "занормированы", что запросы по таймауту минут в 10 отваливаются - приходится дублировать поля и включать в индексы (хотя когда я такое увидел первый раз - сильно удивился - нафига... база стала >>100 гб и понял нафига). Ну т.е. оно вроде как оптимизировано, но как то по объему, что требуется далеко не всегда.

[kalobyte]

Дефайн - нормальный, удобный и признанный способ задавать все, что угодно. А enum нужен совсем для другого.

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

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

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

VoltMeter написан мной на Delphi думаю он будет полезен.

разве сегодня кто-то пишет на дельфи? уже .нет 4.5 вышел и 5 зарелизили, да мелкасофт открыла исходники и под линупс вроде портируют или уже портировали

ну как альтернатива - qt, а так - просто школьное поделие как у меня лет 10 назад и исходников нет
так что скетч чужой и тот кривой, твоих исходников нет - полезность твоей темы 0

[FantasyDD]

Коты не кидайте камнями

Претендовать на авторство 5 строчек кода сложно! Это я про скетч. Там нет авторства там показана идея.
Мне понравилось выражение "под Делфи не кто не пишет" потом "где исходники".

Исходник вышлю любому по запросу на майл, но предупреждаю писано без комментариев и с пользованием коммерческих компонент + своих библиотек, это есть RAD, минус в сложности переноса(среду придется настраивать по моему, с моими библиотеками компонентами и и под определенную версию. Если конкретно то под XE6).

Господа Коты прекратим холивар не то сюда сбегутся Коты со всех форумов

[Vga]

Я бы не сказал, что это как-то связано именно с C++. Просто GCC в данном конкретном случае оказался немного умнее, чем я думал.

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

Гм, странно.

Это, как раз, понятно, если понимать как работает компилятор.

Дефайны - очень мощный инструмент Си.

И порождающий кучу проблем. Поэтому пользоваться им следует только там, где другими средствами сделать требуемое нельзя.
Кстати, я был неправ. Для С++ константы задаются как const type varname, т.е. в приведенном скетче все сделано правильно. Для С это не применимо, поэтому там используются enum'ы для чисел и макросы для всего остального. Но ардуино - это С++.

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

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

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

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

если можно не использовать больших библиотек - их не надо использовать

Это не столь однозначный вопрос. Очень сильно зависит от задач и конкретного случая.
Но если библиотека проверенная и широко используется - лучше взять ее, чем писать свой велосипед, который будет глючным и медленным.
Недавний пример - ковырял код первой ревизии гита. Он подключает libopenssl только ради расчета SHA1. А все потому, что в openssl эта функция проверенная и вылизанная по производительности.
Другой пример - некоторые вещи намного сложнее, чем кажутся. Например, различные велосипеды для разбора XML регулярно падают на корректных файлах из-за того, что их автор не учел какой-то момент синтаксиса.
С другой стороны - врядли есть смысл подключать библиотеку вывода на 44780 от Васи Пупкина.

[YS]

Исходник вышлю любому по запросу на майл

А чего так не выложить-то, чтобы все могли оценить качество кода? Ведь тему обычно начинают, чтобы получить совет. Как минимум, Vga, например, собаку съел на паскалеподобных языках (и не только) и наверняка мог бы дать ценные комментарии.

Иррациональная нелюбовь к Си не делает его менее здравомыслящим программистом - программирование Си не кончается. Я вот, например, Pascal не люблю. Правда я, в отличие от Vga, никого не учу, как "правильно" писать на том языке, который сам считаю косым и неудобным...

но на интуитивном уровне я ощутил, что про енум он сказал херню

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

Кстати, простой пример, когда не-макро константа принципиально не решит проблемы:

Спойлер

Представим, что у нас в коде есть переменная (или несколько), которую (которые) надо инициализировать. Ну мы и пишем:

Код: Выделить всё

#define X       100

...

var=X;

А теперь представим, что мы подцепили к нашей системе memory-mapped EEPROM, и теперь хотим скомпилить код в варианте, который читает начальное значение переменной из этой самой EEPROM по адресу 100500. Берем и пишем:

Код: Выделить всё

#define X       (*((uint8_t *)(100500UL)))

...

var=X;

Поменяли программу в одном месте, и все переменные, которые инициализировались значением X, стали инициализироваться значением из EEPROM.

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

Код: Выделить всё

#define X       ((mode==READ_FROM_EEPROM)?(*((uint8_t *)(100500UL))):(100))

...

var=X;

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

разве сегодня кто-то пишет на дельфи?

Вы не поверите...

[Vga]

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

Потому что ты его и не знаешь. Я же работал с С/С++ и зачастую знаю его лучше тех, кто на нем пишет. Не буду преувеличивать - С я знаю плохо. Просто большинство тех, кто на нем пишет - не знают С вообще.

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

Не совсем. Он должен компенсировать недостатки человека (невнимательность, склонность к ошибкам) и избавлять от рутины. Но советы я даю исходя из практик программирования на С/С++ - ясен пень, что подходы Паскаля или Идеального Языка Программирования в С ничего не дадут.
И это именно сишная практика - использовать перечисления для числовых констант. Да, они предназначены не для этого - но и макросы, в целом, предназначены не для этого. Так что приходится выбирать, каким из имеющихся средств реализовывать недостающее (т.к. констант этом понимании в С нет). enum'ы решают проблему для числовых констант, при этом не имея такого числа побочек, как макросы. Все остальное приходится делать макросами.
В С++ изменили понятие const, так что там для задания констант предназначено именно ключевое слово const.

Кстати, простой пример, когда не-макро константа принципиально не решит проблемы

Для чего угодно можно придумать пример, в том числе и для "ужасного" goto. Вот только на практике в 99.(9)% случаев это не надо. А когда таки надо - можно заменить enum{X=100} на тот самый макрос. Я не призываю не использовать макросы вообще. Просто не надо использовать их там, где в них нет нужды.
Ну и да, в С++ приведенный код отлично реализуется без макросов без потерь в оптимальности машинного кода.

[YS]

Спойлер

Я же работал с С/С++ и зачастую знаю его лучше тех, кто на нем пишет.

Утверждение, мягко говоря, сильное. Но ладно, я поверю на слово. Может Vga вообще коммиты в GCC делал (на Паскале, надо полагать) и знает Си изнутри. Я же не знаю. Я всего лишь пишу на Си для встроенных систем, да и пишу совсем недолго, ну, лет семь максимум. Да и образования программистского у меня нет.

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

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

enum'ы решают проблему для числовых констант

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

***

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

[Vga]

Спойлер

Утверждение, мягко говоря, сильное. Но ладно, я поверю на слово.

Мне регулярно приходится объяснять пишущим на С их собственный язык. В том числе основы, вроде "почему я написал в хедере static int foo и теперь у меня линкер ругается". Иного вывода, чем то, что эти люди не знают язык, на котором пишут я сделать не могу.
Остается только посокрушаться о том, как много ламеров среди программистов на С.
Конечно, ты знаешь язык намного лучше этих людей. Но с другой стороны, я знаю, почему AnalogInPin компилер выпилил, а sensorValue - нет, а ты этому удивляешься.

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

Как ни странно, хоть я и пасквилянт, но я немало изучал и тему того, как правильно писать на С. В том числе и потому, правда, что многое применимо и к Delphi. Забавно, но острая нелюбовь к С и С++ появилась именно при этом, когда я изучал основы языка - все казалось простым и красивым...

Как я уже показывал выше, не всегда, не для всех.

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

[Morroc]

Вы тут такую жесть пишите, а в теме ключевое слово "Ардуино", что должно как бы намекать

[kalobyte]

Вы тут такую жесть пишите, а в теме ключевое слово "Ардуино",

так весь срач и начался со скетча

как по мне, то енумы нужны для автоматической разметки числовых констант
например можно писать
define a 1
define b 2
define с 3
и использовать их в тех же switch case

а можно просто сделать
enum {a, b, c} и насрать там какие числа будут, главное привязаться к буквенному образу состояния switch
собственно вот тут пример http://we.easyelectronics.ru/Soft/gener ... c.html#cut

с дефайнами тупо возни больше и засирают мозги незначащими числами

Исходник вышлю любому по запросу на майл

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

Вы не поверите...

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

а если по гитхабу, то вон справа https://github.com/trending
напрямую по дельфи не ищет, надо политкорректно просить Component Pascal

[Vga]

как по мне, то енумы нужны для автоматической разметки числовых констант

Так и есть. Но за неимением в С констант их приходится делать другими средствами, подходящих всего два - enum и #define.

а так в европах что-то я не вижу вакансий для дельфи

Один мой знакомый программист на Delphi нанялся Altium писать. Так что пишут, вполне. Хотя и редко. Скайп, кстати, на нем же писан - или на его ближайшем родственнике C++ Builder. И многие другие до сих пор развивающиеся программы.
Кроме того, сама Delphi из стагнации нулевых выходит. Embarcadero активно пилит новые версии, вводит долгожданные фичи вроде поддержки новых платформ. Другой вопрос - не поздно ли спохватились...

напрямую по дельфи не ищет, надо политкорректно просить Component Pascal

Component Pascal - совсем другой язык. Delphi - с версии 7 так и называется, ранее назывался Object Pascal. На гитхабе она, вместе с прочими вариантами паскаля находится в разделе Pascal.

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

+1