Pull to refresh

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') => ...
Кто-то использует RustDT + Eclipse кроме меня, вау!
Для непривыкшего к файлово-конфиговой возне с vim/emacs, вроде меня, Eclipse на удивление хорошо и стабильно работает. Есть приколы с созданием exe-проекта, но в остальном, включая дебаг, вполне себе рулит.

а у вас дебаг в RustDT нормально работает? Я пробовал RustDT и сразу наткнулся на 2 бага:


  1. Если что-то поменять в программе и пытаться перекомпилить, то бывает выводится сообщение "Blocking waiting for file lock on build directory" — и компиляция не начинается
  2. если у нас есть:
    fn func(v:&i32) {
    println!("v={}", v);
    }

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


Что работает:
— Пошаговая отладка, в любом потоке
— Отображение содержимого переменных. Для enum приходится напрячь воображение, но в принципе читаемо
— Отладка ffi (если сишная библиотека собрана с дебагом)
Что не работает
— Автоматический выход из процедуры (нужно нажать F7 в конце процедуры, тогда выходит нормально)
— Отображение сложно вложенных структур и векторов (отображается только первый элемент)
— Отладка макросов (топчется несколько тактов и перескакивает)

Перекомпиляция и перезапуск дебага происходят без проблем.
Windows + Rust Nightly GNU.
ясно. Я под убунтой. Не знаю, что не так, но RustDT произвел крайне плохое впечатление: глючно до такой степени, что не подходит.
А исполняемые файлы на Rust на много жирнее получаются, по сравнению с C?
Удается ли воспользоваться какими-нибудь готовыми библиотеками, просто указав зависимость в Cargo.toml?
У меня это не сработало: https://habrahabr.ru/post/305246/#comment_10142540

Видимо, когда-то так можно было, но теперь это сломали.
В общем, сколько бы не говорили, что язык уже довольно рслый — но реально это штука пока еще сырая, хотя и выглядит перспективно.

Так ведь компилятор говорит чего ему не хватает. И в мануале в примере это есть.

Вы напрасно минусуете. Пример из мануала предполагает, что если его закопипастить и попытаться собрать — должно собраться.
В данном случае это не так. В мануале написано, что нужны эти функции, эти функции используют #[feature] — а это фича только ночных сборок.
Сейчас я «застрял» на попытке собрать с #[no_std] в стабильном варианте. Согласно документации, либу оно должно собирать и в стабильном варианте тоже.

Если оно не может так делать в стабильном варианте — для продакшена не подходит.
Пример из мануала предполагает, что если его закопипастить и попытаться собрать — должно собраться. В данном случае это не так.

Глава из секции "Nightly Rust", вполне логично что нужен ночной канал для использования того что там описано.


Сейчас я «застрял» на попытке собрать с #[no_std] в стабильном варианте.

Да, на стабильном канале этого сделать нельзя, возможность пока только для ночников. Когда-нибудь стабилизируют.


Если оно не может так делать в стабильном варианте — для продакшена не подходит.

Это может быть, хотя "продакшен" "продакшену" рознь — https://www.rust-lang.org/en-US/friends.html — многие из этих компаний пользуются именно ночными сборками.


С rustup вполне удобно зафиксировать какой-то ночник по дате и только когда сам захочешь — обновиться на более свежий ночник.

вот тут: https://doc.rust-lang.org/book/using-rust-without-the-standard-library.html

Пишут 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

Но в std и прочих частях останутся landing pads, в клиентском коде их, естественно не будет. Если хочется избавиться ещё и от них, то можно использовать xargo

Если писать код, не используя фреймворки, то по объему получается примерно также, как если программировать на С.
Например, если в примере из статьи убрать вызов usart2.print("..."), который использует collections::Vec, то вызов Rust-кода делает результат компиляции всего на сотню байт больше.
А вот если подключить векторы, то это увеличит размер бинарника на целых 14кБ. Если взять пример посложнее, который использует стандартную библиотеку «на полную», то там будет 50кБ+.
Но на мой взгляд, гораздо дешевле купить чип в котором будет больше памяти и при этом иметь возможность комфортно писать код. В том же STM32F103C8T6 64кБ flash памяти, чего обычно вполне хватает.
Использовать другие библиотеки не пробовал.
Only those users with full accounts are able to leave comments. Log in, please.