Как стать автором
Обновить

Комментарии 29

Для упрощения еще можно воспользоваться семихостингом. Для arm-none-eabi-gcc это будет что-то типа
arm-none-eabi-gcc -mthumb -mlittle-endian -march=armv7-m -mcpu=cortex-m3 test.c -o test --specs=rdimon.specs
Заработает стандартный printf и file IO, которые будут транслироваться на хост.

Для linaro тулзов arm-linux-gnueabi-gcc/arm-linux-gnueabihf-gcc еще проще:
arm-linux-gnueabi-gcc -static -mthumb -mlittle-endian -march=armv7-m -mcpu=cortex-m3 test.c -o test

В обоих случаях получаем бинарь, который можно запустить на QEMU и ввод-вывод будет редиректиться на хост.
В убунте эти тулзы можно установить из репозитария, а полученный бинарь автоматом будет запускаться через QEMU — очень удобно.
Спасибо, интересная альтернатива. Правда полученный бинарник на железке не запустить без пересборки с настоящими не-хостовыми функциями (как я понял, компилятор навставляет в этих местах bkpt в образе), но любопытно. Я такое не использовал, посмотрю.

На реальной железке этот проект не заработает хотя бы потому, что UART нужно настроить — заполнить конфигурационные регистры, включить тактирование итд. Кроме того в эмуляторе UART работает на скорости = бесконечность, а в рельном железе из "Hello world" пройдет лишь "H", ведь статус-регистр не проверяется на предмет окончания передачи. То, что заработало в эмуляторе, не факт, что будет работать на реальном железе.

Конечно может не заработать, я же явно указал в статье, что для упрощения не будем заниматься настройками уарта. Ниже в статье ссылка на эту платформу в Embox, там уже по-настоящему настраивается уарт, прерывания, системный таймер.

Тут смысл был не в том, чтобы научить в уарт писать, а чтобы показать как этот образ правильно собрать, чтобы он запустился.

Смысл статьи понятен, я лишь хотел сказать, что полагаться на эмулятор не стоит. В эмуляторе можно проверить лишь "математику" алгоритма. Лучше отлаживать на реальном железе через jtag/swd

Я согласен с Вами. Отлаживать нужно на реальном железе, «работа на эмуляторе» != «работа на железе». Например, именно на железе можно настраивать клоки, управление питанием. Но на эмуляторе можно отладить не только математику, но и большинство драйверов периферии (опять же, какие-то специфические штуки могут проявиться только на железе, но основная логика драйвера при этом сохранится). И если я вижу что какая-то платформа есть в эмуляторе, я сначала пробую ее, а уже потом иду за железкой.
А не знаете еще симулятора (кроме платных армовых тулзов), который может количество клоктиков просимулировать и профайл показать. На худой конец инструкции но без танцев с бубном, для QEMU я костыль сделал github.com/lieff/qemu-prof. Не знаю есть ли способ проще.
Не смогу подсказать. Мне кажется потактовый симулятор с выводом такого профайла — штука сложная, учитывая что нужно же и кэши процессорные симулировать тогда, если по-хорошему… Ну и еще, там нужно следить за сопроцессорами, и симулировать их в том же цикле что и ЦПУ, типа на одну инструкцию ЦПУ всегда исполняем одну инструкцию сопроцессора и тд (я видел такое в одном симуляторе для MIPS). Поэтому тот же куему ограничивается лишь генерацией Translation блоков с ассеблерными инструкциями. И вся периферия в куему делает ввод-вывод прямо в главном цикле с ЦПУ. Т.е. любые общения с периферией (тот же дма) будут сразу же «ухудшать» частоту ЦПУ. Так что в куему тогда нужно гигантскую архитектурну переделку производить, чтобы такое реализовать. Про другие открытые и более-менее поддерживаемы симуляторы для ARM я, если честно, не в курсе.
Да не, 16 байт (размер FIFO) пройдет, если FIFO по умолчанию включен. Может и 17 — FIFO+сдвиговый регистр.

Но сам код — жуть.
А что не так с кодом?
Где включение питания UART? Где включение его тактирования? Где установка делителей?

Ну и самый смак — отправка в DR без ожидания готовности.

