Mindboards

I heard the enhanced NBC firmware is a lot better than the Lego one, while still compatible, however, when searching for documentation about it, they say "2D arrays", but the final word is "John Hansen knows".

First question: What is the canonical download location? BricxCC has a link, as well as Mindsensors, but just that. A direct link with little or no explanation.

I also found http://git.ni.fr.eu.org/?p=nxt-firmware.git which is called NXT Improved Firmware. Is it the same thing? Now we can say "Nicolas Schodet knows" as well.

The important question: What is the difference?

I'll list some things I found, add imaginary [citation needed] to all of them.

• 2D arrays
• Improved I2C comm.
• Absolute regulation
• Enhanced graphics

A thing I would find interesting is allocating memory at runtime, but I believe niether of the firmwares supports this? I did read arrays can grow and shrink.

Mindsensors did something with the FW, and claim to have made the I2C more robust (I didn't try it).
Nicolas Schodet added a PID controller to the FW to control the position of an NXT motor.

John Hansen has done many things to the FW (more-or-less tying in other people's improvements along the way) :

• Support 4D arrays (maybe bigger, I don't know).
• Added many array/string functions.
• Work on the I2C communication (and improved it greatly). Just to name a couple things, he fixed a bug so that you can read/write 16 bytes at a time (instead of 15), and made a fast mode (about 6 times the speed of the normal I2C).
• Added the Absolute Position Regulation that Nicolas Schodet came up with.
• Improve the LCD stuff, but I'm not sure what all he did with that.

Basically, John went through the different functions of the FW, and improved whatever he reasonably could. He also added many things by request. In order to use the extra functionality, you need to use NXC. He did all of that (and much more) while keeping the FW backwards compatible with NXT-G.

The difference is that you can do more stuff, and faster, with John's EFW, which is the reason that I only use his EFW (except when I use ROBOTC).

So is that git link their combined work? Because it has both their names in the log.

I'd rather trust a random git repo than a random binary file without even so much as a version number and a changelog.

My enhanced NBC/NXC firmware combines the work of Nicolas Schodet, Mindsensors.com, and my own enhancements/fixes into one. You can grab the latest enhanced NBC/NXC sourcecode from the following link using SVN:

https://mindboards.svn.sourceforge.net/ ... rsion_131/

The list of bug fixes and enhancements is really too long to list but here's a rough stab:

Fixes:

1. Fix the unbalanced GetProcArray and SetProcArray lengths. The SetProcArray should have 11 function pointers (not 9) in it just like the GetProcArray does. This will fix the bug when you pass a float type into a function that uses the SetProcArray to set the variable to a new value. Since the float type is not included in the SetProcArray the result is a locked up brick.

2. Fix the use of floating point constants so that they are marked as floats. Currently the compiler uses doubles for these constants and as a results links in library code for double to float conversions that is not necessary.

3. Fix the SET opcode bug where it does not handle 4 byte longs correctly.

4. Fix the bug in cCmdInterpPolyUnop2 where if both types are an array of the same int scalar type it always performs a MOV operation whether the opcode is OP_MOV or not. This function is called with several other opcodes in addition to MOV - none of which work correctly on scalar int arrays due to this bug.

5. Fix the bug in cCmdUnop2Flt where sqrt is called instead of sqrtf, causing unnecessary double to float library code to be linked into the firmware.

6. Fix the bug in the GETIN opcode where it incorrectly checks the type code for argument 1 twice instead of checking the type code of argument 1 and argument 2.

7. Fix the bug in ARRINIT where it assumes the output array type is compatible with the initial value type rather than checking both in the if condition.

8. Fix the bug in cCmdBinopFlt where it casts the left and right float inputs as SLONG for the MOD opcode - resulting in incorrect values in the output. fmodf should be used instead.

9. Fix the REPLACE opcode bug which breaks support for multi-dimensional arrays. As written it only works for arrays with 1 dimension.

10. Fix the STRINGTONUM opcode so that it works correctly with either int or float values in the string.

11. Fix the bug in cCmdLSCalcBytesReady so that it handles 16 byte IIC responses rather than a maximum of 15.

12. Fix the partial/wrong implementation of CommHSWrite, CommHSCheckStatus, and CommHSRead system call functions.

13. Fix the incorrect return type (should be UWORD rather than SBYTE) for the newly added CommBTConnection and CommBTOnOff system call functions.

14. Fix the bug that limits RIC parameters to 16 instead of 256 which should be supported (the IMG_SYMB_ARG mask should be 0x00FF rather than 0x000F).

15. Fix the missing RIC Circle opcode.

16. Fix the incorrect size (IMG_OP_LINE vs IMG_OP_RECT) checked for the RIC Rectangle opcode.

17. Fix the bug in cCommInterpreteCmd (in the POLLCMD case) where the high speed output pointer is limited to the size of the USB buf (64) rather than the size of the hig speed buf (128).

Enhancements:

1. Support multiple ports in the SetOutputState direct command instead of just one or 0xFF == all ports. I have simple code I can provide which supports 0x03 or 0xFC = AB, 0x04 or 0xFD = AC, 0x05 or 0xFE = BC, and 0x06 or 0xFF = ABC.

2. Add support for a user-definable program abort flag (rather than hard coded as BTN1 state == PRESSED_EV) so that you can use the 4th button in a user program.

3. Enable SETOUT opcode to handle scalar values for multiple ports in addition to specifying multiple ports via a byte array containing the port values (e.g., 0x03 == AB, 0x04 == AC, 0x05 == BC, and 0x06 == ABC).

4. Allow user programs to write/read more than 64 bytes at a time via the internal IOMapWrite and IOMapRead system calls.

5. Extensive enhancements to drawing code, including support for polyline/polygon and ellipse both with API functions and in RIC files. Support for RIC-based fonts.

6. Support for precise position based motor regulation (written by Nicolas Schodet)

7. Support for fast I2C communication

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

9. Support for pausing a running program, and single-stepping through the code

10. Enhanced random number generator

11. Support for low level input port digital pin manipulation

12. Support for a FileTell functionality (to check position of read pointer in a file).

13. Memory manager system call function for checking memory usage or forcing a dataspace compaction.

14. Support for DATA_MODE_NXT over RS485 so that the firmware automatically handles direct and system commands sent via RS485

15. Support for multi-NXT addressing via RS485 when in the new DATA_MODE_NXT data mode

16. Native opcodes for (nearly) every math.h standard C library function such as sin, cos, tan, asin, acos, atan, log, pow, etc...

17. Opcodes for low level direct memory addressing (reladdr, and addrex)

18. Support for getting/setting the display contrast.

19. Support for bitwise negation (complement)

20. Support for file system iteration via new system calls (FileFindFirst, FileFindNext, etc...)

21. Native opcodes for stopping another thread/task, formatting a number into a string (simple printf style opcode)

22. Native opcode for several fast array operations (min, max, mean, sort, etc...)

Probably lots more that I have forgotten.

John Hansen

Cool, thanks a lot. Someone should stick this high up the sticky thread section.

*updates his NXT*

Wait, did you just say I can allocate memory, or was that wishful reading on my part?

pepijndevos wrote:Cool, thanks a lot. Someone should stick this high up the sticky thread section.

so do you still think your vote

"I need the std firmware for NXC and do not use the enhanced firmware for this"

is still valid?

pepijndevos wrote:I also found http://git.ni.fr.eu.org/?p=nxt-firmware.git which is called NXT Improved Firmware. Is it the same thing? Now we can say "Nicolas Schodet knows" as well.

Please read http://nxt-firmware.ni.fr.eu.org/ about this NXT Improved firmware.

The NXT Improved Firmware is more suited if you want to dig into firmware internal and hack it with your own code, it can compile with GCC and I do my best to keep the history readable.

However the NXT Enhanced Firmware by John Hansen is much better for firmware users as it includes new features and many bugfixes.

So is that git link their combined work? Because it has both their names in the log.

I have included changes from John Hansen in the NXT Improved Firmware and gave credits to him as the commit author. If you look at the commit message, John Hansen is the author, and I am the committer.

John, how about putting this long feature list on a web page with a link to your firmware resources (svn repository, download...)?

schodet wrote:...John, how about putting this long feature list on a web page with a link to your firmware resources (svn repository, download...)?

+1

Done.

http://bricxcc.sourceforge.net/firmware.html (linked to from the main BricxCC page).

John Hansen

Dear John

Could you provide me/us some explanations/examples about topics you highlight in this topic:

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???

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?

low level input port digital pin manipulation

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

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

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

Thank you very much to provide the community such wonderfull tools, both firmware and NXC/Bricxcc.
Best regards
Ben

P.S All of those questions will help me to build a conference support i will give to parisian hacklabs about the possibilities of NXT/NXC in opensource rapid prototyping for robots. I will share this support here as soon at it will be OK. English Translation will also be available.