Can you set up a thread that posts plans, progress and maybe the eta of RobotC for EV3?

+1

Aye... I understand you've had some difficulties aquiring hardware, but it has been six months since we last had any news.

Hardware has never been the issue - it's the firmware and software.

Our current progress is:
- The ROBOTC VM is not running on the EV3 yet, but we're close
- We're updating the ROBOTC IDE to support EV3 and also use the USB Port Communication to detect hardware - we've made good progress with this so far.
- The initial ROBOTC VM will be an add-on to the existing LEGO implementation. There's too much hacking and slashing to do to solve all of the issues that the EV3 has for the first release - not to mention we would have to recreate everything like the GUI and such.
- Initial release will more than likely be USB only and support out of box issues.
- We're actively working with NI to have a common solution for both ROBOTC and LabVIEW to exist on the same brain (but not run at the same time)
- Initial implementation will be on par with the NXT in terms of memory, variable space, and performance... it'll take a much bigger overhaul to be able to really take advantage of the gobs of memory on the EV3 (we've never had this much RAM/Flash before).

We're hoping to have something to release and workable within a month's time in a VERY BETA form - moving from greenfield/embedded systems to a Linux runtime is proving more complex than expected, especially when fitting into an existing environment such as the EV3 - not to mention squeezing everything in with other platforms and features being developed at the same time.

That's the update. I wish I had more for you guys, but that's where we are.

what is hardware detection supposed to do?
Is it for daisy chaining purposes?
Anyway, all hardware could be configured manually, of course we already know what kind of motors and sensors we have attached to which ports of master and slaves.



Do I understand you correctly that the EV3 will not be much more powerful than currently the NXT when running RobotC?
But hopefully this restriction for performance and memory is only for the very first test release?

Finally, too poor computational power and too poor memory for code and variables was always an issue for the NXT...

That's the intent. It'll be for the initial releases, but as the product matures, so will ROBOTC. Our goal is to utilize the full capabilities of the hardware, but I think you guys might want to see something released in 2014, right?

to be honest, I wouldn't need any EV3 which has no crucial advantages compared with the NXT, e.g., 100x memory, 10x performance, 4x daisy-chaining, and 64 bit arithmetics (double).

What do you mean by USB-only? Are you talking about communication being USB only? If that's in reference to Bluetooth, that's probably okay as long as USB Wifi dongle works. I think this is the minimum requirement for the FTC competition.

USB (slave) for PC-brick-communication (e.g., program download, online-debugging)
- or -
USB (master) for both 4x daisy-chaining like the Lego VM provides and USB-WiFi-sticks?

Many thanks for the answers (and the questions)!

...and you surely mean: for the additional missing answers in advance...?

Given that RobotC's largest group of users is likely FTC teams,
and given that FIRST is not likely to allow the use of software
compiled by anything other than RobotC in a competition, and
given that for the vast majority of teams, the performance of
the existing NXT brick is adequate, my personal reaction to
increased performance from an EV3 is "meh".

If that's what you want or need, then yeah, move to gcc
because you aren't likely bound by the FIRST rules, and you
are clearly more sophisticated than the other target market
for RobotC of people who need the simplest introduction to
getting a motor to turn.

I'd much rather see Robomatter putting resources into fixing
some of the project management issues inherent in RobotC,
my personal biggest pet peeve being the inability to put
pragmas in a header file for reuse among dozens of robot
unit tests. (And the standard model really isn't a suitable
substitute, especially given the requirement that you reboot
RobotC for changes to apply).

Followed a close second by the lack of multi-file project
support.

I'd love to see those two items fixed. It's hard to teach
my team members good software practices when RobotC
is lacking in some fundamental features that all modern
compilers and IDE's support.

FTC is surely one user group, but for those there is a specific subforum.
I am programming "free" projects, FTC rules are for me completely irrelevant.

if to someone the NXT performance is sufficient, he should stick to it.
The EV3 can provide more power, so he should also be able to work more powerful.

(the time I once was building bumper cars and line followers and wall followers is finally almost 30 years from now)

Overall, our goal is to support ALL of the functionality of the brain. We're not going to just pick and choose certain things - however, just like the community, we want to actually get something usable out of the door ASAP.

Few replies:
- Initial support will be in regards to USB direct communication. Bluetooth and Wifi to shortly follow (if not at first release). Download and debug will be eventually support over USB, Bluetooth and Wifi.
- Our plan is to support the daisy chaining ability of the EV3 via the USB cables. This will allow a master brain to control up to 3 slave brains inputs/outputs directly similar to the EV3 Graphical Software. This will probably work the same way the FTC system works (Motors A-D on brain 1, Motors E-H on brain 2, etc.)
- Yes: We plan on having #pragma header support. We committed to that in a previous thread.
- In regards to "projects"... it's something we've discussed previously, but many people really enjoy the ability to just fire up a single source file. This probably won't be a 4.0 feature, but something we could consider for 4.5+. I'd love to have another thread fired up on how you'd envision this working.

do you have plans if or when double precision fp arithmetics (64 bit) will be provided?