Comments 60
Заголовок безграмотный.
Ваша работа, бесспорно, полезна. Но заголовок в самом деле неоднозначный.
Когда я увидел заголовок, сразу вспомнилась проблема с выбором конкретного дисплея, так как не во всех винстаровских дисплеях зашита кириллица. Нарочно не искал способ решения, думал в своё время просто дорисовать недостающие символы в CGRAM, но в итоге просто отложил дисплей на полку.
Когда я увидел заголовок, сразу вспомнилась проблема с выбором конкретного дисплея, так как не во всех винстаровских дисплеях зашита кириллица. Нарочно не искал способ решения, думал в своё время просто дорисовать недостающие символы в CGRAM, но в итоге просто отложил дисплей на полку.
Поменял, спасибо.
Это для более быстрой отрисовки и экономии RAM?
В либе для ssd1306 которую я нашел вся таблица лежит в массиве, можно спокойно рисовать свои символы. Инересно, там тоже есть зашитая в контроллер таблица?
Чтобы это выяснить нужно 30 секунд на поиск в гугле и еще 40-50 секунд для беглого просмотра результата поиска — http://www.buydisplay.com/download/ic/SSD1306.pdf :)
Если это слишком сложно, то ответ — в контроллере нет зашитых таблиц.
М-да, мое мнение об ардуинщиках после этой статьи ничуть не повысилось :)
Наше мнение о снобах, с пустым профилем без единой статьи и проекта тоже не повысилось. И при этом позволяющим себе пренебрежительно высказываться о системе на которой создано бесчисленное количество замечательных проектов и которая позволила приобщиться к миру микроконтроллеров миллионам людей во всём мире. (Это безотносительно этой конкретной статьи.)
с пустым профилем без единой статьи
А если бы у меня в профиле было два десятка статей на медицинскую тему — мое мнение об ардуинах было бы более весомым? :))
на которой создано бесчисленное количество замечательных проектов и которая позволила приобщиться к миру микроконтроллеров миллионам людей
Да, а Лего позволил приобщиться миллионам людей к архитектуре и роботостроению :)
Я не умаляю достоинств ардуины, но нужно называть вещи своими именами: миллионы людей приобщились не к миру микроконтроллеров, а к миру конструктора на их основе.
Лучше скажите, где брать недорогие дисплей 1602 с кириллицей?
Кто-то делает?
Кто-то делает?
SPI используется нечасто? Серьёзно? При том, что это один из самых быстрых интерфейсов? Может быть у ардуинщиков и не часто, но разработчиков очень часто.
Вы невнимательно читали, там русским по белому написано: «в любительской практике».
А для любителей выпускаются отдельные серии микросхем без spi? Дисплеи, АЦП, ЦАП, датчики. Что тогда вообще используют «любители»? Голый МК, кнопки и светодиоды?
"Любители" используют широко распространенные ардуиновские библиотеки. Шаг влево или вправо от этих библиотек — и это уже "профессионал" :)
Кажется, я выбрал не тот уровень сложности, когда начинал изучать МК, ибо делал это без ардуйни xD
Когда я начинал изучать МК, у них еще не было флеш-памяти, а стирание производилось ультрафиолетом. И о таких инструментах, как AVRStudio, еще и не мечтали, Ардуино и в проекте не существовало, потому как не существовало AVR. Си-компилятор от IAR стоил бешеные деньги, потому все всё делали на ассемблере в текстовом редакторе. Первый AVR1200 встречали, как манну небесную. Я с удовольствием воспринимаю все новое, если оно действительно помогает, облегчает, упрощает и т.п. Но не более того: бритву Оккама никто никогда не отменял.
Ардуйня далеко не новое и на счет облегчения и упрощения можно сильно поспорить, т.к. на выходе получаем абсолютно непредсказуемую прошивку, которая может в любой момент повиснуть. Точнее дело не в самой ардуйне, а в их калечных библиотеках. Хотя проблема с готовыми библиотеками не только там. Например встроенная в CodeVision библиотеку 1-Wire запрещает все прерывания при работе с шиной. К зависанию, конечно, это не приводит, но все равно довольно неприятная «фишка». Хотите использовать плюшки ардуйни в виде кучи готовых модулей? Да пожалуйста. Только для этого совсем не обязательно писать код в Arduino IDE. Открываем ту же AVR Studio, пишем свои библиотеки и получаем отличную платформу для обкатки прошивок. Только результат становится абсолютно предсказуемым.
Ну и зря считаете, что если у человека нет десятка статей на гиктаймс, то он болтун. На их написание нужно время, а когда человек занят работой, а не баловством с ардуйней, то как раз его у него и нет.
Спасибо за то, что вы сэкономили мое время!
Зачем вы переписали библиотеку? Можно было создать свою и унаследовать все классы оригинальной, разбавив своим кодом.
А еще можно создать свою среду Arduino — мне в ней тоже не все нравится. Но почему-то я этого не делаю. Интересно, почему?
Ясное дело, не умеете, вот и не делаете.
Да ну? Научиться этому не так уж сложно. Проще, чем написать все на чистом ассемблере, как я это делал ранее. Но если у высокоуровневого языка и есть преимущества, то они заключаются именно в готовых библиотеках, макросах и т.п.
Которые при необходимости можно чуток подрихтовать, не теряя времени на отладку всего массива кода. Я ведь не программы пишу, а работающую схему ваяю. И коли схема работает, то совершенно неважно как там вы все это оформили — чем быстрее справились, тем лучше. Это, если вы не в курсе, нормальный подход электронщика, программеры могут возмущаться сколько влезет.
Которые при необходимости можно чуток подрихтовать, не теряя времени на отладку всего массива кода. Я ведь не программы пишу, а работающую схему ваяю. И коли схема работает, то совершенно неважно как там вы все это оформили — чем быстрее справились, тем лучше. Это, если вы не в курсе, нормальный подход электронщика, программеры могут возмущаться сколько влезет.
Не сложно, но вам не дано, т.к. без готовых библиотек вы работать не умеете. При этом в корне неверно понимаете смысл применения ОО языков.
Ну, конечно, автор вот этой книги, выдержавшей три издания, работать без готовых библиотек ну совершенно не умеет.
Да, и еще вдогонку: если мне сейчас предложили делать серьезный проект на AVR, я бы не только от ОО отказался, я бы и простое С обошел. На ассемблере много надежней. В том-то и разница между электронщиком и программистом, что для первого чем меньше посредников, тем лучше. Есть и другие принципиальные соображения, применимые конкретно к архитектуре AVR. Ардуино — это удобная прибамбасина, которая позволяет минимумом усилий достичь вполне рабочих результатов. И ничего за этими пределами — если усилия превышают некоторый порог, то проще от такого инструмента отказаться, и делать все руками.
На ассемблере много надежней
Не надо бросаться в крайности. Он лишь быстрее, но надежность с ним ни чем не выше. Да и выигрыш в скорости есть лишь при выполнение каких-то сложных расчетов, для которых AVR в принципе не сильно подходит. Есть еще выигрыш в размере прошивки, но сейчас это мало актуально.
Вы просто не в курсе. Размещение данных в SRAM, а не сразу в регистрах (которых у AVR аж 32) дает замедление сразу в два-три раза на каждую операцию с данными. Это если не говорить о таких наворотах, как PROGMEM. А С по-другому не умеет, ибо приспособлен к фон-неймановской архитектуре, а не гарвардской. Это касается скорости. А что до надежности, то когда я сам отвечаю за то, где что разместить и каким путем выполнить, а не дядя, неизвестно какую оптимизацию наворотивший в компиляторе, то это уже не убеждение, а уверенность.
дает замедление сразу в два-три раза на каждую операцию с данными.
И часто вам надо производить высокоскоростные операции на таких убогих МК (да, да, AVR одни из самых убогих и малофункциональных МК на рыке)? Да такие, когда разница в 2-6 тактов играет существенную роль? Что-то сомневаюсь.
А что до надежности, то когда я сам отвечаю за то, где что разместить и каким путем выполнить, а не дядя, неизвестно какую оптимизацию наворотивший в компиляторе, то это уже не убеждение, а уверенность.
И что вам дает это знание? Ровным счетом ничего. И уж точно никак не влияет на надежность работы МК.
«И часто вам надо производить высокоскоростные операции на таких убогих МК (да, да, AVR одни из самых убогих и малофункциональных МК на рыке)»
— вы не поверите, но часто. Причем именно 8-разрядные тут рулят. Насчет убогости — это типичное приглашение поучаствовать в очередном холиваре, и не заслуживает внимания.
— вы не поверите, но часто. Причем именно 8-разрядные тут рулят. Насчет убогости — это типичное приглашение поучаствовать в очередном холиваре, и не заслуживает внимания.
Расскажите, в чем же они рулят. И почему именно AVR, где даже тактовую на ходу поменять нельзя. Или рулят по тому, что с другими вы не умеете работать?
Так что же, расскажете, по какой причине AVR и 8-битники «рулят»?
P.S.
Вот и минусовщики подтянулись. Самим сказать нечего, а вот оценки ляпать — самое то.
Вдогонку — я был неточен в предыдущем посте: в регистрах нужно размещать, конечно, не «данные», а «переменные». Прошу прощения за оговорку.
Си вообще пофиг где располагаются переменные — это епархия компилятора. И архитектура к Си имеет очень слабое отношение.
когда я сам отвечаю за то, где что разместить и каким путем выполнить, а не дядя, неизвестно какую оптимизацию наворотивший в компиляторе
Я же говорю — Вы просто не освоили нормально Си и директивы его компилятора :) И имеете какое-то устаревшее лет на 15 представление о возможностях нормальных компиляторов :)
На ассемблере много надежней
Обычно так говорят те, кто не освоил нормально С/С++ :) На ассемблере не надежнее, и даже почти не быстрее и почти не компактнее. Современные компиляторы в умелых руках создают очень оптимальный код.
В том-то и разница между электронщиком и программистом, что для первого чем меньше посредников, тем лучше.
То электронщик у Вас любит ардуину потому что "совершенно неважно как там вы все это оформили — чем быстрее справились, тем лучше", то электронщик не любит лишних посредников, чьим очень жирным представителем является ардуина. Вас, электронщик, не поймешь :)
Ну вот смотрите, например автор исходников LiquidCrystal_I2C исправит кучу багов или перелопатит весь код сделая ее быстрее. Вам придется посидеть вечерок занимаясь копи-пастой, чтоб привести ваш код к новому виду.
С наследованием такого не будет — вам только нужно будет перезаписать LiquidCrystal_I2C в папке библиотек и все.
С наследованием такого не будет — вам только нужно будет перезаписать LiquidCrystal_I2C в папке библиотек и все.
Ардуинскую библиотеку TWI тоже поправить нужно. У неё внутре неонка есть весёлый while без выхода по таймауту (или количеству циклов), который вешает всю ардуину при малейших косяках при коммуникации по этому протоколу.
Особенно актуально при наводках или помехах по питанию.
Особенно актуально при наводках или помехах по питанию.
Вы, наверное, программист, а не электронщик. Посмотрите на аппноты Atmel — там куча образцов алгоритмов, в которых бесконечные циклы ожидания без всяких выходов. Почему так? А потому, что конструкция все равно не будет работать, если в TWI обрыв. Куда ее выводить по таймауту? Эта только лишнее и ничем не оправданное усложнение в программе, все равно ничего продуктивного она не сделает.
Если, доспустим, мой терморегулятор будет делать своё дело, но на экране будет пусто или крякозябры — то флаг ему в руки. А если при попытке вывода температуры на экран он зависнет и заморозит (или наоборот вскипятит) всё вокруг — то тут начинаются вопросы.
А дело всего-навсего в одной проверке, которая резко повысит стабильность системы.
А дело всего-навсего в одной проверке, которая резко повысит стабильность системы.
В этом конкретном случае возможно. Но дело в том, что нет никаких оснований считать интерфейс TWI менее надежным, чем компоненты терморегулятора. Скорее (точнее, наверняка) наоборот. И под этот редчайший случай загромождать библиотеку операциями, которые никогда не будут востребованы? В космосе или военке, в медицине я бы, безусловно, так и сделал, а для бытового прибора, у которого скорее перегорит нагреватель от того, что забыли налить воду — совершенно ни к чему.
TWI надежен ровно до тех пор, пока к нему не лепят библиотеки от ардуйни, 90% которых кривые и глючные. И не надо думать, что для бытовых применений не нужна надёжность. Представьте, что ваш телевизор по 5 раз в день зависает. Понравится?
BARSRAB, мне казалось, что мы серьезно обсуждаем организацию процесса, а не «библиотеки от ардуйни, 90% которых кривые и глючные». Это вообще не о том и голословная болтовня, а не аргумент. Никакой такой особой глючности в TWI я не замечал. Ни при собственной реализации на ассемблере, ни путем ардуино-библиотеки. Годами работает без единого сбоя, по собственному опыту. Там, что ни говори, есть немало упущений, но уж к TWI это точно не относится. Он и спроектирован так, чтобы работать с минимальными хлопотами.
Он и спроектирован так, чтобы работать с минимальными хлопотами.
К TWI у меня никаких претензий, только к ардуйне, с ее внезапными бесконечными циклами ожидания.
Еще раз — поглядите аппноты от Atmel. Я попервоначалу — лет двадцать назад — тоже дергался, искал способы выхода из таких бесконечных циклов, но потом понял, что это просто не надо.
искал способы выхода из таких бесконечных циклов
Ок. Представим ситуацию. МК управляет неким объектом, пусть будет теплица. К нему подключена та же EEPROM по I2C, в которую он раз в некий промежуток времени записывает температуру, влажность и т.п. Как видно, функция второстепенная. А теперь представим, что EEPROM перестала отвечать (умерла, намокла, и.д.) и МК тупо висит в цикле и ждет второго пришествия, вместо того, чтобы сообщить оператору о неисправности. Считаете, что это нормальная ситуация? Лично я нет. МК никогда и ни при каких ситуациях не должен виснуть. Если же он виснет от элементарной поломки I2C периферии, то место такого девайса на свалке.
Я же совсем не отрицаю, что такие ситуации бывают. Сам искал когда-то выходы из неисправности EEPROM и внутренней (в Classic она была слабо защищена) и внешней, хотя бы в виде диагностики ошибок. И намоделировать таких случаев можно много. Но это не значит, что всегда и во всех случаях бесконечные циклы совершенно неприемлемы и их нужно пугаться. Просто трезво оценивать вероятности и последствия и цену их преодоления. То, что в библиотеках Arduino их применяют — не катастрофа, и даже не противоречит официальной идеологии производителя. Вот я о чем.
Использование библиотек с такими "бомбами" — это катастрофа и есть. Потому что их используют по большей части те, кто не сможет их проверить, даже если и захочет — элементарно знаний не хватит.
Вас вон не хватило даже на то, чтобы найти причину глюка в библиотеке LiquidCrystalRus, то есть Вы не знаете что творится внутри используемой Вами библиотеки, хотя точно знаете, что работает она некорректно.
Нет, извините, но такой подход к проектированию — это диагноз, и большинство ардуинщиков как раз его и практикуют. Взять какие-то библиотеки, зачастую левые, найденные в сети, кое-как костылями заставить их заработать по нужному сценарию — и все, изделие готово!
Представляю беседу инженеров в каком-нить самсунге:
- У нас тут одна подпрограмма в смартфоне не очень, может зависнуть и привести к возгоранию батареи...
- Да хрен с ней, это же не для военки. Все равно пользователь скорее всего раньше уронит и разобьет телефон.
Но дело в том, что нет никаких оснований считать интерфейс TWI менее надежным, чем компоненты терморегулятора. Скорее (точнее, наверняка) наоборот.
Как бы то ни было, но любую часть системы нужно делать максимально надежной. Вы-то, как электронщик, должны знать как считается надежность изделия в целом :) А рассуждать "да все равно вон та деталь менее надежна, так что можно и над надежностью других деталей не париться" :)
И под этот редчайший случай загромождать библиотеку операциями, которые никогда не будут востребованы?
Простите, но по отношению к ардуине это выглядит просто смешным :) Когда при использовании ее библиотек код имеет объем раза в полтора-два больше, чем написанный без ее использования :) И быстродействие настолько же меньшее.
В космосе или военке, в медицине я бы, безусловно, так и сделал, а для бытового прибора, у которого скорее перегорит нагреватель от того, что забыли налить воду — совершенно ни к чему.
А вот это вообще прекрасно. Бытовому прибору надежность ни к чему :) В ногу со временем шагаете, любой производитель Вас поддержит. Главное, чтобы Ваше "ни к чему" в период гарантии не случилось :)
Ну и никто Вас не пустит к военке или космосу с ардуинами, разумеется :)
Andy, когда некто упорно не желает читать то, что написано, а выдумывает из собственной головы за оппонента, и сутками приходится доказывать, что «я имел в виду это, а не это» (хотя там все было сформулировано и без того), желание общаться пропадает напрочь. Вы вместе с BARSRAB — сутяжники, цель которых, очевидно, доказать, что оппонент дурак и недоучка. А я уже скоро лет тридцать, как вышел из возраста, в котором непременно требуется сказать последнее слово. Удачи вам в ваших добрых делах!
Если бы проблема была лишь в одной библиотеке, то ладно. Но это болезнь агрдуйни.
Я прочитал и даже процитировал что написано.
И доказать я стараюсь, что Ваш подход к разработке микроконтроллерных систем непригоден для серьезных задач, применять его можно только для мелких домашних поделок типа часов или "метеостанций".
Микроконтроллеры и компиляторы для них за 30 лет сильно изменились, но Вы, кажется, этого не заметили.
ЗЫ: Вы мне напоминаете моего знакомого, который тоже перешел от ассемблера к бейсику для AVR, так и не сумев освоить Си, и всем доказывал, что Си — это глючно и сложно, Си++ вообще неприменим для контроллеров, а вот Бейсик — это самое то.
А откуда вы знаете мой «подход к разработке микроконтроллерных систем»? По этой публикации? А, да, по моим комментам, я понял. Я бы не стал на вашем месте делать подобных обобщений (и, собственно, никогда и не делал). Чтобы понять «подход к разработке микроконтроллерных систем», никаких комментов не может быть достаточно (потому я обычно на них не реагирую, и очень жалею, что сейчас ввязался). Я не считаю вообще правомерным понятие «подход к разработке микроконтроллерных систем». Этих подходов ровно столько, сколько проектов. И крупной ошибкой будет считать, что в этом плане существуют готовые рецепты на все случаи жизни. Для любительского термостата более, чем достаточно того, что я здесь излагал. Для медицинского прибора недостаточно даже этих ваших гарантированных выходов из цикла — там куда более крутые меры надо применять, чтобы ничего и ни-ни. Для космического аппарата без тщательно продуманного дублирования, линий связи с квитанциями, восстановлением ошибок и так далее даже подходить к проекту не стоит. И, кстати, там в начале всего даже не эта программная уйня, а продуманная схемотехника и выбор компонентов. Потому вы ничего не можете заключить о «подходе» из анализа того, что я говорил о любительском термостате.
ЗЫ: А насчет того, что «Си — это глючно и сложно» я с вашим знакомым согласен. Бейсик, правда, для контролеров не годится напрочь, потому что еще хуже Си, и вообще не годится не для чего — это говорит человек, который когда-то на встроенном MS-Бейсике кучу программ наваял, и ими пользовались. Но Си (который я изучал, когда вы еще в школу ходили, наверное) всегда мне напоминал произведение пьяного художника-конструктивиста. Менее логичный, хуже читаемый и более неудобный практически синтаксис еще надо очень постараться придумать.
ЗЫ: А насчет того, что «Си — это глючно и сложно» я с вашим знакомым согласен. Бейсик, правда, для контролеров не годится напрочь, потому что еще хуже Си, и вообще не годится не для чего — это говорит человек, который когда-то на встроенном MS-Бейсике кучу программ наваял, и ими пользовались. Но Си (который я изучал, когда вы еще в школу ходили, наверное) всегда мне напоминал произведение пьяного художника-конструктивиста. Менее логичный, хуже читаемый и более неудобный практически синтаксис еще надо очень постараться придумать.
Посмотрите на аппноты Atmel — там куча образцов алгоритмов, в которых бесконечные циклы ожидания без всяких выходов. Почему так?
- Примеры они на то и примеры чтобы быть максимально простыми и прозрачными для понимания. Чтобы ничего не отвлекало от конкретной темы. При использовании код, разумеется, корректируется исходя из потребностей конкретной системы.
- Из бесконечного цикла таки могут быть выходы. Вспомним про прерывания. Грамотно построенный диспетчер прерываний позволит системе продолжать работать даже при наличии некоторых проблем с кодом. Хотя, конечно, таких ситуаций лучше не допускать.
- В конце концов, существует механизм watch dog. Вообще не здорово его применять в рабочем цикле, но вытащить систему из сумрака он поможет. Проблему с железом это не решит, но может помочь диагностировать (опять же, если программист об этом позаботится).
К тому же SPI помогает не сильно — вместо шести соединений получаем четыре и опять же наглухо привязанные к дисплею, потому что еще для каких-то целей SPI в любительской практике употребляют нечасто.
Прошу извинить, если недостаточно внимательно прочитал статью и обсуждение, но это… это похоже на незнание основ схемотехники, а именно — наличия входов разрешения (ChipSelect, CS, Enable, Inh[ibit] и т.п.). Всё с чем не требуется общение в данное время может быть отключено от шины.
Даже, внезапно!, ЖКИ с параллельной шиной. И именно тем самым входом E[nable], которым снабжены контроллер HD44780 и армия его клонов. К сожалению, этот момент работы контроллера не выделен явно в тексте datasheet. Но из анализа временных диаграмм обмена и транзисторной структуры порта ввода-вывода данных — это следует как 2х2. Пытлиыве читатели могут найти не только явное подтверждение моим словам в документации на HD44780 или SPLC780, но и косвенные — в документации на алфавитно-цифровые модули с размером 40х4.
Sign up to leave a comment.
Русификация библиотеки LiquidCrystal_I2C для OLED-дисплеев Winstar