(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=gccif 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_LENs 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_64The 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