Solved: Error with EV3 Motors using BricxCC

[afanofosc]

Did you try the corrected replacement for RotateMotorEx and then use that API function in your test code?

Can you post a simple program that demonstrates how you are testing OutputStepSyncEx?

With OutputStepSyncEx (and the higher level RotateMotorNoWait - with or without the Ex) you need to wait after the call long enough for it to complete the movement before the program exits. You might, for example, put a call to Wait(SEC_3); after the call to either RotateMotorNoWait or OutputStepSyncEx and before the call to OutputClose() and OutputExit().

I can't tell whether you are correctly waiting after the motor movement command and before the code that shuts down the output module.

John Hansen

[afanofosc]

I've uploaded a new lms_api.zip and BricxCC test_release zip to http://bricxcc.sourceforge.net/test_releases/

The ex_RotateMotor.c sample program appears to work correctly in all cases.

If you want to link to libev3.so you will need to copy it to a micro SD card in a folder off the root of the card called "lib". This folder will show up on the EV3 as /media/card/lib. The lms_api.zip also contains the standard C++ library that is not included on the EV3 (for some odd reason). You should also copy this file to that "lib" folder if you want to do any C++ programming for the EV3. Check the option on the EV3 tab in the Preferences dialog if you want to link to the libev3 shared library. If you want to keep this shared library in separate library folder on your PC then you'll need to add a -L library path switch in the makefile template.

John Hansen

[endojo]

I quickly tested it out, and even if it gets compiled and uploaded to the brick I'm not able to execute it. Later I will investigate more time but right now that is all I can say.

(It's most likely a problem with the compiler - can you please specify more precisly where to add the -L switch?)

[afanofosc]

If the executable is successfully compiling and downloading but nothing happens when you execute it from within BricxCC then it would be useful to try running it from a putty telnet window. You may be getting a segmentation fault. That's what I was getting yesterday at first.

I forgot to mention that I made some changes to the default makefile template. Here's the new default, which you can copy and paste into that window (use the right click context menu to select what's there and paste over it with the new content). Alternatively, you can just click the Default button while the Compiler tab is active. It will reset all compiler settings to their default values.

Code: Select all

PROGRAM=%PROGRAM%
DOBJECTS=%DOBJECTS%
TOOLPREFIX=%TOOLPREFIX%

all:: realclean $(DOBJECTS) $(PROGRAM)

download:: all

#pscp -scp -pw "%PW%" %PROGRAM% root@%IPADDR%:%FOLDER%

clean::
	rm -f *.o *.ppu *.rst

realclean:: clean
	rm -f $(PROGRAM)

FLAGS=%FLAGS%
LDFLAGS=-Wl,-R/media/card/lib

CC=$(TOOLPREFIX)%CCNAME%

# how to link executable
%PROGRAM%: %MAINSRC%
	$(CC) $(FLAGS) $(LDFLAGS) $< -o$@ %LINKOBJS%

# how to compile source
%.o: %%EXT%
	$(CC) $(FLAGS) %LINKONLY% $< -o$@

The -L library path switch is for linking on your PC to a library that is not in a folder that the linker normally checks, which would be the lib folders in your CodeSourcery Lite directory structure and the current directory. So if libev3.so is in the same folder as your source then you don't need a -L switch. Otherwise, add it ahead of the %LINKOBJS%. Here's an example:

Code: Select all

# how to link executable
%PROGRAM%: %MAINSRC%
	$(CC) $(FLAGS) $(LDFLAGS) $< -o$@ -L../lib %LINKOBJS%

The -L switch has no impact on runtime behavior. It has only a link-time impact, i.e., helping the compiler find the library at link time. At runtime the library is found via the OS link library path and the RPATH set in the executable. The LDFLAGS variable in the above makefile sample is used to set the RPATH to /media/card/lib so that if you copy the libev3.so to that folder (i.e., a lib folder at the root of your micro SD card) and put that card in your EV3 then it will find and use the library at runtime. It is easier to test the basic functionality of the code without the complexity of runtime library loading so I would recommend that you not link to libev3.so and instead add ev3_output.c and ev3_command.c to your test project's .prj file using the Project Manager tool, ideally with those files in the same folder (for now) as your source file.

John Hansen

[endojo]

Thank you for explaining this stuff.
First I was worried because it didn't work - and there is something wrong in the makefile template:
C:\...\lcd_test_c.mak:12: *** missing separator. Stop.

Since I'm not familiar to the syntax of those templates, I couldn't fix it, so I used the old one - wich worked after resetting everything.

And - Yay! - it's one step closer to work!
But there's still something wrong with medium motors. I tried the test with only the to big motors attached to the brick and everything's working fine,
but when using the medium motor it still crashes. (I tried out: OUT A B C: Big Big Medium and Medium Big Big, both crashes.)

So I really hope after isolating the problem this will be an easy fix!

P.S.: When only having attached the medium motor it still crashes, so mixing up the motor types is not the problem.

[afanofosc]

If I can't reproduce the problem I won't be able to fix it. Did you run my program unmodified? I had the medium motor attached to A, and two large motors attached to B and C. My ex_RotateMotor.c program ran without crashing.

Are you linking to libev3.so or not? The template I posted is exactly the template you get when you click the Default button so it must have gotten mangled slightly while copying from a browser window and pasting it into your makefile template window. The indented lines (such as line 12) are supposed to only have a single tab character at the start of the line. Perhaps those were converted to multiple spaces or something.

The bottom line is I have no idea what code you are running so it makes it extremely difficult to know where the root of the problem might be. Please, always post source.

This, btw, is the sort of noise that I mentioned as the reason I prefer that users of alpha code email me instead of posting on the forums. Once the problem is resolved a post summarizing the findings would be far more useful than multiple messages back and forth.

The one line you posted that hints at what you are running says "lcd_test_c.mak" which makes me think you are not running my ex_RotateMotor.c test code or anything else that only tests the RotateMotor API function. Please do not try anything other than my ex_RotateMotor.c test program for now. I know, for instance, that there is at least one other API routine that will not work correctly with single motors so including that API function in a test harness is counter-productive at the moment.

John Hansen

[endojo]

So... ok, I'm really ashamed right now...

Everything works!
I copied again the temp file (Pressing Default did nothing) and since there where three whitspaces instead of a tab character so I replaced it.
After that I opened ex_RotateMotor.c, included ev3_ouptut.c and ev3_command.c to the File List, connected the motors like you did and I had no troubles starting the program.

Since I don't know the internals, I hope that I didn't waste too much of your time and am very thankful that you've solved it!