Такую же задачу, как Вы со шнековой печатью краской, пытаются решить для нанесения паяльной пасты на печатные платы производители станков для прототипирования. Недавно тут была подробная статья про станок немецкого производителя. Результат на мой взгляд как-бы не очень, несмотря на все старания шелкография через тонкий лист нержавеющей стали с вырезанными лазером отверстиями вне конкуренции. В статье подробно этот процесс расписан начиная с калибровки размера точки. Очень нестабильно, много различных факторов надо учитывать.
Сначала подумал что Вы попытаетесь сделать сетку для шелкографии на 3D-принтере. А резиноподобным пластиком печатать не пробовали?
Я разработчик полного стека (javascript | typescript | react | react native | node) и студент факультета компьютерных наук. Здесь я пишу о том, чему я учусь на своем пути к тому, чтобы стать лучшим разработчиком, каким я могу быть.
Студент пишет о том, чему его учат. Все претензии к его преподавателям :)
Да и статья в оригинале называется "Object-Oriented Programming in JavaScript for Beginners"
Наверное на это товарищу Germán Cocca надо указать. Автор тут только переводчик как я понял.
Germán Cocca I'm a full stack dev (javascript | typescript | react | react native | node) and computer science student. Here I write about the things I learn along my path to becoming the best developer I can be.
camelCase - Первое слово пишется со строчной буквы, следующие — с заглавной, разделителей между составными частями нет.
...
PascalCase - Тот же camelCase, но все слова, даже первое, начинаются с заглавной буквы.
...
Иногда Pascal case называют upper camel case или, наоборот, camel case называют low Pascal case.
IMHO - PascalCase это всегда PascalCase, а вот camelCase без (upper) и (lower) это х.з. что, по этому автор и уточняет регистр первой буквы. Изначально у вас все было правильно, "capital first letter and camelCase" и "с первой заглавной буквы и прописываются в верблюжьем регистре" - формально одно и то же, только общепринятый термин переводить не стоило.
"Прописываются" - это нотация, т.е. "По соглашению классы именуются в нотации camelCase с первой прописной буквой" (с первой буквой в верхнем регистре) или, что более понятно, "По соглашению классы именуются в нотации UpperCamelCase".
Снова исправлять ничего не надо, спасибо napa3um-у, уже все хорошо :)
то есть для поддержки транзакционной записи особенной разницы нет — CRC16 или 2 счетчика.Но счетчики в 8-битном контроллере немного быстрее ;)
Не смешно, по причинам:
1. Главное галочку поставить, а целостность содержимого пакета вас не интересует? Способы испортить пакет после его записи в еепром перечислить?
2. Ещё раз спрошу, за время записи одного байта в еепром, сколько раз можно CRC пакета табличным способом подсчитать?
3. Андуина — это только ATMega8? Про ардуины на STM32 не слышали, не? И про их аппаратный модуль расчёта CRC тоже не в курсе?
4. Сохранение данных в еепром эксклюзивно в ардуине используется, другие МК их на бумажку записывают?
5. Просто любопытно, а где в МК счётчики, которые 'немного быстрее'?
Ну ок. Зачем еще может понадобиться в однозадачной среде транзакционная запись?
Это фейспалм! Извините великодушно, не удержался. И действительно, зачем?
К тому же с чего вы решили что она однозадачная? Это где-то оговаривалось? RTOS на ATMega8 никто не запрещал.
Но один байт либо запишется весь, либо не запишется тоже весь.
Мне этот аргумент кажется очень притянутым. При таком времени записи пропадание/просадка питания имеет далеко ненулевую вероятность. Но к теме это отношения не имеет.
Если же это относится только к EEPROM — надо начинать с datasheet'ов. Там должно быть про это написано. Или не написано ;)
Действительно, может перед тем как разводить флейм, стоит почитать даташиты, начать с AVR104 например? Или спросить у гугла 'atmega eeprom проблемы'?
Или посмотреть ваш профиль.
тогда вы начинаете решать придуманную проблемму.
Автор затронул реальную проблему, на которую новички не обращают внимания. Привязывать её к Ардуине необязательно, еепром может быть внешней, или её может не быть совсем и использоваться часть флэша для сохранения данных. Проблем с ними ещё больше.
Затронута серьёзная проблема. Предложенное решение, на мой взгляд, не идеальное, но автор даёт хороший повод задуматься и возможность разрабатывать свою систему уже не на пустом месте.
Не нужно путать контроль целостности (для этого годится CRC) и атомарность записи (для этого флажки-счетчики размером в 1 байт — eeprom в avr работает с байтами — отлично подходят).
1. Не нужно путать, нужно знать. Что CRC8 имеет размер ровно в один байт и гораздо информативнее 'флажка-счетчика'.
2. Атомарность? Сколько команд 'avr'(?) требуется для записи одного байта в EEPROM? Сколько времени занимает запись одного байта?
Может и сойтись. Откуда вы знаете, что находится в той области, куда CRC не дописалось?
1. Может. Какова вероятность?
2. Ничего не находится, пусто там. Предварительная запись 0xFF ресурс не расходует. Но это не важно при правильной финализации. Не?
А то и навредить; при аварийном сохранении данных на расчеты может не хватить времени.
1. Не покажите, где автор говорил про аварийное сохранение?
2. Спрошу повторно, сколько времени 'avr'(?) записывает один байт в EEPROM? Сколько за это время можно сделать 'расчетов'?
Не всегда… Иногда выбор может сильно повлиять и на вторую часть и на третью…
А что не так? Линейность игры от этого не нарушается. Повлиять — да, многовариантность всегда интересна. В той же цивилке есть шанс проиграть на первом ходу, но менее интересной от этого она не стала. Кстати это к вопросу рандомной генерации начальных условий игры. К примеру карточные игры, всего тридцать шесть спрайтов…
Сложность <> интересность — выражение спорное и неоднозначное. Повторю про баланс, если сложность пропорционально увеличивает вариантность то игра становится только интереснее (гранд-стратегии). А если только добавляет занудства, то увы. Это очень тонкая грань.
В таком случае он и в игре под названием «жизнь» абсолютно линеен — родился, жил, умер. Вариантов нет, но от возможности поиграть мало кто отказывается.
Первая или вторая — не роляет, но вот потом баланс потеряли. Усложнение и украшение новых версий популярности не добавило, наоборот.
В старых играх сюжет, по большей части, линеен. Или нелинеен в несущественной части.
Расскажите это засыпавшим перед монитором игрокам во вторую цивилку, твердившим ночи напролёт «ещё один ход и выключаю». Не было в ней графики и анимации, она была как книга, каждый видел её по своему. И с удовольствием перечитывал, раз за разом находя что то новое.
За Кирандию не скажу, а приводить в качестве примера вторую дюну как бы не стоит. Вся её прелесть была в прорисованных со всех сторон машинках, а весь элемент неожиданности в червяке. Включил, посмотрел, выключил.
Баланс был в старых играх, сложность на грани. По этому было желание играть много раз, оттачивая мастерство, поднимая свой уровень. И чем лучше ты играл, тем сложнее становилась игра (и в плане выбора уровня сложности тоже).
Мне кажется автор не учитывает ещё одну особенность старых интересных игр, называемую имитацией полезной деятельности. Эффект, заставляющий чувствовать что занимаешься полезным делом и мешающий прекратить игру. Желание играть в неё снова и занимаясь фигней чувствовать себя комфортно.
А где у них такое было? Наоборот на 3DNews типичные результаты тестирования получались в разы иногда больше чем на порядок выше заявленных производителями ресурсов.
Это написано не в самой статье, а в результатах тестирования
Выносливость новой версии Western Digital Blue 3D NAND оказалась драматически низка: этот накопитель не только не смог перенести запись заявленного в условиях гарантии объёма, но и установил новый антирекорд надёжности – 82 Тбайт.
Значит комфорт не всем дискам одинаково полезен?
В этой статье хорошо описывает как раз почему — очень уж «комфортные» условия работы у дисков в таких тестах по сравнению с реальными условиями эксплуатации.
Вот и мне интересно почему. Почему он умер в таких комфортных условиях? И сколько реально проживет согласно приведенных выше поправок к методике тестирования?
Автор проделал большую работу. Я усомнился только в однозначности выводов, имея на входе лишь предположения об алгоритмах работы микропрограммы диска. Не думаю что ценность статьи от этого уменьшилась.
Вы не представляете с каким трудом множество людей абстрагируется от непосредственно того, что видит конкретно в текущий момент. И никакие «волшебные пассы руками» и заверения «попробуйте представить себе» не помогают. Он не знает, что хочет и по этому не увидит ничего, кроме того что видит тут и сейчас.
Метод автора — хорошая попытка разбудить фантазию клиента. Но с другой стороны легко нарваться на ситуацию «давычёсделалито! я совсем не так себе это представлял». Проблема точного техзадания.
А так то мне, к примеру, было бы быстрее эти формы в IDE набросать и создать минимальное взаимодействие, чем бумажки резать. Но это плохой путь, заказчик скажет «не нравится» и не докажешь ему что это прототип. Так что прав автор, пусть сам выдумывает что хочет, главное потом узнать что за фантазии у него были…
Распечатать? Не-е-е, тёплый ламповый рисунок ручкой на бумаге для заказчика куда притягательнее, особенно выполненный в цвете! Сразу видно что старались, готовились, а на принтере каждый может. Вобщем перьевой графопостроитель рулит!
А зачем регистр обнулять? Обнуляется (устанавливается в исходное положение) автомат сложения. Первая запись в регистр заносит число в стек (адрес 0) и двигает указатель вверх, вторая запись заносит число в стек (адрес 1), двигает указатель вниз и запускает сумматор. Результат в стек (адрес 0) и автомат в исходное положение (обнулить).
Можно вариант с бесконечным суммированием, каждая запись прибавляется к предыдущей, реального стека нет. При первой записи в ячейке памяти с суммой был ноль, а всё, что пишется в регистр, к ней прибавляется. Чтение выдает сумму и сбрасывает ячейку памяти-сумматор в ноль. Так второй раз прочитать сумму нельзя. Но если добавить флаг «было чтение», то можно, сумма обнулится при следующей записи со сбросом флага.
Примечание: чтение и запись в один регистр могут адресоваться к разным адресам памяти. Например запись к реальной ячейке памяти, содержимое которой приплюсуется к сумме, а чтение к ячейке памяти в которой эта сумма хранится.
Ещё интереснее было бы послушать разработчиков ПО контроллера диска. Без знания алгоритма его работы любые тестирования — гадание на кофейной гуще.
Например тест 3DNews показывает что диск и половины заявленного объёма не запишет, а производитель даёт гарантию 5 лет или 100 Тб. Видимо у них свои тесты.
Но сильно сомневаюсь в их желании беседовать на эту тему.
После нескольких сот тысяч чтений заряд в любом случае теряется.
Исходя из чего вы решили что он теряется при чтении «в любом случае»? И откуда данные про «несколько сот тысяч»?
Просто интересно, насколько я знаю, в микроконтроллерах используется подобная электрически перепрограммируемая память для прошивки и хранения данных. И без каких либо «обновлений» там годами производится несколько «сот тысяч чтений» в секунду. И ни один известный мне производитель не устанавливает ограничение на число чтений. Только на циклы стирание-запись и хранение.
«При типичной температуре 50℃ эксплуатации под нагрузкой накопитель должен обеспечивать 58 недель ≈ 1 год хранения данных в отключенном состоянии при 25℃.»
Вопрос: если накопитель находится во включенном состоянии, то заряд не утекает?
Год при условии если накопитель уже выработал свой ресурс. Бытовой накопитель.
А что ему мешает утекать при поданном питании? Контроллер, когда ему нефик делать, многократно читает и сравнивает записанные данные. При частичной потере заряда чтение нестабильное. Дальнейшие действия на его усмотрение. Питания нет — проверять некому… я так думаю.
<Таким образом вопрос сводится скорее к «как происходит рефреш в ячейках?» — как в DRAM, с некоторой периодичностью или методом «очистить блок, записать заново»?
Думаю с некоторой периодичностью методом «очистить блок, записать заново». А разве есть другие варианты?
Такую же задачу, как Вы со шнековой печатью краской, пытаются решить для нанесения паяльной пасты на печатные платы производители станков для прототипирования. Недавно тут была подробная статья про станок немецкого производителя. Результат на мой взгляд как-бы не очень, несмотря на все старания шелкография через тонкий лист нержавеющей стали с вырезанными лазером отверстиями вне конкуренции. В статье подробно этот процесс расписан начиная с калибровки размера точки. Очень нестабильно, много различных факторов надо учитывать.
Сначала подумал что Вы попытаетесь сделать сетку для шелкографии на 3D-принтере. А резиноподобным пластиком печатать не пробовали?
Студент пишет о том, чему его учат. Все претензии к его преподавателям :)
Да и статья в оригинале называется "Object-Oriented Programming in JavaScript for Beginners"
Наверное на это товарищу Germán Cocca надо указать. Автор тут только переводчик как я понял.
Опасную тему затрагиваете однако. Статью про "табы против" с Хабра неспроста убрали. Я так думаю :)
https://ru.wikipedia.org/wiki/CamelCase
https://ru.wikipedia.org/wiki/Соглашения_об_именах_(программирование)#JavaScript
https://skillbox.ru/media/code/notatsii-v-programmirovanii/
IMHO - PascalCase это всегда PascalCase, а вот camelCase без (upper) и (lower) это х.з. что, по этому автор и уточняет регистр первой буквы. Изначально у вас все было правильно, "capital first letter and camelCase" и "с первой заглавной буквы и прописываются в верблюжьем регистре" - формально одно и то же, только общепринятый термин переводить не стоило.
"Прописываются" - это нотация, т.е. "По соглашению классы именуются в нотации camelCase с первой прописной буквой" (с первой буквой в верхнем регистре) или, что более понятно, "По соглашению классы именуются в нотации UpperCamelCase".
Снова исправлять ничего не надо, спасибо napa3um-у, уже все хорошо :)
1. Главное галочку поставить, а целостность содержимого пакета вас не интересует? Способы испортить пакет после его записи в еепром перечислить?
2. Ещё раз спрошу, за время записи одного байта в еепром, сколько раз можно CRC пакета табличным способом подсчитать?
3. Андуина — это только ATMega8? Про ардуины на STM32 не слышали, не? И про их аппаратный модуль расчёта CRC тоже не в курсе?
4. Сохранение данных в еепром эксклюзивно в ардуине используется, другие МК их на бумажку записывают?
5. Просто любопытно, а где в МК счётчики, которые 'немного быстрее'?
Это фейспалм! Извините великодушно, не удержался. И действительно, зачем?
К тому же с чего вы решили что она однозадачная? Это где-то оговаривалось? RTOS на ATMega8 никто не запрещал.
Мне этот аргумент кажется очень притянутым. При таком времени записи пропадание/просадка питания имеет далеко ненулевую вероятность. Но к теме это отношения не имеет.
Или посмотреть ваш профиль.
Автор затронул реальную проблему, на которую новички не обращают внимания. Привязывать её к Ардуине необязательно, еепром может быть внешней, или её может не быть совсем и использоваться часть флэша для сохранения данных. Проблем с ними ещё больше.
2. Атомарность? Сколько команд 'avr'(?) требуется для записи одного байта в EEPROM? Сколько времени занимает запись одного байта?
1. Может. Какова вероятность?
2. Ничего не находится, пусто там. Предварительная запись 0xFF ресурс не расходует. Но это не важно при правильной финализации. Не?
1. Не покажите, где автор говорил про аварийное сохранение?
2. Спрошу повторно, сколько времени 'avr'(?) записывает один байт в EEPROM? Сколько за это время можно сделать 'расчетов'?
Извините, не удержался, заглянул в ваш профиль.
Сложность <> интересность — выражение спорное и неоднозначное. Повторю про баланс, если сложность пропорционально увеличивает вариантность то игра становится только интереснее (гранд-стратегии). А если только добавляет занудства, то увы. Это очень тонкая грань.
Первая или вторая — не роляет, но вот потом баланс потеряли. Усложнение и украшение новых версий популярности не добавило, наоборот.
За Кирандию не скажу, а приводить в качестве примера вторую дюну как бы не стоит. Вся её прелесть была в прорисованных со всех сторон машинках, а весь элемент неожиданности в червяке. Включил, посмотрел, выключил.
Баланс был в старых играх, сложность на грани. По этому было желание играть много раз, оттачивая мастерство, поднимая свой уровень. И чем лучше ты играл, тем сложнее становилась игра (и в плане выбора уровня сложности тоже).
Мне кажется автор не учитывает ещё одну особенность старых интересных игр, называемую имитацией полезной деятельности. Эффект, заставляющий чувствовать что занимаешься полезным делом и мешающий прекратить игру. Желание играть в неё снова и занимаясь фигней чувствовать себя комфортно.
Автор проделал большую работу. Я усомнился только в однозначности выводов, имея на входе лишь предположения об алгоритмах работы микропрограммы диска. Не думаю что ценность статьи от этого уменьшилась.
Метод автора — хорошая попытка разбудить фантазию клиента. Но с другой стороны легко нарваться на ситуацию «давычёсделалито! я совсем не так себе это представлял». Проблема точного техзадания.
А так то мне, к примеру, было бы быстрее эти формы в IDE набросать и создать минимальное взаимодействие, чем бумажки резать. Но это плохой путь, заказчик скажет «не нравится» и не докажешь ему что это прототип. Так что прав автор, пусть сам выдумывает что хочет, главное потом узнать что за фантазии у него были…
Распечатать? Не-е-е, тёплый ламповый рисунок ручкой на бумаге для заказчика куда притягательнее, особенно выполненный в цвете! Сразу видно что старались, готовились, а на принтере каждый может. Вобщем перьевой графопостроитель рулит!
Он же образно выражался.
Move имеет два операнда, куда и откуда.
Move туда — это Set, Move обратно — это Get.
Можно вариант с бесконечным суммированием, каждая запись прибавляется к предыдущей, реального стека нет. При первой записи в ячейке памяти с суммой был ноль, а всё, что пишется в регистр, к ней прибавляется. Чтение выдает сумму и сбрасывает ячейку памяти-сумматор в ноль. Так второй раз прочитать сумму нельзя. Но если добавить флаг «было чтение», то можно, сумма обнулится при следующей записи со сбросом флага.
Примечание: чтение и запись в один регистр могут адресоваться к разным адресам памяти. Например запись к реальной ячейке памяти, содержимое которой приплюсуется к сумме, а чтение к ячейке памяти в которой эта сумма хранится.
Например тест 3DNews показывает что диск и половины заявленного объёма не запишет, а производитель даёт гарантию 5 лет или 100 Тб. Видимо у них свои тесты.
Но сильно сомневаюсь в их желании беседовать на эту тему.
Просто интересно, насколько я знаю, в микроконтроллерах используется подобная электрически перепрограммируемая память для прошивки и хранения данных. И без каких либо «обновлений» там годами производится несколько «сот тысяч чтений» в секунду. И ни один известный мне производитель не устанавливает ограничение на число чтений. Только на циклы стирание-запись и хранение.
А что ему мешает утекать при поданном питании? Контроллер, когда ему нефик делать, многократно читает и сравнивает записанные данные. При частичной потере заряда чтение нестабильное. Дальнейшие действия на его усмотрение. Питания нет — проверять некому… я так думаю.
Думаю с некоторой периодичностью методом «очистить блок, записать заново». А разве есть другие варианты?