Очень круто! :) То есть уже сейчас можно попробовать самому под RTEMS запустить Qt с linuxfb?
И еще такой вопрос, возможно ли добавление также порта Qt под Embox (я имею ввиду QPA части и мб конфигов), если, например, получим показатели не хуже чем на RTEMS? Не вместо RTEMS конечно, а как альтернативу.
Moveblocks стандартный пример из Qt, так что думаю раз QT запустили, то и виджеты осилим. Виджеты так-то проще чем анимация, на самом деле. Надеюсь, что уже скоро и с виджетами попробуем :)
Возможно, они как раз пишут что у них в 5.8 какая-то прям новая система конфигурирования, и вероятно Qt получится еще лучше сконфигурировать. Так что да, надеюсь сделаем 2й заход :)
Про стеки понял только что два крайних — это
в одном адреса функций а в другом адреса возвратов обратно из функций,
Не совсем, в одном стеке лежат адреса возвратов, а в другом — оперативные регистры (те, которые из вращаемого окна). Это нужно потому как региcтровый файл имеет весьма ограниченный размер, и в случае его переполнения нужно сбросить его содержимое в память — на стек. То же самое касается выхода из процедуры — может понадобится загрузить регистры обратно со стека.
но каким образом это вообще все разделяется и что вообще это за адреса,
Про адреса — это Instruction Pointer, он сохраняется в регистрах CR0/CR1. По сути это самый обычный адрес возврата, как, например, Link Register в ARM.
И да, тема глобальных регистров не раскрыта.
Ага, но мы их пока и не используем :) Так что решили про это не писать. Да и показались они нам более классическими нежели вращаемые, т.к. к ним доступ кажется осуществляется по прямой адресации g0, g1,… Т.е. это по сути регистры общего назначения, если опять проводить аналогию с ARM.
Точно не могу сказать, но на данный момент существенных ограничений для этого я не вижу… Запас по производительности и памяти имеется, звук на 48 kHz записывать и проигрывать умеем, в составе pjsip opus есть. Думаю можно попробовать подцепить его вместо PCM.
Да, статья предполагает некое знакомство с STM32. Мотивация была описана в нашей предыдущей статье. Я в первом обзаце дал на нее ссылку. Но может быть стоило еще раз об этом написать отдельно (со стороны лучше видно). Основная идея заключается в том, что на Линуксе сделать такой телефон довольно просто, но и платформа должна быть уже не такая мелкая. А нам хотелось сделать телефон с минимальными аппаратными ресурсами (например, в целях снижения его стоимости).
Спасибо.
Я тоже находил эту багу в llvm когда разбирался с gcс, но вот Ваш патч тогда не нагуглился. Похоже ARM убрал фреймы в новом стандарте AAPCS. И насколько я понимаю, когда они переделывали APCS, то одним из аргументов отказаться от фреймов была производительность, поэтому они сейчас на такие патчи реагируют негативно. Ну и плюс для тех же Cortex-M, ARM активно внедрял аппаратную отладку и профилирование, те же ITM.
Патч может бы и взяли, но довольно сложно будет поддерживать свою версию компилятора.
У gdb свой метод — через отладочную информацию в формате DWARF. Я сильно глубоко не разбирался в структуре формата, но знаю, что он более широкий, чем приведенные в статье (т.е. тот же ARM.exidx можно получить из DWARF). То есть когда вы собираете elf файл с отладочной информацией, компилятор создает там секцию .debug_frame, в которой лежит информация в формате DWARF, предназначенная для раскрутки стека. Посмотреть на то как она выглядит можно через readelf --debug [file]
p.s.
Немного дополню: Два метода приведенные в статье — это методы трассировки стека в обычном режиме работы программы. Без подключения отладчика.
А почему бы не рассказать про приложеньки под Embox? Сколько труда нужно, чтобы поднять на ней сетевой стек на какой-нибудь K1879ВЯ1Я? А сколько — чтобы портировать её туда?
Так в нашем блоге хватает статей. И про портирование в том числе тоже есть. А приложеньки? Ну так у нас это POSIX. Погодите, а зачем вам тогда перенос сетевого стека и порт на плату, это же другие люди должны делать. Вы же сами выше писали ровно это.
А про MBed — ну привел человек какое-то очередное API, что-то на нем написал. Какая-то онлайн-среда разработки. И что дальше? Зачем все это в реальных проектах? Вы же как раз про реальные проекты говорите. Я что буду что-то через сайт mbed.com программировать??.. Пффф. По-моему опять начали спорить о вкусах.
Никого не хочу этим обидеть. Просто выражаю мысль о том, что есть разные темы, и не все они отдельно взятому человеку кажутся нужными и интересными. Но я такое просто игнорирую и не читаю в таком случае.
Ладно, давайте не будем спорить :) Я же не спорю, что jtag вещь полезная, и даже необходимая. Но вот есть немало людей, которые пользуются эмуляторами, вот можно полазить форумы почитать. Там, вероятно, 80% процентов их проектов «учебные». А под железо разве все прям промышленные? Хорошо, давайте считать, что эмулятор нужен только при написании ОС.
Ну вот вам это не нужно, а кому-то интересно узнать. Не про приложеньки под FreeRTOS же рассказывать в самом деле)) А давайте дальше пойдем. Зачем сегодня в чем-то разбираться — можно ведь прийти в магазин и купить айфон с полки. Смотрите как удобно — ни эмулятор, ни jtag не нужен, ляпота!
На эмуляторе все нормально эмулируется с точность до клоков. Да, клоки придется настраивать на железе. И да, могут и другие проблемы возникнуть — сталкивались не раз. Но уарт, контроллер прерываний, системный таймер, сетевуха — все это обычно имеется. Плюс можно тестировать много архитектур. Плюс можно поднять много эмуляторов и тестировать какую-то распределенную логику на них. В общем штука безмерно удобная.
Конечно я проверил на эмуляторе QEMU. В этом весь смысл.
О том что запускать будем на QEMU говорится в самом первом абзаце, еще до ката. Смотрите, я не хочу усложнять код. В идеале, можно было вообще уарт не трогать, а просто сделать бесконечный цикл, и на этом все. Проще некуда. Но хотелось чуть большей информативности, но без объяснения как работать с периферией.
Вот этот самый адрес 0x4000c000 берется из документации, там лежит регистр DR нулевого уарта. Мы не будем заниматься настройкой, а попробуем сразу напрямую положить в него символ
Я тут не пытаюсь учить уарт программировать. Тут объяснялись базовые вещи по загрузке образа. И ниже говорится
Если вам нужен более содержательный функционал, стоит воспользоваться готовыми вещами. Мы добавили поддержку данной платформы в Embox. Называется этот темплейт platform/stellaris/lm3s811evb. Поэтому если кто-то хочет попробовать запустить чуть более серьезную вещь (консоль, таймер, прерывания)
И еще такой вопрос, возможно ли добавление также порта Qt под Embox (я имею ввиду QPA части и мб конфигов), если, например, получим показатели не хуже чем на RTEMS? Не вместо RTEMS конечно, а как альтернативу.
Не совсем, в одном стеке лежат адреса возвратов, а в другом — оперативные регистры (те, которые из вращаемого окна). Это нужно потому как региcтровый файл имеет весьма ограниченный размер, и в случае его переполнения нужно сбросить его содержимое в память — на стек. То же самое касается выхода из процедуры — может понадобится загрузить регистры обратно со стека.
Про адреса — это Instruction Pointer, он сохраняется в регистрах CR0/CR1. По сути это самый обычный адрес возврата, как, например, Link Register в ARM.
Ага, но мы их пока и не используем :) Так что решили про это не писать. Да и показались они нам более классическими нежели вращаемые, т.к. к ним доступ кажется осуществляется по прямой адресации g0, g1,… Т.е. это по сути регистры общего назначения, если опять проводить аналогию с ARM.
Я тоже находил эту багу в llvm когда разбирался с gcс, но вот Ваш патч тогда не нагуглился. Похоже ARM убрал фреймы в новом стандарте AAPCS. И насколько я понимаю, когда они переделывали APCS, то одним из аргументов отказаться от фреймов была производительность, поэтому они сейчас на такие патчи реагируют негативно. Ну и плюс для тех же Cortex-M, ARM активно внедрял аппаратную отладку и профилирование, те же ITM.
Патч может бы и взяли, но довольно сложно будет поддерживать свою версию компилятора.
readelf --debug [file]p.s.
Немного дополню: Два метода приведенные в статье — это методы трассировки стека в обычном режиме работы программы. Без подключения отладчика.
Так в нашем блоге хватает статей. И про портирование в том числе тоже есть. А приложеньки? Ну так у нас это POSIX. Погодите, а зачем вам тогда перенос сетевого стека и порт на плату, это же другие люди должны делать. Вы же сами выше писали ровно это.
А про MBed — ну привел человек какое-то очередное API, что-то на нем написал. Какая-то онлайн-среда разработки. И что дальше? Зачем все это в реальных проектах? Вы же как раз про реальные проекты говорите. Я что буду что-то через сайт mbed.com программировать??.. Пффф. По-моему опять начали спорить о вкусах.
Безусловно, порты разные, но как именно устроен vector table, thumb mode и тд — общее. Суть статьи была в этом. А не в драйвере уарта.
На эмуляторе все нормально эмулируется с точность до клоков. Да, клоки придется настраивать на железе. И да, могут и другие проблемы возникнуть — сталкивались не раз. Но уарт, контроллер прерываний, системный таймер, сетевуха — все это обычно имеется. Плюс можно тестировать много архитектур. Плюс можно поднять много эмуляторов и тестировать какую-то распределенную логику на них. В общем штука безмерно удобная.
О том что запускать будем на QEMU говорится в самом первом абзаце, еще до ката. Смотрите, я не хочу усложнять код. В идеале, можно было вообще уарт не трогать, а просто сделать бесконечный цикл, и на этом все. Проще некуда. Но хотелось чуть большей информативности, но без объяснения как работать с периферией.
Я тут не пытаюсь учить уарт программировать. Тут объяснялись базовые вещи по загрузке образа. И ниже говорится