Перейти к содержанию
    

Quantum1

Участник
  • Постов

    208
  • Зарегистрирован

  • Посещение

Репутация

1 Обычный

Информация о Quantum1

  • Звание
    Местный
    Местный

Посетители профиля

2 495 просмотров профиля
  1. Да никак не быть, никак под него не писать и все! А зачем мне они вообще нужны? Очередная глубокая проприетарщина какая-то, хочет Тексас скрывать - пожалуйста! Я просто использовать не буду, так как не вижу прозрачных явно описанных преимуществ. В моем случае когда тебе нужно более 2 ядер, то там уже и без ПЛИСа тяжеловато, поэтому эти PRUSSы вообще никакого интереса не вызывают. Кстати у того же Тексаса из новых серий хватает хороших многоядерников на Cortex-R5, с нормальными описаниями и плюшками При чем тут тестирование! До него еще доехать бы! Ты идешь по минному полю, не зная где сейчас рванет. Допустим разработал алгоритм, какой-то код накидал, и тут начинается - это место не так работает, тут задержки рушат всю концепцию, а это он оказывается только в урезанном виде поддерживает, а тут он флаги неожиданным образом ставит, тут прерывание не срабатывает. Это не разработка это треш какой то. Или вы предлагаете для каждого регистра свой тест писать, что бы просто догадаться что это он вдруг тут стал неожиданно делать? Ну или классический путь кодописа - накинуть Линукс и радоваться каким то там трем примерам из сети, радостно крича: IoT, IoT!!! (Хотя если уж настолько нужно описание Тексасов, я думаю через знакомых в иностранных компаниях спокойно можно их поиметь, им то их дадут по запросу, самое главное, что у Тексаса они точно физически есть! А вот у китайцев нет))))) Вы вот щас на полном серьезе предлагаете многоядерную, сложную систему, пытатся освоить на bare-metal, не имея нормальной документации, просто на шару? Вы либо какой-то сверх оптимист, или вы просто стебетесь)
  2. ну так тогда на них вообще невозможно работать)) Из линуксовских исходников вытаскивать информацию о работе периферии и регистрах ??? Это ж каким мазахистом надо быть!)) А потом еще и пофигистом заявляя что твой прибор отказоустойчив, хотя ты сам про него и половину толком не знаешь)) ты иной раз с хорошим описанием днями сидишь какой-то заковыристый косяк выгрести не можешь, который в итоге в железе сидит, материшься, почему его нет в errata, плюешь и переделываешь такой прекрасный и готовый свой алгоритм дабы этот момент обойти. Я думаю проще извернуться и привезти нормальное железо, пусть даже за x3 цену, но оно будет работать, а ты будешь спокойно спать, и уверенно развивать свою компанию....
  3. Я бы не стал с ними связываться, во первых свою линейку разной производительности хочу все таки на Cortex-R серий строить, как база для реал-тайм дел. Второе как я понимаю по разным отзывам на уровне железа эти китайцы не особо прозрачны. По крайней мере очень многие жаловались, что есть проблемы с полноценным описанием. DSP(DSP это вообще не совсем про реал-тайм(хотя он там обязателен, но он его "как бы" обслуживает, а не создает) это больше про монотонное числомолочение под всякие цифровые фильтры и т.д.) как таковые я не очень люблю, если нужно применить обширные числомолотилки, на ПЛИС обычно изящнее и проще выходит, без кучи проприетарности конкретного DSP.
  4. Судя по состоянию, этот пациент уже давно метрв....
  5. да хрен с ним с полноценным, меня и сильно ограниченный устроил бы. Главное что б ПО можно было сразу на всё писать и использовать, пусть и рядом особенностей и требований.
  6. Я вот дословно тоже самое но на Zynq Ultrscale для R5, стараюсь сделать - важный код в OCM/TCM. Обидно конечно, что при этом так сказать быстрая-RAM сокращается значительно. я тут пытаюсь делать bank-память. Т.е. допустим пока критичный код крутится из OCM/TCM. Другой процесс подготавливает там же допустим другой критичный код. И как только потребуется, проц переходит уже на новую область OCM/TCM с новым кодом. Геммороя конечно не меряно, но даже предварительные результаты очень хороши. Так можно уложится в маленький размер OCM/TCM. Но тут выход только один - то что грузим в OCM/TCM, только самописный ассемблер, никаких компиляторных дел. Вот тогда система реально раскрывается как по быстродействию, и по малому размеру кода. Я тут всерьез, задумался об отечественной ОС Embox. Как заявляется она способна запускать линукс приложения написаны чисто под линукс даже на мелких МК. Для меня это идеальная тема для больших SoC систем пишем под полноценный линукс. А для мелких на Embox берем куски/части своего же линукс кода и запускаем, но конечно они должны быть не тяжелые ибо мелкий МК. Вроде как просматривается замечательная экономия времени, универсализация и масштабируемость. Мож работал кто? Слишком аппетитно выглядит, что б быть прям правдой) Да и ее разраб от меня в часе езды походу живет)))
  7. Тогда трижды благодарю)))) че то для 400 МГц, 450 нс действительно это прямо совсем печаль-печальная....
  8. Да я с вами и не спорю, что это мои хотелки! И они могут не отражаться в реальности. Под реакцию на состояние, я имел ввиду только поведение кода. ИИП никак не относится к этому. Допустим пользовательский таск захотел залезть и потереть настройки самой системы без спец разрешения, ОС должна ему сказать низя-низя! Кстати в Zynq Ultrascale, есть великолепная вещь - защита аппаратная областей адресов, можно принудительно ограничить какому то ядру область памяти, и только туда он может ходить, если пытается в другие залезть - его во первых шлют лесом, во вторых могут вызвать прерывание на ошибку. Отказоустойчивая ОС по идеи должна тоже такое делать, но софтово. Или таск зазвал полную, власть и не отдает его больше чем некое критическое время - опять же таск обрываем, думаем что делать.Или какой то таск токен на периферию держит и не отдает. Опять же повторюсь! Это мои хотелки. Но вот уже неделю как решил почитать про эти RTOS, и такое впечатление, что это вообще не про ОС и надёжность. А это просто компактная среда планировщика задач с некоторыми интересными драйверами на периферию.... ОС и тем более с гарантированной надёжностью тут особо то и не пахнет. По сути "надёжность" это просто следствие потому что в планировщике мало кода и он простой и прозрачный... Заранее извиняюсь, я не с кем не спорю, просто всегда считал, что раз называется ОС да ещё и реал-тайм с сертификатами, то там ворох защит от сбоев и неправильного юзер ПО есть.... Ан нет....
  9. RTOS это ж про системы с высокой надёжностью, всякие сертификаты там имеют как подразумевает что любое действие прогнозируемо , в том числе сбой. Видел сети вот такое удачное определение: система реального времени должна предсказуемо, а не быстро, реагировать на любое событие или совокупность событий, вне зависимости от своего состояния и окружения. Кстати очень полезная информация, благодарю! На A9 ни разу не замерял это время, а он есть в Zynq 7000, иногда его использую. А в каком чипе ваш A9 стоял, и если не сложно от чего там поподробнее там прерывание было?
  10. да хоть по классике - прерывание по системному таймер(везде есть), хоть внешняя микрушка с window-WDT, тоже простая штука. RTOS ведь по идеалогии не имеет права повиснуть... по краней мере я от нее этого жду)))) может и напрасно)))
  11. А в этом и есть искусство разработчика, максимально эффективно и экономно выбрать и hard, и soft ресурсы для решения задачи. Или если выбирать нельзя, извернуться и решить задачу имеющимися. А то сейчас много кодописов "ОЙ! В этой библиотеке AVR, нет функции включения лампочки/открывания дверей, я что теперь в регистры и даташиты что ли лезть должен?? фу-фу-фу я ж програмист высокоуровневый! Я хочу задачи решать, а не в этих ваших битах ковыряться.. Пойду возьму Малинку, накачу Linux, там это есть... и вооще это IoT, модно и современно, C то уже такое себе, хочу на Rust писать.... ассемблер??? вы че совсем, я что на пенсионера похож? человек способен только на 10% лучше компилятора написать...." и прочее бредовое ко-ко-ко.... Абсолютно в точку!! Я сам очень люблю ПЛИС + многоядерный CPU. Но поголовное использование такого не всегда оправдано, к сожалению, так как тащит много накладных расходов как в разработке так и в стоимости изделия. Конечно когда нужен реал-тайм для управления радиолокатором, то тут конечно без вариантов - ПЛИС)) А если это какой-то пром. прибор где например тоже осуществляется сканирование, но допустим оптическим дефлектором(где не нужно много вычислений), его управление вешается на таймеры, работу которых нужно корректировать каждые 10мкс, т.е. реал-тайм полный, но вычисления, спокойно можно сделать в первые 5 мкс (что бы за остальные 5 мкс периферия спокойно приняла новые значение и подготовилась к новому циклу). Прервались в начале на 0-ой мкс, посчитали, что надо за 3-5 мкс, и дальше софт может работать с тем что выходит из реал-таймовой части, и/или курить бамбук и заниматься любыми прикладными не реал-таймовыми задачами что послать на сервер, там дисплей какой то обслужить и т.д. .. Это реал-тайм? ДА! потому что мы обязаны принять решения до следующих 10 мкс. Нужен ли тут ПЛИС, нет - он избыточен. Не гарантируют, вы абсолютно правы! Но если немного пораскинуть мозгами и чуток позаниматься разработкой кода, а не кодописанием. То такие результаты вполне себе получаются даже почти без бубнов
  12. Так что cortex -m что -r, что -a. Это ж всё ARM ))) но теперь понятно, вы про сравнение nvic и fiq/irq.
  13. Вам осциллограмму снять? Ну да десятки, я не спорю, Время входа по событию от периферии в FIQ с выгрузкой всех регистров в стек при 160 МГц на Cortex-R4F, у RM47 равно около 63 тактов вроде(ща уже не помню). Но это очень стабильное время, я ж говорю +-1...2 такта максимум, оно никуда не плавает, поэтому его спокойно можно точно учитывать. Но это очень много т.к. у RM47, прерывания хитрые там висит куча защит(они для промышленности и автоиндустрии) и как прерывания, так и внутренние шины медленные. На stm32 быстрее бегать должно) но насколько стабильно я уже не и помню лет 13 с ними дела уже не имел.
  14. А есть в FreeRTOS функционал выделения ему только конкретных прерываний? Допустим полностью запретить FIQ, и разрешить несколько IRQ конкретных(допустим от периферии). т.е. в ее ядре нет обязательного функционала какой-нибудь сторожевой собаки?))
  15. опять же без проблем ))) Допустим на том же RM47(у STM-ов тоже разделение есть, но я не помню какое) шина разделена на несколько грубо говоря секторов(кросс-мультиплексирование), на одном секторе висит одна периферия, на другом другая, на третьем DMA, на четвертой еще RAM ну и т.д. Если нет пересечения то паралельные потоки на одной шине друг друга вообще не чувствуют К примеру Допустим SPI в одном секторе, Таймеры в третьем, АЦП в четвертом. Допустим у тебя проц постоянно дергает АЦП тогда пишешь так, что бы в сектор АЦП лез только CPU (но тогда конечно да остальную периферию на этом секторе ты как бы "потеряешь" для других мастеров). А DMA переносит дату с SPI в конкретную область RAM, к которой обращается CPU только в определенное время, когда гарантировано туда не лезет DMA, и в таймер. В итоге вот пример когда все работает и нет ни одного пересечения и задержек. """""" LDM/STM на реализациях CPU (я про Cortex-M) без возможности рестарта их после прерываний """""" а это как? Это ж прямая потеря данных. LDM в любом случае выполнится
×
×
  • Создать...