Ada on Nintendo DS ?

Ada on Nintendo DS ?

[Natasha Kerensikova]

Hello,

I have been desiring getting a try at developing for embedded platforms
for a while now.

Moreover, I just happen to own a device that probably qualifies as
embedded, with two ARM CPUs (one ARM7 and one ARM9), 4 MB RAM and a few
DSPs. The device is known as Nintendo DS lite.

So how do I compile code suitable to run on such a device?

I haven't been able to find anything that perform such a task, but I
have missed it?

As far as I can tell, devkitARM is a toolchain derived from GCC that
targets my hardware (it seems there is also some libraries to deal with
DSPs and stuff, but I can care about this later on). On the other end,
gnatdroid seems to successfully translate Ada code into binary that can
be fed to ARM CPUs. So unless I'm missing something, there is nothing
new to discover, I would only need to merge both derivations.

Would anyone have an estimation or a bound on how difficult it can be?

I have never built a compiler myself (except gnat-aux ports, but it just
works, so I have no actual experience of making a compiler code build),
so I'm not sure exactly how much of a task it is.

Maybe I should start with smaller steps, like writing C stuff going
through devkitARM, and then only start aiming at Ada?


Thanks in advance for your insights,
Natasha

Re: Ada on Nintendo DS ?

[Stephen Leake]

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> Moreover, I just happen to own a device that probably qualifies as
> embedded, with two ARM CPUs (one ARM7 and one ARM9), 4 MB RAM and a few
> DSPs. The device is known as Nintendo DS lite.
>
> So how do I compile code suitable to run on such a device?
>
> I haven't been able to find anything that perform such a task, but I
> have missed it?
>
> As far as I can tell, devkitARM is a toolchain derived from GCC that
> targets my hardware (it seems there is also some libraries to deal with
> DSPs and stuff, but I can care about this later on). 

It should be straight-forward to include Ada in that toolchain. The hard
part will be the Ada runtime library; it assumes some operating system,
similar to POSIX. It is possible to use no runtime, but then you lose
some features of Ada (exceptions, fixed point, tasking, new/free, etc).

Is there an OS on the Nintendo?

> On the other end, gnatdroid seems to successfully translate Ada code
> into binary that can be fed to ARM CPUs. 

gnatdroid is intended for Android, a specific operating system. It might
be useful as an example.

> Would anyone have an estimation or a bound on how difficult it can be?

If Nintendo has a decent operating system, Ada should Just Work (similar
to the ports you describe doing)

