Quantum1
-
Постов
209 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Quantum1
-
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/28/2024 at 9:14 PM, mantech said:А на счет описания, так его даже техас на свои PRUSSы не дает, и как тут быть уверенным тогда?)))
Да никак не быть, никак под него не писать и все! А зачем мне они вообще нужны? Очередная глубокая проприетарщина какая-то, хочет Тексас скрывать - пожалуйста! Я просто использовать не буду, так как не вижу прозрачных явно описанных преимуществ. В моем случае когда тебе нужно более 2 ядер, то там уже и без ПЛИСа тяжеловато, поэтому эти PRUSSы вообще никакого интереса не вызывают. Кстати у того же Тексаса из новых серий хватает хороших многоядерников на Cortex-R5, с нормальными описаниями и плюшками. (Хотя если уж настолько нужно описание Тексасов, я думаю через знакомых в иностранных компаниях спокойно можно их поиметь, им то их дадут по запросу, самое главное, что у Тексаса они точно физически есть! А вот у китайцев нет)))))
On 3/28/2024 at 9:14 PM, mantech said:Ну и много чего просто решается тестированием с пристрастием
При чем тут тестирование! До него еще доехать бы! Ты идешь по минному полю, не зная где сейчас рванет. Допустим разработал алгоритм, какой-то код накидал, и тут начинается - это место не так работает, тут задержки рушат всю концепцию, а это он оказывается только в урезанном виде поддерживает, а тут он флаги неожиданным образом ставит, тут прерывание не срабатывает. Это не разработка это треш какой то. Или вы предлагаете для каждого регистра свой тест писать, что бы просто догадаться что это он вдруг тут стал неожиданно делать? Ну или классический путь кодописа - накинуть Линукс и радоваться каким то там трем примерам из сети, радостно крича: IoT, IoT!!!
Вы вот щас на полном серьезе предлагаете многоядерную, сложную систему, пытатся освоить на bare-metal, не имея нормальной документации, просто на шару? Вы либо какой-то сверх оптимист, или вы просто стебетесь)
On 3/28/2024 at 9:14 PM, mantech said:Ну и на систему управления ядерным реактором или автопилотом самолета я аллвиннер бы не поставил, конечно по неск причинам сразу))))
А в допустим промышленные установки по микроэлектронным процессам с к примеру, опасной химией, поставили бы? ))) бытовым IoT-ом я как бы не занимаюсь))) о чем и писал в самой теме)))
-
On 3/28/2024 at 9:00 PM, mantech said:
Ну эт да, есть такое
ну так тогда на них вообще невозможно работать)) Из линуксовских исходников вытаскивать информацию о работе периферии и регистрах ??? Это ж каким мазахистом надо быть!)) А потом еще и пофигистом заявляя что твой прибор отказоустойчив, хотя ты сам про него и половину толком не знаешь)) ты иной раз с хорошим описанием днями сидишь какой-то заковыристый косяк выгрести не можешь, который в итоге в железе сидит, материшься, почему его нет в errata, плюешь и переделываешь такой прекрасный и готовый свой алгоритм дабы этот момент обойти. Я думаю проще извернуться и привезти нормальное железо, пусть даже за x3 цену, но оно будет работать, а ты будешь спокойно спать, и уверенно развивать свою компанию....
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/28/2024 at 6:14 PM, mantech said:аллвиннер Т113
Я бы не стал с ними связываться, во первых свою линейку разной производительности хочу все таки на Cortex-R серий строить, как база для реал-тайм дел. Второе как я понимаю по разным отзывам на уровне железа эти китайцы не особо прозрачны. По крайней мере очень многие жаловались, что есть проблемы с полноценным описанием. DSP(DSP это вообще не совсем про реал-тайм(хотя он там обязателен, но он его "как бы" обслуживает, а не создает) это больше про монотонное числомолочение под всякие цифровые фильтры и т.д.) как таковые я не очень люблю, если нужно применить обширные числомолотилки, на ПЛИС обычно изящнее и проще выходит, без кучи проприетарности конкретного DSP.
-
On 3/28/2024 at 1:39 PM, Arlleex said:
uCLinux
Судя по состоянию, этот пациент уже давно метрв....
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/28/2024 at 1:07 PM, jcxz said:полноценный линукс на "мелких МК" (типа Cortex-M) не возможен по определению. Меньше всяких "блохеров" читайте.
да хрен с ним с полноценным, меня и сильно ограниченный устроил бы. Главное что б ПО можно было сразу на всё писать и использовать, пусть и рядом особенностей и требований.
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/28/2024 at 12:41 PM, dxp said:Поэтому тоже ковыряю Zynq-7000 на предмет baremetal. Моё намерение: разместить программу в OCM, которой там 256к (для моих задач достаточно, что-то не критичное можно и в SDRAM закинуть)
Я вот дословно тоже самое но на Zynq Ultrscale для R5, стараюсь сделать - важный код в OCM/TCM. Обидно конечно, что при этом так сказать быстрая-RAM сокращается значительно. я тут пытаюсь делать bank-память. Т.е. допустим пока критичный код крутится из OCM/TCM. Другой процесс подготавливает там же допустим другой критичный код. И как только потребуется, проц переходит уже на новую область OCM/TCM с новым кодом.
Геммороя конечно не меряно, но даже предварительные результаты очень хороши. Так можно уложится в маленький размер OCM/TCM.
Но тут выход только один - то что грузим в OCM/TCM, только самописный ассемблер, никаких компиляторных дел. Вот тогда система реально раскрывается как по быстродействию, и по малому размеру кода.
Я тут всерьез, задумался об отечественной ОС Embox. Как заявляется она способна запускать линукс приложения написаны чисто под линукс даже на мелких МК. Для меня это идеальная тема для больших SoC систем пишем под полноценный линукс. А для мелких на Embox берем куски/части своего же линукс кода и запускаем, но конечно они должны быть не тяжелые ибо мелкий МК. Вроде как просматривается замечательная экономия времени, универсализация и масштабируемость.
Мож работал кто? Слишком аппетитно выглядит, что б быть прям правдой) Да и ее разраб от меня в часе езды походу живет)))
-
On 3/28/2024 at 11:29 AM, dxp said:
А вот как раз на Zynq-7000 это и было. 🙂 Прерывания пробовал разные -- от внешней ноги и от таймера.
Тогда трижды благодарю)))) че то для 400 МГц, 450 нс действительно это прямо совсем печаль-печальная....
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/28/2024 at 11:26 AM, haker_fox said:Теперь вернёмся к "Вашему" определению. Там написано "вне зависимости от своего состояния и окружения". Можно сразу задать вопросы: если в окружении будут проблемы с питанием, ОСРВ должна работать? Если питание исчезнет совсем? Про своё состояние тоже можно уточнить: если дала сбой плашка памяти SDRAM или контроллер памяти был настроен ошибочно, и данные в ней повреждены, в том числе структуры самой ОСРВ, она должна реагировать предсказуемо? Очевидно, что нет. В этом случае обязан отреагировать сторожевой таймер и перезагрузить систему, давшую сбой. Но этот таймер не относится к ОСРВ точно так же, как и надёжный блок питания, обеспечивающий аппаратную платформу питанием.
Да я с вами и не спорю, что это мои хотелки! И они могут не отражаться в реальности.
Под реакцию на состояние, я имел ввиду только поведение кода. ИИП никак не относится к этому.
Допустим пользовательский таск захотел залезть и потереть настройки самой системы без спец разрешения, ОС должна ему сказать низя-низя! Кстати в Zynq Ultrascale, есть великолепная вещь - защита аппаратная областей адресов, можно принудительно ограничить какому то ядру область памяти, и только туда он может ходить, если пытается в другие залезть - его во первых шлют лесом, во вторых могут вызвать прерывание на ошибку. Отказоустойчивая ОС по идеи должна тоже такое делать, но софтово.
Или таск зазвал полную, власть и не отдает его больше чем некое критическое время - опять же таск обрываем, думаем что делать.Или какой то таск токен на периферию держит и не отдает.
Опять же повторюсь! Это мои хотелки.
Но вот уже неделю как решил почитать про эти RTOS, и такое впечатление, что это вообще не про ОС и надёжность. А это просто компактная среда планировщика задач с некоторыми интересными драйверами на периферию.... ОС и тем более с гарантированной надёжностью тут особо то и не пахнет. По сути "надёжность" это просто следствие потому что в планировщике мало кода и он простой и прозрачный...
Заранее извиняюсь, я не с кем не спорю, просто всегда считал, что раз называется ОС да ещё и реал-тайм с сертификатами, то там ворох защит от сбоев и неправильного юзер ПО есть.... Ан нет....
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/28/2024 at 3:18 AM, haker_fox said:Дайте, пожалуйста, описание такой идеологии. Насколько я помню, ОСРВ даёт лишь некоторые гарантии временных характеристик, да предоставляет сервисы для межпроцессного взаимодействия.
Возможности конкретной ОСРВ описаны в документации на неё. Ни FreeRTOS, ни scmRTOS, с которыми я работаю, не предоставляют сервисов для работы со сторожевым таймеров.
RTOS это ж про системы с высокой надёжностью, всякие сертификаты там имеют как подразумевает что любое действие прогнозируемо , в том числе сбой.
Видел сети вот такое удачное определение:
система реального времени должна предсказуемо, а не быстро, реагировать на любое событие или совокупность событий, вне зависимости от своего состояния и окружения.
On 3/28/2024 at 4:55 AM, dxp said:Расскажите это, например, Cortex-A9 с GIC, у которого вход в IRQ занимает пару сотен тактов (на тактовой CPU 400 МГц задержка от внешнего события, до попадания в обработчик прерывания от него занимает порядка 450 нс -- специально исследовал этот вопрос, снимал времянки осциллографом, очень удивлялся поначалу, пока не понял, почему так).
Кстати очень полезная информация, благодарю! На A9 ни разу не замерял это время, а он есть в Zynq 7000, иногда его использую. А в каком чипе ваш A9 стоял, и если не сложно от чего там поподробнее там прерывание было?
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/27/2024 at 10:23 PM, Arlleex said:В ядре ОСРВ? Нет, конечно. С чего ей там быть?🙂 Да и как она должна тогда выглядеть, чтобы всем подходила и всегда работала исправно?
да хоть по классике - прерывание по системному таймер(везде есть), хоть внешняя микрушка с window-WDT, тоже простая штука. RTOS ведь по идеалогии не имеет права повиснуть... по краней мере я от нее этого жду)))) может и напрасно)))
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/27/2024 at 10:23 PM, Arlleex said:Если так удачно случилось, что периферия и доступы не пересекаются (физически или система построена так, чтобы гарантировать отсутствие таких пересечений во времени) - то это, несомненно, благотворительно повлияет на детерминизм, но не сведет предсказуемость задержек к 100%.
А в этом и есть искусство разработчика, максимально эффективно и экономно выбрать и hard, и soft ресурсы для решения задачи. Или если выбирать нельзя, извернуться и решить задачу имеющимися. А то сейчас много кодописов "ОЙ! В этой библиотеке AVR, нет функции включения лампочки/открывания дверей, я что теперь в регистры и даташиты что ли лезть должен?? фу-фу-фу я ж програмист высокоуровневый! Я хочу задачи решать, а не в этих ваших битах ковыряться.. Пойду возьму Малинку, накачу Linux, там это есть... и вооще это IoT, модно и современно, C то уже такое себе, хочу на Rust писать.... ассемблер??? вы че совсем, я что на пенсионера похож? человек способен только на 10% лучше компилятора написать...." и прочее бредовое ко-ко-ко....
On 3/27/2024 at 10:23 PM, Arlleex said:Реально критичные ко времени процессы выполняются на аппаратном уровне - ПЛИСами или возможностями периферии. CPU тут лишь как связующее звено для управления такой периферией. Исходят из расчета на достаточную производительность CPU с запасом, чтобы, например, успеть подготовить данные для отправки на эту самую "быструю" периферию.
Абсолютно в точку!! Я сам очень люблю ПЛИС + многоядерный CPU. Но поголовное использование такого не всегда оправдано, к сожалению, так как тащит много накладных расходов как в разработке так и в стоимости изделия. Конечно когда нужен реал-тайм для управления радиолокатором, то тут конечно без вариантов - ПЛИС)) А если это какой-то пром. прибор где например тоже осуществляется сканирование, но допустим оптическим дефлектором(где не нужно много вычислений), его управление вешается на таймеры, работу которых нужно корректировать каждые 10мкс, т.е. реал-тайм полный, но вычисления, спокойно можно сделать в первые 5 мкс (что бы за остальные 5 мкс периферия спокойно приняла новые значение и подготовилась к новому циклу). Прервались в начале на 0-ой мкс, посчитали, что надо за 3-5 мкс, и дальше софт может работать с тем что выходит из реал-таймовой части, и/или курить бамбук и заниматься любыми прикладными не реал-таймовыми задачами что послать на сервер, там дисплей какой то обслужить и т.д. .. Это реал-тайм? ДА! потому что мы обязаны принять решения до следующих 10 мкс. Нужен ли тут ПЛИС, нет - он избыточен.
On 3/27/2024 at 10:23 PM, Arlleex said:В последнем ядре, безусловно, есть свои механизмы, но они не гарантируют никаких +/- 1..2..5 тактов.
Не гарантируют, вы абсолютно правы! Но если немного пораскинуть мозгами и чуток позаниматься разработкой кода, а не кодописанием. То такие результаты вполне себе получаются даже почти без бубнов
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/27/2024 at 9:06 PM, jcxz said:Я вообще-то писал не про время входа в свой ISR, а про случай, когда ваше срочное прерывание возникло в тот момент когда уже только начался вход/выход в другой ISR. И не про ARM-ы с перключением состояний FIQ/IRQ, а про Cortex-M с его NVIC (STM32). Никакой стабильности там быть не может по определению. А будет джиттер в десятки тактов (опять же - Cortex-M).
Так что cortex -m что -r, что -a. Это ж всё ARM ))) но теперь понятно, вы про сравнение nvic и fiq/irq.
-
On 3/27/2024 at 8:32 PM, jcxz said:
Не верю! Сказки не надо рассказывать. Один вход или выход в ISR занимает уже десятки тактов (это если контекст FPU не сохраняется/восстанавливается; иначе будет ещё печальнее).
Точно такие же сказки - максимальное время активации задачи во FreeRTOS == 900нс. По причине (как уже сказали выше) - что сервисы РТОС выполняются как правило при запрещённых прерываниях.ЗЫ: Сказочникам советую почитать описание CPU и посмотреть исходный код сервисов FreeRTOS. Для спуска с небес на землю...
Кроме ПЛИС можно взять МК с богатой периферией, и реализовать нужный функционал силами этой периферии.
Вам осциллограмму снять? Ну да десятки, я не спорю, Время входа по событию от периферии в FIQ с выгрузкой всех регистров в стек при 160 МГц на Cortex-R4F, у RM47 равно около 63 тактов вроде(ща уже не помню). Но это очень стабильное время, я ж говорю +-1...2 такта максимум, оно никуда не плавает, поэтому его спокойно можно точно учитывать. Но это очень много т.к. у RM47, прерывания хитрые там висит куча защит(они для промышленности и автоиндустрии) и как прерывания, так и внутренние шины медленные. На stm32 быстрее бегать должно) но насколько стабильно я уже не и помню лет 13 с ними дела уже не имел.
-
On 3/27/2024 at 7:06 PM, Arlleex said:
Это не рушит внутренности ОСРВ как таковой. Она как и обычно будет думать, что только она и запущена на проце и никаких прерываний вовсе нет. А они есть, и смещают идеальную временную диаграмму обработки событий и реакцкию на них.
А есть в FreeRTOS функционал выделения ему только конкретных прерываний? Допустим полностью запретить FIQ, и разрешить несколько IRQ конкретных(допустим от периферии).
On 3/27/2024 at 7:06 PM, Arlleex said:Это не рушит внутренности ОСРВ как таковой. Она как и обычно будет думать, что только она и запущена на проце и никаких прерываний вовсе нет. А они есть, и смещают идеальную временную диаграмму обработки событий и реакцкию на них.
т.е. в ее ядре нет обязательного функционала какой-нибудь сторожевой собаки?))
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/27/2024 at 7:00 PM, Arlleex said:Попробуйте нагрузить систему большим количеством параллельно работающих шинных мастеров: DMA, Ethernet/USB DMA, алгоритмами, активно пользующимися групповой загрузкой/сохранением LDM/STM на реализациях CPU (я про Cortex-M) без возможности рестарта их после прерываний и т.д. Никаких 1, 2 и даже 10 тактов там не будет🙂
опять же без проблем ))) Допустим на том же RM47(у STM-ов тоже разделение есть, но я не помню какое) шина разделена на несколько грубо говоря секторов(кросс-мультиплексирование), на одном секторе висит одна периферия, на другом другая, на третьем DMA, на четвертой еще RAM ну и т.д. Если нет пересечения то паралельные потоки на одной шине друг друга вообще не чувствуют
К примеру
Допустим SPI в одном секторе, Таймеры в третьем, АЦП в четвертом.
Допустим у тебя проц постоянно дергает АЦП тогда пишешь так, что бы в сектор АЦП лез только CPU (но тогда конечно да остальную периферию на этом секторе ты как бы "потеряешь" для других мастеров). А DMA переносит дату с SPI в конкретную область RAM, к которой обращается CPU только в определенное время, когда гарантировано туда не лезет DMA, и в таймер. В итоге вот пример когда все работает и нет ни одного пересечения и задержек.
""""""
LDM/STM на реализациях CPU (я про Cortex-M) без возможности рестарта их после прерываний
""""""
а это как? Это ж прямая потеря данных. LDM в любом случае выполнится
-
On 3/27/2024 at 5:56 PM, aaarrr said:
Нет: какая может быть опасность, если только не рушить данные и контекст?
А вот допусти такая
On 3/27/2024 at 6:40 PM, Arlleex said:На каком-нибудь ARM7 с обычными прерываниями FIQ/IRQ вход в критическую секцию запрещает все прерывания, а не только групповые, как у Cortex-M.
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 3/27/2024 at 6:04 PM, Arlleex said:Если прям там реалтайм реалтаймович, то самым надежным способом будет поставить ПЛИС или SoC CPU + FPGA, на ней крутить этот самый реалтайм, а управлять CPU.
Выцеплять даже микросекунды на обычных CPU/MCU - дело бесперспективное.
Да вы совершенно правы, в крупных проектах, так и будет.
Есть мелкие где ПЛИС, явно избыточен.
"""
Выцеплять даже микросекунды на обычных CPU/MCU - дело бесперспективное.
"""
Вообще без проблем. Если тайминго критические вещи писать на ассемблере(или супер прозрачном С) и запускать все это в прерываниях с таймером. То легко получается джиттер такого кода в районе 1, ну 2 тактов. А то и вообще без него.
On 3/27/2024 at 6:27 PM, dxp said:Если нужна прямо такая лютая риалтаймовость, то почему просто не выполнять этот код (4 мкс) прямо в обработчике прерывания?
К тому же, на фоне 200 МГц тактовой проца 10 мкс выглядят не так уж мало, а тормознутость RTOS -- понятие растяжимое. Если не обременяться сложными планировщиками, не цеплять толстые хуки на процессы переключения контекстов, то там время передачи управления вполне себе не страшное -- например, на Cortex-M4 при 168 МГц время передачи управления (не просто переключение контекстов, а именно от возникновения события до получения управления кодом потока) порядка 900 нс. Это для самого приоритетного потока. Можно распихать этот требующий риалтайма код по приоритетным потокам (которые будут сами нагло отбирать управление у менее приоритетных, когда им надо) и не придумывать ничего.
Благодарю за ответ! Насколько я понимаю логику RTOS, 1 процесс по хорошему должен выполнять 1 раз в 1 квант времени. Иначе никак не сделать четкое временное детерминирование. Теоритически можно в них сделать минимальный квант времени 10 мкс. Но! Практически это не целесообразно, так как вы правильно заметили, только вход в таск будет уже 900нс(с системным прерыванием)! плюс код, допустим 4 мкс... и далее остается 5 мкс. Я видел в статьях по FreeRTOS, что всякие функции семафоров, очередей, на по моему 180МГц(там тоже Cortex-M4 был), занимали от 5 до 25 мкс. Так что тут так не выйдет.
-
On 3/27/2024 at 5:40 PM, aaarrr said:
На всяких кортексах запустить поверх не проблема, достаточно снизить приоритет прерываний ОС до нужного уровня. Но всю синхронизацию между ОС и собственным кодом придется городить врукопашную.
Вот! Я собственно и имел ввиду, так как не работал с RTOS до этого, насколько безопасна для RTOS, такая штука, когда у нас есть регулярные массивные прерывания приоритнее чем RTOSовские... Есть ли какие-то участки работы RTOS, которые опасно для нее прерывать?
про синхронизацию - да тут как раз и не страшно и понятно)
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
Добрый день!
Делаю ответственные высоконадежные проекты на МК, и всяких многоядерных SoC, для задач, где требуется реакция на события порядка наносекунд, и с различными процессами периодичностью мегагерцы, килогерцы и т.д.
Всегда пишу такие вещи baremetal, никаких ОС и стороннего софта. Только мой четко детерминирваннных код, который непосредственно и очень тесно связан с периферией. Предпочитаю практически не пользоваться никакими библиотеками, а все писать с регистрами и даташитом на конкретный камень))))
Если уж под ОС, то под Linux и тогда уже сразу забываем об всяких спец и выкоответственных применениях, просто по сути обычный кодинг под ОС.
Но тут появляется целая серия проектов, в которых есть часть скоростного высоконадежного кода(как я описал в первом абзаце), и есть часть условно "не ответственного" - всякие свистоперделки по файловым системам, всякие TCP/IP ну итд... Сразу скажу, что по различным архитектурным и схемным моментам, полностью разделить этот код нельзя, ну т.е. высоконадежная часть крутится на одном камне, а с остальная на другом. Все необходимо делать в одной системе.
Есть еще один нюанс - проектов будет не один а целая серия, и в ней применяются очень разные по ресурсам вещи от МК TI TMS570 / RM47 (одноядерные МК на Cortex-R4/R5 до 200 МГц клока) и до всяких страшных многоядерных штук с ПЛИС. Но круг задач у этих проектов и подход к их созданию очень похожий, отличие по сути в объеме систем и количеству процессов. Поэтому я хочу выработать так сказать общую концепцию и подход к софту.
Можно ее назвать хоть собственной ОС, хоть просто так сказать "крупнокусковые" кодовые стандарты. Это без разницы.Я хочу разделить весь код грубо говоря на 3 категории.
1 категория. Работает с высоконадежными скоростными реал-тайм задачами, и пишется близко к периферии вместе с ассемблером. Грубо говоря допустим нужно что бы какая то часть кода выполнялась каждые 10 мкс - значит каждые 10 мкс, все остальные идут лесом, и по глобальному прерыванию этот код работает, тут уже моя задача(о не какого-нибудь планировщика), что бы это код выполнился за разумное время. К примеру он выполнился за 4 мкс. У нас осталось 6 мкс свободного времени для всех остальных процессов.
2 категория. Второй слой - это четко детерминированные процессы с шагом, который допускает 1 категория (по round-robin в четкое время по таймеру), всякие "условно" редкие процессы(100us - 100мс), но которые также отсосящиеся к критически важным с четким таймингом. Эта часть кода тоже полностью моя. Она соотсветственно может безопасно прерываться 1-ой категорией. Так же она является мостом/буфером связи между 1 и 3 категорией. Т.е. процессы из 3-ей категории не имеют прямой доступ ни к периферии ни к данным процессов 1-категории.
3 категория. Тут уже просто валовый софт, который работает со всякими не детерминированными процессами - работа с флешкой/диском, работа с монитором, каким то долгим интерфейсом ну и т.д.
Прошу прощения за столько букв)))) А теперь собственно вопрос!
Допустим для 3-ей категории я хочу использовать какую-нибудь RTOS, да бы не писать всякие рутинные вещи, допустим даже FreeRTOS так как по ней много доков.
Насколько удобно и в принципе возможно запустить ее так сказать поверх другого более приоритетного кода?Сразу оговорюсь - я не жду от RTOS работы с периферией с моим МК, периферийные дрова для работы с ней я буду сам писать, также мне не принципиально поддержка STM32, так как в обозримом будущем я не буду на них работать.
По сути мне нужен крепкий такой шедуллер, в таски которого я из своего софта 2-категории кину, например, "Запиши вот это на диск". В таске этот запрос обрабатывается и кидается запрос на API ядра RTOS который работает с файловой системой, Выход этого API подцеплен к моему драйверу, допустим SPI, который уже кинет raw поток (сформированный API) на SPI-периферию (а она уже на флешку соответственно).Еще раз простите, тяжело это все описать))) если вы что то сумели понять, подскажите пожалуйста
"Насколько удобно и в принципе возможно запустить FreeRTOS так сказать поверх другого более приоритетного кода?" -
On 12/24/2023 at 7:27 AM, injener said:
Познакомитесь с проблемой длинного кабеля со всеми вытекающими
Какие там могут быть проблемы, если по нему пускать сигнал с частотника отфильтрованный нормальным синус-фильтром? Т.е. фактически несколько искаженные допустим 20-100 Гц... никто же не собирается по ним ШИМ на 100кГц вкорячивать...
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 4/26/2023 at 1:01 PM, sonycman said:Как это нет?
Да в том-же xfsbl_main.c функция main:
XFSBL_STAGE3: Load the partitions: XFsbl_PartitionLoad - загрузка пользовательской программы.
XFSBL_STAGE4: Handoff to the applications: XFsbl_Handoff - запуск программы.
Всё это находится за 5 минут 👀
У меня в этих кусках нет никакой загрузки. Больше скажу там даже нет никакой работы с DDR.
может у меня сами куски эти какие-то кривые, почему то.
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 11/20/2023 at 10:09 PM, Stepanov said:А УПП это и есть симмисторный фазный регулятор, он помех выдаёт не менее чем любой трёхфазный преобразователь.
С ЛАТРами при 30кВт с нагрузкой в виде насоса может быть неожиданная засада (о ней в одной старой книжке старого опытного электрика было написано, штука не очевидная) насос имеет сильно нелинейные нагрузочные характеристики. Короче говоря большой шанс что никакого плавного разгона с ЛАТР не получится, на малом токе мотор не будет входить в синхронизм, а потом на очень небольшом участке уже почти полного рабочего тока быстро выйдет на номинальные обороты. Не надо забывать что у асинхронных машин обороты прежде всего частотой тока определяются, а ЛАТР ей вообще никак не меняет, и это будет попытка регулирования за счет скорости проскальзывания в несинхронном режиме, что в случае полного успеха при такой мощности приведет к.. перегреву ротора. Да да.
Правильное решение тут одно: отставить догматизм и действовать грамотно. А именно обеспечить требуемый комплекс мер по устранению помех от нормального частотного преобразователя. Это фильтры на входе, фильтр на выходе, причем хороший LC фильтр с требуемой полосой частот, и да он будет по размеру больше чем сам преобразователь, это нормально. Правильный кабель. правильное заземление. Правильный железный шкаф расположенный подальше от приборов. Практически это не сложно и не дорого и обеспецит наилучший результат. Этим путём от ПЧ помех будет меньше чем из питающей сети 3х400В.
On 12/14/2023 at 3:53 PM, Stepanov said:Тут моторик на 30кВт. Любые методы изменения напряжения для уменьшения (а увеличить сверх номинальной увеличением напряжение невозможно) оборотов основаны на использовании мотора в режиме с большой скоростью проскальзывания, и в этом случае во первых никакие 20...30кВт от него не получить, даже на половинной от номинальной скорость вращения, получить удастся максимум 5-6кВт. Во вторых это нелинейный и нестабильный режим сильно зависящий от нагрузки, практически это неприменимо. В третьих это режимы с малым КПД, и потери будут в роторе, он будет перегреваться. Трансформаторы с отводами применяются во всяких небольших двухфазных моторах для вентиляции, те моторы специально рассчитаны для работы с большими скоростями проскальзывания, в большинстве моделей у них внешний ротор и интенсивное охлаждение.
Благодарю, за развернутый ответ! Собственно понимаю эти про ЛАТР нюансы, но вы еще подтвердили мои мысли.
С импульсными очень сложно - рядом измерительное оборудование, и частотник даже на 1 кВт, уже хорошенько ловится им. Видимо единственный вариант ставить частотник за километр хорошенько фильтровать выход и тянуть уже к двигателю.
On 12/15/2023 at 4:53 PM, injener said:1. Попробуйте реакторный пуск (запускаем через реактор, потом выкорачиваем его).
2. Автотрансформаторный пуск - нечто вроде вашего ЛАТРа. Но ЛАТР долго не проживет.
3. Может быть, есть смысл использовать асинхронник с фазным ротором? Тогда отработанное решение - реостат со ступенчатым переключением.
4. В случае фазного ротора вообще открывается много возможностей по пуску и даже регулированию, например в каскаде с другой машиной или преобразователем частоты
Мотор уже есть, менять его нельзя.
On 12/15/2023 at 4:42 PM, sanya221 said:У человека похоже классическая задачка- ограничение пускового тока асинхронника,на валу которого постоянно висит насос. Есть опять же известные много лет методы- коммутация звезда/треугольник, если надо увеличить ток и момент (не наш случай), включение последовательно на момент старта резисторов или дросселей для уменьшения тока. Тут главное не перестараться, иначе двигатель под нагрузкой просто не запустится.
Реле применять не желательно, - сильные помехи при переключениях.
On 12/1/2023 at 7:53 AM, dOb said:Если частотник сертифицирован, значит он прошёл испытания на помехи.
Измерительному оборудованию пофиг на все эти сертификаты)))
естественно процессор эти помехи не собьют - но изгадить сигнал с датчика до неузнаваемость, когда ты и так его показания на уровне шумов фильтруешь/ловишь и киловатных инвертер может спокойно.
-
On 4/16/2023 at 8:44 PM, Alex77 said:
применительно к zynq --- FSBL загружает и запускает программу пользователя и прошивку плисы докучи. По идее это всё прописано в документации...
Сгенерированный код FSBL смотриться в Vitis, и его спокойно можно разобрать на конкретные этапы - настройка тактирования, периферии, памяти, изоляции ну итд... Но в нем !нет куска! который брал бы и к примеру копировал пользовательскую программу по выбранному адресу, FSBL обрывается на настройках.... отсюда и вопрос, при создании бутлодеров Vitis сам дописывает эту загрузку? Т.е. пользователю ее код просмотреть и проконтролировать невозможно?
-
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
On 4/13/2023 at 9:17 PM, sonycman said:После загрузки пользовательской программы, FSBL передает управление ей - переходом по адресу Entry point.
Вроде бы доки в сети доступны, курите их и закрепляйте практикой.
Это понятно, но кто и как выполняет загрузку пользовательской программы?
Запуск RTOS поверх более приоритетного кода
в FreeRTOS
Опубликовано · Изменено пользователем Quantum1 · Пожаловаться
Вы правы, но как я в шапке описал, хочется универсальный так скажем "стек" подходов, технологий и дорожную карту разработки с проектами в том числе где FPGA не требуется, и вполне достаточно 1-2 ядра.
Да благодарю, пока еще изучаю это)