mplata

Я спорить не буду, каждый выбирает свой метод. По поводу ТЗ очень часто заказчик по ходу разработки хочет что-то дополнить. Можно формально поступить: извините этого не было в ТЗ, а можно пойти на встречу. Тут опять каждый решает сам. У нас нет проблем что то добавить, Доп соглашение и вперед. А скрам позволяет безболезненно решить это. Я понял, что у вас по другому, но у нас иначе и самое главное это прекрасно работает. Отнимает в среднем 15 минут в день.

Скрам это юнит экономика. Можно все что угодно разрабатывать в нем. Да не для огромных проектов , там канбан лучше идёт. В Вашем примере вполне возможен такой результат: сделали ТЗ, начали работу, через месяц проверяем что сделано и оказывается что сделано не совсем то или вообще ничего. А так как часто заказчик по ходу разработки меняет или дополняет что то то через этот самый месяц получается катастрофа. Этого не происходит в скраме, более того все участники знают что происходит на других направлениях, когда поступают комплектующие, когда можно приступать к выпуску КД, когда нужно отдать корпус в покраску. Все прозрачно и без нервов. У нас это прижилось и работает просто великолепно. А главное в начале стринта нет необходимости каждому перегружать себя, вешаешь на себя посильную ношу. Все довольны.

можно в личку.

Разработка относительно несложных Embedded проектов от архитектуры до серийного производства (собственные мощности), Что нужно будет делать: - разработка электрических принципиальных схем; - разработка топологии; - трассировка печатных плат; - программирование микроконтроллеров (STM32, AVR ATMega) разработка низкоуровневого ПО (С, С++); - запуск, тестирование и отладка опытных образцов изделий; - разработка КД к разрабатываемым изделиям; - участие в подготовке проектов к серии. Что мы ждём от кандидатов: - высшее техническое образование в области электроники и электротехники; - знание ЕСКД - знание основ электроники, цифровой и аналоговой техники; - знания современной элементной базы; - опыт монтажа, регулировки и ремонта электронных устройств; - знание пакета Altium Designer, PCAD2001+ (архивные проекты); - навыки быстрого изучения и внедрения интерфейсов (например LoRa, LoRaWAN, Ethernet, USB и пр.) - английский язык (технический) - хорошее знание С, С++ (качественный, понятный, чистый код с комментариями) - опыт работы с RTOS для микроконтроллеров. - понимание работы процессора и периферии на низком уровне. - работа в системе контроля версий. Работа удаленная, но в г. Москва или ближайшей области, так как требуется участие в переговорах и приезды для экспериментов и передачи документации и комплектующих (спаянные платы, компоненты, исполнительные устройства). Работать нужно в СКРАМ системе управления проектами, спринтами по 2 недели в ведением проектов в Битрикс24 под управлением руководителя. Работа по совмещению недопустима. Большая вероятность того, что с осени будет предоставлена бронь от мобилизации. Выезд за границу свободный. Работа по ТК РФ. На испытательный срок (3мес) оклад чистыми (на руки) 200 000р. После 250 000р. Далее рост в зависимости от успехов. Справки 2НДФЛ для получения кредитов. Ипотека 5-6%. Токсичных людей нет. Есть у кого что-то спросить, но полноценная школа не предполагается. Ищем человека имеющего опыт.

То есть это: 1. embedded разработчик, 2. тополог PCB, 3. оператор автоматической линии, 4. технолог PCB, 5. сотрудник ОТК, 6. отработчик с навыками ремонта 7. складской сотрудник с навыками входного контроля ОТК как элементной базы так и плат 8. Технолог SMA 9. Тестировщик 10. Наладчик линии SMT с навыками написания и оптимизации программ для станков, наладки профилей, наладки принтеров трафаретной печати. То есть Вы потенциально ищете 10 в 1. Но даже если взять 3. и 10. больше ни на что времени у кандидата не будет. Очень странная вакансия.

По моему неплохой вариант! Все правила соблюдены. Количество ключей в каждом генераторе тоже достаточно велико. Есть где-то описание прямо на пальцах данного генератора?

Да я прошу прощения не посмотрел, это у Вас в цитате было и форум присвоил это Вам, хотя это было цитатой другого участника. А я не увидел этого после публикации. Количество устройств ключей довольно приличное: десятки миллионов.

За глаза и уши. Вопрос как его реализовать. Разумеется можно использовать м/с памяти для хранения уже сформированных кодов (ключей). Но! мне то нужно чтобы не только в данном генераторе числа были разные, но и в других генераторах тоже. то есть базовые числа будут 100% разные по тому же Вихрю Мерсенна, а вот будут ли соседние генераторы пересекаться друг с другом. Они не должны. То есть есть несколько прошивальщиков ключей, они не связаны друг с другом. и накопление истории одного не дает гарантии что в другом генераторе не будет такого-же числа. в итоге могут получиться одинаковые ключи что дискредитирует систему в целом. Да, можно использовать номер генератора в теле ключа, но это мне кажется какой-то подсказкой для тех кто захочет попробовать сгенерировать ключ который окажется подходящим.

А есть где то почитать про это? И примеры построения таких последовательностей.

А в SHA-3 эта вероятность получается 2^-256? Неужели нет алгоритма в котором первые 10^8 не повторяются гарантированно?

Я про то что мы ксорим две части ключа и получаем половинный ключ (нужной длины). Затем с новым ключом делаем тоже самое. И так далее. Так вот не получится ли что в новой отксоренной последовательности встретятся одинаковые ключи?

А если после ксора будут одинаковые ключи?

Хэш это отлично, но там 256 разрядов минимум. А мне нужно максимум 128.

По rfid прошивать уникальный код доступа электронного ключа скуд. Программаторы имеют уникальные серийные номера. Повторение приведет к тому что тот кто не должен тот получает доступ туда куда нельзя. Это если грубо.

