А вам внутри самому удобно с этими порядками то? Мне - нет, родственникам и друзьям моим - тоже нет. Нашли тоже способ для проявления уважения - «мучайся как местные». Ещё какие-нибудь ямы на дороге защищать начните, объехал - не уважает!
Если редуцировать - да, тогда и 80% свободы и 8% свободы - одно и то же, «отсутствие полной свободы». Но есть нюанс.
Сторонники редуцирования, как у них принято, ответили своим главным аргументом - молчаливым минусованием здешнего неназываемого параметра. Ну значит, в точку.
Вы нейросеть репостите? Нет при чтении никакого «теста на скорость», падение скорости на просевших ячейках - несколько чтений с разными уровнями Vth (пороговое напряжение), они ничего не «подзаряжают», пускаем напряжение с ячейки на один вход компаратора, выбранный Vth - на другой, получаем 0/1 на выходе, а дальше по собранной статистике софтово (в прошивке) пытаемся вычислить, к чему ближе реальное хранимое значение. И сами чтения вообще вредны (см. “read disturb”), если без последующей перезаписи.
А то, что «ssd сами всё перезаписывают» - всего лишь предположение от надежд на лучшее, до сих пор не встретил ни одного внятного заявления производителя «такая-то модель делает это»,ю. Если кто даст ссылку на документацию, где такое заявлено, буду благодарен.
Это общеизвестная информация. А как вы «подпитывать» ячейки собирались, так и не рассказали. Потому что никак, только читать, стирать и записывать вычитанное назад. И миф о пользе подачи питания в изначальном виде как раз содержал идею, что контроллеры флешек занимаются этим в простое, но подтверждений этому до сих пор не нашли.
Как оно поступает в ячейку, которая в данный момент не читается и не пишется и соответственно, ни к чему не подключена? (посмотрите схему такой памяти, увидите, что ячейки в покое отключены).
А что сделает «подпитывание» (если бы оно работало) с ячейкой, в которой хранится единица, т.е. заряда изначально нет и «дозаряжать» её не нужно?
Да непривычно людям ещё. Племянник, хоть и матёрый ездок, несколько дней назад в жару встрял в очередь в первый раз, без малейшего представления о длительности, досидел с кондиционером до красной лампочки, запарковался и ушёл (на дизеле заглохнуть от полной выработки - потом то ещё удовольствие заполнить систему).
Интересно, откуда вообще пошла эта наркоманская идея «защиты» с закрытием только flash и свободным доступом ко всему остальному? «Раньше такого не было!»
USB interrupt endpoint может опрашиваться хостом хоть каждый фрейм - 1кГц для USB FS (и 8кГц для HS) и при наличии данных сразу отдать до 64 байт (до 1кБ в HS) в пределах этого же фрейма. RS-232 на 115200 8N1 за это время (1мс) на физическом уровне прокачает всего 11 байт - более чем сравнимые показатели, если речь идёт о событиях, требующих передачи каких-то данных, а не "однобитовых" сигналах через пины CTS/DSR/DCD.
Если вопрос в том, как именно хост узнаёт о наличии данных - да, через периодический опрос, на USB это "дёшево", прикладному софту отдельных действий на каждый фрейм не нужно (да и драйвер хост-контроллера тоже особо не утруждается, один раз собрать список Transaction Descriptor'ов для повторяющихся действий и железо будет ему следовать).
Да, был неправ. Полез читать подробнее, наткнулся на обсуждение сна MicroPython’щиками, и там человек пишет, что сначала на примере из C SDK получил около 800мкА (близко к вашему результату), затем портировал процедуру входа в DORMANT с С на MicroPython и внезапно получил уже 300мкА, сам удивляется. Подозреваю, в Python иначе настроены какие-то не относящиеся напрямую ко сну вещи, например, режимы GPIO. Вот и ниже пишут про вред свободно плавающих входов.
А не пробовали перед сном перейти не на внешний кварц, а на внутренний ROSC (а кварц остановить)? Он и медленнее, и по самой технологии должен быть менее прожорлив.
Недавно натыкался на специализированный МК для управления мотором - Nuvoton NM1520, так у него целый отдельный периферийный модуль интерфейса экнодера оказался, фильтрует дребезг, определяет направление вращения (и его смену), отсчитывает время от сигнала нулевого положения итд, красота!
Я в курсе, что компиляторы Zig/Rust делают куда большую работу по проверке логики на этапе компиляции, это здорово, но мои потребности в выискивании nullов не настолько велики, чтобы менять язык. А вот от компилятора C очень хотелось бы в случаях, где он в рамках текущих его возможностей уженаходит потенциальные проблемы, получать не молча заложенную в машинный код мину, а warning. Люди, конечно, порой всякое программируют, но всё-таки молча тактовать каждый найденный null dereference как намеренное желание упасть, пожалуй, перебор. К тому же, оцените иронию, схожее по суицидальности намеренное желание зависнуть (циклы вида while(true) {}) свежие стандарты С трактуют как неопределённое поведение и превращают в "тыкву". Эмбедчики теперь в конце main(), из которой на голом железе возвращаться некуда, вместо while(1) {} пишут while(1) { __asm("NOP"); }. Так почему упасть помогают, а зависнуть - нет? :)
А вам внутри самому удобно с этими порядками то? Мне - нет, родственникам и друзьям моим - тоже нет. Нашли тоже способ для проявления уважения - «мучайся как местные». Ещё какие-нибудь ямы на дороге защищать начните, объехал - не уважает!
Если редуцировать - да, тогда и 80% свободы и 8% свободы - одно и то же, «отсутствие полной свободы». Но есть нюанс.
Сторонники редуцирования, как у них принято, ответили своим главным аргументом - молчаливым минусованием здешнего неназываемого параметра. Ну значит, в точку.
«Везде всё так же!» - главная российская скрепа.
В том, что заряд утекает, сомнений не было. Вопрос был к вашей «подпитке», и никакой конкретики по нему вы так и не выдали. У меня, пожалуй, всё.
Вы нейросеть репостите? Нет при чтении никакого «теста на скорость», падение скорости на просевших ячейках - несколько чтений с разными уровнями Vth (пороговое напряжение), они ничего не «подзаряжают», пускаем напряжение с ячейки на один вход компаратора, выбранный Vth - на другой, получаем 0/1 на выходе, а дальше по собранной статистике софтово (в прошивке) пытаемся вычислить, к чему ближе реальное хранимое значение. И сами чтения вообще вредны (см. “read disturb”), если без последующей перезаписи.
А то, что «ssd сами всё перезаписывают» - всего лишь предположение от надежд на лучшее, до сих пор не встретил ни одного внятного заявления производителя «такая-то модель делает это»,ю. Если кто даст ссылку на документацию, где такое заявлено, буду благодарен.
Это общеизвестная информация. А как вы «подпитывать» ячейки собирались, так и не рассказали. Потому что никак, только читать, стирать и записывать вычитанное назад. И миф о пользе подачи питания в изначальном виде как раз содержал идею, что контроллеры флешек занимаются этим в простое, но подтверждений этому до сих пор не нашли.
И как вы себе представляете это «подпитывание»?
Как оно поступает в ячейку, которая в данный момент не читается и не пишется и соответственно, ни к чему не подключена? (посмотрите схему такой памяти, увидите, что ячейки в покое отключены).
А что сделает «подпитывание» (если бы оно работало) с ячейкой, в которой хранится единица, т.е. заряда изначально нет и «дозаряжать» её не нужно?
«Подпитывание» флешки - миф, раздутый журналистами, но не подтверждённый ни одним экспериментом.
Да непривычно людям ещё. Племянник, хоть и матёрый ездок, несколько дней назад в жару встрял в очередь в первый раз, без малейшего представления о длительности, досидел с кондиционером до красной лампочки, запарковался и ушёл (на дизеле заглохнуть от полной выработки - потом то ещё удовольствие заполнить систему).
В честь одного известного прицепа назвали?</s>
Интересно, откуда вообще пошла эта наркоманская идея «защиты» с закрытием только flash и свободным доступом ко всему остальному? «Раньше такого не было!»
Прочитал заголовок как «лунной АЗС», актуальнее
Little
USB interrupt endpoint может опрашиваться хостом хоть каждый фрейм - 1кГц для USB FS (и 8кГц для HS) и при наличии данных сразу отдать до 64 байт (до 1кБ в HS) в пределах этого же фрейма. RS-232 на 115200 8N1 за это время (1мс) на физическом уровне прокачает всего 11 байт - более чем сравнимые показатели, если речь идёт о событиях, требующих передачи каких-то данных, а не "однобитовых" сигналах через пины CTS/DSR/DCD.
Если вопрос в том, как именно хост узнаёт о наличии данных - да, через периодический опрос, на USB это "дёшево", прикладному софту отдельных действий на каждый фрейм не нужно (да и драйвер хост-контроллера тоже особо не утруждается, один раз собрать список Transaction Descriptor'ов для повторяющихся действий и железо будет ему следовать).
Да, был неправ. Полез читать подробнее, наткнулся на обсуждение сна MicroPython’щиками, и там человек пишет, что сначала на примере из C SDK получил около 800мкА (близко к вашему результату), затем портировал процедуру входа в DORMANT с С на MicroPython и внезапно получил уже 300мкА, сам удивляется. Подозреваю, в Python иначе настроены какие-то не относящиеся напрямую ко сну вещи, например, режимы GPIO. Вот и ниже пишут про вред свободно плавающих входов.
А не пробовали перед сном перейти не на внешний кварц, а на внутренний ROSC (а кварц остановить)? Он и медленнее, и по самой технологии должен быть менее прожорлив.
Блинообразная форма эта просится в двухколёсную технику прямо в колёса
Недавно натыкался на специализированный МК для управления мотором - Nuvoton NM1520, так у него целый отдельный периферийный модуль интерфейса экнодера оказался, фильтрует дребезг, определяет направление вращения (и его смену), отсчитывает время от сигнала нулевого положения итд, красота!
Так GoPro, по крайней мере, раньше, на вставную MicroSD писали (покупку которой можно переложить на плечи пользователя).
Я в курсе, что компиляторы Zig/Rust делают куда большую работу по проверке логики на этапе компиляции, это здорово, но мои потребности в выискивании nullов не настолько велики, чтобы менять язык. А вот от компилятора C очень хотелось бы в случаях, где он в рамках текущих его возможностей уже находит потенциальные проблемы, получать не молча заложенную в машинный код мину, а warning. Люди, конечно, порой всякое программируют, но всё-таки молча тактовать каждый найденный null dereference как намеренное желание упасть, пожалуй, перебор. К тому же, оцените иронию, схожее по суицидальности намеренное желание зависнуть (циклы вида while(true) {}) свежие стандарты С трактуют как неопределённое поведение и превращают в "тыкву". Эмбедчики теперь в конце main(), из которой на голом железе возвращаться некуда, вместо while(1) {} пишут while(1) { __asm("NOP"); }. Так почему упасть помогают, а зависнуть - нет? :)