Сгенерировать случайное число, Возможно ли? Опции

[rv3dll(lex)]

1 на ацп завести напряжение батареи, через делитель из неточных резисторов немаркированных, которые будут ставить как попало.

разобраться с контроллером с его битовым файлом на загрузку и отвести там область, в которую писать ключ текущее время например - просто файл прошивки надо обработать программой перед каждой прошивкой.

[Amper25]

Можно сделать гораздо проще, без всяких АЦП и пр.

При первом подключении батарейки, запустить программный 8-бит счетчик и инкрементировать его по возможности с наибольшей частотой. Одновременно записывать его значение в ячейку(или поочередно в 2 ячейки) EEPROM. Потом выдернуть батарею и опять вставить.
Если время записи в EEPROM составляет 5-8мс, то если разница во временах удержания батареи разных устройств больше 5-8мс(что логично) то и "RANDOM" числа будут отличатся.

Единственное что можно добавить, лучше писать в 2 ячейки поочередно, и если питание обрывается на процессе стирания ячейки, то хотябы в одной из них будет число отличное от 0xFF.
Ну и само значение 0xFF надо считать не RANDOMOM.

[DpInRock]

Попробую. Хотя думаю, что запись в епром синхронная.
А АЦП стоит как вкопаный гад. Вот когда не надо, дергается. А тут железно меряет. Даже удивительно. И младший разряд стоит.

А может можно программатор научить ячейку образа памяти инкрементировать?
Точно. Просто напишу программку, которая раз в секунду увеличивает содержимое ячейки в нужном месте хексфайла. Правда, там еще надо будет контрольную сумму фиксить...
А программатор всегда проверяет файл на свежесть (ПикКит2).

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

[one_man_show]

Может быть ошибаюсь, давно не работал с пИками, но вроде была раньше какая-то возможность программировать область памяти так, чтобы получить неустойчивое значение, тогда достаточно при запуске читать известные ячейки памяти программ

[DpInRock]

Да сложно все получается, если программно решать вопрос.
Дело копеечное.
Все-таки правильнее сделать процесс управляемым. Т.е. снаружи писать прогу, которая правит хекс. По крайней мере надежно и точно. И числа будут точно не совпадать.

[DpInRock]

Может кому пригодится.
Опробованы все способы.

Самым надежным и приятным в реализации оказался озвученный тут совет суммирования памяти.

Тесты показали, что память инициализируется действительно случайными числами. Даже не FF 00 F0 0F. А нормальными такими числами. Там, 18, 75, 36....

Полсотни раз порпобовал - числа не повторились. Хотя могли бы.

А реализация - всего одна строка.

Рад в усмерть. Спасибо еще раз.

[Amper25]

Рад в усмерть. Спасибо еще раз.

Не стоит устраивать преждевременных празднований. С Пиками много не работал, не могу сказать. Но на AVR с tiny26 были случаи когда в L(Low voltage) версии память инициализировалась случайными числами, а в обычной версии контроллера - сплошными нулями.

Вообщем, может полуцчится так, что на некоторых версиях это не сработает.

Сообщение отредактировал Amper25 - Aug 12 2008, 15:46

[kurtis]

Возможно вы использовали разные версии компилятора. Т.к. обнуление ОЗУ это задача программы, и например в WinAVR процедуры "обнуления" ОЗУ находятся в модуле crtxxxx.o, и можно увидеть как в начале программы, еще перед вызовом main(), выполняется код, который обнуляет секцию bss (т.е. ОЗУ)

[Amper25]

Для tiny26 я писал на ASM, и никаких процедур обнуления там не было.

[DpInRock]

Я делаю все из МСС18. Не стал вмешиваться в стартапные вещи (еще чего, нам, боярам не с руки ковыряться). У компилятора действительно есть неинициализируемые области, которые он явно указывает.
Но так как я суммирую вообще ВСЮ память, то все нормально получится.
На самый худой конец (самый худой) - последствия не очень фатальны. Это не прицел баллистической ракеты.

Действительно, почему я не стал в первую очередь ориетироваться на память, ибо опыт работы с осталными процами говорил, что память чаще всего именно обнуляется аппаратно (в смысле, сама по себе). ....

[Rst7]

На память я бы полагаться не стал. А вот использовать тот факт, что тактовая частота WDT и тактовая самого проца - суть разные генераторы, вполне можно. Для этого достаточно запустить TMR0 по сбросу от PowerUp и по сбросу от WDT взять несколько младших битов TMR0. При необходимости повторить до получения нужного количества бит. Кстати, какой основной генератор используется, внутренний RC, внешний RC или кварц?

[DpInRock]

Внутренний.
Не хотелось бы строить еще один автомат. Хотя так можно, конечно.

[Огурцов]

Требуется после старта программы сгенерировать случайный байт.

Нужны стабилитрон, в качестве генератора шума, резистор и АЦП на борту, желательно с усилителем.
Я использовал дифференциальный и дополнительно RC цепочку для выделения постоянной составляющей, для подключения второго входа.

[DpInRock]

Как вообще генерировать случайные числа я себе представляю.
Как генерировать их без внешних устройств - вот в этом вопрос.

[DeadMoroz]

Соглашусь с Amper25:
"Можно сделать гораздо проще, без всяких АЦП и пр.

При первом подключении батарейки, запустить программный 8-бит счетчик и инкрементировать его по возможности с наибольшей частотой. Одновременно записывать его значение в ячейку(или поочередно в 2 ячейки) EEPROM. Потом выдернуть батарею и опять вставить.
Если время записи в EEPROM составляет 5-8мс, то если разница во временах удержания батареи разных устройств больше 5-8мс(что логично) то и "RANDOM" числа будут отличатся.

Единственное что можно добавить, лучше писать в 2 ячейки поочередно, и если питание обрывается на процессе стирания ячейки, то хотябы в одной из них будет число отличное от 0xFF.
Ну и само значение 0xFF надо считать не RANDOMOM."

Если есть кнопка или свободный вход, то можно поступить так: перед включением устройства нажимаем кнопку/устанавливаем вход в нужный уровень и после включения питания в процессе инициализации проверяем ее состояние - если активно, то инкриментируем 1/2 байта, далее, после того как пользователь отпустит кнопку/деактивирует вход, считываем текущее значение переменной. Проверено - работает.