(Somewhat) minimalist C/C++ EV3 API
-
src/
- contains API source code filesmotor.c
- motor control modulesensor.c
- sensor control moduleshared.c
- shared macros and functions
-
include/
- contains API headersmotor.h
- motor.c headersensor.h
- sensor.c headershared.h
- shared.c header
-
config.h
- configures path prefixes -
Makefile
- instructions for shared library compilation, usecc=gcc
if compiling for x86_64 -
testenv/
- testing environmentbuild/
- compiled testing programstest_gnu_arm
- compiled for ARM architecturetest_gnu_x86_63
- compiled for x86_64 architecture
sys/class/lego-sensor/sensor0/
- lego sensor emulatorsys/class/tacho-motor/motor0/
- lego motor emulatormain.c
- main testing programMakefile
- instructions for GNU-ARM and GNU-x86_64 compilation
Testenv allows for debugging and testing of API functionality on x86_64 machines without the need for an ARM processor or arm-linux-gnueabi toolchain.
When using ev3dev-clib-min on a lego robot, path prefixes in config.h
should be absolute, as the /sys/
directory is located in /
#define PATH_LEN 23
#define SENSOR_PREFIX "/sys/class/lego-sensor/"
#define MOTOR_PREFIX "/sys/class/tacho-motor/"
When using ev3dev-clib-min in testenv, however, path prefixes must be relative to the current directory, ./
(if the program is ran in testenv/
director, that is)
#define PATH_LEN 24
#define SENSOR_PREFIX "./sys/class/lego-sensor/"
#define MOTOR_PREFIX "./sys/class/tacho-motor/"
Notice the change in PATH_LEN
. PATH_LEN
describes the string lenght of both SENSOR_PREFIX
and MOTOR_PREFIX
. Currently there is no reason for two separate PATH_LEN
s as in ev3dev and in testenv, both have the same length.
(Assuming the testing code is situated in main.c
) To build a testing program, execute
make GNU-x86_64
The resulting executable binary can then be found in build/
and will be named test_gnu_x86_64
and can be executed using
./build/test_gnu_x86_64