NXT enhanced firmware

[mattallen37]

fast I2C communication

How to use this, i have try to find some help in the help of bricxcc, and didn't find.
The US sensor seems to be the only one which didn't support the fast i2c routines (if i trust lejos forums), is it true? and will the direct sensor access routines be able to handle fast coms (how???) or will i have to address them directly to enable fast i2c coms???

Set it up as LowSpeed, and then set the I2C options to fast, like this:

Code: Select all

SetSensorLowspeed(S1);
SetI2COptions(S1, I2C_OPTION_FAST);

The Lego US sensor certainly won't support the high-speed, but any other device I have tried seems to work fine.

If by direct sensor access routines, you mean like ReadSensorMSPlayStation or ReadSensorHTAccel, they seem to work just fine.

RS485 baud/mode/uartmode setting (i.e., 9600, N81, RS232)

Is it to say that i can configure the 4th sensor port to handle RS232 coms? How to do that?
How to use this feature? Is there some new RS485 commands to ease some RS485 com?

Yes and no. The NXT processor is set up to be able to run either RS485 or RS232, but the NXT PCB HW is set up for RS485. Unless you hack the NXT PCB, I don't think it's currently possible to use RS232 (although a FW mod might allow it, but even then, I would personally rather TTL UART).

Sorry, I don't currently have access to the specifics of how to set up RS485 in other modes.

low level input port digital pin manipulation

How to use that very interesting feature??? What are the possibilities opened by this?

Here is how to set up the port for user control of the IO pins, and how to read the state of them.

Code: Select all

SetSensorType(S1, SENSOR_TYPE_CUSTOM);
byte x = SensorDigiPinsStatus(S1);

To set the state of them, I think you use:

Code: Select all

SetSensorDigiPinsDirection(S1, state);

Where state is a byte. IIRC, just the two lowest bits are used, and they set the IO state for the two pins (LOW or high impedance).

DATA_MODE_NXT over RS485 so that the firmware automatically handles direct and system commands sent via RS485

How to use that, to make a zombified NXT (if i understand well )!

I don't know on this, but I think it's a way of letting another NXT have direct control, and mailboxes (like with BT and USB).

Another question/request is about the temperature sensors, the RCX model was supported by old standard firmware, until new NXT one was supported in 1.2x.
How to adress the RXC one, with the enhanced firmware 1.31, and is there any direct procedure to address the NXT temp sensor, (i already have the I2C low level stuff)...

John will have to answer this.

[pbenco]

Dear mattallen37
Thank you very much, i will try all your tips this week-end, to get familiar with. You will get credits for your help!
Best regards
Ben

[afanofosc]

fast I2C communication

How to use this, i have try to find some help in the help of bricxcc, and didn't find.
The US sensor seems to be the only one which didn't support the fast i2c routines (if i trust lejos forums), is it true? and will the direct sensor access routines be able to handle fast coms (how???) or will i have to address them directly to enable fast i2c coms???

Set it up as LowSpeed, and then set the I2C options to fast, like this:

Code: Select all

SetSensorLowspeed(S1);
SetI2COptions(S1, I2C_OPTION_FAST);

The Lego US sensor certainly won't support the high-speed, but any other device I have tried seems to work fine.
If by direct sensor access routines, you mean like ReadSensorMSPlayStation or ReadSensorHTAccel, they seem to work just fine.

I have not extensively tested the Fast I2C support but I would love to hear back from more people than just Matt what they experience when they try reading sensor values either via low level API calls or via the existing high level API functions for the various I2C devices for which I have created standard API functions. As Matt indicates, you just need to tell the firmware via my new I2COptions field in the Lowspeed module's IOMap structure whether a port should use fast mode or not. I2C_OPTION_STANDARD would be the default value for this field for each port.

You should be aware that using fast I2C mode will block other modules from executing during the duration of the I2C transaction, which could be much longer than 1ms. The NXT firmware is written in a way that each module expects that it will get a chance to do its thing once every 1ms so you should use fast I2C with caution and expect that it might cause other modules to misbehave. For example, the motor control routines probably will not correctly synchronize your motors if you make the Output module frequently wait for several milliseconds before it can update the motor state. I'm not saying "don't use Fast I2C mode". I'm saying "understand the pros and cons and make a decision that after experimentation proves to be successful in your situation".

RS485 baud/mode/uartmode setting (i.e., 9600, N81, RS232)

Is it to say that i can configure the 4th sensor port to handle RS232 coms? How to do that?
How to use this feature? Is there some new RS485 commands to ease some RS485 com?

Yes and no. The NXT processor is set up to be able to run either RS485 or RS232, but the NXT PCB HW is set up for RS485. Unless you hack the NXT PCB, I don't think it's currently possible to use RS232 (although a FW mod might allow it, but even then, I would personally rather TTL UART).
Sorry, I don't currently have access to the specifics of how to set up RS485 in other modes.

I am not a hardware guy so when I saw in documents that I found online that you could configure the AT91 UART in "normal" (aka RS232) or RS485 modes (plus several others) I made the assumption that if I exposed these options to users that it would just work. I did not know that there were obstacles between the AT91 chip and the port 4 pins that would make these settings useless. So I will remove that option from the enhanced NBC/NXC firmware. You can, at least, set the baud rate and the mode. I gather that the ST485C chip that is between the AT91 and port 4 will definitely prevent anything except RS485 mode from working.

You configure baud and mode via RS485Uart().

http://bricxcc.sourceforge.net/nbc/nxcd ... 1c9bb.html

See all the RS485* functions for the preferred way to communicate over Port 4 via RS485. Also UseRS485() which configures S4 as SENSOR_TYPE_HIGHSPEED.

low level input port digital pin manipulation

How to use that very interesting feature??? What are the possibilities opened by this?

Here is how to set up the port for user control of the IO pins, and how to read the state of them.

Code: Select all

SetSensorType(S1, SENSOR_TYPE_CUSTOM);
byte x = SensorDigiPinsStatus(S1);

To set the state of them, I think you use:

Code: Select all

SetSensorDigiPinsDirection(S1, state);

Where state is a byte. IIRC, just the two lowest bits are used, and they set the IO state for the two pins (LOW or high impedance).

This refers to a new capability that is not what Matt is describing. It does not work perfectly since timing greatly depends on the speed with which the VM executes your NXC code but you can very quickly turn on and off the digital pins (i.e., sub millisecond speeds) using the new SysInputPinFunction system call function.

http://bricxcc.sourceforge.net/nbc/nxcd ... e7320db6bb
http://bricxcc.sourceforge.net/nbc/nxcd ... e.html#a13
http://bricxcc.sourceforge.net/nbc/nxcd ... _type.html

The SensorDigiPins* functions all rely on changing an Input module IOMap field which would not actually do anything until at least 1ms later when the Input module got around to noticing the field's new value and then updating the pin state for the specified port.

This new system call function immediately modifies the pin state and gives you the ability to request a micro-second wait time. The problem here is that the actual amount of time that occurs between setting a pin high, waiting, and setting a pin low depends on how long it takes to execute the syscall opcode, how long it takes to execute any code between two syscall opcodes, how long it takes when the VM in the Command module periodically yields to other modules, etc... But I would love to see more people experiment with this capability to see if they can reliably send digital signals between the NXT and some custom device attached to any of the input ports.

DATA_MODE_NXT over RS485 so that the firmware automatically handles direct and system commands sent via RS485

How to use that, to make a zombified NXT (if i understand well )!

I don't know on this, but I think it's a way of letting another NXT have direct control, and mailboxes (like with BT and USB).

Every direct and system command that you can send between two NXTs via Bluetooth can also be sent between two NXTs via RS485 if you configure both NXTs with their HSDataMode to be DATA_MODE_NXT rather than the default value of DATA_MODE_RAW. SetHSDataMode(DATA_MODE_NXT);

http://bricxcc.sourceforge.net/nbc/nxcd ... le.html#a5

These direct and system command API functions all start with "Remote". So search the online NXC help for Remote. You find a list of system command functions and direct command functions.

http://bricxcc.sourceforge.net/nbc/nxcd ... tions.html
http://bricxcc.sourceforge.net/nbc/nxcd ... tions.html

To send a DC or SC via Bluetooth you use a connection number between 0 and 3: CONN_BT0..CONN_BT3. To send a DC or SC via RS485 you use a connection number >= 4: CONN_HS4

http://bricxcc.sourceforge.net/nbc/nxcd ... tants.html

You can also set your NXTs HSAddress to something other than HS_ADDRESS_ALL (0) if you want to use multiple NXTs all connected via RS485 and send a DC or SC to a specific NXT. Currently the response from an NXT is always sent to the ALL (broadcast) address. If there is sufficient interest I could change this in a future firmware revision so that the sender of the message can specify what address to send the response to (i.e,. prepend the DC an SC with 2 bytes - one for the destination address and one for the response or sender address).

There is also a new system call function called SysReadLastResponse which can be used to manually read the last SC or DC response buffer received either via Bluetooth or RS485. With the standard firmware the only response that is not discarded is the response to the MessageRead direct command. With the enhanced firmware all DC and SC responses are kept in the LastResponse buffer (which does not have a queue, currently) but for DC and SC commands where it makes sense the Remote* API function will automatically process the response buffer and return the value directly to the caller of the API function. See, for example, all the RemoteGet* functions, such as RemoteGetOutputStatus.

http://bricxcc.sourceforge.net/nbc/nxcd ... fbd71d7331

So, yes, kind of like turning an NXT into a zombie via either Bluetooth or RS485.

Another question/request is about the temperature sensors, the RCX model was supported by old standard firmware, until new NXT one was supported in 1.2x.
How to adress the RXC one, with the enhanced firmware 1.31, and is there any direct procedure to address the NXT temp sensor, (i already have the I2C low level stuff)...

John will have to answer this.

The RCX temperature sensor can be read via SensorValue(port) or SENSOR_n (i.e., SENSOR_1..SENSOR_4) when you have your port configured in either CELCIUS or FAHRENHEIT type/mode. See SetSensor(port, combined_type_mode_constants).

http://bricxcc.sourceforge.net/nbc/nxcd ... f4efbc028b

Use SENSOR_CELCIUS or SENSOR_FAHRENHEIT with SetSensor() if you want to use the old RCX temperature sensor with your NXT.

To use the new NXT temperature sensor, which as you know is an I2C device, you use the new SetSensorTemperature() API function and then read its value with SensorTemperature().

John Hansen

[pbenco]

Dear John

Thank you very much taking time to make such a very complete answer!
Lot of experimentation time now, the week end is shortening in a snap.
Be sure i will report my results here.
Once again thank you!
Ben
P.S. for RS232 interface, please wait as there are some solutions laying around to provide rs232 interface with simple components, as the full version with a max232 chip

or the well known transistor version:

or
or
or

[mattallen37]

...You should be aware that using fast I2C mode will block other modules from executing during the duration of the I2C transaction, which could be much longer than 1ms. The NXT firmware is written in a way that each module expects that it will get a chance to do its thing once every 1ms so you should use fast I2C with caution and expect that it might cause other modules to misbehave. For example, the motor control routines probably will not correctly synchronize your motors if you make the Output module frequently wait for several milliseconds before it can update the motor state. I'm not saying "don't use Fast I2C mode". I'm saying "understand the pros and cons and make a decision that after experimentation proves to be successful in your situation".

