Hello. I write this hoping it can be fixed before I have the competition...

Basically, TACHO_HOLD or just "hold" if we don't use INX_T, doesn't work. I remember it working when I used ev3dev-python, so this problem seems to be limited to ev3dev-c.

I am using ev3dev jessie.

In ev3-c/source/ev3, I got below error:

$ make
python -u ../../yupp/yup.py -q --pp-browse -d../../source/ev3 ev3_light.yu-h
File "../../yupp/yup.py", line 407
print PP_I, PP_FILE % fn
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(PP_I, PP_FILE % fn)?
make: *** [makefile:289: ev3_light.h] Error 1

Should I rewrite?

environment:
archlinux: (May 7, 2018)
ev3dev-c: 1.0c2, 2017-10-13
kernel: 4.4.87-22-ev3dev-ev3
arm-linux-gnueabi-gcc: 8.1.0

Thank you.

When I do make at ev3dev-c/source/ev3,I got below error:

arm-linux-gnueabi-gcc -I. -I../../3d_party -Iev3_link -O2 -std=gnu99 -W -Wall -Wno-comment -fPIC -c ../../3d_party/modp_numtoa.c -o ../../object/./modp_numtoa.o
In file included from ../../3d_party/modp_numtoa.h:37,
                 from ../../3d_party/modp_numtoa.c:4:
/usr/lib/gcc/arm-linux-gnueabi/8.1.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                ^~~~~~~~~~
compilation terminated.
make: *** [makefile:294: ../../object/./modp_numtoa.o] Error 1

environment:
archlinux(May 8,18)
arm-linux-gnueabi: 8.1.0

I have no idea. What should I do?

Thank you.

I'm having a little trouble getting started. I'm running ev3dev jessie on Raspberry Pi B+ V1.2

After initial setup, when I run make in the source/ev3 directory, this is my output:

/bin/sh: 1: arm-linux-gnueabi-gcc: not found
/bin/sh: 1: arm-linux-gnueabi-gcc: not found
/bin/sh: 1: arm-linux-gnueabi-gcc: not found
python -u ../../yupp/yup.py -q --pp-browse -d../../source/ev3 ev3_sensor.yu-h
* ERROR * 
  File "../../yupp/yup.py", line 290, in _pp
    ast = yuparse( yushell.input_file )
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 932, in yuparse
    ( sou, ast ) = text.next()
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 984, in ps_text
    ( sou, leg ) = ps_import( sou, depth + 1 )
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 908, in wrapped
    return fn( sou, depth )
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 1168, in ps_import
    leg = yuparse( _import_source( lpath, False ))
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 932, in yuparse
    ( sou, ast ) = text.next()
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 984, in ps_text
    ( sou, leg ) = ps_import( sou, depth + 1 )
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 908, in wrapped
    return fn( sou, depth )
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 1176, in ps_import
    leg = yuparse( _import_eval( leg ))
  File "/home/robot/ev3dev-c/yupp/yugen.py", line 887, in _import_eval
    sou = eval( code, dict( globals(), **builtin ))                                                                #pylint: disable=eval-used
  File "<string>", line 2, in <module>
  File "grab_sensors.py", line 42, in grab_sensors
    j = urllib2.urlopen( url )
  File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 437, in open
    response = meth(req, response)
  File "/usr/lib/python2.7/urllib2.py", line 550, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.7/urllib2.py", line 475, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 558, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
TypeError: python: __init__() takes exactly 6 arguments (2 given)
  File "ev3_sensor-dict.yu", line 16
    )
     ^


makefile:289: recipe for target 'ev3_sensor.h' failed
make: *** [ev3_sensor.h] Error 4

python version is 2.7.9

Any guidance would be great.

I'm trying to write some support routines to allow someone to specify the sensor type (from ev3_sensor.h) and the port (INPUT_1/2/3/4) that it should be configured in.

The API would look like the following:

/** Configure the specific sensor type fpr a given port and find the sequence number
 *
 * @param type_inx Sensor type. [From ev3_sensor.h]
 * @param port EV3 port.
 * @param extport Extended port (used by Motor Multiplexers).
 * @param[out] sn Buffer for the sequence number.
 * @return Flag - the sensor is found.
 *
 */
bool dvcs_config_sensor_type_for_port(INX_T type_inx, U8 port, U8 extport, U8 *sn );

From the examples, I'd need to call set_port_mode_inx() and then set_port_set_device() to configure the device/sensor correctly.

Currently, there is no API to determine the correct port mode for a given sensor type.
I've attempted to come up with a routine to do so but I'm not sure if it is all correct since I'm still quite confused regarding how configuration of the port for specific sensors are supposed to be done:

