![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
jcxz
Свой-
Постов
13 478 -
Зарегистрирован
-
Посещение
-
Победитель дней
34
Весь контент jcxz
-
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
Какая "внешняя микросхема памяти"? И какое она имеет отношения с теме обсуждения? - вообще непонятно... Здесь вроде как ГПСЧ обсуждаются, если что. -
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
Грамотным является хотя бы прочитать то, что пишут оппоненты. А вы видимо даже не читали то, что я предложил. Если бы прочитали, то уяснили бы что: Т.е. - период 4,3•106001 (о котором я писал) - это не константа. И можно выбрать свой период, наиболее удобный. Из ряда простых чисел Мерсенна. Ряд этот имеется по приведённой мною ссылке. Например в нём есть число = 170141183460469231731687303715884105727. (что даёт разрядность = ln(170141183460469231731687303715884105727)/ln(2) = ~127 бит). Т.е. - реализуем Вихрь Мерсенна с базой = 170141183460469231731687303715884105727 и получаем период = ~2^127. И этот период математически обоснован, а не голословное утверждение. ТСу 2^127 вроде как - вполне достаточно. -
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
Что примерно на 100 десятичных порядков меньше чем у "Вихря Мерсенна". Сомнительное утверждение. Чем оно обосновано? -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
Совершенно не понятно - куда автор собрался подавать свои выходные импульсы 10-100мсек? В какие именно линии COM-порта? Входных (в ПК) сигналов от COM-порта всего 4шт.: CTS, DSR, DCD, RI. Автору же нужно минимум 8 таких сигналов: 4шт. для импульсов перемещения + 2шт. - для колеса мыши + 2шт. - для минимум 2-х кнопок мыши. А если добавить ещё и: То получается ещё больше. Или это будет возложено на некий "контроллер клавиатуры", с нормальным UART-выходом (TXD)? Это уже не говоря о том, что макс. частота импульсов перемещения = 50 или 100(?) Гц - маловата для нормальной работы с мышкой. Тем более - для игр (о которых пишет ТС). И не говоря о сомнительном решении с постоянным замыканием 5V-питания на 4шт. 100нФ ёмкости. Сколько протянут контакты замыкающиеся в таком режиме постоянно с частотой 50Гц? - большой вопрос. Ещё и источник этого 5V-питания - TXD(от ПК), RTS, DTR - маломощный. Но должен выдерживать эти импульсные токи замыкания 200нФ (или 400нФ?) на GND без просадок. И одновременно должен питать и всю схему и 5 выходных сигналов COM-порта. И с дребезгом борятся совсем не так. PS: Самое правильное решение тут - выкинуть весь этот колхоз (вместе с контроллером клавиатуры) и заменить его на простейший микроконтроллер с UART. -
И не нужно ничего прибивать гвоздями к фиксированным адресам.
-
Для MPU нет никакой необходимости в: Как уже писал выше. Помещаем все такие переменные в секции называемые например ".dma", а в командном файле компоновщика говорим "компоновать эти секции в регион ОЗУ с установленными как надо атрибутами MPU". Всё.
-
Ещё раз повторю вопрос: Где именно вы включаете это самое "кеширование"??? Или речь про атрибуты MPU? Включения кеша флеша или кеша внутреннего ОЗУ? PS: Если речь про разные регионы ОЗУ с различными атрибутами MPU, то можно создать отдельно регион обычной ОЗУ (с включенным битом "cacheable") и отдельно - регион с выключенным атрибутом "cacheable" для DMA. И скомпоновать во 2-й все секции ОЗУ с которыми работает DMA. Я именно так и делаю в своих проектах. И не прибиваю никаких переменных гвоздями к фиксированным адресам ОЗУ в командном файле компоновщика.
-
Какое "кеширование памяти" для внутреннего ОЗУ МК? На кой оно сдалось в STM32? И как вы его собрались включать? И о каком STM32 вообще речь? В каком STM32 это необходимо?
-
Т.е. - это вы сознательно лукавите? Рассказывая о цене 100р и "забывая", что нужно ещё потратиться на замену присланной некондиции, переделку плат (может неоднократную), потерянное время, потерянную репутацию у заказчиков (а была ли она вообще?) и т.д.? А если завтра эти "норм" сдохнут? Потому, что некондиция, но такая, что сразу не проявляется?
-
Причём тут куб, если это ваш командный файл? Почему не описать один единый регион ОЗУ: RAM(xrw) : ORIGIN = 0x20010000, LENGTH = 192K /* SRAM1 (192k) */ И скомпоновать все RW-секции данных в него? И для Ethernet и для DMA и пр. DTCM - отдельный регион: RAM(xrw) : ORIGIN = 0x20000000, LENGTH = 64K /* DTCM (64k) */ В DTCM-регион можно скомпоновать стеки задач.
-
Во-первых: определения региона RAM и последующих RAM_ETH_DMA_RX, ... - перекрываются. Разве такое допустимо? Во-вторых - на кой заниматься закатом солнца вручную распределением ОЗУ вручную? Командный файл линковщика предназначен не для этого. Нормальная практика: задать все массивы в файлах исходного кода, а в командном файле линковщика описать только регионы памяти. И правила распределения скомпилированных секций по этим регионам. У вас же всё сделано через одно небезъизвестное место. Теперь пытаетесь бороться с проблемами, которые сами же и создали.
-
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
У Вихря Мерсенна период намного больше = 4,3•106001 -
Тогда - компактное реле. Гуглите "поляризованное реле" или "bistable relay".
-
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
Почему? Причём тут "помеха от работы какого-либо узла платы"? Речь шла об использовании например теплового шума какого-либо элемента (резистора, диода или схемы на их основе). Достаточно чтобы непредсказуемо шумел хотя бы один младший бит в данных АЦП. Впрочем - и штатные (уже имеющиеся) измерения каких-то напряжений через АЦП тоже подойдут - ведь в них наверняка тоже есть хотя бы один шумящий разряд. Дальше - накапливаем этих данных как можно больше и считаем от них CRC или хеш нужной длины (равной требуемому размеру случайного числа). Всё. У ГПСЧ проблема не в повторе какого-то числа, а в том что при одном и том же стартовом seed, последовательность будет одна и та же. Если это не проблема в задаче ТС, то можно его использовать. Если вам подойдёт псевдослучайное, то можно попробовать "Вихрь Мерсенна": https://ru.wikipedia.org/wiki/Вихрь_Мерсенна Это вроде как очень хороший алгоритм ГПСЧ. Есть его си++ исходники (вроде как): https://www.boost.org/doc/libs/1_49_0/boost/random/mersenne_twister.hpp -
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
У моего варианта вряд-ли возможно гарантированное повторение последовательности с некоторым периодом. Что характерно для любого генератора ПСЧ. Только если уж руки совсем кривые, что не смогли построить адекватную схему генератора шума на входе АЦП. Т.е. - с моим вариантом нужно ещё "постараться", чтобы он стал псевдослучаен. А вот различные математические алгоритмы - гарантированно псевдослучайны. Хотя период их может быть достаточно большим. -
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
Это будет псевдослучайная последовательность Автору же вроде нужна случайная. Ни на каком хеше или алгоритме генератор случайных не построить. Только на аппаратном источнике шума. -
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
Тогда изучать работу АЦП в своём МК и строить генератор на нём. -
Генератор случайных чисел на STM32
jcxz ответил mplata тема в Математика и Физика
User manual на ваш STM32. Раздел "Генератор случайных". -
Плохо ищете. Я давно использую S70FL01GS на 1Гбит. Но есть и больше. Не обязательно. Есть и NOR.
-
Вроде как в вашем МК есть quad-SPI. Какой тогда смысл цеплять параллельную флешку, а не quad-SPI?
-
Я вообще-то писал: Т.е. - за время с момента задания вопроса (чуть больше месяца) уже было много сообщений по STM32. Причём тут "годы"? До того как начинать что-то выпускать, нужно чтобы появился спрос, а чтобы он появился, нужно чтобы были начаты и завершены разработки. О чём я выше писал. Такое ощущение что вы даже не прочитали моё сообщение, на которое отвечаете.... Никто не "шлёпает миллионами" в никуда, на склад. Даже китайцы. С чего вы взяли? Производить миллионами штук адекватный производитель начинает только если уверен в спросе. Т.е. - при наличии уже оплаченных заказов или наличии гарантий будущих заказов. Которые опять-же появляются только после проведения всех этапов, о которых я писал выше. А "шлёпать миллионы" в никуда - прямой путь к банкротству. Т.е. - если сейчас начали производить миллионами штук, значит примерно как минимум полгода назад (а скорее - год и более назад), должны были появиться инженерные образцы и разработчики должны были начать разработку. А значит - у них должны были появиться вопросы. Но никаких вопросов не было видно. А потом вдруг, сразу как с неба - миллионы штук. Так не бывает. Хотя.... если речь о распиле госбабла, то всё возможно. Могли даже начать лепить их просто в никуда. Ведь тогда законы рынка не работают.
-
А смысл переходить на давно устаревшие ARM7/ARM9 (которые вы предлагаете) - какой? Если и переходить с AVR на что-то, то скорее всего - на Сortex-M. А не на то старьё, что вы предлагаете.
-
А вы сопоставьте: и тот факт, что на вопрос, заданный здесь много дней назад: не было ни одного ответа. При том, что за это время здесь на форуме было уже множество сообщений о других МК, например STM32. Т.е. - если следовать логике, получается тогда STM32 должен использоваться ещё больше... миллиарды штук?? в РФ??? что абсурдно. Или какое ещё может быть объяснение этого факта? Что на одном из самых популярных тематических русскоязычных форумов не слышно вообще вопросов/тем по этому Амуру (при том, что по другим МК - полно). Да и на других аналогичных русскоязычных форумах - тоже не видел тем с практическими вопросами по нему. А ведь чтобы что-то делать серийно (ведь миллионы - это явно серийное производство), нужно сперва это что-то разработать, отладить. Т.е. - потратить довольно прилично времени. А значит наверняка столкнуться с вопросами. С которыми обычно куда идут русскоязычные разработчики? Я думаю вы знаете. Т.е. - логично предположить последовательность: 1) Появляется новый МК; 2) выпускаются средства разработки для него; 3) сам он производится пока мелкими сериями; 4) разработчики покупают его понемногу и начинают разработку, по ходу сталкиваясь с кучей проблем и багов (тем в более в новом МК их должно быть довольно много); 5) идут на разные форумы с вопросами; 6) постепенно проблемы решаются, начинаются испытания, опытная эксплуатация; 7) И только после этого всего может начаться массовое производство, миллионами штук. А значит к этому моменту уж наверняка хоть где-то хоть на каком-то форуме хоть одна тема по нему всплывёт. А скорее - даже много. А вот чтобы вдруг, ниоткуда, сразу и миллионы штук с неба упавшей прошивкой и схемой - это похоже на сказку. PS: Может конечно любой амуро-покупатель сразу с чеком подписывает соглашение о молчании. Или ему сразу отключают интернет. Или ещё одно объяснение: этот Амур - это просто перемаркировка какого-то популярного МК (типа STM32F103), совпадающий с ним один-в-один и позволяющий выполнять код предназначенный для того МК. Или Амуры дают только мега-гуру, которые всё заранее знают, и у которых не возникает вопросов и проблем. Верите в сказку? Или же всё прозаично, как обычно: не имеющее ничего общего с реальностью.
-
Бессмысленный вопрос. Способ будет зависеть от алгоритма обработки этих данных. Можно придумать 100500 разных вариантов, удобных для каждого конкретного случая. Такой же бесмысленный, как вопрос: Каким столовым прибором вы пользуетесь для еды? Вы же, надеюсь, пользуете и вилки и ложки и ножи? - что когда удобнее, а не мешаете сахар в чае вилкой... Так и средств межпоточной синхронизации придумано множество. Если бы был общий универсальный наилучший способ, то какой смысл было бы придумывать такое их многообразие?
-
Так я же дал ссылки. Там всё есть. Кроме того - есть ещё руководство по использованию (чтению/записи): http://www.libpng.org/pub/png/libpng-1.0.3-manual.html