cnc-club.ru

UAVpilot писал(а):Я понял! Просто нашёлся китайский MX_Master, который уже засунул свою прошивку в эту плату, а теперь наш MX_Master хочет сделать тоже самое...

Я могу засунуть и в оригинал и даже стм'ку могу махнуть на F4, был бы толк.

UAVpilot писал(а):Тут стоит что-то типа dc/dc, плата сильно другой версии, да и это совсем противоположный угол платы.

dc/dc тут sot23-6, обведён красным: И вобще эта плата больше похоже на оригинал.

На фотке оригинал 2-й версии. В первой версии микрухи не было. Конечно, если первая тоже была оригиналом Мне, честно говоря, клон подходит даже больше.

Может, все проще - увидели китайцы, что нет у STM32 EEPROM, ну и заложили внешний "шоб було".
А потом разобрались, как эмулировать его через флэш.

MX_Master писал(а):STM32F207VCT6. Весь софт менять.

Вопрос совсем не по теме, возможно даже не для этого форума, но всё равно спрошу. Ломаю голову на задачей, как забирать данные с некого внешнего устройства через DMA. Устройство примитивное: 8-ми разрядная шина данных DD0...DD7, входы CE/RD/WR. Не могу понять откуда во время обмена DMA perepheral-to-memory взять такты RD? Как заставить DMA контроллер выводить такты на какую-либо ножку контроллера? Если делать не через DMA, а просто дёргать линию RD программно, то все просто и понятно, но очень меееееееедлнно ((

Пока что играюсь с Atmel SAM3X8E (Arduino Due). Но на примере STM32F207VCT6, как можно было бы решить такую задачку? Даташит посмотрел, про тактирование периферии ничего не нашёл.

указать DMA контроллеру, что делать передачу надо после определенного аппаратного события Без часового изучения доков к STM32, это можно сделать за пару минут в CubeMX. Я, кстати, когда выбирал между модулями ардуино и STM32, таки заставил себя изучить сначала STM32. И не пожалел. К ардуинам я теперь ваще не прикасаюсь

Сергей Саныч писал(а):Может, все проще - увидели китайцы, что нет у STM32 EEPROM, ну и заложили внешний "шоб було".
А потом разобрались, как эмулировать его через флэш.

В этом деле есть момент, когда одни китайцы скопировали контроллер у других китайцев. А на клон эту микруху не стали ставить, потому что в STM32 всё необходимое уже есть. Прошивка клона даже никак не защищена, потому что это и не нужно. Никто не станет делать контроллер ещё дешевле клона.

aekhv писал(а): ↑ Как заставить DMA контроллер выводить такты на какую-либо ножку контроллера

Довольно странный вопрос.

Настрой таймер и им тактируй ПДП. а УВВ укажи гпио.
Именно для этого столько вариантов тактирования стримов с привязкой к таймеру. А не только для ШИМ .
умеючи МК можно нагрузить так что он будет стоять, а переферия шуршать. И по сути как многоядерное устройство пахать.
И это есть мастерство, а "не извращения с DMA".

Добавлю - а выход таймера можешь настроить как RD.
Удачи!

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

Решил сделать в своём софте так:
Cами Ethernet пакеты не шифруются, это лишнее. Зато к каждому пакету добавляется пара длинных чисел (как подпись). Первое число - всегда случайное. Второе число - хэш от первого числа с солью из ID контроллера. У каждого контроллера имеется свой уникальный ID. Этот ID нужно вбить в настройках драйвера, чтобы LinuxCNC мог без проблем общаться с данным контроллером. Если контроллер получит больше 3-х пакетов, подписанных некорректно, доступ к контроллеру блокируется до отключения на нём питания.

Я правильно понимаю, что можно один раз перехватить эти два числа и просто добавлять их к любым "левым" пакетам?..

UAVpilot писал(а): ↑08 сен 2020, 17:17 Я правильно понимаю, что можно один раз перехватить эти два числа и просто добавлять их к любым "левым" пакетам?..

Аха, я немного тупанул. Думаю, будет логичнее сделать первое число номером пакета. Счётчик пакетов на каждой стороне должен увеличиваться. Если номер очередного пакета будет старый или слишком новый, весь пакетик можно считать левым. Даже без проверки второго числа.

Счётчика на 32 бита должно хватить на несколько дней, а на 64 бита - чуть подольше

MX_Master писал(а): ↑ Счётчик пакетов на каждой стороне должен увеличиваться. Если номер очередного пакета будет старый или слишком новый, весь пакетик можно считать левым.

Как быть с восстановлением работы после потери пакета?

Почему вместо хеша случайного числа не хочешь использовать цифровую подпись (хеш всего пакета со случайным числом, зашифрованный открытым ключём)?

Потеря пакетов не страшна для этой проверки. Когда ответа нет, счётчик увеличиваться не должен. Небольшой диапазон скачков вперёд можно разрешить.

Во многих STM32 есть аппаратный CRC32. Пара тактов и хэшик готов. А вот модуль шифрования есть не везде. Программно шифровать весь пакет будет довольно накладно.

У меня по сути получается быстрая подпись только номера пакета, закрытым ключом. Другие варианты, особенно, программные, должны быть гораздо медленней. Или я чего не знаю?

MX_Master писал(а): ↑ Программно шифровать весь пакет будет довольно накладно.

Зачем шифровать весь пакет?

MX_Master писал(а): ↑ Другие варианты, особенно, программные, должны быть гораздо медленней. Или я чего не знаю?

А ты попробуй...

Достаточно добавить к пакету закрытый ключ и посчитать crc32 от всего этого добра.

Не защищает от повтора пакетов, но уже что-то.

alex_sar писал(а): ↑ Достаточно добавить к пакету закрытый ключ

И передавать всё это по сети?

Если будешь использовать UID контроллера, который будет записан на ПК. То можно просто все шифровать на нём симметрично. Он же не будет передаваться по открытым каналам....

UAVpilot писал(а): ↑09 сен 2020, 01:26 Зачем шифровать весь пакет?

UAVpilot писал(а): ↑08 сен 2020, 23:58(хеш всего пакета со случайным числом, зашифрованный открытым ключём)

Согласен. Не весь пакет, а лишь хэшик всего пакета. Но хэш всего пакета будет считаться дольше, чем хэш одного числа. А юзать медленный программный RSA для шифровки одного хэшика - это как с пушки по воробьям. Плюс длина открытого ключа будет всегда больше хэшика.

Я не спорю, что способ рабочий и логически правильный. Но даже невооружённым глазом видно, что он ест заметно больше ресурсов. И чтобы им пользоваться нужен какой-то мега быстрый программный RSA (или аналог).

Bender писал(а): ↑09 сен 2020, 05:09 Если будешь использовать UID контроллера, который будет записан на ПК. То можно просто все шифровать на нём симметрично. Он же не будет передаваться по открытым каналам....

Да, сейчас я так и делаю. Только юзаю не сам UID, а хэшик от него. Этот хэшик знают обе стороны.

UAVpilot писал(а): ↑09 сен 2020, 04:17

alex_sar писал(а): ↑ Достаточно добавить к пакету закрытый ключ

И передавать всё это по сети?

это ваши домыслы

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

в процессе работы достаточно подписи crc32 содержимого пакета + закрытый ключ

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

alex_sar писал(а): ↑ ключами надо как-то поменяться. в начале сессии сгенерировать временный или заранее. это уже другой вопрос.

Как например? Это как раз самый главный вопрос.
Закрытый ключ на то и закрытый, что хранится в надёжном месте и никому никогда не передаётся.

alex_sar писал(а): ↑ или id какой нибудь известный взять в качестве ключа.

Известный кому, и злоумышленнику тоже?

MX_Master писал(а): ↑ Но хэш всего пакета будет считаться дольше, чем хэш одного числа.

С какого перепугу?

MX_Master писал(а): ↑ Плюс длина открытого ключа будет всегда больше хэшика.

Ну и что, памяти жалко?
Не нравится ассиметричное шифрование используй симметричное с генерацией сессионных ключей (протокол Диффи-Хеллмана).

UAVpilot писал(а): ↑ Не нравится ассиметричное шифрование используй симметричное с генерацией сессионных ключей (протокол Диффи-Хеллмана).

Нравится/не нравится - это, скорее, про вкус мороженого. Любое шифрование или мои хэшики в пакетах мне не нравятся. Это дополнительное усложнение. Но мне интересно другое - почему дядь Серёже не нравится простая, быстрая и симметричная система из пары чисел с закрытым ключом?

Я, кстати, не знаю, а в протоколах связи месы какая-то защита от левых пакетов есть?