NXC or RobotC?

[equals_jsp]

I'm relatively new to NXT, but not to programming. I quickly got frustrated with NXT-G (spent way too much time trying to get the graphics formatting vs. coding) so decided to give RobotC a try. So far I'm relatively happy but have hit a series of quirks that have me considering trying NXC; I have a fair amount of time invested into RobotC at this point rather than change one quirk for another I thought I'd ask the community for their opinions based on my perceived requirements and my perceived strengths/weaknesses of RobotC vs. what I've read about NXC, any comments on the thoughts below would be very welcome:

1) 3rd party sensor support: I expect to be using some third-party sensors/servos, nothing crazy, things already used by other NXT programmers, but I don't want to run into 'can't use that hardware with (NXT|RobotC). RobotC seems to have the edge here, I see regular updates for third-party drivers for RobotC but not so much talk about drivers for NXC.

2) Decent Debugger: In RobotC I've already had some minor issues with the debugger. It (or more correctly, I) can't tell the difference between similarly named variables across functions in the debugger variable screen. Is NXC's any better? Anything that sets either one apart positively or negatively?

3) Fewer Quirks: I understand that these are personal, but I'm curious as to how people feel NXC stacks up:
* I wasted a lot of time trying to 'inline' several of my functions based upon compiler warnings that they should be 'inline' only to find out after searching forums that 'inline' is not supported. I was pretty upset at being told to implement something that doesn't exist in the software.
* I looked heavily for mutex/semaphore support which has been stated as 'coming soon' since 2008, but I can't find any reference that it ever got implemented. It feels sloppy doing it with HogCPU but more disconcerting that after two years it with multiple statements that it would be available shortly that it appears that it still isn't there. If it is there, I can't find it in the docs. I'm running the latest Beta.
* Can't seem to find a way to open multiple views of the same file. I can open multiple files in tabs, but not multiple copies of the same file. I'm tired of scrolling up/down to see what I named a function or variable.

4) Bluetooth/Wired connectivity. In general, I've been happy with RobotC here, love that I can leave my cable in the box. Does NXC support this as well?

5) Joystick/Remote Control. I really liked NXT-G's remote control dialog. It was great for re-aligning the robot between tests, it is probably the one thing I miss from NXT-G and I can't find an equivalent in RobotC, does NXC do this?

6) Speed. I've read that RobotC's firmware is faster. Is this noticeable? If so, under what circumstances? My current 'bot uses active sonar sweeping while moving to acquire and follow a target; I've already had some issues with the drive/turn task not picking up an update from the scanner task (re: mutex/semaphore mention above) that I'm working on, I don't know if I'm hitting speed limits on processing (the issue is most likely my code) but I would like to know relatively if there are significant differences in speed differences between the two.

Again, thanks for any comments. I did look for a review between the two but the only thing I could find was from 2007.

[mightor]

JSP,

1) 3rd party sensor support: I expect to be using some third-party sensors/servos, nothing crazy, things already used by other NXT programmers, but I don't want to run into 'can't use that hardware with (NXT|RobotC). RobotC seems to have the edge here, I see regular updates for third-party drivers for RobotC but not so much talk about drivers for NXC.

NXC has a lot of support for 3rd party sensors already built-in. You may notice that some of the functions in my suite are closely named after the ones in NXC. That's not an accident, I liked the naming standard used in NXC, so emulated it.

2) Decent Debugger: In RobotC I've already had some minor issues with the debugger. It (or more correctly, I) can't tell the difference between similarly named variables across functions in the debugger variable screen. Is NXC's any better? Anything that sets either one apart positively or negatively?

This is a serious issue for me, too. I get around it by using better named variables, but you're right, there should be a way to visually distinguish between them.

I wasted a lot of time trying to 'inline' several of my functions based upon compiler warnings that they should be 'inline' only to find out after searching forums that 'inline' is not supported. I was pretty upset at being told to implement something that doesn't exist in the software.

I've already pointed that out to the devs, they have not removed that stupid error message yet. It's confusing.