Ну вот один из работающих вариантов для 16550
       int cnt = ((LSR & 0x20) != 0) ? OUT_FIFO_16550_SIZE : 0;
       if ((LSR & 0x40) != 0) /* TEMP - пустота сдвигового регистра */
          cnt++;
       for (int i = 0; i < cnt; i++) {
           uint8_t btOut;
           if (xQueueReceiveFromISR (port->data->transmit_queue, &btOut, &woken)) {
              port->regs->TFR = btOut;
              sent++;
           } else
              break;
       };

Вы статью читали?

Вот этот самый адрес 0x4000c000 берется из документации, там лежит регистр DR нулевого уарта. Мы не будем заниматься настройкой, а попробуем сразу напрямую положить в него символ


Я тут не пытаюсь учить уарт программировать. Тут объяснялись базовые вещи по загрузке образа. И ниже говорится

Если вам нужен более содержательный функционал, стоит воспользоваться готовыми вещами. Мы добавили поддержку данной платформы в Embox. Называется этот темплейт platform/stellaris/lm3s811evb. Поэтому если кто-то хочет попробовать запустить чуть более серьезную вещь (консоль, таймер, прерывания)
Вы хотя бы на имитаторе проверили работоспособность? Просто у меня есть сомнения, что этот код даже на имитаторе будет работать. И уж точно — не пойдет на железе.

Смените тогда заголовок, укажите, что пишите для имитатора, а не для железа.
Конечно я проверил на эмуляторе QEMU. В этом весь смысл.
О том что запускать будем на QEMU говорится в самом первом абзаце, еще до ката. Смотрите, я не хочу усложнять код. В идеале, можно было вообще уарт не трогать, а просто сделать бесконечный цикл, и на этом все. Проще некуда. Но хотелось чуть большей информативности, но без объяснения как работать с периферией.
Тогда причем тут Cortex-M3??? Тем более что порты у него бывают самые разные. Вы написали, как вывести hello world на эмуляторе.

Но я не понимаю, зачем нужен эмулятор. Математику проще отладить под windows или linux, а специфическое общение с железом на эмуляторе не отладить.

Такое впечатление, что статья писалась ради упоминания Embox.

P.S. Эмулятор сильно плох тем, что на нем сложно сделать регрессионные тесты. Портировав код под винду мы заменяем устройства на файлы и имеем стабильное прохождение тестов. На эмуляторе это сложно. Особенности железа он тоже адекватно не эмулирует.
Но я не понимаю, зачем нужен эмулятор

На эмуляторе все нормально эмулируется с точность до клоков. Да, клоки придется настраивать на железе. И да, могут и другие проблемы возникнуть — сталкивались не раз. Но уарт, контроллер прерываний, системный таймер, сетевуха — все это обычно имеется. Плюс можно тестировать много архитектур. Плюс можно поднять много эмуляторов и тестировать какую-то распределенную логику на них. В общем штука безмерно удобная.
Ну по вашему примеру видно, насколько «точно» имитируется UART. На реальном UART вы таким образом выведите максимум 17 байт (размер FIFO = сдвиговый регистр). Иными словами, то, что работает на имитаторе — не факт, что будет работать на железе.

При написании ОС — возможно, что имитатор удобней железа. Но в реальных (не учебных) проектах всегда есть железо и JTAG/SWD.

А если железо такое новое, что ещё и семплов нету — ну так его и в эмуляторе не будет.
Ладно, давайте не будем спорить :) Я же не спорю, что jtag вещь полезная, и даже необходимая. Но вот есть немало людей, которые пользуются эмуляторами, вот можно полазить форумы почитать. Там, вероятно, 80% процентов их проектов «учебные». А под железо разве все прям промышленные? Хорошо, давайте считать, что эмулятор нужен только при написании ОС.
Тогда причем тут Cortex-M3??? Тем более что порты у него бывают самые разные.

Безусловно, порты разные, но как именно устроен vector table, thumb mode и тд — общее. Суть статьи была в этом. А не в драйвере уарта.
А какая разница, как они устроены? Тот, кто пишет порт RTOS — тот в этом разбирается. А все остальные — просто используют готовый порт.