But if it doesn't, the level of difficulty really depends on your level
of experience; since you seem to be new at configuring compilers, it
will be hard and confusing :(.

Definitely set a goal of a runtimeless compiler, and see if you can make
that work. Then think about what parts of the Ada runtime you really
need.

> Maybe I should start with smaller steps, like writing C stuff going
> through devkitARM, and then only start aiming at Ada?

That can be useful just to understand how all the tools work together.
In particular, writing a simple program in C, and the same in Ada, can
be instructive in finding out why the Ada compiler isn't doing the right
thing.

But it also leads to the Dark Side :). (as in, "I know I can do this
simple program in C; I'll put off porting Ada just a little longer").

-- 
-- Stephe

Re: Ada on Nintendo DS ?

[Natasha Kerensikova]

On 2012-04-28, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
> Natasha Kerensikova <lithiumcat@gmail.com> writes:
>> As far as I can tell, devkitARM is a toolchain derived from GCC that
>> targets my hardware (it seems there is also some libraries to deal with
>> DSPs and stuff, but I can care about this later on). 
>
> It should be straight-forward to include Ada in that toolchain. The hard
> part will be the Ada runtime library; it assumes some operating system,
> similar to POSIX. It is possible to use no runtime, but then you lose
> some features of Ada (exceptions, fixed point, tasking, new/free, etc).

Well, that's encouraging for a start :-)

Is there some "official" list of what does not have to be supported on
an RTL-less system? The C Standard has the notion of "freestanding" and
"hosted" environments, which basically means without or with libc (which
is quite weaker than POSIX); is there something similar in Ada RM? Or is
it up to the compiler provider to decide what belong to RTL and what is
code generated on bare metal?

For example I'm a bit surprised to see fixed point in the list, when I
would have naively thought appropriate inline code generation would be
enough (exactly like when I did fixed point "by hand" in 386 assembly).

> Is there an OS on the Nintendo?

I would have to double check, but as far as I remember no. There is only
a bootloader that transfers binary code from cartridge storage to memory
and jump to it, and that's it.

An even more fuzzy memory of mine says Nintendo sells a SDK that comes
with most of what you would expect from an OS, but that's not exactly
within hobbyist financial reach.

On the other hand, devkitARM comes with a libnds that might take care of
a reasonable amount of stuff.

>> On the other end, gnatdroid seems to successfully translate Ada code
>> into binary that can be fed to ARM CPUs. 
>
> gnatdroid is intended for Android, a specific operating system. It might
> be useful as an example.

That's all I expected from it, really.

My reasoning was that devkitARM is an example of
C --(1)--> GCC internals --(2)--> Nintendo DS
while gnatdroid is an example of
Ada --(3)--> GCC internals --(4)--> native Android

What I need is just arrows (2) and (3), and I chose gnatdroid for the
argument to lower the risk of stumbling on platform-related variation in
"GCC internals" part. Both are ARM code, and that's the closed target I
have found.

>> Would anyone have an estimation or a bound on how difficult it can be?
> Definitely set a goal of a runtimeless compiler, and see if you can make
> that work. Then think about what parts of the Ada runtime you really
> need.

That was most definitely my plan. First make RTL-less Ada run (which
might not be that easy considering "proving" something runs involves an
output, that require going through DSPs or direct access to LCD or
speakers), then bind divkitARM's libnds, and then the parts of libada I
miss, then celebration about the projet reaching such an incredibly
mature stage, then the rest of libada.

> But it also leads to the Dark Side :). (as in, "I know I can do this
> simple program in C; I'll put off porting Ada just a little longer").

Well remember I'm coming from a decade of allegiance to the Dark Side,
and still find most task to look easier in C (with the notable exception
of debugging low-quality code I have not written), and yet I kept being
irresistibly attracted to the Bright Sparkling Shiny Blinding Side ;-)


Thanks for your help,
Natasha

Re: Ada on Nintendo DS ?

[Robert A Duff]

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> Is there some "official" list of what does not have to be supported on
> an RTL-less system? The C Standard has the notion of "freestanding" and
> "hosted" environments, which basically means without or with libc (which
> is quite weaker than POSIX); is there something similar in Ada RM?

No.  Some of the annexes are optional, but that's not really
analogous to C's "freestanding".  An "Ada" without any
run-time libraries is almost certainly not Ada -- it might
be a subset of Ada.

>...Or is
> it up to the compiler provider to decide what belong to RTL and what is
> code generated on bare metal?

Yes.  The same is true of C, by the way, and I suppose any
other high-level language.  Language definitions are in the
business of telling compiler writers what to do, not how to
get it done.

Note that the line is kind of fuzzy in the case of GNAT, because
some features are implemented as RTL calls, but those calls
can sometimes be inlined.

- Bob

Re: Ada on Nintendo DS ?

[Brian Drummond]

On Fri, 27 Apr 2012 18:56:10 +0000, Natasha Kerensikova wrote:

> Hello,
> 
> I have been desiring getting a try at developing for embedded platforms
> for a while now.

Me too, though I haven't had all the success I would like, so far!
But I hope a beginner's viewpoint (at building gcc) may be of some 
interest...

In my case I want to be able to build the same version of gcc for native 
x86/x64, AVR (Arduino etc), Android, Raspberry Pi. I have managed the 
first two of these last month,(got stuck on Arm/Android last summer, 
moving house keeps getting in the way)

