Покопавшись в коде я обнаружил ошибку в программе SNANDer при инициализации программатора в режиме работы с микросхемами серии 24Сxxx. Потом я нашел еще одну ошибку с порядком следования байт при записи и чтении микросхем MicroWire - 93xxx в 16-битном режиме. Так я понял, что придется писать программу самому.
Плюс вам за то, что отправили Pull Request-ы с обновлением базы данных чипов в SNANDer, но вот обоснование необходимости писать свою программу какое-то слабенькое. То есть в существующем решении проблема была найдена и локализована, было понятно как её поправить. Признайтесь честно, реальная причина "потому что могу", тут никто не осудит %)
Вспоминается книга Д. Канемана "Шум. Несовершенство человеческих суждений". Там как раз рассказывается про то, что настроение судьи из-за погоды или близости времени обеда может влиять на выносимое им суждение.
Я такой же. Следил за игрой и оформил предзаказ Oil Rush именно потому, что они пообещали поддержку Linux. По тем же причинам покупал игрушки в составе Humble Bundle (4 или 5 выпусков). Но должен признаться честно, почти ни во что из купленного я толком не играл. Максимум запускал "на посмотреть" на пару часов %)
Знаете, у меня в такие моменты в голове возникает примерно такая картинка: сидит чиновник в своём кабинете, бьёт себе по лбу лютый facepalm и восклицает: "Ах, так вот зачем была нужна эта куча разнообразных НИИ в СССР, которые мы так старательно банкротили и превращали в ТЦ и бизнес-центры!"
А кто что может вспомнить про OpenRISC?
Ну кроме того что когда-то Cadence на его основе проводил пару тренингов.
Так-то оно вроде пока живое, относительно недавно даже его поддержку в upstream GCC продвинули.
Я в него палочкой потыкал, с помощью FuseSOC собрал битстрим для платы DE0-Nano, запустил mainline Linux 5.1.2 + BusyBox и на этом пока успокоился.
У меня дома лежит пачка старых роутеров и ADSL модемов.
Что-то отличное от Linux встречается очень редко.
Могу вспомнить разве что VxWorks и ZyNOS. Всё-таки ядро Linux — это весьма хороший framework для написания драйверов, плюс там очень много поддерживаемых «плюшек» (сетевых протоколов, алгоритмов шифрования и прочего). А тут важен параметр Time To Market, поэтому в большинстве случаев берут именно его, ибо цена доработки под свою железку минимальна.
А с WinCE и Platform Builder мне пришлось немного пострадать, не могу сказать что мне понравилось.
Я пользуюсь ОС на базе ядра Linux примерно с 2004 года.
С поддержкой железа за это время стало значительно лучше. Я помню как искал в киосках с дисками драйвера для Linux для моей NVidia GeForce2 MX400. И даже нашёл.
Когда я всё это заставил работать с Mandrake 10 — счастью не было предела.
Сейчас же всё гораздо проще, поддержка железа в разы шире. Но ноутбуки я до сих пор выбираю предварительно изучая списки совместимости. Как правило, найти нужную по характеристикам совместимую железку можно без проблем, но выбирать «не глядя» я бы не рискнул.
Я немного в другой области работаю, но могу сказать одно: лучше просто не знать что наворочено внутри любого коммерческого закрытого продукта, а иначе про спокойный сон можно забыть.
Ключевое преимущество ядра Linux в данном случае (как и любого другого открытого/свободного продукта) — это возможность найти причину неполадки и исправить её самостоятельно. Да, для этого нужен определенный уровень, да, мало кто этим станет заниматься. Но сама возможность — это уже много.
Приведу пример «сбоку». Мне приходится работать с дорогущими проприетарными САПР и, как по мне, там просто адский ад. Куча глупейших багов и проблем, тикеты на которые висят годами.
Однажды мне пришлось перехватывать вызов unlink с помощью подключения самописной so-шки через LD_PRELOAD, чтобы посмотреть содержимое временных файлов с нетлистами из-за которых падала симуляция. Посмотрев в то, что генерит эта софтина, я ужаснулся содержимому, нашёл причину проблемы, сделал не менее жуткий костыль и в итоге всё завелось. Но мой тикет пофикисили только через пол года, и то не полностью.
Так что альтернатив Linux я пока просто не вижу. Если там что-то не работает, то хотя бы можно докопаться до истины.
Лично я ничего страшного в этом не вижу, так как User Agent всё равно содержит информацию об ОС.
У меня, например, это выглядит так:
Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Если верить этой статистике: http://www.w3schools.com/browsers/browsers_os.asp, то пользователей Linux больше 5%, правда на хабре и ГТ есть километровые обсуждения корректности этих данных и репрезентативности выборки, но это уже совсем другая история.
По поводу стабильности тактовой частоты… Поделюсь собственным опытом.
Приобрел я на всем известной китайской торговой площадке 5 модулей ESP-07.
Распаял первый модуль на монтажке согласно общим рекомендациям.
Питание заводится с отдельного стабилизатора на 3.3 В. По питанию стоит 100 мкФ электролитический конденсатор и непосредственно у ног питания модуля — керамический.
CH_PD через 4.7 кОм подтянут к питанию, GPIO15 посажен на землю.
Включаю, цепляюсь через PL2303, а оно мне в терминал мусор сыпет. То есть эхо-ответ работает. В теории, код того символа что я набираю на клавиатуре приходит на порт RXD ESP8266, и ровно такой же код я должен получить на порту TXD ровно до момента завершения команды (на AT-прошивке CR+LF). Я потыкался осциллографом в RXD и TXD и понял что импульсы у кода в эхе слегка короче плюс короткие паразитные выбросы. Как итог — я вижу мусор. Потом была куча потуг понять почему уплывает частота. Пытался отмывать модуль и плату от канифоли и занимался прочей ересью.
Кто-то ещё с таким сталкивался? Можно ли с этим как-то бороться?
В итоге всё заработало нормально со вторым модулем.
Ну тут проще любой spice-симулятор использовать.
Я в студенческие годы ngspice использовал.
Параметризовал то что нужно, а потом перебираешь. А ещё там есть встроенный скриптовый язык.
Ответ тут: www.viva64.com/ru/b/0132/#ID0EUAAC
Но мне кажется, что авторам стоит сделать Linux-версию лишь для того, чтобы не тратить время, отвечая на этот вопрос в каждом топике (:
> Про «кто хочет — напишет себе плагин» посмеялся. В смысле не будет никто себе плагин писать…
Эээ… Я в некотором замешательстве. Эта вещь точно для программистов?
Достаточно всего одного человека, который сделает плагин и выложит его на github. По крайней мере в мире *nix так принято… И поверьте, такие люди найдутся.
Ну и в качестве небольшого проявления занудстава: XML — это всё же не совсем то, что подразумевается под словами «простой текстовый лог».
Тут скорее требуется следующее:
— текстовый лог должен легко читаться;
— текстовый лог должен иметь структуру, которая легко парситя;
— управление фильтрацией и прочими плюшками делается либо через комментарии, оформленые особым образом, либо через конфигурационный файл (опять-таки, с простой и понятной структурой).
Выполнение данных требований позволит легко осуществить интеграцию с любым IDE с помощью системы плагинов.
Таким образом, мухи получаются отдельно, а котлеты отдельно (статический анализатор сам по себе, а управление осуществляется плагином для конкретной IDE). Кому хочется, пишет плагин для vim, кто-то для emacs на lisp, да хоть для KDevelop или ещё какой экзотики. А если лень плагин писать, а его ещё никто не написал до тебя, то текстовый редактор в зубы и вперёд.
А я предпочитаю LGPL.
С одной стороны код можно линковать с коммерческими проектами, с другой стороны все улучшения в моём коде будут обязаны вернуть в проект. Да, придётся весь код тащить в отдельную разделяемую библиотеку, просто взять и скопировать его к себе лицензия не позволит, но это не большая цена за то, что мой проект будет улучшаться по мере использования другими людьми где бы то ни было.
Проблема пермиссивных лицензий в том, что коммерческие компании не любят возвращать улучшения назад, а данный тип лицензий позволяет им это не делать с чистой совестью.
Другая сторона медали в том, что многие компании, имея выбор между двумя аналогичными по функциональности проектами под LGPL и пермиссивной лицензией, с вероятностью стремящейся к 100% выберут вторую, тут уж ничего не поделать.
Спорно. awk есть практически в любом UNIX-шелле, и как правило, по умолчанию. И он есть даже в BusyBox. Просто затащить perl на embedded железку, у которой всего 4 Mb DataFlash-а вряд ли выйдет.
1) А у некоторых МК нет стека как такового. Например у некоторых МК от Microchip есть стек на 32 адреса, в котором хранятся только адреса возврата из функции и больше ничего там хранится не может.
2) Так там же нет сравнения типа «больше-меньше». Используется сравнение типа ==. То бишь тут проще вычесть одно из другового и смотреть выставился ли флаг Z или нет. Так что эффективность сравнения, как мне кажется, немного притянута за уши.
3) Ну запихивать их в один байт, это уже перебор =) А что касается читабельности, то если переписать числа в hex-е, то станет горяздо нагляднее что делается с nibble'ами %)
Плюс вам за то, что отправили Pull Request-ы с обновлением базы данных чипов в SNANDer, но вот обоснование необходимости писать свою программу какое-то слабенькое. То есть в существующем решении проблема была найдена и локализована, было понятно как её поправить. Признайтесь честно, реальная причина "потому что могу", тут никто не осудит %)
Вспоминается книга Д. Канемана "Шум. Несовершенство человеческих суждений". Там как раз рассказывается про то, что настроение судьи из-за погоды или близости времени обеда может влиять на выносимое им суждение.
Я такой же. Следил за игрой и оформил предзаказ Oil Rush именно потому, что они пообещали поддержку Linux. По тем же причинам покупал игрушки в составе Humble Bundle (4 или 5 выпусков). Но должен признаться честно, почти ни во что из купленного я толком не играл. Максимум запускал "на посмотреть" на пару часов %)
Знаете, у меня в такие моменты в голове возникает примерно такая картинка: сидит чиновник в своём кабинете, бьёт себе по лбу лютый facepalm и восклицает: "Ах, так вот зачем была нужна эта куча разнообразных НИИ в СССР, которые мы так старательно банкротили и превращали в ТЦ и бизнес-центры!"
Ну кроме того что когда-то Cadence на его основе проводил пару тренингов.
Так-то оно вроде пока живое, относительно недавно даже его поддержку в upstream GCC продвинули.
Я в него палочкой потыкал, с помощью FuseSOC собрал битстрим для платы DE0-Nano, запустил mainline Linux 5.1.2 + BusyBox и на этом пока успокоился.
Что-то отличное от Linux встречается очень редко.
Могу вспомнить разве что VxWorks и ZyNOS. Всё-таки ядро Linux — это весьма хороший framework для написания драйверов, плюс там очень много поддерживаемых «плюшек» (сетевых протоколов, алгоритмов шифрования и прочего). А тут важен параметр Time To Market, поэтому в большинстве случаев берут именно его, ибо цена доработки под свою железку минимальна.
А с WinCE и Platform Builder мне пришлось немного пострадать, не могу сказать что мне понравилось.
С поддержкой железа за это время стало значительно лучше. Я помню как искал в киосках с дисками драйвера для Linux для моей NVidia GeForce2 MX400. И даже нашёл.
Когда я всё это заставил работать с Mandrake 10 — счастью не было предела.
Сейчас же всё гораздо проще, поддержка железа в разы шире. Но ноутбуки я до сих пор выбираю предварительно изучая списки совместимости. Как правило, найти нужную по характеристикам совместимую железку можно без проблем, но выбирать «не глядя» я бы не рискнул.
Ключевое преимущество ядра Linux в данном случае (как и любого другого открытого/свободного продукта) — это возможность найти причину неполадки и исправить её самостоятельно. Да, для этого нужен определенный уровень, да, мало кто этим станет заниматься. Но сама возможность — это уже много.
Приведу пример «сбоку». Мне приходится работать с дорогущими проприетарными САПР и, как по мне, там просто адский ад. Куча глупейших багов и проблем, тикеты на которые висят годами.
Однажды мне пришлось перехватывать вызов unlink с помощью подключения самописной so-шки через LD_PRELOAD, чтобы посмотреть содержимое временных файлов с нетлистами из-за которых падала симуляция. Посмотрев в то, что генерит эта софтина, я ужаснулся содержимому, нашёл причину проблемы, сделал не менее жуткий костыль и в итоге всё завелось. Но мой тикет пофикисили только через пол года, и то не полностью.
Так что альтернатив Linux я пока просто не вижу. Если там что-то не работает, то хотя бы можно докопаться до истины.
У меня, например, это выглядит так:
Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Если верить этой статистике: http://www.w3schools.com/browsers/browsers_os.asp, то пользователей Linux больше 5%, правда на хабре и ГТ есть километровые обсуждения корректности этих данных и репрезентативности выборки, но это уже совсем другая история.
Приобрел я на всем известной китайской торговой площадке 5 модулей ESP-07.
Распаял первый модуль на монтажке согласно общим рекомендациям.
Питание заводится с отдельного стабилизатора на 3.3 В. По питанию стоит 100 мкФ электролитический конденсатор и непосредственно у ног питания модуля — керамический.
CH_PD через 4.7 кОм подтянут к питанию, GPIO15 посажен на землю.
Включаю, цепляюсь через PL2303, а оно мне в терминал мусор сыпет. То есть эхо-ответ работает. В теории, код того символа что я набираю на клавиатуре приходит на порт RXD ESP8266, и ровно такой же код я должен получить на порту TXD ровно до момента завершения команды (на AT-прошивке CR+LF). Я потыкался осциллографом в RXD и TXD и понял что импульсы у кода в эхе слегка короче плюс короткие паразитные выбросы. Как итог — я вижу мусор. Потом была куча потуг понять почему уплывает частота. Пытался отмывать модуль и плату от канифоли и занимался прочей ересью.
Кто-то ещё с таким сталкивался? Можно ли с этим как-то бороться?
В итоге всё заработало нормально со вторым модулем.
Я в студенческие годы ngspice использовал.
Параметризовал то что нужно, а потом перебираешь. А ещё там есть встроенный скриптовый язык.
Вообще документация к ядру меня в своё время очень порадовала, написано людьми для людей.
Но мне кажется, что авторам стоит сделать Linux-версию лишь для того, чтобы не тратить время, отвечая на этот вопрос в каждом топике (:
Эээ… Я в некотором замешательстве. Эта вещь точно для программистов?
Достаточно всего одного человека, который сделает плагин и выложит его на github. По крайней мере в мире *nix так принято… И поверьте, такие люди найдутся.
Ну и в качестве небольшого проявления занудстава: XML — это всё же не совсем то, что подразумевается под словами «простой текстовый лог».
— текстовый лог должен легко читаться;
— текстовый лог должен иметь структуру, которая легко парситя;
— управление фильтрацией и прочими плюшками делается либо через комментарии, оформленые особым образом, либо через конфигурационный файл (опять-таки, с простой и понятной структурой).
Выполнение данных требований позволит легко осуществить интеграцию с любым IDE с помощью системы плагинов.
Таким образом, мухи получаются отдельно, а котлеты отдельно (статический анализатор сам по себе, а управление осуществляется плагином для конкретной IDE). Кому хочется, пишет плагин для vim, кто-то для emacs на lisp, да хоть для KDevelop или ещё какой экзотики. А если лень плагин писать, а его ещё никто не написал до тебя, то текстовый редактор в зубы и вперёд.
С одной стороны код можно линковать с коммерческими проектами, с другой стороны все улучшения в моём коде будут обязаны вернуть в проект. Да, придётся весь код тащить в отдельную разделяемую библиотеку, просто взять и скопировать его к себе лицензия не позволит, но это не большая цена за то, что мой проект будет улучшаться по мере использования другими людьми где бы то ни было.
Проблема пермиссивных лицензий в том, что коммерческие компании не любят возвращать улучшения назад, а данный тип лицензий позволяет им это не делать с чистой совестью.
Другая сторона медали в том, что многие компании, имея выбор между двумя аналогичными по функциональности проектами под LGPL и пермиссивной лицензией, с вероятностью стремящейся к 100% выберут вторую, тут уж ничего не поделать.
Так это тоже хорошо =)
Только для таких целей, как мне кажется, awk лучше подойдёт:
Ибо не пораждает кучу процессов с последующей проверкой статуса выхода, а соответсвенно работает гораздо быстрее. А так на вкус и цвет, конечно же.
2) Так там же нет сравнения типа «больше-меньше». Используется сравнение типа ==. То бишь тут проще вычесть одно из другового и смотреть выставился ли флаг Z или нет. Так что эффективность сравнения, как мне кажется, немного притянута за уши.
3) Ну запихивать их в один байт, это уже перебор =) А что касается читабельности, то если переписать числа в hex-е, то станет горяздо нагляднее что делается с nibble'ами %)