Mindboards

ok so then I'll let me be surpised

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

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).

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).

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.

= Xander

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!

...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 !

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.

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.

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!

Hello,

this is a sample programm. Run motor A and B for 1 second.

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!