I looked heavily for mutex/semaphore support which has been stated as 'coming soon' since 2008, but I can't find any reference that it ever got implemented. It feels sloppy doing it with HogCPU but more disconcerting that after two years it with multiple statements that it would be available shortly that it appears that it still isn't there. If it is there, I can't find it in the docs. I'm running the latest Beta.

It isn't there. You could use the method here: http://www.robotc.net/forums/viewtopic.php?p=492#492 and then you wouldn't need hogCPU/releaseCPU. Perhaps I will make this available in the next release of my driver suite. Please take note that a lot of opcodes in ROBOTC are atomic in nature, much more so than the standard firmware, this reduces (but does not eliminate) the need for things like mutexes.

Can't seem to find a way to open multiple views of the same file. I can open multiple files in tabs, but not multiple copies of the same file. I'm tired of scrolling up/down to see what I named a function or variable.

You could use the bookmarks feature for that. That's what I use.

4) Bluetooth/Wired connectivity. In general, I've been happy with RobotC here, love that I can leave my cable in the box. Does NXC support this as well?

Yes, it does.

6) Speed. I've read that RobotC's firmware is faster. Is this noticeable? If so, under what circumstances? My current 'bot uses active sonar sweeping while moving to acquire and follow a target; I've already had some issues with the drive/turn task not picking up an update from the scanner task (re: mutex/semaphore mention above) that I'm working on, I don't know if I'm hitting speed limits on processing (the issue is most likely my code) but I would like to know relatively if there are significant differences in speed differences between the two.

Programming technique can make up for a lot. It is hard to see why an update wouldn't have gone through. I highly doubt the firmware would miss a poll from the sensor, those internal threads have a much higher priority than anything you, as a user, can make. Without the code, it's hard to say why it would do that.

Regards,
Xander

[hassenplug]

2) Decent Debugger: In RobotC I've already had some minor issues with the debugger. It (or more correctly, I) can't tell the difference between similarly named variables across functions in the debugger variable screen. Is NXC's any better? Anything that sets either one apart positively or negatively?

I get stuck comparing them both to MS Visual Studio, and for me, they both fall far short. Personally, I would not suggest one over the other in this area.

6) Speed. I've read that RobotC's firmware is faster. Is this noticeable?

This is one place where there IS a huge difference. The RobotC firmware is many times faster. Of course, that doesn't mean a robot moving across the floor will drive any faster.

NXC is strongly tied to the standard firmware. This is good and bad. It means NXC is limited by things designed into that firmware, but also does not require you to change firmware (allowing you to write programs in both NXT-G and NXC at the same time).

RobotC uses it's own (faster) firmware, which makes it possible to do things not available in the standard firmware (like communicate with other devices via bluetooth). This would be a greater advantage, if the RobotC developers were still actively working on RobotC (as you've pointed out, they aren't).

My suggestion: Stick with what you started with. You already understand some of the quirks. I do believe you'd be trading one set of quirks for another.

Steve

[mightor]

This would be a greater advantage, if the RobotC developers were still actively working on RobotC (as you've pointed out, they aren't).

They're still developing it, they just chose not to implement mutexes. ROBOTC is currently being ported to Arduino.

- Xander

[afanofosc]

My 2 cents.

NXC has plenty of quirks and limitations as does BricxCC. With the enhanced NBC/NXC firmware, which is fully compatible with the standard NXT firmware, you get a lot of extra power - some of which even RobotC doesn't have. But there are, of course, still things you can do with RobotC that are harder to do if not impossible (not sure about that?) with NXC.

Every 3rd party device can be used with NXC but not all of them have built-in API functions out of the box. I have a list of devices I need to get around to adding functions for, such as the HiTechnic tetrix controllers. If you decided to start using NXC you could easily roll your own functions for any device that doesn't already have an official NXC API function.

In BricxCC you can watch variable values but the debug features are not as complete as what you get with RobotC. I have started implementing program pause and single step support and break points but that still has a long way to go to be fully featured and iron clad. These kind of features require the enhanced NBC/NXC firmware since the standard firmware has no support at all for pausing/stepping through a running program.

BricxCC has several tool windows which aid you in programming/interacting with an NXT robot. The NXT Screen lets you view on your PC what is drawn to the NXT LCD (either the normal or the popup screens) and grab screen captures or movies from the LCD. The NXT Explorer lets you drag and drop files between your PC and your NXT as well as deleting/defragmenting/running programs/stopping programs/playing sounds, etc... The Brick Joystick tool lets you control the NXT motors via mouse, keypad, or joystick/gamepad. The joystick buttons can be programmed to run Pascal scripts on the PC which control the NXT via direct commands. The Pascal scripts can be edited via the IDE and run with pause and single stepping in the IDE editor window. The Remote tool gives you fine-tuned control over motors with user-definable program button actions (right click to set which program the button launches). The Direct Control tool window also lets you turn motors on (in either direction) or off and control the power level. Additional tool windows in BricxCC include a Diagnostics tool which shows information about the NXT including the battery level, firmware version, free flash memory, running program name, NXT name (editable via double click), and bluetooth mac address. The Brick Piano lets you write simple melodies which can be saved in several different formats and replayed on the NXT. The Send Message tool lets you send any kind of message to any mailbox on the NXT. The MIDI and Sound conversion tools let you create NXT Melody files (RMD) or NXT Sound (RSO) files for playing on your NXT via the PlayFile API function. And there are 3 different ways you can watch variables in a running program: Watching the Brick, Configurable Watch, and the new not yet released NXT Watch List tool. Here's a preview of the new NXT Watch List tool:

nxtwatch.JPG (41.94 KiB) Viewed 10392 times

addwatch.JPG (22.2 KiB) Viewed 10392 times

All of the tool windows are available on Mac OSX and Linux platforms in addition to Windows (the NXT Watch List is coming soon).

The BricxCC IDE includes extensive context sensitive help for NXC and the NXC API along with a code explorer tool, user-configurable templates and hotkey macros, recordable/playable editor macro scripts, grep search, procedure list, code completion, parameter completion, and so forth.

None of this is perfect, of course, and I am very much open to suggestions for changes/improvements/new features. The compiler is similarly not perfect and I try to fix bugs as fast as they are found and add new abilities as fast as I can figure out how to add them without breaking things.

If you can forgive the quirks and imperfections then I think NXC and BricxCC is a great choice for programming your NXT.

John Hansen

[kvols]

Hi there.

I did a fair bit of programming in NXC for the obvious reasons: The firmware is compatible with the original, meaning that you can use the brick as a completely standard brick in most respects.

But after some time, and influenced by a colleague, I decided to give Lejos a try. It has some advantages over NXC and RobotC:

- It's a real object-oriented language, with encapsulation, objects etc.
- You use (almost) real Java when programming, including recursion etc.
- You can use Eclipse - a highly efficient and professional programming environment
- You can create real Java classes, that can be unit tested separately before integrating them in you robot
- It's a lot faster than NXC (about 12-13 times on arrays and 16 times on ints)
- Easy-to-use I2C
- Real dynamic memory management.

It also has some disadvantages:

- It's a real object-oriented language, with encapsulation, objects etc.
- You'll need to learn some Java, though it's somewhat similar to C/C++
- It's not a standard brick anymore
- The code takes up a bit more space than NXC. I'm not sure how much.

Another 5 cents...

[equals_jsp]

Thank you all for your great commentary, this was exactly the type of pro/cons that I was looking for. At this point I'm going to give NXC with the enhanced firmware a try, hopefully porting over my RobotC code will be straightforward. Perhaps in the future once I'm more familiar with the NXT hardware and how it behaves, I'll give Lejos a try as well; but while I've certainly coded and understand OO, I still think more naturally in C.

[nxt-ai]

Another alternative could be nxtOSEK as (if I read correctly) it runs C programs on a real-time kernel. I don't really know as it runs on windows not Macs, the compiler that is.
You might be interested in the chart at http://www.teamhassenplug.org/NXT/NXTSoftware.html as that's how I decided which to use.