Lego NXT with GCC

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello !

I apologise if this has been discussed before but I have not managed to find such a thread so I decided to make one .

I'll be working with the LEGO NXT brick for some project for school.
I would like to use C as the programming language because the in built languages of the NXT are pretty crap and lack control.
I've found a GCC toolchain for this brick on

http://nxtgcc.sourceforge.net/
http://thenxtstep.blogspot.cz/20...

I'm reading on how it works but not really understanding the principle.

Does anyone have any experience/info on using the nxt with gcc compiler?

How will the language be written ? Are there going to be specific functions for the peripherals ?(light sensor , motor etc) or will I have to write those ?

The NXT brick uses an ARM7 processor and I think an atmega secondary but not sure .

Any info would be appreciated and thanks in advance !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC it's an Atmel SAM7 with an AVR MEGA for motor control.
Though not an answer, AdaCore's Libre website contains a GPL Ada compiler for the LEGO's SAM7.
http://libre.adacore.com/

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course, being both ATMEL parts, Studio 6 would do nicely. I've only played with SAM parts a little, but they seemed to program about like the AVR parats. Parats? Some sort of new avian chip?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm thanks for the info guys , I'll check that link out.
It's good if it works in AS6 , I use it for my avr's.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If this is correct:

http://mindstormsnxt.blogspot.co...

then the main CPU is AT91SAM7S256. If that's true you won't be programming the ARM using AS6 as it only support SAM D20, SAM3, SAM4 but not SAM7.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not try something like NQC and http://bricxcc.sourceforge.net/
This is so simple, that 6 graders can do it (I know, I've been teaching it a few years)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a project called lejos that is a java interpreter for the nxt. It is writen.in c and uses gcc to build it. You can use the build environment for your code as well as using their code for the low level stuff.

I'm not sure if coocox supports sam7.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Instead of the LEGO Ada cross-compiler IDE on Windows there's a LEGO Ada on Linux.
http://www.adacore.com/newsletter/autumn-winter-2012-2013
Go to "Academia Corner: Universidad Politécnica de Madrid".

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks everyone for the reply .
I've been busy for the past week and I forgot about this thread .

I decided to use the NXC language for now so I don't have to deal with the trouble of installing the lejos or other firmware .

One thing I noticed is that in the NXC language(not exactly C - by definition) There is an option to multitask.
Basically , tasks are defined in the main and when the main finishes then these tasks start executing in a parallel fashion.

My question is : Is this multithreading?
How is it executing many tasks (255 max) at once?
I'm assuming that it's not really executing them at once but that the cpu is just jumping from one task to the other . Is it really like that?

I haven't used ARM before so I don't know , but I assume that the principle is the same as 8 bit avr : One cpu core which executes instructions consecutively.

Thanks for the input

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

My question is : Is this multithreading?

Depends on the structure. In multi-tasking you have several "programs" each with a notional "main()" - though it might not be called that - and each runs in parallel not aware of the other programs running alongside. In multi-threading it's the case that any one of those main()s (maybe just one) can say "within this program I want several things to happen at once" and the main logic starts a number of coexisting threads that each take some part of the work. In PC land it's worth exploring "pthreads" to learn about the concept. This page is very good:

https://computing.llnl.gov/tutor...

uid23021@ws-czc1138h0b:~$ cat pthread.c
#include 
#include 
#include 
#define NUM_THREADS     5

void *PrintHello(void *threadid)
{
   long tid;
   tid = (long)threadid;
   printf("Hello World! It's me, thread #%ld!\n", tid);
   pthread_exit(NULL);
}

int main (int argc, char *argv[])
{
   pthread_t threads[NUM_THREADS];
   int rc;
   long t;
   for(t=0; t

Quote:

How is it executing many tasks (255 max) at once?

Almost anything that runs multiple programs (and that includes the Linux/Windows where your browser is showing this text) uses a timer interrupt at the heart of multi-tasking/multi-threading. Each time the timer "ticks" it switches control from one task/thread to the next. (that's a bit simplistic but it's kind of what happens). It doesn't matter if you have 3 tasks or 253 tasks. The difference is that it can take a lot longer for one of 253 to "get another go" as it does for one of three.
Quote:

I'm assuming that it's not really executing them at once but that the cpu is just jumping from one task to the other . Is it really like that?

Google RTOS for more. While modern PCs and high-end ARMs have cores that really do have 2/4/8 CPUs running multiple tasks/threads in parallel on the whole simple CPUs (like AVR and small ARMS like Cortex M) have just noe CPU and so it can only ever be executing one opcode at a time. To give the impression that it is running the opcodes from several different tasks/threads in parallel all it can do is run a handful of opcodes from task/thread 1 then switch that out and start running another handful from task/thread 2 and so on. When I say a "handful" it's a bit more than that. The switch between tasks/threads generally takes several hundred opcodes to achieve anyway so if it was only doing a handful from each thread it would spend more time executing the switching code (RTOS) than it does actually running the tasks. A usual happy medium on small micros is about 10ms between taks switches. At 8MHz that allows 80,000 opcodes to execute from each task before a switch (a "handful"!). For a long time Linux (and probably Windows) used 10ms as the task switching time but as CPUs got faster and faster so that the over-head of the few hundred opcodes to make a switch got less and less in the overall scheme of things the task switching time was changed. I think it's now 1ms in Windows. You, the user (who works in the realms of things happening 100-200ms apart) don't ever see this switching going on (what's more the program that has the "focus") is actually given a higher priority so it's tasks/threads are scheduled to run more often.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a bunch for the reply Clawson! :)
I'm going to check out all the keywords that you suggested , but your reply pretty much answered all my questions/doubts.