Video

Основное назначение хедера - это чтобы его содержимое было вставлено на место include, где он вызывается. Хедер не компилируется, а си-файл - компилируется, оттого и нужно тела функций прописывать не в хедерах, а в исходных файлах. Header файлы удобны тем, что их можно перетаскивать из проекта в проект и легко модифицировать в связке с исходным файлом.

Правила, по которым вы обмениваетесь данными (типа - количество бит, количество стопов, скорость, порядок бит в посылке) - это протокол UART, а вот то, «по чему» обмен осуществляется (например - CH340G, RS-…) - это интерфейс. Интерфейс, вроде как принято считать, материальным, а протокол - это неосязаемые правила.

Мастер управляет потом данных на линии. Если мастер хочет получить от подчиненного информацию, то предварительно мастер отсылает на него байт чтения. В рассмотренном примере, подчиненное устройство сразу начинает слать байты, оно просто больше ничего не умеет, как только произошел сигнал сброс-присутствие, DHT11 (или DHT22) "неуправляемо" начинают слать байты. На программном уровне же протокол 1-wire устроен несколько более сложно и в нём есть стандартные (а также индивидуальные для каждого устройства) команды - байты данных, с помощью посылки которых мастер переводит слейва в состояние приема или отправки информации. Вот тут об этом есть подробнее: avr.ru/beginer/understand/1wire?ysclid=lxq0dwxnai70797933.

Здравствуйте. Честно говоря, весь курс (даже два) выложены на канале и доступны бесплатно.

Есть такое мнение, что когда у вас помеха аддитивная (то есть на цифровой сигнал нуля «накладывается» сигнал единицы), в этом случае, подтяжка к питанию предпочтительнее, потому как бОльшую часть времени сигнал будет в высоком состоянии, а в непродолжительном активном состоянии - в низком.

Когда я передаю массив в функцию, я могу передать только адрес его первого элемента (указатель на массив) и в этом случае, у функции нет шансов узнать сколько байт занимает массив, поэтому мне нужно передать ещё и его длину, иначе есть шанс влезть в область памяти, не касающуюся интересующего нас массива. Массив типа строка заканчивается признаком конца строки ‘\0’, а массив вещественных чисел не имеет признака конца, насколько мне известно.

Command byte в случае рассматриваемого датчика - это адрес его конфигурационного регистра, куда мы пишем настройки датчика температуры. В общем же случае - после старта и адреса слева, согласно методике TWI протокола, по линии мастером всегда передается адрес регистра слейва (этих регистров может быть больше одного, например у гироскопа-акселерометра mpu6050 их чёртова уйма), куда мастер будет писать биты (если выставлен признак записи после адреса слейва) или откуда будет читать биты (если выставлен признак чтения после адреса слейва). Короче в данном случае command byte - это либо конфигурационный регистр датчика температуры, либо предельные значения температуры, на которые должен срабатывать датчик. Вот, надеюсь, что стало немного понятнее.

Command byte в случае рассматриваемого датчика - это адрес его конфигурационного регистра, куда мы пишем настройки датчика температуры. В общем же случае - после старта и адреса слева, согласно методике TWI протокола, по линии мастером всегда передается адрес регистра слейва (этих регистров может быть больше одного, например у гироскопа-акселерометра mpu6050 их чёртова уйма), куда мастер будет писать биты (если выставлен признак записи после адреса слейва) или откуда будет читать биты (если выставлен признак чтения после адреса слейва). Короче в данном случае command byte - это либо конфигурационный регистр датчика температуры, либо предельные значения температуры, на которые должен срабатывать датчик. Вот, надеюсь, что стало немного понятнее.

Спасибо!

Да, спасибо.

Перейдите в настройки VSCODE (иконка шестеренки слева внизу в интерфейсе), в строке поиска наберите avr helper, это приведёт вас к настройкам соответствующего расширения. В настройках найдите AVR > HEX > Dump: Enabled и поставьте в этом пункте отметку. Теперь при сборке проекта в папке Build будет создаться output.hex файл.

@@michael_mmk да спасибо все получилось

@@michael_mmk А не могли бы ли вы сделать видео как в проект добавлять сторонние библиотеки ?

Наверное, можно этим циклом for(i = 0…7) обернуть функцию readAdc(i); Ещё - можно сделать прерывание от ацп и когда прочитан один канал, класть номер следующего канала в младшие биты регистра ADMUX.

@@michael_mmk В общем вчера мучался, по итогам сделал функцию adcread(uint8_t channel) с переменной восьмибитной, в нее запихнул запуск преобразования, ожидание окончания и чтение результата. а уже в майне просто создал переменный соответствующие каналам adcresult1=adcread(1) и так со всеми каналами, и просто вывожу их на дисплей, незнаю насколько это правильно или быстродейственно. пока только начла изучать все. Осталось только прилететь домой и в железе проверять. Пилите еще ролики! у вас очень классный материал! если бы у вас был фулл курс я бы купил его!

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

Давайте попробуем разобраться. Пусть есть файл типа common.h и в нём код: 1 #ifndef COMMON_H_ 2 #define COMMON_H_ 3 #include <avr/io.h> 4 #include <utils/delay.h> 5 uint16_t findMiddleValue(uint16_t a, uint16_t b, uint16_t c); 6 #endif Подключаем этот файл в main.c и, например, в ещё одном .c файле, где нам это требуется. Каждое подключение (директива #include "myHeader.h") занимает процессорное время. Когда мы подключаем common.h, мы же заинтересованы в том, чтобы иметь возможность обращаться к частям "хедеров" avr/io и utils/delay, а также иметь возможность находить среднее значение из трёх переменных с помощью функции findMiddleValue(). Возникает вопрос - если мы уже однажды подключили common.h - надо ли нам тратить процессорное время на повторное подключение этого файла, учитывая, что его содержимое не изменилось? Ответ - наверное, нет. Второй вопрос - должны ли мы сами следить за подключениями? Ответ - наверное, тоже нет. Мы должны писать программу и подключать всё, что нам требуется в каждом файле (программист - не компилятор). Компилятор должен нам помочь в экономии процессорного времени, но мы должны "сказать" ему о том, что нам нужна здесь помощь. А теперь - суть. В момент, когда мы впервые подключили common.h мы проверяем не задефайнено ли значение COMMON_H_ (мы сами придумали эту запись; обратите внимание, что мы не пишем #define COMMON_H_ 100, мы просто "декларируем дефайн"), и если оно не задефайнено, мы его дефайнем и делаем все строки, начиная с третьей и заканчивая пятой, после чего идёт endif. Если мы после этого опять пытаемся подключить common.h, то мы опять натыкаемся на условие #ifndef, только в этом случае оно будет ложно (COMMON_H_ уже задефайнен) и мы, экономя процессорное время, прыгаем на сроку, после шестой в коде выше.

@@michael_mmk Теперь стало более понятно, спасибо за развернутый ответ.

Метод выглядит рабочим, VSCODE ни на что не ругается. Если нужно передать не просто абстрактный адрес (вот на это IDE ругается, потому что не факт, что по прописанному адресу что-то есть и не факт, что я обращусь к области памяти, которая мне не предназначается), а адрес конкретной переменной, то пишем просто int* memAdr = &myVar; (myVar тоже int) В этом случае будет возможность передавать адрес myVar, сравнивать его с какими то значениями и класть по этому адресу что-то.

@@michael_mmkну я сделал чуть по другому, я все адреса в дефайн запихнул, а где нужно просто присваиваю его указателю)

Спасибо. Скорее всего, я всё-таки имею ввиду "чАстоту сигнала", когда говорю о периодических сигналах. Вместо слова "чистота" я бы в своих записях использовал слово "помехозащищённость" или вариации слова "фильтрация".

Спасибо, но я просто преподаватель, до кандидата наук мне далековато.

@@michael_mmk главное поставить цель

Можно ещё такой экран использовать - roboshop.spb.ru/display/simvolnye-displei/lcd-0802-green - он тоже символьный, но общается по TWI протоколу.