А теперь попробуйте менять значения пинов на одном порту из разных потоков без издержек межпоточного взаимодействия, так как требования по времянке таких издержек не позволяют )
DMA читает буфер по кольцу по словам или по байтам. Задача программы писать в этот буфер новые данные до того, как до них дойдет DMA и не переписывать данные, которые DMA ещё не успел считать.
Я привел конкретный пример, в котором для оптимизации производительности не выполняется операция инициализация того, что по логике работы программы не должно читаться до того, как туда будет что-то записано. Туда вообще не CPU может писать, а DMA. Но исключить при этом ошибку, когда оттуда читается до записи нельзя. Вот и приходится верифицировать весь код.
И примеров таких масса. Например, изменять значения пинов у MK на конкретном порту из разных потоков безопасно никак не получится, потому что значение конкретного пина изменяется накладыванием маски на весь порт. А устраивать взаимодействие между потоками производительность МК может не позволять.
Вы читать умеете? Вы только подтверждаете мои слова, что при наличии usafe блоков необходимо верифицировать ВЕСЬ КОД, так как одного их наличия достаточно для того, что Rust не мог контролировать безопасность.
А уже причины того, почему и как используется usafe блоки - совершенно отдельная тема.
Я про то речь и веду, что не заботится и не даже не умеет сейчас заботиться о безопасности. Поэтому и приходится верифицировать весь код, а не только unsafe
Не лукавьте. Проверка только unsafe блоков недостаточна. Нужно проверять весь код, который прямо или косвенно с этими блоками связан. Например, если имеем неинициализированную структуру через MaybeUninit, то ошибка может содержаться в последующем чтении из этой структуры
С учетом того, что все больше панелей выпускаются уже под управлением Android/Linux, а на старых панелях несложно и Windows 2000 встретить, очень сомневаюсь в востребованности Windows 11 в этих целях.
Сначала всё же ослик. А уже когда убедился в наличии сигнала удовлетворительной формы и уровней, тогда уже можно ЛА. Причем тогда его можно подключать уже к логическим уровням, а не добавлять в цепь трансивер, который может оказаться не живым
На самом деле в no_std отваливается очень мало из того, что действительно востребовано на МК. Это даже не касаясь того, что для ESP32 std подразумевает работу через ESP-IDF, написанном на C, тогда как no_std реализуется целиком на Rust.
В ностд отваливается слишком много, даже если рефцелл доступна.
И что же там такое отваливается в случае, если операционной системы как таковой просто нет? Даже HTTP сервер на no_std замечательно реализуется.
Я вообще не хочу инициализировать то, что по логике программы не требует инициализации. А реализация кастомного аллокатора, позволяющего получать память из конкретного пула любого размера без оверхеда, ценой возможности освободить только весь пул целиком - это уже детали.
Ну верифицировали, что есть специально не инициализированный объект. Вы же сами выше писали, что никаких гарантий отсутствия UB это не даст )))
А теперь попробуйте менять значения пинов на одном порту из разных потоков без издержек межпоточного взаимодействия, так как требования по времянке таких издержек не позволяют )
И даже в столь простых примерах: https://github.com/search?q=repo%3Artic-rs%2Frtic+path%3A%2F^examples\%2F%2F+%2Funsafe+%2F&type=code
DMA читает буфер по кольцу по словам или по байтам. Задача программы писать в этот буфер новые данные до того, как до них дойдет DMA и не переписывать данные, которые DMA ещё не успел считать.
Можно, но с дополнительными издержками, что может быть терпимо в проблемных программах, но уж никак не в ядре или на МК,
Я привел конкретный пример, в котором для оптимизации производительности не выполняется операция инициализация того, что по логике работы программы не должно читаться до того, как туда будет что-то записано. Туда вообще не CPU может писать, а DMA. Но исключить при этом ошибку, когда оттуда читается до записи нельзя. Вот и приходится верифицировать весь код.
И примеров таких масса. Например, изменять значения пинов у MK на конкретном порту из разных потоков безопасно никак не получится, потому что значение конкретного пина изменяется накладыванием маски на весь порт. А устраивать взаимодействие между потоками производительность МК может не позволять.
Вы читать умеете? Вы только подтверждаете мои слова, что при наличии usafe блоков необходимо верифицировать ВЕСЬ КОД, так как одного их наличия достаточно для того, что Rust не мог контролировать безопасность.
А уже причины того, почему и как используется usafe блоки - совершенно отдельная тема.
Попробуйте написать без unsafe код на Rust для МК. Особенно если это no_std
А как тогда вызывающий код сможет в этот буфер писать? Не предлагаете же Вы останавливать DMA после каждой его транзакции?
Это говорит о том, что данная проблема требует решения без unsafe и без ущерба производительности новыми средствами языка.
Я про то речь и веду, что не заботится и не даже не умеет сейчас заботиться о безопасности. Поэтому и приходится верифицировать весь код, а не только unsafe
Как остановить DMA при освобождении его буфера, с учётом того, что владеет буфером вызывающий код?
Не лукавьте. Проверка только unsafe блоков недостаточна. Нужно проверять весь код, который прямо или косвенно с этими блоками связан. Например, если имеем неинициализированную структуру через MaybeUninit, то ошибка может содержаться в последующем чтении из этой структуры
Непонятно, зачем цепляться за REST, применяя костыли в виде WebSocket и SSE для снижения задержек, если это "из коробки" доступно в gRPC?
С учетом того, что все больше панелей выпускаются уже под управлением Android/Linux, а на старых панелях несложно и Windows 2000 встретить, очень сомневаюсь в востребованности Windows 11 в этих целях.
У каждого? У меня дома для DIY три ослика.
Сначала всё же ослик. А уже когда убедился в наличии сигнала удовлетворительной формы и уровней, тогда уже можно ЛА. Причем тогда его можно подключать уже к логическим уровням, а не добавлять в цепь трансивер, который может оказаться не живым
Что мешало в самом начале воспользоваться осциллографом?
На самом деле в no_std отваливается очень мало из того, что действительно востребовано на МК. Это даже не касаясь того, что для ESP32 std подразумевает работу через ESP-IDF, написанном на C, тогда как no_std реализуется целиком на Rust.
И что же там такое отваливается в случае, если операционной системы как таковой просто нет? Даже HTTP сервер на no_std замечательно реализуется.
Я вижу, что MayBeUnit - union. А union обязан содержать tag, определяющий, какое из возможных значений он в данный момент содержит.
Я вообще не хочу инициализировать то, что по логике программы не требует инициализации. А реализация кастомного аллокатора, позволяющего получать память из конкретного пула любого размера без оверхеда, ценой возможности освободить только весь пул целиком - это уже детали.