В том-то и дело, что можно! Но есть разница — в отношении Японии у меня никогда не было предубеждений об их умении обращаться с ядерными материалами, так что я не был удивлен событиями 2011 года (хотя нет, даже я удивился). И конечно можно сказать «да им вот американцы же все построили», но думается мне, что если и вешать ответственность за выбор места и мероприятий по предотвращению аварий на американцев, то только в контексте «это была осознанная диверсия». А уж как дальше все это эксплуатировалось и управлялось…
Мне кажется, вы не только американские газеты, но и учебник географии не читали
Ну и к чему тут эта грязь? Уж лучше бы в карму мне минуснули, и то было бы красивее.
Между «куда-то посередине ничего» и «куда-то в Великие Озёра» есть, мягко говоря, разница
Ключевой момент приведенной вами статьи не в куда, а почему. «Дизастер или террористы», охренеть какой набор причин. Мне кажется, или это применимо примерно к любому ядерному объекту? Ну разве что на ГХК это чуть сложнее в силу известных причин.
И совершенно не надо расстраиваться насчет Великих Озер, если рядом с ними что-то построили (к слову, в США отнюдь не только Великие Озера «под угрозой», а многие другие водоемы), то об этом хорошо подумали. В том числе в контексте «дизастер или террористы».
Да конечно проблемы везде есть, и я так уверенно тут минусы набираю именно потому, что специально знакомился с этими проблемами в США — есть, и еще какие. Но все-таки не такие, об этом речь.
Вы конечно правы, американских газет я читаю мало, т.к. живу не в Америке. Так что спасибо за ссылку, хотя по ней нет ничего, имеющего хотя бы отдаленное отношение к обсуждаемому вопросу. Кратко: в статье описывается, что на АЭС в США имеются хранилища отработанного топлива (справка: так не только в США), и если случится дизастер или набегут террористы, то топливо может куда-нибудь попасть. Круто, вот это совершенно того же уровня опасность, что и озеро с радиоактивной жижей.
Впрочем нельзя не согласиться, что в части терроризма озеро с радиоактивной жижей много безопаснее, ведь вряд ли террористы с ведерками рискнут к нему сунуться.
Боже, не хочу даже представлять тот день, когда мне придется еще и с внешней памятью на Миландрах возиться
О боже, вам вообще приходится с ними возиться? :-(
Тут не спорю, хотя плохо спроектированные шаблонные классы пустым конструктором способны отъедать очень много
Ммм, поясните? Я человек, далекий от шаблонной магии, поэтому не все сходу понимаю, сорри.
Ну, учитывая, что код автора генерируется, а не руками пишется
Как же это он генерируется? Там данные из CMSIS SVD берутся, как я понял (видимо каким-то парсером, тоже пропреитарным), а сам-то код не генерируется, а пишется человеком с объемной головой.
Все эти вещи я тоже прекрасно понимаю, честное слово, сам киповец же (в прошлом). И даже в некотором роде отношусь к той категории киповцев, которые скорее за аналоговые преобразователи, пусть и со стандартным выходным сигналом (я не знаю, какие именно датчики вы делаете, вполне возможно в вашем случае операционниками не обойтись). Потому что, да, простота, надежность, монотонность отказов, вот это вот все. И так же точно люблю петлю 4-20 мА. Но есть следующие соображения: во-первых цифровых интерфейсов и функций все больше, во-вторых я уверен, что вы не только датчики делаете и смотрите в другие ниши, и в-третьих — китайцев я упомянул скорее в качестве некоего собирательного образа конечно же. Современному российскому производителю оказывается необходимым конкурировать по цене даже с итальянцами (а это уже не китайцы по качеству, хотя и китайцы бывают конечно очень разные). Кое-где и американцы по цене давят, то есть тут вопрос не в сравнении конкретно с китайцами, а вообще в бесперспективности конкуренции только по цене. И если кроме цены остается в активе только привязанность пользователей, то это неуверенная позиция, даже если речь про рынок переработки.
Не будешь же каждый объект контрольной суммой защищать… А сам тест ОЗУ, что она вобще фурычит ещё, писать, читать можно, ячейки не залипли уже отработан + во многих контроллера есть аппаратная проверка
Ну и прекрасно, не надо каждый объект защищать контрольной суммой. Всего лишь ЕСС и скраббер, частоту работы которого вы подбираете исходя из <something_reason>. У вас же все равно есть изменяемые данные — так и защищайте все разом.
Ну и если так уж хочется положить почему-то именно работу с пинами в ПЗУ… Хз, я бы обошелся минимально шаблонизированным кодом, не таким навороченным. Лично я.
На самом деле проверяется все, ALU, например, что все команды делают то, что надо
Круто, если без локстепа. И как проверяете кстати?
Но глобально здесь есть вот какая тонкость — все эти расчеты конечно отлично играют на NRE, тех самых инженеров, а лучше — лишних продавцов. Но в контексте продукта куда лучше не соревноваться с китайцами по цене, а искать новые штреки, придумывать новые фичи, и тут как скорость реакции, так и запас прочности очень играют. Вы же тоже все-таки не болты делаете… Да и с болтами, знаете ли, бывает очень по-разному.
Да, про отечественные МК — у того же миландра многие контроллеры имеют интерфейс внешней памяти. Явно с намеком, поскольку в остальном они не выглядят "мощными" (а у остальных производителей это скорее привилегия для "мощных" контроллеров, чем для всех подряд).
Я конечно не хочу сказать, что это вообще не нужно, просто значимость преувеличена. И тонкое место в таком случае имхо будет не в способе хранения класса Pin, а в используемых либах, качестве протоколов связи и изощрённости бизнес-логики. Первое весьма важно, поскольку ценность С++ без стандартной библиотеки резко снижается.
В шаблонной магии автора, несмотря на ее объективную эффективность, меня ещё смущает ее недоступность для применения. Систему обычных классов любой программист слепит на раз-два, а всю вот эту вот красоту надо где-то брать, сам не напишешь. А негде, чтобы и лицензия МИТ, и под любые платформы.
Да да да, старая песня, всю жизнь слышу. Только ИРЛ такие ограничения редко встречаются, и то это чаще всего косяк бизнеса (а то и архитектора системы).
Читал, вам не понравился беззнаковый литерал в ассерте. Только при чем тут ассерт, я еще раз спрашиваю? Разве это не должно быть везде сделано правильно?
Датчик работает 5 лет до поверки. За это время с ОЗУ все что угодно может случится, чтобы в ОЗУ не было таких «постоянных данных», как раз лучше их кинуть в ПЗУ и делать проверку контрольной суммы ПЗУ, если с ПЗУ что-то произойдет, то выставить ошибку — это проще, чем проверять все объекты ОЗУ или пихать их в специальный сегмент и проверять этот сегмент.
Эм, если вы реально за исправность железа беспокоитесь, то опора на ПЗУ спасет ваш лишь от части проблем, это во-первых, а во-вторых от скраббера ОЗУ вы все равно не уйдете в конечном итоге.
Ну и к чему тут эта грязь? Уж лучше бы в карму мне минуснули, и то было бы красивее.
Ключевой момент приведенной вами статьи не в куда, а почему. «Дизастер или террористы», охренеть какой набор причин. Мне кажется, или это применимо примерно к любому ядерному объекту? Ну разве что на ГХК это чуть сложнее в силу известных причин.
И совершенно не надо расстраиваться насчет Великих Озер, если рядом с ними что-то построили (к слову, в США отнюдь не только Великие Озера «под угрозой», а многие другие водоемы), то об этом хорошо подумали. В том числе в контексте «дизастер или террористы».
Впрочем нельзя не согласиться, что в части терроризма озеро с радиоактивной жижей много безопаснее, ведь вряд ли террористы с ведерками рискнут к нему сунуться.
О боже, вам вообще приходится с ними возиться? :-(
Ммм, поясните? Я человек, далекий от шаблонной магии, поэтому не все сходу понимаю, сорри.
Как же это он генерируется? Там данные из CMSIS SVD берутся, как я понял (видимо каким-то парсером, тоже пропреитарным), а сам-то код не генерируется, а пишется человеком с объемной головой.
Ну и прекрасно, не надо каждый объект защищать контрольной суммой. Всего лишь ЕСС и скраббер, частоту работы которого вы подбираете исходя из <something_reason>. У вас же все равно есть изменяемые данные — так и защищайте все разом.
Ну и если так уж хочется положить почему-то именно работу с пинами в ПЗУ… Хз, я бы обошелся минимально шаблонизированным кодом, не таким навороченным. Лично я.
Круто, если без локстепа. И как проверяете кстати?
Но глобально здесь есть вот какая тонкость — все эти расчеты конечно отлично играют на NRE, тех самых инженеров, а лучше — лишних продавцов. Но в контексте продукта куда лучше не соревноваться с китайцами по цене, а искать новые штреки, придумывать новые фичи, и тут как скорость реакции, так и запас прочности очень играют. Вы же тоже все-таки не болты делаете… Да и с болтами, знаете ли, бывает очень по-разному.
Да, про отечественные МК — у того же миландра многие контроллеры имеют интерфейс внешней памяти. Явно с намеком, поскольку в остальном они не выглядят "мощными" (а у остальных производителей это скорее привилегия для "мощных" контроллеров, чем для всех подряд).
Я конечно не хочу сказать, что это вообще не нужно, просто значимость преувеличена. И тонкое место в таком случае имхо будет не в способе хранения класса Pin, а в используемых либах, качестве протоколов связи и изощрённости бизнес-логики. Первое весьма важно, поскольку ценность С++ без стандартной библиотеки резко снижается.
В шаблонной магии автора, несмотря на ее объективную эффективность, меня ещё смущает ее недоступность для применения. Систему обычных классов любой программист слепит на раз-два, а всю вот эту вот красоту надо где-то брать, сам не напишешь. А негде, чтобы и лицензия МИТ, и под любые платформы.
Ну, вы разъясните, тогда может и вопросы отпадут, зачем же сразу истерить.
TMI — любимая тема у наших людей, я понимаю, но все же это очень далеко по последствиям.
Ну а Фукусима это конечно да, это треш и угар, втоптавший в грязь все утверждения о Японии.
Эм, если вы реально за исправность железа беспокоитесь, то опора на ПЗУ спасет ваш лишь от части проблем, это во-первых, а во-вторых от скраббера ОЗУ вы все равно не уйдете в конечном итоге.
И вот это к половине статей по эмбеду можно просто дисклеймером вешать: