wishlist for NXC

Discussion specific to NXT-G, NXC, NBC, RobotC, Lejos, and more.
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe » 03 Aug 2012, 11:45

hi John,
would you like to include

Code: Select all

const float FLT_MAX=1E+37; 
const float NEG_FLT_MAX=-1E+37;
const float FLT_MIN=1E-37; 
const float NEG_FLT_MIN=-1E-37;
into the NXT libs?

HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe » 15 Aug 2012, 18:40

doc-helmut wrote:hi John,
would you like to include

Code: Select all

const float FLT_MAX=1E+37; 
const float NEG_FLT_MAX=-1E+37;
const float FLT_MIN=1E-37; 
const float NEG_FLT_MIN=-1E-37;
into the NXT libs?
thank you!

HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe » 15 Aug 2012, 18:43

John,
would it be much effort to make for *.h the same txt highlighting available as for *.nxc?

mattallen37
Posts: 1818
Joined: 02 Oct 2010, 02:19
Location: Michigan USA
Contact:

Re: wishlist for NXC

Post by mattallen37 » 15 Aug 2012, 19:03

Certainly not a solution for syntax highlighting of header files in BCC, but you could try using a different IDE (such as Programmer's Notepad).
Matt
http://mattallen37.wordpress.com/

I'm all for gun control... that's why I use both hands when shooting ;)

HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe » 15 Aug 2012, 19:12

I'd like to keep using BCC because of it's features (like, e.g., NXT screen, fw download, direct control, and many others) which I'm using very often.

mattallen37
Posts: 1818
Joined: 02 Oct 2010, 02:19
Location: Michigan USA
Contact:

Re: wishlist for NXC

Post by mattallen37 » 15 Aug 2012, 19:18

I don't mean ditch BCC, just use both (BCC for .nxc files and NXT programming, and pn for editing .h files).

Otherwise, if the .h files are NXC header files, leave the extension .nxc (just don't try to compile them directly while editing).
Matt
http://mattallen37.wordpress.com/

I'm all for gun control... that's why I use both hands when shooting ;)

HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe » 16 Aug 2012, 12:49

no, I want to stay at just 1 IDE and I want to distinguish header files from programs by it's extensions as it's common in C.

so again my question to John:


John,
would it be much effort to make for *.h the same txt highlighting available as for *.nxc?

mattallen37
Posts: 1818
Joined: 02 Oct 2010, 02:19
Location: Michigan USA
Contact:

Re: wishlist for NXC

Post by mattallen37 » 21 Aug 2012, 16:04

I'd really like a more robust I2C structure, with better error handling.

Currently, a communications error with I2C sensor APIs will crash the program, and an I2C communications error with fast I2C will lock up the brick. If I use my own device drivers (with default I2C), I can implement error handling so that the program doesn't crash. However, fast I2C errors lock up the brick before the function can return to let me know there was an error.

I would secondarily like clock stretching to be supported (so that at an I2C request, the slave can take a reading and then return it).
Matt
http://mattallen37.wordpress.com/

I'm all for gun control... that's why I use both hands when shooting ;)

afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: wishlist for NXC

Post by afanofosc » 28 Aug 2012, 21:37

The code I used for fast I2C was intended to support clock stretching to the same extent that leJOS support for fast I2C supported clock stretching.

I'm not sure what you mean about I2C errors crashing a program. I think that you mean that my I2C API functions are not avoiding cases where it reads past the end of a response array which causes a File Error abort. Is that what you mean? I can certainly spruce up those API functions so that they check the return length and bail out before trying to read from the buffer.

If you could be more specific about the brick crashing issues you are experiencing with Fast I2C, such as steps to reproduce, etc... I would be grateful. I'll work on solving any of those that I can if I can reproduce them and figure out what the root cause is.

John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/

mattallen37
Posts: 1818
Joined: 02 Oct 2010, 02:19
Location: Michigan USA
Contact:

Re: wishlist for NXC

Post by mattallen37 » 28 Aug 2012, 23:03

I haven't tried clock stretching with fast mode, I guess I'll have to give it a try.

In Re. to your API, that is exactly what I would like ;)

If you try an I2C transaction with fast mode and a slave isn't connected, then the NXT just becomes totally unresponsive, and requires a hard restart (such as removing the battery pack and replacing it).

I remember hearing that you disabled time-slicing (round-robin task management) during fast I2C, so that the transaction can be as fast as possible. You warned that everything (e.g. FW APR motor control) would come to a halt until the I2C transaction had completed. I assume that what I want is a timeout (maybe even user adjustable?), so that if the slave is unresponsive, the I2C function will return an error, and allow operations to continue (re-enable time-slicing).

If you run this code with no sensor attached, the NXT will crash (blank screen, soft ticking, no button response).

Code: Select all

byte data[] = {0x02, 0x42};

task main(){
  SetSensorLowspeed(S1);
  SetI2COptions(S1, I2C_OPTION_FAST);
  I2CWrite(S1, 0, data);
}
But if you connect a pullup from SCL to Vcc, then the program finishes successfully (or if you plug in a sensor with a pullup). No pullup on SCL would appear the same as a slave holding SCL low (clock stretching).

This seems to point to the clock-stretching feature. I think it needs a timeout (user-adjustable).
Matt
http://mattallen37.wordpress.com/

I'm all for gun control... that's why I use both hands when shooting ;)

Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests