Именно в Raspberry Pi B+ разъем GPIO стал содержать все выходы, необходимые для _аппаратного_ VGA выхода. В чипах почти всегда на одно выходе по несколько функций. Так вот до B+ на разъеме были не все выводы, имеющие фунции VGA. Там есть небольшая «магия на резисторах», но в целом всё корректно. Автор заявляет полную поддержку: на VGA можно будет выдавать теже самые 1920×1080×60 fps, что и на HDMI.
С одной стороны, хочется читаемых конфигов, с другой — быстрого парсинга и быстрого обращения по этому типу.
Глядя на всё то, что вы понаписали после этой фразы, очень хочется спросить: для чего вам этого хочется? Нужны очень весомые основания, чтобы встраивать в свой проект такую жуть.
Было бы здорово, если бы вы привели пример, когда действительно жизненно необходимо использовать перечисления, вместо хешей.
Сначала просто плюсанул пост, читать некогда было.
1) Большое спасибо за инфу! Не знал о такой возможности. Но ИМХО в данном случае я хотел не решить только свою конкретную задачу, а разобраться, как бы это решил Gentoo Developer. Я этого не достиг, конечно, но попытался :)
2) Супер!
3) Да, этот ресурсик я видел. Я там правда кроме статуса и коротенького коммента ничего больше не нашёл. Когда остановился, когда планируют заново ввести в строй…
По поводу PORTDIR_OVERLAY не понял: оверлей может быть только один или нет? В любом случае спасибо за наводку, ещё раз почитаю мануалы.
Да, патч я выложил. А нормально, что я его просто так выложил в gentoo bugzilla? Я помню при работе в одном проекте надо было допиливать libc. Приходилось немного общаться с Урлих Дреппером. Уж не знаю, что я там делал не так, но он не объяснял, а сразу ругаться начинал :) Теперь у меня какая-то фобия :)
Сразу в разрабы мне и не надо в принципе. Я не против и так просто попатчить. Уже есть на примете несколько пакетов, которые использую и для которых ebuild'ы криво написаны. Ещё раз спасибо!
А не знаете, что с overlays.gentoo.org сейчас происходит?
Это очень маленькая сумма, если речь идёт о нормально поставленой работе, когда контракт выполняет не один человек. Нельзя выполнять длительный сложный проект по разработка железа и при этом всё делать самому. На собственном опыте проверено — работа получается жутко не эффективной. Как минимум нужно 3 человека, а это уже при полугодовалом проекте даёт более 2 млн. руб. А полгода — это крайне мало…
Это всё моё ИМХО, результат собственного опыта железячного «фриланса». Может быть я просто «не умею готовить» в этой области — спорить не стану. Группа, в которой я состою, решила предпринять последнюю попытку на чём-то взлететь. Если дойдём до финала, тоже опишу на Хабре свои скитания.
Автору выражаю большущую благодарность за статью. Очень приятно осознавать, что ты не один в этом интересном, но тёмном месте :) (в хорошем смысле)
А по мне так всё логично. Переключение на работу в своём стеке должно производиться не в прерывании (в 90% случаев). Обычно это делается при инициализации. А значит переключать должен Thread, а не Handler. Поэтому ему и дали эту функцию. Предполагается, что переключение стека должно производиться один раз при инициализации.
А теперь посмотрим на мой любимый Cortex-M3. Там есть привилегированный режим. Включаем его и Handler, пусть и неудобно, но может всё (и правильно, что неудобно, раз неудобно — значит что-то делается неправильно), а вот Thread может быть ограничен в своей песочнице контроллером MMU. Поменять стек он больше не может, т.к. в непривилегированном режиме ему это запрещается. Вот вам и главенство Handler'а (ядра) над Thread'ом (приложением).
Cortex-M0/M1 разрабатывались не для исполнения ОС. Они под firmware сделаны с одним фоновым процессом и обработчиками. Просто там ко всему прочему дали возможность иметь разные стеки для обработчиков и фонового процесса — и всё. Остальных элементов — привилегированного режима и MMU -, присущих процессорам под ОС, там нету. Т.ч. это не MPU, а MCU и, строго говоря, ОС на них крутить — значит использовать не совсем по назначению. А раз так, то и не надо удивляться, что задачи приходится решать «криво».
А мне статья не понравилась и вот почему.
1. Заявление о том, что самая важная фича в Си++ — это декструкторы, на мой взгляд весьма неочевидно. Может быть это и так, но в статье данная тема не раскрыта, притом, что заявление очень и очень громкое.
2. В статье неявно используется тезис, гласящий, что Си++ до сих пор на плаву главным образом потому, что он обладает такими хорошими свойствами. Совсем неочевидно, что этот тезис верен. Лично я склонен считать, что в плавучесть этого языка вносят весомый вклад также и внешние факторы, и история. Например, язык Си является куда более распространенным, но почти никто не сомневается, что он менее удобен для большинства задач, нежели Си++.
3. В главе «Шаблоны» есть проблемы со связностью. Скорее всего предложения этой главы как-то связаны друг с другом, но мне, как читателю, эта связь кажется туманной. Стоило бы объясниться яснее.
4. Толи я что-то не понял, толи диаграммы в некоторых вопросах конфликтуют с текстом. Заявляется, например, что Си++ — на втором месте по вкладу в OS. А на диаграммах прямо над этим текстом Си++ на третьем месте после Java и Си. Тут видимо тоже есть смысл, но он раскрыт плохо. Необходимы дополнительные комментарии автора.
Общее впечатление о статье также плохое. Анализа мало, знамён и воодушевляющих речей много. А хотелось бы именно анализа, тема-то интересная…
А разве 1 чип eMMC до сих пор не ограничен пропускной способностью в 104 МБайт/сек, как гласит JEDEC'овский станадарт на MMC в версии 4.4.1? И даже эту скорость на запись ещё надо постараться достич на одном чипе. Если я не устарел и 4.4.1 до сих пор доминирует, то даже для 128 ГБ версии представленного SDD применяется многоканальность. Вопрос только в количестве каналов. И, кстати, запись обычно у eMMC в 2-3 раза медленней, чем чтение, поэтому только скорость записи и постарадала.
Я это не из занудства написал. Может действительно я устарел и меня кто-то поправит — буду очень благодарен.
Они дороже не потому, что выше их себестоимость. На 70% разница между обычными и «спортивными» товарами складывается из-за наценки на спрос (спортивные товары популярней) и характер спроса (любителей спорта чаще не останавливает бОльшая цена).
А что произойдёт с предсказуемостью, если я вдруг запущу mruby на моём микроконтроллере? Понятно, что сейчас mruby хотя бы потенциально не стабилен. Но если предположить, что его отладили — то предсказуемость останется на прежнем уровне. Вот скорость выполнения операций ядром упадет — да. Но не в любой задаче это важно.
Мне кажется мы говорим о разных вещах. Я пытаюсь донести мысль «у нас появилась новая возможность», а вы — «чаще всего возникают задачи, в которых этот метод не проходит». Может быть чаще это действительно и так (хотя статистики у меня нет), но это не повод полностью отстранять идею.
Коллеги, работавшие на тот момент со мной на одном предприятии. Более того, мне, как разработчику, начальство часто «вставляло» за «лишнюю» информацию, переданную северокорейцам и китайцам. При этом из слов начальства было понятно, что случаи были. Это, конечно, не доказательство, но и простыми слухами имеет мало общего: люди не в курилке байки травили, а выписывали конкретные распоряжения, чтобы защититься от воровства.
Глядя на всё то, что вы понаписали после этой фразы, очень хочется спросить: для чего вам этого хочется? Нужны очень весомые основания, чтобы встраивать в свой проект такую жуть.
Было бы здорово, если бы вы привели пример, когда действительно жизненно необходимо использовать перечисления, вместо хешей.
Ждать, правда, придётся похоже не один месяц… :(
1) Большое спасибо за инфу! Не знал о такой возможности. Но ИМХО в данном случае я хотел не решить только свою конкретную задачу, а разобраться, как бы это решил Gentoo Developer. Я этого не достиг, конечно, но попытался :)
2) Супер!
3) Да, этот ресурсик я видел. Я там правда кроме статуса и коротенького коммента ничего больше не нашёл. Когда остановился, когда планируют заново ввести в строй…
По поводу PORTDIR_OVERLAY не понял: оверлей может быть только один или нет? В любом случае спасибо за наводку, ещё раз почитаю мануалы.
Да, патч я выложил. А нормально, что я его просто так выложил в gentoo bugzilla? Я помню при работе в одном проекте надо было допиливать libc. Приходилось немного общаться с Урлих Дреппером. Уж не знаю, что я там делал не так, но он не объяснял, а сразу ругаться начинал :) Теперь у меня какая-то фобия :)
Сразу в разрабы мне и не надо в принципе. Я не против и так просто попатчить. Уже есть на примете несколько пакетов, которые использую и для которых ebuild'ы криво написаны. Ещё раз спасибо!
А не знаете, что с overlays.gentoo.org сейчас происходит?
Это всё моё ИМХО, результат собственного опыта железячного «фриланса». Может быть я просто «не умею готовить» в этой области — спорить не стану. Группа, в которой я состою, решила предпринять последнюю попытку на чём-то взлететь. Если дойдём до финала, тоже опишу на Хабре свои скитания.
Автору выражаю большущую благодарность за статью. Очень приятно осознавать, что ты не один в этом интересном, но тёмном месте :) (в хорошем смысле)
А теперь посмотрим на мой любимый Cortex-M3. Там есть привилегированный режим. Включаем его и Handler, пусть и неудобно, но может всё (и правильно, что неудобно, раз неудобно — значит что-то делается неправильно), а вот Thread может быть ограничен в своей песочнице контроллером MMU. Поменять стек он больше не может, т.к. в непривилегированном режиме ему это запрещается. Вот вам и главенство Handler'а (ядра) над Thread'ом (приложением).
Cortex-M0/M1 разрабатывались не для исполнения ОС. Они под firmware сделаны с одним фоновым процессом и обработчиками. Просто там ко всему прочему дали возможность иметь разные стеки для обработчиков и фонового процесса — и всё. Остальных элементов — привилегированного режима и MMU -, присущих процессорам под ОС, там нету. Т.ч. это не MPU, а MCU и, строго говоря, ОС на них крутить — значит использовать не совсем по назначению. А раз так, то и не надо удивляться, что задачи приходится решать «криво».
1. forum.amperka.ru/threads/Проблема-с-экспериментом-15-Комнатный-термометр-в-конспекте-хакера-Матрёшка-z.3350/
2. forum.amperka.ru/threads/Проблема-с-экспериментом-9-миксер-в-конспекте-хакера-Матрёшка-z.3322/
pinMode(BUTTON_PIN, INPUT_PULLUP)1. Заявление о том, что самая важная фича в Си++ — это декструкторы, на мой взгляд весьма неочевидно. Может быть это и так, но в статье данная тема не раскрыта, притом, что заявление очень и очень громкое.
2. В статье неявно используется тезис, гласящий, что Си++ до сих пор на плаву главным образом потому, что он обладает такими хорошими свойствами. Совсем неочевидно, что этот тезис верен. Лично я склонен считать, что в плавучесть этого языка вносят весомый вклад также и внешние факторы, и история. Например, язык Си является куда более распространенным, но почти никто не сомневается, что он менее удобен для большинства задач, нежели Си++.
3. В главе «Шаблоны» есть проблемы со связностью. Скорее всего предложения этой главы как-то связаны друг с другом, но мне, как читателю, эта связь кажется туманной. Стоило бы объясниться яснее.
4. Толи я что-то не понял, толи диаграммы в некоторых вопросах конфликтуют с текстом. Заявляется, например, что Си++ — на втором месте по вкладу в OS. А на диаграммах прямо над этим текстом Си++ на третьем месте после Java и Си. Тут видимо тоже есть смысл, но он раскрыт плохо. Необходимы дополнительные комментарии автора.
Общее впечатление о статье также плохое. Анализа мало, знамён и воодушевляющих речей много. А хотелось бы именно анализа, тема-то интересная…
И то, что применением нескольких чипов можно достич нужной скорости — я тоже знаю, как видно из моего исходного поста.
Я как раз-таки и удивился вот этому заявлению:
Ого! MRuby требует в 3 раза больше! Неплохо.
Я это не из занудства написал. Может действительно я устарел и меня кто-то поправит — буду очень благодарен.
Мне кажется мы говорим о разных вещах. Я пытаюсь донести мысль «у нас появилась новая возможность», а вы — «чаще всего возникают задачи, в которых этот метод не проходит». Может быть чаще это действительно и так (хотя статистики у меня нет), но это не повод полностью отстранять идею.