потому что выше у вас написано >>>> "PRU берёт BOOL из основной программы и записывает его в другую переменную."Сообщение от Владимир Ситников
но смысл поста Владислава в том, что нужно, как минимум понимать, что будет с алгоритмом, если ему из другого потока значение переменных менять, а в общем случае - проклясть и не использовать сей "метод"
Вот вот, данных нет, но я решил, что...
Нельзя так сделать.
Идея всей программы PRU как одного куска на С-подобном языке мне не нравилась из-за проблем с тестированием кода. Но это цветочки по сравнению с прямым доступом к ОЗУ (да ещё и "скрытым от пользователя").
И если подход с компиляцией непонятно чем программы из С-языка я ещё могу понять, то
Как разработчик системы ПЛК ответственно заявляю:
Прямой доступ из PRU к ОЗУ за пределами PRU, либо из основного цикла ПЛК к PRU по указателю является опасным и при таком доступе не гарантируется соблюдение алгоритма работы PRU, цикла PRU, либо правильность получения в PRU/из PRU данных.
Тролль-наседка, добрый, нежный и ласковый
гм, при 16-битной шине и наличии в системе нескольких DMA контроллеров, которые использует ОС ПЛК по своим неизвестным нам приоритетам... ну - нуТ.е. мой подход опирается на следующее:
1) Чтение/запись DWORD атомарны (всегда читается/записывается полное значение)
а идея, под которую затачивались ПРУ ядра - это остановить ядро, загрузить блок данных, запустить ядро на обработку и по завершении - остановить вычисления и выгрузить результат
И учитывая, что у PRU только побайтное чтение/запись. Ню-ню.
Тролль-наседка, добрый, нежный и ласковый
Короче - без знания железа и внутренних потрахов лезть туда не безопасно чистым программистам или нужно все согласовывать и работать по ТЗ.Что бы ню-ню не превратилось в ба- бах
электронщик до мозга костей и не только
вывод не совсем правильный ))) разговор о том, что нужно хорошо понимать что именно собираешься сделать....Короче - без знания железа и внутренних потрахов лезть туда не безопасно чистым программистам или нужно все согласовывать и работать по ТЗ.Что бы ню-ню не превратилось в ба- бах
концепция "овена" - конструкции из проверенных "атомарных" блоков с прозрачным и однозначным функционированием, и поскольку библиотеку будет распространять овен - то и нести некую ответственность за конечную работоспособность системы
господин Ситников продвигает свою среду разработки - презентуя ее в стиле - каждый станет богом программирования с этой волшебной оболочкой ))) как он ее будет поддерживать, и будет ли "диктовать бабушкам емейлы" - большой вопрос, и скорее похоже на желание продать этого "слона" овену (возможно вместе с собой!)
лично мне больше всего импонирует концепция ассемблерных модулей - все едино они там не большие получаются - отлаживать не сложно, зато свободными от окружающей шелухи - различных оберток... и собственно это натуральная среда, предполагавшаяся разработчиками чипа, позволяющая использовать все возможности ( и кстати, выйти за ограничения кодесиса, ибо ядра ПРУ имеют доступ ко всей памяти и ко всем периферийным устройствам - гы - поставить в основном цикле холостой оператор и выполнить весь функционал на "чердаке"!!! - это конечно смешно, но вполне возможно (правда 2к команд) )
Значит не в среде разработки дело, а в правильном подходе к PRU - программированию.
Последний раз редактировалось Вольд; 27.10.2016 в 15:01.
не обязательно... как я понял, заложенный механизм работает следующим образом: когда PRU что-нить нужно - оно генерит прерывание, сообщающее ЦП о желании пообщаться и ЦП освобождает шину, занимаясь другими проблемами - при кеше ядра в 16к вполне есть чего поделать... и это нормально, потому что одно из назначений PRU первичная обработка получаемых с интерфейсов данных..Вся красота разбивается о суровую реальность: задержка доступа к основной памяти запросто может быть 50 тактов, т.е. тупо ждём по 0.25мкс на каждое обращение к памяти. Беда-печаль.
не, конечно нас не пустят в прерывания ЦП, но суть в том что ожидание: 1. совсем необязательно будет, все таки в ПЛК нет обмена видео и аудио потоками и 2. ПРУ имеет высокий приоритет на доступ к шине
но учитывать возможность в задержках и разрыве потока байтов обязательно ))) .... буфера обмена и флаги !!!!
Понимание возникает (или нет) от знания ,а не наоборот .
нравится Хардела - используйте её, чего тут агитировать за всё хорошее.
Тролль-наседка, добрый, нежный и ласковый
Ваши права
Ответить с цитированием