У меня полсотни экземпляров на разных ARM работают под FreeRTOS. Но в тонкостях vector table я не разбираюсь. Это прерогатива ОС, а не моя. Даже для написания драйвера мне это не нужно — дергается готовая процедура контроллера прерываний и всё.
Ну вот вам это не нужно, а кому-то интересно узнать. Не про приложеньки под FreeRTOS же рассказывать в самом деле)) А давайте дальше пойдем. Зачем сегодня в чем-то разбираться — можно ведь прийти в магазин и купить айфон с полки. Смотрите как удобно — ни эмулятор, ни jtag не нужен, ляпота!
Никого не хочу этим обидеть. Просто выражаю мысль о том, что есть разные темы, и не все они отдельно взятому человеку кажутся нужными и интересными. Но я такое просто игнорирую и не читаю в таком случае.
Ну вот как раз для написания приложений под айфон (а ещё пуще под Андроид) эмулятор явно нужен. Не собирать же весь зоопарк совместимых устройств и вариантов IOS?

Но вряд ли у кого из новичков будет задача написать приложение, работающее на всех кортексах. Тут, скорее наоборот — ищется SoC под задачу, потом под задачу делается плата.

Не про приложеньки под FreeRTOS же рассказывать в самом деле))
А почему бы не рассказать про приложеньки под Embox? Сколько труда нужно, чтобы поднять на ней сетевой стек на какой-нибудь K1879ВЯ1Я? А сколько — чтобы портировать её туда?

Вот человек про MBed рассказал. И код простой, и компилится прямо на сайте.

А про FreeRTOS рассказано уже очень много
А почему бы не рассказать про приложеньки под Embox? Сколько труда нужно, чтобы поднять на ней сетевой стек на какой-нибудь K1879ВЯ1Я? А сколько — чтобы портировать её туда?

Так в нашем блоге хватает статей. И про портирование в том числе тоже есть. А приложеньки? Ну так у нас это POSIX. Погодите, а зачем вам тогда перенос сетевого стека и порт на плату, это же другие люди должны делать. Вы же сами выше писали ровно это.

А про MBed — ну привел человек какое-то очередное API, что-то на нем написал. Какая-то онлайн-среда разработки. И что дальше? Зачем все это в реальных проектах? Вы же как раз про реальные проекты говорите. Я что буду что-то через сайт mbed.com программировать??.. Пффф. По-моему опять начали спорить о вкусах.

Погодите, а зачем вам тогда перенос сетевого стека и порт на плату, это же другие люди должны делать.

А это разница между «делать» и «планировать». Я должен понимать при выборе процессора и ОС, сколько труда уйдет у коллег на адаптацию. Особенно это важно когда речь об импортозамещении, то есть о мелкосерийных российских SoC. На тот же К1879ВЯ1Я даже FreeRTOS пришлось самим портировать. Ну и коллегам надо понимать, сколько у меня займет времени адаптация к API.

А про MBed — ну привел человек какое-то очередное API, что-то на нем написал.
MBed — это разработка компании ARM. То есть туда вложено не просто много денег, а очень много. Вот список поддерживаемых «из коробки» плат.

С одной стороны — это только COortex-M. Ни MIPS, ни ARM1176, ни даже Cortex-A. С другой стороны, если ограничится миром Cortex-M — похоже, что реально удобно.

Какая-то онлайн-среда разработки. И что дальше? Зачем все это в реальных проектах?
А все просто. Подключил плату — быстро опробовал работу устройств. Без установки тулкита, без мучений… Просто собрал на сайте и залил на вирутальную флэшку. А оно — заработало.

Ну как почти реальный пример.
У меня одна из медленных операций — это обращение матриц. Если SoC справляется за 1 миллисекунду — SoC годится. Если нет — то нет. Пожалуй что довольно дешевый способ — это купить готовую плату и залить туда тест, сделанный при помощи MBox. Это сильно дешевле, чем делать такой же проект на FreeRTOS + подъем синхронизации и питания своими руками.

То есть MBed вполне может взлететь. Ну пример как взлетела Windows, когда в неё вложили очень много денег. Если помните — конкуренты Windows 1.0 были получше неё.

А нормальный тулкит у MBed тоже есть. Куда уж без него.
НЛО прилетело и опубликовало эту надпись здесь
Да, это похожая штука для более больших армов, они на arm926ej-s запускают.
Запускали 8 лет назад.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий