From ad9218f03cd4308dbbb431056500f5fd294e9ebd Mon Sep 17 00:00:00 2001 From: Juan Antonio Brena Moral Date: Sun, 4 Nov 2018 14:39:57 +0100 Subject: [PATCH 01/13] Adding initial ADR Support --- docs/adr/README.md | 8 ++++++++ docs/adr/adr-lejos-support.md | 21 +++++++++++++++++++ docs/adr/adr-logging-support.md | 27 +++++++++++++++++++++++++ src/main/resources/META-INF/MANIFEST.MF | 1 + 4 files changed, 57 insertions(+) create mode 100644 docs/adr/README.md create mode 100644 docs/adr/adr-lejos-support.md create mode 100644 docs/adr/adr-logging-support.md diff --git a/docs/adr/README.md b/docs/adr/README.md new file mode 100644 index 00000000..5490a41c --- /dev/null +++ b/docs/adr/README.md @@ -0,0 +1,8 @@ +# Architecture decision record (ADR) + +This folder contains some topics that they motivated some decisions +in this project. + +## References: + +https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records \ No newline at end of file diff --git a/docs/adr/adr-lejos-support.md b/docs/adr/adr-lejos-support.md new file mode 100644 index 00000000..057efbd7 --- /dev/null +++ b/docs/adr/adr-lejos-support.md @@ -0,0 +1,21 @@ +# Implement LeJOS API on top of EV3Dev (Nov 2015) + +EV3 Brick is the first Lego Mindstorms Brick with capacity to Linux. + +LeJOS team designed a solution on top of Busybox a non complete Linux solution. +this architecture don't have USB support to connect devices like a LIDAR or an Arduino Board. + +With the time, the number of developers decreased and the project launched few releases. + +In 2015 appeared a project named EV3Dev, a OSS project designed to provide a +Debian distribution for EV3 and RaspberryPi boards like BrickPi or PiStorms. +The project included an interface to operate with EV3 sensors/actuators and I2C devices. + +The main reasons to implement LeJOS Interfaces on top of EV3Dev were: + +- Lack of LeJOS releases. Last release was launched on November of 2015 +- Lack of a complete Linux distro support +- Lack of USB support +- Lack of support for modern JVM + +That reasons motivated the creation of this project. diff --git a/docs/adr/adr-logging-support.md b/docs/adr/adr-logging-support.md new file mode 100644 index 00000000..164addec --- /dev/null +++ b/docs/adr/adr-logging-support.md @@ -0,0 +1,27 @@ +# Logging Support + +The library move away from the idea to use `System.out.println("Your message")` +because it is a bad practice. You can search on the network many articles about +this fact. + +The library follow some Best practices in the software industry and use +the dependency SLF4J (Simple Logging Facade for Java). + +The Simple Logging Facade for Java (SLF4J) serves as +a simple facade or abstraction for various logging frameworks +(e.g. java.util.logging, logback, log4j) allowing +the end user to plug in the desired logging framework at deployment time. + +The library uses SLF4J in the whole project and later the user has to +choose the final implementation. In the example, the development use +Logback but any user could use any logging framework. + +For testing purposes, enable traces is a good practice but for +production projects try to disable some levels. +Generate many traces in your logs impact in your performance. + +## Links + +https://javarevisited.blogspot.com/2016/06/why-use-log4j-logging-vs.html +https://www.slf4j.org/ +https://logback.qos.ch/ \ No newline at end of file diff --git a/src/main/resources/META-INF/MANIFEST.MF b/src/main/resources/META-INF/MANIFEST.MF index 3cddcb5c..41c72f84 100644 --- a/src/main/resources/META-INF/MANIFEST.MF +++ b/src/main/resources/META-INF/MANIFEST.MF @@ -2,3 +2,4 @@ Manifest-Version: 1.0 Implementation-Title: EV3Dev-lang-java Implementation-Version: 2.1.0-SNAPSHOT Implementation-Vendor: Juan Antonio Breña Moral +Main-Class: examples.sensors.mindsensors.CreatePhotoDemo From f8256f1575e025a8d28f92f61fe0b5e26ed39c7a Mon Sep 17 00:00:00 2001 From: Juan Antonio Brena Moral Date: Sun, 4 Nov 2018 14:43:05 +0100 Subject: [PATCH 02/13] Minor change in MANIFEST.MF --- src/main/resources/META-INF/MANIFEST.MF | 1 - 1 file changed, 1 deletion(-) diff --git a/src/main/resources/META-INF/MANIFEST.MF b/src/main/resources/META-INF/MANIFEST.MF index 41c72f84..3cddcb5c 100644 --- a/src/main/resources/META-INF/MANIFEST.MF +++ b/src/main/resources/META-INF/MANIFEST.MF @@ -2,4 +2,3 @@ Manifest-Version: 1.0 Implementation-Title: EV3Dev-lang-java Implementation-Version: 2.1.0-SNAPSHOT Implementation-Vendor: Juan Antonio Breña Moral -Main-Class: examples.sensors.mindsensors.CreatePhotoDemo From 5dfe39a17d08873d9d825a6742a8fe055c22d6da Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= Date: Sun, 4 Nov 2018 15:50:51 +0100 Subject: [PATCH 03/13] Add info about LEGO OS to LeJOS ADR --- docs/adr/adr-lejos-support.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/adr/adr-lejos-support.md b/docs/adr/adr-lejos-support.md index 057efbd7..bd315901 100644 --- a/docs/adr/adr-lejos-support.md +++ b/docs/adr/adr-lejos-support.md @@ -1,14 +1,16 @@ # Implement LeJOS API on top of EV3Dev (Nov 2015) -EV3 Brick is the first Lego Mindstorms Brick with capacity to Linux. +EV3 Brick is the first Lego Mindstorms Brick powerful enough to run Linux. -LeJOS team designed a solution on top of Busybox a non complete Linux solution. -this architecture don't have USB support to connect devices like a LIDAR or an Arduino Board. +LeJOS team designed a solution on top of a LEGO-provided Linux rootfs & +Linux kernel with modules also provided by LEGO, although enhanced by leJOS hackers. +This architecture doesn't have proper USB support to connect devices like a LIDAR or an Arduino Board. +Also, LEGO didn't provide any package manager, so the core system is effectively stuck in time. With the time, the number of developers decreased and the project launched few releases. -In 2015 appeared a project named EV3Dev, a OSS project designed to provide a -Debian distribution for EV3 and RaspberryPi boards like BrickPi or PiStorms. +In 2015 appeared a project named EV3Dev, a OSS project designed to provide a +Debian distribution for EV3 and RaspberryPi boards like BrickPi or PiStorms. The project included an interface to operate with EV3 sensors/actuators and I2C devices. The main reasons to implement LeJOS Interfaces on top of EV3Dev were: @@ -16,6 +18,6 @@ The main reasons to implement LeJOS Interfaces on top of EV3Dev were: - Lack of LeJOS releases. Last release was launched on November of 2015 - Lack of a complete Linux distro support - Lack of USB support -- Lack of support for modern JVM +- Lack of support for modern JVM That reasons motivated the creation of this project. From 76201053f41651f4ac290567f3d20a2170260b06 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= Date: Sun, 4 Nov 2018 15:51:30 +0100 Subject: [PATCH 04/13] Add better explanation to Logging ADR --- docs/adr/adr-logging-support.md | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/docs/adr/adr-logging-support.md b/docs/adr/adr-logging-support.md index 164addec..389237ac 100644 --- a/docs/adr/adr-logging-support.md +++ b/docs/adr/adr-logging-support.md @@ -1,27 +1,32 @@ # Logging Support The library move away from the idea to use `System.out.println("Your message")` -because it is a bad practice. You can search on the network many articles about -this fact. +because using `stdout` is not the same as using `stderr` or a logging interface. + +The reason you shouldn't use `System.out` is that we depend on output redirection +provided by ev3dev's brickrun. `stderr` is redirected via SSH to the user +when running remotely. If you use `System.out`, the message will be +displayed on the brick display only. On the other hand, this might +be intentional, in which case you should use `System.out`. The library follow some Best practices in the software industry and use the dependency SLF4J (Simple Logging Facade for Java). -The Simple Logging Facade for Java (SLF4J) serves as -a simple facade or abstraction for various logging frameworks -(e.g. java.util.logging, logback, log4j) allowing -the end user to plug in the desired logging framework at deployment time. +The Simple Logging Facade for Java (SLF4J) serves as +a simple facade or abstraction for various logging frameworks +(e.g. java.util.logging, logback, log4j) allowing +the end user to plug in the desired logging framework at deployment time. The library uses SLF4J in the whole project and later the user has to -choose the final implementation. In the example, the development use +choose the final implementation. In the example, the development use Logback but any user could use any logging framework. -For testing purposes, enable traces is a good practice but for -production projects try to disable some levels. +For testing purposes, enable traces is a good practice but for +production projects try to disable some levels. Generate many traces in your logs impact in your performance. ## Links https://javarevisited.blogspot.com/2016/06/why-use-log4j-logging-vs.html https://www.slf4j.org/ -https://logback.qos.ch/ \ No newline at end of file +https://logback.qos.ch/ From f237a5afd51f0894f77d73d33a4d28aeb19d59d6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= Date: Sun, 4 Nov 2018 16:12:39 +0100 Subject: [PATCH 05/13] Add Display ADR --- docs/adr/adr-display-api.md | 107 ++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 docs/adr/adr-display-api.md diff --git a/docs/adr/adr-display-api.md b/docs/adr/adr-display-api.md new file mode 100644 index 00000000..ccd149b4 --- /dev/null +++ b/docs/adr/adr-display-api.md @@ -0,0 +1,107 @@ +# ev3dev Display API + +## Reason + +In Linux 4.14 for EV3, there was a change in the LCD framebuffer code +which required a redesign of our display architecture. The change was +that kernel no longer accepted 1bpp black-and-white bitmap. Now a +32bpp XRGB bitmap was required. To allow for simultaneous support of +these two formats and also to address a few other issues, a new +display API was designed. + +## API Design + +The code has roughly these interfaces: +* leJOS LCD emulation in `LCD` - This reimplements some parts of leJOS + `GraphicsLCD` API on top of Java2D Graphics2D. The `BufferedImage` is + obtained from and the refresh is forwarded to `JavaFramebuffer`. + The `JavaFramebuffer` itself is obtained from `SystemDisplay`. +* Glue in `SystemDisplay` - This provides a factory for a system + display manager - either a native one or a remote one, and + a JavaFramebuffer above the display manager. +* `JavaFramebuffer` interface - This interface abstracts away + a framebuffer. The interface provides: + * basic information about the display geometry, + * methods for creating offscreen `BufferedImage` for drawing, + * writing full-size offscreen buffers to the display, + * clearing the display, + * saving and restoring a single snapshot, + * getter for the underlying `DisplayInterface` +* `DisplayInterface` interface - This class manages the underlying + display output. It provides: + * switching between text mode (Linux console is displayed) and + graphics mode (user graphics is displayed), + * framebuffer creation - this class creates the appropriate + `JavaFramebuffer` implementation for the system display. + * framebuffer lifetime management - this class stores the opened framebuffer. +* `FramebufferProvider` interface with `AllImplFailedException` - + These classes provide Java SPI for framebuffer formats. + The `DisplayInterface` uses this SPI to instantiate the correct + `JavaFramebuffer` implementation for the system framebuffer. + +Then, we have the following implementations: +* `ImageUtils` class - This class implements BufferedImage creation + for 32bpp XRGB and 1bpp BW framebuffers. +* `LinuxFramebuffer` class - This class implements `JavaFramebuffer` + for native Linux framebuffer device. +* `BitFramebuffer`, `RGBFramebuffer` - These classes specialize + `LinuxFramebuffer` for 1bpp BW and 32bpp XRGB formats. +* `BitFramebufferProvider`, `RGBFramebufferProvider` - These classes wrap + `BitFramebuffer` and `RGBFramebuffer` for usage in `FramebufferProvider`. +* `OwnedDisplay` class - This class implements `DisplayInterface` + for standard Linux console. The Java process must have access to + the system console. +* `StolenDisplay` class - This class implements `DisplayInterface` when + the standard Linux console is unavailable. It ignores text/graphics mode + switching. However it disables brickman process when instantiated. + +Under all of this is an extension of leJOS Native* APIs: +* `NativeFile` class - this class wraps ILibc file system calls. +* `NativeDevice` class - this class wraps ILibc system calls + for Linux devices. +* `NativeFramebuffer` class - this class wraps ILibc system calls + for Linux framebuffer devices. +* `NativeTTY` class - this class wraps ILibc system calls + for Linux console devices. +* `NativeConstants` class - contains basic C macros, like errno values and + ioctl arguments. +* `ILibc` interface - abstraction of basic system calls. + This is useful for testing the interface code. +* `NativeLibc` interface - class which is used for JNA binding to system libc. + +`ILibc` interface had been mocked for purposes of unit testing: +* `EmulatedLibc` - class which provides a virtual file system to which + fake files and devices can be mounted. +* `IFile` - interface for fake files, +* `ICounter` - interface for event counters, +* `CountingFile` - this class wraps another IFile and provides + counting of system call invocations, +* `EmulatedFramebuffer` - this class provides a mocked version of system + framebuffer device. +* `EmulatedFramebufferBuilder` - this class helps with `EmulatedFramebuffer` + construction. + +This design makes it possible to implement new framebuffer formats +(through subclassing JavaFramebuffer and FramebufferProvider) and +new output devices (through subclassing DisplayInterface and modifying +SystemDisplay). It also allows for unit testing the interfacing code +through abstracted system call interface. + +For example, it should be possible to relatively easily implement a Swing-backed +display output. This feature might actually be implemented in a future +version of the display code. + +## Running programs + +There is also a change in how the programs have to be launched. Until now, +simply running the JAR on the console was sufficient. However this wasn't +compliant with how ev3dev handles console (the old method is still possible +through current StolenDisplay). + +For this reason, we introduced the recommended usage of `brickrun` +to our project too. This program allocates a virtual terminal +for the application and suspends Brickman. Then, it launches there +the application it was given in its arguments. + +When you run the application from Brickman menu, using brickrun is not +necessary, because Brickman automatically suspends itself. From cd0b0663a3249d4e2c4c45fe8adb53340beba273 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= Date: Sun, 4 Nov 2018 16:23:00 +0100 Subject: [PATCH 06/13] Add file links to the ADR readme --- docs/adr/README.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/adr/README.md b/docs/adr/README.md index 5490a41c..7202c7d9 100644 --- a/docs/adr/README.md +++ b/docs/adr/README.md @@ -3,6 +3,11 @@ This folder contains some topics that they motivated some decisions in this project. -## References: +* [Why this project was started](adr-lejos-support.md) +* [Logging support](adr-logging-support.md) +* [New Display API](adr-display-api.md) +* [Changes to leJOS sensor API](adr-lejos-sensor.md) -https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records \ No newline at end of file +## References: + +https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records From 5f33f2e7a563a3bcfe80a2672b029f26c8917062 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= Date: Sun, 4 Nov 2018 16:43:13 +0100 Subject: [PATCH 07/13] Add LeJOS Sensor ADR --- docs/adr/adr-lejos-sensor.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 docs/adr/adr-lejos-sensor.md diff --git a/docs/adr/adr-lejos-sensor.md b/docs/adr/adr-lejos-sensor.md new file mode 100644 index 00000000..f9801d22 --- /dev/null +++ b/docs/adr/adr-lejos-sensor.md @@ -0,0 +1,29 @@ +# leJOS Sensor API changes + +In this project, we reimplemented most of the leJOS sensor API. +However, there are some incompatibilities and changes to enhance +performance and decrease the complexity of the sensor code +that break previously established promises: + +* Using multiple `SensorMode`s in parallel doesn't work anymore. + This is because for now, we have removed the kernel mode switching + from `fetchSample()` of sensor modes. Instead, the mode switch + is performed in the associated `get*Mode()` functions. This means + that once you call one `get*Mode()` function, you cannot use + `SensorMode`s from the other ones. This also means that once you + reset the `EV3GyroSensor`, you have to call `get*Mode()` once more. + + In the future, if we find a way how to do this efficiently and + without making it omplex, we might add support for this + feature again. However, we might also keep it the way it is now, + as this establishes a different promise - `fetchSample` only fetches + data, and it doesn't touch the sensor mode. + +* Most of the `BaseSensor` functions dealing with sensor modes + are effectively broken now. This is caused by the previous point - + sensor mode is not switched when using these functions. + +* Waiting for multiple values does not work. We do not know how to + wait for a new value in ev3dev. This means that IR sensor function + reading multiple commands will read only one, otherwise it will + throw an exception. From f57a5a3fa87ed01fd19f042e041467deb1c88cba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= Date: Sun, 4 Nov 2018 17:05:34 +0100 Subject: [PATCH 08/13] Extend/reword LeJOS and Logging ADRs --- docs/adr/adr-lejos-support.md | 19 +++++++++++-------- docs/adr/adr-logging-support.md | 18 +++++++++--------- 2 files changed, 20 insertions(+), 17 deletions(-) diff --git a/docs/adr/adr-lejos-support.md b/docs/adr/adr-lejos-support.md index bd315901..1efc28a4 100644 --- a/docs/adr/adr-lejos-support.md +++ b/docs/adr/adr-lejos-support.md @@ -1,22 +1,25 @@ # Implement LeJOS API on top of EV3Dev (Nov 2015) -EV3 Brick is the first Lego Mindstorms Brick powerful enough to run Linux. +EV3 Brick is the first Lego Mindstorms Brick to run a Linux-based operating system. -LeJOS team designed a solution on top of a LEGO-provided Linux rootfs & +LeJOS team designed a solution on top of a LEGO-provided Linux userspace & Linux kernel with modules also provided by LEGO, although enhanced by leJOS hackers. -This architecture doesn't have proper USB support to connect devices like a LIDAR or an Arduino Board. +This architecture doesn't have proper USB support, so devices like USB LIDAR or an Arduino Board do not work. Also, LEGO didn't provide any package manager, so the core system is effectively stuck in time. -With the time, the number of developers decreased and the project launched few releases. +As the time passed, the number of developers decreased and the project development slowed down. -In 2015 appeared a project named EV3Dev, a OSS project designed to provide a +In 2015 a project named EV3Dev was launched, am OSS project designed to provide a Debian distribution for EV3 and RaspberryPi boards like BrickPi or PiStorms. -The project included an interface to operate with EV3 sensors/actuators and I2C devices. +The project doesn't use the userspace nor the kernel modules from LEGO. +Rather, the sensor and actuator interfaces were reimplemented to provide +a better and easier-to-understand interface. This includes EV3 sensors +and also various other sensors. The main reasons to implement LeJOS Interfaces on top of EV3Dev were: -- Lack of LeJOS releases. Last release was launched on November of 2015 -- Lack of a complete Linux distro support +- Lack of LeJOS releases. Last release was launched in November of 2015 +- Lack of a complete Linux distro support, - Lack of USB support - Lack of support for modern JVM diff --git a/docs/adr/adr-logging-support.md b/docs/adr/adr-logging-support.md index 389237ac..59ba5ec7 100644 --- a/docs/adr/adr-logging-support.md +++ b/docs/adr/adr-logging-support.md @@ -1,6 +1,6 @@ # Logging Support -The library move away from the idea to use `System.out.println("Your message")` +We recommend to move away from using `System.out.println("Your message")` because using `stdout` is not the same as using `stderr` or a logging interface. The reason you shouldn't use `System.out` is that we depend on output redirection @@ -9,21 +9,21 @@ when running remotely. If you use `System.out`, the message will be displayed on the brick display only. On the other hand, this might be intentional, in which case you should use `System.out`. -The library follow some Best practices in the software industry and use -the dependency SLF4J (Simple Logging Facade for Java). +Also, to align with the best practises in the software industry, we +integrated support for SLF4J (Simple Logging Facade for Java). The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at deployment time. -The library uses SLF4J in the whole project and later the user has to -choose the final implementation. In the example, the development use -Logback but any user could use any logging framework. +The library uses SLF4J in the whole project, but the user has to +choose the final implementation. In the example, the development uses +Logback but users can choose any other compatible logging framework. -For testing purposes, enable traces is a good practice but for -production projects try to disable some levels. -Generate many traces in your logs impact in your performance. +For testing purposes, enabling traces is a good practice, but for +production builds you might want to disable some levels. +Generating too many tracing output creates a measurable impact on the program performance. ## Links From 0db10e2177a168f7db4a38eeca5e4b331af5281a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= Date: Sun, 4 Nov 2018 17:36:56 +0100 Subject: [PATCH 09/13] Add OpenJDK ADR --- docs/adr/README.md | 1 + docs/adr/adr-openjdk-builds.md | 47 ++++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+) create mode 100644 docs/adr/adr-openjdk-builds.md diff --git a/docs/adr/README.md b/docs/adr/README.md index 7202c7d9..83ab983f 100644 --- a/docs/adr/README.md +++ b/docs/adr/README.md @@ -7,6 +7,7 @@ in this project. * [Logging support](adr-logging-support.md) * [New Display API](adr-display-api.md) * [Changes to leJOS sensor API](adr-lejos-sensor.md) +* [Support for newer Java versions](adr-openjdk-builds.md) ## References: diff --git a/docs/adr/adr-openjdk-builds.md b/docs/adr/adr-openjdk-builds.md new file mode 100644 index 00000000..d6315768 --- /dev/null +++ b/docs/adr/adr-openjdk-builds.md @@ -0,0 +1,47 @@ +# Support for newer Java versions + +In December 2017, we noticed that Oracle had released their HotSpot port +for ARM32. Until that moment, there were only a few options of JVMs +which would run on the EV3: +* Debian-provided Zero build, which is a lot slower than HotSpot JIT. +* Oracle-provided EJDK7 build, which was used in leJOS. +* Oracle-provided EJDK8 build, which was used in leJOS as well. +* Some alternative JVMs, but we haven't finished investigating these options. + +The problem with EJDK8 from Oracle was that it was the last supported +Java release for EV3. At that time, Java 9 was already available and +Java 10 was coming as well. + +So, now that we knew OpenJDK 9 had the necessary bits from EJDK8, we +tried to create a build of OpenJDK for EV3. This resulted in creation +of [ev3dev-lang-java/openjdk-ev3][1] repository. +Over time, we adopted Docker for the builds. The next big thing was +that after some communication, [AdoptOpenJDK][2] Group +allowed us to use their [CI infrastructure][2] to do our builds. From that time, +instead of doing the releases on developer's computers, they are performed +on their Linux Jenkins slaves. + +To make OpenJDK work on EV3, we maintain a set of patches on top of +OpenJDK tree. They do these things: +* ARMv5 support - there are some memory barriers that work only on ARMv6+. They are disabled on ARMv5 now. +* Additional optimizations - GCC flags `-mcpu` is used to compile for the CPU in EV3. +* SoftFloat support - previously, a SoftFloat-2 library was injected into `arm-sflt` builds + to provide floating point emulation with higher precision for some code paths. This patch + adds support for a modified version of SoftFloat-3e to be used. +* Debian library path - this patch adds support for Debian-style `/usr/lib/jni` path and others. + +Also, with the new features in Java 9 and onwards, we changed Java packaging: +* JRI - Java Runtime Image - provides very small runtime environment suitable for ev3dev. +* JDK - Java Development Kit - provides full Java JDK build for EV3. +* JMODs - Java MODules - with these a curious user can build larger + subsets of full Java than our JRI is. + +There is a small problem with using Java HotSpot, though. ARMv5/softfp +is no longer a supported configuration. We depend on that Java developers +do not break or remove the support for this platform in future releases. +If such a thing happens, we will have to either use the Zero JVM, or to +use an alternative JVM altogether. + +[1]: https://github.com/ev3dev-lang-java/openjdk-ev3 +[2]: https://adoptopenjdk.net/ +[3]: https://ci.adoptopenjdk.net/ From 09e4faeda0df07aaf9b5da7138c5df4addd6b935 Mon Sep 17 00:00:00 2001 From: Juan Antonio Brena Moral Date: Mon, 5 Nov 2018 20:41:17 +0100 Subject: [PATCH 10/13] Adding the adr section about modular design --- docs/adr/adr-modular.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 docs/adr/adr-modular.md diff --git a/docs/adr/adr-modular.md b/docs/adr/adr-modular.md new file mode 100644 index 00000000..d0e3560c --- /dev/null +++ b/docs/adr/adr-modular.md @@ -0,0 +1,31 @@ +# Modular design + +The project has been designed like a set of libraries stackables +to offer different solutions for different use cases with the Brick. + +## Libraries + +**Core** + +The main library offers a Integration solution with EV3Dev. +Using this library, it is possible to interact with +Sensors & Actuators from Lego Mindstorms & third party manufacturers +like MindSensors or Dexter Industries. + +This library depends of `lejos-commons` & `jna` + +**LeJOS // Commons** + +`lejos-commons` manage a set of Interfaces in order to maintain the +same way to develop than LeJOS but in this case using the `EV3Dev` runtime. + + +**LeJOS // Navigation** + +`lejos-navigation` is a library to use the local navigation stack from LeJOS. + +**USB-devices** + +This library has been designed to manage different usb devices like +Arduino boards, LIDARs, IMUs, Microphones, GPS + From 22f637f094f9e5f364042cc318e2cd3445aefaba Mon Sep 17 00:00:00 2001 From: Juan Antonio Brena Moral Date: Mon, 5 Nov 2018 20:48:47 +0100 Subject: [PATCH 11/13] Adding dates in the different ADR documents --- docs/adr/adr-display-api.md | 2 +- docs/adr/adr-lejos-sensor.md | 2 +- docs/adr/adr-logging-support.md | 2 +- docs/adr/adr-modular.md | 2 +- docs/adr/adr-openjdk-builds.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/adr/adr-display-api.md b/docs/adr/adr-display-api.md index ccd149b4..8b042bb1 100644 --- a/docs/adr/adr-display-api.md +++ b/docs/adr/adr-display-api.md @@ -1,4 +1,4 @@ -# ev3dev Display API +# ev3dev Display API (October 2018) ## Reason diff --git a/docs/adr/adr-lejos-sensor.md b/docs/adr/adr-lejos-sensor.md index f9801d22..7a36d70b 100644 --- a/docs/adr/adr-lejos-sensor.md +++ b/docs/adr/adr-lejos-sensor.md @@ -1,4 +1,4 @@ -# leJOS Sensor API changes +# leJOS Sensor API changes (Nov 2015) In this project, we reimplemented most of the leJOS sensor API. However, there are some incompatibilities and changes to enhance diff --git a/docs/adr/adr-logging-support.md b/docs/adr/adr-logging-support.md index 59ba5ec7..fde5204b 100644 --- a/docs/adr/adr-logging-support.md +++ b/docs/adr/adr-logging-support.md @@ -1,4 +1,4 @@ -# Logging Support +# Logging Support (Nov 2015) We recommend to move away from using `System.out.println("Your message")` because using `stdout` is not the same as using `stderr` or a logging interface. diff --git a/docs/adr/adr-modular.md b/docs/adr/adr-modular.md index d0e3560c..be96442a 100644 --- a/docs/adr/adr-modular.md +++ b/docs/adr/adr-modular.md @@ -1,4 +1,4 @@ -# Modular design +# Modular design (Nov 2015) The project has been designed like a set of libraries stackables to offer different solutions for different use cases with the Brick. diff --git a/docs/adr/adr-openjdk-builds.md b/docs/adr/adr-openjdk-builds.md index d6315768..fdcb1ad3 100644 --- a/docs/adr/adr-openjdk-builds.md +++ b/docs/adr/adr-openjdk-builds.md @@ -1,4 +1,4 @@ -# Support for newer Java versions +# Support for newer Java versions (April 2018) In December 2017, we noticed that Oracle had released their HotSpot port for ARM32. Until that moment, there were only a few options of JVMs From 352928cf7ba9f8fd8bb4efe70fb20f36d02fb773 Mon Sep 17 00:00:00 2001 From: Juan Antonio Brena Moral Date: Mon, 5 Nov 2018 21:00:06 +0100 Subject: [PATCH 12/13] Adding new functions --- gradle/deploy.gradle | 71 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 69 insertions(+), 2 deletions(-) diff --git a/gradle/deploy.gradle b/gradle/deploy.gradle index 63ade9f5..dcd1841e 100644 --- a/gradle/deploy.gradle +++ b/gradle/deploy.gradle @@ -13,6 +13,50 @@ task testConnection { } } +task free { + doLast { + ssh.run { + session(remotes.ev3dev) { + println "free " + execute "free " + } + } + } +} + +task top { + doLast { + ssh.run { + session(remotes.ev3dev) { + println "top " + execute "top " + } + } + } +} + +task ps { + doLast { + ssh.run { + session(remotes.ev3dev) { + println "ps " + execute "ps aux | sort -n -k 4 " + } + } + } +} + +task stopBluetooth { + doLast { + ssh.run { + session(remotes.ev3dev) { + println "echo -e \"maker\" | sudo systemctl stop bluetooth" + execute "echo -e \"maker\" | sudo systemctl stop bluetooth" + } + } + } +} + task ev3devInfo { doLast { ssh.run { @@ -94,8 +138,8 @@ task remoteSudoRun { doLast { ssh.run { session(remotes.ev3dev) { - println "echo -e \"maker\" | sudo -S brickrun -- java -jar /home/robot/" + "${rootProject.name}" + "-" + version + "-all" + ".jar" - execute "echo -e \"maker\" | sudo -S brickrun -- java -jar /home/robot/" + "${rootProject.name}" + "-" + version + "-all" + ".jar" + println "echo -e \"maker\" | sudo -S java -jar /home/robot/" + "${rootProject.name}" + "-" + version + "-all" + ".jar" + execute "echo -e \"maker\" | sudo -S java -jar /home/robot/" + "${rootProject.name}" + "-" + version + "-all" + ".jar" } } } @@ -123,6 +167,15 @@ task remoteProfilingSudoRun { } } +task remoteNativeRun << { + ssh.run { + session(remotes.ev3dev) { + println "time java -verbose:class -verbose:jni -Djava.library.path=/usr/lib/jni/ -cp /home/robot/" + "${rootProject.name}" + "-" + version + "-all.jar:/usr/share/OpenCV/java/opencv-249.jar examples.opencv.HelloWorldCV" + execute "time java -verbose:class -verbose:jni -Djava.library.path=/usr/lib/jni/ -cp /home/robot/" + "${rootProject.name}" + "-" + version + "-all.jar:/usr/share/OpenCV/java/opencv-249.jar examples.opencv.HelloWorldCV" + } + } +} + task deployAndRun { doLast { } @@ -154,11 +207,23 @@ task deployAndProfilingSudoRun { } deployAndProfilingSudoRun.dependsOn deploy, remoteProfilingSudoRun +task deployAndNativeRun { + doLast { + } +} +deployAndNativeRun.dependsOn deploy, remoteNativeRun + + + apply from: './gradle/config.gradle' //Organize tasks in a Group def groupName = "ev3dev-lang-java" testConnection.group = groupName +free.group = groupName +ps.group = groupName +top.group = groupName +stopBluetooth.group = groupName ev3devInfo.group = groupName removePreviousJar.group = groupName deploy.group = groupName @@ -168,9 +233,11 @@ remoteRunClassVerbose.group = groupName remoteSudoRun.group = groupName remoteProfilingRun.group = groupName remoteProfilingSudoRun.group = groupName +remoteNativeRun.group = groupName deployAndRun.group = groupName deployAndBrickRun.group = groupName deployAndSudoRun.group = groupName deployAndProfilingRun.group = groupName deployAndProfilingSudoRun.group = groupName +deployAndNativeRun.group = groupName pkillJava.group = groupName From 6500b3af2a9afe10622bf7889d70d8c683ade181 Mon Sep 17 00:00:00 2001 From: Juan Antonio Brena Moral Date: Mon, 5 Nov 2018 21:17:51 +0100 Subject: [PATCH 13/13] Removed Native deploy task --- gradle/deploy.gradle | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/gradle/deploy.gradle b/gradle/deploy.gradle index dcd1841e..cb96f2df 100644 --- a/gradle/deploy.gradle +++ b/gradle/deploy.gradle @@ -167,15 +167,6 @@ task remoteProfilingSudoRun { } } -task remoteNativeRun << { - ssh.run { - session(remotes.ev3dev) { - println "time java -verbose:class -verbose:jni -Djava.library.path=/usr/lib/jni/ -cp /home/robot/" + "${rootProject.name}" + "-" + version + "-all.jar:/usr/share/OpenCV/java/opencv-249.jar examples.opencv.HelloWorldCV" - execute "time java -verbose:class -verbose:jni -Djava.library.path=/usr/lib/jni/ -cp /home/robot/" + "${rootProject.name}" + "-" + version + "-all.jar:/usr/share/OpenCV/java/opencv-249.jar examples.opencv.HelloWorldCV" - } - } -} - task deployAndRun { doLast { } @@ -207,14 +198,6 @@ task deployAndProfilingSudoRun { } deployAndProfilingSudoRun.dependsOn deploy, remoteProfilingSudoRun -task deployAndNativeRun { - doLast { - } -} -deployAndNativeRun.dependsOn deploy, remoteNativeRun - - - apply from: './gradle/config.gradle' //Organize tasks in a Group @@ -233,11 +216,9 @@ remoteRunClassVerbose.group = groupName remoteSudoRun.group = groupName remoteProfilingRun.group = groupName remoteProfilingSudoRun.group = groupName -remoteNativeRun.group = groupName deployAndRun.group = groupName deployAndBrickRun.group = groupName deployAndSudoRun.group = groupName deployAndProfilingRun.group = groupName deployAndProfilingSudoRun.group = groupName -deployAndNativeRun.group = groupName pkillJava.group = groupName