Хочется спросить, где был бы сейчас Linux, будь он написан на ассемблере для x86 в свое время?
И где теперь написанная на ассемблере OS/360 от IBM, после работы над которой Брукс написал свою знаменитую книгу «Мифический человеко-месяц»?
Мой ответ на вопрос «как надо программировать на ассемблере» на данный момент звучит так: программируйте на С во всех случаях, кроме написания компилятора С для совершенно новой архитектуры.
Я безмерно уважаю разработчиков ColibriOS за их труд и статьи, но, по моему мнению, коммерческая разработка на ассемблере сейчас сродни коммерческой разработке на Whitespace, с тем же примерно уровнем сложности и соотношением затрат к результату.
И не только для пожилых. Мне всегда не нравились режимы работы в интерфейсах и увлечение контекстными кнопками, но пожилым я себя пока еще не могу назвать. То же самое и с тач-устройствами: совмещение устройств вывода с устройствами ввода, как когда-то выразился Леонид Каганов, это «как чай в унитазе заваривать». А потом все равно купил себе iPad.
Ждем тач-устройств с тактильной обратной связью, то, что предлагается на рынке сейчас — совершенно не замена теплым и ламповым аппаратным кнопкам.
Код у FTDI, к сожалению, получается много хуже чем устройства.
Не думаю, что наткнулся бы на этот баг, ибо об использовании их библиотек даже мысли в голову не приходили — прямая работа с D2XX или libftdi не намного сложнее, но все равно спасибо огромное.
Вышли тому, кто продемонстрирует на LCD, а то в консоли — это не спортивно.
Мой LCD сейчас на работе, а те, что доступны в «удаленной лаборатории» моего ПТУ, подключены к Stellaris Launchpad и Infineon XE167FM EasyKit, запуск Linux на которых — еще больший хардкор, а через мой драйвер дисплея это писать еще менее спортивно, чем в консоль.
Два символа: [b
И 2 совета:
1. Поставь в свою IDE плагин для проверки орфографии в комментариях и строках
2. Не оставляй комментариев на русском, пожалей наших англоязычных товарищей
Надо будет проделать с подобным LCD все то же самое, только без собственных драйверов и через USB в рамках статей про FT232H.
Получится в разы проще, но и в разы менее хардкорно.
Хабр — торт.
Кто там минусовал за Длинного за картинку с Боромиром и «нельзя просто так написать статью за 5 часов»? Стыдитесь.
Не соглашусь только, что I2C назван так за использование двух проводников. Двойка там — это на самом деле не «два», а «квадрат», а само I2C — это Inter-Integrated Circuit, но это несущественная мелочь.
В остальном — преклоняюсь. Сам разбил бы статью на десяток коротких заметок длиной в полгода, и еще не факт, что удалось бы закончить.
При работе с множеством разных (а часто очень-очень разных) МК одновременно выстроить в голове толковый эмулятор каждого у меня не получается, и без отладки в том случае было бы очень грустно. И уже было, когда мне попался доселе неизвестный Infineon XE167FM на ранее незнакомой архитектуре C166, а отладчика к нему не было. Зато был мануал на 2000 страниц и делайн до послезавтра.
Можно отлаживать и в уме, и это хорошее упражнение для начинающих при обучении работе с определенным МК с заранее известными ограничениями, багами и хитростями. Но если у тебя большой проект, сложный сам по себе, плюс на эту сложность накладываются определенные особенности МК (описанные либо на 1255 странице мануала, либо на 25 странице Errata sheet, который как раз обновили позавчера), то лучше, на мой взгляд, использовать все возможности по снижению нагрузки на мозг.
Без отладки, мне кажется, микроконтролеры можно попробовать, пару раз наткнуться на неожиданное для новичка поведение, сказать про себя «пошла она к черту, эта магия-шмагия», и больше к ним не возвращаться.
Надо тестировать, возможно, команда работает во всех режимах, но в документации это не описано (она вообще не очень, честно говоря).
Опять же, можно написать напрямую в FTDI, есть ненулевая вероятность, что помогут.
Есть еще вариант использовать другой канал специально для ловли этого прерывания, но тут уже слишком большой оверхед получается.
Согласен. Но бывает появляется вдохновение, садишься писать, пару часов пописал — выдохся, и дальше тащить тяжело, и бросить уже жалко. А тут просто победил сон. Постараюсь написать про JTAG-отладку более вдумчиво и начать не так поздно.
Странно тогда, что не Abaddon, если предположить, что порядок алфавитный.
Хотя, как вы яхту назовете, так она и поплывет, зачастую, поэтому пусть лучше будет Alchemist. :)
И где теперь написанная на ассемблере OS/360 от IBM, после работы над которой Брукс написал свою знаменитую книгу «Мифический человеко-месяц»?
Мой ответ на вопрос «как надо программировать на ассемблере» на данный момент звучит так: программируйте на С во всех случаях, кроме написания компилятора С для совершенно новой архитектуры.
Я безмерно уважаю разработчиков ColibriOS за их труд и статьи, но, по моему мнению, коммерческая разработка на ассемблере сейчас сродни коммерческой разработке на Whitespace, с тем же примерно уровнем сложности и соотношением затрат к результату.
Ждем тач-устройств с тактильной обратной связью, то, что предлагается на рынке сейчас — совершенно не замена теплым и ламповым аппаратным кнопкам.
Не думаю, что наткнулся бы на этот баг, ибо об использовании их библиотек даже мысли в голову не приходили — прямая работа с D2XX или libftdi не намного сложнее, но все равно спасибо огромное.
Мой LCD сейчас на работе, а те, что доступны в «удаленной лаборатории» моего ПТУ, подключены к Stellaris Launchpad и Infineon XE167FM EasyKit, запуск Linux на которых — еще больший хардкор, а через мой драйвер дисплея это писать еще менее спортивно, чем в консоль.
И 2 совета:
1. Поставь в свою IDE плагин для проверки орфографии в комментариях и строках
2. Не оставляй комментариев на русском, пожалей наших англоязычных товарищей
Получится в разы проще, но и в разы менее хардкорно.
Кто там минусовал за Длинного за картинку с Боромиром и «нельзя просто так написать статью за 5 часов»? Стыдитесь.
Не соглашусь только, что I2C назван так за использование двух проводников. Двойка там — это на самом деле не «два», а «квадрат», а само I2C — это Inter-Integrated Circuit, но это несущественная мелочь.
В остальном — преклоняюсь. Сам разбил бы статью на десяток коротких заметок длиной в полгода, и еще не факт, что удалось бы закончить.
Можно отлаживать и в уме, и это хорошее упражнение для начинающих при обучении работе с определенным МК с заранее известными ограничениями, багами и хитростями. Но если у тебя большой проект, сложный сам по себе, плюс на эту сложность накладываются определенные особенности МК (описанные либо на 1255 странице мануала, либо на 25 странице Errata sheet, который как раз обновили позавчера), то лучше, на мой взгляд, использовать все возможности по снижению нагрузки на мозг.
Без отладки, мне кажется, микроконтролеры можно попробовать, пару раз наткнуться на неожиданное для новичка поведение, сказать про себя «пошла она к черту, эта магия-шмагия», и больше к ним не возвращаться.
Опять же, можно написать напрямую в FTDI, есть ненулевая вероятность, что помогут.
Есть еще вариант использовать другой канал специально для ловли этого прерывания, но тут уже слишком большой оверхед получается.
Хотя, как вы яхту назовете, так она и поплывет, зачастую, поэтому пусть лучше будет Alchemist. :)