/* Convert a Sensor Type into the appropriate Port Mode for configuring set_port_mode_inx() */
INX_T ev3_sensor_port_mode_inx(INX_T type_inx ) {

	switch ( type_inx ) {
	case EV3_ANALOG_XX:
		return INPUT_EV3_ANALOG;
	case NXT_ANALOG:
		return INPUT_NXT_ANALOG;
	case PIXY_LEGO:
		return INPUT_NXT_I2C;
	case DI_DFLEX:
		return NXT_ANALOG;
	case FCL_9DOF:
	case FCL_ADC:
	case FCL_ALTITUDE:
	case FCL_GESTURE:
	case FCL_HUMIDITY:
	case FCL_IR:
	case FCL_LIGHT:
		return INPUT_EV3_UART;
	case HT_NXT_COLOR:
	case HT_NXT_ANGLE:
	case HT_NXT_ACCEL:
	case HT_NXT_BAROMETRIC:
	case HT_NXT_COLOR_V2:
		return INPUT_NXT_I2C;
	case HT_NXT_EOPD:
	case HT_NXT_FORCE:
	case HT_NXT_GYRO:
		return NXT_ANALOG;
	case HT_NXT_IR_LINK:
	case HT_NXT_IR_RECEIVER:
	case HT_NXT_PIR:
	case HT_NXT_COMPASS:
		return INPUT_NXT_I2C;
	case HT_NXT_MAG:
		return NXT_ANALOG;
	case HT_NXT_IR_SEEK_V2:
	case HT_NXT_SMUX:
	case HT_SUPER_PRO:
		return INPUT_NXT_I2C;
	case LEGO_EV3_US:
	case LEGO_EV3_GYRO:
	case LEGO_EV3_COLOR:
		return INPUT_EV3_UART;
	case LEGO_EV3_TOUCH:
		return INPUT_EV3_ANALOG;
	case LEGO_EV3_IR:
		return INPUT_EV3_UART;
	case WEDO_HUB:
		return PORT_MODE__NONE_;					// FIXME: USB Port (?)
	case WEDO_MOTION:
	case WEDO_TILT:
		return WEDO_AUTO;
	case LEGO_POWER_STORAGE:
	case LEGO_NXT_TEMP:
		return INPUT_NXT_I2C;
	case LEGO_NXT_TOUCH:
	case LEGO_NXT_LIGHT:
	case LEGO_NXT_SOUND:
		return INPUT_NXT_ANALOG;
	case LEGO_NXT_US:
		return INPUT_NXT_I2C;
	case MI_XG1300L:
	case MS_ABSOLUTE_IMU:
	case MS_ANGLE:
	case MS_LIGHT_ARRAY:
	case MS_LINE_LEADER:
	case MS_NXTCAM:
	case MS_NXTCAM5:
	case MS_8CH_SERVO:
	case MS_PPS58_NX:
	case MS_PIXY_ADAPTER:
		return INPUT_NXT_I2C;
	case MS_EV3_SMUX:
		return MS_EV3_SMUX_ANALOG;				// FIXME: There are two settings, MS_EV3_SMUX_ANALOG and MS_EV3_SMUX_UART
	case MS_NXTMMX:
		return MS_NXTMMX_TACHO_MOTOR;
	case MS_NXT_TOUCH_MUX:
		return INPUT_NXT_ANALOG;
	default:
		return PORT_MODE__NONE_;
}

In the servo snippet, you have:

sn_port = ev3_search_port( INPUT_1, EXT_PORT__NONE_ );
set_port_mode_inx( sn_port, INPUT_NXT_ANALOG );
set_port_set_device( sn_port, ( char *) ev3_sensor_type( MS_8CH_SERVO ));

I think INPUT_NXT_ANALOG should be INPUT_NXT_I2C instead based on this.
But then there are also specific cases such as MS_NXTMMX_TACHO_MOTOR which I presume is the correct port mode for MS_NXTMMX.

I'd like to propose that ev3_sensor_port_mode_inx() (or whichever naming is better) is added to the ev3dev-c library.

Unable to make the tacho example since make file looks for Debug folder with capital letter, while the debug folder in tacho has debug with lowercase.

Currently, ENUM_EQ which uses a numerical constant value as a parameter has a L suffix added. This causes the Assembler to complain about syntax errors.

arm-linux-gnueabi-gcc -I../../../include -I../../../ev3dev-c/asm -O2 -std=gnu99 -W -Wall -Wno-comment -g -c tachotest.S -o ../../../object/tachotest.o
../../../ev3dev-c/asm/ev3_tacho.h: Assembler messages:
../../../ev3dev-c/asm/ev3_tacho.h:82: Error: junk at end of line, first unrecognized character is `L'

yupp shoud be modified to not generate a L suffix for numerical constants. After I remove the L suffix manually, I can assemble the files without any errors.

Files which have numerical constants:

ev3_dc.h:ENUM_EQ DC_RUNNING, 0x1L
ev3_dc.h:ENUM_EQ DC_RAMPING, 0x2L
ev3_tacho.h:ENUM_EQ TACHO_RUNNING, 0x1L
ev3_tacho.h:ENUM_EQ TACHO_RAMPING, 0x2L
ev3_tacho.h:ENUM_EQ TACHO_HOLDING, 0x4L
ev3_tacho.h:ENUM_EQ TACHO_OVERLOADED, 0x8L
ev3_tacho.h:ENUM_EQ TACHO_STALLED, 0x10L
ev3_servo.h:ENUM_EQ SERVO_RUNNING, 0x1L
ev3_both.h:#define EV3_KEY_UP      0x01L
ev3_both.h:#define EV3_KEY_DOWN    0x02L
ev3_both.h:#define EV3_KEY_LEFT    0x04L
ev3_both.h:#define EV3_KEY_RIGHT   0x08L
ev3_both.h:#define EV3_KEY_CENTER  0x10L
ev3_both.h:#define EV3_KEY_BACK    0x20L

The default master branch for ev3dev-c is still based on the jessie distribution. I propose to merge/switch it to the stretch branch since new users coming from ev3dev.org will be downloading the stretch release in any case.

Otherwise people not familiar with git will probably be confused since the examples will not work on stretch.

Error

The build fails with the message

python -u ../../yupp/yup.py -q --pp-browse -d../../source/ev3 ev3_sensor.yu-h
python -u ../../yupp/yup.py -q --pp-browse -d../../source/ev3 brick.yu-h
* ERROR * 
  File "../../yupp/yup.py", line 269, in _pp
    ast = yuparse( yushell.input_file )
  File "/tmp/test/yupp/yugen.py", line 923, in yuparse
    ( sou, ast ) = text.next()
  File "/tmp/test/yupp/yugen.py", line 975, in ps_text
    ( sou, leg ) = ps_import( sou, depth + 1 )
  File "/tmp/test/yupp/yugen.py", line 899, in wrapped
    return fn( sou, depth )
  File "/tmp/test/yupp/yugen.py", line 1159, in ps_import
    leg = yuparse( _import_source( lpath, False ))
  File "/tmp/test/yupp/yugen.py", line 923, in yuparse
    ( sou, ast ) = text.next()
  File "/tmp/test/yupp/yugen.py", line 975, in ps_text
    ( sou, leg ) = ps_import( sou, depth + 1 )
  File "/tmp/test/yupp/yugen.py", line 899, in wrapped
    return fn( sou, depth )
  File "/tmp/test/yupp/yugen.py", line 1167, in ps_import
    leg = yuparse( _import_eval( leg ))
  File "/tmp/test/yupp/yugen.py", line 878, in _import_eval
    sou = eval( code, dict( globals(), **builtin ))                                                                #pylint: disable=eval-used
  File "<string>", line 2, in <module>
  File "grab_sensors.py", line 42, in grab_sensors
    j = urllib2.urlopen( url )
  File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib64/python2.7/urllib2.py", line 435, in open
    response = meth(req, response)
  File "/usr/lib64/python2.7/urllib2.py", line 548, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib64/python2.7/urllib2.py", line 473, in error
    return self._call_chain(*args)
  File "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "/usr/lib64/python2.7/urllib2.py", line 556, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
TypeError: python: __init__() takes exactly 6 arguments (2 given)
  File "ev3_sensor-dict.yu", line 16
    )
     ^


* ERROR * 
  File "../../yupp/yup.py", line 269, in _pp
    ast = yuparse( yushell.input_file )
  File "/tmp/test/yupp/yugen.py", line 923, in yuparse
    ( sou, ast ) = text.next()
  File "/tmp/test/yupp/yugen.py", line 975, in ps_text
    ( sou, leg ) = ps_import( sou, depth + 1 )
  File "/tmp/test/yupp/yugen.py", line 899, in wrapped
    return fn( sou, depth )
  File "/tmp/test/yupp/yugen.py", line 1159, in ps_import
    leg = yuparse( _import_source( lpath, False ))
  File "/tmp/test/yupp/yugen.py", line 923, in yuparse
    ( sou, ast ) = text.next()
  File "/tmp/test/yupp/yugen.py", line 975, in ps_text
    ( sou, leg ) = ps_import( sou, depth + 1 )
  File "/tmp/test/yupp/yugen.py", line 899, in wrapped
    return fn( sou, depth )
  File "/tmp/test/yupp/yugen.py", line 1167, in ps_import
    leg = yuparse( _import_eval( leg ))
  File "/tmp/test/yupp/yugen.py", line 878, in _import_eval
    sou = eval( code, dict( globals(), **builtin ))                                                                #pylint: disable=eval-used
  File "<string>", line 2, in <module>
  File "grab_sensors.py", line 42, in grab_sensors
    j = urllib2.urlopen( url )
  File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib64/python2.7/urllib2.py", line 435, in open
    response = meth(req, response)
  File "/usr/lib64/python2.7/urllib2.py", line 548, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib64/python2.7/urllib2.py", line 473, in error
    return self._call_chain(*args)
  File "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "/usr/lib64/python2.7/urllib2.py", line 556, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
TypeError: python: __init__() takes exactly 6 arguments (2 given)
  File "ev3_sensor-dict.yu", line 16
    )
     ^

Cause

This is caused by an HTTP Error 403 thrown in source/ev3/grab_sensors.py while trying to fetch the sensor data from http://docs.ev3dev.org/projects/lego-linux-drivers/en/ev3dev-jessie/sensors.json

Replication

Run source/ev3/grab_sensors.py manually.

Grabbing the file manually with wget works without error.

I think there is no way to reference the key definitions EV3_KEY_* from the ASM headers currently, as well as constants such as DESC_LIMIT. Should ev3_both.h be manually ported to the ASM folder?

Hi,
I'd just like to find out what is your plan for ev3dev-stretch support in ev3dev-c?
As I mentioned in Issue #15, the current libraries will not work with the new sysfs naming.

Since there is already a beta release of ev3dev-stretch on Aug 6 2018, I think the actual release will be coming along soon.

First off, the sensor itself is working, I can go into Device Browser and it reads the correct values.
Secondly, I can get it to work normally using set_sensor_mode and get_sensor_value<n>.

However, I'm trying to recreate HiTechnic's "enhanced" function they coded for NXC, so going through their source code I came to the immediate issue of not having any function similar to I2CBytes, so I made my own:

typedef unsigned char BYTE;

static void get_sensor_all(BYTE port, char* mode, BYTE* buffer, int off, int len) {
    set_sensor_mode(port, mode);
    int value;
    printf("%s:\t", mode); // for testing
    for (int i = 0; i < len; ++i) {
        get_sensor_value(i + off, port, &value);
        printf("%i\t", value); // for testing
        buffer[i] = (BYTE)value;
    }
    printf("\n"); // for testing
}

But it all the output values were 10 no matter what I did. So I added this between int value and the first printf:

for (int j = 0; j < 100; ++j) {
    for (int i = 0; i < len; ++i) {
        get_sensor_value(i + off, port, &value);
    }
}

My thinking behind this that I needed a bit of time between setting the mode and the final reading, however this caused the outputs to be some crazy large negative numbers.

PS. I need to be able to switch between sensor modes because I need both AC and DC information.

Hello

I am hoping someone can explain the relationship between the python code & C code in the EV3 C libraries. I understand from reading up on SWIG, that C/C++ code can be wrapped for use in scripting languages, however it seems at some point that the opposite is occurring.

For example:
In trying to understand the example (ev3dev-c\eg\tacho\tacho.c) I tried to discover where DESC_LIMIT was declared/defined/set. It is referenced in ev3_tacho.h, but only set in line 133 of ev3.yu-i.

#define DESC_LIMIT    64

All of which gives me the impression that the C is wrapping something else (whatever *.yu-i is).
I suppose I could spend hours trying to get up to speed on SWIG &/or reverse engineering all this, or maybe someone can be merciful and give me a shove in the right direction. I'm finding the examples don't help me that much if I have to go outside of the *.h or *.c files.

Thanks!

I've installed the ev3dev distribution onto the EV3 device and everything boots fine.

I've cloned and built the ev3dev-c library with no problem. But it appears I've either done something incredibly wrong or misunderstood what is compatible with what.

The file ev3_led.c refers to the following files:

static const char *const led_attr_brightness[] = {
	"/sys/class/leds/ev3:left:green:ev3dev/brightness",
	"/sys/class/leds/ev3:right:green:ev3dev/brightness",
	"/sys/class/leds/ev3:left:red:ev3dev/brightness",
	"/sys/class/leds/ev3:right:red:ev3dev/brightness",
	"/sys/class/leds/outA::ev3dev/brightness",
	"/sys/class/leds/outB::ev3dev/brightness",
	"/sys/class/leds/outC::ev3dev/brightness",
	"/sys/class/leds/outD::ev3dev/brightness",

};

But when I look in /sys/class/leds I find the following:

lrwxrwxrwx 1 root root 0 Sep 14 12:35 ath9k_htc-phy0 -> ../../devices/platform/soc@1c00000/ohci-da8xx/usb1/1-1/1-1:1.0/leds/ath9k_htc-phy0
lrwxrwxrwx 1 root root 0 Sep 14 12:35 led0:green:brick-status -> ../../devices/platform/soc@1c00000/ti-pruss/1c32000.pru1/remoteproc/remoteproc0/virtio0/virtio0.ev3-tacho-rpmsg.-1.0/leds/led0:green:brick-status
lrwxrwxrwx 1 root root 0 Sep 14 12:35 led0:red:brick-status -> ../../devices/platform/soc@1c00000/ti-pruss/1c32000.pru1/remoteproc/remoteproc0/virtio0/virtio0.ev3-tacho-rpmsg.-1.0/leds/led0:red:brick-status
lrwxrwxrwx 1 root root 0 Sep 14 12:35 led1:green:brick-status -> ../../devices/platform/soc@1c00000/ti-pruss/1c32000.pru1/remoteproc/remoteproc0/virtio0/virtio0.ev3-tacho-rpmsg.-1.0/leds/led1:green:brick-status
lrwxrwxrwx 1 root root 0 Sep 14 12:35 led1:red:brick-status -> ../../devices/platform/soc@1c00000/ti-pruss/1c32000.pru1/remoteproc/remoteproc0/virtio0/virtio0.ev3-tacho-rpmsg.-1.0/leds/led1:red:brick-status

Did I skip an important step somewhere that normalises the file names or something? Or am I using mixed versions of things that aren't compatible?

Sorry, I cannot create a pull request due to the significant divergence between your stretch branch and my current fork.

I've created a specific patch for this issue, it is in the enclosed file.

0001-Fix-stretch-LED-syspath-naming.patch.txt

Hi,

This is a bit of a tangent, but I'm planning on using ev3dev-c to implement an ARM Assembly Language-based EV3 programming environment. The gist of it is to use the GCC C-Compiler to preprocess the source files (C or Assembly source), so C-style preprocessor directives can be utilized in Assembly Language source files as well.

My main issue currently is how to make the header file definitions accessible from both C and Assembly. In my previous project nxos-armdebug, I used C preprocessor macros (see ev3dev-arm.h) to define shared definitions such as enums, while commenting out function defintions and typedefs.

Since ev3dev-c is using yupp to generate the headers, I'm thinking that it is probably a better solution for my use case. Nonetheless, I'm not sure where to start looking in the yupp code to understand how to modify the output generation module to create ARM assembly syntax headers instead of the C/Ruby/Perl/etc headers.

I'd appreciate it if you can point me towards the relevant info for yupp; that would be great!

Problem

The makefile assumes that the directories D_INSTALL/bin and D_INSTALL/include already exist. This is probably true if D_INSTALL has the standard value, i.e. /usr/local. However, if we are installing into another directory this is probably not true.

Use Case

I am cross-compiling and will only statically link to ev3dev-c. I don't want or need to install ev3dev-c to /usr/local on my pc, I just want it in a subdirectory in my projects file tree, so I can then give that directory to the linker.

Side note: I'm using cmake to automate this, but this shouldn't make any difference to the makefile.

Suggested Solution

add mkdir -p $(D_INSTALL)/lib and mkdir -p $(D_INSTALL)/include to the install function in the makefile. As far as I know, this shouldn't cause any problems if the directories (like /usr/local/lib and /usr/local/include) already exist, and should solve the problem in other cases.

If you'd like a pull request with this change, just let me know. :)

Hi,

I'm trying to port ev3dev-c to run on ev3-stretch, and the /sys/class hierarchy has changed, notably for the LED controls (this is the first device driver I'm trying to port). I understand that the definitions are found in ev3-led-dict.yu.

However, I can't find any information regarding how to use yupp to regenerate the *.h and *.c files after modifying the *.yu file.

I was trying to make remote ev3 running under my mac using python. However, when I try to run the setup.py or import ev3 it will give me this error:

Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

if running pip install --pre ev3dev-c it will say:

setup.py", line 106, in
NAME = import(PACKAGE).library
File "ev3dev/init.py", line 1, in
from ev3 import *
File "ev3dev/ev3.py", line 28, in
_ev3 = swig_import_helper()
File "ev3dev/ev3.py", line 24, in swig_import_helper
_mod = imp.load_module('_ev3', fp, pathname, description)
ImportError: dlopen(ev3dev/_ev3.so, 2): no suitable image found. Did find:
ev3dev/_ev3.so: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x01 0x01 0x01 0x00

The readme didn't specify that it will work on mac but I just wonder if it is possible. Thanks.

I am starting to try to program in C - the advice from ev3dev is to use this library. I managed to set up cross compilation working quite well (writeup on stackexchange) and examples compile and run on EV3 brick, but not so on BrickPi3. I understand that the issue probably is that BrickPi does not autodetect sensors or motors.

Is there a simpler sample program in C that would use sensors/motors without autodetection (int ev3_tacho_init() does not return anything). I cannot yet work it out from the doxygen generated documentation. I am sorry, too complex for a beginner.

In other words - how to deal with no autodetection. Brickpi for example does not create

robot@ev3dev:~/src$ cat /sys/class/lego-sensor/sensor2/driver_name 
lego-ev3-ir

This above works on EV3 device but not on BrickPi :-(

So I'm trying to install the docker cross compiler, and it says that I need to clone the ev3dev-c library in the docker folder. So, I run (in powershell): docker build https://github.com/in4lio/ev3dev-c.git#master:docker. And it gives me:

Sending build context to Docker daemon 9.216kB
Step 1/4 : FROM ev3dev/debian-jessie-armel-cross:latest
latest: Pulling from ev3dev/debian-jessie-armel-cross

....
....

Removing intermediate container 9a74020d0c2e
---> 1e195ce2dd5d
Successfully built 1e195ce2dd5d
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

After that, I tried running:
cd /PATH/TO/ev3dev-c/docker/
but it doesn't work and gives me an error saying it can't find it. After copying the library, is there anything else I need to set-up?

And also just to clarify: does the bash command line support secure copy protocol (scp) like on linux? If not, how would I transfer my compiled files to my ev3?

Thanks!

I followed the instructions to set up ev3dev-c on my ev3 running stretch.

It was able to install and build the "hello" program.

I installed libperl-dev.

from the ev3dev-c/perl/eg directory I tried to run the led.pl example:

Can't load '../ev3.so' for module ev3: libperl.so.5.20: cannot open shared object file: No such file or directory at /usr/lib/arm-linux-gnueabi/perl/5.24/DynaLoader.pm line 187.
at ../ev3.pm line 11.
Compilation failed in require at led.pl line 2.
BEGIN failed--compilation aborted at led.pl line 2.

I then tried from the ev3dev-c/perl directory in case it couldn't see ev3.so:

perl ./eg/led.pl
Can't locate ev3.pm in @inc (you may need to install the ev3 module) (@inc contains: .. /etc/perl /usr/local/lib/arm-linux-gnueabi/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabi/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabi/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabi/perl-base) at ./eg/led.pl line 2.
BEGIN failed--compilation aborted at ./eg/led.pl line 2.

Any hints on what I'm doing wrong here?

In ev3dev stretch distro, the address of a port has changed:

$ cat /sys/class/tacho-motor/motor0/address 
ev3-ports:outC

$ cat /sys/class/lego-sensor/sensor0/address 
ev3-ports:in4

This is causing the ev3_parse_port_name() function to fail.
I don't think it is a trivial fix, since if I modify ev3_port-dict.yu to include the new ev3-ports prefix for in and out (besides the issue of it being non-portable to the other platforms. e..g, Raspberry Pi), I get the following error on compiling:

arm-linux-gnueabi-gcc -I. -I../../3d_party -O2 -std=gnu99 -W -Wall -Wno-comment -fPIC -c ev3_port.c -o ../../object/./ev3_port.o
ev3_port.c:366:12: warning: ISO C99 requires whitespace after the macro name
 #define EV3-PORTS:IN_PREF_LEN  12
            ^
ev3_port.c:367:12: warning: ISO C99 requires whitespace after the macro name
 #define EV3-PORTS:OUT_PREF_LEN  13
            ^
ev3_port.c:367:0: warning: "EV3" redefined
 #define EV3-PORTS:OUT_PREF_LEN  13
 
ev3_port.c:366:0: note: this is the location of the previous definition
 #define EV3-PORTS:IN_PREF_LEN  12
 
In file included from /usr/arm-linux-gnueabi/include/string.h:630:0,
                 from ev3_port.c:14:
ev3_port.c: In function 'ev3_parse_port_name':
ev3_port.c:367:13: error: 'PORTS' undeclared (first use in this function)
 #define EV3-PORTS:OUT_PREF_LEN  13
             ^
ev3_port.c:380:38: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN ) == 0 ) {
                                      ^~~
ev3_port.c:367:13: note: each undeclared identifier is reported only once for each function it appears in
 #define EV3-PORTS:OUT_PREF_LEN  13
             ^
ev3_port.c:380:38: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN ) == 0 ) {
                                      ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:380:38: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN ) == 0 ) {
                                      ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:380:38: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN ) == 0 ) {
                                      ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:380:38: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN ) == 0 ) {
                                      ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:380:38: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN ) == 0 ) {
                                      ^~~
ev3_port.c:367:18: error: expected ';' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:382:11: note: in expansion of macro 'EV3'
   name += EV3-PORTS:IN_PREF_LEN;
           ^~~
In file included from /usr/arm-linux-gnueabi/include/string.h:630:0,
                 from ev3_port.c:14:
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:389:39: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:out", EV3-PORTS:OUT_PREF_LEN ) == 0 ) {
                                       ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:389:39: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:out", EV3-PORTS:OUT_PREF_LEN ) == 0 ) {
                                       ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:389:39: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:out", EV3-PORTS:OUT_PREF_LEN ) == 0 ) {
                                       ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:389:39: note: in expansion of macro 'EV3'
  if ( strncmp( name, "ev3-ports:out", EV3-PORTS:OUT_PREF_LEN ) == 0 ) {
                                       ^~~
ev3_port.c:367:18: error: expected ';' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:391:11: note: in expansion of macro 'EV3'
   name += EV3-PORTS:OUT_PREF_LEN;
           ^~~
ev3_port.c: In function 'ev3_port_name':
ev3_port.c:367:13: error: 'PORTS' undeclared (first use in this function)
 #define EV3-PORTS:OUT_PREF_LEN  13
             ^
ev3_port.c:406:30: note: in expansion of macro 'EV3'
   memcpy( p, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN );
                              ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:406:30: note: in expansion of macro 'EV3'
   memcpy( p, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN );
                              ^~~
ev3_port.c:367:18: error: expected ';' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:407:8: note: in expansion of macro 'EV3'
   p += EV3-PORTS:IN_PREF_LEN;
        ^~~
ev3_port.c:367:18: error: expected ')' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:414:31: note: in expansion of macro 'EV3'
   memcpy( p, "ev3-ports:out", EV3-PORTS:OUT_PREF_LEN );
                               ^~~
ev3_port.c:367:18: error: expected ';' before ':' token
 #define EV3-PORTS:OUT_PREF_LEN  13
                  ^
ev3_port.c:415:8: note: in expansion of macro 'EV3'
   p += EV3-PORTS:OUT_PREF_LEN;
        ^~~
ev3_port.c:401:44: warning: unused parameter 'extport' [-Wunused-parameter]
 char *ev3_port_name( uint8_t port, uint8_t extport, uint8_t addr, char *buf )
                                            ^~~~~~~

Currently yupp is converting the string literally and generating the following output:

#define EV3-PORTS:IN_PREF_LEN  12
#define EV3-PORTS:OUT_PREF_LEN  13
#define I2C_PREF_LEN  3
#define MUX_PREF_LEN  3
#define SV_PREF_LEN  2
#define M_PREF_LEN  1
#define WEDO_PREF_LEN  4

void ev3_parse_port_name( char *name, uint8_t *port, uint8_t *extport, uint8_t *addr )
{
	*port = EV3_PORT__NONE_;
	*extport = EXT_PORT__NONE_;
	*addr = 0;

	if ( strncmp( name, "ev3-ports:in", EV3-PORTS:IN_PREF_LEN ) == 0 ) {
		/* "ev3-ports:in" */
		name += EV3-PORTS:IN_PREF_LEN;
		*port = *name++;
		if ( *name != ':' ) return;
		++name;
			
		return;
	}					
	if ( strncmp( name, "ev3-ports:out", EV3-PORTS:OUT_PREF_LEN ) == 0 ) {
		/* "ev3-ports:out" */
		name += EV3-PORTS:OUT_PREF_LEN;
		*port = *name++;
		if ( *name != ':' ) return;
		++name;
			
		return;
	}										
	return;
}

I also tried putting the ev3-ports in the PORT_SLICE_PARENT field for in and out, but it probably needs to have an empty PORT_SLICE_PARENT as the first item(s) in the table to work, as the generated ev3_parse_port_name() is a empty function.

When I try to compile eve_link there is an error:

Undefined reference to 'main' error in crt1.o function _start...

Before adding -nostartfiles flag its compiling. but return an error

segmentation fault

what can i do?

it was on ubuntu 14

hi there! I can't seem to get the light example to work, it just returns for every option, any idea what I could be doing wrong?

I would like to use ev3dev to teach C programming to some kids. ev3dev - Programming Languages recommends your ev3dev-c lib.

I saw that your lib is not ready for ev3dev-stretch yet (#23). I would love to contribute, but I hesitate to learn the ropes of yupp if I do not understand why it is useful at all.

I'm starting on ev3dev-c as my target language for EV3 development, and I'd just like to mention that the building inside docker guide is not working with the default ev3dev-cross Docker images, since they don't come with python installed.

It might be fine for someone familiar with docker and how to keep updated containers around, but I think there would be a problem in the following cases if someone is using the default docker images:

1. The existing SKIP_PP checks will skip header generation inside the Docker image since __ARM_ARCH_4T__ always evaluate to TRUE. (incidentally this is a rather fragile test since the Host-based Carlson-Minot Cross-compilers just happen to NOT support ARMv4T output. Would /proc/cpuinfo be a better test?)
2. 'make clean; make' will fail inside the docker container, since the *.h and *.c file cannot be regenerated.
3. I cannot generate the *.c files easily outside the Docker environment (assuming that i don't have arm-linux-gnueabi-gcc installed for the Host), since make does not create all the necessary files in one step. (It'll generate one .c and then try to run gcc on it).

Is it possible to cause the *.c and *.h generation step to be done in one shot, so that it can at least avoid problem #3? Alternatively python would have to be included as part of the ev3dev-cross images.

Hi,

I try the sensor_is_plugged fonction, but it doesn't work as expected :
whatever i connect on any port, it return ever true.

#include <stdio.h>
#include "brick.h"
#include <unistd.h>
#define Sleep( msec ) usleep(( msec ) * 1000 )

#define capteurContact IN4
bool etatCapteurContact;

int initCapteurContact()
{
if ( sensor_is_plugged(capteurContact,LEGO_EV3_TOUCH))
{
printf( "capteur contact connecté\n");
}
else
{
printf("vérifier le branchement du capteur de contact !\n");
return (0);
}
return 1;
}

int main( void )
{
if ( ev3_init() == -1 )
{
printf("\erreur d'initialisation\n");
return ( 1 );
}
printf("initialisation des capteurs ... ");
ev3_sensor_init();
printf(" ok !\n");
printf("initialisation des actionneurs ... ");
while ( ev3_tacho_init() < 1 ) Sleep( 1000 );
printf(" ok !\n");
if ( initCapteurContact()==0 )
{
ev3_uninit();
return(-1);
}

ev3_uninit();
printf("*** ( EV3 ) Bye! ***\n" );
return(0);
}

thanks.

Frankly, this is what one hates Windows programming for:

Short: you cannot use close(sockfd) (see source/ev3/ev3_link/ev3_link.c ) to close a WSA/winsock socket. It needs to be closesocket(). This only comes to attention, when you embed the library into something longer running.
Yes, I found that out the hard way.

Anyways, top library!!

I tried to run the sample program for the engines tacho.c with ev3dev-c.

Compiling and running the example on the Brick does not cause any problems.
But I don't want to write every line of code in the ssh terminal, I want to use an IDE.
So i tried Docker Cross Compile with eclipse.

When I use Docker-Cross Compile to compile the project and transfer it to the brick, the program gets stuck in the ev3_tacho_init while running on the EV3 and does not find the path "/sys/class/tacho-motor".

And one more question:
When I compile the example tacho.c with mingw on Windows and run it with tacho.exe, the brick is not found, although the IP address is set correctly. And there it gets stuck too.

I would be very happy about any support

Hi,

After looking at the ev3_led.h and ev3_light.h ASM headers again, I find that the actual ENUMs are difficult to parse from the generated output.

.set ENUM_COUNTER, 0
.equiv LIT_OFF, ENUM_COUNTER
.set ENUM_COUNTER, ENUM_COUNTER + 1
.equiv LIT_GREEN, ENUM_COUNTER
.set ENUM_COUNTER, ENUM_COUNTER + 1
.equiv LIT_RED, ENUM_COUNTER
.set ENUM_COUNTER, ENUM_COUNTER + 1
.equiv LIT_AMBER, ENUM_COUNTER
.set ENUM_COUNTER, ENUM_COUNTER + 1

.equiv LIT__COL__, ENUM_COUNTER

The expanded macros makes the actual ENUM values LIT_OFF, LIT_GREEN, LIT_RED, and LIT_AMBER difficult to determine.

I realize that these 2 headers depend on a dictionary file. However, is it possible to generate output that is similar to the other ASM include files?

#include "enum-asm.h"

ENUM_0 LIT_OFF
ENUM_N LIT_GREEN
ENUM_N LIT_RED
ENUM_N LIT_AMBER
ENUM_N LIT__COL__

Not sure whether I specified LIT__COL__ correctly in the example output.

I very recently installed ev3dev, followed instructions, downloaded and built ev3dev-c library - all good
followed a number the examples and noticed that the sensors.c output correctly identified the devices plugged in but NEVER gave a valid port.

ev3_sensor[3]
type = lego-ev3-color
port =
mode = COL-REFLECT
value[0] = 0

Similar issue with testing motors...

I installed gdb and went digging and realized that the issue is in ev3_port.c in the function ev3_parse_port_name(). All of the name strings being passed in have a prefix of "ev3-ports:".

adding the following lines ahead of the first 'if' statement in that function fixed the problem:
if( strncmp( name, "ev3-ports:", 10 ) == 0 )
{
name += 10;
}

ev3_sensor[3]
type = lego-ev3-color
port = in3
mode = COL-COLOR
value[0] = 0

detials of installation:
uname -a
Linux ev3dev 4.14.117-ev3dev-2.3.5-ev3 #1 PREEMPT Sat Mar 7 12:54:39 CST 2020 armv5tejl GNU/Linux

the README in the ev3dev-c source tree reports: ev3dev-c 1.0c3 2019-01-27

Hope this helps
PeterT

I've just finished installing ev3 dev on two of my bricks for a Rubik's cube solver, and after looking through the documentation I've been unable to find a way to use the two bricks simultaneously.

Both bricks control 6 motors, (4 on one and 2 on the other) and I have two color sensors on one of the bricks being used to read the cube faces; this data is then supposed to be sent to the computer and the computer can send instructions to both bricks.

Is there a way I can do this?
Thanks in advance.

There are two more fixes to the GPIO_KEYS_PATH constant that needs to be merged:

tcwan/ev3dev-c/stretch branch commits:
7223109
605b056