Does USB still work, or will it pause during the few ms it takes to do an I2C transaction? Would the communication with the computer get corrupted and need to be reset/restarted? What about BT? Will the UART (DMA?) still work with BT and RS485 for receiving messages?

I am not a hardware guy so when I saw in documents that I found online that you could configure the AT91 UART in "normal" (aka RS232) or RS485 modes (plus several others) I made the assumption that if I exposed these options to users that it would just work. I did not know that there were obstacles between the AT91 chip and the port 4 pins that would make these settings useless. So I will remove that option from the enhanced NBC/NXC firmware. You can, at least, set the baud rate and the mode. I gather that the ST485C chip that is between the AT91 and port 4 will definitely prevent anything except RS485 mode from working...

Actually, please keep the RS232 available. Even if it requires HW hacking, I would like for you to keep it... unless it's a resource issue.

This refers to a new capability that is not what Matt is describing. It does not work perfectly since timing greatly depends on the speed with which the VM executes your NXC code but you can very quickly turn on and off the digital pins (i.e., sub millisecond speeds) using the new SysInputPinFunction system call function.

http://bricxcc.sourceforge.net/nbc/nxcd ... e7320db6bb
http://bricxcc.sourceforge.net/nbc/nxcd ... e.html#a13
http://bricxcc.sourceforge.net/nbc/nxcd ... _type.html

The SensorDigiPins* functions all rely on changing an Input module IOMap field which would not actually do anything until at least 1ms later when the Input module got around to noticing the field's new value and then updating the pin state for the specified port.

This new system call function immediately modifies the pin state and gives you the ability to request a micro-second wait time. The problem here is that the actual amount of time that occurs between setting a pin high, waiting, and setting a pin low depends on how long it takes to execute the syscall opcode, how long it takes to execute any code between two syscall opcodes, how long it takes when the VM in the Command module periodically yields to other modules, etc... But I would love to see more people experiment with this capability to see if they can reliably send digital signals between the NXT and some custom device attached to any of the input ports.

Thanks for the information.

You mentioned that the fast I2C doesn't allow the FW to go on with giving time to other modules during a transaction. Can you allow user access to that ability? It would allow for very precise timing control for things like bit-banged UART (now that the IO pins can be controlled instantly). I know that the user would have to be very careful not to hang the NXT, and would have to give the FW permission to go on again before anything else would work. I also know that the ARM needs to talk with the AVR at least every 5 minutes in order to stay powered.

[mattallen37]

...P.S. for RS232 interface, please wait as there are some solutions laying around to provide rs232 interface with simple components, as the full version with a max232 chip

Well, the RS485 that the NXT uses is half-duplex. It could be converted into TTL UART (max485, or other RS485 transceiver) and RS232 using an additional max232 (or other converted), but it's still limited to half-duplex (only one of the devices can talk at a time). Most serial devices are accustom to having full duplex available.

[pbenco]

Dear mattalen37

the RS485 that the NXT uses is half-duplex.

the output of the rs485 is half duplex, Yes, but the input of the chip not, so it remains a little hope to find a way doing real rs232 with minimal hack of the NXT board..., perhaps an external dual switch to drive RX and TX to the "right" interface RX/TX .
Don't know yet if it's possible, but i have to investigate deeeper...
Bye for now, 2:17 am, it's time to sleep!!!
Ben

[pbenco]

Dear afanofosc and mattalen37

How to use SetBTDataMode and DATA_MODE_GPS to get ride of the GPS routines from Antonio Scarfone and Robokalle? (i guess this is related )????

I really want to improve my own routines to extract data from NMEA GPS signals received through BT http://freelug.org/spip.php?page=articl ... C%2520code
Best regards
Ben

[afanofosc]

At the moment I have not yet implemented firmware-level support for the GPS data mode. It's just not been high enough on the priority list yet.

John Hansen

[peter-cocteau]

Hi John,

one more time you made a good work.
What about Fast I2C? it seems, we cannot access this function with NXT-G only, isn't it ?

Peter.