SO some comments that may help...
apologies if the details are inaccurate, my notes are on another machine.

(1) Building GCC "should be straightforward" as Stephen Leake says.
However it probably took me three weeks for x86 and AVR...

(a) Read the prerequisites but they may not be entirely accurate, and 
differ for different gcc versions, and Ada support in crosscompilers is a 
less explored corner...
My starting point, gcc_4.7.0_rc1_20120302 failed to build with one 
version of mpfr, and then failed another "prerequisite" (ppl or ploog) 
when I turned on Ada language support. I backtracked a version on the 
first, and omitted the second (which turned out to be an optional 
prerequisite).
The prerequisites gmp, mpc, mpfr are essential, others seem to be 
optional so far.
(b) Do not build in the source dir. The FAQ isn't kidding about this.
(c) Script the process. Helps to repeat it in the same order each time. I 
made many errors not doing so. Safest to delete the "build" directory 
each time (but slowest).
(d) Build a native version first. Then build it again, using itself as 
the compiler. If it can build itself, THEN use it to build a 
crosscompiler. Build the crosscompiler with C support only first, then 
build the C library, then turn on Ada support and build again.
(e) If it goes wrong, the gcc build system is so obscure that I found it 
difficult to make any progress, and sometimes had to do things the 
completely *wrong* way to move forward, intending to learn the right way 
later. e.g. patching a Makefile each time from the script, because I 
don't understand how to make the autoconfigure tools generate it 
correctly in the first place...
(f) Building gcc crosscompilers with Ada support definitely feels 
lonely...

I must say gcc4.7 rc1 seemed to build with fewer problems than the gcc4.6 
version I was trying to build last summer.

But having a working compiler (or using gnatdroid) is only part of the 
problem...

> Moreover, I just happen to own a device that probably qualifies as
> embedded, with two ARM CPUs (one ARM7 and one ARM9), 4 MB RAM and a few
> DSPs. The device is known as Nintendo DS lite.

I know nothing about the runtime support on that system. There are 
probably 2 levels of problem : (1) how to get a basic executable to run 
(gnatdroid produces console apps that run successfully on the Android) 
and (2) how to tap into the machine's higher level facilities, gamepad, 
GUI etc. This still seems to be a sticking point with Gnatdroid/Android 
let alone the Nintendo...

> As far as I can tell, devkitARM is a toolchain derived from GCC that
> targets my hardware (it seems there is also some libraries to deal with
> DSPs and stuff, but I can care about this later on). 

