AS
типа они бы лучше сделали крейты и доки на них написали и назвали бы контрибьютора Tockos
Size: a a a
2017 November 08
AS
а так в это все влезать это ж пиздец
AS
лол, а юзеркод на сишнике)
AS
куча какоих-то жестких сишных оберток
AS
ну и вот эта история с системными вызовами прям странная
AS
там какой-то лютый и нихуя не типизированный API
AS
допустим есть проект blink (https://github.com/helena-project/tock/blob/master/userland/examples/blink/main.c)
мигает светоидодом. Для этого есть функции led_on/led_off (зачем надо было отедьные делть для светодиодов, хз)
окей, лезем в libtock, находим [https://github.com/helena-project/tock/blob/master/userland/libtock/led.c], там дергается command с параметром DRIVER_NUM_LEDS — то есть они блин на уровне ядра это добавили…
А что такое DRIVER_NUM_LEDS? Пфф, ну очевидно, это же
потом мы идем в [https://github.com/helena-project/tock/blob/master/capsules/src/led.rs] и видим там
мигает светоидодом. Для этого есть функции led_on/led_off (зачем надо было отедьные делть для светодиодов, хз)
окей, лезем в libtock, находим [https://github.com/helena-project/tock/blob/master/userland/libtock/led.c], там дергается command с параметром DRIVER_NUM_LEDS — то есть они блин на уровне ядра это добавили…
А что такое DRIVER_NUM_LEDS? Пфф, ну очевидно, это же
#define DRIVER_NUM_LEDS 0x00000002!потом мы идем в [https://github.com/helena-project/tock/blob/master/capsules/src/led.rs] и видим там
pub const DRIVER_NUM: usize = 0x00000002;AS
динамично дохуя
AS
и еще немного Japaric
AS
1. надо позырить на https://github.com/japaric/utest
2. есть вот такая интересная штука https://github.com/japaric/embedded-hal, у меня была тоже идея все аппаратные типажи собрать в одном месте. Чувак подзабросил этот проект, но там прям напрашивается понапихать в него кучу всего типа того же АЦП.
В ту же тему https://docs.rs/bare-metal/0.1.1/bare_metal/ — тут абстракции какого-то другого уровня, ну и тоже явно недописанные.
3. svd2rust делает просто обертку над регистрами, а все вызовы чо там сконфигурить надо, ты сам пишешь. Я посмотрел, например, репозиторий для stm32f103, там куча регистров и дальше ты как в старые добрые пишешь на уровне регистров. НЕ ОЧЕНЬ
2. есть вот такая интересная штука https://github.com/japaric/embedded-hal, у меня была тоже идея все аппаратные типажи собрать в одном месте. Чувак подзабросил этот проект, но там прям напрашивается понапихать в него кучу всего типа того же АЦП.
В ту же тему https://docs.rs/bare-metal/0.1.1/bare_metal/ — тут абстракции какого-то другого уровня, ну и тоже явно недописанные.
3. svd2rust делает просто обертку над регистрами, а все вызовы чо там сконфигурить надо, ты сам пишешь. Я посмотрел, например, репозиторий для stm32f103, там куча регистров и дальше ты как в старые добрые пишешь на уровне регистров. НЕ ОЧЕНЬ
AS
ну да, и нормальная поддержка stm32f103 есть, например, в репозитории blue-pill
AS
я перечитал твои сообщения, когда ты писал мне про japaric, ну в целом да:
* utest надо поизучать
* надо попробовать bindgen
* rtfm я пока не могу найти нормального руководства,
* embedded-hal/bare_metal мне кажется правильной идея контрибьютить аппаратные типажи
* svd2rust сыровато, если только ты не из прошлого века и не хочешь работать с регистрами
* utest надо поизучать
* надо попробовать bindgen
* rtfm я пока не могу найти нормального руководства,
* embedded-hal/bare_metal мне кажется правильной идея контрибьютить аппаратные типажи
* svd2rust сыровато, если только ты не из прошлого века и не хочешь работать с регистрами
AS
вообще я, конечно, в тулу со своим самоваром, тут Japaric'а обсуждали не один раз
AS
надо какую-нибудь страницу в интернете накатать типа «состояние embedded rust на текущий момент», чтобы каждый не тыкался во все эти репозитории
MC
Вообще есть areweembeddedyet.com но там унылая заглушка.
AS
и в списке репозиториев нет самого жира типа rtfm и svd2rust
BD
надо просто сделать на гитхабе репу curated list по типу awesome-cpp только embedded-rust
AS
норм идея
MC
Ну надо тогда со словом awesome