I have a weird problem regarding using the motors of my EV3.
After setting up BricxCC and codesourcery (which wasn't difficult at all after I've found the right tutorial) everything worked as expected - I tested all 4 test-samples and there was no problem.
(I am using the lms-api to communicate with the brick)
But when trying to write my own programs there seemed to be random crashes of the ev3 brick. It freezes executing one command forever (or until I force it to restart).
It took me some time until I noticed that RotateMotor was responsible for the crashes. And that's where it's getting strage: The output_test worked fine.
So after some more testing the reason was clear: RotateMotor does only work with 2 or all 4 outputs. E.g. RotateMotor(OUT_A, 20, 360) crashes, while RotateMotor(OUT_BD, 20, 360) doesn't.
But since it looks like a very simple and convincing way of rotating one motor for the giben amount of degrees I'd like to use it. (On(OUT_A) works)
Thus I conclude that there's a bug in the lms-api, or I need some alternative firmware (I searched for it but didn't found a EFW for EV3 - i use just V1.03H)
So if anyone has an idea to fix that problem, feel free to post it as I don't have a clue regarding how lms-api works.
There was an error with the LEGO Mindstorms API, which made the EV3 crash when trying to use RotateMotor, OutputStepSync or similar on anything other than exactly 2 motors.
But thanks to John Hansen this problem was solved. Make sure to use his newest API: http://bricxcc.sourceforge.net/test_releases/
and update the Makefile Template in Preferences->Compiler->EV3 to:
The motor port might give a clue. I seem to remember reading that 2 of the 4 ports are directly connected to some piece of hardware, while the other 2 are not.
Is the code you have posted part from the mindstorms ev3 firmware?
Because then I can do probably nothing about that but a workaround. (I won't set up a virtual machine, clone that repo and try to understand all that code just for fixing a bug)
But on the other hand - if that is really a such low-level problem, why is then NXT-G able to use the same funciton on one motor? (I think the motor block equals on OS Level the RotateMotor Command)
But thank you for the tip, you will save me a lot of time for not going to trial & error with those commands.
P.S.: As I read your thread I noticed: You don't have to remove a battery, holding the back, middle and left button on the EV3 restarts it
In terms of the hardware. I think you are mixing up the Sensor ports with the motor ports. The motor ports are pretty much identical (two pairs one pair on a chip). The sensor ports are different ports 1 and 2 have hardware UARTS ports 3 and 4 use a software UART using the DSP features of the TI processor.
Well - then it seems logical that commands like rotating for a given angle crashes but just turning a motor on doesn't.
But now it seems even more odd to me why something like RotateMotor(OUT_AC,...) works and the same with OUT_A or OUT_C does not.
Right now I am a bit confused why nearly nobody else is complaining about those bugs - the official release of EV3 was more than a month ago and there aren't that many alternatives to bricxCC.
And while the technical details aren't uninteresting, I would be glad if someone could bring up a solution or at least confirm this bug.
#include <stdio.h>
#include <unistd.h>
#include "ev3_output.h"
#include "ev3_timer.h"
#include "ev3_command.h"
int main()
{
int i;
printf("hello world\n");
printf("start of out_test\n");
Wait(SEC_1);
// initialize
if (!OutputInit())
printf("output init returned false\n");
ResetAllTachoCounts(OUT_ABCD);
OutputSetTypes(DEVICE_TYPE_TACHO, DEVICE_TYPE_TACHO, DEVICE_TYPE_TACHO, DEVICE_TYPE_TACHO);
RotateMotor(OUT_AB, 75, 360); //works
//RotateMotor(OUT_A,75, 360); //crashes
printf("Wait(SEC_5)\n");
Wait(SEC_5);
OutputClose();
OutputExit();
printf("end of out_test\n");
return 0;
}
You need to add ev3_output.c, ev3_timer.c and ev3_command.c to the dependencies or whatever it is called.
As you posted that you've problems with compiling: I got linker errors if my source code wasn't in the same folder like the includes - maybe another bug?
As a side note: What I understood is that the lms-api is just a temporary solution and will be replaced by the NXC / NQC Compiler when John Hansen added support for the EV3.
That would make things easier as there would be no more need for the codesourcery cross-compiler anymore.
What is not clear to me is what environment are you guys using to execute your code? Are you running with the VM shut down? In order to properly diagnose problems of this sort it is crucial to know every detail, no matter how trivial you may think it is. I can tell you, for certain, that if you are running with the VM shut down and you have not loaded all the LMS kernel modules in the correct order that there is a good chance that your motors will not work properly.
Also, RotateMotor is a bit of a hack at the moment. It implements a wait to force it to be synchronous. The underlying firmware opcodes are asynchronous and the RotateMotorNoWait routine is a better choice if you want to avoid possible API layer bugs.
I can only use the standard firmware by Lego with VM on (don't know how to kill it and if then USB would still work ).
I only have USB,
no WiFi, no LAN, no SD card.
I can confirm:
OUT_AB is fine, OUT_A blocks, hangs up, no response any longer.
Maybe here: 