У моего 256к объем Флэш памяти. ( Ну пока решения нет, вот прям четкого и понятного с гарантированным неповторением в генерируемой последовательности. К сожалению.

https://github.com/AxxAxx/AxxSolder Места там много. По поводу температы тоже нестрашны, там плата стоковая закрывает трансформатор.

В принципе период повторяемости минимум через 10^8 генераций с учетом начального числа в виде серийного номера будет супер результатом! Но если это будет через 1000 генераций это провал конечно. однозначно стартовое число будет разным, но! как гарантировать, что при начальном числе 000000001 и 00000002 последовательности не будут содержать одинаковых значений на периоде 10^8 генераций. Чтобы они не пересекались.

Тем не менее. Важно чтобы в течение максимального периода не было повторений. Важно именно максимально увеличить период без повторений.

Базовое число начала последовательности будет опираться на серийный номер изделия который уникален.

Все не так просто. К сожалению мне нужна последовательность случайных чисел без повторов. А не просто генератор. В данном стм нет аппаратного генератора.

Добрый день. Есть необходимость генерации последовательности случайных чисел в диапазоне 2^128. Ключевое требование нет повторений, и нет элементарных чисел типа 00000....001 и т.п. Есть ресурсы где можно почитать про это?

Задача решена.

Задача решена.

Пояснения к задаче, которое возможно поможет принять решение и оценить задачу максимально полно: Задача №1 Паяльные станции. Цель: индикация температуры с точностью +-5С (выше не требуется, так как нам нужно следить за значительными изменениями, а не за точностью настроек паяльника. То есть важно понять, что температура, например, не 310, а 400) Все паяльные станции находятся на одном этаже на площади 500м2. Максимальное расстояние между крайними станциями 60м. Стены из ГКЛ, поэтому та же ЛоРа справится без проблем. Паяльные станции четырех видов: 1. JBC 2. Weller старый WD1000 3. Weller новый тип 1 4. Weller новый тип 2 С каждым видом нужно будет разбираться отдельно. Что касается JBC то кто-то выложил на гитхабе прошивку, сырцы и файлы сапр плат управления, что может послужить поводом к коррекции работы процессора (STM32) и упростить задачу считывания температуры. Также один из новых типов Weller использует K тип термопару, которую можно подключить к микросхеме https://robotchip.ru/obzor-modulya-preobrazovatelya-termopary-na-max6675/ что облегчит считывание, даже параллельное подключение не изменит значительно данные. Интервал получения данных достаточно каждые 3-5 минут. Выберем на этапе отладки. Или работать по алгоритму, который я описал ниже. Так как видов станций 4 то и видов устройств контроля будет также 4. Каждый вид со своим контроллером. Возможность обратной связи будет плюсом (пьезодинамик на борту, который пикает при превышении, и привлекает внимание технолога и бригадира. Сброс сигнала возможен только отключением питания.), но это не обязательно. Таким образом получается, что все паяльные станции через заданный интервал времени отправляют данные о своем состоянии (температура, номер канала (есть двухканальные), номер паяльной станции) на некую базовую станцию (для ЛоРы она может быть покупная у Веги, например). Одна такая БС может служить коллектором данных со всех устройств (не только паяльных станций). БС от веги на Линукс с открытой возможностью обработки данных. Задача №2. Печи. Задача несколько проще так как во всех печах используются только термопары и только К типа. Поэтому есть смысл взять и распараллелить, и объединить датчики для К термопары из Задачи №1, то есть у нас разное количество зон в каждой печи, но можно сделать например 28 канальное устройство состоящее (зоны делятся на нижний и верхний ТЭНы, и там стоят разные термопары). Далее все 28 температур и номер печи передаются на БС, где обрабатываются пакеты. Так как количество каналов взято с избытком, то при покупке новых печей не потребуется ничего менять кроме номера печи. Считывание температур происходит с периодом 6 минут (цикл пайки) чтобы вовремя засечь снижение или превышение температуры. По поводу алгоритма работы. Вообще разумно передавать температуру только если она меняется более чем на заданное количество градусов. Если все в порядке можно передавать контрольный пакет с текущей температурой раз в заданный период чтобы понимать работает ли передатчик или нет. Уверен это резко сократит траффик радиоканала. Единственная проблема в данном случае – это понимание, что паяльная станция или печь выключились. В этом случае нужно предусматривать автономное питание для передачи пакета окончания работы. И предусмотреть пакет начала работы. Тогда система будет просто идеальной. Мы увидим не только температуру, но и продолжительность рабочего дня монтажника. Задача №3. Холодильники и т.п. Если использовать ЛоРу то тут точно можно использовать датчики температуры Вега. Они сильно автономны и уже настроены, и налажены. Мне кажется их использование будет более чем оправдано в данной ситуации. Например такой: https://iotvega.com/product/hs0101 А в качестве базовой станции можно использовать такую: https://iotvega.com/product/bs01-2 О том как развернуть сеть ЛоРа: https://iotvega.com/content/ru/bs/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE%20%D0%BF%D0%BE%20%D1%80%D0%B0%D0%B7%D0%B2%D0%BE%D1%80%D0%B0%D1%87%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D1%8E%20%D1%81%D0%B5%D1%82%D0%B8%20rev04.pdf Теперь сбор данных. База одна, она должна быть довольно распространенной (MySQL например или MS SQL и т.п.), так как из нее данные мы будем считывать и отображать самостоятельно на нашей системе ERP, которую мы написали сами. Серверное оборудование имеется.

Спасибо за ссылку. Придется вникнуть. Поизучал. Это замена плат управления jbc паяльных станций. То есть в принципе можно доработать ее для выгрузки температур во внешний мир и даже выдачу предупреждений в случае установки нерегламентированной температуры. Интересно. Поизучаю ещё. Ещё бы для Weller подобное найти )