View mode: basic / threaded / horizontal-split · Log in · Help
January 08, 2013
Re: D for embedded system
On 01/08/2013 11:58 AM, Freddie Chopin wrote:
> To be even more specific - I'm talking about microCONTROLLERS (not
> micro-processors), ARM Cortex-M3 or Cortex-M4, STM32, LPC17xx, maybe
> even Cortex-M0 if the footprint is low enough... So no MMU, sometimes
> MPU (rarely), ROM in "hundreds of kilobytes", RAM in "tens of kilobytes"
> (sometimes less, rarely over 100kB - only for really big chips).

That makes sense. Our "smart" systems are, at a minimum, an ARM9 core 
(like an Atmel AT91), and we're drooling over the latest TI offerings 
(Cortex-A9 type stuff, like what's on the BeagleBone).

-- 
Matthew Caron, Software Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office
January 08, 2013
Re: D for embedded system
On 2013-01-08 17:52, Freddie Chopin wrote:

> Yes, we're talking about real bare-metal here (; I think D with it's
> safety fits really nicely in the embedded niche... I think that if D
> could be used on a system with 128kB of flash and 8kB of RAM that would
> be great. If it would require the chip to have more RAM it wouldn't be
> so great, but a 16kB or 32kB is still quite OK... This would probably
> require D's lib (phobos) to NOT depend on garbage collector (or maybe
> use it only in some high-level stuff that would be to big for such
> embedded system anyway).

This guy has created a GC free version of druntime and Phobos:

http://3d.benjamin-thaut.de/?p=20

-- 
/Jacob Carlborg
January 08, 2013
Re: D for embedded system
There are hundreds of ARM processors from several vendors from 
megahertz to gigahertz and from kilobytes to gigabytes. When we 
talk about ARMs it should be good to mention what kind of ARM we 
are using.

My interest is stm32f4 but everything I have done should be 
useful in the whole cortex-m series.

A minimum library has been working for a while and I think that D 
really is my choice. There have been a little silence when I have 
investigated linker problems and I am not able to use all my time 
for this anyway. When we now have so many interested people, I 
think I should go on.

My library is done with minimum set of files with minimum changes 
to them. There are about 20 changes required to get it compiled. 
This version can be run with 64 kb rom and 16 kb ram. It would be 
possible to get the library smaller by commenting out all 
unnecessary functions from all files. At this moment I want to 
keep the library as close to the original as possible.

This library does not yet have threads, but I have planned a 
minimun thread library which is somewhere between fiber and 
thread. Garbage collector is the gcstub version, which just calls 
directly malloc and free. The library does not require libc but 
there should be a proper libgcc. (a libgcc for cortex-m3 and -m4 
is not built by default when compiling gcc) The only functions 
needed outside are malloc, free, calloc and realloc and 
__aeabi_read_tp which returns the tls pointer.

Next I think I will make a list of required changes and then I 
will make a simple makefile to compile the library. If anybody is 
interested, please send an email to me and I will send those 
files back to you.
January 08, 2013
Re: D for embedded system
On Tuesday, 8 January 2013 at 20:13:54 UTC, Timo Sintonen wrote:
> Next I think I will make a list of required changes and then I 
> will make a simple makefile to compile the library. If anybody 
> is interested, please send an email to me and I will send those 
> files back to you.

You should definetely post that to github or somewhere (dropbox, 
...)! I'd be really interested to see the files (and maybe some 
details about strange things you need to do to get whole 
toolchain compiled), but I cannot see your e-mail with 
webinterface of this list...

BTW - on GitHub you could just fork phobos and do your changes as 
normal commits and that would be clearly visible to anyone (;

4\/3!!
January 08, 2013
Re: D for embedded system
09-Jan-2013 00:42, Freddie Chopin пишет:
> On Tuesday, 8 January 2013 at 20:13:54 UTC, Timo Sintonen wrote:
>> Next I think I will make a list of required changes and then I will
>> make a simple makefile to compile the library. If anybody is
>> interested, please send an email to me and I will send those files
>> back to you.
>
> You should definetely post that to github or somewhere (dropbox, ...)!
> I'd be really interested to see the files (and maybe some details about
> strange things you need to do to get whole toolchain compiled), but I
> cannot see your e-mail with webinterface of this list...
>
> BTW - on GitHub you could just fork phobos and do your changes as normal
> commits and that would be clearly visible to anyone (;
>

+1 for placing the work as a fork on github. It would also make sure the 
project is more visible and allow others to contribute easily. Plus you 
can scratch up the build instructions in a wiki page there (to avoid 
repeating it over personal emails and/or making a mail-list).

Just compare the current DMD/Phobos to the era prior to placing it on 
GitHub :)

