wishlist for NXC

[HaWe]

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]

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]

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

[mattallen37]

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

[HaWe]

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]

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

[HaWe]

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]

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

[afanofosc]

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

[mattallen37]

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