А чем Вам не нравится моргание диодом в строках 27-32. Сейчас смотрю, а он моргает раз в секунду, без delay()! Вот я движусь по нарастающей, строка 34 и дальше.
Так двигайтесь, я не запрещаю. Но перед этим знания свои подтяните. А то встретите в примере кода в книжке uint8_t и будет ступор и опять вопрос на форум.
Только зачем менять делей в этом коде - мне не понятно. Он не сказывается на работе программы в общем.
uint8_t - это тоже байт (если я не ошибаюсь), а первая буква “u” в названии типа говорит о том, что он беззнаковый (unsigned).
1 лайк
Всем здравствуйте! Благодарю за критику - запомню грубые ошибки) В общем, я пробовал разные библиотеки для работы с дисплеем; пробовал отрисовывать нужные пиксели функцией drawPixel() (и похожими), но зависание ардуино всё равно происходило. Когда я убрал дисплей из проекта, всё работало, как часы. Поэтому можно сделать вполне очевидный вывод - уно просто не справляется с дисплеями, вероятно, не хватает оперативной памяти, поэтому в серьёзных проектах всё-таки предпочтительнее использовать что-то помощнее, например, stm. В моём случае возможно подошла бы какая-нибудь mega…
Тебе бы компилятор об этом сообщил. Приведи вывод после компиляции. «Скетч использует …» ну и так далее.
Молодец. А char это тоже самое что и uint8_t…
И с этим мне придется смириться.
Не смиряться нужно, а выучить базовые знания!!!
В языке Си слабая типизация. Т.е. компилятор практически не проверяет правильность указания типов (разумеется, кроме тех случаев, когда не может привести один тип к другому).
Предполагается, что “программист знает, что делает”.
Напишите, что именно должна делать программа, чтобы и “не задерживаться”, и при этом не выполнять строку 42(55).
У других - справляется.
Кстати, я не обнаружил на приведенной Вами схеме дисплея.
Хотелось бы, чтобы в теме присутствовала та схема, которая обсуждается.
Кстати, кроме памяти может не хватать и чего-то другого, например, питания.
А что касается памяти, к ее перерасходу, как правило, приводит не наличие дисплея, а безграмотная работа с текстовыми строками.
Отнюдь.
Компилятор контролирует распределение только статической памяти. А зависание скорее произойдет при нехватке динамической, которую компилятор никак не оценивает.
Отнюдь.
char может быть как uint8_t, так и int8_t. Более того, этот разнобой реально присутствует в Ардуино.
Согласен. Бывает. Но я о таком только читал. Может быть просто везло, не знаю (за компиляторами «не следу»).
Можете попробовать сами. Для этого Вам нужен код, который позволяет определить, как трактуются символы из второй половины таблицы: как числа от 128 до 255 или как отрицательные числа (например по >127 или по <0), а также Arduino Uno и Arduino Due. Сравните, как работает один и тот же упомянутый выше скетч на одном и на другом.
Я до due не дорос, сразу к stm32 перешел ))
Тогда пробуйте на stm.
Я понял Ваш «посыл», но лично мне «играться» с этим нет никакого желания (да и смысла). Я использую понятные мне типы (int8_t, uint32_t и тп). Пусть лучше молодежь учится, практикуется и вообще - развивается.
ядро там одинаковое
Это вполне резонно.
Но я сказал - Вы услышали.
Если когда придется переносить софт, обрабатывающий кириллицу, с AVR на STM, вероятно, вспомните об этом разговоре (по меньшей мере часть этого софта написана некорректно: вместо проверки старшего бита (что одинаково работает как на int8_t, так и на uint8_t), используется сравнение на больше/меньше).
ценная информация!!! вот так по крохам и собирается …
Замечание принято, исправление внесено.