Доброго времени суток коллеги.
Т.к. в наши ковидные времена появилось свободное время и надо чем то заниматься, написал библиотеку для работы с "железом" из java.
Все подробности доступны в "Проекты -> Открытые проекты ->
Java Embedded Framework (JEF) — AnnouncementАвтор: Infernal
Дата: 31.05.21
"
Если кому то будет полезно — велком.
Здравствуйте, Infernal, Вы писали:
I>Доброго времени суток коллеги.
I>Т.к. в наши ковидные времена появилось свободное время и надо чем то заниматься, написал библиотеку для работы с "железом" из java.
I>Все подробности доступны в "Проекты -> Открытые проекты -> Java Embedded Framework (JEF) — AnnouncementАвтор: Infernal
Дата: 31.05.21
"
I>Если кому то будет полезно — велком.
у кажой "железки" есть свой "протокол" —
их тоже надо реализовывать. у MS для dotnet они называются биндингами
https://github.com/dotnet/iot
https://github.com/dotnet/iot/blob/main/src/devices/README.md
Здравствуйте, Infernal, Вы писали:
I>Доброго времени суток коллеги.
I>Т.к. в наши ковидные времена появилось свободное время и надо чем то заниматься, написал библиотеку для работы с "железом" из java.
I>Все подробности доступны в "Проекты -> Открытые проекты -> Java Embedded Framework (JEF) — AnnouncementАвтор: Infernal
Дата: 31.05.21
"
I>Если кому то будет полезно — велком.
и кстати взаимодейстие с GPIO можно не только на самом "одноплатнике" исполнять но и на любом ПК с USB портом — raspberry pi zero как раз для этого по дизайну и задумывалась.
Здравствуйте, VladCore, Вы писали:
VC>у кажой "железки" есть свой "протокол" —
VC>их тоже надо реализовывать. у MS для dotnet они называются биндингами
VC>https://github.com/dotnet/iot
VC>https://github.com/dotnet/iot/blob/main/src/devices/README.md
Что значит "свой протокол"? У каждой железки(процессора) есть свои особенности работы на уровне регистров с SPI/I2C/GPIO/Serial и прочим.
Эти особенности реализуются на уровне драйверов от вендоров(или например портируются linux-sunxi.org для Allwinner) и становятся доступны, через /dev/spi* для SPI, через /dev/i2c* для I2C или /dev/gpiochip* для GPIO уже через API Posix/Linux с которыми уже единым образом и общается библиотека.
То, что имеется ввиду по ссылкам выше — это уже не протоколы, а набор команд по этим протоколам, для чтения из сенсоров, датчиков и прочего.
Для пары таких штук(которые были в наличии), я уже сделал обвязку на java —
https://github.com/java-embedded-framework/jef/tree/master/device-library/src/main/java/ru/iothub/jef/devices/library
Понятное дело, что придется портировать/делать с нуля обвязку для остального (или самому или народ поможет), чтобы оно было более "вкусным" для end users
Но за ссылки — спасибо. Можно прям оттуда брать и портировать
Добрый день!
Есть такой фреймворк
Quarkus, который может собираться в натив через GraalVM и содержит много всего.
Добавив свой код туда как расширение, можно получить сервисы, jdbc, Hibernate, работу с очередями, security и много всего другого оптимизированного под нативную работу.
Может кому будет полезно.
Здравствуйте, reson, Вы писали:
R>Добрый день!
R>Есть такой фреймворк Quarkus, который может собираться в натив через GraalVM и содержит много всего.
R>Добавив свой код туда как расширение, можно получить сервисы, jdbc, Hibernate, работу с очередями, security и много всего другого оптимизированного под нативную работу.
R>Может кому будет полезно.
Про Кваркус, знаем, помним. Они там целый слой написали для прикручивания компиляции в натив под граалем.
Я же просто через Graal API компилял в натив. По этому под ним оно должно из коробки завестись, как нить позже проверю.
Сейчас думаю в сторону генерализации SPI/I2C/Serial и написания библиотек чипов. Ибо с точки зрения end user это самое больное.
