Я конечно не дипломиповпнных химик, но в данном случае не зарядом единым. Заряд можно пропустить и получить плохой результат: важен и электролит и температура и время. Потому так и ваходит. Может лично вам удобнее, но сомневаюсь, что вся отрасль просто не догадалась...
Поискал информацию, в очередной раз убедился, что C это поле граблей, и некоторые мы подсознательно обходим...
Задумался что компилер уж при прямом то присваивании должен или предупредить или не паковать, но он как обычно никому ничего не должен. У меня просто выработалась привычка набивать структуры как в тетрисе - чтобы паддинг если и оставался - то в хвосте и в 90% случаев тогда и packed не нужен, само собой уляжется. Спасибо за интересный кейс.
Посыл понятен, но кажется таки на любом, ибо pack это "очень хочется сложить поплотнее", но если архитектура не позволяет кривой доступ, то компилер один фиг выравняет. Или я ошибаюсь?
А вот передать такую структуру "как есть" на другую архитектуру и на том конце привести ее в этому же типу без искажения уже не выйдет...
Никак. Это указание компилятору "не оптимизировать". С аппаратурой это никак не связано, утверждение выше про кеши не верно.
Т.е. обычно у вас i+=1 выглядит как чтение в регистр, модификация, запись.
Если вы напишите
while (i != 0) {
...
}
и при этом в цикле переменная не модифицируется, то с включенной оптимизацией компилятор имеет полное право один раз прочитать из памяти в регистр значение и дальше решить: если не 0, то бесконечный цикл. Потому что если в теле цикла переменная не меняется - то и измениться значение не может. Программа по умолчанию штука линейная. И вот volatile нужен как раз для того, чтобы сказать явно "не оптимизировать". Т.е. при каждой проверке условия компилер будет честно каждый раз читать память.
Поэтому тезис "переменная, которая может измениться в другом потоке должна быть помечена как volatile" очень упрощает, иногда портит производительность. Я встречал человека, который все переменные так объявлял. На мое удивление, ответил "чтобы наверняка".
Вообще многопоточное программирование и поведение компилятора - это не только про volatile, но еще и про кэши, барьеры памяти и т.п...
Бегите оттуда. Почему? Потому что это узкоспециализированная система. На реддите как-то была тема, и все кто изнутри в один голос говорили - что если смотреть на отрасль, то сидя на AUTOSAR вы стагнируете, ибо за его пределами все что вы за это время изучили - бесполезно...
MOSFET в девичестве назывался полевым транзистором и имел индуцируемый канал,
Под "полевым транзистором с индуцированным каналом" исторически имели ввиду обычно таки J-FET и думаю их смешивать несколько не справедливо
У вас получается странно.
А мне кажется нет.
Вопросы в статье - явно на джуна, ваши же повыше ощутимо, думаю и то и то норм, но для разных собесов. То что из статьи - это проверить университетские знания + практические навыки при параллельной доподготовке. Т.е. выцепить качественного выпускника с некоторым доп опытом... Заметьте - там нет вопросов на опыт, в основном на типовую фундаментальную подготовку... У вас каждый вопрос по сути оставляет несколько трактовок и подразумевает знание банальных ответов, но ожидает не только лишь их )
Кстати добавлю: смысл в LowSpeed появляется при прохождении ЭМС или наличии чувствительных цепей на плате. Точнее это может влиять в определенных случаях.
Да, возможно я ошибаюсь, я сам был удивлен, но возможно и китайцы накосячили, т.к. к тому моменту как я присоединился к проблеме коллега уже пробовал замедлить шину донелзя, и нормальногу нуля там не образовалось. Это GD32F4 был.
Вот за этим и нужны эти вопросы. Понять ход мыслей и знание узких терминов (потому что команды ими общаются). В вопросе все логично, это не способ унизить, это про взаимодействие.
Вот только достигается это все так же переключением выходного сопротивления. И вишенка здесь в том, что почти всегда это ни на что не влияет, человек привыкает, и потом выхватывает долгий поиск причины проблемы, когда это было важно. Коллега так нарвался на сбои в разветвленной I2C, еще и с трансляцией уровней через MOSFET, когда включенный в "low speed" порт просто не мог придавить к земле полностью шину, и одно из устройств не считало это нулем...
UDS описывает общую идею и как это примерно должно работать
UDS оставляет производителям право поддерживать, не поддерживать либо менять под себя куски спецификации (на деле - что можно менять оговорено, но от этого не легче, ибо этого уж очень много).
В итоге имеем этакий очень обтекаемый простокол: у кого-то есть UDS, но в нем не поддерживается вообще никакой сахар. список DID есть у производителя, и этот список не сквозной, а разбит на кучку по 5 чисел. Причем разные части доступны в сессиях разного уровня, а в этих сессиях они доступны в разных режимах работы.
Короче говоря в стандарте очень много возможностей, но реальность такая, что большая часть из них не доступна.
Пару раз сталкивался, когда приходили на работу коммуникабельные развитые личности, но через несколько месяцев их вынуждены были попросить поискать другое место работы, естественно с потерей для проекта времени и денег. При этом нанимающие не были дураками... И вот и на собесах было красиво, и общий язык люди сразу со всеми находили. Только прямые обязанности по технической части не тянули, совсем. И как здесь на софтскилах выехать? Попросить коллег пописать за себя код за % от зп? =) При этом видел другой случай: человек полностью замкнут в себе, приходит на работу и садится за комп, говоря "Здравствуйте", вечером встает и говорит "До свидания", всё. Иногда немного не удобно, что чтобы что-то выяснить нужно задавать только конкретные вопросы и ответы получитьшь только на них, нужно еще что-то - уточняй, иначе можно упустить детали ("Эти ягоды есть можно?" - "Можно" - "А не отравлюсь?" - "Отравишься, но есть то можно"). Но это полностью компенсировалось тем, что знает человек просто дофига, а если не знает - разберется, и это того стоит. Как-то так...
Ну в М-кортексах можно (а может быть даже и лучше, т.к. чаще случается) заменить на "Hard Fault". Для особо забористых случаев еще спросить "В нашем случае PC в дампе регистров явно показывает не то значение, где происходит сбой, почему?"
Не всегда. Например если флэш организована с коррекцией ошибок, то дописывать если и можно, то нужно знать длину строк, на которые хранится ecc и выравнивание и писать только в полностью чистые, иначе отхватим ошибку памяти. Но вообще согласен, переписывание с единицы в ноль - это наверное то, о чем при вопросе про флэш сказать нужно обязательно. Про NOR/NAND думаю тоже, ибо в восьминогих корпусах есть и те и те, и важно понимать, почему они разные...
Я конечно не дипломиповпнных химик, но в данном случае не зарядом единым. Заряд можно пропустить и получить плохой результат: важен и электролит и температура и время. Потому так и ваходит. Может лично вам удобнее, но сомневаюсь, что вся отрасль просто не догадалась...
Это откуда такая информация?
Поискал информацию, в очередной раз убедился, что C это поле граблей, и некоторые мы подсознательно обходим...
Задумался что компилер уж при прямом то присваивании должен или предупредить или не паковать, но он как обычно никому ничего не должен. У меня просто выработалась привычка набивать структуры как в тетрисе - чтобы паддинг если и оставался - то в хвосте и в 90% случаев тогда и packed не нужен, само собой уляжется. Спасибо за интересный кейс.
Посыл понятен, но кажется таки на любом, ибо pack это "очень хочется сложить поплотнее", но если архитектура не позволяет кривой доступ, то компилер один фиг выравняет. Или я ошибаюсь?
А вот передать такую структуру "как есть" на другую архитектуру и на том конце привести ее в этому же типу без искажения уже не выйдет...
Никак. Это указание компилятору "не оптимизировать". С аппаратурой это никак не связано, утверждение выше про кеши не верно.
Т.е. обычно у вас i+=1 выглядит как чтение в регистр, модификация, запись.
Если вы напишите
while (i != 0) {
...
}
и при этом в цикле переменная не модифицируется, то с включенной оптимизацией компилятор имеет полное право один раз прочитать из памяти в регистр значение и дальше решить: если не 0, то бесконечный цикл. Потому что если в теле цикла переменная не меняется - то и измениться значение не может. Программа по умолчанию штука линейная. И вот volatile нужен как раз для того, чтобы сказать явно "не оптимизировать". Т.е. при каждой проверке условия компилер будет честно каждый раз читать память.
Поэтому тезис "переменная, которая может измениться в другом потоке должна быть помечена как volatile" очень упрощает, иногда портит производительность. Я встречал человека, который все переменные так объявлял. На мое удивление, ответил "чтобы наверняка".
Вообще многопоточное программирование и поведение компилятора - это не только про volatile, но еще и про кэши, барьеры памяти и т.п...
Бегите оттуда. Почему? Потому что это узкоспециализированная система. На реддите как-то была тема, и все кто изнутри в один голос говорили - что если смотреть на отрасль, то сидя на AUTOSAR вы стагнируете, ибо за его пределами все что вы за это время изучили - бесполезно...
Сколько нужно программистов чтобы вкрутить лампочку?
Под "полевым транзистором с индуцированным каналом" исторически имели ввиду обычно таки J-FET и думаю их смешивать несколько не справедливо
А мне кажется нет.
Вопросы в статье - явно на джуна, ваши же повыше ощутимо, думаю и то и то норм, но для разных собесов. То что из статьи - это проверить университетские знания + практические навыки при параллельной доподготовке. Т.е. выцепить качественного выпускника с некоторым доп опытом... Заметьте - там нет вопросов на опыт, в основном на типовую фундаментальную подготовку... У вас каждый вопрос по сути оставляет несколько трактовок и подразумевает знание банальных ответов, но ожидает не только лишь их )
Кстати добавлю: смысл в LowSpeed появляется при прохождении ЭМС или наличии чувствительных цепей на плате. Точнее это может влиять в определенных случаях.
Да, возможно я ошибаюсь, я сам был удивлен, но возможно и китайцы накосячили, т.к. к тому моменту как я присоединился к проблеме коллега уже пробовал замедлить шину донелзя, и нормальногу нуля там не образовалось. Это GD32F4 был.
Вот за этим и нужны эти вопросы. Понять ход мыслей и знание узких терминов (потому что команды ими общаются). В вопросе все логично, это не способ унизить, это про взаимодействие.
Можно, но в Java денег больше (сильно), я бы оставил любимое дело любимым делом =)
Исключения не в счет, ну и эти исключения - позиции с серьезным опытом, т.е. через N лет скорее всего.
Вот только достигается это все так же переключением выходного сопротивления. И вишенка здесь в том, что почти всегда это ни на что не влияет, человек привыкает, и потом выхватывает долгий поиск причины проблемы, когда это было важно. Коллега так нарвался на сбои в разветвленной I2C, еще и с трансляцией уровней через MOSFET, когда включенный в "low speed" порт просто не мог придавить к земле полностью шину, и одно из устройств не считало это нулем...
Ну т.е. получается они таки оказали человеку услугу, чтобы он время не терял. Считаю - не так уж и плохо, в конечном итоге.
В UDS вообще все очень просто:
UDS описывает общую идею и как это примерно должно работать
UDS оставляет производителям право поддерживать, не поддерживать либо менять под себя куски спецификации (на деле - что можно менять оговорено, но от этого не легче, ибо этого уж очень много).
В итоге имеем этакий очень обтекаемый простокол: у кого-то есть UDS, но в нем не поддерживается вообще никакой сахар. список DID есть у производителя, и этот список не сквозной, а разбит на кучку по 5 чисел. Причем разные части доступны в сессиях разного уровня, а в этих сессиях они доступны в разных режимах работы.
Короче говоря в стандарте очень много возможностей, но реальность такая, что большая часть из них не доступна.
Аргументируйте, пожалуйста.
Пару раз сталкивался, когда приходили на работу коммуникабельные развитые личности, но через несколько месяцев их вынуждены были попросить поискать другое место работы, естественно с потерей для проекта времени и денег. При этом нанимающие не были дураками... И вот и на собесах было красиво, и общий язык люди сразу со всеми находили. Только прямые обязанности по технической части не тянули, совсем. И как здесь на софтскилах выехать? Попросить коллег пописать за себя код за % от зп? =) При этом видел другой случай: человек полностью замкнут в себе, приходит на работу и садится за комп, говоря "Здравствуйте", вечером встает и говорит "До свидания", всё. Иногда немного не удобно, что чтобы что-то выяснить нужно задавать только конкретные вопросы и ответы получитьшь только на них, нужно еще что-то - уточняй, иначе можно упустить детали ("Эти ягоды есть можно?" - "Можно" - "А не отравлюсь?" - "Отравишься, но есть то можно"). Но это полностью компенсировалось тем, что знает человек просто дофига, а если не знает - разберется, и это того стоит. Как-то так...
Ну в М-кортексах можно (а может быть даже и лучше, т.к. чаще случается) заменить на "Hard Fault". Для особо забористых случаев еще спросить "В нашем случае PC в дампе регистров явно показывает не то значение, где происходит сбой, почему?"
Вот 2 слова "полоса пропускания" в нужную сторону, остальное - мимо.
Фурье бы по щам надавал, за такой ответ )
Не всегда. Например если флэш организована с коррекцией ошибок, то дописывать если и можно, то нужно знать длину строк, на которые хранится ecc и выравнивание и писать только в полностью чистые, иначе отхватим ошибку памяти. Но вообще согласен, переписывание с единицы в ноль - это наверное то, о чем при вопросе про флэш сказать нужно обязательно. Про NOR/NAND думаю тоже, ибо в восьминогих корпусах есть и те и те, и важно понимать, почему они разные...