Wishlist for C for EV3 (EVC, EV3-C)
Re: Wishlist for C for EV3 (EVC, EV3-C)
ok so then I'll let me be surpised
Re: Wishlist for C for EV3 (EVC, EV3-C)
Is the lower throughput due to the third and fourth sensor ports being connected via the PRUs and not via actual UARTs?mightor wrote:ok, consider the worst case scenario:
The first two sensor ports are running at 460Kbit/s each.
The third and fourth are going at 230Kbit/s each.
= Xander
230 Kbps is still respectable (it is the speed of the old serial Appletalk networks).
Re: Wishlist for C for EV3 (EVC, EV3-C)
That's my understanding yes. I am not all that familiar with the functionality of the PRU, but this is based on info given to use by the hardware engineers.tcwan wrote:Is the lower throughput due to the third and fourth sensor ports being connected via the PRUs and not via actual UARTs?
230 Kbps is still respectable (it is the speed of the old serial Appletalk networks).
= Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
-
- Posts: 323
- Joined: 29 Sep 2010, 05:03
Re: Wishlist for C for EV3 (EVC, EV3-C)
Remember though that these transfer speeds are the raw speeds of the UARTs, the actual update rates at which the current sensors actually produce data is way, way slower than this. When they talk to to the EV3 they may talk very fast, but they only choose to say anything from time to time! The following link gives you a good idea for how often the sensors actually prodice data:
https://raw.github.com/mindboards/ev3so ... pedata.rcf
The time column shows how many mS there are between data updates. So the old Lego light sensor produces data every 10mS while the new IR proximity sensor produces it every 1100mS. I have no idea how accurate these figures are but they probably give you a rough idea of the real world data rates, or at least how the Lego folks see them being used.
On the topic of creating programs that run on the PC and talk to sensors or actuators attached to the EV3 (or even from one EV3 to another), good luck with that! leJOS (on the NXT) has had this feature from the very early days, but it is very hard to do well and adds considerably to the burden of testing and support. Even when it works very well programs will still often work differently due to the latency and jitter involved in the various connections, not to mention the different thread scheduling algorithms used. Even with very fast networks, or connections getting things like PID loops to work well with remote sensors and motors is not easy. As an example on the NXT it was pretty easy to guarantee that code in a particular thread would run regularly say every 5mS, doing that on a typical desktop computer that may only have a scheduler that works in 20mS units and which has hundreds of other tasks vying for the cpu is not easy!
https://raw.github.com/mindboards/ev3so ... pedata.rcf
The time column shows how many mS there are between data updates. So the old Lego light sensor produces data every 10mS while the new IR proximity sensor produces it every 1100mS. I have no idea how accurate these figures are but they probably give you a rough idea of the real world data rates, or at least how the Lego folks see them being used.
On the topic of creating programs that run on the PC and talk to sensors or actuators attached to the EV3 (or even from one EV3 to another), good luck with that! leJOS (on the NXT) has had this feature from the very early days, but it is very hard to do well and adds considerably to the burden of testing and support. Even when it works very well programs will still often work differently due to the latency and jitter involved in the various connections, not to mention the different thread scheduling algorithms used. Even with very fast networks, or connections getting things like PID loops to work well with remote sensors and motors is not easy. As an example on the NXT it was pretty easy to guarantee that code in a particular thread would run regularly say every 5mS, doing that on a typical desktop computer that may only have a scheduler that works in 20mS units and which has hundreds of other tasks vying for the cpu is not easy!
Re: Wishlist for C for EV3 (EVC, EV3-C)
...but imagine that I will probably have not only lots of sensors at each sensor port but also for data transmitting computational (calculation) results might have to be transfered there and back...
aaah ... yes, I just discoverd when reading your post again...:
PID loops for motor controlling and real-time encoder polling for odometric data processing are good examples !
aaah ... yes, I just discoverd when reading your post again...:
PID loops for motor controlling and real-time encoder polling for odometric data processing are good examples !
Re: Wishlist for C for EV3 (EVC, EV3-C)
for future releases of EV3-C beyond initial alpha versions it would be wishful if a few requests and proposals for changes could be considered:
1) the lms-api folder might be renamed to EV3C-API to make clear that it consists just ev3 C files and no, e.g., NXT files.
2) The content of the C api folder should be automatically copied into he BCC system program folder (e.g., c:\programs\Bricxcc\EV3C-API\ by the installation routine.
3) it's already quite complex but still reasonable for home programers to include several library files into each new program at the top like , e.g.,
But on the long run IMO it's overelaborate to expect home programmers additionally to dive down into the internal API structures and API file organisation like having to search through any *.c helper files and then co-involve them additionally by a project manager.
IMO the "ev3_xxxxxxxx.h" files should be organized internally in a way that #including a header file will implicitely include all second level and third level library files by itself.
4) Maybe in future the already existing
ev3_constants.h, ev3_command.h, ev3_button.h, ev3_timer.h, ev3_lcd.h, ev3_sound.h
could be even integrated into 1 single "ev3_stdlib.h" or so to make the top #include list even a little shorter and more convenient.
1) the lms-api folder might be renamed to EV3C-API to make clear that it consists just ev3 C files and no, e.g., NXT files.
2) The content of the C api folder should be automatically copied into he BCC system program folder (e.g., c:\programs\Bricxcc\EV3C-API\ by the installation routine.
3) it's already quite complex but still reasonable for home programers to include several library files into each new program at the top like , e.g.,
Code: Select all
#include <stdio.h>
#include <unistd.h>
#include "ev3_constants.h"
#include "ev3_command.h"
#include "ev3_button.h"
#include "ev3_timer.h"
#include "ev3_lcd.h"
#include "ev3_sound.h"
#include "ev3_output.h"
#include "ev3_sensors.h" // not yet existing
IMO the "ev3_xxxxxxxx.h" files should be organized internally in a way that #including a header file will implicitely include all second level and third level library files by itself.
4) Maybe in future the already existing
ev3_constants.h, ev3_command.h, ev3_button.h, ev3_timer.h, ev3_lcd.h, ev3_sound.h
could be even integrated into 1 single "ev3_stdlib.h" or so to make the top #include list even a little shorter and more convenient.
Re: Wishlist for C for EV3 (EVC, EV3-C)
it would be nice if given you have a file in the BCC/C editor and "save as" to a new file name that also the project manager file is copied and saved accordingly under the new name.
It also would be fine if you made some changes to the source code and compile that the recent changes would be followed, the same way as it works with NXC (currently for BCC/C you always have to save anew or the changes are disregarded).
And then last but not least, it would be very nice if we finally got a BCC/C CSLite sensor API for Lego and 3rd party sensors - and daisy chaining.
It also would be fine if you made some changes to the source code and compile that the recent changes would be followed, the same way as it works with NXC (currently for BCC/C you always have to save anew or the changes are disregarded).
And then last but not least, it would be very nice if we finally got a BCC/C CSLite sensor API for Lego and 3rd party sensors - and daisy chaining.
-
- Posts: 5
- Joined: 17 Dec 2013, 18:47
Re: Wishlist for C for EV3 (EVC, EV3-C)
Hello;
i have a EV3 education kit. I would like to program it in C/C++. Im not new to programming, also im not an expert, but im unable to make any programs because of unfamiliarity of syntax. I only succeeded to run sample program (writing on LCD). For NXT i have found a lots of tutorials for programmming in C (NXC). I understand that EV3 is new so there isnt yet tutorials. But, is there some functions/order list or something like that? Or can someone write an example on how to spin a motor for a few seconds?
Thanks in advance!
i have a EV3 education kit. I would like to program it in C/C++. Im not new to programming, also im not an expert, but im unable to make any programs because of unfamiliarity of syntax. I only succeeded to run sample program (writing on LCD). For NXT i have found a lots of tutorials for programmming in C (NXC). I understand that EV3 is new so there isnt yet tutorials. But, is there some functions/order list or something like that? Or can someone write an example on how to spin a motor for a few seconds?
Thanks in advance!
Re: Wishlist for C for EV3 (EVC, EV3-C)
Hello,
this is a sample programm. Run motor A and B for 1 second.
this is a sample programm. Run motor A and B for 1 second.
Code: Select all
#include "ev3_output.h"
#include "ev3_lcd.h"
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
OutputInit();
SetPower(OUT_AB, 75); //Set power for motor A and motor B to 75 percent
Fwd(OUT_AB); //Start motor A and B
Wait(1000);
Off(OUT_AB); //Brake motor A and B else Float(OUT_AB)
}
Re: Wishlist for C for EV3 (EVC, EV3-C)
thanks for providing this code! :)
but for reasons of tutorials I would suggest to open a new thread, because this thread's topic is about how to improve BCC/C by additional features or by it's functionality!
but for reasons of tutorials I would suggest to open a new thread, because this thread's topic is about how to improve BCC/C by additional features or by it's functionality!
Who is online
Users browsing this forum: No registered users and 8 guests