mattallen37 wrote:
pbenco wrote:
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".
mattallen37 wrote:
pbenco wrote: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.
mattallen37 wrote:
pbenco wrote: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.
mattallen37 wrote:
pbenco wrote: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.
mattallen37 wrote:
pbenco wrote: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
