Срач разводите вы, не сумев принять новую для вас информацию.

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

Мурато Мяуконни, я работаю с реальными копонентами, а не с вашими советами.
Так понятно?

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Типичный бред ардуинщика, скачавшего чужой скетч.

Спойлер

Если у вас ума хватит - надеюсь, вы прекратите срач в этой теме.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

можно в порядке полуоффтопа выскажу своё мнение?

с моей т.з. существует общий, максимально общий, охватывающий абсолютно все случаи жизни, подход в выборе решений: если есть один способ, дающий 100% результат в любых условиях, именно он и является наиболее предпочтительным. почему? да потому, что полностью избавляет от необходимости задумываться об отклонениях.

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

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

так и с ЖКИ. есть метод, который с любым дисплеем, в любых услвиях, гарантированно дает положительный результат - это работа с контролем занятости контроллера ЖКИ. т.е. разработав соответствующую "библиотеку" можно вообще не беспокоиться о том, какой дисплей какие задержки обеспечивает, достаточно удостовериться, что он придерживается принятого протокола обмена. и абсолютно не стоит переживать, 40 мкС у него цикл или 43 или 37 или 98 вдруг. понимаете? раз - и навсегда.

если у вас в программе задержки (независимо от способа их формирования - циклы, таймеры или еще что), то при любых отступлениях от типа ЖКИ, для которого код проверен, вы обязаны удостовериться, что ваши задержки гарантированно более предельных для конкретного типа, без этого вы не можете быть уверены, что код сработает. и даже если вы закладываете 1 мс паузу там, где по даташиту ожидается 40 мкс, это ни от чего вас не спасает - все равно надо проверять даташит, иначе вы не разработчик, а шаляй-валяйщик.

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Albert_V,
Если у вас ума хватит - прочтите наконец то даташит. Что за упорный чел то. Воистину - глупость не искоренить.
Бред вы пишете сами. И вы уже готовы признать это, только ущемленное чсв этого не даёт сделать.
Считаете ардуинщиками тех, кто пишет на Си? Ну-ну. А я вот считаю устаревшим динозавра тех, кто пыжится писать исключительно только на ассемблере и только на каких-нибудь древних 8-16-битках.

AVR, все случаи в жизни не предусмотрите. А пока будете предусматривать, технологии уйдут далеко вперёд и ваши наработки потеряют актуальность. Придётся заново переписывать. Универсальность - не есть оптимальность. Особенно на ассемблере вы не напишете универсального кода. Все равно придётся переделывать под другой контроллер. И даже на Си универсальность не полная. Где-то нужны одни ресурсы, один метод вывода, а где-то уже другой метод. Хорошие знания современной базы и быстрое ориентирование в ресурсах контроллера позволят не мучиться в создании сверхуниверсального метода.

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

Верно сказано:

Спойлер

любой спор в Интернете это битва за ЧСВ

спасибо, принял!

это на 100% относится к жизни вообще. любой поступок человека в конечном итоге совершается ради этого.

предлагаю отвлечься от битвы за ЧСВ, а поискать баг в данном коде КАК пишет МОНСТЕР он НЕИСПРАВЕН

#define F_CPU 8000000UL
#include <avr/io.h>
#include <util/delay.h>

#define RS_command ~(1<<0)
#define RS_data (1<<0)
#define RW_write ~(1<<1)
#define RW_read (1<<1)
#define E (1<<2)
#define LCD_PORT PORTD
#define RUN_PORT PORTA
#define SIZE_BUS 4 // размер шины данных 4 или 8 бит



void busy_flag()
{
DDRD &= 0x00; // порт D на вход
LCD_PORT |= 0xFF; // включаем поддтяжку
RUN_PORT |= RW_read;
RUN_PORT |= E; // взводим строб
_delay_us(40);
RUN_PORT &= ~E; // команда на запись
_delay_us(40);
if(PIND&(1<<7))
busy_flag();
}

void write_nibbleCommand(int DATA)
{
DDRD |= 0xF0; // младшие три разряда порта А на выход
RUN_PORT &= RS_command; // пишем команду
RUN_PORT &= RW_write;
LCD_PORT &= 0x00; // очищаем шину данных
LCD_PORT |= DATA; // бaйт данных
RUN_PORT |= E; // взводим строб
_delay_us(40);
RUN_PORT &= ~E; // команда на запись
_delay_us(40);
LCD_PORT &= 0x00; // очищаем шину данных

}

void write_command(int DATA)
{
write_nibbleCommand(DATA);
if(SIZE_BUS==4)
write_nibbleCommand(DATA<<4);
busy_flag();
}

void write_nibbleData(int DATA)
{
DDRD |= 0xF0;
RUN_PORT |= RS_data; // пишем команду
RUN_PORT &= RW_write;
LCD_PORT &= 0x00; // очищаем шину данных
LCD_PORT |= DATA; // бaйт данных
RUN_PORT |= E; // взводим строб
_delay_us(40);
RUN_PORT &= ~E; // команда на запись
_delay_us(40);
LCD_PORT &= 0x00; // очищаем шину данных
}

