Comments 24
В будущем, при каждом обновлении компилятора (rustup update) нужно будет переключаться на актуальную версию исходников и перекомпилировать библиотеки для ARM, иначе потеряется возможность дебажить код на rust.
Попробуйте xargo, чтобы не перекомпилировать нужное руками.
Также в корне проекта необходимо создать файл конфигурации целевой платформы thumbv7m-none-eabi.json
Стараниями Jorge Aparicio (автора xargo, cross, svd2rust и кучи других полезных вещей, а также одного из самых активных движителей развития rust в embedded) теперь должно быть можно спокойно жить без ручного создания этого файла (тем более он имел свойство ломаться при изменениях версий llvm), т. к. оно есть в комплекте с компилятором.
Ещё рекомендую посмотреть на его же проект utest поддерживающий тестирование в qemu и под аппаратным отладчиком с использованием semihosting.
match u2_byte {
Some(v) => {
let c = v as char;
match c {
'r' => ...
'g' => ...
'b' => ...От преобразования u8 в char в этом коде можно избавиться, если использовать байтовые литералы b'r', b'g' и т.д. Например,
match u2_byte {
Some(v) => {
match v {
b'r' => ...
b'g' => ...
b'b' => ...или
match u2_byte {
Some(b'r') => ...
Some(b'g') => ...
Some(b'b') => ...
Для непривыкшего к файлово-конфиговой возне с vim/emacs, вроде меня, Eclipse на удивление хорошо и стабильно работает. Есть приколы с созданием exe-проекта, но в остальном, включая дебаг, вполне себе рулит.
а у вас дебаг в RustDT нормально работает? Я пробовал RustDT и сразу наткнулся на 2 бага:
- Если что-то поменять в программе и пытаться перекомпилить, то бывает выводится сообщение "Blocking waiting for file lock on build directory" — и компиляция не начинается
- если у нас есть:
fn func(v:&i32) { println!("v={}", v); }
мы поставили туда точку останова и стали на нее, то v в окошке переменных отображается как указатель — показывает адрес, а не значение по этому адресу. Посмотреть значение невозможно. Ну и плюс, переменная v дважды там показывается в списке. И, при выделении одной из строк — обе начинают перемигиваться.
— Пошаговая отладка, в любом потоке
— Отображение содержимого переменных. Для enum приходится напрячь воображение, но в принципе читаемо
— Отладка ffi (если сишная библиотека собрана с дебагом)
Что не работает
— Автоматический выход из процедуры (нужно нажать F7 в конце процедуры, тогда выходит нормально)
— Отображение сложно вложенных структур и векторов (отображается только первый элемент)
— Отладка макросов (топчется несколько тактов и перескакивает)
Перекомпиляция и перезапуск дебага происходят без проблем.
Windows + Rust Nightly GNU.
Удается ли воспользоваться какими-нибудь готовыми библиотеками, просто указав зависимость в Cargo.toml?
Видимо, когда-то так можно было, но теперь это сломали.
В общем, сколько бы не говорили, что язык уже довольно рслый — но реально это штука пока еще сырая, хотя и выглядит перспективно.
Так ведь компилятор говорит чего ему не хватает. И в мануале в примере это есть.
В данном случае это не так. В мануале написано, что нужны эти функции, эти функции используют #[feature] — а это фича только ночных сборок.
Сейчас я «застрял» на попытке собрать с #[no_std] в стабильном варианте. Согласно документации, либу оно должно собирать и в стабильном варианте тоже.
Если оно не может так делать в стабильном варианте — для продакшена не подходит.
Пример из мануала предполагает, что если его закопипастить и попытаться собрать — должно собраться. В данном случае это не так.
Глава из секции "Nightly Rust", вполне логично что нужен ночной канал для использования того что там описано.
Сейчас я «застрял» на попытке собрать с #[no_std] в стабильном варианте.
Да, на стабильном канале этого сделать нельзя, возможность пока только для ночников. Когда-нибудь стабилизируют.
Если оно не может так делать в стабильном варианте — для продакшена не подходит.
Это может быть, хотя "продакшен" "продакшену" рознь — https://www.rust-lang.org/en-US/friends.html — многие из этих компаний пользуются именно ночными сборками.
С rustup вполне удобно зафиксировать какой-то ночник по дате и только когда сам захочешь — обновиться на более свежий ночник.
Пишут Note, в котором заявляют, что stable должно уметь собирать либы без std. И это глава 5, а ночные сборки — это глава 6. Или я что-то неверно понял.
Так что должно. Но не собирает.
Или я что-то неверно понял.
Верно. Это я пропустил момент когда обсуждение перешло с этой ссылки на эту.
В общем, библиотеку без std можно собрать на стабильной ржавчине уже давно, исполняемый файл — нет.
Стабилизация последнего не особо приоритетна, как я понимаю, потому что не так-то проста и на практике обычно не так уж и важна (по сравнению со сборкой библиотек).
Пример из документации вываливает ошибки на все те же panic_fmt и eh_personality.
$ cat src/lib.rs
#![no_std]
pub fn plus_one(x: i32) -> i32 { x + 1 }
$ cat Cargo.toml
[package]
name = "nostr"
version = "0.1.0"
[lib]
# Если заменить rlib на staticlib или еще что - все печально :(
crate-type = ["rlib"]
$ c b
Compiling nostr v0.1.0 (file:///home/ozkriff/zoc/nostr)
Finished dev [unoptimized + debuginfo] target(s) in 0.10 secs
$ ls -lh target/debug/libnostr.rlib
-rw-rw-r-- 2 ozkriff ozkriff 6,5K мар 29 19:45 target/debug/libnostr.rlibЧерт, и правда. rlib собрать можно, но толку от rlib без std никакого нет, потому что кроме как с ржавчиной такую библиотеку не используешь.
А вот staticlib или cdylib, которые как раз притворились бы сишными библиотеками, хотят panic_fmt и eh_personality :-( .
http://stackoverflow.com/questions/43097676/how-to-build-a-standard-linux-so-library-with-stable-rust-without-using-std
Получается, если хочешь создать либу, которую надо линковать с сишным кодом — ты ограничен только ночными сборками. И, по всей видимости, все нормальные люди этим моментом особо не заморачиваются. Так же, документация документирует ночные сборки, и дифференциации по фичам не делает.
Ответили в итоге тут:
вроде, примерно то же что и я написал.
Получается, если хочешь создать либу, которую надо линковать с сишным кодом — ты ограничен только ночными сборками.
Если речь именно о "без std" то выходит так, да.
Так же, документация документирует ночные сборки, и дифференциации по фичам не делает.
Звучит как слишком мощная экстраполяция, так-то весь нестабильный функционал описывается в доках отдельно или с пометками. Просто конкретно этот момент с nostd такой хитрожопый вышел.
Зачем nostd тогда вообще стабилизировали я теперь не очень понимаю.
Если речь именно о «без std» то выходит так, да
Я тут путем эксперимента выяснил — оптимизатор выбрасывает std и core, если их не используешь де-факто (тип либ — cdylib). В том числе, при сборке в стабильной версии. Никакого #[no_std] писать вообще ненадо. При линковке такого .so ругается: undefined reference to `rust_begin_unwind', но это всего 1 ссылка, ее наверняка можно объявить в сишном коде, тем более что она вызываться не будет. Так что, на этот вопрос я пока просто забил.
Мне пока надо понять концептуально — готов ли руст для продакшена. Выглядит для меня он весьма привлекательно, как замена си. Но вот использовать нестабильное апи — как-то стремно.
Я тут путем эксперимента выяснил — оптимизатор выбрасывает std и core, если их не используешь де-факто (тип либ — cdylib).
Конечно, без этой оптимизации статическое связывание теряло бы всякий смысл.
Только надо учитывать, что какой-нибудь простой println косвенно использует значительную часть стандартной библиотеки.
При линковке такого .so ругается: undefined reference to `rust_begin_unwind', но это всего 1 ссылка, ее наверняка можно объявить в сишном коде, тем более что она вызываться не будет.
Можно в Cargo.toml прописать panic="abort", по идее это всю раскрутку (unwind) должно отключить: http://doc.crates.io/manifest.html#the-profile-sections
Например, если в примере из статьи убрать вызов usart2.print("..."), который использует collections::Vec, то вызов Rust-кода делает результат компиляции всего на сотню байт больше.
А вот если подключить векторы, то это увеличит размер бинарника на целых 14кБ. Если взять пример посложнее, который использует стандартную библиотеку «на полную», то там будет 50кБ+.
Но на мой взгляд, гораздо дешевле купить чип в котором будет больше памяти и при этом иметь возможность комфортно писать код. В том же STM32F103C8T6 64кБ flash памяти, чего обычно вполне хватает.
Использовать другие библиотеки не пробовал.
Rust, Eclipse и STM32