If its source is available, building it with Ada support may be possible. 
But what version of gcc? Bad BAD bad things happen when building gcc4.3.3 
with gcc4.5 for example - like negative enumerations (which 4.3 uses and 
4.5 rejects as errors!

Or the runtime system (libc, interface to GUI etc) may be portable to a 
newer GCC. Or you may be able to substitute the right version of GCC, 
separately built, with Ada support. But any of these may fail to build 
unless you can find or recreate the correct patches. IMO gcc is 
frighteningly fragile...

> On the other end,
> gnatdroid seems to successfully translate Ada code into binary that can
> be fed to ARM CPUs. So unless I'm missing something, there is nothing
> new to discover, I would only need to merge both derivations.

A promising approach, I think. Where I fell over was combining gnatdroid's 
output into the Android NDK build system to use anything more 
sophisticated than the console - i.e. open a simple window and display 
"Hello World". (I could get it through the linker, but the resulting 
executable didn't work)

I can imagine similar problems with the Nintendo.

> Maybe I should start with smaller steps, like writing C stuff going
> through devkitARM, and then only start aiming at Ada?

Definitely. This is an essential part of the process, so you have a 
"known good" chain to compare the Ada chain to, step by step.
Can I substitute my Ada .o for this C .o into the linker? If not, what is 
different between them?

>Would anyone have an estimation or a bound on how difficult it can be?

Difficult. But IMO the more people building Ada for embedded platforms, 
the easier it will become, if we share information and feed back fixes 
into the process. 
(Which I have not been doing, mainly because what I see as an obstacle, 
probably arises from my own blockheadedness rather than a genuine bug in 
gcc. And I have felt reluctant to submit them to sanity checks before 
passing any potential bugs upstream - mainly because there don't seem t 
be many of us trying it, so where to submit them?. Clearly there are 
some, as Jacob Sperre-Andersen recently reported success on Raspberry Pi
If you think my notes/scripts so far may be useful, I'll pass them on.)

Consider having another platform available as another way of moving 
forward. (This works on the Raspberry Pi but not the Nintendo... what is 
different between them?)

> Thanks in advance for your insights,
> Natasha

Re: Ada on Nintendo DS ?

[Rugxulo]

Hi,

On Apr 28, 4:22 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> On Fri, 27 Apr 2012 18:56:10 +0000, Natasha Kerensikova wrote:
>
> > I have been desiring getting a try at developing for embedded platforms
> > for a while now.
>
> (d) Build a native version first. Then build it again, using itself as
> the compiler. If it can build itself, THEN use it to build a
> crosscompiler. Build the crosscompiler with C support only first, then
> build the C library, then turn on Ada support and build again.

I'm not exactly big on cross-compiling, but it seems to be better
supported on Linux host than others (and faster too). I know that
sounds kinda silly or obvious, but it's nevertheless good to know (if
you're naive like me and think all things should be equal).

> (e) If it goes wrong, the gcc build system is so obscure that I found it
> difficult to make any progress, and sometimes had to do things the
> completely *wrong* way to move forward, intending to learn the right way
> later. e.g. patching a Makefile each time from the script, because I
> don't understand how to make the autoconfigure tools generate it
> correctly in the first place...

You could always check this mailing list:   http://sourceware.org/ml/crossgcc/

> I must say gcc4.7 rc1 seemed to build with fewer problems than the gcc4.6
> version I was trying to build last summer.

Dunno, and IIRC they stopped building "core" tarballs, so now it's
everything bundled together (including test suites, runtimes, etc.,
kinda bulky due to Java, etc).

> > Moreover, I just happen to own a device that probably qualifies as
> > embedded, with two ARM CPUs (one ARM7 and one ARM9), 4 MB RAM and a few
> > DSPs. The device is known as Nintendo DS lite.

Don't have one, never programmed anything similar, not very skilled.
(Then why am I responding? Heh, don't get mad.) Though I'm surprised
it has so little RAM, I thought modern developers couldn't live
without hundreds of MB.

> I know nothing about the runtime support on that system. There are
> probably 2 levels of problem : (1) how to get a basic executable to run
> (gnatdroid produces console apps that run successfully on the Android)

Good to know.

> and (2) how to tap into the machine's higher level facilities, gamepad,
> GUI etc. This still seems to be a sticking point with Gnatdroid/Android
> let alone the Nintendo...

What little I do know of Android is that a lot of high-level stuff
needs wrappers (facades?) via their internal native (Java?) API. See
http://code.google.com/p/android-scripting/.

> > As far as I can tell, devkitARM is a toolchain derived from GCC that
> > targets my hardware (it seems there is also some libraries to deal with
> > DSPs and stuff, but I can care about this later on).
>
> If its source is available, building it with Ada support may be possible.
> But what version of gcc? Bad BAD bad things happen when building gcc4.3.3
> with gcc4.5 for example - like negative enumerations (which 4.3 uses and
> 4.5 rejects as errors!

I don't really know Ada (sorry, I'm fairly noobish), but I don't think
Pascal allowed negative enums either (and Ada is heavily inspired by
Pascal, right?).

> IMO gcc is frighteningly fragile...

Definitely, it's scary and annoying, IMO. But I guess it's their
developers' decision, and they prefer POSIX (really Linux, but ...).

> > On the other end,
> > gnatdroid seems to successfully translate Ada code into binary that can
> > be fed to ARM CPUs. So unless I'm missing something, there is nothing
> > new to discover, I would only need to merge both derivations.
>
> A promising approach, I think. Where I fell over was combining gnatdroid's
> output into the Android NDK build system to use anything more
> sophisticated than the console - i.e. open a simple window and display
> "Hello World". (I could get it through the linker, but the resulting
> executable didn't work)

You mean something like makeToast or deviceGetInput? Again, see SL4A,
that's as close a guess as I can suggest. (I know you probably knew
this, but ....)

> >Would anyone have an estimation or a bound on how difficult it can be?
>
> Difficult. But IMO the more people building Ada for embedded platforms,
> the easier it will become, if we share information and feed back fixes
> into the process.

Well, everything is difficult, but honestly it can't be that hard
because I've seen that a lot of people have heavy interest in ARM and
Android, Nintendo DS, etc.

> Consider having another platform available as another way of moving
> forward. (This works on the Raspberry Pi but not the Nintendo... what is
> different between them?)
>
> > Thanks in advance for your insights,
> > Natasha

Okay, so here's the real tip I wanted to pass along, though it's far
from secret:  FreePascal's website claims that their ARM support
covers Linux, WinCE, GBA, and NDS. So there. I know it's not quite
"Ada" per se, but close enough to be comfortable (or at least moreso
than C, right?). And it doesn't need (barely any) GNU tools to build
or use, i.e. no complex GCC / POSIX muck (no offense!). So it should
be self-contained and easy to use (though I've not tried, I neither
have nor want a NDS).

http://sourceforge.net/projects/freepascal/files/NDS/2.6.0/

arm-nds-fpc-2.6.0.i386-win32.zip	2011-12-31	15.6 MB

Hmmm, I'm surprised it doesn't have Linux host binaries, but I blindly
assume it's easy to build as FPC is pretty darn portable.

Hope this helps (doubt it, but ...).

Ada on embedded devices (Was: Ada on Nintendo DS ?)

[Jacob Sparre Andersen]

Brian Drummond wrote:

> Difficult. But IMO the more people building Ada for embedded
> platforms, the easier it will become, if we share information and feed
> back fixes into the process.

Agreed.

You might want to follow the AVR-Ada mailing list/newsgroup
(nntp+news.gmane.org:gmane.comp.hardware.avr.ada), even if your primary
embedded platform is a different one.

I have a selection of different embedded devices here on my desk.  All
of which I intend to program in Ada at some point.

 + MSP430 (TI Launchpad) - GCC but no Ada reported yet (according to
   Google).

One known Ada project targeting the MSP430 used AdaMagic as a front-end
to a C compiler targeting MSP430.  Not my favourite solution, but
definitely a possible solution.

 + Atmel (Arduino etc.) - AVR-Ada works but without much of a run-time
   system.

We are actively using AVR-Ada on a commercial project I'm working on.

 + ARM (various boards) - GNAT works (apparently) flawlessly on
   Debian/Squeeze on Raspberry Pi.  Tero Koskinen is doing some work to
   get Gumstix modules to the same level of Ada support as the Raspberry
   Pi.  ACT has a cool demo of GNAT with a Ravenscar run-time running on
   Mindstorms NXT (I have some LEGO here in the office too ;-).

I'll publish build instructions and test results here as I get things to
work.

Greetings,

Jacob
-- 
"War does not determine who is right - only who is left."
                                         -- Bertrand Russell

Re: Ada on embedded devices (Was: Ada on Nintendo DS ?)

[Brian Drummond]

On Thu, 03 May 2012 14:37:28 +0200, Jacob Sparre Andersen wrote:

> Brian Drummond wrote:

> You might want to follow the AVR-Ada mailing list/newsgroup
> (nntp+news.gmane.org:gmane.comp.hardware.avr.ada), even if your primary
> embedded platform is a different one.

Thanks. Once I figured out that I just had to add news.gmane.org as a new 
newsserver in Pan, I looked at this and it is very useful. 
At some stage I ought to condense the problems I found with GCC4.7 and 
post there.

> I have a selection of different embedded devices here on my desk.  All
> of which I intend to program in Ada at some point.
> 
>  + MSP430 (TI Launchpad) - GCC but no Ada reported yet (according to
>    Google).

Agreed. At a guess, building GCC with Ada for MSP will be no more than 
usually painful, but writing a minimum RTS (or porting the AVR-Ada one) 
would be a lot of work.

>  + Atmel (Arduino etc.) - AVR-Ada works but without much of a run-time
>    system.
> 
> We are actively using AVR-Ada on a commercial project I'm working on.
Good to know. I have the "Blinky" example running on 3 platforms (Arduino, 
Teensy (where the LED is on a different port) and the Evil Mad Scientist 
breadboard... Working on stepper control through the Arduino MotorShield.

>  + ARM (various boards) - GNAT works (apparently) flawlessly on
>    Debian/Squeeze on Raspberry Pi.  Tero Koskinen is doing some work to
>    get Gumstix modules to the same level of Ada support as the Raspberry
>    Pi.  ACT has a cool demo of GNAT with a Ravenscar run-time running on
>    Mindstorms NXT (I have some LEGO here in the office too ;-).

My R-Pi should be here by the end of June :-)

R-Pi is getting a LOT of publicity at the moment, and it's a shame that 
Ada isn't riding on that wave yet. Especially since Ada has a good role 
as a teaching language, and the R-Pi is marketed as an educational 
product.

Don't forget Android. A touchscreen tablet could replace a lot of 
embedded systems in industry (DRO/CNC readouts/controllers for a start)
Gnatdroid on DragonflyBSD is a good start but its executables are not 
really integrated with the Android system.

> I'll publish build instructions and test results here as I get things to
> work.

Thanks, and ditto if I manage anything useful...

- Brian

Re: Ada on embedded devices (Was: Ada on Nintendo DS ?)

[Britt]

I ran across this site the other day: http://www.adafruit.com/ selling
Arduino and BeagleBoard kits. They need some Ada development kits to
go along with the hardware.

Re: Ada on embedded devices (Was: Ada on Nintendo DS ?)

[Tero Koskinen]

On Fri, 4 May 2012 04:17:14 -0700 (PDT)
Britt <britt.snodgrass@gmail.com> wrote:

> I ran across this site the other day: http://www.adafruit.com/ selling
> Arduino and BeagleBoard kits. They need some Ada development kits to
> go along with the hardware.

If you end up ordering something from Adafruit, don't forget to buy
Ada Lovelace stickers:
https://www.adafruit.com/products/701
https://www.adafruit.com/products/696

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: Ada on embedded devices

[BrianG]

On 05/04/2012 07:17 AM, Britt wrote:
> I ran across this site the other day: http://www.adafruit.com/ selling
> Arduino and BeagleBoard kits. They need some Ada development kits to
> go along with the hardware.
>
>
Apparently, you missed the "You must know how to program, preferrably in 
C."

I'm still trying to figure out just what this site is, besides a seller 
of hardware which looks like a good source.  I have yet to find any 
reference to (software) tools.

I like the (in-development) Raspberry Pi prototyping board.

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Ada on embedded devices (Was: Ada on Nintendo DS ?)

[Tero Koskinen]

On Thu, 03 May 2012 14:37:28 +0200
Jacob Sparre Andersen <sparre@nbi.dk> wrote:
> We are actively using AVR-Ada on a commercial project I'm working on.
> 
>  + ARM (various boards) - GNAT works (apparently) flawlessly on
>    Debian/Squeeze on Raspberry Pi.  Tero Koskinen is doing some work to
>    get Gumstix modules to the same level of Ada support as the Raspberry
>    Pi.

To be more precise: Gumstix Overo devices can run same Debian armel
distribution as Raspberry Pi devices. In addition, Overo can run
Debian armhf (which Raspberry Pi cannot).

Debian armhf does not contain GNAT yet. I have been working on the issue,
but compiling full GCC package with all languages is somewhat slow
on 720MHz machine... (I have GNAT for armhf done, but it is cross-compiled
on x86_64 machine, fully native build is not done yet.)

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: Ada on embedded devices (Was: Ada on Nintendo DS ?)

[Lucretia]

On Thursday, May 3, 2012 1:37:28 PM UTC+1, Jacob Sparre Andersen wrote:
> Brian Drummond wrote:
> 
> > Difficult. But IMO the more people building Ada for embedded
> > platforms, the easier it will become, if we share information and feed
> > back fixes into the process.

If you go to https://github.com/Lucretia/tamp and follow the instructions for building gcc there, you'll find that I've already done the work to get a bare metal compiler going on ARM using a custom and very bare RTS without any nasty hacks in the makefiles.
 
> I have a selection of different embedded devices here on my desk.  All
> of which I intend to program in Ada at some point.
> 
>  + MSP430 (TI Launchpad) - GCC but no Ada reported yet (according to
>    Google).

I also have one of these was aiming on using the above to play with it, as developing an OS may be too large in Ada due to the memory constraints of this chip - I don't know yet.

My aims are to play on tiny devices with the above tiny RTS, then as you get bigger, add OSes of which TAMP is aimed to be usable on small MCU's up to desktop.

Luke.

Re: Ada on Nintendo DS ?

[Micronian Coder]

Hi,

Have you considered looking into RTEMS?
http://wiki.rtems.org/wiki/index.php/RTEMSAda

There is a Nintendo DS BSP (http://wiki.rtems.org/wiki/index.php/Nds) that has support for some low level functions (e.g. LCD access). The Ada compiler for RTEMS was updated quite often last time I tried it (at least 3 years ago). When I experimented with Ada on RTEMS I built a cross compiler for the Nintendo GameBoy Advance on a Slackware Linux machine. Instead of running on real hardware, I ran the binary output in a GBA emulator (I forgot which one, and it wasn't maintained any longer when I found it). I only got as far as printing a Hello World program and translated a C pong game example into Ada that ran very well. There was an issue with exceptions not getting caught, but it looks like that may have been fixed in more recent version of GCC for RTEMS (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143 )

--Micronian Coder


On Friday, April 27, 2012 11:56:10 AM UTC-7, Natasha Kerensikova wrote:
> Hello,
> 
> I have been desiring getting a try at developing for embedded platforms
> for a while now.
> 
> Moreover, I just happen to own a device that probably qualifies as
> embedded, with two ARM CPUs (one ARM7 and one ARM9), 4 MB RAM and a few
> DSPs. The device is known as Nintendo DS lite.
> 
> So how do I compile code suitable to run on such a device?
> 
> I haven't been able to find anything that perform such a task, but I
> have missed it?
> 
> As far as I can tell, devkitARM is a toolchain derived from GCC that
> targets my hardware (it seems there is also some libraries to deal with
> DSPs and stuff, but I can care about this later on). On the other end,
> gnatdroid seems to successfully translate Ada code into binary that can
> be fed to ARM CPUs. So unless I'm missing something, there is nothing
> new to discover, I would only need to merge both derivations.
> 
> Would anyone have an estimation or a bound on how difficult it can be?
> 
> I have never built a compiler myself (except gnat-aux ports, but it just
> works, so I have no actual experience of making a compiler code build),
> so I'm not sure exactly how much of a task it is.
> 
> Maybe I should start with smaller steps, like writing C stuff going
> through devkitARM, and then only start aiming at Ada?
> 
> 
> Thanks in advance for your insights,
> Natasha