void write_data(int DATA)
{
write_nibbleData(DATA);
if(SIZE_BUS==4)
write_nibbleData(DATA<<4);
busy_flag();

}
void init_LCD()
{
_delay_ms(20); // установка ном напряжения
write_nibbleCommand(0x30); //
_delay_ms(5);
write_nibbleCommand(0x30);
_delay_us(110);
write_nibbleCommand(0x30);
busy_flag();

write_nibbleCommand(0x20); // две строки 4 бита
busy_flag();

write_command(0x28); // две строки 4 бита

write_command(0x08); // отключаем

write_command(0x01); // очищаем

write_command(0x06); // двигаем курсор вправо

write_command(0xF); //включаем

}

int main(void)
{
DDRA =0xFF;
PORTA =0x00;
DDRD =0xFF;
PORTD =0x00;
init_LCD();
// unsigned char znak = 0; // определяем переменную

//while (1)
//{
//write_command(0x80); // Вывод в верхнюю левую позицию 1 строки
//write_data(znak/100 + '0'); // Выделяем сотни
//write_data((znak/10)%10 + '0'); // Выделяем десятки
//write_data(znak%10 + '0'); // Выделяем единицы
//write_data('='); // Выводим знак равенства
//write_data(znak); // Выводим содержимое знакогенератора
//_delay_ms(1000); // Тут можно поменять задержку вывода символов
//znak++; // Следующий символ знакогенератора
//}
}

Это касалось предыдущих версий. Сейчас код выглядит получше, хотя и здесь есть вопросы:
1 Зачем дергаете DDRD в процедурах отправки? Постоянно спрашиваю, но вы так и держите интригу... Порты ведь настраиваются однократно.
2 Зачем спамите дисплей стробом, проверяя его занятость? И зачем вообще с busy_flag() заморочились, если проверяете ее однократно?
3 Функции write_nibbleCommand(int DATA) и write_nibbleData(int DATA) различаются лишь одним битом (RS_data). Этот бит можно менять в write_command(int DATA) и write_data(int DATA), как менее "пушистых", а предыдущие процедуры свести в одну.

с какой целью сделана рекурсия в busy_flag()? потенциально - это источник больших проблем!

if(SIZE_BUS==4) - для чего так? Если хотите сделать универсальный код под 4 и 8 бит ширины, применяйте условную компиляцию, не резервируя переменные. Сейчас у вас этот участок кода выглядит вот так: #define SIZE_BUS 4. То есть текст SIZE_BUS равнозначен тексту 4. И далее "если 4 равно 4 (а это истина всегда!) то сделать то-то ".
Условная компиляция выглядит вот так:

#define SIZE_BUS_4bit /* выбрана 4 бит ширина */

/* --- секция кода */

#ifdef SIZE_BUS_4bit // если определено 4 бита,
/* ------ код работы с 4 битной шириной */

#else // иначе,
/* ------ код работы с 8 битной по умолчанию */

#endif

Для тех, кто вдруг опять сфигали начнет спорить на пустом месте - объясняю: во время работы ширина шины не меняется, дорожки физически не добавляются и не убираются. Как нарисовали их, так они и остаются. 4/8 бит на ходу не переключаются - это бессмысленно. Потому условная компиляция выбирает во время компиляции кода либо один, либо другой блок, в зависимости от написанного в #define. Во время работы кода бессмысленно выполнять проверку "если константа 4 равна 4" или "если константа 8 равна 4".

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

Собственно, такое поведение компилятора - это ещё одно подтверждение того, что так писать смысла нет.

А смысл? Переменных разных, как таковых - нет. Шина в коде "участвует" в 2-х местах: инсталляция и посылка байта/полубайта. В вашем варианте этот функционал придется дублировать, по видимому?
WiseLord, смысл - есть. Мне такой вариант потребовался, когда я переходил с 8 на 4 бита. Очень удобно контролировать код и девайс, меняя всего одну константу.

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

Не вдаваясь в подробности конкретного ногодергания, абстрактно можно представить вот так (абстрактно - это значит без привязки к конкретному контроллеру, то есть в общих чертах):

Оптимизация обычно включена на AVR, там отладчика почти ни у кого нет, а на STM32, например, он почти у всех есть, потому приходится задумываться над тем, что в дебаге размер может легко вырасти в несколько раз. Вчера как раз решал оставить два класса или совместить в одном, через if... Второй вариант вышел почти на пол Кб больше, оставил пока два класса, жду gcc 7, там есть constexpr if

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

С целью прослушки PIN7 до тех пор пока условие станет ложью.

Добавлено after 19 minutes 24 seconds:


1. К коде есть функции чтения,в частности при проверке BF, то есть порт переопределяю на вход, при записи на выход.
2.Первую часть вопроса не понял byus_flag проверяю после каждого процесса записи/чтения о чем свидетельствует наличие вызова функции byus_flag() в конце функции записи/чтения.
3. согласен, но пока кабы не запутаться и не пропустить ошибку, решил написать громадно,но подробно.это же не является фатальной ошибкой?

Добавлено after 10 minutes 31 second:


Принято к сведению!А вариант отраженный в исходнике он что не рабочий?