Mindboards

So thanks to this page, I know where to get the source, but when I change something, hoe can I compile it? http://bricxcc.sourceforge.net/firmware.html

I found that IAR workbench, which requires a huge signup form and is windows only. I do seem to remember someone mentioned using a regular GCC cross-compiler.

At present, the enhanced NBC/NXC firmware only compiles using the IAR Embedded Workbench for ARM version 4.2 which is a free download but is Windows only as you note. If you send me your changes I would be happy to compile them for you. Especially if they are totally awesome!

John Hansen

Especially if they are totally awesome!

Heh, regular awesome is just not awesome enough. It's all or nothing!

For the normal firmware (not enhanced and certainly not awesome), does using gcc not lead to much larger binaries or has that issue been fixed?

- Xander

About GCC, you can find instructions to compile the firmware using it on http://nxt-firmware.ni.fr.eu.org/. However, this improved firmware is not as complete as the enhanced firmware. I have a git branch where I merged changes from Enhanced firmware, tell me if you are interested.

@Xander: The size is a problem if you use the NXTGCC project which use an old ARM toolchain and which clobber the sources with unaligned variables accesses. This problem has been solved with NIF, but firmware is still larger than the one compiled with IAR, because of the larger runtime library (printf for example is really large in newlib).

Ok, so GCC is not a good idea. I'll boot up the windows box of my brother, while he's in school.

Why doesn't the enhance firmware work with GCC? Is that a matter of writing a makefile or whatever, or are some enhancements just not compatible?

What I'm trying to implement is a variable jump statement, which I posted to the NXC wishlist topic.

Can I use that NBC debugger or something like that for debugging, or do I really need a JTag cable for that?

Weee! This is fun.

It compiles, but which file do I upload to the NXT now?

I had to add my new opcode to the c_cmd_bytecodes.h, but I'm not sure if I did it right. I'm not sure if I did anything right for that matter.

https://gist.github.com/1716139

Thinking about it, how do I test it… I'd have to patch NBC first, or get a hex editor. I wonder where the source for that is hiding, it's not in the mindboards or brickcc repo as far as I can tell.

It is in the BCC repository inside the NXT folder as far as I understand: http://bricxcc.svn.sourceforge.net/viewvc/bricxcc/NXT/

Thanks!

Hrm, it has OP_JMP in 10 places, more than I'm comfortable to take a guess at. Half of them are quite easy, but I'm not sure about the rest.

I wonder if something like "set var label" actually works, which I kind of assumed. Ow, this is starting to look more complicated that the copy-paste one-line change I had imagined.

So for now that means I'll be using a hex editor, until I figure out how to read Pascal properly, or until someone thinks this idea is more than regularly awesome.

I think you are heading for disaster if you are trying to simply have the compiler generate your new opcode where it currently generates a JMP. You'd be way better off to work with the guy who wrote the compiler rather than trying to do something like this on your own. If you have trouble tracking him down let me know and I might be able to help.

The output of the IAR compiler is a .a79 file. That can be downloaded using BricxCC if you switch the filter on the dialog to be Alternate NXT Firmwares (or something like that).

Can you explain exactly what you think you'll be able to do with a JMP opcode that can take a variable? What would be the value that you put into the variable? A PC Delta? That would be a very hard value to get into your variable without another opcode that can work magic. You'd somehow have to be able to call an opcode that stores in the output variable the PC delta between two other lines of code or something very odd like that. If you have the compiler calculate the delta at compile time then you are back exactly in the same state as you are with the existing JMP opcode (i.e., the value is determined at compile time rather than at run time). If you want it to be an absolute JMP address (PC) then the same question needs to be answered. How do you get a valid PC value into the variable at runtime?

In any case, I am not convinced that this new opcode is a totally awesome change to the enhanced NBC/NXC firmware but I have an open mind. Your detailed explanation about how this would work and enable things you can't currently do may convince me otherwise.

John Hansen

I was looking at JMP as an example, how to implement the new jump.

Erm, offset, right. Hmm, I thought a JMP would be just the absolute index in the code space. But in fact you're saying "jump forward 3 lines"? Well, ship. Okay, back to the drawing board. What about subroutines, do they also call "the next clump"?

No, I guess not, since you said subret in fact uses the clump id. So what if you had an opcode that could call a subroutine from a clump id in a variable? Higher order subroutines Would that work?