-- 
Dmitry Olshansky
January 08, 2013
Re: D for embedded system
On Tuesday, 8 January 2013 at 16:52:05 UTC, Freddie Chopin wrote:
> Well, RTOSes ("schedulers") like FreeRTOS don't do that much - 
> you have threads, mutexes/semaphores, message queue and 
> software timers - all of them but the last one is covered by D 
> APIs, but now I thought that D probably just uses some OS 
> services for that (like POSIX pthread.h), wrapping it up a 
> little...

That seems true - internally D just wraps POSIX (pthread.h 
especially) or whichever threading mechanism exists on the OS.

Fortunately I have a rally nice and universal solution going 
around my head, which would make most of D runtime available for 
small embedded targets like Cortex-M3 (; If I could just stretch 
the day a bit, to - say - 96h...

4\/3!!
January 09, 2013
Re: D for embedded system
On Tuesday, 8 January 2013 at 20:42:07 UTC, Freddie Chopin wrote:

> You should definetely post that to github or somewhere 
> (dropbox, ...)! I'd be really interested to see the files (and 
> maybe some details about strange things you need to do to get 
> whole toolchain compiled), but I cannot see your e-mail with 
> webinterface of this list...

The address is in the text in several places in this thread, but 
here it is:
t.sintonen (at) luukku.com

>
> BTW - on GitHub you could just fork phobos and do your changes 
> as normal commits and that would be clearly visible to anyone (;
>

Of course this is the way to go. This just came so quickly. I 
should first write a makefile that works outside of my 
application and a list of changes. Because I have been messing 
around the files, I will also take a clean version of the 
original sources and write the changes again.

Meanwhile I am asking you, have you read the instructions on 
http://gdcproject.org/wiki/Cross%20Compiler and have you been 
able to make the toolchain?
January 09, 2013
Re: D for embedded system
On Wednesday, 9 January 2013 at 07:15:33 UTC, Timo Sintonen wrote:
> Meanwhile I am asking you, have you read the instructions on 
> http://gdcproject.org/wiki/Cross%20Compiler and have you been 
> able to make the toolchain?

I've read this article, but actually I was hoping I could "drop" 
GDC into a linaro  distribution of ARM bare-metal toolchain - 
https://launchpad.net/gcc-arm-embedded - it's a 4.7.x version, I 
don't know how big problem that is... So I haven't yet tried 
compiling the toolchain, but I guess that without your files it 
would not work anyway, right? (;

4\/3!!
January 10, 2013
Re: D for embedded system
On Wednesday, 9 January 2013 at 08:31:01 UTC, Freddie Chopin 
wrote:

> but actually I was hoping I could "drop" GDC into a linaro  
> distribution of ARM bare-metal toolchain - 
> launchpad.net/gcc-arm-embedded - it's a 4.7.x version, I don't 
> know how big problem that is... So I haven't yet tried 
> compiling the toolchain, but I guess that without your files it 
> would not work anyway, right? (;
>
You can and in this case you should make the toolchain first 
without library. It is possible to compile programs with gdc 
without the library as long as only c style functions are used.
A working linker script is needed to make the executable and a 
proper startup file is needed to make the executable work in the 
target platform. A suitable bootloader is needed to transfer the 
executable to the target processor.

When all these are working, the runtime library is needed.

The toolchain in https://launchpad.net/gcc-arm-embedded seems to 
be a good starting point for arm cortex processors. It has all 
the tools and also suitable linker scripts and startup files. But 
it is not aware of D.

As mentioned earlier in this thread, nobody has made this yet. So 
there is not an easy way to go. As long as gdc is not part of the 
gcc package, some extra work is always needed.
If the toolchain works, it is worth of try to replace gcc in 
there with the newest gcc with d patches. Some modifications are 
needed in the build script to enable d and disable libphobos.
January 15, 2013
Re: D for embedded system
After browsing the forums a bit I've stumbled across a discussion 
about C-style "volatile" and lack of something like that in D (I 
did not get too deep in the details yet), so I'd like to ask if 
there is something that can be used for the purpose of forcing 
memory accesses to happen ALWAYS, disregarding what sense such 
operations make to the compiler/optimizer?

In MCUs it's for example common for one peripheral register 
(memory address) to perform two distinct functions, depending on 
whether you read or write:

SPI->DR = data_to_send[0];
SPI->DR = data_to_send[1];
SPI->DR = data_to_send[2];
data_received[0] = SPI->DR;
data_received[1] = SPI->DR;
data_received[2] = SPI->DR;

This cannot be mixed, this cannot be skipped, this cannot be 
concatenated, as each read/write has to take place exactly in the 
order specified.

In C this is handled by making the memory address pointed 
"volatile":

typedef struct SPI_s
{
volatile uint32_t DR;
volatile uint32_t REG1;
volatile uint32_t REG2;
} SPI_t;

#define SPI ((SPI_t*)0x12345678)

How would you handle things like that in D? Is that possible? 
That's a crucial thing for system-programming (;

4\/3!!
1 2 3 4 5
Top | Discussion index | About this forum | D home